ops-warden/workplans/WARDEN-WP-0010-access-routing-charter.md

id, type, title, domain, repo, status, owner, topic_slug, planning_priority, planning_order, created, updated

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	planning_order	created	updated
WARDEN-WP-0010	workplan	Access Routing — Charter and Pointer Catalog	custodian	ops-warden	ready	codex	custodian	high	10	2026-06-18	2026-06-18

WARDEN-WP-0010 — Access Routing — Charter and Pointer Catalog

Scope: Sharpen the existing steward framing so it cannot be misread as a desk API that wraps every subsystem. ops-warden issues SSH certificates and points workers to the owning subsystem for everything else. This workplan updates INTENT/SCOPE wording and adds a machine-readable routing catalog that is a pointer layer, not a second copy of NetKingdom canon.

Not a new security lane. This is wording + a thin lookup surface. SSH issuance remains the only thing ops-warden executes. Maturity moves Availability A3 → A4 (structured lookup for agents); Completeness and Reliability for SSH are unchanged.

Out of scope: Secret-vending, OIDC, policy PDP, tunnel, or host-hardening code in this repo; flex-auth policy packages (WARDEN-WP-0009); any universal broker.

Depends on: WARDEN-WP-0006 stewardship canon (routing wiki, security map) — shipped.

Feeds: WARDEN-WP-0011 (routing CLI over the catalog).

---

Principles (target)

1. Point, don't proxy — Name the owner and the doc; do not wrap a foreign API unless the answer is an SSH certificate.
2. Direct interaction — Workers (humans, agents, CI, operators) call OpenBao, key-cape, flex-auth, ops-bridge, and railiance repos themselves.
3. One source of truth — Routing procedure for non-SSH needs lives in the wiki (aligned to net-kingdom canon) and upstream canon, not restated in the catalog. The catalog carries identifiers and pointers only. ops-warden authors procedure for exactly one lane: SSH certificate issuance, which it owns.
4. Same truth, two shapes — Humans read the wiki; agents read the catalog. The catalog references wiki sections by anchor so they cannot drift apart.

---

No-double-source rule (binding on T3)

The catalog must not contain step-by-step procedure for any subsystem ops-warden does not own. For non-SSH scenarios an entry carries:

• owner_repo, subsystem — who to talk to
• wiki_ref — anchor into an in-repo wiki section (the authoritative restatement)
• canon_ref — upstream net-kingdom doc the wiki section tracks
• need_keywords, title, id — lookup metadata
• warden_executes: false

Only warden_executes: true (SSH) entries may carry an authored steps block and the cert_command pattern — because that is the lane ops-warden owns. A CI test (WP-0011 T5) enforces this structurally: non-SSH entries with a steps block fail.

---

Tasks

T1 — INTENT and SCOPE wording

id: WARDEN-WP-0010-T01
status: todo
priority: high

• INTENT.md — keep "operational access steward"; replace the "operational access desk" phrasing with plain "issues SSH certs and routes everything else to its owner." Drop any metaphor that implies a wrapping service.
• SCOPE.md — state the A3 → A4 move plainly: "structured routing lookup for agents; execution unchanged." Add the coach-free "issue vs route" table.
• Non-goals: add "duplicating or restating another subsystem's procedure."
• Cross-link this workplan from the assessment note.

T2 — Routing-role wiki page

id: WARDEN-WP-0010-T02
status: todo
priority: high

• Create wiki/AccessRouting.md — what ops-warden answers (where + who owns it), what it executes (SSH only), anti-patterns (no warden secret, warden login, warden policy), and audience notes.
• Include the issue-vs-route matrix (subsystem × ops-warden role × who acts).
• Link from README, CredentialRouting.md, NetKingdomSecurityMap.md.

T3 — Pointer catalog schema + seed

id: WARDEN-WP-0010-T03
status: todo
priority: high

• Define registry/routing/catalog.yaml per the No-double-source rule above: id, title, need_keywords, owner_repo, subsystem, warden_executes, wiki_ref, canon_ref, reviewed (date), status (active|draft); plus steps + cert_command only when warden_executes: true.
• Seed from existing WP-0006 scenarios: SSH cert (executes), OpenBao API key, flex-auth policy, key-cape OIDC, ops-bridge tunnel, railiance-infra principals.
• Add issue-core-ingestion-api-key as status: draft (owner path TBD by railiance-platform) — draft entries are not surfaced by default lookup.

T4 — Routing index in CredentialRouting.md

id: WARDEN-WP-0010-T04
status: todo
priority: medium

• Add a playbook index table to wiki/CredentialRouting.md keyed to catalog id.
• Add "what ops-warden answers vs what the worker does next on the owner system" examples — without restating the owner's procedure.
• Refresh the duplicate-interface anti-examples section.

T5 — Registry and repo-boundary alignment

id: WARDEN-WP-0010-T05
status: todo
priority: medium

• Update registry/capabilities/capability.security.ssh-certificate-issuance.md — note routing lookup in discovery; target availability notes the routing CLI.
• Update .claude/rules/repo-boundary.md and AGENTS.md one-liner (no new metaphor — "issues SSH certs; routes other credential needs to their owner").
• Extend the existing capability entry rather than minting a second capability.

---

Acceptance

• A reader of INTENT + wiki/AccessRouting.md understands ops-warden issues SSH certs and routes everything else, with no implication it proxies any API.
• registry/routing/catalog.yaml exists with ≥6 active scenarios; every non-SSH entry has wiki_ref + canon_ref and no authored steps.
• No new secret-storage or foreign-API code.

---

See also

• INTENT.md · SCOPE.md
• history/2026-06-18-access-routing-intent-shift-assessment.md — decision record
• WARDEN-WP-0011 — routing CLI
• WARDEN-WP-0012 — scenario playbook expansion (backlog)