Triage the stale ops-warden inbox (11 unread)

Answers owed were sent and all 11 marked read: railiance-platform front-door
thread confirmed closed (both lanes active, selector is openrouter-llm-connect),
railiance01/activity-core and llm-connect requests superseded, secrets-engine
warden-sign referred back to the operator.

Leaves T03 open: whether to keep or withdraw the warden-sign AppRole now that
the credential broker serves the VAULT_TOKEN lane.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

workplans/ADHOC-2026-08-11.md

@@ -4,11 +4,12 @@ type: workplan
 title: "Ad Hoc Tasks — 2026-08-11"
 domain: infotech
 repo: ops-warden
-status: finished
+status: active
 owner: claude
 topic_slug: custodian
 created: "2026-08-11"
 updated: "2026-08-11"
+state_hub_workstream_id: "c8c51e07-f42d-43b1-873f-fec6cda7ed25"
 ---
 
 # Ad Hoc Tasks — 2026-08-11
@@ -19,6 +20,7 @@ updated: "2026-08-11"
 id: ADHOC-2026-08-11-T01
 status: done
 priority: medium
+state_hub_task_id: "b0420c81-81bb-4733-9aa0-e9c867503387"
 ```
 
 rapp-postgres (msg `96907986`, residual from RAPP-POSTGRES-WP-0002-T04) reported the
@@ -33,3 +35,63 @@ an anchor that does not exist. The intended heading is `## Routing catalog index
 - [x] `warden route find "database credential"` still returns the active
       `database-dynamic-credentials` rapp-postgres entry; that T04 route is untouched —
       still `warden_executes: false` with no `steps:` block (pointer, not procedure).
+
+### T02 — Triage the stale ops-warden inbox (11 unread, C-28/C-29)
+
+```task
+id: ADHOC-2026-08-11-T02
+status: done
+priority: medium
+```
+
+`fix-consistency` flagged 11 unread messages older than 3 days, two of them as possible
+work requests (C-29). All eleven triaged, answered where an answer was owed, and marked
+read. Inbox is now empty.
+
+- [x] **railiance-platform front-door thread** (`72d3ee84`, `cb50ea3c`, `6b058584`,
+      `5d47caaa`, `78c1c075`) — confirmed both lanes active and placeholder-free
+      (`issue-core-ingestion-api-key` catalog.yaml:219, `openrouter-llm-connect`
+      catalog.yaml:283, promoted in 364eb7d), closing RAILIANCE-WP-0009-T06 and
+      RAILIANCE-WP-0010-T06. Answered their open question: the stable ops-warden
+      selector is **`openrouter-llm-connect`**, not `llm-connect-openrouter-api-key`;
+      asked them to cross-reference the id in CCR-2026-0003 rather than have ops-warden
+      rename an active, test-referenced lane.
+- [x] **railiance01 / activity-core** (`467153f3`, `3b9c6a77`, `fe796249`, `674f02e0`) —
+      superseded. STATE-WP-0071 finished; the `.git/FETCH_HEAD` blocker was filesystem
+      ownership, not SSH, and no `warden sign` was needed. Nothing was ever open for
+      ops-warden. Pointed activity-core at `warden plan` / `warden route find` instead of
+      hub round-trips for access questions.
+- [x] **llm-connect LLM-WP-0006** (`f5975211`) — superseded: `OPENROUTER_API_KEY` was
+      provisioned through OpenBao custody 2026-07-02 (CCR-2026-0003), ES synced,
+      llm-connect rolled out. Restated the boundary — ops-warden does not populate
+      Secrets — and pointed at the now-active catalog lane. `LLM_CONNECT_URL` wiring
+      remains activity-core's.
+- [x] **secrets-engine warden-sign** (`80456912`) — see T03; replied with status and
+      referred the live-apply question to the owner.
+
+### T03 — Open question for the operator: withdraw or keep the warden-sign AppRole
+
+```task
+id: ADHOC-2026-08-11-T03
+status: wait
+priority: medium
+```
+
+secrets-engine (msg `80456912`, 2026-06-29) is holding a validated non-mutating dry-run
+for policy + AppRole `warden-sign` (exact `update` grants on `ssh/sign/{agt,adm,atm}-role`).
+It is blocked on two **operator** actions: recording/approving the SECRETS-WP-0004
+decision, and providing the mode-0600 lane bootstrap token
+(`~/.secrets-engine/bootstrap/prod-warden-sign.token`). secrets-engine correctly refused
+to substitute the broader platform-admin token.
+
+**The request has been overtaken by events.** Since 2026-07-01 the scoped `VAULT_TOKEN`
+need is served by the railiance-platform credential broker
+(`ops-warden-warden-sign-token`, active; `credential.py exec --grant ops-warden/warden-sign`,
+proven via `make credential-exec-ops-warden-smoke`) — no AppRole involved.
+
+Decision needed from Bernd: keep the AppRole as a broker-independent fallback path to
+signing, or withdraw SECRETS-WP-0004. ops-warden's recommendation is **withdraw** unless
+there is a concrete failure mode the broker cannot cover — a second standing credential
+to rotate and audit is a real cost for a lane that currently works. Not ops-warden's call;
+asked secrets-engine to hold live apply until it resolves. Task stays `wait` pending that
+answer.