the-custodian/intake-legacy-suggestions-migration.md

193 lines
8.5 KiB
Markdown
Raw Normal View History

# 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.
```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
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."
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
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."
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
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."
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
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."
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
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."
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
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."
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
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."
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"
```