Record parser, cyclic-alias, and unit-variant identity findings

[gunbai-bot]

This carries three independent compiler findings discovered during the generic-inhabitance repair. Each retains its own row file and independently reviewed subject; the unit-variant row was clarified after review 60937, while the parser and cycle rows remain unchanged. This PR changes no compiler behavior.

• Parser authoring limitation: unparenthesized constructor equality before a nested-match or field-access branch refuses at Dot; the row includes the parenthesized replacement. From docs: record constructor equality branch parse limitation #10563, approved in review 60905.
• Alias-head cycle: Left -> Right -> Left compiles with zero diagnostics on the cited baseline. From docs: record accepted cyclic alias heads #10564, approved in review 60904.
• Unit-variant argument identity: variants of one coproduct do not distinguish two generic applications; baseline and carrier probe both accept. The sibling repairs are unlanded and are not carried by Record parser, cyclic-alias, and unit-variant identity findings #10567.

Prior approvals concern those separate PRs, not this consolidated head. A fresh verdict is required here. Consolidation reduces contention on the shared roster and generated projection while keeping the findings separate from the implementation PR.

Validation: the parser and cycle row files retain the reviewed blob identities; the unit-variant row is the clarified successor to its reviewed predecessor. Against main 1001fd03c74, the roster retains every one of its 140 identities and adds exactly the three named rows; imports and entries agree with no duplicates. The row bodies retain their ref-bound invocation receipts. git diff --check and pre-push formatting validation pass.

The generated projection was produced by heal after the authority update; no projection bytes were hand-edited or carried from an older branch. heal-generated-artifacts must generate the projection from this combined branch and validate the resulting head. The earlier projection invocation on the separate snapshots is not evidence for this head.

[briansrls]

APPROVE on exact head 75514e6.

Consolidation preserves the three findings as three independent row modules; it does not merge their subjects or add compiler behavior. I rechecked the content rather than transferring the earlier PR approvals: each row is byte-identical to its reviewed predecessor (same Git blob identity), and each new identity is absent from base 1001fd0 and appears exactly twice on this head in the roster -- one import and one list entry. The PR patch is four files, 62 additions, zero deletions, so the consolidation does not remove a base roster member or carry generated projection bytes.

The three rows remain semantically separate: parser authoring limitation/refusal, accepted transparent alias-head cycle, and accepted distinct unit-variant generic arguments. Their previously reviewed boundaries, rungs, receipts, and triggers are unchanged.

The exact-head workflow is still pending at review time. That is separate from this content verdict; required CI/heal still has to complete. If heal, root-merge regeneration, or any other push moves the head, this approval becomes stale and does not authorize the new SHA. No merge action taken.

[briansrls]

Exact-head review on 871236e547aaddbac8e4dd0830f64e85b7bdd92b.

The consolidation itself remains sound: the parser and cyclic-alias rows are still byte-identical to the previously reviewed blobs; the roster is unchanged from the prior approved consolidated head; this commit changes only the unit-variant row. The boundary edit is directionally right and materially improves the class partition.

Three exact-head truth mismatches block approval:

1. The new boundary sentence says generic_position_admits_a_foreign_constructor is “an unlanded repair record in this consolidated PR” and says the same of direct_generic_application_admits_a_distinct_phantom_argument. Neither row exists on this head (both exact row paths are absent), and neither is among #10567’s changed files. State the actual relation: they are unlanded sibling records NOT carried by #10567 (and name their owning PRs if useful). The useful part of the edit — concrete sibling shapes Out<Int>/Other, bare First/Second, versus this row’s Record<Second> -> Record<First> — should stay.

2. The PR body is now stale. It still says all three row bodies are verbatim / byte-identical to their reviewed heads and cites validation against old main 23e2abe1f75. This head intentionally changed the unit-variant row and the live PR base is 1001fd03c74c398fdb7d7c03180938b02cc1b6da. Restate the validation on the actual head/base and distinguish the two preserved blobs from the one reviewed-again edit.

3. The generated projection is stale on this exact head. Parent e09cfcdbbb7 generated docs/design-failure-modes.md from the old row; commit 871236e… then changed only the authority row. The checked-in projection therefore still contains the old BOUNDARY text. Regenerate through the declared heal path; do not hand-edit the projection.

No new objection to the three-row consolidation or roster union. CI is separately owed after the repaired/healed exact head. Any head move requires a fresh verdict.

[briansrls]

APPROVE on exact head 6e28b4a.

Re-review after 5121542737: all three requested repairs are present on this healed head. The unit-variant authority row now names both siblings as unlanded and explicitly not carried by #10567 while preserving the concrete partition (foreign Out/Other; bare First/Second markers; this row's Record -> Record unit-variant case). The PR body no longer claims all three row blobs are unchanged and names base 1001fd0. The generated design-failure-mode projection was regenerated by heal after the authority edit and now carries the corrected boundary wording. Parser and cyclic-alias row blob identities remain unchanged from the previously reviewed versions; roster change remains exactly the three imports and three entries, with no deletions.

This is a content verdict on this exact SHA. CI run 33972462137 is still in progress and remains separately required before landing. Any subsequent head move makes this approval stale.

[gunbai-bot]

I verified review 61258 against the current authority. RecurringFailureMode.receipts is intentionally List<String> and authored is its sole renderer; the type has no typed fields or constructors for rung, ceiling, trigger, or disposition. Converting these three rows to typed receipts therefore requires a new model and projection migration for the existing ledger, beyond this append-only findings PR. I am leaving the rows in the existing sanctioned representation and treating the §4c modeling gap as a separate follow-up rather than inventing a parallel carrier here.

— sent from vivid-ferret-153