@cratis/pi 7.124.0 → 7.125.1

package/package/corpus/agents/orchestrator.md

@@ -97,7 +97,8 @@ When you receive a goal:
 6. **Output a team plan** — always as a structured markdown checklist with agent assignments and phase labels.
 7. **Return or execute the plan** — default to a parent handoff; delegate only under the explicit large-scope contract.
 8. **Track overall progress** — after each phase, report what was completed and what remains.
-9. **Enforce scoped quality gates** — require relevant changed-lane evidence, not an unrelated full-code matrix.
+9. **Open the PR yourself, once** — sub-agents deliver verified branches and never open or push to PRs. Verify locally first, then open one PR for the whole scope with `--assignee @me`; do not open it early or keep pushing to it (see `pull-requests.md`).
+10. **Enforce scoped quality gates** — require relevant changed-lane evidence, not an unrelated full-code matrix.
 
 ---
 
@@ -107,6 +108,7 @@ When you receive a goal:
 - **Implementation before documentation** — documentation of new features must wait until the implementation is complete and reviewed.
 - **Build is a synchronisation point** — `dotnet build` must succeed before any frontend, spec, or documentation work that references generated proxies.
 - **Quality gates are always last** — code review and security review run after all implementation, specs, and documentation are complete.
+- **Cap local parallelism.** Delegated streams share this machine: limit each build and spec run (`dotnet -m:2`, `vitest --maxWorkers=2`), run one heavy phase at a time, and stagger parallel agents' builds so the machine stays responsive (see `verification-discipline.md`).
 - **Independent features** (no shared events) can be implemented in parallel via separate `planner` or `coordinator` invocations.
 
 ---

package/package/corpus/agents/spec-writer.md

@@ -94,7 +94,7 @@ public class and_all_information_is_valid : Specification
 
 ### What to specify
 
-0. **Every contract specification first** — one spec each, named after it, using the contract's example values. Then add the code-derived cases below that the contract lacks and report them as proposals for the contract (the `.play` model when one covers the slice, otherwise the agreed outline); never present them as contract coverage. A `.play` specification maps to a plain-call spec for a pure decision, with a scenario added only for the composition or application-owned race policy it proves; never edit, skip or delete a spec derived from the contract to make code pass — change the code or return an edit request.
+0. **Every contract specification first** — one spec each, named after it, using the contract's example values. Then add the code-derived cases below that the contract lacks and report them as proposals for the contract (the `.play` model when one covers the slice, otherwise the agreed outline); never present them as contract coverage. A `.play` specification maps to a plain-call spec for a pure decision, with a scenario added only for the pipeline composition it proves (never a simulated race); never edit, skip or delete a spec derived from the contract to make code pass — change the code or return an edit request.
 1. **Happy path** — succeeds, correct event(s) appended.
 2. **Each validation failure** — call the validator directly with supplied state; pipeline validation specs assert **both** `ShouldNotBeSuccessful()` and `ShouldHaveValidationErrors()`. Do not assert on message strings by default; assert exact text only when that wording is the specified behavior, and name that behavior in the fact. Violate **only** the rule the spec is named after (build the command valid in every other respect), or a neighbouring rule makes it pass.
 3. **Business-rule violations** — call `Handle()` or the validator directly with the required model state and assert each rejection. Arc/Chronicle specs alone prove platform concurrency, conflict refusal and isolation. The application's only decision-read spec obligation is the single cheap shape-admission spec in `specs.scenarios.csharp.md`; do not repeat guard scenarios per decision.

package/package/corpus/harnesses/copilot/instructions/application-profile.instructions.md

@@ -74,7 +74,7 @@ Tagged **[contract]** (framework-enforced) or **[convention]** (house default).
   3. **Code level** — infrastructure (hosting, DI composition, identity wiring, CI, deployment), clients, Screenplay code attachments and handlers, adapters in the render's customization area, and scope Stage cannot render yet (the model remains the contract). Framework repositories and brownfield work that is not opted in also stay code-first. Only the entry-point session may propose a model, at most once per session and never for trivial, bug-fix, infrastructure, client, framework or brownfield-maintenance work; if declined, do not ask again. Confirm Module/Feature, slice name, slice type and domain requirements as before; for new behavior or unclear event vocabulary run **cratis-chronicle-event-modeling** first, and record the agreed outline (fields, events, rules, scenarios) where the team tracks work, if anywhere. If you write code first where a model exists, say the model now lags.
   4. **Trivial changes** keep the proportional-delegation policy; Phases 1–3 below apply to code you write at either level.
 - **Phase 1 — Backend.** Implement a coherent slice change. **Gate:** incremental Debug build of the affected project (regenerates proxies, compiles `#if DEBUG` spec code).
-- **Phase 2 — Specs.** Mandatory for every slice type. Start with plain calls for pure command/validator/reducer decisions with supplied read-model state; add scenarios only for pipeline/authorization wiring, constraints, declarative mapping or application-owned race policies. Follow [specs.scenarios.csharp.md](./specs.scenarios.csharp.instructions.md) for shared setup and cost budgets. **Gate:** tests pass.
+- **Phase 2 — Specs.** Mandatory for every slice type. Start with plain calls for pure command/validator/reducer decisions with supplied read-model state; add scenarios only for pipeline/authorization wiring, constraints or declarative mapping. Follow [specs.scenarios.csharp.md](./specs.scenarios.csharp.instructions.md) for shared setup and cost budgets. **Gate:** tests pass.
 - **Phase 3 — Frontend.** Build from the generated proxies, register in the composition page, wire routing. **Gate:** lint, conditional test, build.
 
 **Backend before frontend, always** — the frontend depends on proxies that exist only after a successful build. Generate proxies from the **Debug** build (house convention); verify Release without re-running the generator: `dotnet build -c Release -p:CratisProxiesOutputPath=`. Why that property, and what to do when nothing is generated: the **cratis-arc-command** skill's proxy-generation reference.

package/package/corpus/harnesses/copilot/instructions/framework.instructions.md

@@ -50,6 +50,7 @@ Repo conventions follow from this: `Source/DotNET` + `Source/JavaScript` for dua
 - **Backward compatibility is a contract.** A change to a public type, attribute, interface, or generated-proxy shape is a breaking change for every downstream app — label PRs by semver impact (`major`/`minor`/`patch`) and treat removals/renames of public surface as `major`.
 - **Convention discovery is built here.** `IInstancesOf<T>` / `IImplementationsOf<T>`, attribute-based discovery, and source generation are the mechanisms the framework *provides*; use them internally too rather than hand-registration where a convention fits. A Fundamentals project reference does not carry the type-discovery analyzer like its NuGet package does: reference `Fundamentals.TypeDiscovery.Generator` explicitly, or your project's types may be absent from the generated universe.
 - **Source generators / analyzers** (Arc's proxy generator, Fundamentals) follow Roslyn conventions; their output is consumed verbatim by apps, so treat generated shape as public API.
+- **Analyzers and generators are written for speed** (fast feedback is a product requirement): incremental generators only; a syntactic prefilter (name or kind) before any semantic bind; compute shared evidence once per compilation, never once per analyzer or per symbol; touch it only after cheap relevance checks; never rebind every call site of the compilation. Each expensive analyzer gets a performance spec.
 - **Orleans grains** in the Chronicle kernel follow `orleans.md`.
 - **An alternate implementation of an interface must match the primary one's *semantics*, not just its signature.** Chronicle ships several implementations of the same storage interfaces (MongoDB, SQL, in-memory) and the in-memory ones exist precisely so the real kernel code paths can run without infrastructure. When you touch one, **diff it against the persistent implementations** — the signature tells you nothing about the contract. The specific trap: query criteria carry **sentinels meaning "do not narrow"** (`EventSourceId.Unspecified`, `EventSourceType.Unspecified`/`Default`, `EventStreamType.All`, `EventStreamId.Default`, an empty event-type set). Callers asking for "everything" pass those sentinels, never `null`, so a plain `is not null` check narrows every row away and the read silently returns nothing. A divergence here does not fail — it makes specs pass vacuously, which is worse.
 - **A stub that silently succeeds is a bug, not a placeholder.** An unimplemented method returning `Task.CompletedTask`/an empty result lets a spec assert on work that never happened. Implement it, or make it fail loudly — never leave it quietly lying.

package/package/corpus/harnesses/copilot/instructions/pull-requests.instructions.md

@@ -34,3 +34,4 @@ applyTo: "**/*"
 - Run `node .cratis/ai/hooks/scripts/cratis-check-pr.mjs --body-file <file> --label <intent>`; it applies the exact `policy / verify` release-note rules and the Bash hook runs it on `gh pr create` and `gh pr edit`. If it fails, fix the description, not the code. Before every body edit, run `git diff --stat origin/main...HEAD` and delete bullets the diff no longer supports.
 - Run the affected-project gates before marking work ready (`dotnet build`/`dotnet test` with zero warnings, `yarn lint`, `npx tsc -b`), and the repository's required CI checks after an authorized push. `no-release` and documentation-only PRs still satisfy every required check; none is a blanket exemption from red CI.
 - Group small related changes into one branch and one PR; see the skill for consolidation and the release-action windows.
+- Open the PR once, when verified: each push starts CI. One PR per body of work, opened by the orchestrator (`cratis-engineering-release-trains`), with `--assignee @me`.

package/package/corpus/harnesses/copilot/instructions/specs.csharp.instructions.md

@@ -12,7 +12,7 @@ Extends the base [specs.md](./specs.instructions.md) (folder structure, naming,
 
 > **Which spec surface?**
 > - **Framework / library code** (Chronicle kernel, Arc pipeline, source generators, Fundamentals): the `Specification` base + NSubstitute in this file is the dominant mode — unit-test the classes under test in isolation. Reach for a `*Scenario` helper (in [specs.scenarios.csharp.md](./specs.scenarios.csharp.instructions.md)) **only** when testing the very engine your repo provides — Arc → `CommandScenario`, Chronicle → the event/projection/reactor scenarios. The **cratis-application-slice-specifications** skill is application-oriented, not for general framework specs.
-> - **Event-sourced applications on Cratis** (commands, projections, reducers, reactors, constraints): use this base plus a direct call by default for pure `Handle()`, validator and reducer decisions with supplied read-model state; add scenarios only for pipeline/authorization wiring, constraints, declarative projections or application-owned race policies — see **[specs.scenarios.csharp.md](./specs.scenarios.csharp.instructions.md)** (`profile: application`) and the **cratis-application-slice-specifications** skill.
+> - **Event-sourced applications on Cratis** (commands, projections, reducers, reactors, constraints): use this base plus a direct call by default for pure `Handle()`, validator and reducer decisions with supplied read-model state; add scenarios only for pipeline/authorization wiring, constraints or declarative projections — see **[specs.scenarios.csharp.md](./specs.scenarios.csharp.instructions.md)** (`profile: application`) and the **cratis-application-slice-specifications** skill.
 
 `Cratis.Specifications` keeps the approach of Machine.Specifications (MSpec): `Establish → Because → should_` maps to "Given → When → Then" and keeps each spec focused on *one setup, one action, one set of assertions*.
 

package/package/corpus/harnesses/copilot/instructions/specs.scenarios.csharp.instructions.md

@@ -15,16 +15,16 @@ Specs are **mandatory for every slice type**, including reactors.
 
 ## Start with the plain call; add a scenario where it adds proof
 
-**Judgment-shaped convention:** call pure `Handle()`, validators, reducers and reactor decisions directly with their inputs, including read-model state. Add a scenario only for pipeline/authorization wiring, constraints, declarative projection mapping or an application-owned race policy. Do not repeat every decision through the pipeline; name the extra behavior each scenario proves.
+**Judgment-shaped convention:** call pure `Handle()`, validators, reducers and reactor decisions directly with their inputs, including read-model state. Add a scenario only for pipeline/authorization wiring, constraints or declarative projection mapping. Do not repeat every decision through the pipeline; name the extra behavior each scenario proves.
 
-**Application specs supply state, not decision-read infrastructure.** Call `Handle()` or the validator directly with supplied read-model state. Never call `UseDecisionReads`, configure protection modes, seed events solely for infrastructure, or re-prove the platform's concurrency, conflict-refusal or isolation matrix; Arc/Chronicle specs own it. The application's **only decision-read spec obligation** is one cheap assembly-level shape-admission spec: `DecisionReadAdmissions.ShouldAdmitDecisionReadsIn(assembly)` (`Cratis.Arc.Chronicle.Testing.Commands`). It checks the application's own models/projections without executing commands or running Chronicle, not the platform guards. An application-owned race policy may justify a scenario; assert its business outcome. Report harness state-setup gaps upstream; never weaken production guards for test speed.
+**Application specs supply state, not decision-read infrastructure.** Call `Handle()` or the validator directly with supplied read-model state. Never call `UseDecisionReads`, configure protection modes, seed events solely for infrastructure, or re-prove the platform's concurrency, conflict-refusal or isolation matrix; Arc/Chronicle specs own it. The application's **only decision-read spec obligation** is one cheap assembly-level shape-admission spec: `DecisionReadAdmissions.ShouldAdmitDecisionReadsIn(assembly)` (`Cratis.Arc.Chronicle.Testing.Commands`). It checks the application's own models/projections without executing commands or running Chronicle, not the platform guards. Never simulate competing appends either (`AppendConcurrently` or any hand-built interleaving): concurrency is a framework concern a developer should not think about in tests, and Arc and Chronicle specs prove it. A rule that must hold under races is expressed in production by taking the read model as a `Handle` parameter under `[ReadProtection(On)]`; the spec gives that read model's state and asserts the outcome. Report harness state gaps upstream; never weaken production guards for speed. `AppendConcurrently` is an advanced framework-verification API: use only for an explicit need. Direction, no release claim: Arc will obsolete `UseDecisionReads`.
 
 **Share setup and budget cost (judgment-shaped).** Keep shared lifecycle on; use `[PerFactSpecificationLifecycle]` only on a class whose facts genuinely mutate shared state and cannot move that mutation into `Because`. Plain decision specs should take roughly milliseconds; measure scenario facts and justify seconds by the extra behavior they prove. Compare TRX durations and suite wall time with unchanged concurrency; see [running-specs.md](../../../skills/cratis-specifications-csharp/references/running-specs.md). Do not multiply scenario startup by splitting assertions into classes or opting the project out of shared lifecycle.
 
 | Tool | Tests | Use when |
 |---|---|---|
 | `Specification` (plain call) | `Handle()`, `Handle(providedValue)`, validator/reducer logic or a reactor's decision as a method call; or an isolated class with mocked collaborators | **default** for a decision that is a pure function of its arguments |
-| `CommandScenario<TCommand>` | the real Arc command pipeline — authorization + validators + `Provide()` + `Handle()` + appended events | pipeline wiring, authorization, constraints or an application-owned race policy adds proof |
+| `CommandScenario<TCommand>` | the real Arc command pipeline — authorization + validators + `Provide()` + `Handle()` + appended events | pipeline wiring, authorization or constraints adds proof |
 | `QueryScenario<TReadModel>` | query pipeline: argument conversion, authorization, validation, interceptors; `Observe` buffers emissions | query composition matters; real MongoDB observations still need infrastructure |
 | `EventScenario` | Chronicle-level append semantics, no command pipeline | constraint violations, raw stream sequencing/concurrency |
 | `ReadModelScenario<TReadModel>` | projection/reducer state from a sequence of events (auto-detects model-bound / fluent / reducer) | one class per read model, many read-only assertions on shared setup |
@@ -121,7 +121,7 @@ arguments?, paging?, sorting?)`; `Observe(...)` returns `QueryObservation.Initia
 and buffered `Next()`. Configure principal/policies in `Services`; schemes fail
 closed without HTTP. Chronicle query `Given` can seed keyed models/events.
 
-For query setup and application-owned race policies, see **cratis-application-slice-specifications**,
+For query setup, see **cratis-application-slice-specifications**,
 `references/query-and-decision-scenarios.md`. Framework read-protection guards are not application spec obligations.
 
 ### `EventScenario` — constraints & append semantics

package/package/corpus/harnesses/copilot/instructions/verification-discipline.instructions.md

@@ -12,8 +12,10 @@ authored a file or preserve a chain of evidence about how it arrived.
 
 - Run the narrowest relevant build, type check, lint, and specifications while iterating; explain when a wider gate is required before completion or push/PR.
 - Run one phase per command with its real exit status. Budget targeted checks around 120 seconds and build/test phases around 300 seconds; explain any longer budget first, and obtain explicit approval before a phase exceeds 600 seconds. Stop on a failure; do not blindly retry or repeat passing tests on unchanged inputs without a flaky-test hypothesis or required matrix.
+- CI is not a feedback loop: run every gate locally before pushing. On a shared machine cap parallelism, one heavy phase at once (`cratis-engineering-ci-gates`).
 - Separate status/fetch from builds, Debug from Release, each test project, and frontend lint/compile/test/build. Do not combine these into an opaque command with a large outer timeout. Expose progress and cancellation; report the precise failed or timed-out phase and do not continue dependent phases after failure.
 - Never use `build/test | grep | sort/head/tail` as gate evidence. Capture the producer's exit status before summarising output; `pipefail` alone is insufficient with early-closing consumers such as `head`. Printed zero-error counts are not proof of success. Preserve needed full diagnostics in task-scoped `.ai-work/` logs rather than hiding them in `/tmp`.
+- Fast feedback is a product requirement: a spec takes milliseconds, the suite seconds; specs share setup and run in parallel; analyzers must not halt builds. CI builds the spec path without analyzers and enforces them, warnings as errors, in a parallel required job; the pre-push gate runs them. A slowdown is a defect.
 - Add a focused specification for every behavior or rejection rule you change.
 - Keep each check deterministic and runnable locally and in CI.
 - Never replace a real behavior check with a checksum, inventory, generated

package/package/corpus/harnesses/copilot/instructions/vertical-slices.instructions.md

@@ -21,7 +21,7 @@ This file is the reference for *what* goes in each part of a slice. Layout, slic
 
 - .NET / C# (ASP.NET Core) — **Cratis Arc** for CQRS / model-bound commands and queries, **Cratis Chronicle** for event sourcing, MongoDB or EF Core for read models.
 - React + TypeScript (Vite) — Cratis Components 4.x + Arc-generated proxies, MVVM. Vitest + Mocha/Chai/Sinon for frontend specs.
-- xUnit + Cratis.Specifications + NSubstitute for C# specs (`Specification` plus a direct call for pure command/validator/reducer decisions with supplied state; add scenarios only for pipeline/authorization wiring, constraints, declarative projections or application-owned race policies — see [specs.md](./specs.instructions.md)).
+- xUnit + Cratis.Specifications + NSubstitute for C# specs (`Specification` plus a direct call for pure command/validator/reducer decisions with supplied state; add scenarios only for pipeline/authorization wiring, constraints or declarative projections — see [specs.md](./specs.instructions.md)).
 
 ## Proxy generation — the build dependency
 

package/package/corpus/harnesses/pi/agents/orchestrator.md

@@ -93,7 +93,8 @@ When you receive a goal:
 6. **Output a team plan** — always as a structured markdown checklist with agent assignments and phase labels.
 7. **Return or execute the plan** — default to a parent handoff; delegate only under the explicit large-scope contract.
 8. **Track overall progress** — after each phase, report what was completed and what remains.
-9. **Enforce scoped quality gates** — require relevant changed-lane evidence, not an unrelated full-code matrix.
+9. **Open the PR yourself, once** — sub-agents deliver verified branches and never open or push to PRs. Verify locally first, then open one PR for the whole scope with `--assignee @me`; do not open it early or keep pushing to it (see `pull-requests.md`).
+10. **Enforce scoped quality gates** — require relevant changed-lane evidence, not an unrelated full-code matrix.
 
 ---
 
@@ -103,6 +104,7 @@ When you receive a goal:
 - **Implementation before documentation** — documentation of new features must wait until the implementation is complete and reviewed.
 - **Build is a synchronisation point** — `dotnet build` must succeed before any frontend, spec, or documentation work that references generated proxies.
 - **Quality gates are always last** — code review and security review run after all implementation, specs, and documentation are complete.
+- **Cap local parallelism.** Delegated streams share this machine: limit each build and spec run (`dotnet -m:2`, `vitest --maxWorkers=2`), run one heavy phase at a time, and stagger parallel agents' builds so the machine stays responsive (see `verification-discipline.md`).
 - **Independent features** (no shared events) can be implemented in parallel via separate `planner` or `coordinator` invocations.
 
 ---

package/package/corpus/harnesses/pi/agents/spec-writer.md

@@ -89,7 +89,7 @@ public class and_all_information_is_valid : Specification
 
 ### What to specify
 
-0. **Every contract specification first** — one spec each, named after it, using the contract's example values. Then add the code-derived cases below that the contract lacks and report them as proposals for the contract (the `.play` model when one covers the slice, otherwise the agreed outline); never present them as contract coverage. A `.play` specification maps to a plain-call spec for a pure decision, with a scenario added only for the composition or application-owned race policy it proves; never edit, skip or delete a spec derived from the contract to make code pass — change the code or return an edit request.
+0. **Every contract specification first** — one spec each, named after it, using the contract's example values. Then add the code-derived cases below that the contract lacks and report them as proposals for the contract (the `.play` model when one covers the slice, otherwise the agreed outline); never present them as contract coverage. A `.play` specification maps to a plain-call spec for a pure decision, with a scenario added only for the pipeline composition it proves (never a simulated race); never edit, skip or delete a spec derived from the contract to make code pass — change the code or return an edit request.
 1. **Happy path** — succeeds, correct event(s) appended.
 2. **Each validation failure** — call the validator directly with supplied state; pipeline validation specs assert **both** `ShouldNotBeSuccessful()` and `ShouldHaveValidationErrors()`. Do not assert on message strings by default; assert exact text only when that wording is the specified behavior, and name that behavior in the fact. Violate **only** the rule the spec is named after (build the command valid in every other respect), or a neighbouring rule makes it pass.
 3. **Business-rule violations** — call `Handle()` or the validator directly with the required model state and assert each rejection. Arc/Chronicle specs alone prove platform concurrency, conflict refusal and isolation. The application's only decision-read spec obligation is the single cheap shape-admission spec in `specs.scenarios.csharp.md`; do not repeat guard scenarios per decision.

package/package/corpus/prompts/ship-changes.prompt.md

@@ -14,7 +14,7 @@ branch → commits → PR → merge → issue disposition → cleanup workflow.
 ## Inputs
 
 - **What changed** — brief description of the work (used for branch name and PR title)
-- **Label** — exactly one of `no-release`, `patch`, `minor`, or `major`, selected from the repository's release contract and applied in `gh pr create --label <intent>`
+- **Label** — exactly one of `no-release`, `patch`, `minor`, or `major`, selected from the repository's release contract and applied in `gh pr create --label <intent> --assignee @me`
 - **Related issue** — optional exact repository and issue number; if unknown, search read-only first. Comment on or close it only when the user's request includes that effect; otherwise prepare the disposition as a proposal. In repositories released by `cratis/release-action`, a delivered issue is closed by release-action through `(#n)` in the description, but release-action does not run for a `no-release` PR, so `(#n)` closes nothing there; elsewhere follow the repository's own release and issue-closing process. Keep the issue current and close it with a reason per `cratis-engineering-issue-hygiene`.
 
 Invoking this prompt is direct authority for the standard branch, commit, push, pull-request,
@@ -41,6 +41,12 @@ another. The method is in the `cratis-engineering-release-trains` skill.
 
 ## Waiting on checks and merging
 
+Verify locally and open the PR once: CI is the final confirmation, not a feedback loop, so every
+gate runs on this machine first, with parallelism capped when other agents or builds share it
+(see `verification-discipline.md`). Do not open the PR early or keep pushing to it; each push
+starts checks on shared runners. Assign the PR to the user you run for with `--assignee @me`.
+When this prompt is run by an orchestrator or for sub-agent deliveries, the orchestrator opens the one PR.
+
 Push only when the ship bar is met: root cause understood, specs added, local gate green,
 review passed, issue and PR re-read, and no overlap with main. Then watch the exact run once
 instead of polling it. Merge only after required checks pass. The method is in the

package/package/corpus/rules/application-profile.md

@@ -73,7 +73,7 @@ Tagged **[contract]** (framework-enforced) or **[convention]** (house default).
   3. **Code level** — infrastructure (hosting, DI composition, identity wiring, CI, deployment), clients, Screenplay code attachments and handlers, adapters in the render's customization area, and scope Stage cannot render yet (the model remains the contract). Framework repositories and brownfield work that is not opted in also stay code-first. Only the entry-point session may propose a model, at most once per session and never for trivial, bug-fix, infrastructure, client, framework or brownfield-maintenance work; if declined, do not ask again. Confirm Module/Feature, slice name, slice type and domain requirements as before; for new behavior or unclear event vocabulary run **cratis-chronicle-event-modeling** first, and record the agreed outline (fields, events, rules, scenarios) where the team tracks work, if anywhere. If you write code first where a model exists, say the model now lags.
   4. **Trivial changes** keep the proportional-delegation policy; Phases 1–3 below apply to code you write at either level.
 - **Phase 1 — Backend.** Implement a coherent slice change. **Gate:** incremental Debug build of the affected project (regenerates proxies, compiles `#if DEBUG` spec code).
-- **Phase 2 — Specs.** Mandatory for every slice type. Start with plain calls for pure command/validator/reducer decisions with supplied read-model state; add scenarios only for pipeline/authorization wiring, constraints, declarative mapping or application-owned race policies. Follow [specs.scenarios.csharp.md](./specs.scenarios.csharp.md) for shared setup and cost budgets. **Gate:** tests pass.
+- **Phase 2 — Specs.** Mandatory for every slice type. Start with plain calls for pure command/validator/reducer decisions with supplied read-model state; add scenarios only for pipeline/authorization wiring, constraints or declarative mapping. Follow [specs.scenarios.csharp.md](./specs.scenarios.csharp.md) for shared setup and cost budgets. **Gate:** tests pass.
 - **Phase 3 — Frontend.** Build from the generated proxies, register in the composition page, wire routing. **Gate:** lint, conditional test, build.
 
 **Backend before frontend, always** — the frontend depends on proxies that exist only after a successful build. Generate proxies from the **Debug** build (house convention); verify Release without re-running the generator: `dotnet build -c Release -p:CratisProxiesOutputPath=`. Why that property, and what to do when nothing is generated: the **cratis-arc-command** skill's proxy-generation reference.

package/package/corpus/rules/framework.md

@@ -49,6 +49,7 @@ Repo conventions follow from this: `Source/DotNET` + `Source/JavaScript` for dua
 - **Backward compatibility is a contract.** A change to a public type, attribute, interface, or generated-proxy shape is a breaking change for every downstream app — label PRs by semver impact (`major`/`minor`/`patch`) and treat removals/renames of public surface as `major`.
 - **Convention discovery is built here.** `IInstancesOf<T>` / `IImplementationsOf<T>`, attribute-based discovery, and source generation are the mechanisms the framework *provides*; use them internally too rather than hand-registration where a convention fits. A Fundamentals project reference does not carry the type-discovery analyzer like its NuGet package does: reference `Fundamentals.TypeDiscovery.Generator` explicitly, or your project's types may be absent from the generated universe.
 - **Source generators / analyzers** (Arc's proxy generator, Fundamentals) follow Roslyn conventions; their output is consumed verbatim by apps, so treat generated shape as public API.
+- **Analyzers and generators are written for speed** (fast feedback is a product requirement): incremental generators only; a syntactic prefilter (name or kind) before any semantic bind; compute shared evidence once per compilation, never once per analyzer or per symbol; touch it only after cheap relevance checks; never rebind every call site of the compilation. Each expensive analyzer gets a performance spec.
 - **Orleans grains** in the Chronicle kernel follow `orleans.md`.
 - **An alternate implementation of an interface must match the primary one's *semantics*, not just its signature.** Chronicle ships several implementations of the same storage interfaces (MongoDB, SQL, in-memory) and the in-memory ones exist precisely so the real kernel code paths can run without infrastructure. When you touch one, **diff it against the persistent implementations** — the signature tells you nothing about the contract. The specific trap: query criteria carry **sentinels meaning "do not narrow"** (`EventSourceId.Unspecified`, `EventSourceType.Unspecified`/`Default`, `EventStreamType.All`, `EventStreamId.Default`, an empty event-type set). Callers asking for "everything" pass those sentinels, never `null`, so a plain `is not null` check narrows every row away and the read silently returns nothing. A divergence here does not fail — it makes specs pass vacuously, which is worse.
 - **A stub that silently succeeds is a bug, not a placeholder.** An unimplemented method returning `Task.CompletedTask`/an empty result lets a spec assert on work that never happened. Implement it, or make it fail loudly — never leave it quietly lying.

package/package/corpus/rules/general.md

@@ -13,7 +13,7 @@ Profile-specific rules declare a **`profile:`** in their frontmatter (`applicati
 
 > **Arc is a standalone CQRS framework — not bound to event sourcing.** Even within the application profile, Arc provides model-bound commands/queries, validation, authorization, and full-stack proxy generation, and works **without** Chronicle (Arc.Core does not depend on Chronicle). A `[Command]` `Handle()` does not *have* to append events — it can return a response, return `void`, or work through injected services. The event-sourcing behavior (a returned event gets appended; `EventForEventSourceId`; "never inject `IEventLog`") comes from the **Arc + Chronicle** integration. This application is event-sourced, so the slice guidance assumes event-sourced commands — read the event-centric rules as the *house default for this app*, not universal Arc laws.
 
-The framework is convention-over-configuration. **Idiomatic Cratis is the goal — not custom abstractions over it.** When something is unclear, prefer the Cratis convention; do not invent. The rules and skills under `.cratis/ai/` are the authoritative answer — if your question is not answered there, ask rather than inferring framework behavior from package internals.
+The framework is convention-over-configuration. **Idiomatic Cratis is the goal — not custom abstractions over it.** Always recommend the idiomatic way unless explicitly needed otherwise. When something is unclear, prefer the Cratis convention; do not invent. The rules and skills under `.cratis/ai/` are the authoritative answer — if your question is not answered there, ask rather than inferring framework behavior from package internals.
 
 ## Project Philosophy
 
@@ -52,6 +52,7 @@ obtaining credentials, and other local conventions ("Product policy" above).
 - Project context may explain which approved secret mechanism or local setup to
   use, but it must never contain credential values, tokens, keys, passwords, or
   other secrets.
+- A repository's accepted decision records (`decisions/`) and project rules bind AI work: read those matching your paths, follow them, never work around one.
 - Project-specific guidance wins when it deliberately narrows shared behavior,
   but it may not weaken organization security, authorization, or required
   quality gates.

package/package/corpus/rules/issue-assignment.md

@@ -10,3 +10,5 @@ unassigned. Never guess an issue/repository, replace an assignee or reopen a
 closed issue. Report assignment failures and continue. The request to work on
 the issue authorizes this claim only, not comments, labels or closure; follow
 [pull-requests.md](./pull-requests.md) and the user's request for those.
+
+Assign each PR you open to the same user: `gh pr create --assignee @me`.

package/package/corpus/rules/pull-requests.md

@@ -33,3 +33,4 @@ applyTo: "**/*"
 - Run `node .cratis/ai/hooks/scripts/cratis-check-pr.mjs --body-file <file> --label <intent>`; it applies the exact `policy / verify` release-note rules and the Bash hook runs it on `gh pr create` and `gh pr edit`. If it fails, fix the description, not the code. Before every body edit, run `git diff --stat origin/main...HEAD` and delete bullets the diff no longer supports.
 - Run the affected-project gates before marking work ready (`dotnet build`/`dotnet test` with zero warnings, `yarn lint`, `npx tsc -b`), and the repository's required CI checks after an authorized push. `no-release` and documentation-only PRs still satisfy every required check; none is a blanket exemption from red CI.
 - Group small related changes into one branch and one PR; see the skill for consolidation and the release-action windows.
+- Open the PR once, when verified: each push starts CI. One PR per body of work, opened by the orchestrator (`cratis-engineering-release-trains`), with `--assignee @me`.

package/package/corpus/rules/specs.csharp.md

@@ -11,7 +11,7 @@ Extends the base [specs.md](./specs.md) (folder structure, naming, philosophy) w
 
 > **Which spec surface?**
 > - **Framework / library code** (Chronicle kernel, Arc pipeline, source generators, Fundamentals): the `Specification` base + NSubstitute in this file is the dominant mode — unit-test the classes under test in isolation. Reach for a `*Scenario` helper (in [specs.scenarios.csharp.md](./specs.scenarios.csharp.md)) **only** when testing the very engine your repo provides — Arc → `CommandScenario`, Chronicle → the event/projection/reactor scenarios. The **cratis-application-slice-specifications** skill is application-oriented, not for general framework specs.
-> - **Event-sourced applications on Cratis** (commands, projections, reducers, reactors, constraints): use this base plus a direct call by default for pure `Handle()`, validator and reducer decisions with supplied read-model state; add scenarios only for pipeline/authorization wiring, constraints, declarative projections or application-owned race policies — see **[specs.scenarios.csharp.md](./specs.scenarios.csharp.md)** (`profile: application`) and the **cratis-application-slice-specifications** skill.
+> - **Event-sourced applications on Cratis** (commands, projections, reducers, reactors, constraints): use this base plus a direct call by default for pure `Handle()`, validator and reducer decisions with supplied read-model state; add scenarios only for pipeline/authorization wiring, constraints or declarative projections — see **[specs.scenarios.csharp.md](./specs.scenarios.csharp.md)** (`profile: application`) and the **cratis-application-slice-specifications** skill.
 
 `Cratis.Specifications` keeps the approach of Machine.Specifications (MSpec): `Establish → Because → should_` maps to "Given → When → Then" and keeps each spec focused on *one setup, one action, one set of assertions*.
 

package/package/corpus/rules/specs.scenarios.csharp.md

@@ -14,16 +14,16 @@ Specs are **mandatory for every slice type**, including reactors.
 
 ## Start with the plain call; add a scenario where it adds proof
 
-**Judgment-shaped convention:** call pure `Handle()`, validators, reducers and reactor decisions directly with their inputs, including read-model state. Add a scenario only for pipeline/authorization wiring, constraints, declarative projection mapping or an application-owned race policy. Do not repeat every decision through the pipeline; name the extra behavior each scenario proves.
+**Judgment-shaped convention:** call pure `Handle()`, validators, reducers and reactor decisions directly with their inputs, including read-model state. Add a scenario only for pipeline/authorization wiring, constraints or declarative projection mapping. Do not repeat every decision through the pipeline; name the extra behavior each scenario proves.
 
-**Application specs supply state, not decision-read infrastructure.** Call `Handle()` or the validator directly with supplied read-model state. Never call `UseDecisionReads`, configure protection modes, seed events solely for infrastructure, or re-prove the platform's concurrency, conflict-refusal or isolation matrix; Arc/Chronicle specs own it. The application's **only decision-read spec obligation** is one cheap assembly-level shape-admission spec: `DecisionReadAdmissions.ShouldAdmitDecisionReadsIn(assembly)` (`Cratis.Arc.Chronicle.Testing.Commands`). It checks the application's own models/projections without executing commands or running Chronicle, not the platform guards. An application-owned race policy may justify a scenario; assert its business outcome. Report harness state-setup gaps upstream; never weaken production guards for test speed.
+**Application specs supply state, not decision-read infrastructure.** Call `Handle()` or the validator directly with supplied read-model state. Never call `UseDecisionReads`, configure protection modes, seed events solely for infrastructure, or re-prove the platform's concurrency, conflict-refusal or isolation matrix; Arc/Chronicle specs own it. The application's **only decision-read spec obligation** is one cheap assembly-level shape-admission spec: `DecisionReadAdmissions.ShouldAdmitDecisionReadsIn(assembly)` (`Cratis.Arc.Chronicle.Testing.Commands`). It checks the application's own models/projections without executing commands or running Chronicle, not the platform guards. Never simulate competing appends either (`AppendConcurrently` or any hand-built interleaving): concurrency is a framework concern a developer should not think about in tests, and Arc and Chronicle specs prove it. A rule that must hold under races is expressed in production by taking the read model as a `Handle` parameter under `[ReadProtection(On)]`; the spec gives that read model's state and asserts the outcome. Report harness state gaps upstream; never weaken production guards for speed. `AppendConcurrently` is an advanced framework-verification API: use only for an explicit need. Direction, no release claim: Arc will obsolete `UseDecisionReads`.
 
 **Share setup and budget cost (judgment-shaped).** Keep shared lifecycle on; use `[PerFactSpecificationLifecycle]` only on a class whose facts genuinely mutate shared state and cannot move that mutation into `Because`. Plain decision specs should take roughly milliseconds; measure scenario facts and justify seconds by the extra behavior they prove. Compare TRX durations and suite wall time with unchanged concurrency; see [running-specs.md](../skills/cratis-specifications-csharp/references/running-specs.md). Do not multiply scenario startup by splitting assertions into classes or opting the project out of shared lifecycle.
 
 | Tool | Tests | Use when |
 |---|---|---|
 | `Specification` (plain call) | `Handle()`, `Handle(providedValue)`, validator/reducer logic or a reactor's decision as a method call; or an isolated class with mocked collaborators | **default** for a decision that is a pure function of its arguments |
-| `CommandScenario<TCommand>` | the real Arc command pipeline — authorization + validators + `Provide()` + `Handle()` + appended events | pipeline wiring, authorization, constraints or an application-owned race policy adds proof |
+| `CommandScenario<TCommand>` | the real Arc command pipeline — authorization + validators + `Provide()` + `Handle()` + appended events | pipeline wiring, authorization or constraints adds proof |
 | `QueryScenario<TReadModel>` | query pipeline: argument conversion, authorization, validation, interceptors; `Observe` buffers emissions | query composition matters; real MongoDB observations still need infrastructure |
 | `EventScenario` | Chronicle-level append semantics, no command pipeline | constraint violations, raw stream sequencing/concurrency |
 | `ReadModelScenario<TReadModel>` | projection/reducer state from a sequence of events (auto-detects model-bound / fluent / reducer) | one class per read model, many read-only assertions on shared setup |
@@ -120,7 +120,7 @@ arguments?, paging?, sorting?)`; `Observe(...)` returns `QueryObservation.Initia
 and buffered `Next()`. Configure principal/policies in `Services`; schemes fail
 closed without HTTP. Chronicle query `Given` can seed keyed models/events.
 
-For query setup and application-owned race policies, see **cratis-application-slice-specifications**,
+For query setup, see **cratis-application-slice-specifications**,
 `references/query-and-decision-scenarios.md`. Framework read-protection guards are not application spec obligations.
 
 ### `EventScenario` — constraints & append semantics

package/package/corpus/rules/verification-discipline.md

@@ -11,8 +11,10 @@ authored a file or preserve a chain of evidence about how it arrived.
 
 - Run the narrowest relevant build, type check, lint, and specifications while iterating; explain when a wider gate is required before completion or push/PR.
 - Run one phase per command with its real exit status. Budget targeted checks around 120 seconds and build/test phases around 300 seconds; explain any longer budget first, and obtain explicit approval before a phase exceeds 600 seconds. Stop on a failure; do not blindly retry or repeat passing tests on unchanged inputs without a flaky-test hypothesis or required matrix.
+- CI is not a feedback loop: run every gate locally before pushing. On a shared machine cap parallelism, one heavy phase at once (`cratis-engineering-ci-gates`).
 - Separate status/fetch from builds, Debug from Release, each test project, and frontend lint/compile/test/build. Do not combine these into an opaque command with a large outer timeout. Expose progress and cancellation; report the precise failed or timed-out phase and do not continue dependent phases after failure.
 - Never use `build/test | grep | sort/head/tail` as gate evidence. Capture the producer's exit status before summarising output; `pipefail` alone is insufficient with early-closing consumers such as `head`. Printed zero-error counts are not proof of success. Preserve needed full diagnostics in task-scoped `.ai-work/` logs rather than hiding them in `/tmp`.
+- Fast feedback is a product requirement: a spec takes milliseconds, the suite seconds; specs share setup and run in parallel; analyzers must not halt builds. CI builds the spec path without analyzers and enforces them, warnings as errors, in a parallel required job; the pre-push gate runs them. A slowdown is a defect.
 - Add a focused specification for every behavior or rejection rule you change.
 - Keep each check deterministic and runnable locally and in CI.
 - Never replace a real behavior check with a checksum, inventory, generated

package/package/corpus/rules/vertical-slices.md

@@ -20,7 +20,7 @@ This file is the reference for *what* goes in each part of a slice. Layout, slic
 
 - .NET / C# (ASP.NET Core) — **Cratis Arc** for CQRS / model-bound commands and queries, **Cratis Chronicle** for event sourcing, MongoDB or EF Core for read models.
 - React + TypeScript (Vite) — Cratis Components 4.x + Arc-generated proxies, MVVM. Vitest + Mocha/Chai/Sinon for frontend specs.
-- xUnit + Cratis.Specifications + NSubstitute for C# specs (`Specification` plus a direct call for pure command/validator/reducer decisions with supplied state; add scenarios only for pipeline/authorization wiring, constraints, declarative projections or application-owned race policies — see [specs.md](./specs.md)).
+- xUnit + Cratis.Specifications + NSubstitute for C# specs (`Specification` plus a direct call for pure command/validator/reducer decisions with supplied state; add scenarios only for pipeline/authorization wiring, constraints or declarative projections — see [specs.md](./specs.md)).
 
 ## Proxy generation — the build dependency
 

package/package/corpus/skills/cratis-application-slice-specifications/SKILL.md

@@ -12,7 +12,7 @@ Start a pure decision with a plain method call: `Handle()`,
 `Handle(providedValue)`, reducer logic or a reactor's decision needs no host,
 services or harness, including direct validator calls with supplied read-model state.
 Add scenarios only for pipeline/authorization wiring, constraints, declarative
-mapping or application-owned race policies; follow the
+mapping; follow the
 [scenario selection and cost rule](../../rules/specs.scenarios.csharp.md). The scenario family
 exercises the real Arc and Chronicle code paths in-process — no HTTP, no fixture,
 no server.
@@ -207,14 +207,15 @@ do not replay a projection merely to feed a pure command decision.
 Both builder methods return `void`; there is nothing to await.
 
 Read protection is invisible to application spec authors. Never configure modes,
-call `UseDecisionReads`, seed events solely for infrastructure, or re-prove
-the platform concurrency/guard matrix. Keep one cheap assembly-level
+call `UseDecisionReads`, simulate competing appends (`AppendConcurrently`), seed
+events solely for infrastructure, or re-prove the platform concurrency/guard
+matrix: give state, assert the outcome. Keep one cheap assembly-level
 `DecisionReadAdmissions.ShouldAdmitDecisionReadsIn(assembly)` spec for the
 application's own model/projection shapes: its only decision-read spec obligation.
 If the harness cannot accept required state, report the upstream gap; never weaken
 production guards for test speed. Read
 [query and decision scenarios](references/query-and-decision-scenarios.md) for
-query pipelines and application-owned race policies.
+query pipelines.
 
 Validator and `Provide()` dependencies are registered in `_scenario.Services`;
 the concrete validator itself is discovered automatically.

package/package/corpus/skills/cratis-application-slice-specifications/references/query-and-decision-scenarios.md

@@ -3,7 +3,7 @@
 ## Contents
 
 - Query pipeline
-- Application-owned race policies
+- Decision specifications
 - Sources
 
 <!-- Copyright (c) Cratis. All rights reserved. -->
@@ -67,7 +67,7 @@ execution runs the query through Arc's hosted query pipeline and establishes con
 before `Provide`/`Handle` on the command path. A direct static query call does not
 cover those pipeline hooks.
 
-## Application-owned race policies
+## Decision specifications
 
 Start with a direct decision call supplied with read-model state. Follow the
 [scenario rule](../../../rules/specs.scenarios.csharp.md): application authors do
@@ -89,22 +89,20 @@ method bodies are not statically discovered. If the harness cannot accept
 required state for a business decision, report the upstream gap; never weaken
 production guards or invent guard doubles.
 
-Add a `CommandScenario<TCommand>` only when the application owns a race policy:
-for example, two callers reserving the last seat must produce one reservation
-and the specified rejection or retry outcome. Name that business contract and
-assert it, rather than repeating the platform's generic stale-read tests.
+Do not add a scenario to prove a race. A rule such as "two callers reserving the last
+seat yield one reservation" is specified from state: supply a read model with no seats
+left and assert the rejection, then supply one seat and assert the reservation.
+Simulating competing appends is a framework concern a developer should not think
+about in tests; Arc and Chronicle prove it. `AppendConcurrently` stays a public but
+advanced framework-verification API (hidden from IntelliSense), outside application
+testing guidance; use it only for a specific, explicit need. Production expresses
+the guarantee with the read model as a `Handle` parameter under
+`[ReadProtection(On)]`. Direction, not a release claim: Arc will obsolete
+`UseDecisionReads`; do not adopt it.
+`ShouldHaveCompletedStream(ClosedStreamScope)` may assert that a decision completed a
+stream at the exact source and route (`Cratis.Arc.Chronicle.Testing.Commands`).
 Use event history only when it is part of the domain example.
 
-For an application-owned race/retry policy only, `AppendConcurrently(id, events...)`
-(or its routed overload) can supply controlled interference. It is not required
-for every guarded decision. Requires Arc 22.92.0 without explicit decision-read
-setup; older limitations are upgrade/report concerns, not application setup
-instructions. A competing append alone proves no policy: assert the intended
-business outcome and ensure the decision would otherwise append.
-`ShouldHaveCompletedStream(ClosedStreamScope)` can assert an application-owned
-completion outcome at the exact source and route. These APIs are in
-`Cratis.Arc.Chronicle.Testing.Commands`.
-
 The Chronicle-backed `CommandScenario` discovers constraints automatically.
 Assert domain constraint refusals instead of disabling them; use `EventScenario`
 for append-time uniqueness examples. Do not subclass or substitute its engine.

package/package/corpus/skills/cratis-arc-command/SKILL.md

@@ -276,7 +276,7 @@ Components guidance, not to this skill.
 
 Start pure `Handle()` and validator decisions with direct calls and supplied
 read-model state. Add scenarios only for pipeline/authorization wiring,
-constraints or application-owned race policies, not read-protection plumbing;
+constraints, never read-protection plumbing or simulated concurrency;
 follow the [scenario selection and cost rule](../../rules/specs.scenarios.csharp.md).
 
 - The command is a `record`, carries `[Command]`, and declares a public instance

package/package/corpus/skills/cratis-arc-command/references/decisions-and-routing.md

@@ -15,6 +15,13 @@ Source: Arc. These features require `Cratis.Arc.Chronicle`.
 
 ## Pick the guarded read
 
+**Idiomatic default:** a state-dependent rule takes the read model as a `Handle()`
+(or validator-constructor) parameter, with `[ReadProtection(On)]` where it must hold
+under concurrent writers. Do not take `IDecisionReads` in `Handle()`: it is not
+recommended with Arc and is not an investment target. A computed key stays in
+`Provide()` until a read-model parameter covers it. Direction, not a release claim:
+Arc will pin protected parameters so the idiomatic shape needs no further ceremony.
+
 Under read protection `On` (`<CratisReadProtection>On</CratisReadProtection>`, or
 `[ReadProtection(ReadProtectionMode.On)]` on a command), a read model that is a
 parameter of `Handle()` or of a `CommandValidator<T>` constructor is read fresh from
@@ -178,19 +185,18 @@ source id/type and stream route; reactor tuples/collections cannot mix it with e
 Call `Handle()` and validators directly with read-model state for pure business
 decisions. Follow the [scenario rule](../../../rules/specs.scenarios.csharp.md):
 read-protection plumbing is invisible to application spec authors. They never
-call `UseDecisionReads`, configure modes, seed events solely for infrastructure,
-or re-prove the platform concurrency, conflict-refusal or isolation matrix;
+call `UseDecisionReads`, configure modes, simulate competing appends
+(`AppendConcurrently`), seed events solely for infrastructure, or re-prove the platform concurrency, conflict-refusal or isolation matrix;
 Arc/Chronicle specs own it. The application's only decision-read spec obligation
 is one cheap assembly-level shape-admission spec from that rule.
 Never weaken production guards for test speed. Report a harness state-setup gap
 upstream instead of working around it in application specs.
 
-Add scenarios for pipeline/authorization wiring, constraints or an application-owned
-race policy. Name the domain outcome (for example, one successful reservation and
-one rejection), not the generic guard behavior. Read
+Add scenarios for pipeline/authorization wiring or constraints. Never simulate
+competing appends: assert the business outcome from supplied state (for example, no
+copies left rejects). Read
 [query and decision scenarios](../../cratis-application-slice-specifications/references/query-and-decision-scenarios.md)
-for controlled interference and completion assertions. Keep shared lifecycle on
-and measure the added cost.
+for the query and decision setup. Keep shared lifecycle on and measure the added cost.
 
 ## Sources
 

package/package/corpus/skills/cratis-arc-command-validation/SKILL.md

@@ -268,10 +268,10 @@ authorization and camelCase member paths are separate contracts.
 
 Every rule gets a failure specification: instantiate the validator with its
 read-model state and validate directly, asserting the specific rejection. Add
-`CommandScenario<TCommand>` only for pipeline/authorization wiring, constraints
-or an application-owned race policy. Follow the
+`CommandScenario<TCommand>` only for pipeline/authorization wiring, constraints.
+Follow the
 [scenario rule](../../rules/specs.scenarios.csharp.md): application specs never
-configure read-protection modes, call `UseDecisionReads`, seed events solely for
+configure read-protection modes, call `UseDecisionReads`, simulate competing appends, seed events solely for
 infrastructure, or re-prove platform guards. Keep the single cheap assembly-level
 application-shape admission spec specified by that rule; it is the application's
 only decision-read spec obligation. Report harness gaps upstream; never weaken

package/package/corpus/skills/cratis-chronicle-decision-reads/SKILL.md

@@ -199,5 +199,5 @@ deciding writer is guarded or the rule is a constraint.
   changes, absence guards, empty checked appends, isolation and commit lifecycle.
   Their real-client/kernel integration proves the boundary; a default
   `EventScenario` scope strategy returning `None` is not concurrency evidence.
-- An application-owned race/retry policy may justify a focused scenario, not
-  repetition of that matrix. Never weaken production guards for spec speed.
+- Application specs never simulate competing appends or repeat that matrix.
+  Never weaken production guards for spec speed.

package/package/corpus/skills/cratis-chronicle-decision-reads/references/choosing-how-a-rule-holds.md

@@ -316,12 +316,11 @@ assembly-level `DecisionReadAdmissions.ShouldAdmitDecisionReadsIn(assembly)`
 check of its own models/projections, not per-decision scenarios. Production
 protection stays unchanged regardless of spec cost.
 
-A scenario is justified for an application-owned race policy: for example, two
-borrowers competing for the last copy must yield one loan and the specified
-rejection or retry. Assert that domain outcome, not the engine's generic append
-conditions. See [query and decision scenarios](../../cratis-application-slice-specifications/references/query-and-decision-scenarios.md)
-for controlled interference. If the harness cannot accept required state, report
-the upstream gap rather than adding infrastructure setup to application specs.
+Do not simulate competing appends in an application spec, even for a rule such as
+two borrowers competing for the last copy. Give the state (no copies left) and assert
+the domain outcome (rejected); the guarantee that only one wins is proven by Arc and
+Chronicle. If the harness cannot accept required state, report the upstream gap
+rather than adding infrastructure setup to application specs.
 
 ## Costs
 

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

@@ -144,10 +144,14 @@ handle it. Pitfall: without `merge_group` the required check never reports in th
 queue. Read `references/required-checks-and-path-filters.md`.
 
 **Compile once, analyze once.** Fits any workflow where one push compiles the same
-code several times. Default: build once and reuse the output; run analyzers in one
-parallel lint job instead of in every build, and let that job fail early on compile
-and analyzer errors before long test legs. Pitfall: dropping analyzers from the only
-build that consumers enforce. Read `references/test-setup-cost.md`.
+code several times. Default: build the spec path without analyzers
+(`-p:RunAnalyzers=false`) and reuse the output; enforce every analyzer with warnings
+as errors in one parallel **required** job that fails early on compile and analyzer
+errors, while the local fast loop may skip analyzers and the pre-push gate runs them.
+Pitfall: dropping analyzers from the only build that consumers enforce, or leaving
+the analyzer job out of the required checks. Measure analyzer cost per rule before
+and after (binlog analyzer timings), and fix a slow analyzer at its source rather
+than switching it off. Read `references/test-setup-cost.md`.
 
 **Cores per job before job count.** Fits uniformly slow jobs. Default: check `nproc`
 and the runner's resources before sharding; undersized runners make every job slow.

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

@@ -11,6 +11,7 @@ a suite re-tests a dependency, or when compile errors surface late.
 - Test each guarantee where it can break
 - Surface compile errors early
 - Count compiles per push
+- Analyzer cost
 
 ## Time hidden outside per-test timing
 
@@ -80,3 +81,17 @@ Each extra compile is avoidable: build once, reuse the output (see
 `build-once-and-shard.md`). Analyzers can roughly double compile time; run them once
 in a parallel lint job and disable them in the shared build, while keeping the
 strictest configuration that consumers enforce somewhere on the required path.
+
+## Analyzer cost
+
+Analyzers that run in the spec path stall every build. Take per-analyzer timings
+from a binlog of the slow project, with the same inputs and concurrency before and
+after. Rank by cumulative time per rule, not by assembly. Three results are
+typical: rules that cannot apply to the repository (switch them off; a bulk
+severity setting can run an analyzer whose own rules are `none`), an analyzer that
+rebinds the whole compilation (fix it upstream: syntactic prefilter, evidence
+computed once per compilation, touched only after cheap relevance checks), and
+generators, which are rarely the cost. In one measured application, compiling with
+analyzers took 395 s, 180 s after removing inapplicable rules, and 90 s with
+analyzers off. Pass means the spec-path build skips analyzers, the parallel
+required job still fails on any analyzer warning, and both timings are recorded.

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

@@ -17,7 +17,7 @@ See [commits.md](./commits.md) for logical grouping, message format and staging
 
 Confirm the current repository workflow contract before selecting release intent because release-intent labels can trigger publication. A direct request to ship with a named label authorizes applying that label and completing the repository's standard pull-request workflow, including the release it normally triggers. Do not ask for separate authorization at each step. If the user did not request shipping or publication, a proposed semantic label describes impact but does not grant authority.
 
-- Exactly one of `major`/`minor`/`patch`/`no-release`, set in the creating command (`gh pr create --label patch`), in every repository, including samples, docs and tooling repositories (`no-release` when nothing is shipped). To change intent, swap labels in one command: `gh pr edit <n> --remove-label minor --add-label patch`. Never add a second: with more than one of them, release-action releases nothing and reports `reason=error`. Re-running a `pull_request` workflow replays the original label payload, so fix a label mistake by editing the PR or pushing; a `workflow_dispatch` run needs an explicit `version` and the PR description as `release-notes`, and without notes it closes no issues.
+- Exactly one of `major`/`minor`/`patch`/`no-release`, set in the creating command (`gh pr create --label patch --assignee @me`), in every repository, including samples, docs and tooling repositories (`no-release` when nothing is shipped). To change intent, swap labels in one command: `gh pr edit <n> --remove-label minor --add-label patch`. Never add a second: with more than one of them, release-action releases nothing and reports `reason=error`. Re-running a `pull_request` workflow replays the original label payload, so fix a label mistake by editing the PR or pushing; a `workflow_dispatch` run needs an explicit `version` and the PR description as `release-notes`, and without notes it closes no issues.
 - Dependabot PRs carry only `no-release`. release-action never releases them, and the `major`/`minor`/`patch` Dependabot adds describe the dependency's version, not this product's.
 - Label the PR according to semantic versioning impact:
   - **major**: breaking changes to public APIs

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

@@ -72,6 +72,23 @@ do not run dependent phases or hide a producer's exit status behind a filter.
 Report the exact command and result. Put verification and deferred coverage in
 reviewer comments, not the release-note description.
 
+## Local first, and resource-aware
+
+CI is the final confirmation before merge and deploy, never a feedback loop.
+Run build, specifications, lint and frontend gates locally until green, then
+push. Do not push to see whether something compiles or passes, and do not use
+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`.
+- 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
+  checkout; wait or lower the cap, and do not retry a starved or timed-out phase
+  at full parallelism.
+
 ## Wait without polling
 
 After an authorized push, capture the full head SHA and discover the run for the

package/package/corpus/skills/cratis-engineering-issue-hygiene/SKILL.md

@@ -38,6 +38,9 @@ Before starting, read the issue, comments, assignees and any status block. Follo
 - Do this once, at the start before the first edit, not on every turn. If it
   fails (permissions or authentication), report it and continue with the work.
 
+Assign each PR you open the same way: `gh pr create --assignee @me`, or
+`gh pr edit <n> --add-assignee @me` afterwards.
+
 The request to work on the issue authorizes this assignment only, not comments,
 labels or closure. If another writer is active, coordinate rather than starting
 a parallel edit. Delegated workers do not claim or mutate the issue.

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

@@ -34,6 +34,16 @@ Use `cratis-engineering-consolidation-guard` when folding existing PRs to prove
 nothing was dropped. Use `cratis-engineering-ci-gates` for gate selection and
 run handling, and `cratis-engineering-review-rounds` for proportionate review.
 
+## Open the PR once
+
+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
+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.
+
 ## Choose the candidate before creating a PR
 
 1. Inspect the repository's worktrees, finished branches, and open PRs:

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

@@ -13,7 +13,7 @@ of contents, and each file states one setup, one action, and one or more
 focused assertions.
 
 Read [query and decision scenarios](../cratis-application-slice-specifications/references/query-and-decision-scenarios.md)
-when specifying query emissions or application-owned race policies.
+when specifying query emissions.
 Follow the [scenario selection and cost rule](../../rules/specs.scenarios.csharp.md):
 application specs supply read-model state and test business decisions, never
 read-protection plumbing. `Perform`/`Observe` need configured services/principal;
@@ -90,8 +90,7 @@ before changing runner or package family.
 The plain `Specification` base is the universal foundation and the dominant mode
 in library and framework code. In applications, start pure decisions with a
 plain call, including direct validator calls, and add scenarios only for
-pipeline/authorization wiring, constraints, declarative mapping or application-owned
-race policies. Keep shared lifecycle on; measure scenario cost using
+pipeline/authorization wiring, constraints, or declarative mapping. Keep shared lifecycle on; measure scenario cost using
 [running-specs.md](references/running-specs.md). Read
 [application-scenarios.md](references/application-scenarios.md) before using
 one. Out-of-process integration specifications are an advanced case reserved for

package/package/corpus/skills/cratis-specifications-csharp/references/application-scenarios.md

@@ -10,18 +10,18 @@
 
 The four scenario helpers exercise the real Arc and Chronicle pipelines
 in-process. Follow the [scenario selection and cost rule](../../../rules/specs.scenarios.csharp.md):
-use them for pipeline/authorization wiring, constraints, declarative mapping or an
-application-owned race policy; specify pure `Handle()`, validator, reducer and
+use them for pipeline/authorization wiring, constraints, or declarative mapping;
+specify pure `Handle()`, validator, reducer and
 reactor decisions first as plain calls with supplied read-model state. A library or framework repository reaches for a scenario only to test the
 very engine it provides.
 
 Read [query and decision scenarios](../../cratis-application-slice-specifications/references/query-and-decision-scenarios.md)
-when using `QueryScenario<T>`, buffered emissions or application-owned race policies.
+when using `QueryScenario<T>`, or buffered emissions.
 Read-protection plumbing is the harness's responsibility, never application setup.
 
 | Helper | Exercises | Use for |
 | --- | --- | --- |
-| `CommandScenario<TCommand>` | Authorization, validators, `Provide()`, `Handle()`, appended events | Pipeline wiring, authorization, domain constraints/race policies |
+| `CommandScenario<TCommand>` | Authorization, validators, `Provide()`, `Handle()`, appended events | Pipeline wiring, authorization, domain constraints |
 | `QueryScenario<TReadModel>` | Argument conversion, authorization, validation, interceptors and buffered observations | Query pipeline behavior |
 | `EventScenario` | Chronicle append semantics without the command pipeline | Domain constraints; raw engine guards belong in framework specs |
 | `ReadModelScenario<TReadModel>` | Projection or reducer state from a sequence of events | Declarative mapping/wiring, one class per model |

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

@@ -63,7 +63,7 @@ project on its own; `dotnet test` on the whole solution does not work there.
 Apply the [scenario cost budget](../../../rules/specs.scenarios.csharp.md): plain
 decision specs should take roughly milliseconds, not seconds. Measure scenario
 facts and justify their cost by pipeline/authorization wiring, constraints,
-declarative mapping or an application-owned race policy that a plain call cannot
+or declarative mapping that a plain call cannot
 prove. Prefer fewer startups, not fewer assertions or weaker production guards.
 
 Capture TRX for the affected project before and after the change. With VSTest,

package/package.json

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