Screenplay generation: recover validation messages from WithMessage(_ => Constant) lambdas (SP0016)

[woksin]

Summary

Validation-message recovery only accepts messages given as constant values directly. The very common FluentValidation shape WithMessage(_ => SomeMessages.Constant) — a lambda returning a constant — is rejected with SP0016 [Warning] A message was declared without a constant value or without a rule preceding it, and was left out. In an application that uses the message-constants pattern consistently, every validation message in the generated document is lost.

Evidence (real application)

Generating from the Ada application produced 643 SP0016 warnings, and the generated document's validate blocks carry no message "…" clauses at all. Ada's validators consistently use:

RuleFor(c => c.Name)
    .NotEmpty()
    .WithMessage(_ => AccountsMessages.Name_Required);

where AccountsMessages.Name_Required is a const string. The Screenplay grammar has first-class support for messages (not empty message "…"), so the loss is purely on the recovery side.

Two compounding notes:

• The lambda body here is a plain member access to a const field — resolvable with the semantic model (IFieldSymbol.HasConstantValue), no evaluation needed.
• In Ada the message classes are source generated, so recovering them also requires the host to run source generators before analysis (see the companion SP0024 issue) — but the lambda shape fails even for hand-written const classes.

Suggested fix

In the validation chain reader, when WithMessage receives a lambda whose body is a field/property reference with a compile-time constant value (or a literal), use that constant as the message. Keep SP0016 for genuinely computed messages (interpolation, method calls, localization lookups).

Environment

• Cratis.Arc.Screenplay 20.65.0 (Analysis/Validation/ValidationChainReader.cs)

[woksin]

Correction to the evidence in this issue, checked against the current Ada tree while implementing it (PR #2408).

The fix described here is implemented, but it recovers nothing on this application — and the reason matters.

All 510 WithMessage calls are the lambda form, as the issue says. But every one of them points at a resx-generated designer property:

internal static string SomeMessage {
    get { return ResourceManager.GetString("SomeMessage", resourceCulture); }
}

That is a runtime, culture-dependent lookup, not a constant. IFieldSymbol.HasConstantValue / GetConstantValue cannot reach it, so "use the constant" has no constant to use. The issue's own carve-out — keep SP0016 for genuinely computed messages — is exactly what applies. SP0016 therefore stays at 643.

The lambda-returning-a-literal and lambda-returning-a-const shapes are now recovered, and are specified hermetically. They simply do not occur here.

The 643 figure is also not all message drops. The real split is:

Cause	Count
RuleFor(c => c) whole-command rules	268
messages	247
Must	59
NotEqual	28
MustAsync	20
When	12
InclusiveBetween	6
IsInEnum	3

So even full message recovery would move SP0016 by 247, not 643.

What did improve. Those 247 drops now name the expression they could not write down, and the 12 When drops name their condition, so what was lost is inspectable rather than reported as a generic sentence.

What would actually recover them: emitting a $strings. localization key from the resx key, rather than trying to resolve the message to text at generation time. That is a different change and is filed separately as #2409.