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

---
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)