generated from coulomb/repo-seed
feat(WARDEN-WP-0017): make the access front door discoverable (not SSH-only)
WP-0014 made ops-warden the operator access front door (warden access --fetch/--exec proxies an exec_capable secret as the caller), but every discovery surface still told the pre-WP-0014 "SSH certs only, pointer not key" story — so agents like whynot-design never found the proxy and concluded they had to message ops-warden for a token value. Messaging/discoverability only; the conduit security model is unchanged (no custody, no broker). T1 — CLI: `warden route` table warden column is now three-valued (issue/assist/route); route + access JSON gain warden_role + exec_capable and a proxy-aware next_action; `warden access` closing line leads with "ops-warden can fetch this for you as the caller" for exec_capable lanes (route-only lanes keep "owner vends"). T2 — .claude/rules/credential-routing.md reframed (lead + routing table role column); SCOPE one-liner + a second capability block for the access front door. T3 — registered the State Hub capability "Operator access front door (caller-identity fetch proxy)" (the hub had no ops-warden security capability at all); messaged whynot-design the corrected `warden access "npm auth token" --fetch/--exec` path. 210 tests pass, lint clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
116
workplans/WARDEN-WP-0017-access-front-door-discoverability.md
Normal file
116
workplans/WARDEN-WP-0017-access-front-door-discoverability.md
Normal file
@@ -0,0 +1,116 @@
|
||||
---
|
||||
id: WARDEN-WP-0017
|
||||
type: workplan
|
||||
title: "Access front-door discoverability — stop reading as SSH-only"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: finished
|
||||
owner: claude
|
||||
topic_slug: custodian
|
||||
planning_priority: high
|
||||
planning_order: 17
|
||||
created: "2026-06-27"
|
||||
updated: "2026-06-27"
|
||||
---
|
||||
|
||||
# WARDEN-WP-0017 — Access front-door discoverability
|
||||
|
||||
**Problem:** WP-0014 made ops-warden the operator **access front door** — for
|
||||
`exec_capable` lanes (OpenBao reads, key-cape login) `warden access <need> --fetch/--exec`
|
||||
proxies the fetch **as the caller** and streams the value to them (ops-warden holds
|
||||
nothing). But every *discovery* surface still tells the pre-WP-0014 story, so agents
|
||||
(e.g. whynot-design needing `NPM_AUTH_TOKEN`) conclude "ops-warden only issues SSH certs
|
||||
and replies with a pointer, not a token" and never find the proxy.
|
||||
|
||||
**Fix:** propagate the WP-0014 conduit charter to the surfaces agents actually read. This
|
||||
is a *messaging/discoverability* change — **no** change to the security model: the conduit
|
||||
stays a conduit (no custody, no standing broker; the responsibility-map boundary holds).
|
||||
|
||||
**Out of scope:** ops-warden holding/brokering token values (that would override the
|
||||
WP-0014 charter); shipping the concrete OpenBao npm KV path (railiance-platform infra —
|
||||
tracked separately); any new fetch capability (the proxy already exists).
|
||||
|
||||
**Depends on:** WP-0014 (the proxy lane being described).
|
||||
|
||||
---
|
||||
|
||||
## Surfaces that mislead today
|
||||
|
||||
| Surface | Says now | Should say |
|
||||
| --- | --- | --- |
|
||||
| `warden route` table `warden` column | binary `issue` / `route` | `issue` / **`assist`** (exec_capable) / `route` |
|
||||
| `warden route` `--json` | no proxyability field | add `warden_role` + `exec_capable` |
|
||||
| `warden access` closing line | "warden advises, the owner vends" | for exec_capable: "ops-warden can fetch this for you as the caller…" |
|
||||
| `.claude/rules/credential-routing.md` | "issues SSH certs **only**… reply is a pointer, not a key" | issues SSH certs **and** is the access front door; exec_capable lanes proxy as you |
|
||||
| Federated capability registry | only "SSH certificate issuance" | also "Operator access front door / caller-identity fetch proxy" |
|
||||
| SCOPE one-liner + capability block | SSH + routing + posture | add the access-assist/proxy front door |
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
### T1 — CLI discoverability: route role + access framing
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0017-T01
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
- [x] `warden route` table: three-valued `warden` column — `issue` / `assist`
|
||||
(exec_capable) / `route`. `_entry_summary` JSON gains `warden_role` + `exec_capable`;
|
||||
`route show` JSON `next_action` surfaces the proxy for exec_capable lanes.
|
||||
- [x] `warden access` closing line: for `exec_capable` lanes leads with "ops-warden can
|
||||
fetch this for you as the caller (`--fetch`/`--exec`); runs the owner's tool with
|
||||
your identity, value never held/cached/logged." Non-exec lanes keep "advises, owner
|
||||
vends." `_access_json` `next_action` mirrors it.
|
||||
- [x] Tests in `tests/test_routing.py` (warden_role issue/assist) and `tests/test_access.py`
|
||||
(front-door framing for exec lane, owner-vends for route-only lane). 210 pass.
|
||||
|
||||
### T2 — Agent rule + SCOPE reframe
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0017-T02
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
- [x] `.claude/rules/credential-routing.md`: reframed the lead ("issues SSH certs **and**
|
||||
is the operator access front door…") and the quick routing table (`ops-warden role`
|
||||
column: Issue / Assist / Route). Kept the true anti-pattern: don't POST a State Hub
|
||||
message for a secret *value* — it comes from the CLI front door run as you.
|
||||
- [x] SCOPE one-liner reframed to "steward **and front door**"; added a second `capability`
|
||||
block "Operator access front door (caller-identity fetch proxy)".
|
||||
|
||||
### T3 — Federated capability registration
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0017-T03
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
- [x] Registered the State Hub capability "Operator access front door (caller-identity
|
||||
fetch proxy)" (id `708e46f6`, repo ops-warden) — the hub had **no** ops-warden
|
||||
security capability before, so the front door was undiscoverable cross-domain.
|
||||
- [x] Sent whynot-design (msg `83a3bb2e`) the corrected path: `warden access "npm auth
|
||||
token" --fetch/--exec`, the CLI refresh, the OpenBao-auth prereq, and the
|
||||
railiance-platform path caveat.
|
||||
|
||||
---
|
||||
|
||||
## Acceptance
|
||||
|
||||
- An agent doing the first-line `warden route find` / `--json` lookup can see ops-warden
|
||||
*assists* (proxies) the OpenBao lane, not merely points.
|
||||
- The credential-routing rule and federated capability registry describe the access
|
||||
front door; none of them say "SSH certificates only".
|
||||
- The conduit boundary is unchanged and explicit: ops-warden fetches *as the caller* and
|
||||
holds nothing — no custody, no broker.
|
||||
|
||||
---
|
||||
|
||||
## See also
|
||||
|
||||
- `WARDEN-WP-0014` (the proxy lane), `wiki/OperatorAccessAssist.md`
|
||||
- `.claude/rules/credential-routing.md`, `registry/routing/catalog.yaml`
|
||||
Reference in New Issue
Block a user