Classify 5 proxy lanes interim; hold 6 pending secrets-engine
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 2s

Revised the classification axis after inspecting the entries: sorting by
subsystem was wrong. Nine of eleven lanes are a generic KV read with the
caller's own token, duplicating no owner procedure. Test is now
procedure-or-lifecycle vs generic read.

Interim now: rapp-qonto-keycape-client (key-cape), binky-company-email-imap
and binky-qonto-api (tenant-engine), railiance-backup-offsite-lane and
agent-harness-forgejo-deploy (re-establish procedures).

Held: the six thin-wrapper lanes are permanent only if secrets-engine exec
stays per-lane; asked whether it generalizes (msg 7d55d332).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-12 01:33:29 +02:00
parent cd074caaaa
commit 8d5188c24f
2 changed files with 81 additions and 30 deletions

View file

@ -41,23 +41,40 @@ Consequence: an absorbed need is indistinguishable from a designed one. Ownershi
drift is invisible by construction, which is exactly the failure mode the directive
targets.
## 3. Drafted classification of the eleven
## 3. Classification of the eleven (revised on inspection, founder review 2026-08-11)
Not authoritative — architecture judgement belongs to the founder (WP-0030 T02).
A first draft sorted by *subsystem* — tenant lanes to tenant-engine, workload lanes to
secrets-engine. Reading the entries showed that is the wrong axis. Nine of the eleven
share one `auth_method` ("caller's own OpenBao token" via operator OIDC or a
`workload-kv-read-*` policy) and one `fetch_command` shape
(`bao kv get -field=X <path>`). No owner procedure is duplicated in those. Contrast
`whynot-design-npm-publish` — npm config plus token injection into a specific tool, a
*procedure*, which is why WP-0019 handed it to secrets-engine.
| Lane | Draft reading | Intended owner / blocker |
**Test applied: owner-specific procedure or lifecycle → interim. Generic KV read →
thin wrapper, arguably permanent.**
### Interim (5) — classified
| Lane | Intended owner | Blocked on |
| --- | --- | --- |
| `key-cape-oidc-login` | **Permanent** | Login is key-cape's; the proxy is caller convenience, not custody |
| `openbao-api-key` | **Permanent (by design)** | Generic escape hatch for any OpenBao path; a catch-all, not a lane |
| `binky-company-email-imap` | Interim | **tenant-engine** — WP-0028 defined the tenant custody pattern; no tenant front door executes it |
| `binky-qonto-api` | Interim | **tenant-engine** — same |
| `rapp-qonto-keycape-client` | Interim | **tenant-engine** / key-cape — tenant workload client credential |
| `issue-core-ingestion-api-key` | Interim | **secrets-engine** — same shape WP-0019 closed for npm publish |
| `openrouter-llm-connect` | Interim | **secrets-engine** — high-risk provider key |
| `reuse-surface-hub-write-token` | Interim | **secrets-engine** |
| `railiance-backup-offsite-lane` | Interim | **secrets-engine** / railiance-platform |
| `forgejo-admin-api-token` | Interim | **secrets-engine** |
| `agent-harness-forgejo-deploy` | Interim | **secrets-engine** |
| `rapp-qonto-keycape-client` | key-cape | `client_secret_basic` exchange is a key-cape procedure; rotation already `automatable: true` |
| `binky-company-email-imap` | tenant-engine | `tenants/binky/...` custody, rotation owned by `binky-control` — split lifecycle |
| `binky-qonto-api` | tenant-engine | Same split |
| `railiance-backup-offsite-lane` | railiance-platform | Rotation is `re-establish`, a procedure ops-warden only describes |
| `agent-harness-forgejo-deploy` | railiance-platform / agent-harness | `re-establish` + alternative host-local key path |
### Held (6) — pending secrets-engine
`openbao-api-key`, `key-cape-oidc-login`, `issue-core-ingestion-api-key`,
`reuse-surface-hub-write-token`, `openrouter-llm-connect`, `forgejo-admin-api-token`.
Permanent **only if** `secrets-engine exec` stays per-lane and provisioned. If it
generalizes over arbitrary OpenBao lanes, all six become interim with secrets-engine as
intended owner. Asked directly (msg `7d55d332`). For three of them
(`issue-core-*`, `reuse-surface-*`, `openrouter-llm-connect`) production never touches
the proxy at all — External Secrets delivers the value and the proxy serves operator
verification only, which weakens the case that a front door is missing.
**No lane names `user-engine` as owner.** It appears only as a *consumer* inside
`coulomb-social-runtime-env` (route-only, owned by railiance-platform), whose rotation

View file

@ -120,8 +120,8 @@ delegation:
Backfill all 24 entries. `exec_owner` lanes become `mode: native`.
`ssh-cert-host-access` becomes `mode: permanent` (ops-warden's own lane). The
eleven undelegated proxies get a **drafted** classification plus intended owner,
flagged in the workplan for founder review rather than asserted as settled.
eleven undelegated proxies are classified per the founder review below — five
`interim` now, six held pending secrets-engine's answer.
### T03 — `warden route gaps` + conformance test
@ -178,22 +178,56 @@ fleet-visible capability gap.
- [ ] Founder has reviewed the interim/permanent classification of the eleven
- [ ] Register delivered to the named owner repos
## Open question for the founder
## Classification of the eleven (founder review, 2026-08-11)
The eleven undelegated proxies are: `openbao-api-key`, `key-cape-oidc-login`,
`issue-core-ingestion-api-key`, `reuse-surface-hub-write-token`,
`openrouter-llm-connect`, `railiance-backup-offsite-lane`, `forgejo-admin-api-token`,
`binky-company-email-imap`, `binky-qonto-api`, `rapp-qonto-keycape-client`,
`agent-harness-forgejo-deploy`.
### The test
An initial draft sorted by *subsystem* (tenant lanes → tenant-engine, workload lanes →
secrets-engine). Inspecting the entries showed that is the wrong axis. Nine of the
eleven share one `auth_method` — "caller's own OpenBao token" (operator OIDC via
key-cape, or a `workload-kv-read-*` policy) — and one `fetch_command` shape,
`bao kv get -field=X <path>`. No owner procedure is duplicated there. Contrast
`whynot-design-npm-publish`, which needs npm config and token injection into a specific
tool; that is a *procedure*, which is why WP-0019 handed it to secrets-engine.
**Test: owner-specific procedure or lifecycle → `interim`. Generic KV read →
ops-warden's thin wrapper is arguably `permanent`.**
### Interim — classify now (5)
| Lane | `intended_owner` | `blocked_on` |
| --- | --- | --- |
| `rapp-qonto-keycape-client` | key-cape | `client_secret_basic` exchange is a key-cape protocol procedure, not a KV read; rotation already `automatable: true`, so key-cape could front it today |
| `binky-company-email-imap` | tenant-engine | Custody at `tenants/binky/...` but rotation owner is `binky-control` — split lifecycle, no front door reconciling it |
| `binky-qonto-api` | tenant-engine | Same split, same tenant |
| `railiance-backup-offsite-lane` | railiance-platform | Rotation is `re-establish`, a multi-step procedure ops-warden only describes |
| `agent-harness-forgejo-deploy` | railiance-platform / agent-harness | `re-establish` plus an alternative host-local key path; two ways in, neither owner-fronted |
### Held pending secrets-engine (6)
`openbao-api-key`, `key-cape-oidc-login`, `issue-core-ingestion-api-key`,
`reuse-surface-hub-write-token`, `openrouter-llm-connect`, `forgejo-admin-api-token`.
These pass the test as `permanent` **only if `secrets-engine exec` stays per-lane and
provisioned.** If secrets-engine intends `exec --catalog <id>` to generalize over
arbitrary OpenBao lanes, the thin-wrapper argument collapses and all six become
`interim` with `intended_owner: secrets-engine` — ops-warden would then be duplicating
a front door the owner provides.
Asked directly (msg `7d55d332`, 2026-08-11): generic or per-lane; if generic, is it
near-term enough to mark now; and are there lanes they would decline, so those can be
marked permanent with the owner's position on record rather than ops-warden's inference.
Supporting detail: for `issue-core-ingestion-api-key`, `reuse-surface-hub-write-token`
and `openrouter-llm-connect`, **production never touches the proxy** — External Secrets
syncs the value into the cluster and the proxy exists for operator verification and
debugging. That weakens the case that they represent a missing front door at all.
**Do not backfill these six until the answer arrives.** A lane wrongly marked
`permanent` bakes in exactly the ownership drift this register exists to catch.
### user-engine
Draft reading, for review in T02: `key-cape-oidc-login` is **permanent** (login is
key-cape's and the proxy is convenience, not custody). `openbao-api-key` is the
generic escape hatch and is arguably permanent-by-design. The two `binky-*` tenant
lanes and `rapp-qonto-keycape-client` look like **tenant-engine** gaps (WP-0028
defined the custody pattern; no tenant front door executes it). The workload secret
lanes — `issue-core-*`, `openrouter-llm-connect`, `reuse-surface-*`,
`railiance-backup-*`, `forgejo-admin-*`, `agent-harness-forgejo-deploy` — look like
**secrets-engine** gaps of the same shape WP-0019 already closed for npm publish.
No lane names **user-engine** as owner — it appears only as a consumer inside
`coulomb-social-runtime-env` (`USER_ENGINE_PROXY_SECRET`, rotated at
`user-engine/user-engine-runtime`). Whether user-engine should front that lane itself