Skip to content

Describe every project of a solution rather than asking which one to read - #53

Open
woksin wants to merge 2 commits into
mainfrom
fix/screenplay-multi-project-selection
Open

Describe every project of a solution rather than asking which one to read#53
woksin wants to merge 2 commits into
mainfrom
fix/screenplay-multi-project-selection

Conversation

@woksin

@woksin woksin commented Jul 29, 2026

Copy link
Copy Markdown
Collaborator

Changed

  • screenplay generate describes every project of a solution in one document, instead of reporting a solution that holds more than one project as ambiguous and generating nothing
  • The domain defaults to the solution name when several projects are read; --domain still overrides it
  • The generated result names the projects the document was generated from

Fixed

  • A project named exactly Specs or Tests was taken for part of the application, putting test-only artifacts in the document

Removed

  • The CLI0002 ambiguous-project error, which no longer has a situation to report

woksin and others added 2 commits July 29, 2026 14:55
…read

An application is regularly split across several projects, and the generator
has taken a list of compilations since 20.65.2 — the CLI still reported a
solution holding more than one candidate project as ambiguous and generated
nothing at all.

- Every project that is not specs takes part in the same document, so a
  project holding only the events of a slice no longer has to be named by hand.
- A project named exactly `Specs` or `Tests` is recognized as specs. Only a
  dotted suffix was, which put test-only artifacts in the document.
- A project that yields no compilation is reported and left out rather than
  ending the run, so the projects that did load are still described.
- The domain defaults to the solution name; several projects have no single
  assembly for the generator to name the document after.
- The result names the projects the document was generated from — which ones
  took part is the difference between describing an application and half of it.

CLI0002 is retired rather than reused: a solution holding several projects
stopped being a question.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VRa2Z1cA6D3Fuw9TAo6m2p
@woksin woksin added the patch label Jul 29, 2026
@woksin

woksin commented Jul 29, 2026

Copy link
Copy Markdown
Collaborator Author

Reviewer context — deliberately kept out of the description.

This is agent-authored and no human has read it yet. Green CI is not sign-off.

This is the follow-up that could not be done before Cratis.Arc.Screenplay shipped Generate(IReadOnlyList<Compilation>, ScreenplayOptions) — the package reference moves 20.65.0 → 20.65.3 in the same change.

Verified on a real application

/…/Ada.slnx, nine projects, taken back-to-back with the same working tree:

Before (cli#51 as merged) After
outcome error CLI0002: holds 5 candidate projects (Composition, Core, Lobby, Specs, Specs.AppHost) — pass the project to generate from success
document 0 lines 9,485 lines
projects read none Composition, Core, Cratis.Ada.CodeAnalysis, Infrastructure, Lobby, Lobby.Contracts, Specs.AppHost
errors 1 0 (977 warnings, 1,119 info)

Against the same binary reading Core.csproj alone (9,373 lines), the solution adds feature Lobby and resolves what a single project could only leave as import Lobby.Invitations.InvitationToJoinAdaAccepted — an event referenced by Core and defined in another project.

  • Determinism: two runs byte-identical.
  • The document compiles: screenplay validate on the 9,485-line result reports 0 diagnostics.
  • Release build 0/0, 356 specs pass.

Three judgment calls worth a second opinion

1. The document is restructured, not just extended. With one compilation the generator names the domain after the assembly; with several it has no single assembly to name, and the fallback is the literal Application. The CLI now passes the solution name instead, so Ada reads domain Ada / module Ada with feature Core and feature Lobby rather than domain Application. Anyone regenerating an existing .play from a solution will see the whole document re-nest one level. --domain overrides.

2. Projects that are not the application are still read. Ada's analyzer project and Aspire host contribute nothing but are loaded. Filtering to projects that reference Cratis was considered and not done: a contracts project holding only events references Chronicle rather than Arc, and filtering by reference would silently drop exactly the project this change exists to include. The cost is load time, not content.

3. CLI0002 is retired rather than reused, and recorded as retired in ScreenplayDiagnosticCodes so a later code cannot take the number.

Not covered by specs

ScreenplayCompilationLoader needs an MSBuild workspace, so the per-project failure path (a project that yields no compilation is reported and left out while the rest are still described) is exercised only by the run above, not by a spec. The narrowing rule itself is specified, including the Specs-named project that the old dotted-suffix check missed.

@woksin

woksin commented Jul 29, 2026

Copy link
Copy Markdown
Collaborator Author

CI note: the first run failed in Cratis.Cli.Integration.Chronicle.for_Users.when_adding_and_removing_user — unrelated to this change and now filed as #54. Re-running the same commit with no changes passed; the same specs pass 8/8 locally against a real Chronicle container; Build dispatched on main is green; and the Cratis.Arc.Screenplay dependency set is byte-identical between 20.65.0 and 20.65.3, so the bump cannot reach the Chronicle client. Checks are green as of this comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant