Read a specification step that names a value the specification holds

[woksin]

Changed

• A specification step that names a value the specification holds is read as the construction that value was put together by, so a scenario stating its event or its command through a member reads the same as one constructing it inline (Screenplay generation: follow a specification value held in a field one hop #2412)

Fixed

• Screenplay options are resolved once, at whichever entry point sees them first, so emitting a model directly and reaching the same model through a generation no longer resolve the domain name against two different fallbacks (Screenplay generation hardening: small analysis and emission defects from review #2401)

[woksin]

Reviewer notes.

What changed. SpecificationStepReader required both a given-state and the issued command to be a BaseObjectCreationExpressionSyntax written at the step. New HeldValues follows an IdentifierNameSyntax / MemberAccessExpressionSyntax resolving to a field, property or local one hop to the single place it was given a value, and returns that construction with the semantic model of its tree (HeldConstruction) — the two need not share a tree once the member is inherited.

The discipline, deliberately kept narrow. Following is refused when:

• the value is given in more than one place (declaration initializer + assignment, or two assignments);
• the assignment sits under anything StepsTaken.IsConditional recognises — if, switch, a loop, a ternary, a lambda;
• what it is given is not itself a construction (no chains — one hop, never two).

All three keep reporting SP0039 and take the scenario with them, which is the existing rule.

One non-obvious carve-out. RegisterAuthor _command = null!; is the idiomatic declaration for a member filled in later, so counting it as a place the value is given would make every held value look like it was given twice — the feature would recover nothing. StatesNothing excludes null, null!, default and default!.

Spec churn worth looking at. a_specification_whose_steps_cannot_be_read had a case named and_the_command_is_held_in_a_field asserting exactly the behaviour this PR changes. It is now and_the_command_is_held_in_a_field_given_twice — a field given a value in two places — so the file still covers three genuinely unreadable shapes and the count assertion is unchanged. The readable shape moved to the new a_specification_holding_what_its_steps_state.

Verification. Screenplay.Specs 1181 passed / 0 failed. Debug and Release builds zero warnings. markdownlint-cli2 clean on the changed page.

Not verified. The issue's estimate of ~77 recovered scenarios on the reference application — I have no checkout of it, so that number is unconfirmed. Worth measuring before closing #2412 if the count matters.

[woksin]

CI note. A red specs (Source/DotNET/MongoDB.Specs) run may appear in this PR's history. It is an unrelated pre-existing flake — same SHA, no changes, green on re-run — now filed as #2453. This branch changes only Source/DotNET/Screenplay/, and MongoDB.Specs has no dependency path to it.

Consolidation. #2452 (Screenplay options resolved once, #2401 item 7) was folded in here rather than shipped separately, since both change the Screenplay generator and this repository ships related work as one PR. Its commit f6dbd59e is unchanged; the label stays minor, which dominates that change's patch.

Verification of the merged branch. Screenplay.Specs 1181 passed / 0 failed. Release build zero warnings.

[woksin]

Heads-up: #2522 just merged and it touches Source/DotNET/Screenplay/Analysis/Specifications/SpecificationStepReader.cs, which this PR also changes. Expect a conflict.

More important than the conflict is why that file changed. SpecificationStepReader was one of several places calling compilation.GetSemanticModel(tree) directly. That throws SyntaxTree is not part of the compilation whenever the tree belongs to a referenced project's compilation — which happens for any multi-project application, because MSBuildWorkspace wires project references as CompilationReferences and their symbols keep real DeclaringSyntaxReferences. It took Screenplay generation down completely on real applications (#2521).

The fix routes those reads through Analysis/SemanticModels.cs — models.For(tree) finds the compilation that actually holds the tree and returns null when none does, so an unreadable value degrades to a diagnostic instead of an exception.

When resolving the conflict, please keep the SemanticModels routing. Reinstating a direct compilation.GetSemanticModel(...) in this reader brings the crash back, and no spec will catch it: every spec in Screenplay.Specs builds its compilation from source strings, so a second compilation never exists. #2522 adds coverage that does exercise the boundary — worth rebasing onto it rather than merging around it.