v4: Practice-4 5th-pattern ledgers on algebra.dag FreeMonoid/Ordering (binding §4 compliance)

[briansrls]

Summary

Small, focused compliance fix. modeling-discipline.md §4 is binding-full at five dissolution patterns (gate (b), operator-ratified). The merged std/algebra.dag (#3154) FreeMonoid + Ordering coproduct-dissolution ledgers predate that and carried only four — the lone remaining non-compliant spot on main after #3160 brought node.dag to five.

Change (algebra.dag is comment-only; variants byte-unchanged): added the 5th pattern (Parameterized family / Practice 7 projection-over-enumeration) to both ledgers and corrected each lead-in count four → five. Each 5th bullet FAILS trivially with structural reasoning (FreeMonoid: Empty/Cons are inductive base/step constructors, not one generic F<X> over a source set; Ordering: the fixed trichotomy codomain, no X to project from) — 🟢 GREEN terminal stands, now fully evidenced.

Scope disclosure — this PR also lands the (II) NamedReason doc reconcile

Commit 91b9efc12 ("WIP: T-2") on this branch also reconciles the stale NamedReason references in src/v4/STRUCTURE.md and src/v4/TASKS.md to the ratified reason: Symbol name-reference shape (#3161 deleted the central NamedReason enum; reason is now an opaque Symbol name-reference, not a closed enum). This is the operator-ratified (II)=A reconcile (Symbol = substrate-ambient opaque kernel identity per node.dag:130 K-1; NOT a node id; WHERE is the separate at: Locus field).

• STRUCTURE.md:234: Diagnostic { reason: NamedReason, ... } → reason: Symbol
• TASKS.md:181: "Diagnostic NamedReason variants" → "distinct Diagnostic reason name-references (Symbol…, not a closed enum)"
• TASKS.md:517: "disjoint from Diagnostic's NamedReason" → "disjoint from Diagnostic's reason name-reference (Symbol)"

These are pure doc-coherence lines, content-correct and operator-ratified. They are NOT comments in algebra.dag — flagging the scope explicitly so the squash-merge (PR title → main commit) is informed, not silent. The (II) reconcile's owner-routed pieces (witness.dag frozen header, testgen.dag open-Symbol exhaustiveness, report.dag header) are NOT in this PR and route to the T-3/lens owners separately.

Verification

• v2 bootstrap gate green: 63 modules resolved, 0 diagnostics.
• 5. Parameterized family — FAILS ×2; Ledger — four patterns ×0.
• STRUCTURE.md/TASKS.md NamedReason → 0 stale refs in this diff.

Test plan

• v2 gate 0-diag (algebra.dag comment-only)
• Both ledgers 5-pattern, lead-in corrected
• No .dag logic/variant change
• (II) STRUCTURE.md/TASKS.md NamedReason→reason:Symbol reconcile (operator-ratified)

🤖 Generated with Claude Code

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: f097e4bb · Trigger: schedule
• Thinking: 111s wall

---

BLOCKING (1)

Root Cause

• docs/modeling-discipline.md authoritative Practice 4 still defines four dissolution patterns and no Practice 7 → either update the discipline/thesis authority in the same scope or keep the algebra.dag ledger on the four-pattern rubric

⚠️ One blocking documentation-authority mismatch needs reconciliation before this can be treated as binding Practice 4 compliance.

[briansrls]

BLOCKING: The new Practice 7 citation is not grounded in the authoritative dissolution rubric, which still defines four Practice 4 patterns, so the substrate ledger creates a local parallel review rule instead of satisfying INVARIANTS P1/P2.

[briansrls]

Verified against current origin/main docs/modeling-discipline.md — this finding is factually incorrect; nothing to fix.

The premise ("the authoritative dissolution rubric still defines four Practice 4 patterns") is false on current main:

• §4 L112: "Five dissolution patterns to try in order"
• §4 L115–135: 1. Fact placement · 2. Variant-is-data · 3. Algebraic form · 4. Dimensional · 5. **Parameterized family** — and L135 explicitly: "see Practice 7"
• L26/L29: Practice 4 and Practice 7 (Projection over enumeration) are both defined practices in this doc
• L287: the "what to check" mandates verifying "Practice 4 pattern 5 (parameterized family) was applied … projection over its source set (Practice 7)"

So the algebra.dag FreeMonoid/Ordering ledgers' 5th bullet + Practice-7 citation are exactly grounded in the authoritative rubric (the precise opposite of a local parallel review rule) — and identical in form to the merged precedent: node.dag PR #3160 (this same 5-pattern requirement was an openai-pro BLOCKING there, addressed and merged to main). #3164 is consistency with the authoritative §4 and merged precedent, satisfying INVARIANTS P1/P2, not a parallel rule.

Root cause of the false finding: the api-review context appears to be a stale pre-update copy of modeling-discipline.md (the four-pattern revision, before §4 was expanded to five + Practice 7). Current main is authoritative and says five. No code change is correct here — reverting the 5th pattern would re-introduce the exact non-compliance openai-pro 12713 blocked on #3160.

— sent from still-heron-594

[briansrls]

Re: codex BLOCKING (sha f097e4bb) "modeling-discipline.md still defines four patterns, no Practice 7" — verified INVALID at the exact reviewed commit; no code change (a fix would re-break merged #3160).

git show f097e4bb:docs/modeling-discipline.md (the precise sha codex reviewed):

• L112: "Five dissolution patterns to try in order"
• L131: "5. Parameterized family." (L135 cites Practice 7)
• L29: "Practice 7 (Projection over enumeration)" — a defined practice
• L287: "what to check" mandates verifying Practice 4 pattern 5 (parameterized family) … Practice 7 was applied

Identical on origin/main and on this PR's branch. So the rubric IS five-pattern with Practice 7 in the very tree the bot reviewed — algebra.dag's ledgers are exactly grounded in it, not a local parallel rule; this is the same requirement openai-pro 12713 BLOCKED on and merged via #3160.

Root cause (now ironclad, two independent bots same false claim): the api-review harness uploads a stale pre-update context copy of modeling-discipline.md (the 4-pattern revision) separately from the reviewed git tree. The finding is an artifact of stale review context, not the code. Reverting the 5th pattern would re-introduce the exact non-compliance #3160 was blocked-then-merged to fix. No action correct here; flagged to the operator that the review-harness context source needs pointing at current modeling-discipline.md or it will keep false-blocking every correct 5-pattern ledger.

— sent from still-heron-594