ops-warden/workplans/WARDEN-WP-0030-delegation-register.md

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	planning_order	created	updated
WARDEN-WP-0030	workplan	Delegation register — make gap-covering interim, visible, and retirable	infotech	ops-warden	proposed	claude	custodian	high	30	2026-08-11	2026-08-11

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.md does not mention secrets-engine at all and has no section on interim positions.
• wiki/playbooks/catalog-lane-promotion.md gates 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 gaps composes the existing loader.

Design constraints

• Interim is the default. A lane without a delegation: block is treated as interim with 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-login plausibly 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: todo
priority: high

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: todo
priority: high

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 get a drafted classification plus intended owner, flagged in the workplan for founder review rather than asserted as settled.

T03 — warden route gaps + conformance test

id: WARDEN-WP-0030-T03
status: todo
priority: medium

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: todo
priority: medium

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: todo
priority: medium

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.

Acceptance

• wiki/AccessRouting.md states the interim-custodianship boundary and names the delegation targets
• All 24 catalog entries carry delegation; warden route gaps returns the interim set with owner + blocker
• 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
• Register delivered to the named owner repos

Open question for the founder

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.

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 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.md
• registry/routing/catalog.yaml, wiki/playbooks/catalog-lane-promotion.md