Name the constraint that rejected a command

[woksin]

Added

• The name of the violated constraint on a validation result, so a client can tell one constraint rejection from another without matching on the message text (a rejection carries no machine-readable identity, so nothing downstream can tell one rejection from another #2487)
• ShouldHaveConstraintViolationFor for asserting a command result names a given constraint, matching the assertion already available against a raw append (a rejection carries no machine-readable identity, so nothing downstream can tell one rejection from another #2487)

Fixed

• A client-composed validation failure no longer loses its reason, which had reported every such result as an authored rule (a rejection carries no machine-readable identity, so nothing downstream can tell one rejection from another #2487)

[woksin]

Reviewer context, kept out of the body.

Shape and semver. ReasonDetail is an init-only body property on ValidationResult, mirroring Reason from v21.0.0. The record stays a four-parameter positional record, so its constructor, Deconstruct and with are unchanged — a fifth positional parameter would have been binary breaking. The three factories gained a trailing optional parameter, so existing call sites bind unchanged. It is a plain string? rather than Chronicle's ConstraintName because Arc.Core does not reference Chronicle and must not start.

Why the assertion matters as much as the field. Chronicle's testing package already ships ShouldHaveConstraintViolationFor against an IAppendResult, and this repository's own analyzer lists that name among its named rejections, while the .ai corpus tells authors to assert the constraint name and never the message. None of that was reachable from a command result, because the name was dropped in the conversion — the documented way to specify a constraint could not be written. The field and the helper are one gap seen from two sides.

Verification. Debug and Release, --no-incremental, for Arc.Core, Chronicle, Testing and their spec projects: zero warnings, zero errors. Arc.Core.Specs 1925, Chronicle.Specs 641, Testing.Specs 30, Arc.Specs 274 — no failures. TypeScript tsc -b clean, vitest 778, eslint clean.

Mutation evidence, each applied and restored with the restore verified by hash:

Mutation	Result
drop reasonDetail from the conversion	4 assertions, 637 passing — specific
carry a wrong constraint name	the same 4 — specific
helper's name comparison always true	3 assertions, specific
helper's reason check dropped, identity alone	3 assertions, specific
assertion policy call removed from the helper	1 assertion, specific

Two notes for whoever reviews the surrounding area. The reason a client-composed validation failure carries has been dropped since v21.0.0 introduced it; that is the Fixed bullet, and it is now pinned. And a first draft of the TypeScript member used string | undefined with a default, which is structurally required in TypeScript and broke a story file in Arc.React — caught only by building a package downstream of the one changed. It is ?: now.

Not covered. The TypeScript specs are asserted green but were not mutation-tested. ReasonDetail's wire encoding is argued from the serializer defaults rather than observed over HTTP. ConcurrencyViolation and DependencyUnavailable carry no detail yet — deliberately out of scope.

[woksin]

Independent review found three things worth acting on. All are addressed in ec43230e.

The Fixed bullet was only half true, and the review is what caught it. QueryResult.validationFailed dropped reason and reasonDetail exactly as CommandResult.validationFailed did — the same bug, in the file whose doc comment three lines above promises it mirrors the command side so a caller reads the two the same way. Fixing one and not the other made that promise less true than it was before. Both are fixed now, so the bullet holds for commands and queries alike.

Nothing on the query side was specced at all. The reviewer's mutation removing both fields from QueryResult's server mapping passed the entire suite. Two specs added — one for the mapping, one for the composed failure — and both mutations now die: dropping the mapping kills 2 assertions, reverting the validationFailed fix kills 2.

One of my new assertions could not fail. It filtered for a constraint name that appears nowhere in its fixture and asserted the count was zero, which holds whether or not the name is carried. It now filters for the name the fixture does carry and asserts it is found; it dies to the mapping mutation along with its siblings.

On semver, the reviewer did the experiment I had only argued. Compiling a consumer against 506ee40f and running it against 78226061 throws MissingMethodException — the three factories each gained a trailing optional parameter, and C# bakes defaults into the call site, so this is source-compatible but binary-breaking. Keeping minor deliberately rather than by omission: it is neither a removal nor a rename, and the only downstream callers across the Cratis repos are applications, which recompile. Worth recording that Reason's v21.0.0 precedent rode a major, so it does not settle the question, and that a with { ReasonDetail = … } expression would have delivered the same feature with no ABI change at the cost of an asymmetry with reason.

Record equality was checked and is inert — nothing keys, dedupes or groups by a whole ValidationResult, and the specs that compare one compare it to itself.

Gate after the fixes: 305 spec files / 782 tests in the Arc package, tsc -b clean, eslint 0 errors (5 pre-existing Unused eslint-disable warnings in for_ObservableQueryMultiplexer and for_QueryResult, unchanged with these edits stashed).

Two things the reviewer raised that I did not act on: the helper takes a string where Chronicle's takes a ConstraintName — Cratis.Arc.Testing cannot reference Chronicle, and the implicit conversion covers the call site — and there is no spec for several validation results where the match is not the first. Any(...) makes that correct rather than lucky, but the input space is genuinely uncovered.