A: coulomb as approved; four infotech hall-of-helix values move there as
part of MASON-WP-0005-T04. B1 retire duplicate activity-core/default entry,
B2 forgejo-mailer -> rapp-forgejo, B3 target-revenue deferred.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 327203@bnt-lap001
Assistant-Session: 55028ae3-4914-4bd1-8f5c-815f3527aef0
49 paths, 45 without custody fields. 38 owners proposed from catalog/CCRs,
3 genuinely unclear, and 4 undocumented fluid-telegram entries under tenant
infotech that conflict with the approved coulomb plan; WP-0005-T04 on hold
until the founder rules.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 327203@bnt-lap001
Assistant-Session: 55028ae3-4914-4bd1-8f5c-815f3527aef0
Value-free evidence under the read-only ops-mason-survey grant (revoked after
use). Adds T05 for live-token checks and the pointer route. Fixes
bao-session.sh grant misreporting an unreadable policy as absent.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 132360@bnt-lap001
Assistant-Session: 769b1afd-4330-4c86-96b2-e510e26db42b
Founder decision 2026-10-07, option (c)+(a): ops-mason surveys and verifies
only. Policy/role writes, secret-id minting and token creation go through the
founder-attended railiance-platform delegated applier. ops-mason-build retired
to policies/retired/ (never installed).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 132360@bnt-lap001
Assistant-Session: 769b1afd-4330-4c86-96b2-e510e26db42b
scripts/plan-survey.py runs under the ops-mason-build grant and prints a
pasteable section 2: relevant secrets/auth/policy/role listings with counts,
policy stanzas covering the target for name-matched policies, KV metadata
existence, matching ops-warden catalog entries, timestamp, BAO_ADDR, token
display_name and a draft yes/no/partial answer. Metadata only: an allowlist
refuses kv get, */data/* and role-id/secret-id before any process starts; a
non-grant token is refused and the token is never printed. Denied queries
degrade to 'not permitted by ops-mason-build'. Tests use a fake bao runner.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1170398@bnt-lap001
Assistant-Session: 622cd705-cb31-4322-ba08-dd42e44fa583
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>
