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

Real build executed for real (MASON-WP-0001-T05, MASON-WP-0001 done 5/5)

Browse source 
Ran the whole approved pipeline against real OpenBao: created the reins/
KV v2 mount (after pausing for explicit founder confirmation -- a bigger
action than the executive summary's blast-radius framing disclosed),
the read-only policy, the AppRole, delivered role_id/secret_id. Caught
and fixed a real bug in the same pass: built with token_num_uses=0
(OpenBao's default = unlimited) instead of the plan's own stated 8;
fixed live and removed the executor's silently-permissive default so it
can't recur. Catalog entry proposed and merged in ops-warden (c0a50bc).

Corrected a real misreading in this repo's own INTENT.md along the way:
pointer fields (auth_method/fetch_command/rotation.steps) are normal on
non-SSH catalog entries; only a bare top-level steps:+cert_command:
pair is SSH-only -- verified against ops-warden's real entries and its
full test suite (326 tests, green).

Plan status: built. Catalog entry status: draft until the founder's
paste-once-provision and glas-harness/GLAS-WP-0002-T02's live
verification succeed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-07-27 01:25:14 +02:00
parent ae75a6c4d9
commit 33573a35a1
5 changed files with 110 additions and 26 deletions
Download patch file Download diff file Expand all files Collapse all files

31
INTENT.md
View file

@ -106,18 +106,25 @@ build once approved.
(`ops-warden/registry/routing/catalog.yaml`) for what it builds
- Its own audit trail of what it built, when, and under which approved plan
**Catalog entries are pointer-only, same rule ops-warden enforces on every
non-SSH entry (the catalog's own "no-double-source rule",
`ops-warden/workplans/WARDEN-WP-0010-access-routing-charter.md`):**
`id`/`title`/`need_keywords`/`owner_repo`/`subsystem`/`wiki_ref`/`canon_ref`/
`reviewed`/`status`, always `warden_executes: false` (ops-mason built the
lane, it does not execute the runtime credential fetch — the consumer's own
code does, the way `rein-openweights/credentials.py` does today). **Never**
an authored `steps`/`cert_command` block — those are reserved for
`warden_executes: true` entries, i.e. ops-warden's own SSH lane. The actual
"how a consumer uses this credential" doc lives with the consumer (e.g.
`rein-openweights/INTENT.md`/`credentials.py`), referenced via `wiki_ref`,
not restated inside the catalog.
**Catalog entries are pointer-shaped, same rule ops-warden enforces on
every non-SSH entry (the catalog's own "no-double-source rule",
`ops-warden/workplans/WARDEN-WP-0010-access-routing-charter.md`) —
corrected here 2026-07-27 after checking real catalog entries, not just
the header comment:** `id`/`title`/`need_keywords`/`owner_repo`/
`subsystem`/`wiki_ref`/`canon_ref`/`reviewed`/`status`, always
`warden_executes: false` (ops-mason built the lane, it does not execute
the runtime credential fetch — the consumer's own code does, the way
`rein-openweights/credentials.py` does today). Fields like
`auth_method`/`path_template`/`fetch_command`/`rotation.steps` **are**
expected on non-SSH entries — e.g. `agent-harness-binky-mail-approle`
carries all of them despite `warden_executes: false`. What's actually
reserved for `warden_executes: true` (ops-warden's own SSH lane) is a
bare **top-level** `steps:` + `cert_command:` pair — that specific
shape, not procedural detail in general. A companion wiki playbook
(`wiki/playbooks/<id>.md`, `## Worker checklist` section) is the norm,
same as every other lane in the catalog — not a violation of
no-double-source as long as it doesn't restate a *different owner's*
procedure.
Landing a catalog entry is a normal git contribution to the `ops-warden`
repo (a commit/PR touching `registry/routing/catalog.yaml`), subject to