ops-mason/workplans/MASON-WP-0001-foundation.md at d3dbad34e1a118bdeafd00d1fbbab40265412d77

tegwick ed518fb876 Tighten the ops-warden boundary after reviewing its actual repo

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>

2026-07-27 00:44:37 +02:00

4.6 KiB

Raw Blame History

id	title	status	state_hub_workstream_id
MASON-WP-0001	Foundation: the four-phase construction process, exercised on a real demand	proposed	fa60e81b-19f6-4ad5-a584-f049cdec1bdb

First workplan for ops-mason. Stands up the four phases described in INTENT.md — construction plan, review/optimize, executive summary, build — and exercises the whole pipeline on one real, already-waiting piece of demand: the rein-openweights OpenBao AppRole (glas-harness/workplans/GLAS-WP-0002-T02, currently blocked on exactly the mechanic this repo exists to formalize). That task is not busywork invented for this workplan — it's real backlog this pipeline unblocks the moment phase 4 lands.

Task: Construction-plan format

Design the artifact phase 1 produces: demand description (consumer, credential type, scope requested), an existing-structure survey (what bao policy list/bao auth list/bao secrets list/ops-warden's registry/routing/catalog.yaml already cover, and whether any of it already satisfies the demand), and the proposed changes (create/modify/ tear-down, each with a stated reuse-vs-new rationale). Document in docs/construction-plan-format.md. Plain, versioned markdown/YAML — not a database — so a plan can be reviewed in a diff and stored next to the workplan that requested it.

id: MASON-WP-0001-T01
status: todo
priority: high
state_hub_task_id: "6b25e7ca-52a0-41c2-b5a0-b5e46c824264"

Task: Review/optimize pass

A self-check phase 2 runs over a draft plan before it's shown to anyone: flag likely-redundant new policies/roles against what already exists, naming/TTL/scoping convention drift against established lanes (e.g. the agent-harness-binky-mail shape: token_ttl=15m, token_max_ttl=30m, bounded token_num_uses), and note any compaction opportunity (two existing lanes that could merge). This can start as a checklist a human/agent runs manually against a draft plan — doesn't need to be automated tooling on day one.

id: MASON-WP-0001-T02
status: todo
priority: high
state_hub_task_id: "58a446fb-78d0-42b4-b10a-1119266b1016"

Task: Executive-summary format

Design the phase 3 artifact: a short, decidable rendering of a reviewed plan — who/what gets access to what, for how long, blast radius if the credential leaks, and what it costs to reverse. This is the only mandatory human checkpoint (INTENT.md design principle 3/4) — it must be readable without knowing bao syntax. Document in docs/executive-summary-format.md, with the rein-openweights AppRole plan (task T05) as the worked example.

id: MASON-WP-0001-T03
status: todo
priority: medium
state_hub_task_id: "e37debfd-8a00-4780-b036-9376c6a10557"

Task: Build executor

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 (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.

id: MASON-WP-0001-T04
status: todo
priority: high
state_hub_task_id: "e949f4b7-5ef4-4e42-8a07-61b6c8040298"

Task: First real build — rein-openweights OpenBao AppRole

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 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.

id: MASON-WP-0001-T05
status: todo
priority: high
state_hub_task_id: "01782608-aa5a-4f9b-a1fb-9a64f6d9c299"

4.6 KiB Raw Blame History