Every execution position is now explicit. Catalog entries carry delegation.mode (permanent / native / interim) with intended owner and blocker. warden route gaps lists the interim set. Promotion requires the ownership question. Doctrine lives in AccessRouting.md; the register was published to the named owner repos.
12 KiB
| id | type | title | domain | repo | status | owner | topic_slug | planning_priority | planning_order | created | updated | state_hub_workstream_id |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| WARDEN-WP-0030 | workplan | Delegation register — make gap-covering interim, visible, and retirable | infotech | ops-warden | finished | grok | custodian | high | 30 | 2026-08-11 | 2026-08-15 | 29f3fcb3-e3c5-4f9d-bdfd-f76254754e21 |
WARDEN-WP-0030 — Delegation register
Origin
Founder directive 2026-08-11: ops-warden should work with, but never replace or duplicate, secrets-engine, tenant-engine, user-engine and other NetKingdom components. It is acceptable for ops-warden to cover a gap where needed security functionality is not yet systematically provided — provided the gap is kept in mind, filled, and given proper governance, after which ops-warden delegates to the improved component.
The directive is already half-lived and nowhere written. Survey of
registry/routing/catalog.yaml on 2026-08-11 (24 entries):
| Execution mode | Count | Meaning |
|---|---|---|
warden_executes: true |
1 | ops-warden's own lane (ssh-cert-host-access) |
exec_owner: set |
2 | Delegated — route-primary, proxy-fallback |
exec_capable proxy, no exec_owner |
11 | ops-warden is the de facto front door |
| route-only | 10 | Pointer, nothing to delegate |
The delegation primitive already exists and works: exec_owner / exec_command /
pointer_command (whynot-design-npm-publish → secrets-engine, WP-0019;
ops-warden-warden-sign-token → railiance-platform credential broker,
RAILIANCE-WP-0005 T08). It is used by 2 of 24 lanes.
Nothing distinguishes the other eleven — "ops-warden proxies because that is the right end state" reads identically to "ops-warden proxies because no owner front door was ever built." Supporting evidence of the doctrine gap:
wiki/AccessRouting.mddoes not mention secrets-engine at all and has no section on interim positions.wiki/playbooks/catalog-lane-promotion.mdgates draft→active on the lane working, never on whether ops-warden should be the one running it.
Goal
Make every ops-warden execution position explicitly interim or explicitly permanent, with the intended owner and blocking condition recorded in the machine-readable layer — so gap-covering is a tracked, retirable state rather than silent ownership drift.
Success is not removing proxies. Success is that no proxy exists without an answer to "who should own this front door, and what is missing?"
Non-goals
- Removing or degrading any working lane. Proxies keep working until the owner's front door exists and is proven.
- Building the missing front doors. That work belongs to secrets-engine, tenant-engine, user-engine, and railiance-platform — this workplan produces the register they need, not their implementations.
- A second catalog or a parallel schema.
delegation:extends the existing entry shape;warden route gapscomposes the existing loader.
Design constraints
- Interim is the default. A lane without a
delegation:block is treated asinterimwith an unknown owner, not as settled. Absence must read as a question. - Founder classifies, agent drafts. Which of the eleven are legitimately
permanent is an architecture judgement (
key-cape-oidc-loginplausibly is; the tenant/workload secret lanes plausibly are not). T02 lands a drafted classification for review; the founder's answer is authoritative. - No restating owner procedure. The register names the intended owner and the blocker; it does not describe how that owner will implement their front door. Same pointer-layer discipline as the rest of the catalog.
Tasks
T01 — Interim custodianship doctrine
id: WARDEN-WP-0030-T01
status: done
priority: high
state_hub_task_id: "3d76f6c2-5007-4ad5-8d6f-360f9303c929"
Add a doctrine section to wiki/AccessRouting.md stating the boundary: the only
lane ops-warden executes with its own authority is SSH issuance; every other
execution position is interim, held because the owning component does not yet cover
the need, and retired to that owner once it does. Name secrets-engine,
tenant-engine, user-engine, railiance-platform and flex-auth as the delegation
targets. Cross-link INTENT.md §9.
T02 — delegation: metadata + backfill
id: WARDEN-WP-0030-T02
status: done
priority: high
state_hub_task_id: "8013020b-d0a5-4e89-8e0b-bc418a761c84"
Extend the catalog entry schema with:
delegation:
mode: native | interim | permanent # native = owner already fronts it
intended_owner: <repo> # required unless mode: permanent
blocked_on: <what is missing> # required when mode: interim
reviewed: "YYYY-MM-DD"
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 are classified per the founder review below — five
interim now, six held pending secrets-engine's answer.
Landed 2026-08-15. Catalog is now 27 entries. All 27 carry delegation:.
permanent(1):ssh-cert-host-accessnative(10): bothexec_ownerlanes plus the route-only pointersinterim(16): the five founder-classified now; the six held pending secrets-engine (still unanswered as of 2026-08-15, msg7d55d332) recorded asinterim/intended_owner: secrets-engine/blocked_onthe generic-vs-per-lane question — notpermanent; plus five new-since-survey lanes drafted the same way (email-connect-transactionalsame held question; two AppRoles;coulomb-social-runtime-env; draftscaleway-bootstrap)
The six are not guessed permanent. Interim is the default until secrets-engine
answers. Reclassify to permanent only if they confirm exec --catalog stays
per-lane.
T03 — warden route gaps + conformance test
id: WARDEN-WP-0030-T03
status: done
priority: medium
state_hub_task_id: "e7755708-e1bf-4d42-999c-4a60330cf154"
warden route gaps [--json] lists interim lanes with intended owner, blocker, and
age since review — the queryable register. Add a routing test asserting every
exec_capable non-warden_executes entry declares delegation, so a new proxy
cannot be added without answering the ownership question. Surface stale interim
entries in the existing drift/stale review cadence.
T04 — Promotion gate
id: WARDEN-WP-0030-T04
status: done
priority: medium
state_hub_task_id: "ddc0268b-1279-4875-b223-0627c97d657a"
Update wiki/playbooks/catalog-lane-promotion.md: draft→active requires a
delegation block. If mode: interim, the promotion note must state the intended
owner and the retirement condition. Add the matching question to the lane-review
checklist.
T05 — Publish the register to the owners
id: WARDEN-WP-0030-T05
status: done
priority: medium
state_hub_task_id: "d8796e25-e896-463d-9476-f002e38b6897"
Once T02 is reviewed, send the interim register to secrets-engine, tenant-engine, user-engine, railiance-platform and net-kingdom as a coordination message: here is what ops-warden currently fronts on your behalf, here is what would let us step back. This is the artefact that converts a private ops-warden position into a fleet-visible capability gap.
Landed 2026-08-15. Register sent (no secret values):
| To | Message |
|---|---|
| secrets-engine | 9c1d753f — 1 native + 7 interim pending generic-exec answer |
| tenant-engine | 17c851b1 — 2 Binky tenant lanes |
| user-engine | 38aeccd5 — confirm USER_ENGINE_PROXY_SECRET ownership |
| railiance-platform | e75793e3 — 1 native + 4 interim |
| net-kingdom | 3fea09df — object-storage-sts remains native/draft |
| key-cape | 28ded56c — rapp-qonto-keycape-client (founder-classified interim) |
Acceptance
wiki/AccessRouting.mdstates the interim-custodianship boundary and names the delegation targets- All catalog entries carry
delegation;warden route gapsreturns the interim set with owner + blocker (27 entries; 15 active interim) - Routing test fails when a proxy lane omits
delegation - Promotion playbook gates draft→active on the ownership question
- Founder has reviewed the interim/permanent classification of the eleven (2026-08-11); the six held lanes stay interim pending secrets-engine, not marked permanent
- Register delivered to the named owner repos (T05)
Classification of the eleven (founder review, 2026-08-11)
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
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
is worth confirming.
See also
- INTENT.md §9 (cover gaps, never silently own them)
- WARDEN-WP-0019 (route to secrets-engine — the pattern this generalizes)
- WARDEN-WP-0028 (tenant secret custody pattern; front door still ops-warden's proxy)
history/2026-08-11-delegation-surface-assessment.mdregistry/routing/catalog.yaml,wiki/playbooks/catalog-lane-promotion.md