The agent responsible to create, change, maintain and tear down access routes with new credentials, tokens, policies, etc inside net-kingdom. Ops-mason is responsible to build the security infrastructure as required and defined by architecture documents as a base for ops-warden..
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> |
||
|---|---|---|
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| AGENTS.md | ||
| INTENT.md | ||
| LICENSE | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
ops-mason
The builder of NetKingdom security infrastructure — creates, changes, maintains, and tears down access routes, credentials, tokens, and policies so that ops-warden always has something real to route to.
- Why and boundaries: INTENT.md
- Current work: workplans/
The four-phase process
- Construction plan — given an access demand, draft what needs building, respecting/extending/compacting existing structure first.
- Review and optimize — self-review the plan against what already exists, for consistency and ease of use.
- Executive summary — the one mandatory human decision gate: render who gets what access, for how long, and what it costs to reverse.
- Build — once approved, execute the plan.
See INTENT.md for the full responsibility boundary against ops-warden,
OpenBao, flex-auth, and key-cape.