Charter ops-mason: builder of NetKingdom security infrastructure

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>

workplans/MASON-WP-0001-foundation.md

@@ -0,0 +1,100 @@
+---
+id: MASON-WP-0001
+title: "Foundation: the four-phase construction process, exercised on a real demand"
+status: proposed
+---
+
+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
+```
+
+## 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
+```
+
+## 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
+```
+
+## 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,
+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.
+
+```task
+id: MASON-WP-0001-T04
+status: todo
+priority: high
+```
+
+## 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 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.
+
+```task
+id: MASON-WP-0001-T05
+status: todo
+priority: high
+```