---
id: ADHOC-2026-08-11
type: workplan
title: "Ad Hoc Tasks — 2026-08-11"
domain: infotech
repo: ops-warden
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

### 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 — Open question for the operator: withdraw or keep the warden-sign AppRole

```task
id: ADHOC-2026-08-11-T03
status: wait
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.

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.