coulomb/ops-mason
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Enforce readiness tiers and reconcile blocked workplans

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e75a-fc5c-7913-9dba-9846210c766d
This commit is contained in:
tegwick 2026-09-28 11:40:57 +02:00
parent 370e1f84c7
commit 36445ae679
14 changed files with 652 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

91
docs/evidence/2026-09-28-loose-end-review.md Normal file
View file

@ -0,0 +1,91 @@
# Loose-end review — 2026-09-28
Reviewed every local workplan. MASON-0001 and MASON-WP-0001–0003 are
finished; no open task in those files needs implementation. The three proposed
workplans, MASON-WP-0004–0006, contain the remaining work. No new task or
workplan was opened. Existing uncommitted intake, Telegram construction-plan,
and lockfile work was left outside this change.
## MASON-WP-0006
T01 is answered by founder decision in
`the-custodian/docs/kubernetes-change-gate-decision.md`, communicated by message
`b41bd54f-a7a4-41e5-a1ee-aa9b0efa7dc5`: whitehat is explicitly non-production.
The same decision and current agent orientation establish that ArgoCD has
since been installed; the blanket absence-of-ArgoCD transition is obsolete.
T02–T05 implemented in the readiness resolver, bundle, CLI, evidence and docs.
Validation: 54 tests pass (`.venv/bin/pytest -q`), including a real temporary
Git history that promotes then reverts a binding; `git diff --check` passes.
Tests exercise approved and refused apply, explicit whitehat placement,
binding supersession, stale/missing sources, namespace mapping, historical
production approval, deprecation, the December 21 boundary, and emergency
reason/evidence. Existing manifest and approval refusals remain covered.
Secret-presence verification now requests object names, never Secret JSON.
A read-only local source check resolves the actual whitehat bundle to
non-production under APPROVED, using reef-railiance commit
`e3c5ca2b74f6ae4f3b79f918708f3b573157a0c2`, bindings SHA-256
`796007c68f0eda1d50cebddf9e11a2c123a8814ebaf67f739ed5d2af2d6fa3f1`.
No Kubernetes command or deployment was needed for this implementation.
T06 stays wait: its review is due 2026-12-21 and requires platform confirmation
of policy-nexus GitOps adoption and review of the accepted plan-approval
exception. The workplan remains blocked, not finished; the existing task holds
this obligation.
## MASON-WP-0004
The session check at `http://127.0.0.1:18200` reports no valid caller session
and no scoped ops-mason grant. No credential value was requested. The original
21-path/17-undescribed inventory has no saved path-level snapshot in this repo;
source documents cannot prove the current live path set or completeness.
T01–T03 therefore remain wait for an attended scoped metadata grant, current
inventory, and owner confirmations. No ownership or recovery story is invented.
Source-backed candidates for the next T01 inventory comparison:
| Path or family | Proposed responsible repo | Evidence / unresolved question |
| --- | --- | --- |
| operators/lldap/admin | net-kingdom | platform-root-custody.md; confirm current consumers and recovery |
| operators/privacyidea/pi-admin | net-kingdom | platform-root-custody.md and verify-t06.md; confirm recovery ownership |
| operators/forgejo/state-hub-svc | railiance-platform | MASON-WP-0003 construction/delivery record; confirm active metadata |
| platform/workloads/railiance/backup/object-storage | railiance-platform | plans/backup-object-storage.md |
| platform/workloads/railiance/backup/offsite-lane | railiance-platform | ops-warden catalog railiance-backup-offsite-lane |
| platform/workloads/railiance/scaleway/bootstrap | railiance-platform | plans/reef-storage-scaleway-bootstrap.md |
| user-engine/runtime and rapp-qonto families | owning consumer plus railiance-platform custody | corresponding plans in this repo; exact current paths need live inventory |
| reuse-surface/runtime-secrets | reuse-surface plus railiance-platform custody | cited by T02; current owner procedure still needs confirmation |
These are candidates, not accepted custom_metadata, and do not enumerate the
missing seventeen. Every additional live path needs an owner or a named unknown
before T01 can close.
T04 preparation fixes an actual false-success defect: an unavailable/denied
metadata request previously returned an empty list and exit 0. The inventory
now exits 2 on missing grant, command failure or malformed response, exits 1
for missing descriptions, and reserves 0 for a completed inventory. It refuses
to fall back silently to the user's default token. The default Bao address in
both helpers now follows the private tunnel. Tests cover failure reporting and
metadata-only traversal. Running it without a grant returned the expected
explicit error, not a fictitious healthy inventory.
Scheduled reporting remains blocked on T03 and a named reader plus a
non-interactive metadata-only credential. No existing scheduler for this repo
was found; a 45-minute interactive grant cannot support a durable schedule.
## MASON-WP-0005
The September 9 platform reply (`c0977d84-9a63-421d-8ee1-98587fc60b1b`)
and `railiance-platform/docs/credential-lane-designs/fluid-telegram-operator-kv.md`
confirm a proposed matrix, not an accepted writer contract. Tenant/path,
field/capability acceptance, actual OIDC group/MFA and callbacks, named writer
authority, matching platform validator/renderer, and live survey remain open.
The existing ops-mason grant does not authorize auth/netkingdom role changes;
it must not be widened to bypass this boundary.
T01–T05 remain wait for those inputs and explicit construction approval.
T02 cannot be called done by shipping an unapproved engine shape: the owner
requires matching approved CCR and builder contracts before any writer.
T06 also waits for verification and routing-owner acceptance; no live lane or
resolvable pointer is claimed. Local draft preparation remains in the existing
construction plan. The separate adapter demand stays in its existing intake.

62
docs/kubernetes-plane.md
View file

@ -46,3 +46,65 @@ ops-mason plane rollback-plan --bundle bundles/<id>.yaml
Rollback output is a plan, never an action. Review live inventory immediately
before using it.
## Readiness gate
`apply` checks `ops_mason.readiness.inspect_readiness` after approval/digest
checks and before any Kubernetes command. `preflight` reports the result even
when direct apply would be refused.
| Verified target state | Direct apply under APPROVED |
| --- | --- |
| declared, installed, verified | Allowed with the existing approved-plan checks |
| production-approved, including a later evidence lapse | Refused; use the manifest repository and ArgoCD |
| deprecated | Retains the previous tier; missing history means production |
| missing, unknown, invalid or stale readiness | Production; refused |
| whitehat namespace, explicit founder placement of 2026-09-21 | Non-production, until a binding supersedes the placement |
| rapp-policy-nexus, production tier | Transition only before 2026-12-21; evidence labels it production |
ArgoCD now exists on railiance01, so the historical blanket transition for
all production targets is not enabled. The policy-nexus transition remains
bounded by its review date. The gate does not decide authorization or contact
an authorization engine.
Bundles include a reviewed namespace-to-binding mapping and a source pin:
```yaml
readiness:
target: {kind: rapp, rapp_id: rapp-user-engine, namespace: user-engine}
source:
repo: reef-railiance
path: bindings/rapps.yaml
revision: <full-40-character-commit-id>
sha256: <sha256-of-file-at-that-commit>
```
The approved bundle is the mapping record: the namespace must match its object
scope, and any namespace mapping in the source must agree. The only explicit
namespace placement is `kind: namespace, namespace: whitehat` for bundle
`whitehat-foundational-plane`, using the same pinned source so a newly declared
whitehat binding invalidates the placement. Other namespace-only targets and
platform objects remain production-tier.
Use `--readiness-repo /path/to/reef-railiance` on `preflight` or `apply` to
locate the source; the default is the sibling checkout. The gate verifies its
file digest, commit ancestry, unchanged content through local HEAD, clean source
file, and complete Git history. Refresh that checkout before review: the gate
checks local HEAD, not an unfetched remote. Missing source/history fails closed.
Any production approval in the reachable file history retains production tier;
a deliberate re-scope needs a separately reviewed gate change, not just lowering
the readiness field. Source pins and mapping changes alter the bundle digest
and need fresh review/confirmation. Existing live evidence remains historical.
For emergency direct apply, keep all normal plan/digest requirements and add:
```bash
ops-mason plane apply --bundle bundles/<id>.yaml \
--confirm <approved-plan-id> --expect-digest <digest> \
--activation BREAK_GLASS --break-glass-reason '<incident and justification>'
```
The JSON evidence and CLI output record activation, local executing account,
time, reason, resolved tier/source, and the obligation to commit the same
change to the manifest repository ArgoCD reconciles. The command does not open
that change or grant emergency authority itself. An empty reason is refused.