--- id: ADHOC-2026-08-11 type: workplan title: "Ad Hoc Tasks — 2026-08-11" domain: infotech repo: ops-warden status: finished owner: claude topic_slug: custodian created: "2026-08-11" updated: "2026-08-15" state_hub_workstream_id: "c8c51e07-f42d-43b1-873f-fec6cda7ed25" --- # Ad Hoc Tasks — 2026-08-11 ### T01 — Repair stale `rapp-qonto-keycape-client` wiki anchor (restore green routing suite) ```task 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 focused routing suite at 60/61: `test_every_wiki_ref_anchor_resolves` failed because `rapp-qonto-keycape-client` pointed at `wiki/CredentialRouting.md#credential-routing-catalog`, an anchor that does not exist. The intended heading is `## Routing catalog index`. - [x] Repointed `rapp-qonto-keycape-client.wiki_ref` to `wiki/CredentialRouting.md#routing-catalog-index` (the live heading). No other entry used the stale anchor. - [x] `uv run pytest tests/test_routing.py -q` → **61 passed**. - [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 state_hub_task_id: "546a4299-314c-448d-b2fb-201ddc50353c" ``` `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 — warden-sign AppRole: PARKED pending WP-0027 break-glass + ops-bridge cutover ```task id: ADHOC-2026-08-11-T03 status: done priority: medium state_hub_task_id: "b930df62-b8dd-45ae-b0a5-98298cdfa1b6" ``` 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. **Resolved 2026-08-11: parked** — neither withdrawn nor proceeding. Founder decision after reviewing the mechanics. Communicated to secrets-engine (msg `863c7b57`) with an explicit instruction to stop holding apply readiness. An initial recommendation to **withdraw** was revised on inspection: - `warden sign` reads `VAULT_TOKEN` from the environment and has no AppRole login path (`src/warden/vault.py:24-27`). The AppRole is a way for a *host* to obtain a token, not an ops-warden code path — withdrawing costs no code and removes no working capability. For the workstation, the broker plus attended operator OIDC is sufficient. - The uncovered case is **unattended signing on a remote host** — the pending ops-bridge cert_command cutover. `wiki/playbooks/ops-bridge-tunnel-cert.md:61` still falls back to a manually exported `VAULT_TOKEN` there. - Running the broker on that host means placing the railiance-platform checkout *and its issuer token* (`credential-broker-warden-sign-issuer` — authority to mint warden-sign tokens repeatedly) on it. The AppRole exchanges for a `warden-sign`-only token (`update` on `ssh/sign/{agt,adm,atm}-role`). Both are standing credentials on a remote host; **the AppRole is the narrower one**, and is the established NetKingdom pattern for this shape (`rein-openweights-openrouter-approle`, `agent-harness-binky-mail-approle`). No circular dependency exists today: OpenBao is a public endpoint (`https://bao.coulomb.social`), so obtaining a cert never requires already holding one. **Un-park triggers** (either one re-opens the question): 1. **WARDEN-WP-0027** (backlog) designs the graded lockdown / break-glass path and its explicit trust-root — a second autonomous path to signing is an input to that design, not an isolated decision. 2. **ops-bridge cert_command live cutover** reaches unattended signing on a remote host. Cheap to reverse: the secrets-engine dry-run plan is validated, re-runnable, and correct as drafted. The two operator gates (SECRETS-WP-0004 decision, mode-0600 lane bootstrap token) are deliberately *not* being satisfied while parked. **Closed 2026-08-15.** Neither un-park trigger has fired: 1. `WARDEN-WP-0027` is still `backlog`; T02 (graded lockdown / break-glass) stays `cancel` with the workplan. The parked AppRole remains an input on that task. 2. ops-bridge live cert_command cutover has not reached unattended signing on a remote host. WP-0016 is finished as *pilot-ready and handed off*, not migrated. This ad-hoc's job was the operator question (withdraw vs keep). The 2026-08-11 answer stands: **neither — park and hand off**. Applying or withdrawing the AppRole is out of scope here and would re-open the operator gates that were deliberately left unsatisfied. Long-term ownership is `WARDEN-WP-0027-T02` (and the ops-bridge cutover if that arrives first). secrets-engine already has the park instruction (msg `863c7b57`); no new apply/withdraw ask. - [x] Park decision recorded and communicated (2026-08-11) - [x] Ownership transferred to `WARDEN-WP-0027` T02; playbook pointer updated - [x] Ad-hoc closed so a `wait` item does not linger past the handoff