ops-warden/workplans/ADHOC-2026-08-11.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
WARDEN-WP-ADHOC-2026-08-11	workplan	Ad Hoc Tasks — 2026-08-11	infotech	ops-warden	finished	claude	custodian	2026-08-11	2026-08-15	9f99cc64-4682-5f20-b13e-89af2b6f7c70

Ad Hoc Tasks — 2026-08-11

T01 — Repair stale rapp-qonto-keycape-client wiki anchor (restore green routing suite)

id: WARDEN-WP-ADHOC-2026-08-11-T01
status: done
priority: medium

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.

• Repointed rapp-qonto-keycape-client.wiki_ref to wiki/CredentialRouting.md#routing-catalog-index (the live heading). No other entry used the stale anchor.
• uv run pytest tests/test_routing.py -q → 61 passed.
• 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)

id: WARDEN-WP-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.

• 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.
• 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.
• 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.
• 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

id: WARDEN-WP-ADHOC-2026-08-11-T03
status: done
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.

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.

• Park decision recorded and communicated (2026-08-11)
• Ownership transferred to WARDEN-WP-0027 T02; playbook pointer updated
• Ad-hoc closed so a wait item does not linger past the handoff