coulomb/ops-mason
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Tighten the ops-warden boundary after reviewing its actual repo

Browse source 
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>
This commit is contained in:
tegwick 2026-07-27 00:44:37 +02:00
parent c5e935f949
commit ed518fb876
3 changed files with 81 additions and 34 deletions
Download patch file Download diff file Expand all files Collapse all files

34
workplans/MASON-WP-0001-foundation.md
View file

@ -72,14 +72,18 @@ state_hub_task_id: "e37debfd-8a00-4780-b036-9376c6a10557"
Phase 4: given an **approved** construction plan (explicit approval
marker set after the executive summary was reviewed), execute it against
OpenBao — policy write, AppRole creation, KV secret path creation,
role_id/secret_id delivery to the consuming host, and a matching
ops-warden catalog entry in the same action (`INTENT.md` principle 5 —
nothing built stays invisible to ops-warden). Must refuse to run against
an unapproved or missing-approval-marker plan — this is the one place a
bug is a real security incident, not a bad UX. Start narrow: implement
only the operations the first real plan (T05) needs, not a general
OpenBao automation framework.
OpenBao — policy write, AppRole creation, KV secret path creation
(**empty path/structure only — never a secret value**, see `INTENT.md`),
role_id/secret_id delivery to the consuming host, and a proposed
pointer-only ops-warden catalog entry (`warden_executes: false`, no
authored `steps`, `status: draft` — a normal commit/PR to the
`ops-warden` repo, not a live API call). Ends by naming the exact
`paste_once_provision` step the founder still needs to do (which path,
which field) — it does not attempt to fill the value itself. Must refuse
to run against an unapproved or missing-approval-marker plan — this is
the one place a bug is a real security incident, not a bad UX. Start
narrow: implement only the operations the first real plan (T05) needs,
not a general OpenBao automation framework.
```task
id: MASON-WP-0001-T04
@ -92,11 +96,15 @@ state_hub_task_id: "e949f4b7-5ef4-4e42-8a07-61b6c8040298"
Run the whole pipeline for real: construction plan for
Option B from `glas-harness/workplans/GLAS-WP-0002-T02` (dedicated
`rein-openweights` AppRole + KV secret at `reins/rein-openweights/openrouter`,
mirroring `agent-harness-binky-mail`'s shape) → review/optimize → executive
summary → founder approval → build. Once built, notify
`glas-harness`/`rein-openweights` so `GLAS-WP-0002-T02`'s live OpenBao
verification can proceed.
`rein-openweights` AppRole + KV secret path at
`reins/rein-openweights/openrouter`, mirroring `agent-harness-binky-mail`'s
shape) → review/optimize → executive summary → founder approval → build
(structure only). Build ends with the founder pasting the real
OpenRouter key through ops-warden's `paste_once_provision` desk into the
newly created path/field — that one paste is the only place the live
value exists outside OpenBao. Once done, notify `glas-harness`/
`rein-openweights` so `GLAS-WP-0002-T02`'s live OpenBao verification can
proceed.
```task
id: MASON-WP-0001-T05