ops-warden/history/2026-08-11-delegation-surface-assessment.md
tegwick 8d5188c24f
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 2s
Classify 5 proxy lanes interim; hold 6 pending secrets-engine
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>
2026-08-12 01:33:29 +02:00

104 lines
5.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Delegation surface assessment — 2026-08-11
**Trigger:** founder directive — ops-warden should work with, but never replace or
duplicate, secrets-engine, tenant-engine, user-engine and other NetKingdom
components. Covering an unfilled gap is acceptable if the gap stays visible, gets
filled with proper governance, and ops-warden then delegates.
**Method:** enumerate `registry/routing/catalog.yaml` by execution mode; check
`wiki/AccessRouting.md` and `wiki/playbooks/catalog-lane-promotion.md` for existing
interim/delegation doctrine; compare against SCOPE/INTENT claims.
---
## 1. Execution surface (24 catalog entries)
| Mode | Count | Entries |
| --- | --- | --- |
| `warden_executes: true` — ops-warden's own authority | 1 | `ssh-cert-host-access` |
| `exec_owner:` set — delegated, route-primary/proxy-fallback | 2 | `whynot-design-npm-publish` (secrets-engine), `ops-warden-warden-sign-token` (railiance-platform broker) |
| `exec_capable` proxy, **no** `exec_owner` | 11 | `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` |
| route-only pointer | 10 | remainder |
**Finding.** The delegation primitive exists, is proven in production, and is used by
**2 of 24** lanes. Eleven lanes have ops-warden as the de facto front door with no
record of who should own it instead.
## 2. The doctrine is not written down
- `wiki/AccessRouting.md` — the canonical "what ops-warden answers" page — contains
**no mention of secrets-engine** and no section on interim positions. A worker or
agent reading it cannot tell that `warden access` proxying a workload secret is a
stopgap rather than the design.
- `wiki/playbooks/catalog-lane-promotion.md` gates draft→active on the lane
*working* (zero placeholders, resolvable, tests green). It never asks whether
ops-warden should be the one executing it.
- The delegation intent for `whynot-design-npm-publish` lives in WP-0019 prose and
SCOPE; the *machine-readable* expression (`exec_owner`) was a by-product, not a
policy applied catalog-wide.
Consequence: an absorbed need is indistinguishable from a designed one. Ownership
drift is invisible by construction, which is exactly the failure mode the directive
targets.
## 3. Classification of the eleven (revised on inspection, founder review 2026-08-11)
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.
**Test applied: owner-specific procedure or lifecycle → interim. Generic KV read →
thin wrapper, arguably permanent.**
### Interim (5) — classified
| Lane | Intended owner | Blocked on |
| --- | --- | --- |
| `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
guidance points at the OpenBao path `user-engine/user-engine-runtime` for
`USER_ENGINE_PROXY_SECRET`. So a user-engine runtime secret exists and is routed, but
user-engine fronts nothing itself. Whether it should own that lane is worth confirming
rather than assuming either way.
## 4. Secondary finding — SCOPE drift
`SCOPE.md` "Where we are" was dated **2026-07-01** and stated *"Active work: none
open in ops-warden after WP-0022/0023."* Six workplans have shipped since
(WP-00240026, WP-0028, WP-0029 finished; WP-0027 sits in `backlog`), adding
`warden plan`, `warden desk`, `warden taint`, `warden rotate-guide`, experiential
memory, the tenant custody pattern, and the build-phase organization posture axis.
SCOPE understated the repo by roughly six weeks of work. Corrected in this pass.
## 5. Recommendation
WARDEN-WP-0030 — record `delegation:` (mode / intended_owner / blocked_on) on every
entry, expose `warden route gaps`, gate promotion on the ownership question, and
publish the resulting interim register to the owner repos. Absence of a delegation
block should read as *interim, owner unknown* — a question — never as settled
ownership.
The measure of success is not fewer proxies. It is that no proxy exists without an
answer to *"who should own this front door, and what is missing?"*