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

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	proposed	claude	custodian	high	30	2026-08-11	2026-08-11	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.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
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: todo
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.

T03 — warden route gaps + conformance test

id: WARDEN-WP-0030-T03
status: todo
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: todo
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: todo
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.

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

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