Collection item fields emit the HTML5 Required attribute, contradicting the project's validation convention #190

Problem / motivation

The two render paths disagree about the HTML5 Required attribute, and the collection path is the
one that breaks the project's stated convention.

CLAUDE.md records the rule explicitly:

Required() adds validation but NOT HTML5 required attribute · Browser validation disabled via
novalidate · All validation through FluentValidation · MudBlazor components don't include
Required attribute

Measured with a probe rendering the same .Required("…") field two ways:

CollectionFieldComponent.AddCommonFieldAttributes emits builder.AddAttribute(…, "Required", field.IsRequired). No component-path renderer emits Required at all — grep -r "Required" FormCraft.ForMudBlazor/**/*.razor returns nothing.

Consequence. Inside a collection, MudBlazor's own required validation runs alongside
FluentValidation, so a blank required item field can produce two error messages with different
wording for one problem — and the message MudBlazor generates is not the one the developer wrote in
.Required("Product name is required").

Found while reviewing #188, which added a render-path parity test. Required was initially in that
test's compared set but was never configured by the test, so it asserted nothing; removing it
surfaced this genuine divergence, which the test now documents rather than hides.

Proposed solution

Stop emitting Required from AddCommonFieldAttributes, matching the component path and the
documented convention, then move Required into the parity test's compared set with the shared
Configure delegate actually calling .Required(...).

Validation behaviour is unaffected: Required() still registers its validator, and FluentValidation
still produces the developer's message. What disappears is MudBlazor's second, differently-worded
browser-style error.

Alternatives considered

• Emit Required on the component path too, making both paths agree in the other direction.
  Rejected: it contradicts the documented convention, re-enables browser-flavoured validation the
  project deliberately disables with novalidate, and would change behaviour on every existing form
  rather than only on collection item fields.
• Leave the divergence and document it. Rejected — the parity test would have to carry a permanent
  exception, and duplicate error messages are a real user-visible defect.
• Make it configurable. Disproportionate for an attribute the project has already decided about.

Area

FormCraft.ForMudBlazor — collection field rendering

Related: #184, #188 (where this was found), #189 (the other half of the same render-path drift)

flowchart TD
    A["field.Required(\"Product is required\")"] --> B{which render path?}
    B -->|ordinary field| C["no Required attribute<br/>FluentValidation only<br/><b>one message ✅</b>"]
    B -->|inside .WithItemForm| D["Required = true<br/>MudBlazor validation + FluentValidation<br/><b>two messages ❌ — today</b>"]
    D --> E["<b>after this issue:</b><br/>no Required attribute, one message"]

🛠️ Implementation plan

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: make Required behave the same on both render paths, in the direction the project has
already documented, and let the parity test prove it.

Architecture: all changes in FormCraft.ForMudBlazor; the UI-agnostic FormCraft core is
untouched. Required()'s validator registration is core behaviour and must not change.

Tech stack: .NET 8 / 10 multi-target, Blazor, MudBlazor 9, xUnit + bUnit + Shouldly (MudBlazorTestBase).

Global constraints:

• Base branch dev; commit as Philippe Matray <phmatray@gmail.com>; conventional commits.
• TreatWarningsAsErrors=true and CA analyzers are enforced — the build fails on any warning.
• dotnet test --filter is silently ignored here (MTP0001, Microsoft.Testing.Platform) — it runs the whole suite. Use the full run; it takes seconds.
• The documented convention is binding: validation is server-side, forms render novalidate, MudBlazor components carry no Required attribute.
• RenderTreeBuilder sequence numbers must stay source-position constants.

Task 1: Stop driving Required from IsRequired on the collection path

Files: modify FormCraft.ForMudBlazor/Features/CollectionField/CollectionFieldComponent.razor.cs (AddCommonFieldAttributes); create FormCraft.ForMudBlazor.UnitTests/Fields/CollectionRequiredTests.cs.

Interfaces: Required is resolved from the field's explicit "Required" attribute (default false) instead of from field.IsRequired.

• Step 1: Write failing tests in CollectionRequiredTests.cs: a .Required("…") item field renders Required == false; an item field with .WithAttribute("Required", true) renders Required == true.
• Step 2: Run dotnet test -c Release → FAIL (the first case renders True).
• Step 3: Resolve Required via GetItemFieldAttribute<bool>(field, "Required", false) rather than field.IsRequired, so the explicit opt-in survives.
• Step 4: Run dotnet test -c Release → PASS, with CollectionShrinkLabelTests, CollectionAdornmentTests and ShrinkLabelDiagnosticsTests green with no edits.
• Step 5: Commit: fix(mudblazor): stop emitting the HTML5 Required attribute on collection item fields.

Task 2: Prove validation still works, and only once

Files: modify CollectionRequiredTests.cs.

Interfaces: none new.

• Step 1: Write a test that submits a form whose required item field is blank and asserts the validation message is the one passed to .Required("…").
• Step 2: Write a test asserting exactly one validation message is surfaced for that field, not two.
• Step 3: Run the suite → PASS (Task 1 already produced this behaviour; this task pins it). If either fails, fix the cause rather than the assertion.
• Step 4: Commit: test(mudblazor): pin single-message validation for required collection item fields.

Task 3: Fold Required into the parity test and release-note it

Files: modify FormCraft.ForMudBlazor.UnitTests/Components/RenderPipelineParityTests.cs; modify README.md.

Interfaces: none new.

• Step 1: Call .Required("…") in the parity test's shared Configure delegate and add Required to Presentation(), removing it from that method's documented divergence list.
• Step 2: Run the suite → PASS. Then verify the guard bites: temporarily restore the field.IsRequired emission and confirm the parity test goes red, and restore.
• Step 3: Add a release-note bullet under the README's ## 🎉 Unreleased section: collection item fields no longer carry the HTML5 Required attribute, matching ordinary fields; validation is unchanged; .WithAttribute("Required", true) opts back in.
• Step 4: Run dotnet build -c Release and dotnet test -c Release → both green.
• Step 5: Commit: test(mudblazor): compare Required across both render paths.