docs/review-optimize-checklist.md: six checks (naming, TTL/scoping,
redundancy, compaction, ease of use, posture), applied for real to the
rein-openweights plan's section 4 -- including a genuinely useful
finding (credentials.py already expects this exact path/delivery shape,
zero code changes needed to consume it).
docs/executive-summary-format.md: six fixed fields, no bao syntax, no
restating earlier sections, explicit approve/reject/revise decision.
Rendered for real into the plan's section 5 -- ready for an actual
decision.
src/ops_mason/{plan,executor,audit}.py: the phase-4 build executor for
credential_type openbao-approle-kv. Refuses to run against anything but
an approved plan -- verified the refusal never even calls subprocess.run.
role_id/secret_id (the AppRole's own access credential, not the
downstream secret) land as 0600 files, never logged; the HCL policy
goes over stdin, never argv; the audit trail is metadata-only. 12 tests,
all mocked at the bao boundary (no live OpenBao access from this
session).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
docs/construction-plan-format.md: one file per plan (plans/<id>.md),
frontmatter status tracker (draft -> reviewed -> approved -> built ->
catalogued, the phase-4 hard gate), six body sections threading all
four phases through one document.
Proven against real demand: plans/rein-openweights-openrouter-approle.md,
phases 1-2 filled in. Found and reasoned through a real existing-structure
question along the way -- the openrouter-llm-connect catalog lane could
technically be reused, but its auth_method is interactive-caller-shaped
and its policy is shared/high-risk; recommends a dedicated, narrowly
scoped AppRole instead, same reasoning agent-harness-binky-mail used for
its own dedicated lane.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
INTENT.md establishes the four-phase process (construction plan ->
review/optimize -> executive summary -> build), grounded in ops-warden's
own charter: ops-warden explicitly disclaims being a builder/provisioner
("owns no secret store and vends nothing", routes provisioning
elsewhere) and states its own design principle that "the founder is
escalated to, never tasked with mechanics" -- ops-mason's executive
summary gate is that principle applied to the provisioning side, turning
today's ad hoc founder Red-lane bao commands into a reviewed, repeatable
process.
MASON-WP-0001 stands up the four phases and exercises the whole
pipeline on real, already-waiting demand: the rein-openweights OpenBao
AppRole that glas-harness/GLAS-WP-0002-T02 is blocked on.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
