@cratis/pi 7.128.0 → 7.130.0

package/package/corpus/skills/cratis-screenplay-toolchain/references/screenplay-contract.version

@@ -1 +1 @@
-4.245.0
+5.1.0

package/package/corpus/skills/cratis-screenplay-toolchain/references/traps.md

@@ -62,7 +62,7 @@ Identity and compliance traps (`identity.md`, `concepts.md`, `events.md`, `purpo
   unknown, not safe. Arc needs `[ExecuteCommandsAsSystem]` to supply a principal.
 
 Traps 39 to 44 are tool traps.
-39. Attached file/inline command handlers refuse PLAY0800 (`CommandHandlerRequiresAttachment`): permanent constrained-attachment requirement, so gap-fill in code rather than wait for ESM admission. Read required typed `arguments.subject`, not the message; older binders use PLAY0268 (version gate: [diagnostic arguments](diagnostic-arguments.md)). Pending `handler implementation` beside unconditional productions binds as a described v23 command (PLAY0695). Body-reaching specs are Unsupported ImplementationBody; Stage still refuses rendering STAGE-IMPL-002 even in Stub mode; semantic execution reports ImplementationBody only when reached after gates. `implementation` and `hint` are accepted on a command handler, an operation execute/compensate phase and a command property named rule, and are rejected on concept rules, built-in property rules and whole-command `require`/`validate` bodies; hints do not execute, lock or confirm a body. A handler slice is gap-fill, not a customization of a rendered slice.
+39. An attached file/inline command handler binds as the v23 result contract only beside unconditional `produces` with a resolved, nonempty body; with no `produces`, `produces ... when` or an unresolved body it refuses PLAY0800 (`CommandHandlerRequiresAttachment`). Read required typed `arguments.subject`, not the message; older binders refuse every attached handler (version gate: [diagnostic arguments](diagnostic-arguments.md)). Pending `handler implementation` beside unconditional productions binds as a described v23 command (PLAY0695). Body-reaching specs are Unsupported ImplementationBody; Stage still refuses rendering STAGE-IMPL-002 even in Stub mode; semantic execution reports ImplementationBody only when reached after gates. `implementation` and `hint` are accepted on a command handler, an operation execute/compensate phase and a command property named rule, and are rejected on concept rules, built-in property rules and whole-command `require`/`validate` bodies; hints do not execute, lock or confirm a body. A handler slice is gap-fill, not a customization of a rendered slice.
 40. `numbers exact` (the source mode) parses but never binds (PLAY0268; "not admitted by any supported executable model (ESM) version yet") and is PLAY0001 on older compilers; it is absent from `grammar.md`. Exact lowering of qualifying Double-mode literals is separate (v11). Never use it in a model or example meant to execute.
 41. MCP roots bug: a dynamic-root server on an old tool answers the roots request with an `id: null` error right after `notifications/initialized`; hosts treat it as fatal, and `open-workspace.path` does not help. Start with a fixed root (`screenplay mcp <folder>`, `cratis screenplay mcp` in a project with `.cratis/ai.json`).
     Requires Screenplay 4.63.2 or later (`screenplay --version`) for a dynamic-root server; the compiler bundled in older cratis releases lacks it.

package/package/corpus/skills/cratis-screenplay-toolchain/references/verdicts.md

@@ -227,7 +227,7 @@ results, plus runtime when it was exercised:
 2. **Publication**: what was written, unchanged or refused (`.cratis-render.json`,
    `.cratis-render/journal.json`; `recovered: true` means stop and reconcile).
 3. **Build**: Debug build of the destination (`dotnet build`).
-4. **Tests**: Debug tests of the destination (`dotnet test`). Generated specifications are
+4. **Tests**: After the Debug build, run `dotnet test <destination>/<Project>.csproj -c Debug --no-build` for Stage-rendered apps (VSTest). Use a built spec executable only in repositories whose spec projects really are executables (see [specs.csharp](../../../rules/specs.csharp.md)); never start the rendered app's web-server executable to run specs. Generated specifications are
    compiled in Debug only; map results by generated spec class (`when_<snake>` in namespace
    `<Slice ns>.when_<snake>`, `when_<snake>_is_queried`, `when_<snake>_is_projected`) back to
    the `.play` specification, not by test counts.

package/package/corpus/skills/cratis-screenplay-ui-composition/SKILL.md

@@ -248,6 +248,12 @@ Read [change alternatives](references/change-alternatives.md) when a component's
 
 Read [interaction example](references/interaction-example.md) when wiring a
 named confirmation behavior and an inline refresh to the same screen.
+
+State every plain and toolbar `action`'s subject: `for item` (the chosen record fills its
+inputs) or `for screen` (no row does). Omitted, the compiler infers it from types, and a
+create action on a list can bind the selected row's id. Read
+[action subjects](references/action-subjects.md) when adding a screen action or when
+PLAY0817-PLAY0821 appear.
 Scalar/named `returns` bind and reference-execute (ESM v7).
 Renderer generation/response limits: command-surface `references/generated-values-and-responses.md`.
 Screenplay resolves response names in form submit and execute success (Requires Screenplay 4.148.0 or later);

package/package/corpus/skills/cratis-screenplay-ui-composition/references/action-subjects.md

@@ -0,0 +1,73 @@
+# Action subjects: `for item` and `for screen`
+
+Requires Screenplay 4.248.0 or later (`screenplay --version`). Source: Screenplay
+`Documentation/screenplay/action-subjects.md` (decision 0110).
+
+A plain or toolbar `action` states whether it acts on one chosen record or on the screen:
+
+- `for item`: the nearest single `data` record, or the selected row of a collection. Inputs bind
+  from it: explicit `with <input> from item.<field>` first, then case-sensitive same-name
+  fields, then one key field with the same declared concept.
+- `for screen`: independent of selection; no row fills the inputs. Use it for actions that
+  create something or that the user fills in through the form.
+
+The clause follows the command name, before an inline `label`. Only action toolbar items
+accept it.
+
+```screenplay
+concept TaskId : Uuid
+concept Title : String
+module Work
+  feature Tasks
+    slice StateChange AddTask
+      command AddTask
+        taskId TaskId identifier
+        title Title
+        produces event TaskAdded
+          title Title = title
+    slice StateChange CompleteTask
+      command CompleteTask
+        taskId TaskId identifier
+        note String
+        produces event TaskCompleted
+          note String = note
+    slice StateView OpenTasks
+      readmodel OpenTask
+        taskId TaskId key
+        title Title
+      projection OpenTasks => OpenTask
+        from TaskAdded
+          taskId = $eventSourceId
+          title = title
+        remove with TaskCompleted
+      query ListOpenTasks => OpenTask[]
+      screen OpenTasksScreen
+        title "Open tasks"
+        data OpenTask[] via query ListOpenTasks
+        action AddTask for screen
+          label "Add task"
+        action CompleteTask for item
+          label "Complete"
+          with taskId from item.taskId
+        table OpenTask
+          column title label "Task"
+```
+
+State the subject on every plain and toolbar action. Without it, the compiler infers `for item`
+when there is exactly one collection `data`, one required non-generated identifier and one key
+with the same concept, and `for screen` otherwise. Inference follows types, not intent: here
+`AddTask` without a clause infers `for item`, because its `taskId` has the row key's concept,
+and would bind the selected row's id to a new task.
+
+| Code | Severity | Meaning | Fix |
+| --- | --- | --- | --- |
+| PLAY0817 | Error | Malformed, duplicate or misplaced subject clause | One clause after the command name |
+| PLAY0818 | Information | Explains an omitted subject's inference | State `for item` or `for screen` |
+| PLAY0819 | Warning | The inferred binding differs from the legacy case-insensitive row-name matching | Decide per action: `for screen`, or `for item` with explicit inputs; never bulk-accept |
+| PLAY0820 | Warning | Several keys could bind one input | Write `with <input> from item.<field>` |
+| PLAY0821 | Warning | A guarded `for screen` action has collection data and cannot choose one item | Use `for item` or single-record data |
+
+A model written before 4.248.0 can report PLAY0818/PLAY0819 on every list-screen action. Review
+each one against what the action means; a create action is `for screen` even when the row has a
+matching identifier. Compiler inference is authoring evidence only: Scene owns the runtime
+selection and form-input behavior.

package/package/corpus/skills/cratis-screenplay-ui-composition/references/file-references.md

@@ -7,8 +7,9 @@ This reference holds the three meanings of `file` and the rules for paths and lo
 Three meanings, one word:
 
 - **Backend implementation attachment.** On an attached command `handler`
-  (PLAY0800: permanent constrained-attachment requirement, gap-filled in code;
-  pending described handlers instead bind v23 without a file), a validation
+  (binds as the v23 result contract beside unconditional `produces` with a resolved
+  body from Screenplay 4.250.0, otherwise PLAY0800; pending described handlers bind
+  v23 without a file), a validation
   rule predicate, a query `performer`, a reducer rule, a reaction trigger, a
   `constraint` and a `policy`, `file` stands in for the inline body: the
   implementation lives there. These are the files a host inventories.
@@ -22,7 +23,7 @@ Three meanings, one word:
   `readmodel`, `projection`, `slice`, `specification`, top-level `trigger` — it
   only records which file realizes it.
 
-Requires Screenplay 4.210.0 (`screenplay --version`) for the file/inline handler's PLAY0800; older binders use PLAY0268. Read its required typed `arguments.subject` to identify the command, never the message.
+Requires Screenplay 4.250.0 (`screenplay --version`) for a file/inline handler beside `produces` to bind; 4.210.0 to 4.249.x refuse it with PLAY0800 and older binders use PLAY0268. Read its required typed `arguments.subject` to identify the command, never the message.
 
 The rules:
 

package/package/corpus/skills/cratis-screenplay-ui-composition/references/response-continuations.md

@@ -72,7 +72,7 @@ module Billing
           title String = title
         returns invoiceId
       screen CreateInvoiceScreen
-        action CreateInvoice
+        action CreateInvoice for screen
           label "Create invoice"
     slice StateView Details
       readmodel Invoice

package/package/corpus/skills/cratis-screenplay-ui-composition/references/worked-flow.md

@@ -21,7 +21,7 @@ module Marina
       screen BookBerthScreen
         title "Book a berth"
         data BerthListView[] via query ListBerths
-        action BookBerth
+        action BookBerth for screen
           navigate to BerthListScreen
           label "Book berth"
     slice StateView BerthList

package/package/corpus/skills/cratis-specifications-csharp/references/running-specs.md

@@ -11,9 +11,13 @@
 - Filters
 - Migrate from 4.x to 5.0
 
-Requires `Cratis.Specifications.XUnit.v3` 5.0 on `net10.0`. Check the
-`PackageReference` versions in the specification project; 4.x projects follow the
-checklist below before the executable loop applies.
+The xUnit examples and migration checklist require `Cratis.Specifications.XUnit.v3`
+5.0 on `net10.0`. This is not a requirement to migrate frameworks: identify the
+project's evaluated runner first. TUnit and `Cratis.Specifications.Runner` suites
+also run their built executable, with their own help-confirmed flags, not xUnit
+`-trx`/filter flags. Only legacy VSTest projects use `dotnet test <project> --no-build`.
+Check package versions and the actual configuration/TFM; the 4.x migration checklist
+below applies only when migrating, not as a prerequisite to running an existing suite.
 
 Sources: [Running specifications fast](https://github.com/Cratis/Specifications/blob/main/Documentation/running-fast.md),
 [The native runner](https://github.com/Cratis/Specifications/blob/main/Documentation/runner.md) and

package/package/corpus/skills/cratis-stage-rendering-and-sandbox/SKILL.md

@@ -148,11 +148,12 @@ and unaudited-version refusals still stop first. Codes, limits and fixes:
   overrides (`-036`), unsupported code validation (`-005`), DateTime filters (`-010`),
   unsupported conditional productions, unsupported composite-key projection shapes, including DateTime and decimal key parts (`STAGE-ESM-048`, and `-047` for a single-instance query by parts) and unsupported `all` shapes.
   Protected reads render as Arc read protection in a new enough bundle; shapes it cannot preserve, and every protected read in an older bundle, refuse `STAGE-ESM-044` (see admission.md). Described handlers still refuse `STAGE-IMPL-002` even in Stub mode. Query-performer gaps are a separate contract, not a completed implementation.
-- **Attached command handlers (`PLAY0800`):** file/inline handlers permanently require
-  constrained implementation attachments: gap-fill the slice in code, not by waiting
-  for ESM admission. Read the required typed `arguments.subject` for the command,
-  never match message text. Requires Screenplay 4.210.0 (`screenplay --version`);
-  older bundled binders use PLAY0268 for these handlers.
+- **Attached command handlers:** a file/inline handler beside unconditional `produces`
+  with a resolved body binds as the v23 result contract and Stage renders its C# body.
+  Without `produces`, with `produces ... when` or with an unresolved body it refuses
+  `PLAY0800`: read the required typed `arguments.subject` for the command, never match
+  message text. Older bundled binders refuse every attached handler (version gate:
+  toolchain `references/executable-subset.md`).
 - **Binding refusals:** read toolchain `references/executable-subset.md` for
   `PLAY0268`/`PLAY0271` families; binding is not rendering. Composite keys have
   target-specific support, not blanket refusal. Never drop protection.
@@ -240,7 +241,8 @@ to disk with no managed staging and no safe stale-file removal; a failure can le
   result. State the scope in the V5 report.
 - Report V5 as separate results, each a result or "not run": admission, publication,
   Debug build (`dotnet build <destination>/<Project>.csproj -c Debug`), Debug tests
-  (`dotnet test` on the same project) and runtime. Render alone is the first two.
+  (`dotnet test <destination>/<Project>.csproj -c Debug --no-build` after the build; Stage-rendered apps use VSTest) and runtime. Render alone is the first two.
+  Use a built spec executable only in repositories whose spec projects really are executables (see [specs.csharp](../../rules/specs.csharp.md)); the rendered app's executable starts its web server, not its specs.
 - A refusal is kept verbatim as reported: `PLAY*` (compile or bind), `PLAN-*` (execution
   plan), `STAGE-*` (admission), `CLI-RENDER-*`, or a plain ownership error for a managed
   file. The fix is an intent-preserving model change or a recorded gap, never an edit of

package/package/corpus/skills/cratis-stage-rendering-and-sandbox/references/admission.md

@@ -314,11 +314,14 @@ pure expressions, and no generated type shadowing a referenced one. Anything els
 `STAGE-ESM-019`, `-021` or `-022`. A reducer needs a `StateView` slice, its read model in the
 same slice, a required Guid or text identifier and a matching keyed query. Resolved
 C# command/concept rule and iterator validation bodies have pure-gated render
-paths; unsupported body/context shapes still refuse. Attached
-command handlers refuse `PLAY0800` and permanently require constrained implementation
-attachments: gap-fill in code, not by waiting for ESM admission. Requires Screenplay
-4.210.0 (`screenplay --version`); older bundled binders use PLAY0268 for these handlers.
-Read the required typed `arguments.subject` for the command rather than the message.
+paths; unsupported body/context shapes still refuse. An attached command handler
+beside unconditional `produces` with a resolved body binds as the v23 result contract
+(Screenplay 4.250.0, decision 0117); Stage renders a C# body (`STAGE-IMPL-LANGUAGE` when
+no `csharp` body exists) and its semantic Host and executor report a reached body as
+`Unsupported(ImplementationBody)`. Without `produces`, with `produces ... when` or with
+an unresolved body the handler refuses `PLAY0800` at binding; 4.210.0 to 4.249.x refuse
+every attached handler with it and older binders use PLAY0268. Read the required typed
+`arguments.subject` for the command rather than the message.
 A pending handler beside unconditional productions binds as a described v23
 command; rendering still refuses it with STAGE-IMPL-002 even in Stub mode.
 Query-performer gaps are a separate contract: see [bodies and implementation gaps](current-boundaries.md#bodies-and-implementation-gaps).

package/package/corpus/skills/cratis-stage-rendering-and-sandbox/references/render-example.md

@@ -119,7 +119,7 @@ Why it is shaped this way:
 | Forced | the same with `--force` | `written: 1`, the rest `unchanged` |
 | Missing name | render without `--name` | exit 5: `A valid --name is required and must be a C# identifier` |
 | Debug build | `dotnet build out/Marina.csproj -c Debug` | succeeds, 0 warnings, 0 errors |
-| Debug tests | `dotnet test out/Marina.csproj -c Debug` | all specification classes pass |
+| Debug tests | `dotnet test out/Marina.csproj -c Debug --no-build` after the Debug build (Stage-rendered apps use VSTest) | all specification classes pass |
 
 Runtime (`docker compose up`, `/healthz`) and the frontend build are separate results.
 

package/package/corpus/skills/csharp-refactoring/SKILL.md

@@ -132,8 +132,8 @@ Use the repo's own build/test workflow when it documents one (`README`/`CONTRIBU
 
 Otherwise:
 ```bash
-dotnet build   # 0 errors
-dotnet test    # stays green; same pass count as before
+dotnet build   # 0 errors; use dotnet test <project> --no-build only for VSTest (see specs.csharp)
+./<project-dir>/bin/<Config>/<TFM>/<AssemblyName> # built spec executable; same discovered/passed counts
 ```
 
 One operation per step; never mix a refactor and a behavior change in the same step. On red, stop and report the failure; repair only your edit without discarding unrelated worktree changes.

package/package/corpus/skills/eliminate-redundant-restores/SKILL.md

@@ -73,7 +73,8 @@ Keep the first restore. Skip a later one only when all four checks pass:
 ### Step 4: Apply the smallest change
 
 - One explicit restore carrying every restore input, then `--no-restore`, `-restore:false` or `--no-build` on later steps.
-- Several `dotnet test` steps over one solution: build once, then `dotnet test --no-build` on each. Add `--no-restore -restore:false` if an rsp enables restore, including on .NET 8 and earlier. `--no-restore` alone still rebuilds.
+- Supported executable suites run their built spec runner instead (see [running-specs](../cratis-specifications-csharp/references/running-specs.md)); the dotnet-test examples here are VSTest-only.
+- Several `dotnet test` steps over one VSTest-only solution: build once, then `dotnet test --no-build` on each. Add `--no-restore -restore:false` if an rsp enables restore, including on .NET 8 and earlier. `--no-restore` alone still rebuilds.
 - Keep self-contained publish settings. A `publish --no-build` still needs a prior build with matching configuration, framework, RID and self-contained output; restore compatibility does not prove that build outputs exist.
 - Scope the change to CI and scripts. Leave `-restore` in `Directory.Build.rsp`, because developers rely on it; pass `-restore:false` per invocation instead.
 - Never remove the first restore. If it is a `--locked-mode` gate, keep it there.

package/package/corpus/skills/filter-syntax/SKILL.md

@@ -11,7 +11,7 @@ metadata:
 
 # Test Filter Syntax Reference
 
-Cratis rules in `.cratis/ai/rules/` (including `csharp.md`, `specs.csharp.md`, and `orleans.md`) and the `cratis-*` skills win where they differ. Specification authoring belongs to **cratis-specifications-csharp**; Cratis core repositories run xUnit v2 on VSTest.
+Cratis rules in `.cratis/ai/rules/` (including `csharp.md`, `specs.csharp.md`, and `orleans.md`) and the `cratis-*` skills win where they differ. Specification authoring belongs to **cratis-specifications-csharp**; identify the actual runner rather than assuming xUnit v2/VSTest. Supported Cratis executable suites use direct runner flags first (see its [running-specs reference](../cratis-specifications-csharp/references/running-specs.md)). The dotnet-test forms below are technical syntax when that entrypoint is explicitly required, not the Cratis default.
 
 Filter syntax depends on the **platform** and **test framework**.
 

package/package/corpus/skills/msbuild/references/build-perf-baseline.md

@@ -408,9 +408,12 @@ dotnet restore
 if ($LASTEXITCODE -ne 0) { throw "Restore failed; do not use stale assets." }
 dotnet build --no-restore -m
 if ($LASTEXITCODE -ne 0) { throw "Build failed; do not test stale outputs." }
-dotnet test --no-build
+./<project-dir>/bin/<Config>/<TFM>/<AssemblyName> # built spec executable
 ```
 
+Use the evaluated output without rebuilding (see [running-specs](../../cratis-specifications-csharp/references/running-specs.md));
+only VSTest uses `dotnet test <project> --no-build`. The executable step itself
+produces no MSBuild binlog.
 Use matching configuration/TFM/RID and restore-affecting properties in each stage.
 `--no-restore` requires current assets; `--no-build` requires successfully built
 matching test outputs. Keep restore-inclusive and build-only timings separate.

package/package/corpus/skills/run-tests/SKILL.md

@@ -88,6 +88,15 @@ resolved. Route identification-only requests to `platform-detection`.
 
 ## Decision table
 
+For supported Cratis xUnit v3, TUnit and native-runner suites, restore/build once
+and run each project's built executable directly, or `dotnet <TargetPath.dll>`
+when there is no apphost. Use the matching configuration/TFM and runner-specific
+filter/report flags; see [running-specs](../cratis-specifications-csharp/references/running-specs.md).
+Only identified VSTest projects default to `dotnet test <project> --no-build`.
+Mixed suites run per project, never solution-wide `dotnet test`. The command-mode
+forms below remain valid when the user explicitly requires dotnet-test syntax;
+do not switch an executable suite to them as an automatic fallback.
+
 | Detected mode / platform | Command shape | Never use |
 |---|---|---|
 | Classic non-SDK | Repository script, or full MSBuild followed by `vstest.console.exe` / `MSTest.exe` | Assuming `dotnet test` is compatible or migrating implicitly |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cratis/pi",
-  "version": "7.128.0",
+  "version": "7.130.0",
   "description": "Configuration-aware Cratis AI integration for Pi",
   "type": "module",
   "files": [