2026-07-21 01:51:38 +02:00
|
|
|
|
# Legacy suggestion migration — CUST-WP-0061-T06
|
|
|
|
|
|
|
|
|
|
|
|
> Status: one-time close-out, 2026-07-21. The state-hub `suggestions` table
|
|
|
|
|
|
> predates the work-record canon and is being retired to read-only legacy
|
|
|
|
|
|
> (fresh `intake` entity, not a rename-bridge — founder-reviewed decision,
|
|
|
|
|
|
> `WorkOrchestrationArchitectureDraft.md` §8 item 6). At the time of
|
|
|
|
|
|
> retirement, 10 suggestion records were still open (`stage: suggestion`,
|
|
|
|
|
|
> never promoted or declined) — real backlog signal from other domains'
|
|
|
|
|
|
> agents (ops-warden `WARDEN-WP-0012` gated routing scenarios, state-hub's
|
|
|
|
|
|
> own `STATE-WP-0069`/`STATE-WP-0073`, one binky-control repo-classification
|
|
|
|
|
|
> item). Rather than discard that signal, each is migrated here as a proper
|
|
|
|
|
|
> file-backed `intake` work record — landing in `the-custodian` since none
|
|
|
|
|
|
> of these ever had a repo-file origin (they were created hub-first,
|
|
|
|
|
|
> exactly the ADR-001 gap this whole effort exists to close) and
|
|
|
|
|
|
> `the-custodian` is the fleet's natural holding ground for cross-domain
|
|
|
|
|
|
> findings without a specific owning repo yet.
|
|
|
|
|
|
>
|
|
|
|
|
|
> Each intake below carries `origin: "legacy-suggestion:<uuid>"` for
|
|
|
|
|
|
> traceability back to the retired record. The originals were declined in
|
|
|
|
|
|
> the hub with a note pointing here (not deleted — historical record
|
|
|
|
|
|
> preserved). **If you own one of these domains, pick up the finding**:
|
|
|
|
|
|
> vet it, route it, and promote it into a proper workplan/task in the
|
|
|
|
|
|
> right repo — that's the whole point of the mechanism this repo now has.
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
>
|
|
|
|
|
|
> **ops-warden triage, 2026-07-21:** the 7 `WARDEN-WP-0012` findings
|
|
|
|
|
|
> (`CUST-IN-0001`–`0007`) were checked against ops-warden's live catalog
|
|
|
|
|
|
> before any hand-off. 6 were stale — their catalog entries had already
|
|
|
|
|
|
> been promoted to `status: active` weeks before this migration (policy +
|
|
|
|
|
|
> OIDC applied, ExternalSecrets synced, audit-verified) and the source
|
|
|
|
|
|
> suggestions just never got closed. Closed here as `outcome: absorbed`
|
|
|
|
|
|
> with a pointer to the shipped catalog entry, no Forgejo issue opened
|
|
|
|
|
|
> (the fleet doesn't use Forgejo issue tracking as a coordination
|
|
|
|
|
|
> mechanism — this file is the sanctioned equivalent). Only
|
|
|
|
|
|
> `CUST-IN-0004` (object-storage-sts) is genuinely still open; it is
|
|
|
|
|
|
> explicitly **not** ops-warden's to implement (its own playbook: *"do
|
|
|
|
|
|
> not ask ops-warden"*) — routed with the real owners named in its block.
|
2026-07-21 01:51:38 +02:00
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
|
id: CUST-IN-0001
|
|
|
|
|
|
title: "Issue-core ingestion API key OpenBao path"
|
|
|
|
|
|
lane: green
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
status: closed
|
|
|
|
|
|
outcome: absorbed
|
2026-07-21 01:51:38 +02:00
|
|
|
|
origin: "legacy-suggestion:256e94f0-833f-4502-a927-70873c3b5a1b"
|
|
|
|
|
|
origin_ref: "issue-core-ingestion-api-key"
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
notes: "Gated routing scenario from WARDEN-WP-0012. Was stale: ops-warden's
|
|
|
|
|
|
catalog entry issue-core-ingestion-api-key was already promoted to
|
|
|
|
|
|
status: active on 2026-07-02 (railiance-platform CCR-2026-0002 /
|
|
|
|
|
|
RAILIANCE-WP-0009 — policy + OIDC role applied, ExternalSecret
|
|
|
|
|
|
SecretSynced, access verified with OpenBao audit evidence) -- weeks
|
|
|
|
|
|
before this migration (2026-07-21). Absorbed, no action needed."
|
2026-07-21 01:51:38 +02:00
|
|
|
|
state_hub_intake_id: "019f81e5-ab50-716d-8d69-680d46001856"
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
|
id: CUST-IN-0002
|
|
|
|
|
|
title: "Activity-core issue sink consumer key custody"
|
|
|
|
|
|
lane: green
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
status: closed
|
|
|
|
|
|
outcome: absorbed
|
2026-07-21 01:51:38 +02:00
|
|
|
|
origin: "legacy-suggestion:a1a08013-1c5c-4471-8dc6-7bf0b2acb591"
|
|
|
|
|
|
origin_ref: "activity-core-issue-sink"
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
notes: "Gated routing scenario from WARDEN-WP-0012. Was stale: ops-warden's
|
|
|
|
|
|
catalog entry activity-core-issue-sink was already status: active
|
|
|
|
|
|
(reviewed 2026-06-18) -- over a month before this migration
|
|
|
|
|
|
(2026-07-21). Absorbed, no action needed."
|
2026-07-21 01:51:38 +02:00
|
|
|
|
state_hub_intake_id: "019f81e5-b404-7e7f-87a9-c92196351216"
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
|
id: CUST-IN-0003
|
|
|
|
|
|
title: "OpenRouter llm-connect OpenBao -> K8s Secret path"
|
|
|
|
|
|
lane: green
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
status: closed
|
|
|
|
|
|
outcome: absorbed
|
2026-07-21 01:51:38 +02:00
|
|
|
|
origin: "legacy-suggestion:b431df3a-3a0d-4ce9-abf9-d931dff58523"
|
|
|
|
|
|
origin_ref: "openrouter-llm-connect"
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
notes: "Gated routing scenario from WARDEN-WP-0012. Was stale: ops-warden's
|
|
|
|
|
|
catalog entry openrouter-llm-connect was already promoted to
|
|
|
|
|
|
status: active on 2026-07-02 (railiance-platform CCR-2026-0003 /
|
|
|
|
|
|
RAILIANCE-WP-0010 -- policy + OIDC role applied, ExternalSecret
|
|
|
|
|
|
SecretSynced, llm-connect rolled out on the value, access verified) --
|
|
|
|
|
|
weeks before this migration (2026-07-21). Absorbed, no action needed."
|
2026-07-21 01:51:38 +02:00
|
|
|
|
state_hub_intake_id: "019f81e5-be9a-733b-b8ea-711b220d4177"
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
|
id: CUST-IN-0004
|
|
|
|
|
|
title: "Object storage STS vending path (NK-WP-0007)"
|
|
|
|
|
|
lane: green
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
status: routed
|
2026-07-21 01:51:38 +02:00
|
|
|
|
origin: "legacy-suggestion:1fc77948-951a-43be-a3c9-8caebfc9243d"
|
|
|
|
|
|
origin_ref: "object-storage-sts"
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
routed_note: "Genuinely still open (2026-07-21 verification), unlike its 6
|
|
|
|
|
|
siblings. ops-warden's catalog entry object-storage-sts is status: draft
|
|
|
|
|
|
and its own playbook (ops-warden/wiki/playbooks/object-storage-sts.md)
|
|
|
|
|
|
is explicit: 'ops-warden does not vend object-storage credentials' /
|
|
|
|
|
|
'Do not ask ops-warden.' ops-warden's own tracking workplan
|
|
|
|
|
|
(WARDEN-WP-0012, finished 2026-06-27) already scoped this correctly --
|
|
|
|
|
|
its T04 delivered the pointer playbook only; the vending path itself is
|
|
|
|
|
|
out of its scope. Real owners per that workplan's own table and the
|
|
|
|
|
|
playbook: net-kingdom (architecture/trust boundaries,
|
|
|
|
|
|
docs/object-storage-sts-credential-vending.md), flex-auth (policy
|
|
|
|
|
|
decision: may this principal access bucket/prefix), railiance-platform
|
|
|
|
|
|
(OpenBao broker config, audit, bootstrap parent creds), artifact-store
|
|
|
|
|
|
(S3 client refresh/consumer, ARTIFACT-STORE-WP-0007). References
|
|
|
|
|
|
net-kingdom NK-WP-0007. Routed here rather than closed or
|
|
|
|
|
|
implemented -- promotion into a workplan is for one of those four repos'
|
|
|
|
|
|
owners to do, not the-custodian or ops-warden."
|
|
|
|
|
|
notes: "Gated routing scenario from WARDEN-WP-0012."
|
2026-07-21 01:51:38 +02:00
|
|
|
|
state_hub_intake_id: "019f81e5-d422-7e78-9b5a-8b4635fec15d"
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
|
id: CUST-IN-0005
|
|
|
|
|
|
title: "Human OIDC login via key-cape / Keycloak"
|
|
|
|
|
|
lane: green
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
status: closed
|
|
|
|
|
|
outcome: absorbed
|
2026-07-21 01:51:38 +02:00
|
|
|
|
origin: "legacy-suggestion:b3b59fbe-6932-4934-b960-e9f3f244eeb1"
|
|
|
|
|
|
origin_ref: "human-oidc-login"
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
notes: "Gated routing scenario from WARDEN-WP-0012. Was stale: covered by
|
|
|
|
|
|
ops-warden catalog entry key-cape-oidc-login (status: active, reviewed
|
|
|
|
|
|
2026-06-27) -- 'Login lane (WP-0014 T4), interactive auth bootstrap.'
|
|
|
|
|
|
Used directly this session (2026-07-20) to fetch the forgejo-admin-api-token
|
|
|
|
|
|
credential via bao login -method=oidc. Absorbed, no action needed."
|
2026-07-21 01:51:38 +02:00
|
|
|
|
state_hub_intake_id: "019f81e5-f82b-70c8-8948-8fc07e1879e0"
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
|
id: CUST-IN-0006
|
|
|
|
|
|
title: "flex-auth policy decision before sensitive action"
|
|
|
|
|
|
lane: green
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
status: closed
|
|
|
|
|
|
outcome: absorbed
|
2026-07-21 01:51:38 +02:00
|
|
|
|
origin: "legacy-suggestion:1e152a52-88a7-455c-b35b-36ef9a24beeb"
|
|
|
|
|
|
origin_ref: "flex-auth-resource-check"
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
notes: "Gated routing scenario from WARDEN-WP-0012. Was stale: covered by
|
|
|
|
|
|
ops-warden catalog entry flex-auth-policy-check (status: active,
|
|
|
|
|
|
reviewed 2026-06-18) -- 'Authorization decision: may this actor perform
|
|
|
|
|
|
this action.' Absorbed, no action needed."
|
2026-07-21 01:51:38 +02:00
|
|
|
|
state_hub_intake_id: "019f81e6-06f1-7718-bac1-c93ee29265b9"
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
|
id: CUST-IN-0007
|
|
|
|
|
|
title: "auth_principals sync for host principal deploy"
|
|
|
|
|
|
lane: green
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
status: closed
|
|
|
|
|
|
outcome: absorbed
|
2026-07-21 01:51:38 +02:00
|
|
|
|
origin: "legacy-suggestion:0ddbfc0c-469a-4d73-a20f-06071b7114a0"
|
|
|
|
|
|
origin_ref: "host-principal-deploy"
|
ops-warden triage: 6/7 CUST-IN findings were stale, close as absorbed
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:25:11 +02:00
|
|
|
|
notes: "Gated routing scenario from WARDEN-WP-0012. Was stale: covered by
|
|
|
|
|
|
ops-warden catalog entry railiance-infra-principals (status: active,
|
|
|
|
|
|
reviewed 2026-06-18) -- 'Host SSH principal file or force-command
|
|
|
|
|
|
deployment,' owner_repo railiance-infra. Absorbed, no action needed."
|
2026-07-21 01:51:38 +02:00
|
|
|
|
state_hub_intake_id: "019f81e6-1149-78aa-97d2-635c75622e9e"
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
|
id: CUST-IN-0008
|
|
|
|
|
|
title: "Roll out weekly legacy-meter review on Railiance activity-core"
|
|
|
|
|
|
lane: blue
|
|
|
|
|
|
status: open
|
|
|
|
|
|
origin: "legacy-suggestion:05da5540-e7cd-41fb-a511-3c1572e4604f"
|
|
|
|
|
|
origin_ref: "weekly-legacy-meter-review-railiance-rollout"
|
|
|
|
|
|
notes: "From STATE-WP-0069 (financials domain). Migrated 2026-07-21."
|
|
|
|
|
|
state_hub_intake_id: "019f81e6-198b-7df7-964e-6f8c06443454"
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
|
id: CUST-IN-0009
|
|
|
|
|
|
title: "Rebuild activity-core:railiance01-prod for legacy-meter 8h capture"
|
|
|
|
|
|
lane: blue
|
|
|
|
|
|
status: open
|
|
|
|
|
|
origin: "legacy-suggestion:8b3301d6-0222-41e4-89c9-99e8c6dd5248"
|
|
|
|
|
|
origin_ref: "legacy-meter-8h-capture-railiance-rollout"
|
|
|
|
|
|
notes: "From STATE-WP-0073 (financials domain). Migrated 2026-07-21."
|
|
|
|
|
|
state_hub_intake_id: "019f81e6-2348-72a8-8ec9-edb851acb9aa"
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
|
id: CUST-IN-0010
|
|
|
|
|
|
title: "Reclassify repos and guidance docs to the new sector domain scheme"
|
|
|
|
|
|
lane: green
|
|
|
|
|
|
status: open
|
|
|
|
|
|
origin: "legacy-suggestion:9c1de00d-7f2c-43f9-aaef-62356038c0b7"
|
|
|
|
|
|
origin_ref: "binky-control fix-consistency C-24 / session 2026-07-16"
|
|
|
|
|
|
notes: "Originated from a binky-control fix-consistency C-24 classification
|
|
|
|
|
|
gap. Migrated 2026-07-21."
|
|
|
|
|
|
state_hub_intake_id: "019f81e6-2a31-7bee-b50a-8e9ca67267b7"
|
|
|
|
|
|
```
|