Minted on a dedicated identity rather than a site admin. A PAT on
tegwick would have read every repository on the instance — wider than
the approved organisation-wide breadth and wider than the plan's stated
blast radius. Built as user state-hub-svc in team coulomb/state-hub-read
(read, all repositories, repo.code unit only), following the existing
issue-core-svc precedent. The ceiling is enforced by org membership, not
by a scope string, and clones are attributable to a named identity.
Delivered by warden desk --act paste_once_provision; ops-mason neither
minted nor pasted the value.
Verified: rapp-openbao, rapp-core-hub, rapp-issue-core and
rapp-policy-nexus all read — four of the nine that failed
STATE-WP-0083-T04. Push 403, admin API 403, /api/v1/user 403 (the scope
carries no read:user). Clone test used GIT_ASKPASS, so no credential
entered argv or a clone URL.
Records a deviation rather than glossing it: SCOPE.md puts secret values
out of scope, and that held for minting and delivery but not for
verification — the value was read back to fingerprint it and to run the
clone test, under the build-stage disclosure posture agreed 2026-08-27.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3377672@bnt-lap001
Assistant-Session: 15463ccf-238f-4e13-b163-93aa25c6d166
Policy workload-kv-read-state-hub-forge-derivation and Kubernetes auth
role state-hub-forge-derivation, verified both directions through a
2-minute test token that was revoked after use: read on its own path;
deny on forgejo-admin, on the shared llm-connect provider secrets, and
on the parent metadata path.
Kubernetes auth replaces the approved AppRole. The plan's §2 survey was
written from disk with no OpenBao session and could not see that
kubernetes/ auth is enabled on this cluster; the plan's own phase-4
instruction to re-verify against live state is what surfaced it. Ruled
by the founder at phase 4. No static credential is created, so nothing
has to be delivered into the cluster or rotated.
The live survey also re-checked reuse: workload-kv-read-agent-harness-
forgejo grants one repository deploy key, not organisation-wide read, so
§2's rejection of reuse stands.
ops-mason handled no secret value. The KV path does not exist until
paste_once_provision writes the token.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3377672@bnt-lap001
Assistant-Session: 15463ccf-238f-4e13-b163-93aa25c6d166
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3377672@bnt-lap001
Assistant-Session: 15463ccf-238f-4e13-b163-93aa25c6d166
Plan approved 2026-08-26, breadth organisation-wide repository read. The
§4 contingency was satisfied first: STATE-WP-0084-T01 landed the same
day, so a missing grant now surfaces as a named unreadable condition
rather than as silence — which is what the breadth argument rested on.
T01 done. T03 drafted in ops-warden on a branch (entry + playbook +
regenerated high-risk artifact). T02 needs an operator: no valid OpenBao
session here, and the token is the forge owner's to mint.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3377672@bnt-lap001
Assistant-Session: 15463ccf-238f-4e13-b163-93aa25c6d166
Trim MASON-WP-0003 to T01-T03 — decide, build the AppRole/policy/KV path
structure, register the catalog entry — and route it through the
four-phase pipeline via plans/state-hub-forge-derivation-read.md, which
supplies the phase-3 executive summary the workplan was bypassing.
T02 no longer mints or holds the token value: SCOPE.md puts secret
values out of scope, so the forge owner mints and ops-warden's
paste_once_provision desk delivers.
Deployment plumbing, derive_from_forge(), and the fleet re-run move to
state-hub/STATE-WP-0084.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3377672@bnt-lap001
Assistant-Session: 15463ccf-238f-4e13-b163-93aa25c6d166
Nine private repositories are invisible to the hub's derivation: the pod clones
Forgejo anonymously, so ADR-012's premise that the forge is the projection
source holds only for repositories central can read.
warden route find returns no lane for this need, and the nearest entry is an
operator admin PAT owned by railiance-platform — more authority than derivation
requires. ops-mason owns AppRoles, policies and KV paths, which is what is
missing.
Six tasks: settle scope and breadth, create the AppRole and KV path, register
the routing entry, deliver the credential to the pod, teach the derivation to
use it, and confirm the nine. Token creation stays operator-executed; this
workplan describes the lane rather than performing it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
These files carried no type field at all. Selection is by 'type: workplan', so
they were invisible to every projection while the hub held a record for each —
and a forge-derived reset read those correct records as no longer deriving and
queued them for retirement.
Only the type line is added.
Refs STATE-WP-0083-T05
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
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>
status: approved, approved_by: Bernd Worsch, approved_at: 2026-07-27.
Verified against the real executor code: ConstructionPlan.load(...)
.is_approved() returns True for this file. MASON-WP-0001-T05 moves from
todo to wait -- the approval gate is cleared, phase 4 execution is
blocked only on a real OpenBao session existing somewhere (bao token
lookup still 403 from this workstation).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
docs/review-optimize-checklist.md: six checks (naming, TTL/scoping,
redundancy, compaction, ease of use, posture), applied for real to the
rein-openweights plan's section 4 -- including a genuinely useful
finding (credentials.py already expects this exact path/delivery shape,
zero code changes needed to consume it).
docs/executive-summary-format.md: six fixed fields, no bao syntax, no
restating earlier sections, explicit approve/reject/revise decision.
Rendered for real into the plan's section 5 -- ready for an actual
decision.
src/ops_mason/{plan,executor,audit}.py: the phase-4 build executor for
credential_type openbao-approle-kv. Refuses to run against anything but
an approved plan -- verified the refusal never even calls subprocess.run.
role_id/secret_id (the AppRole's own access credential, not the
downstream secret) land as 0600 files, never logged; the HCL policy
goes over stdin, never argv; the audit trail is metadata-only. 12 tests,
all mocked at the bao boundary (no live OpenBao access from this
session).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
docs/construction-plan-format.md: one file per plan (plans/<id>.md),
frontmatter status tracker (draft -> reviewed -> approved -> built ->
catalogued, the phase-4 hard gate), six body sections threading all
four phases through one document.
Proven against real demand: plans/rein-openweights-openrouter-approle.md,
phases 1-2 filled in. Found and reasoned through a real existing-structure
question along the way -- the openrouter-llm-connect catalog lane could
technically be reused, but its auth_method is interactive-caller-shaped
and its policy is shared/high-risk; recommends a dedicated, narrowly
scoped AppRole instead, same reasoning agent-harness-binky-mail used for
its own dedicated lane.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
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>
