tegwick
ed518fb876
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>
114 lines
4.6 KiB
Markdown
114 lines
4.6 KiB
Markdown
---
|
|
id: MASON-WP-0001
|
|
title: "Foundation: the four-phase construction process, exercised on a real demand"
|
|
status: proposed
|
|
state_hub_workstream_id: "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.
|
|
|
|
```task
|
|
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.
|
|
|
|
```task
|
|
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.
|
|
|
|
```task
|
|
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.
|
|
|
|
```task
|
|
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.
|
|
|
|
```task
|
|
id: MASON-WP-0001-T05
|
|
status: todo
|
|
priority: high
|
|
state_hub_task_id: "01782608-aa5a-4f9b-a1fb-9a64f6d9c299"
|
|
```
|