diff --git a/workplans/FLEX-WP-0029-stance-register-second-edition.md b/workplans/FLEX-WP-0029-stance-register-second-edition.md new file mode 100644 index 0000000..e21c278 --- /dev/null +++ b/workplans/FLEX-WP-0029-stance-register-second-edition.md @@ -0,0 +1,184 @@ +--- +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" +--- + +# 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 +``` + +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 +``` + +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 +``` + +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 +``` + +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.