Found two things in ops-warden's own code/docs that sharpen the
boundary beyond what INTENT.md originally said:
1. registry/routing/catalog.yaml enforces a real "no-double-source
rule": non-SSH entries are pointer-only (id/title/need_keywords/
owner_repo/subsystem/wiki_ref/canon_ref/reviewed/status), never an
authored steps/cert_command block -- that's reserved for
warden_executes: true (ops-warden's own SSH lane). ops-mason's
catalog contributions must follow the same rule: warden_executes:
false always, status: draft until verified, and it's a normal git
contribution to ops-warden's repo, not a live registration API.
2. ops-warden already ships a founder-facing "paste-once provision"
desk (src/warden/desk.py's paste_once_provision act) that writes a
secret VALUE into an EXISTING KV path via a localhost-only web form,
never through a terminal/chat/audit log. It does not create
AppRoles, policies, or paths -- that gap is exactly what ops-mason
fills. Clean split: ops-mason builds structure only and never
touches a secret value, even transiently; the founder delivers the
actual credential through ops-warden's existing desk once the
structure exists.
Updated INTENT.md/SCOPE.md/MASON-WP-0001 accordingly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
