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>
49 lines
1.8 KiB
Markdown
49 lines
1.8 KiB
Markdown
# SCOPE
|
|
|
|
## One-liner
|
|
|
|
Builder of NetKingdom security infrastructure — creates, changes,
|
|
maintains, and tears down OpenBao AppRoles, policies, and KV secret paths
|
|
so ops-warden always has something real to route to.
|
|
|
|
## Core Idea
|
|
|
|
Four-phase process: (1) construction plan — respect/extend/compact
|
|
existing structure before proposing new; (2) review/optimize against
|
|
what already exists; (3) executive summary — the one mandatory human
|
|
decision gate, in plain terms; (4) build, only after approval.
|
|
|
|
## In Scope
|
|
|
|
- Construction plans for new/changed/retired OpenBao AppRoles, policies,
|
|
KV secret path *structure* (never values)
|
|
- Consistency review — reuse over duplication, compaction over sprawl
|
|
- The executive-summary format that makes a plan decidable at a glance
|
|
- Proposing pointer-only entries (`warden_executes: false`, no authored
|
|
`steps`) in ops-warden's routing catalog for what it builds — a normal
|
|
git contribution to that repo, not a live API
|
|
- Its own audit trail of what it built, under which approved plan
|
|
|
|
## Out of Scope
|
|
|
|
- Deciding *whether* access should exist — that's architecture/founder,
|
|
ops-mason builds what's already decided
|
|
- Runtime authorization decisions — flex-auth
|
|
- Identity/MFA — key-cape/Keycloak
|
|
- Routing consumers to lanes once built — ops-warden
|
|
- SSH certificate issuance — ops-warden
|
|
- OpenBao cluster init/unseal, platform deploy — railiance-platform
|
|
- Touching secret values at all, even transiently — delivered via
|
|
ops-warden's existing `paste_once_provision` desk instead
|
|
|
|
## Current State
|
|
|
|
Charter only (`INTENT.md`). `MASON-WP-0001` scopes the four-phase
|
|
pipeline and its first real exercise: the `rein-openweights` OpenBao
|
|
AppRole that `glas-harness/GLAS-WP-0002-T02` is blocked on. No code yet.
|
|
|
|
## Getting Oriented
|
|
|
|
- Start with: `INTENT.md`
|
|
- Agent instructions: `AGENTS.md`
|
|
- Workplans: `workplans/`
|