--- id: FLEX-WP-0029 type: workplan title: "The stance register outgrew the review that read it: five rows, and the divergence was ruled rather than resolved" domain: infotech repo: flex-auth status: ready flavor: review owner: claude topic_slug: netkingdom planning_priority: P2 planning_order: 290 related_workplans: - FLEX-WP-0019 created: "2026-09-20" updated: "2026-09-20" state_hub_workstream_id: "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 ```task 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 ```task 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 ```task 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 ```task 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.