FLEX-WP-0029: publish the second stance-register edition across five rows
(a third scope axis, not a converging two — tenant-engine scopes on
engine-reachability, not security-zone), record Finding 1 as resolved by
gate-house doctrine rather than by either side, and note Finding 3 as still
open in secrets-engine's file. First edition marked superseded, not amended.
SCOPE.md's G3 gap closed accordingly.
FLEX-WP-0031: correct cadence.yaml to declare one heartbeat per rare
load-bearing class instead of a single combined class (tests pass unchanged).
Acknowledged audit-core's AUDIT-IN-0006 reply on T02 and recorded its
corrections; the remaining work (drain, reconciliation, PVC rollout, G2
closure) stays wait/blocked pending the founder's attended OpenBao mint and
gate-house's atomicity ruling, so the workplan moves to blocked.
FLEX-WP-0027: marked blocked — the sole remaining task needs the operator's
own signed-in account, an irreducible human action.
FLEX-WP-0020: recorded net-kingdom's T04 update (NK-WP-0039-T02 done,
runtime.yaml digests current) and replied with no objection to their
ADR-0015 values-pointer proposal for the drifted runtime.yaml reference.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: sonnet
Assistant-Process: 250108@bnt-lap001
Assistant-Session: bab3d5bd-b0bb-42d0-bf80-94ed6fc2b08a
TWO FINDINGS, BOTH FROM READING OTHER REPOSITORIES RATHER THAN OURS.
The §13.1 stance register has a second row. secrets-engine published
pep-stance.yaml -- total over catalog stage plus unknown, runtime-read
and pinned to SHIPPED_STANCE by test. SCOPE.md claimed ops-warden's was
the estate's only published map and that the register's single row was
itself the finding; that is no longer true and is corrected.
docs/stance-register-review.md is the first exercise of the
aggregate-divergence capability flex-auth claimed on 2026-08-29 and then
recorded as unexercised because one row cannot diverge from anything.
Three findings:
The two maps take opposite stances on unknown -- ops-warden fail_open by
versioned build profile under ADR-0009, secrets-engine fail_closed. Both
conformant, neither a defect, and they disagree about the one case nobody
planned for. Reported as an observation for gate-house's register, not as
a request that either repository change: a PDP does not set a consumer's
stance, and §9.3's two-owner split is our own finding.
The rows are not comparable. ops-warden scopes by security-zone,
secrets-engine by catalog-stage. §6.4 permits both, but the register
cannot then answer what the estate's stance is for a z2 workload. Worth
recording before a third row arrives.
secrets-engine's map defines fail_closed in terms of a durable
ActionAuthorization record, which GH-DEC-2026-005 shelved. The stance is
unaffected -- only the artifact name is stale -- but the file is read at
runtime and pinned by test, so the stale name outlives a comment.
SEPARATELY, T04 IS BLOCKED AND THE REASON IS STRUCTURAL. The task assumed
the ops-warden/tenant-engine/user-engine pattern, where the pin's
default-deny NetworkPolicy admits one approved consumer workload.
secrets-engine has no Kubernetes deployment at all -- it is a CLI. There
is no pod selector to write, and inventing one would repeat the error
corrected in T02. Three possible shapes recorded in the workplan and
raised with them; callerAuth, not the NetworkPolicy, becomes the real
boundary if an operator CLI is the caller, so the FLEX-WP-0016 precedent
does not transfer unexamined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTbVXpEiXA7mNJVpDnEPcB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19
