dev is red: the new collection-item shape guard rejects a model #308 added

[phmatray]

Problem / motivation

dev is red. CI has failed on every commit since 0ad0d49 (2026-08-13T13:17Z); 01a6580 and
everything before it was green. This blocks every open PR — each one merges a red dev and inherits
the failure.

FormCraft.ForMudBlazor.UnitTests.Fields.CollectionItemShapeGuardTests
  .No_Suite_Should_Re_Declare_A_Collection_Item_Shape_The_Fixture_Provides

  offenders should be empty but had 2 items and was
  [ FieldConfigurationRefreshTests.EqualityItemModel holds List<EqualityItem>, whose shape (String)
      is already a CollectionItemFixture item type,
    FieldConfigurationRefreshTests.EqualityItemModel is a collection root whose composition (String)
      is already modelled by CollectionItemFixture.NamedOrderModel or OrderModel ]

Reproduced on a pristine checkout of origin/dev (65944e5) with no other changes:
dotnet test FormCraft.ForMudBlazor.UnitTests/... -c Release → Failed: 1, Passed: 582.

Neither PR is at fault on its own

This is a semantic collision between two PRs that landed four minutes apart, each green on its own
branch:

PR	What it added	Merged
#308 (fix(mudblazor): re-read a field's configuration when the rendered field changes, #298)	FieldConfigurationRefreshTests.EqualityItemModel / EqualityItem	947a3a5
#306 (test(mudblazor): fail the build when a suite re-declares a fixture model shape, #297)	CollectionItemShapeGuardTests, which rejects exactly that shape	0ad0d49

Neither branch contained the other's code, so neither CI run could see the conflict. The guard is doing
precisely the job #297 asked for — it is the pairing that is new, not a defect in either change.

Proposed solution

The guard's own failure message names the two remedies, and choosing between them belongs to whoever
owns #298/#308, because it turns on why that suite needed its own type:

1. Use the fixture's model — CollectionItemFixture.NamedOrderModel / OrderModel with the
   fixture's item-form builder, if the refresh test's assertions do not actually depend on
   EqualityItem's identity semantics.
2. Allowlist it with a reason — pass FieldConfigurationRefreshTests.EqualityItemModel to
   FindOffenders' allowlist, if a local type genuinely is warranted (the test is named for equality
   behaviour, so this is plausible and is exactly the escape hatch Nothing detects a suite re-declaring a collection-item shape the fixture provides #297 built).

Deliberately not guessing here: allowlisting without cause weakens a guard that has existed for
minutes, and forcing the fixture model could silently change what the refresh test asserts.

Alternatives considered

• Revert test(mudblazor): fail the build when a suite re-declares a fixture model shape (#297) #306 (the guard). Restores green immediately, but discards a guard that is working as
  designed and would have to be re-landed with the same collision waiting.
• Revert fix(mudblazor): re-read a field's configuration when the rendered field changes (#298) #308. Discards a real fix for Field components cache their configuration at init, so a reused instance renders the previous field's settings #298 over a test-model naming choice.
• Leave it and let each PR author work around it. Every open PR merging dev inherits a red bar
  they did not cause; the cost multiplies by the number of PRs in flight (currently several).

Area

Test infrastructure — FormCraft.ForMudBlazor.UnitTests/Fields/FieldConfigurationRefreshTests.cs and
FormCraft.ForMudBlazor.UnitTests/Fields/CollectionItemShapeGuardTests.cs.

Related: #297/#306 (added the guard), #298/#308 (added the model), #205, #258, #282 (the fixture
consolidation the guard enforces), #343 (a different suite re-declaring fixture models — same class,
Fluent UI rather than MudBlazor).

---

Filed while merging #333, which is blocked by this: its own CI is green in isolation but fails once
dev is merged in. No implementation plan attached deliberately — the fix is a one-line judgement call
that belongs to #298/#308's author, not a multi-step task.

[phmatray]

Resolved by #346 — closing.

a68cf29 (test(mudblazor): allowlist the record-item model the shape guard flags (#346)) took remedy (2) from the Proposed solution above: allowlisting FieldConfigurationRefreshTests' model with a reason rather than forcing it onto the fixture's. That is the right call if the refresh test genuinely depends on the record's equality semantics — which its name says it does — and it keeps the guard's teeth for everyone else.

Verified on a pristine checkout of origin/dev (8d23d45): FormCraft.ForMudBlazor.UnitTests → 584 passed, 0 failed, and No_Suite_Should_Re_Declare_A_Collection_Item_Shape_The_Fixture_Provides no longer appears among failures. CI is green on a68cf29 and 8d23d45.

dev was red for roughly 4 minutes' worth of commits (0ad0d49..65944e5). No action left here.