@cratis/pi 7.129.0 → 7.131.0

package/package/corpus/skills/cratis-chronicle-event-specifications/SKILL.md

@@ -229,6 +229,6 @@ assert the value can be claimed again.
 ## How it is proven
 
 `dotnet build` in Debug (which compiles the `#if DEBUG` specification code) and
-`dotnet test`, both clean. A constraint specification is only meaningful if it
+the owning project's built spec executable (see [specs.csharp](../../rules/specs.csharp.md)), both clean. A constraint specification is only meaningful if it
 has been seen to fail: remove the seeding `Given` once and confirm the
 specification goes red before trusting it green.

package/package/corpus/skills/cratis-chronicle-event-type-migration/references/explicit-migrations.md

@@ -41,6 +41,6 @@ the store-local alias. Custom schema generators resolving explicit compensation
 targets need the registry-aware overloads or throw
 `RegistryAwareEventTypeSchemasNotSupported`.
 
-Run `dotnet build -c Debug` and migration specs with `dotnet test`; assert both
+Run `dotnet build -c Debug` and migration spec executables (see [specs.csharp](../../../rules/specs.csharp.md)); assert both
 directions and real observer delivery where pinning or protected-value release
 matters. A successful nomination alone does not prove a generation can be read.

package/package/corpus/skills/cratis-chronicle-reactor/references/starting-and-replaying.md

@@ -29,5 +29,5 @@ handler is still subscribed to.
 
 Verify first registration, restart with an existing position, replay and
 failed-partition redelivery separately. Assert the external effect count, not
-only that the handler was invoked. Run `dotnet test` on the owning spec project;
+only that the handler was invoked. Run the owning spec project's built executable (see [specs.csharp](../../../rules/specs.csharp.md));
 server-first compatibility and durable positions also need kernel integration.

package/package/corpus/skills/cratis-chronicle-read-model/references/collection-observation.md

@@ -41,7 +41,7 @@ pretending observation succeeded.
 
 ## Verify
 
-Run `dotnet build -c Debug` and `dotnet test` for the owning query specs. Cover
+Run `dotnet build -c Debug` and the owning query spec executable (see [specs.csharp](../../../rules/specs.csharp.md)). Cover
 empty, add, update, remove, filter exit and disposal.
 Requires Arc 22.87.0 for Chronicle observations in `QueryScenario`.
 Requires Arc 22.91.1 with Chronicle 19.59.1 for default-mode children/joins/reducers. Scenario rebuilds do

package/package/corpus/skills/cratis-chronicle-read-model-specifications/SKILL.md

@@ -283,6 +283,6 @@ Read `references/view-lifecycle-checks.md` when delivering a read model from a c
 
 ## How it is proven
 
-`dotnet build` in Debug and `dotnet test`, both clean. A projection
+`dotnet build` in Debug and the owning project's built spec executable (see [specs.csharp](../../rules/specs.csharp.md)), both clean. A projection
 specification is only meaningful once it has been seen to fail: drop one seeded
 event and confirm the assertion goes red before trusting it green.

package/package/corpus/skills/cratis-ci-pipeline-performance/SKILL.md

@@ -75,7 +75,7 @@ named reference before applying one.
 **Build once, shard the tests.** Fits execution-bound workflows where build and
 tests run serially or several jobs each rebuild. Default: one job builds in
 `Release`, uploads the output with `actions/upload-artifact`, and a matrix of shard jobs downloads it and runs
-`dotnet test --no-build`. Pitfall: a shard whose filter matches nothing still
+each built spec executable; only VSTest projects use `dotnet test <project> --no-build`. Pitfall: a shard whose filter matches nothing still
 passes, so assert that every shard ran tests. Read
 `references/build-once-and-shard.md` when applying or reviewing this.
 

package/package/corpus/skills/cratis-ci-pipeline-performance/references/build-once-and-shard.md

@@ -75,15 +75,19 @@ jobs:
         with:
           name: build-output
       - run: tar --zstd -xf build-output.tar.zst
+      # Example assumes each xUnit v3 mtp-off AssemblyName matches its directory.
+      # Use evaluated TargetPath for custom outputs; TUnit/native runners need their own report flags.
+      # Only VSTest uses dotnet test <project> --no-build --configuration Release with --logger/--results-directory.
       - name: Test the shard's projects
         env:
           PROJECTS: ${{ matrix.projects }}
         run: |
           failed=0
           for project in $PROJECTS; do
-            dotnet test "$project" --no-build --configuration Release \
-              --logger "trx;LogFileName=$(basename "$project").trx" \
-              --results-directory "$RUNNER_TEMP/test-results" || failed=1
+            mkdir -p "$RUNNER_TEMP/test-results"
+            # xUnit v3 mtp-off example: resolve each project's actual AssemblyName/TFM.
+            "$project/bin/Release/net10.0/$(basename "$project")" \
+              -trx "$RUNNER_TEMP/test-results/$(basename "$project").trx" || failed=1
           done
           exit "$failed"
       - name: Verify every project ran tests

package/package/corpus/skills/cratis-ci-pipeline-performance/references/flaky-and-hung-jobs.md

@@ -24,7 +24,7 @@ cost runner-minutes and developer trust; diagnose before retrying.
 ## Find hangs and crashes in .NET
 
 ```bash
-dotnet test Repo.slnx --configuration Release --no-build \
+dotnet test VSTest.Specs.csproj --configuration Release --no-build \
   --blame-hang --blame-hang-timeout 5m --blame-hang-dump-type mini \
   --blame-crash --blame-crash-dump-type mini \
   --results-directory TestResults

package/package/corpus/skills/cratis-ci-pipeline-performance/references/test-setup-cost.md

@@ -32,7 +32,7 @@ Measure before guessing, with the language's profiler on the test process:
 
 ```bash
 dotnet tool install --global dotnet-trace
-dotnet-trace collect --format speedscope -- dotnet test Project.Specs --no-build --configuration Release
+dotnet-trace collect --format speedscope -- ./<project-dir>/bin/Release/<TFM>/<AssemblyName>
 ```
 
 Read the inclusive time of the setup methods. Pass means the profile names the

package/package/corpus/skills/cratis-commits-and-pull-requests/references/pr-labels-and-release.md

@@ -70,7 +70,7 @@ Do not open a pull request per task when the tasks belong to the same body of wo
 
 Before a consolidation or a re-land of reverted work merges, prove it dropped nothing with `cratis-engineering-consolidation-guard`.
 
-Split into separate pull requests when the changes are genuinely unrelated, when one is urgent and the others are not, or when one is risky enough to want its own revert.
+Split into a separate pull request only for the exceptions in `cratis-engineering-release-trains`: a named major awaiting human confirmation, an urgent security fix authorized in writing, or an accepted outsider issue. Unrelated or riskier work rides a later train instead.
 
 ## Quality gates
 
@@ -81,7 +81,7 @@ Documentation-only changes use repository-supported non-release intent, ordinari
 Before marking code/automation work ready, select the affected-project gates that apply from the following list; run wider checks for cross-cutting changes and repository-required merge/release gates:
 
 - `dotnet build`: zero errors, zero warnings
-- `dotnet test`: all specs pass
+- Built C# spec executables: all specs pass; `dotnet test <project> --no-build` only for VSTest (see specs.csharp)
 - `yarn lint`: zero errors
 - `npx tsc -b`: zero TypeScript errors
 - Code follows all project coding standards and conventions

package/package/corpus/skills/cratis-engineering-ci-gates/SKILL.md

@@ -81,8 +81,9 @@ a red run to discover the next failure.
 
 Several agents, worktrees or builds often share one machine. Keep it responsive:
 
-- Cap parallelism, for example `dotnet build -m:2`, `dotnet test -m:2` with the
-  spec runner's thread limit, and `vitest run --maxWorkers=2`.
+- Cap parallelism, for example `dotnet build -m:2`, built spec executables with their
+  runner-specific thread limit, and `vitest run --maxWorkers=2`. Do not pass MSBuild
+  `-m` to executables; `dotnet test <project> --no-build -m:2` is VSTest-only.
 - Run one heavy phase at a time (build, then specs, then frontend lint and
   tests), never several at once.
 - Do not start a heavy phase while another agent's runs in the same machine's
@@ -133,10 +134,20 @@ After the run completes with a failure:
 3. Fix all in-scope causes together. Report unrelated or unavailable causes as
    blockers rather than silently waiving them. Re-run the required local gate
    on the fixed state, then push once when the request authorizes it.
-4. Rerun a job only for a diagnosed flake, including a demonstrated transient
-   infrastructure failure, and only after the run completes. For example,
-   `gh run rerun <id> --repo OWNER/REPO --failed` retries failed jobs. Watch the
-   resulting attempt once. A deterministic failure needs a fix, not a retry.
+4. Flaky tests never hang a release. Classify within about 15 minutes from one
+   failed-log read and the test's history on main: real (in code the change
+   touched) or flaky. A flaky or pre-existing claim needs independent root-cause
+   validation; an unknown or repeating failure without a matching signature is
+   real and a blocker, not a quarantine candidate.
+   - Confirmed flake: after the run completes, rerun once, e.g.
+     `gh run rerun <id> --repo OWNER/REPO --failed`; a known flake with a
+     matching signature may go straight to quarantine. If it fails again,
+     quarantine the test in the same train via the repo's mechanism, open a
+     tracked "Flaky: <test>" issue with the evidence (label `flaky`), and push
+     once. Never quarantine silently or disable security or critical-path
+     coverage; if the security lens vetoes, evict the item or escalate.
+   - Real failure: fix in one round or evict the item. Never retry in loops; a
+     train waits at most one CI cycle on a flake.
 
 Never put a CI skip token in a title or commit. Do not spend a push on each
 individual fix or use CI to discover whether speculative fixes compile.

package/package/corpus/skills/cratis-engineering-local-cross-repo-verification/SKILL.md

@@ -162,9 +162,13 @@ From the consumer root, with the printed NuGet environment sourced:
 
 ```bash
 dotnet build path/to/consumer.slnx -c Release -warnaserror
-dotnet test path/to/Integration.csproj -c Release --no-build --filter '<regression>'
+./<integration-project-dir>/bin/Release/<TFM>/<AssemblyName> <runner-specific-filter>
 ```
 
+Resolve the integration project's actual built spec entrypoint and filter syntax with
+[running-specs](../cratis-specifications-csharp/references/running-specs.md); without
+apphost use `dotnet <TargetPath.dll>`. Only VSTest uses `dotnet test <project> -c Release
+--no-build --filter '<regression>'`. Keep the sourced local NuGet environment.
 Substitute the repository's actual commands; for frontend fixes run build, lint,
 specs and the previously broken UI action. Pass: the reproducing spec/action now
 succeeds, at least one intended filtered spec actually ran, and the consumer's

package/package/corpus/skills/cratis-engineering-local-cross-repo-verification/references/worked-examples.md

@@ -50,10 +50,14 @@ step. Apply the entry point's check/restore/cleanup sequence to both repositorie
    export CHRONICLE_KERNEL_VERSION="$stamp"
    cd "$consumer"
    dotnet build path/to/Studio.slnx -c Release -p:StudioFullBuild=true -warnaserror
-   dotnet test Source/Integrations/Specs/Specs.csproj -c Release --no-build \
-     --filter '<regression>'
+   ./<integration-project-dir>/bin/Release/<TFM>/<AssemblyName> <runner-specific-filter>
    ```
 
+   Resolve the actual output and filter for `Source/Integrations/Specs/Specs.csproj`
+   via [running-specs](../../cratis-specifications-csharp/references/running-specs.md).
+   Without apphost use `dotnet <TargetPath.dll>`; only VSTest uses
+   `dotnet test <project> -c Release --no-build --filter '<regression>'`.
+   Inspect the current consumer workflow before claiming CI equivalence.
    Studio defaults kernel selection to the client version when the environment
    override is absent. Ensure logs show the stamped local image. Local Debug
    Studio builds skip analyzers; use `-p:StudioFullBuild=true` to match CI analyzer
@@ -83,9 +87,11 @@ bash "$local" use-nuget "$arc" "$stamp"
 Gates (Arc `dotnet-build.yml`), run in this order after sourcing the printed env:
 `yarn install --immutable`; in `Source/DotNET/Screenplay.Embedded`: `npm ci --workspaces=false`,
 `npm run typecheck`, `npm test`, `npm run build`; `dotnet build --configuration Release
--p:CratisSpecsTargetFramework=net10.0`; then `dotnet test <project> --no-build --configuration
-Release --framework net10.0` for each project that `python3 scripts/ci-test-shards.py projects
---shard specs-N` prints. Finish by listing Arc's `obj/project.assets.json` files for the stamp.
+-p:CratisSpecsTargetFramework=net10.0`; then each project's evaluated Release/net10.0
+spec executable (or `dotnet <TargetPath.dll>` without apphost) for each project that
+`python3 scripts/ci-test-shards.py projects --shard specs-N` prints. Only identified
+VSTest projects use `dotnet test <project> --no-build --configuration Release --framework
+net10.0`. Inspect the current consumer workflow before claiming equivalence. Finish by listing Arc's `obj/project.assets.json` files for the stamp.
 
 - Pass: the Fundamentals IDs in `project.assets.json` are at the stamp, build has 0 warnings and 0 errors, 18 spec projects run and none fail.
 - Time: pack about 4 min, build about 6 min, the spec projects about 18 min.
@@ -134,9 +140,12 @@ bash "$local" use-nuget "$direct" "$stamp"
 ```
 
 Gates (Direct `build.yml`): `dotnet build Source/Direct/Direct.csproj -c Release
--p:DisableProxyGenerator=true`, the same in Debug with `-warnaserror`, `dotnet test` of that
-project with `--no-build`, and `dotnet test Source/Assurance/Assurance.csproj`. Then
-check `project.assets.json`. Image-based specs also need the producer image tag.
+-p:DisableProxyGenerator=true`, the same in Debug with `-warnaserror`, then the project's
+verified built Debug spec entrypoint. Build `Source/Assurance/Assurance.csproj` in the
+matching configuration and run its verified spec entrypoint too; do not guess assembly
+names or start an application server. See [running-specs](../../cratis-specifications-csharp/references/running-specs.md);
+only VSTest uses `dotnet test <project> --no-build` in that configuration. Inspect the
+current consumer workflow before claiming equivalence. Then check `project.assets.json`. Image-based specs also need the producer image tag.
 
 - Pass for a consumer whose pins lag the producer: every Chronicle ID is in the feed at the
   stamp, the Release build with the owner's floors passes, and `project.assets.json` shows every

package/package/corpus/skills/cratis-engineering-release-trains/SKILL.md

@@ -13,7 +13,8 @@ compatibility: Requires git and the GitHub CLI (gh).
 A **candidate** is the branch assembling deliveries intended to ship together.
 A repository includes its main checkout and all its worktrees. Consider their
 concurrent work together, not as separate releases merely because it has
-separate branches. One person or session assembles the candidate.
+separate branches. One person or session assembles the candidate. Even a single
+item ships as a train: the train is the PR, and item branches get no PR.
 
 ## Authority and routing
 
@@ -39,8 +40,8 @@ run handling, and `cratis-engineering-review-rounds` for proportionate review.
 Each push to an open PR starts checks on shared runners. Push the branch for
 backup or hand-off if needed, but open the PR only once, when the work is
 verified locally and ready. Push to it again only for a correction that review
-or CI found. Do not open a draft PR to see what CI says. Related work goes into
-one PR (see below and `cratis-engineering-consolidation-guard`). An orchestrator
+or CI found. Do not open a draft PR to see what CI says. All work goes into
+the repository's one train PR (see below and `cratis-engineering-consolidation-guard`). An orchestrator
 opens the one PR; a sub-agent delivers a verified branch and does not open or
 push to a PR unless the request says so. Pass `--assignee @me` when creating it.
 
@@ -53,7 +54,7 @@ push to a PR unless the request says so. Pass `--assignee @me` when creating it.
    gh pr list --state open --json number,headRefName,title,author
    ```
 
-2. Group related, ready deliveries under one candidate and one PR. Check with
+2. Group ready deliveries under one candidate and one PR. Check with
    the person assembling an existing candidate before changing it. Independent
    work branches start from `origin/main`; work that depends on an unmerged
    candidate may start from that candidate's latest commit (see Replace waits
@@ -67,10 +68,14 @@ push to a PR unless the request says so. Pass `--assignee @me` when creating it.
    ready delivery branches with merge commits. Keep each logical change in its
    own commits. Return a conflicting or failing delivery for correction rather
    than guessing its intent in the assembled branch.
-5. Keep one candidate per repository by default. Apply the split criteria in
-   `pull-requests.md` for unrelated work, different risk, or an urgent fix. Name
-   the exception in the reviewer comment; a major awaiting human confirmation
-   must not silently hold unrelated safe work indefinitely.
+5. Keep one train per repository. Split only for a named major awaiting human
+   confirmation, an urgent security fix authorized in writing, or an accepted
+   issue reported by someone outside the organization (patch or minor), which
+   ships promptly on its own release right after private security work; issues
+   captured by internal bots are not outsider issues. Name the exception in the
+   reviewer comment. Other unrelated or differently risky work rides a later
+   train, not its own PR. Item branches get no PR, CI or
+   `run-integration` label; they get local gates and a delta review.
 
 Minimal assembly, after agreeing on the included deliveries:
 
@@ -103,19 +108,19 @@ release, publish, or deploy run, or another session's watched merge. Leave
 others running and report them. Follow `cratis-engineering-ci-gates` for the
 cancellation checks; folding a PR is not blanket cancellation authority.
 
-## Size by readiness, then freeze
+## Cadence, then freeze
 
-Before the final gate, list in-flight deliveries and their expected readiness.
-Hold the cut for work expected ready within about one gate duration, so the
-assembled gate runs once on the larger set. Cut without work further out or
-blocked on a design decision, consumer proof, or another repository.
+A train holds at most about 10 items, or one review slot of glue. Cut the next
+train as soon as the previous one merges, or at least every 4 hours while ready
+items wait. Never hold the cut for work that is not yet ready; keep items blocked
+on a design decision, consumer proof, or another repository out.
 
 After the cut, nothing joins. Late deliveries go into the next candidate.
 Corrections needed to make the frozen candidate pass are not new deliveries;
 rerun the affected required gates for that changed code state.
 
-Record the cut and readiness estimates in one line in the reviewer comment,
-not the release note: `Cut with A and B; C waits for consumer proof.` Keep local
+Record the cut in one line in the reviewer comment, not the release note:
+`Cut with A and B; C waits for consumer proof.` Keep local
 coordination records under `.ai-work/`, never in public release text.
 
 ## Replace waits with local work
@@ -128,9 +133,17 @@ queued, do the next independent piece of work.
 - Prove against locally built packages instead of waiting for a release; see
   [cratis-engineering-local-cross-repo-verification](../cratis-engineering-local-cross-repo-verification/SKILL.md).
   Only the final version pin waits for the release.
-- Drop an item that has been stuck for about two hours rather than holding the
-  candidate; it joins the next one.
-- Cut a candidate at least every few hours with whatever is green.
+- Evict a stuck or failing item instead of holding the train (next section).
+- Cut a train at least every 4 hours with whatever is green.
+
+## Evict, don't hold
+
+If train CI or the glue review fails and the failure is attributable to one
+item, revert that item out of the train with a revert commit (never rewrite
+history), push once, ship the rest, and send the item to the next train after
+its fix. Diagnose an unattributable failure; never evict the whole train blindly.
+Merge as soon as CI is green and the review passed (majors stay with a human),
+then cut the next train. A train's gate and CI run on the real merged state.
 
 ## Apply the ship bar
 
@@ -143,9 +156,10 @@ making a speculative shipping push. Recheck the merge conditions after CI.
    reason why they do not apply. The assembled local gate is green. Required
    integration coverage follows repository policy and must pass before merge;
    name anything that cannot run locally rather than calling it a local pass.
-3. **Whole change reviewed.** The candidate has a completed review without
-   Blockers or missing required evidence. Targeted delivery reviews alone do
-   not satisfy this condition.
+3. **Reviewed.** Each item head is certified in the review log and the
+   train's glue review (merge resolutions, fix-ups, main-merge conflict
+   resolutions) completed without Blockers or missing required evidence. A
+   whole-change review is needed only for an item without a review-log entry.
 4. **Release decision settled.** Release intent follows `pull-requests.md`.
    For a major release, require explicit human confirmation and human merge.
    An agent never merges it; preparing the PR does not answer that checkpoint.
@@ -185,7 +199,7 @@ steps. The next session must recheck the ship bar, not blindly merge on green.
 
 ## What breaks
 
-- **One PR per delivery:** duplicate gates and fragmented releases replace an
+- **A PR per item or a delivery outside the train:** duplicate gates and fragmented releases replace an
   assembled check of the actual shipped change.
 - **A growing frozen candidate:** late work invalidates the gate and cut.
 - **Green means permitted:** checks neither resolve objections nor approve a
@@ -195,7 +209,7 @@ steps. The next session must recheck the ship bar, not blindly merge on green.
 
 Run the repository's exact assembled gate and inspect its successful exit.
 Run `gh pr checks <pr>` before merge: required checks must pass for the tested
-head. Confirm the whole-change review, fresh discussion, and main-overlap check.
+head. Confirm the review-log-certified items and glue review, fresh discussion, and main-overlap check.
 For release notes, execute the repository's `cratis-check-pr.mjs` command from
 `pull-requests.md`; a zero exit is the pass signal. No checklist replaces those
 behavioral and CI signals.

package/package/corpus/skills/cratis-engineering-review-rounds/SKILL.md

@@ -22,12 +22,25 @@ advisory preference is not a merge gate. Missing required evidence yields
 
 ## Budget the review
 
-- Run one quick round per delivery. A second is warranted only after a blocker,
-  not to seek reassurance or eliminate suggestions.
-- Run one whole-change review per PR on the assembled change. Quick delivery
-  rounds do not replace it. Start whole-change inspection in parallel with the
-  gate when possible, but keep it provisional: required gates must pass before
-  an approval report is finalized. Do not launch duplicate gates for review.
+- Review each branch whole once, the first time or when the coordinator orders
+  it; a second round only after a blocker, not to seek reassurance.
+- After that, review deltas only: from the last reviewed head in the review
+  log to the new head. A certified item is never re-reviewed whole.
+- For a release train, review glue only: recreate the merge of the certified
+  item heads and review `git diff <that merge> <train head>` (merge resolutions,
+  fix-ups; for main merges, the conflict resolutions). Item reviews are not an
+  integration pass; the train's gate and CI still run on the merged state.
+- Start review in parallel with the gate when possible, but keep it
+  provisional: required gates must pass before an approval report is finalized.
+  Do not launch duplicate gates for review.
+- Keep a review log at the path the coordinator names, default
+  `.ai-work/review-log.tsv` (ignored work area, configurable). Append one row per
+  attempt: repo, branch/PR, full base and head SHAs, run id, mode, ranges
+  covered, verdict (PASS / NOT PASS / INCOMPLETE), date. An attempt is always
+  recorded, but an unexamined partition never advances certified coverage.
+  Rerunning a missing partition at a later head covers its original base to head
+  range plus the new delta. An item is certified only with complete coverage, the
+  security lens run and blockers resolved; an incomplete slot is not a pass.
 - Use ordinary depth by default. Deep review needs one named risk class:
   **security**, **algorithmic**, **concurrency**, or **cross-cutting**, plus a
   one-line justification tied to the changed behavior. Data-loss exposure or
@@ -84,8 +97,8 @@ later completes a valid review.
 
 ## Delta rounds
 
-A delta round follows a whole-change review and reviews from the last reviewed
-SHA, not from an arbitrary base. Carry the prior Blockers, unresolved evidence
+A delta round is the default after a first whole review and reviews from the last
+reviewed SHA, not from an arbitrary base; take that SHA from the review log. Carry the prior Blockers, unresolved evidence
 gaps, Suggestions, and Dismissed findings with their reasons. Supply the round
 number, prior report, original base, last reviewed SHA, and new head explicitly.
 
@@ -106,8 +119,9 @@ unresolved findings and limits; a narrow delta cannot certify surfaces that
 were never examined. Reuse earlier approval only for the exact committed SHAs
 and examined scope, never for a dirty tree or a changed head. Dirty-tree feedback
 is preliminary, not reusable committed approval. Do not duplicate completed
-premium reviews or gates on unchanged exact reviewed scope; a bounded loop does
-not replace the final independent whole-change review or full required gates.
+premium reviews or gates on unchanged exact reviewed scope. Certified item
+coverage plus the train's glue or delta review replaces a repeat whole-change
+review; it never replaces the required gates, which run on the merged state.
 
 Do not start a follow-up round for advisory findings alone. Fix them only when
 cheap in an existing correction pass; otherwise leave them as Suggestions.

package/package/corpus/skills/cratis-engineering-review-rounds/verification.json

@@ -4,9 +4,11 @@
   "fixtures": [],
   "assertions": [
     { "kind": "skill-contains", "value": "../../rules/review-reports.md" },
-    { "kind": "skill-contains", "value": "Run one quick round per delivery" },
-    { "kind": "skill-contains", "value": "Run one whole-change review per PR" },
+    { "kind": "skill-contains", "value": "Review each branch whole once" },
+    { "kind": "skill-contains", "value": "review glue only" },
     { "kind": "skill-contains", "value": "SHA, not from an arbitrary base" },
+    { "kind": "skill-contains", "value": "covers its original base to head" },
+    { "kind": "skill-contains", "value": "an incomplete slot is not a pass" },
     { "kind": "skill-contains", "value": "Prior: <complete round 1 report, including dismissals and scope limits>" },
     { "kind": "skill-contains", "value": "3 rounds per work item" },
     { "kind": "skill-contains", "value": "Never file an issue merely to dispose of advisory feedback" },

package/package/corpus/skills/cratis-orchestration-lanes/references/context-handoff.md

@@ -59,7 +59,7 @@ Cap export retries at five and surface the final failure.
 
 ## Verified facts (with evidence)
 - Cap and spec committed: `git log -1` shows the SHA above.
-- Spec project passes: `dotnet test Source/Export.Specs` exit 0 at that SHA.
+- Spec project passes: `./Source/Export.Specs/bin/Debug/net10.0/Export.Specs` exit 0 at that SHA.
 - Pull request is open: `gh pr list --head export-retry` shows one entry; CI run
   `1234567890` is in progress.
 

package/package/corpus/skills/cratis-orchestration-lanes/references/lane-brief.md

@@ -60,12 +60,12 @@ C# rules.
 **Decisions already made:** the cap is five and is a constant, not
 configuration.
 
-**Gate command:** `dotnet test Source/Export.Specs`.
+**Gate command:** `./Source/Export.Specs/bin/Debug/net10.0/Export.Specs`.
 
 **Done =**
 - [ ] A failing upload stops after five attempts and reports the error
 - [ ] A spec covers the fifth failure and a success on the third attempt
-- [ ] `dotnet test Source/Export.Specs` exits 0
+- [ ] `./Source/Export.Specs/bin/Debug/net10.0/Export.Specs` exits 0
 - [ ] `git diff --stat` shows only the owned files
 
 **Stop and report if:** a public type must change, or another file needs edits.

package/package/corpus/skills/cratis-screenplay-render-and-gap-fill/references/delivery-protocol.md

@@ -33,8 +33,8 @@ per tool call and read each result from its exit status, never from a grep of th
 | Drift or pending-change check | the same command plus `--check` (and `--scope`, `--force` as used) | no write, no recovery: exit 0 current, 6 `changes_pending`, 5 planning failure, refusal or pending recovery |
 | Bundled-binder check | `cratis screenplay validate --executable <root>` | exit 5 with "does not bind into an executable semantic model" when it does not; never renders or writes. Uses the bundled compiler, not the standalone pin |
 | Debug build | `dotnet build <dir>/<Project>.csproj -c Debug` | the build's exit status |
-| Debug tests | `dotnet test <dir>/<Project>.csproj -c Debug --no-build` | the test runner's exit status plus per-test results |
-| List the generated classes | `dotnet test <dir>/<Project>.csproj -c Debug --no-build --list-tests` | the names to map to specifications |
+| Debug tests | `dotnet test <dir>/<Project>.csproj -c Debug --no-build` after the Debug build (Stage-rendered apps use VSTest) | the test runner's exit status plus per-test results |
+| List the generated classes | `dotnet test <dir>/<Project>.csproj -c Debug --no-build --list-tests` | the names to map to specifications; listing is not execution |
 
 `<Project>` is the project name the render used: the `--project-name` value when one was given,
 otherwise the application name. Confirm it from the published `*.csproj` in the destination

package/package/corpus/skills/cratis-screenplay-specifications/SKILL.md

@@ -284,8 +284,9 @@ For view specifications:
 ## Run the specs before calling the work done
 
 Symptom: a model delivered with specifications that were never run. `screenplay test <root>` runs the
-reference evaluator; after a render, run `dotnet test` (Debug) in the destination for the generated
-specification classes. Report both results separately (`cratis-screenplay-toolchain` V4 and V5.tests); a
+reference evaluator; after rendering and building in Debug, run `dotnet test <destination>/<Project>.csproj -c Debug --no-build`
+for the generated specification classes (Stage-rendered apps use VSTest). Run a built spec executable only where spec projects are executables
+(see [specs.csharp](../../rules/specs.csharp.md)). Report both results separately (`cratis-screenplay-toolchain` V4 and V5.tests); a
 build that succeeds is not a test run, and `unbound`/`unsupported` is not a pass.
 
 ## Verify
@@ -293,7 +294,7 @@ build that succeeds is not a test run, and `unbound`/`unsupported` is not a pass
 - [ ] Validate the complete root with warnings as errors, naming tool/version.
       Standalone tool version: `cratis-screenplay-toolchain/SKILL.md`. Run specification examples through
       `screenplay test`; expected unadmitted syntax reports unbound, not passed.
-- [ ] `screenplay test` and, after a render, `dotnet test` were run and their counts reported.
+- [ ] `screenplay test` and, after a Debug render and build, the `dotnet test` above were run and their counts reported.
 - [ ] Executable diagnostics are clean too: `PLAY0350`, `PLAY0352`, `PLAY0388`,
       `PLAY0389` and `PLAY0273` are only reported at binding.
 - [ ] Every slice has at least one boundary specification.

package/package/corpus/skills/cratis-screenplay-toolchain/references/fast-path.md

@@ -24,7 +24,7 @@ Run these in order and stop at the first failure; each step catches what the one
    run one create command and one query, and read the console for errors. The check is the app, not the build:
    a screen reported as `PLAY0269` (deferred from the backend profile, information only) is not evidence that
    it was rendered. List any authored screen that is absent as not rendered; do not call it delivered.
-10. **Specs:** `dotnet test` in `<dir>` (the generated specifications) and `screenplay test <root>`; see
+10. **Specs:** after the Debug build, `dotnet test <dir>/<Project>.csproj -c Debug --no-build` (Stage-rendered apps use VSTest) and `screenplay test <root>`; see
     `cratis-screenplay-specifications`.
 
 The rendered `README.md` repeats steps 6-8 for the pinned scaffold. Re-render and gap-fill rules:

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-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

@@ -241,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/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**.