ops-warden/workplans/WARDEN-WP-0019-route-to-secrets-engine.md

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

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	planning_order	created	updated	state_hub_workstream_id
WARDEN-WP-0019	workplan	Route secret-exec lanes to secrets-engine (route-primary, proxy fallback)	infotech	ops-warden	finished	claude	custodian	high	19	2026-06-29	2026-06-29	5e49abb6-497f-4640-a484-2da5f39a7c4e

WARDEN-WP-0019 — Route secret-exec lanes to secrets-engine

Trigger: secrets-engine (SECRETS-WP-0003, msg 765a03f0) shipped a native secret-exec front door — secrets-engine route <id> --json and secrets-engine exec --catalog <id> -- <cmd> with canonical decision ids — and asked ops-warden to route to it. This is the owner-native execution lane that ops-warden's warden access --exec proxy was filling as a stopgap (WP-0014). whynot-design already published @whynot/design@0.4.0 through the proxy on this same lane, so both paths resolve today.

Decision (Bernd, 2026-06-29): route-primary, proxy-fallback. For lanes secrets-engine owns, ops-warden surfaces secrets-engine exec/route as the primary path and keeps its own warden access --exec as a documented transparent fallback. ops-warden stays the discovery front door; secrets-engine is the exec owner. Boundary unchanged: ops-warden holds or stores no token on either path.

Out of scope: ops-warden invoking secrets-engine exec itself (it routes/points, the caller runs it); changing the proxy's security model; the production policy-gate flip.

---

Tasks

T1 — Catalog + CLI: surface the owner-native exec front door

id: WARDEN-WP-0019-T01
status: done
priority: high
state_hub_task_id: "ea153605-7a14-4db7-8bce-d780ea143f8a"

• RouteEntry gains exec_owner / exec_command / pointer_command (pointers only, screened by _assert_no_secret_material) and a has_native_exec property.
• whynot-design-npm-publish entry: exec_owner: secrets-engine, exec_command: secrets-engine exec --catalog whynot-design-npm-publish -- <cmd>, pointer_command: secrets-engine route whynot-design-npm-publish --json. Keep the existing fetch_command/exec_capable (the proxy fallback).
• warden access: when exec_owner is set, render the secrets-engine exec as the primary line and the warden access --exec proxy as the fallback; JSON gains exec_owner/exec_command/pointer_command. route find/show JSON too.
• Tests in tests/test_routing.py / tests/test_access.py.

T2 — Agent rule, SCOPE, playbook

id: WARDEN-WP-0019-T02
status: done
priority: medium
state_hub_task_id: "96059b8a-8938-4763-b3d0-cc5a0eb2465c"

• .claude/rules/credential-routing.md: add secrets-engine as the secret-exec owner; for OpenBao-backed secret lanes the route is "secrets-engine exec (primary), ops-warden warden access --exec (transparent fallback)".
• SCOPE: add secrets-engine to Related Repos + the routing model; note the whynot-design lane is production-exercised (real 0.4.0 publish), not just resolvable.
• wiki/playbooks/whynot-design-npm-publish.md: lead with the secrets-engine exec command; fix the fallback one-liner per whynot-design's field notes (--field NPM_AUTH_TOKEN, and --no-policy while policy.enabled=false).

---

Acceptance

• warden access whynot-design-npm-publish shows the secrets-engine exec as primary and the warden proxy as fallback; --json carries exec_owner/exec_command.
• The credential-routing rule names secrets-engine as the secret-exec owner.
• No secret material anywhere; ops-warden holds no token on either path.

See also

• secrets-engine SECRETS-WP-0003, decision e6381a56, docs/whynot-design-real-publish-closeout.md
• WARDEN-WP-0014 (proxy), WARDEN-WP-0017 (discoverability), WARDEN-WP-0018 (lane activation)