flex-auth/workplans/FLEX-WP-0029-stance-register-second-edition.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	planning_priority	planning_order	related_workplans	created	updated	state_hub_workstream_id
FLEX-WP-0029	workplan	The stance register outgrew the review that read it: five rows, and the divergence was ruled rather than resolved	infotech	flex-auth	ready	review	claude	netkingdom	P2	290	FLEX-WP-0019	2026-09-20	2026-09-20	5a11099d-b492-535c-af88-c334db5e8ee6

FLEX-WP-0029 — Stance-register review, second edition

docs/stance-register-review.md is status: published, dated 2026-09-06, and titled "the register has a second row". It is flex-auth's first exercise of the aggregate-divergence capability it claimed on 2026-08-29, and it is now stale in three separate ways at once.

What changed under it

	At publication (v0.7 §13.1)	Today (v0.8 §13.1)
Rows in the register	2	5 — ops-warden, user-engine, tenant-engine, secrets-engine, ops-mason
Scope axes in play	2 (zone, catalog stage)	3 by zone, 1 by stage, 1 absent
unknown divergence	open, reported as observation	ruled by v0.8 §6.4 obligation 3
Marked non-conformant	none	two rows — ops-warden's cell, ops-mason's absent map

The review's own closing sentence was "worth recording before a third row arrives, because the cost of two incommensurable axes is small and the cost of five is not." Five arrived in fourteen days. The prediction landing is itself the finding, and a second edition that does not say so wastes it.

The constraint this plan operates under

Supersede; do not amend in place. A published review that is silently rewritten to match the world is the same defect flex-auth ruled against in FLEX-DEC-2026-008: a correction a reader cannot see is not a correction. The 2026-09-06 edition stays as written, marked superseded, with the second edition in a new file. flex-auth does not get to hold other repositories to a rule it exempts its own artifacts from.

This is still not a §13.1 register. gate-house owns the register. This is one reviewer's reading of the rows in it, and the second edition must keep saying so.

1. Record that Finding 1 was ruled, not resolved

id: FLEX-WP-0029-T01
status: todo
priority: high
state_hub_task_id: "5a7ed269-974f-5c6a-8e80-e9aa0077f8aa"

Owner: flex-auth.

v0.8 §6.4 obligation 3 states that unknown is not a zone and MUST resolve to fail_closed, with the reasoning that being unclassifiable must not buy permissiveness. That disposes of Finding 1's open question — flex-auth asked whether §6.4 should say anything about unknown specifically, and gate-house answered yes.

Three things must be recorded accurately, because the easy summary is wrong:

• The divergence was resolved in secrets-engine's direction, by doctrine, not by either repository persuading the other. flex-auth reported it as an observation and explicitly requested no change; the rule came from gate-house.
• ops-warden assented to the rule and deliberately did not flip the cell. Zero of four signing targets resolve to a zone and three are unknown, so converting today would fail closed on essentially every certificate during a flex-auth outage — including the certificate needed to reach the host and repair flex-auth. WARDEN-WP-0040 orders it: classify the continuity path, raise coverage by asking owners, then convert. That is ADR-0006's rejected configuration reached by another route, and the refusal is correct.
• §13.1 therefore marks ops-warden's row non-conformant while the row is right to be unconverted. Conformance and correctness have come apart on this cell, and the second edition should say that plainly rather than report the mark alone.

Gate: the second edition states who moved, why, and that flex-auth did not cause it. No claim that flex-auth's review produced the rule.

2. Re-run Finding 2 across five rows

id: FLEX-WP-0029-T02
status: todo
priority: high
state_hub_task_id: "991ebb94-cdc4-574a-ba60-f8960ec885fc"

Owner: flex-auth.

Finding 2 said the register cannot answer "what is the estate's stance for a z2-protected workload?" because two rows scoped on different axes. At two rows that was a property worth recording. At five it is measurable, and the measurement changed direction:

• ops-warden, user-engine, tenant-engine — security zone
• secrets-engine — catalog stage, explicitly interim "pending zone membership as a claim"
• ops-mason — no map at all

The axis is converging on zones, with one interim holdout and one absence. That weakens the alarm in the first edition and strengthens flex-auth's own boundary claim, which must be restated rather than assumed: zone membership compiles into the registry snapshot flex-auth already consumes, while per-zone stance belongs to the consumer. If membership arrives as a claim on the decision, secrets-engine's axis converges without either side inventing a stage-to-zone mapping.

Also assess whether ops-mason's absent row is the more useful subject than the axis question. A published map that is wrongly valued is reviewable; an absent one is not, and §13.1 marks both. Report which of the two costs the estate more.

Gate: the finding is re-derived from the five current rows, not carried forward from the two-row text.

3. Close out Finding 3 against the current file

id: FLEX-WP-0029-T03
status: todo
priority: medium
state_hub_task_id: "6dd2c9fd-8ad9-54d6-8fb1-f24e44189f00"

Owner: flex-auth to verify; secrets-engine owns the file.

Finding 3 reported that secrets-engine's pep-stance.yaml defines fail_closed in terms of a durable ActionAuthorization record, an artifact shelved on the PEP consumption path by GH-DEC-2026-005 (accepted by flex-auth in FLEX-DEC-2026-006, against its own proposal). The stance was unaffected; only the artifact name was stale.

Read the current file and record the outcome either way. If it still cites the shelved name, say so as an open item rather than re-reporting it as new; if it was corrected, say who corrected it and stop carrying the finding.

Gate: the outcome is read from the file, not inferred from the absence of a reply.

4. Propagate the row count and state the version trigger

id: FLEX-WP-0029-T04
status: todo
priority: medium
state_hub_task_id: "4dbadd0b-7670-5837-90c9-6201c10479d7"

Owner: flex-auth.

• SCOPE.md says §13.1's register "now has two rows rather than the one the standard recorded as itself the finding." Update to five, and keep the sentence's point — that the register grew past the state the standard recorded.
• INTENT.md frontmatter declares standard_version: "0.7". Do not bump it. v0.8 is status: proposed; flex-auth assented to the boundary in FLEX-DEC-2026-011 with four findings, all adopted. The declaration tracks the accepted version, and bumping it early would make the machine-readable declaration assert something the canon does not yet say. State that trigger explicitly in this plan so the next session does not "fix" it: the bump happens when security-layer-model_v0.8.md reaches status: accepted, and it is a one-line change plus the prose references in INTENT.md.
• Add the second edition to the contract/orientation capability blocks in SCOPE.md only if the first edition is listed there; do not invent a new capability for a republished review.

Gate: no file in the repo claims the register has two rows; no file claims flex-auth has declared v0.8.

Out of scope

• Adopting v0.8 as flex-auth's declared standard version. That follows acceptance, not this review.
• gate-house's A-16 / A-17 (DISTINGUISHABLE ROUTES, and unknown vs absent as two meanings behind one runtime behaviour). A-16 bears on flex-auth's own decision record and is a larger question than a register review; it gets its own workplan if it needs one. Note the adjacency in the second edition, do not absorb it here.
• Any request that ops-warden convert its cell. WARDEN-WP-0040 owns the order and flex-auth agreed the order is right.