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

---
id: WARDEN-WP-ADHOC-2026-09-08
type: workplan
title: "Ad Hoc Tasks — 2026-09-08"
domain: infotech
repo: ops-warden
status: finished
owner: claude
topic_slug: netkingdom
created: "2026-09-08"
updated: "2026-09-08"
state_hub_workstream_id: "182f3aff-8c8a-5766-8a68-5fe35f423f7a"
---

# Ad Hoc Tasks — 2026-09-08

Four key-cape messages, all follow-on from `WARDEN-WP-0033`. Two carry answers
ops-warden's catalog was waiting for; both make a recorded blocker less true than
it reads. This is the T05 mechanism paying out — and this time the owner ran it
against us rather than us running it against them.

### T01 — Narrow the `rapp-qonto-keycape-client` blocker (msg `08d42f47`)

```task
id: WARDEN-WP-ADHOC-2026-09-08-T01
status: done
priority: high
state_hub_task_id: "29cef28a-d93b-5318-bfdb-69dbe11fa3ba"
```

The blocker recorded "still no key-cape-native exchange/rotation command",
`verified: source-read` against key-cape source on 2026-08-28. Accurate then;
two things landed after that read:

- `keycape service-token` (2026-09-05, KEY-WP-0014-T03) — the client_secret_basic
  exchange the blocker records as absent.
- `keycape verify-client` (2026-09-08) — rotation step 3 as one command,
  including predecessor rejection and identical-secret detection.

**Narrowed, not cleared**, as key-cape asked. What remains genuinely blocked is
steps 1-2: successor generation and the CAS write to both custodians. Those are
custody and deployment acts, key-cape deliberately ships no command for them, and
no admitted ops-warden lane authorizes them either (T03).

`verified` moved to `owner-confirmed` — the correction came from the owner.

`rotation.automatable` flipped `true` → `false`, which key-cape explicitly asked
us not to do "either way" without precision. Done with the precision they wanted,
in the only place the schema has room for it: the flag is a single hint consumed
by a future executable driver (`WARDEN-WP-0027` Strand B), and a driver told
`true` would attempt custody acts with no admitted transport — the dangerous
direction. So the flag fails safe and the *steps* now carry the per-step truth,
each naming whether it is automatable and why. Offered them a schema change if a
per-step field would serve better; not built on speculation.

### T02 — Record key-cape's acceptance of `key-cape-oidc-login` (msg `12f1bdfa`)

```task
id: WARDEN-WP-ADHOC-2026-09-08-T02
status: done
priority: high
state_hub_task_id: "8efb8013-7b90-52ef-a17c-d63f5ce3752c"
```

key-cape **accepted** ownership: interactive login, OIDC identity-token issuance
and MFA. This confirms the 2026-08-28 correction of `intended_owner` from
secrets-engine to key-cape, and confirms secrets-engine's 2026-08-21 refusal was
right. `verified: asked-and-waiting` → `owner-confirmed`.

**The lane stays `interim`.** Acceptance covers the identity half only. The
`fetch_command` yields an *OpenBao* token — the `netkingdom` mount, the
`role=<domain>` mapping, the token store and its enforcement are OpenBao's, with
role and policy definition railiance-platform's. `keycape login` yields a
key-cape issuer JWT to a private file: different credential type, different
verifier, different enforcement owner. Accepting an owner is not the same as the
owner fronting the lane, and `ADR-0003` says the interim cover is retired when
the front door exists, not when ownership is agreed. Retirement condition is now
recorded on the entry.

Their reading of the risk is right and we confirmed it: `warden_executes: false`
with a `wiki_ref` pointer, so per `ADR-0001` this is a pointer layer, not a code
path with programmatic consumers. `risk: standard` and
`workload_ref: not-applicable` are correct — a human identity act with no KV
path, consistent with how `ADR-0008` treats the other non-KV lanes.

### T03 — Answer "who executes Qonto rotation steps 1-2" (msg `0a6c9d88`)

```task
id: WARDEN-WP-ADHOC-2026-09-08-T03
status: done
priority: high
state_hub_task_id: "bd621821-2116-51c9-a09a-a3660b5e5557"
```

Answer: **nobody, admittedly, today** — and ops-warden must not invent one.

Steps 1-2 mutate custody on `platform/workloads/rapp-qonto/keycape-client` and
`sso/keycape-rapp-qonto-client`. Custody of platform workload paths is
railiance-platform's; the admitted execution front door for provisioned
secret-exec is `secrets-engine exec`. ops-warden owns neither and absorbing it
would be `ADR-0002` and `ADR-0005` violated in one act. Routed to
railiance-platform, with secrets-engine named as the transport owner — and
secrets-engine independently confirmed the same boundary three days earlier
(msg `15f0c0ca`): they will not rewrite a production lane's custody state from a
coordination message without owner confirmation.

key-cape was right not to treat a generic `warden route` match as authorization.
See T04 for what our own tool did when asked.

### T04 — `warden plan` returned `autonomous` for a custody *write* (defect)

```task
id: WARDEN-WP-ADHOC-2026-09-08-T04
status: done
priority: high
state_hub_task_id: "9ada01d2-b14b-579e-921c-275820f255db"
```

Verifying T03 against our own front door:

```
warden plan "generate a successor client secret ... and CAS-write it to
             OpenBao platform/workloads/... and sso/..." --json
  verdict: autonomous
  lane_id: rapp-qonto-keycape-client
  commands: warden access ... --exec / --out / --wrap
```

A need that says *generate* and *CAS-write* resolved to `autonomous` and was
answered with three **read** transports. This is the `WARDEN-WP-0033-T06` shape
recurring — a generic keyword match producing a confident wrong act — except T06
fixed one route by adding an exact lane, and the defect is in the classifier.
`warden plan` has no notion of read versus mutate intent, so every write need
matches the lane that *reads* the same path and comes back `autonomous`.

Not fixed here: a classifier is design work with an approval-semantics blast
radius, which the convention says is a workplan, not an adhoc.
Promoted to **`WARDEN-WP-0038`** (`proposed`).

Worth stating plainly: key-cape distrusted this output on principle and was right
to. Had they trusted it, our tool would have told them to proceed autonomously on
an unadmitted custody mutation.

### T05 — Acknowledge the KEY-WP-0009 handoff (msg `5bc58847`)

```task
id: WARDEN-WP-ADHOC-2026-09-08-T05
status: done
priority: low
state_hub_task_id: "06bf8508-d1a2-51b4-b951-02539524ebb9"
```

Informational; no route retired or changed. Their routing note matches ours:
"login / OIDC / MFA" → key-cape means **issuance only**, and secret *values*
route to OpenBao custody. Nothing to change in `wiki/CredentialRouting.md`.

Also records that the KEY-WP-0009 reply ops-warden reported never arriving indeed
never existed (KEY-WP-0014-T02, audited 2026-09-05). Our 2026-08-28 finding was
right, and the correction is theirs, recorded.

### T06 — Unpin two tests from a transient catalog state

```task
id: WARDEN-WP-ADHOC-2026-09-08-T06
status: done
priority: medium
state_hub_task_id: "a0b88db9-2886-54dd-a925-9e0521044aa0"
```

`test_stale_gaps_flags_unverified_even_when_the_date_is_today` and
`test_cli_route_gaps_fail_on_stale_exits_3` both asserted that
`key-cape-oidc-login` specifically sat `asked-and-waiting`. T02 answering that
question broke them — **the tests failed on good news**, not on a defect, and a
test that fails when a counterparty replies will get suppressed rather than read.

Both now assert the property they were always about: any lane whose blocker was
never re-established is stale regardless of its date, over whatever lanes are in
that state. The named-lane version of the claim already exists as a unit test on
`Delegation.is_verified`, which is where a fixture belongs.