--- id: WARDEN-WP-0010 type: workplan title: "Access Routing — Charter and Pointer Catalog" domain: custodian repo: ops-warden status: ready owner: codex topic_slug: custodian planning_priority: high planning_order: 10 created: "2026-06-18" updated: "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 ```task 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 ```task 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 ```task 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 ```task 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 ```task 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)