@cratis/pi 7.125.2 → 7.126.0

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

@@ -46,13 +46,13 @@ Select from these canonical rules in `.cratis/ai/rules/` only after applying the
 
 ## C# specs — start with the plain call
 
-Specify pure `Handle()`, validator, reducer and reactor decisions with plain calls and supplied read-model state. Follow `.cratis/ai/rules/specs.scenarios.csharp.md`: scenarios add only pipeline/authorization wiring, constraints, declarative mapping or application-owned race-policy proof, not a platform guard matrix. Keep the single cheap assembly-level admission spec for the application's own decision-model shapes. Prefer in-process helpers over out-of-process Chronicle hosts for the applicable behaviors:
+Specify pure `Handle()`, validator, reducer and reactor decisions with plain calls and supplied read-model state. Follow `.cratis/ai/rules/specs.scenarios.csharp.md`: add exactly the scenarios its per-artifact decision table obligates (pipeline and authorization, constraints, projection and reducer dispatch, reactor dispatch and routing) plus application-owned race-policy proof, not a platform guard matrix. Keep the single cheap assembly-level admission spec for the application's own decision-model shapes. Prefer in-process helpers over out-of-process Chronicle hosts for the applicable behaviors:
 
 | Tool | Use for |
 |---|---|
 | `CommandScenario<TCommand>` | **State Change** — runs authorization + validators + `Provide()` + `Handle()` + appended events |
 | `EventScenario` | constraint violations, raw append/sequencing semantics |
-| `ReadModelScenario<TReadModel>` | **State View** — one class per read model, many read-only assertions on shared setup |
+| `ReadModelScenario<TReadModel>` | **State View** — one class per read model by default (another only for a sequence that cannot share it), many read-only assertions on shared setup |
 | `ReactorScenario<TReactor>` | **Automation / Translation** — reactor invocation + side effects |
 
 Reserve out-of-process integration specs for host/transport/infra boundaries the scenario helpers can't exercise.

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 or declarative mapping. 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 the scenarios the decision table in [specs.scenarios.csharp.md](./specs.scenarios.csharp.instructions.md) obligates, and follow it 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/fast-feedback.instructions.md

@@ -0,0 +1,37 @@
+---
+applyTo: "**/for_*/**,**/when_*/**,**/*.csproj,**/Directory.Build.props,**/Directory.Build.targets,**/*.Specs/**,**/.github/workflows/**"
+paths:
+  - "**/for_*/**"
+  - "**/when_*/**"
+  - "**/*.csproj"
+  - "**/Directory.Build.props"
+  - "**/Directory.Build.targets"
+  - "**/*.Specs/**"
+  - "**/.github/workflows/**"
+---
+<!-- cratis-ai: generated Copilot instructions. Do not edit; rules/ is the source. -->
+
+# Fast feedback is a product requirement
+
+Applies to every Cratis repository and every application built on Cratis. A build and a spec run are
+measured in seconds. Each line is tagged **[contract]** (binding) or **[convention]** (the house
+default) per [`general.md`](../../../rules/general.md).
+
+- **[contract] Building and running specs is as fast as possible, locally and in CI.** A change
+  that makes a build or a spec run slower is a regression: measure it (cold full-suite wall time
+  plus a focused single-folder loop) and fix it in the same change.
+- **[contract] Every spec is safe to run in parallel with every other spec.** No shared mutable
+  static state, no ordering assumptions, no fixed ports, paths or names that two specs could both
+  claim. Never serialize a suite or opt out of shared setup to hide an isolation bug.
+- **[contract] No per-spec startup cost for convenience.** Setup is built once and shared
+  (shared lifecycle stays on). Slow setup in a framework harness is fixed in the framework and
+  reported upstream; do not work around it by merging unrelated assertions or skipping specs.
+- **[contract] Analyzers and generators are cheap or they are not added.** A slow one is an
+  upstream issue; see [`framework.md`](./framework.instructions.md) for how analyzers are written for speed.
+- **[convention] Specify with the cheapest proof that is real.** Call a pure decision directly;
+  use a scenario for what only the framework pipeline or engine proves. The per-artifact table is in
+  [`specs.scenarios.csharp.md`](./specs.scenarios.csharp.instructions.md); the universal base is in
+  [`specs.md`](./specs.instructions.md).
+
+A cold full-suite run under a minute is the target for a repository's spec gate. It is a budget to
+protect, not a reason to delete coverage.

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 or declarative projections — 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 the scenarios its per-artifact decision table obligates — 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.instructions.md

@@ -98,13 +98,19 @@ The goal is to cover *decisions and transformations* — code where bugs hide. S
 
 **Avoid file names starting with:** `when_getting_*`, `when_returning_*` — if a spec name starts with "getting" or "returning", it's probably testing a simple getter, which is not worth specifying.
 
+## Choosing the harness
+
+Call the code. A function whose result depends only on its arguments is specified by calling it with those arguments and asserting the result: no host, container or harness. Use a harness (scenario, fixture, in-memory engine) for behavior that exists only in the framework: discovery, attribute- or convention-driven wiring, authorization, persistence-time rules and declarative mappings. Name each such spec after the wiring it proves, and do not repeat through the harness a decision a plain call already proves.
+
+Substitute collaborators (a service, a clock, a sender) freely in a plain call. Never substitute the event store, a read-model store or the pipeline as proof of persistence, projection or pipeline behavior: either make the code a pure function of its inputs, or keep the harness. Harness coverage is an obligation per behavior the framework owns, not a quota. Fast, parallel-safe harnesses are required by [fast-feedback.md](./fast-feedback.instructions.md).
+
 ## Multiple Outcomes
 
 Each distinct outcome deserves its own spec file. This keeps specs small, focused, and independently verifiable. When a spec fails, you immediately know *which* outcome broke — no debugging through a multi-assertion file.
 
 - When a behavior has multiple outcomes, create a `when_<behavior>/` folder with separate files for each outcome.
 - For simple behaviors with a single outcome, use a single file: `when_<behavior>`.
-- Never write a single file that tests an entire class's unrelated behaviors. **C# declarative read-model mappings are the exception:** use one scenario class per read model, one shared event sequence with captured intermediate states, and many read-only facts for fields and lifecycle outcomes. See [specs.scenarios.csharp.md](./specs.scenarios.csharp.instructions.md) for scenario selection and cost budgets.
+- Never write a single file that tests an entire class's unrelated behaviors. **C# declarative read-model mappings are the exception:** use one scenario class per read model by default (another only for a sequence that cannot share it, such as a removal or another key), one shared event sequence with captured intermediate states, and many read-only facts for fields and lifecycle outcomes. See [specs.scenarios.csharp.md](./specs.scenarios.csharp.instructions.md) for scenario selection and cost budgets.
 
 ## Reusable Context
 

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

@@ -15,7 +15,44 @@ 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 or declarative projection mapping. Do not repeat every decision through the pipeline; name the extra behavior each scenario proves.
+Call pure `Handle()`, validators, reducers and reactor decisions directly with their inputs, including read-model state. Add a scenario only for the wiring the decision table below obligates (pipeline and authorization, constraints, projection and reducer dispatch, reactor dispatch and routing). Do not repeat every decision through the pipeline; name the extra behavior each scenario proves.
+
+**Decision table — apply it per artifact, without judgment.** A plain call proves the decision; a scenario is a coverage obligation for the wiring only the framework proves. These are obligations, not quotas: add a scenario for each behavior listed, and none beyond it.
+
+| Artifact | Plain call (`Specification`) | Scenario obligation |
+|---|---|---|
+| Command with a pure `Handle(…)` | every outcome and rejection branch, with read-model state supplied | the pipeline path once (`CommandScenario`: discovery, DI, event source, appended events), plus a **negative proof for each wiring that can refuse before `Handle`**: authorization denies (`ShouldNotBeAuthorized`), validation rejects, `Provide()` short-circuits |
+| `Handle` that needs `IEventStore`, `IReadModels` or services | none: do not substitute the store | keep the scenario; when touched, take the read model as a `Handle` parameter and use the row above |
+| `CommandValidator`, `ConceptValidator`, `Provide()` logic | each rule, built with its state | the command's pipeline scenarios prove the wiring |
+| Constraint (`[Unique]`, `IConstraint`) | none | an `EventScenario` per constraint: the violation and the nearest non-violation |
+| Projection or read model | none | `ReadModelScenario` against the real engine, covering **each event, key, join, children and removal the projection declares**: one class per read model with one shared event sequence by default; add a class only for a sequence that cannot share it (a removal, another key) |
+| Reducer | each transition: `Model.Reduce(event, current[, context])` | a `ReadModelScenario` for dispatch, filters and stream routing |
+| Reactor | each handler decision and side effect, called directly with substitute collaborators | a `ReactorScenario`: dispatch, filtering, read-model parameters, routing of produced events to the right event source, `[OnceOnly]`/replay |
+| Query | extracted filter, sort or composition logic | `QueryScenario` for arguments, authorization and paging; provider behavior is integration |
+| Cross-slice flow | each link | out-of-process integration, outside the fast loop |
+
+Name a scenario after the wiring it proves (`and_the_caller_is_not_a_maintainer`). A plain `Handle()` spec never takes a validator, authorization or constraint name: it did not run them. Merge scenario classes only with an assertion map that keeps every assertion. Never use a substitute for the event store or a read-model store as proof of persistence or projection. Cost and parallel-safety requirements are in [fast-feedback.md](./fast-feedback.instructions.md).
+
+#### Negative authorization proof
+
+```csharp
+#if DEBUG
+namespace MyApp.Authors.Registration.when_registering_an_author;
+
+public class and_the_caller_is_not_a_maintainer : Specification
+{
+    readonly CommandScenario<RegisterAuthor> _scenario = new();   // no identity registered
+    CommandResult _result;
+
+    async Task Because() => _result = await _scenario.Execute(new RegisterAuthor(AuthorId.New(), "Jane Austen"));
+
+    [Fact] void should_be_denied() => _result.ShouldNotBeAuthorized();
+    [Fact] async Task should_append_nothing() => await _scenario.ShouldNotHaveAppendedEvents();
+}
+#endif
+```
+
+An unauthenticated scenario against an `[Authorize]`/`[Roles]` command is denied before `Handle`; pair it with the happy-path scenario that registers an allowed identity in `_scenario.Services`.
 
 **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`.
 
@@ -27,7 +64,7 @@ Specs are **mandatory for every slice type**, including reactors.
 | `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 |
+| `ReadModelScenario<TReadModel>` | projection/reducer state from a sequence of events (auto-detects model-bound / fluent / reducer) | one class per read model by default, many read-only assertions on shared setup (see the decision table for when to add another) |
 | `ReactorScenario<TReactor>` | reactor handler invocation + side effects via mocked services | the reactor wiring and side effects (Automation / Translation slices) |
 
 > **Out-of-process Chronicle integration specs are an advanced case** — reserve them for host wiring, real infrastructure, serialization/transport, or end-to-end boundaries the scenario helpers can't exercise. They are not the default vertical-slice test shape.
@@ -144,7 +181,7 @@ async Task Because() =>
 
 ### `ReadModelScenario<TReadModel>` — declarative projections and reducer wiring
 
-The default for declarative projections; pure reducer decisions start with a direct call. Use **one scenario class per read model**, not one per property, mapping attribute or lifecycle event. Apply its event sequence once, capture intermediate states in `Because` where needed, then assert fields, children, counters and lifecycle outcomes in many read-only facts. Add a reducer scenario only for dispatch, filtering, metadata or read-model wiring. Use xUnit `Assert.*` on `_scenario.Instance`.
+The default for declarative projections; pure reducer decisions start with a direct call. Use **one scenario class per read model**, not one per property, mapping attribute or lifecycle event; add another class only for an event sequence that cannot share the first (a removal, another key), as the decision table says. Apply its event sequence once, capture intermediate states in `Because` where needed, then assert fields, children, counters and lifecycle outcomes in many read-only facts. Add a reducer scenario only for dispatch, filtering, metadata or read-model wiring. Use xUnit `Assert.*` on `_scenario.Instance`.
 
 ```csharp
 ReadModelScenario<Author> _scenario = null!;

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 or declarative projections — 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 the scenarios the per-artifact decision table in [specs.scenarios.csharp.md](./specs.scenarios.csharp.instructions.md) obligates).
 
 ## Proxy generation — the build dependency
 

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

@@ -41,13 +41,13 @@ Select from these canonical rules in `.cratis/ai/rules/` only after applying the
 
 ## C# specs — start with the plain call
 
-Specify pure `Handle()`, validator, reducer and reactor decisions with plain calls and supplied read-model state. Follow `.cratis/ai/rules/specs.scenarios.csharp.md`: scenarios add only pipeline/authorization wiring, constraints, declarative mapping or application-owned race-policy proof, not a platform guard matrix. Keep the single cheap assembly-level admission spec for the application's own decision-model shapes. Prefer in-process helpers over out-of-process Chronicle hosts for the applicable behaviors:
+Specify pure `Handle()`, validator, reducer and reactor decisions with plain calls and supplied read-model state. Follow `.cratis/ai/rules/specs.scenarios.csharp.md`: add exactly the scenarios its per-artifact decision table obligates (pipeline and authorization, constraints, projection and reducer dispatch, reactor dispatch and routing) plus application-owned race-policy proof, not a platform guard matrix. Keep the single cheap assembly-level admission spec for the application's own decision-model shapes. Prefer in-process helpers over out-of-process Chronicle hosts for the applicable behaviors:
 
 | Tool | Use for |
 |---|---|
 | `CommandScenario<TCommand>` | **State Change** — runs authorization + validators + `Provide()` + `Handle()` + appended events |
 | `EventScenario` | constraint violations, raw append/sequencing semantics |
-| `ReadModelScenario<TReadModel>` | **State View** — one class per read model, many read-only assertions on shared setup |
+| `ReadModelScenario<TReadModel>` | **State View** — one class per read model by default (another only for a sequence that cannot share it), many read-only assertions on shared setup |
 | `ReactorScenario<TReactor>` | **Automation / Translation** — reactor invocation + side effects |
 
 Reserve out-of-process integration specs for host/transport/infra boundaries the scenario helpers can't exercise.

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 or declarative mapping. 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 the scenarios the decision table in [specs.scenarios.csharp.md](./specs.scenarios.csharp.md) obligates, and follow it 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/fast-feedback.md

@@ -0,0 +1,36 @@
+---
+applyTo: "**/for_*/**,**/when_*/**,**/*.csproj,**/Directory.Build.props,**/Directory.Build.targets,**/*.Specs/**,**/.github/workflows/**"
+paths:
+  - "**/for_*/**"
+  - "**/when_*/**"
+  - "**/*.csproj"
+  - "**/Directory.Build.props"
+  - "**/Directory.Build.targets"
+  - "**/*.Specs/**"
+  - "**/.github/workflows/**"
+---
+
+# Fast feedback is a product requirement
+
+Applies to every Cratis repository and every application built on Cratis. A build and a spec run are
+measured in seconds. Each line is tagged **[contract]** (binding) or **[convention]** (the house
+default) per [`general.md`](./general.md).
+
+- **[contract] Building and running specs is as fast as possible, locally and in CI.** A change
+  that makes a build or a spec run slower is a regression: measure it (cold full-suite wall time
+  plus a focused single-folder loop) and fix it in the same change.
+- **[contract] Every spec is safe to run in parallel with every other spec.** No shared mutable
+  static state, no ordering assumptions, no fixed ports, paths or names that two specs could both
+  claim. Never serialize a suite or opt out of shared setup to hide an isolation bug.
+- **[contract] No per-spec startup cost for convenience.** Setup is built once and shared
+  (shared lifecycle stays on). Slow setup in a framework harness is fixed in the framework and
+  reported upstream; do not work around it by merging unrelated assertions or skipping specs.
+- **[contract] Analyzers and generators are cheap or they are not added.** A slow one is an
+  upstream issue; see [`framework.md`](./framework.md) for how analyzers are written for speed.
+- **[convention] Specify with the cheapest proof that is real.** Call a pure decision directly;
+  use a scenario for what only the framework pipeline or engine proves. The per-artifact table is in
+  [`specs.scenarios.csharp.md`](./specs.scenarios.csharp.md); the universal base is in
+  [`specs.md`](./specs.md).
+
+A cold full-suite run under a minute is the target for a repository's spec gate. It is a budget to
+protect, not a reason to delete coverage.

package/package/corpus/rules/general.md

@@ -139,6 +139,7 @@ A claim is only as good as the signal behind it — a build result, a test run,
 | React + Arc + Cratis Components + MVVM + dialogs | `react.md`, `components.md`, `dialogs.md` |
 | Frontend engineering quality & testing | `frontend-quality.md`, `frontend-testing.md`, `storybook.md` |
 | Spec patterns — universal `Specification` base (both profiles) | `specs.md`, `specs.csharp.md`, `specs.typescript.md` |
+| Build and spec-run speed: parallel-safe specs, no per-spec startup, cheap analyzers | `fast-feedback.md` |
 | Spec patterns — the four `*Scenario` helpers (application only) | `specs.scenarios.csharp.md` |
 | Strongly-typed values (`ConceptAs<T>`, `EventSourceId<T>`) | `concepts.md` |
 | Shared term definitions (event, projection, reducer, reactor, observer, DCB, …) | `glossary.md` |

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 or declarative projections — 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 the scenarios its per-artifact decision table obligates — 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.md

@@ -97,13 +97,19 @@ The goal is to cover *decisions and transformations* — code where bugs hide. S
 
 **Avoid file names starting with:** `when_getting_*`, `when_returning_*` — if a spec name starts with "getting" or "returning", it's probably testing a simple getter, which is not worth specifying.
 
+## Choosing the harness
+
+Call the code. A function whose result depends only on its arguments is specified by calling it with those arguments and asserting the result: no host, container or harness. Use a harness (scenario, fixture, in-memory engine) for behavior that exists only in the framework: discovery, attribute- or convention-driven wiring, authorization, persistence-time rules and declarative mappings. Name each such spec after the wiring it proves, and do not repeat through the harness a decision a plain call already proves.
+
+Substitute collaborators (a service, a clock, a sender) freely in a plain call. Never substitute the event store, a read-model store or the pipeline as proof of persistence, projection or pipeline behavior: either make the code a pure function of its inputs, or keep the harness. Harness coverage is an obligation per behavior the framework owns, not a quota. Fast, parallel-safe harnesses are required by [fast-feedback.md](./fast-feedback.md).
+
 ## Multiple Outcomes
 
 Each distinct outcome deserves its own spec file. This keeps specs small, focused, and independently verifiable. When a spec fails, you immediately know *which* outcome broke — no debugging through a multi-assertion file.
 
 - When a behavior has multiple outcomes, create a `when_<behavior>/` folder with separate files for each outcome.
 - For simple behaviors with a single outcome, use a single file: `when_<behavior>`.
-- Never write a single file that tests an entire class's unrelated behaviors. **C# declarative read-model mappings are the exception:** use one scenario class per read model, one shared event sequence with captured intermediate states, and many read-only facts for fields and lifecycle outcomes. See [specs.scenarios.csharp.md](./specs.scenarios.csharp.md) for scenario selection and cost budgets.
+- Never write a single file that tests an entire class's unrelated behaviors. **C# declarative read-model mappings are the exception:** use one scenario class per read model by default (another only for a sequence that cannot share it, such as a removal or another key), one shared event sequence with captured intermediate states, and many read-only facts for fields and lifecycle outcomes. See [specs.scenarios.csharp.md](./specs.scenarios.csharp.md) for scenario selection and cost budgets.
 
 ## Reusable Context
 

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

@@ -14,7 +14,44 @@ 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 or declarative projection mapping. Do not repeat every decision through the pipeline; name the extra behavior each scenario proves.
+Call pure `Handle()`, validators, reducers and reactor decisions directly with their inputs, including read-model state. Add a scenario only for the wiring the decision table below obligates (pipeline and authorization, constraints, projection and reducer dispatch, reactor dispatch and routing). Do not repeat every decision through the pipeline; name the extra behavior each scenario proves.
+
+**Decision table — apply it per artifact, without judgment.** A plain call proves the decision; a scenario is a coverage obligation for the wiring only the framework proves. These are obligations, not quotas: add a scenario for each behavior listed, and none beyond it.
+
+| Artifact | Plain call (`Specification`) | Scenario obligation |
+|---|---|---|
+| Command with a pure `Handle(…)` | every outcome and rejection branch, with read-model state supplied | the pipeline path once (`CommandScenario`: discovery, DI, event source, appended events), plus a **negative proof for each wiring that can refuse before `Handle`**: authorization denies (`ShouldNotBeAuthorized`), validation rejects, `Provide()` short-circuits |
+| `Handle` that needs `IEventStore`, `IReadModels` or services | none: do not substitute the store | keep the scenario; when touched, take the read model as a `Handle` parameter and use the row above |
+| `CommandValidator`, `ConceptValidator`, `Provide()` logic | each rule, built with its state | the command's pipeline scenarios prove the wiring |
+| Constraint (`[Unique]`, `IConstraint`) | none | an `EventScenario` per constraint: the violation and the nearest non-violation |
+| Projection or read model | none | `ReadModelScenario` against the real engine, covering **each event, key, join, children and removal the projection declares**: one class per read model with one shared event sequence by default; add a class only for a sequence that cannot share it (a removal, another key) |
+| Reducer | each transition: `Model.Reduce(event, current[, context])` | a `ReadModelScenario` for dispatch, filters and stream routing |
+| Reactor | each handler decision and side effect, called directly with substitute collaborators | a `ReactorScenario`: dispatch, filtering, read-model parameters, routing of produced events to the right event source, `[OnceOnly]`/replay |
+| Query | extracted filter, sort or composition logic | `QueryScenario` for arguments, authorization and paging; provider behavior is integration |
+| Cross-slice flow | each link | out-of-process integration, outside the fast loop |
+
+Name a scenario after the wiring it proves (`and_the_caller_is_not_a_maintainer`). A plain `Handle()` spec never takes a validator, authorization or constraint name: it did not run them. Merge scenario classes only with an assertion map that keeps every assertion. Never use a substitute for the event store or a read-model store as proof of persistence or projection. Cost and parallel-safety requirements are in [fast-feedback.md](./fast-feedback.md).
+
+#### Negative authorization proof
+
+```csharp
+#if DEBUG
+namespace MyApp.Authors.Registration.when_registering_an_author;
+
+public class and_the_caller_is_not_a_maintainer : Specification
+{
+    readonly CommandScenario<RegisterAuthor> _scenario = new();   // no identity registered
+    CommandResult _result;
+
+    async Task Because() => _result = await _scenario.Execute(new RegisterAuthor(AuthorId.New(), "Jane Austen"));
+
+    [Fact] void should_be_denied() => _result.ShouldNotBeAuthorized();
+    [Fact] async Task should_append_nothing() => await _scenario.ShouldNotHaveAppendedEvents();
+}
+#endif
+```
+
+An unauthenticated scenario against an `[Authorize]`/`[Roles]` command is denied before `Handle`; pair it with the happy-path scenario that registers an allowed identity in `_scenario.Services`.
 
 **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`.
 
@@ -26,7 +63,7 @@ Specs are **mandatory for every slice type**, including reactors.
 | `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 |
+| `ReadModelScenario<TReadModel>` | projection/reducer state from a sequence of events (auto-detects model-bound / fluent / reducer) | one class per read model by default, many read-only assertions on shared setup (see the decision table for when to add another) |
 | `ReactorScenario<TReactor>` | reactor handler invocation + side effects via mocked services | the reactor wiring and side effects (Automation / Translation slices) |
 
 > **Out-of-process Chronicle integration specs are an advanced case** — reserve them for host wiring, real infrastructure, serialization/transport, or end-to-end boundaries the scenario helpers can't exercise. They are not the default vertical-slice test shape.
@@ -143,7 +180,7 @@ async Task Because() =>
 
 ### `ReadModelScenario<TReadModel>` — declarative projections and reducer wiring
 
-The default for declarative projections; pure reducer decisions start with a direct call. Use **one scenario class per read model**, not one per property, mapping attribute or lifecycle event. Apply its event sequence once, capture intermediate states in `Because` where needed, then assert fields, children, counters and lifecycle outcomes in many read-only facts. Add a reducer scenario only for dispatch, filtering, metadata or read-model wiring. Use xUnit `Assert.*` on `_scenario.Instance`.
+The default for declarative projections; pure reducer decisions start with a direct call. Use **one scenario class per read model**, not one per property, mapping attribute or lifecycle event; add another class only for an event sequence that cannot share the first (a removal, another key), as the decision table says. Apply its event sequence once, capture intermediate states in `Because` where needed, then assert fields, children, counters and lifecycle outcomes in many read-only facts. Add a reducer scenario only for dispatch, filtering, metadata or read-model wiring. Use xUnit `Assert.*` on `_scenario.Instance`.
 
 ```csharp
 ReadModelScenario<Author> _scenario = null!;

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 or declarative projections — 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 the scenarios the per-artifact decision table in [specs.scenarios.csharp.md](./specs.scenarios.csharp.md) obligates).
 
 ## Proxy generation — the build dependency
 

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

@@ -11,9 +11,10 @@ metadata:
 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; follow the
-[scenario selection and cost rule](../../rules/specs.scenarios.csharp.md). The scenario family
+Add exactly the scenarios the per-artifact decision table in the
+[scenario selection and cost rule](../../rules/specs.scenarios.csharp.md) obligates
+(pipeline and authorization, constraints, projection and reducer dispatch,
+reactor dispatch and routing). The scenario family
 exercises the real Arc and Chronicle code paths in-process — no HTTP, no fixture,
 no server.
 
@@ -108,9 +109,12 @@ A behavior covering several subjects groups under
 ## Step 2 — Start with the decision; add the scenario by slice type
 
 Specify a pure decision with the plain `Specification` base first. A direct
-`Handle()` call does not run validation, authorization, `Provide()` or operations;
-add a scenario only where that wiring adds proof. Keep shared lifecycle enabled
-and measure scenario cost as described in the linked rule.
+`Handle()` call does not run validation, authorization, `Provide()` or operations,
+so each wiring that can refuse before `Handle` needs its own negative scenario.
+The per-artifact decision table and its coverage obligations are in the
+[scenario rule](../../rules/specs.scenarios.csharp.md); apply it as written.
+A `Handle` that takes `IEventStore`, `IReadModels` or services is not a plain
+call: keep the scenario, and when touched take read models as parameters.
 
 | Slice type | Scenario | Skill |
 | --- | --- | --- |
@@ -135,11 +139,12 @@ exception diagnostics, synchronous handler throws and UTC context defaults.
 
 One specification class for **each** of:
 
-1. **The happy path** — a plain call returns the expected event; add pipeline
-   coverage only for behavior that call cannot prove.
+1. **The happy path** — a plain call returns the expected event, plus one
+   `CommandScenario` happy path for the pipeline, and a negative scenario for
+   each authorization policy and `Provide()` short-circuit.
 2. **Each validation failure** — instantiate `CommandValidator` or
-   `ConceptValidator` with the required state and validate directly. Use a
-   scenario only to prove pipeline wiring.
+   `ConceptValidator` with the required state and validate directly; the
+   command's pipeline scenario proves the wiring.
 3. **Each business-rule rejection** — one `and_` class per condition in
    `Handle()` that inspects a read model.
 4. **Each constraint violation** — one class per constraint, written with

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

@@ -274,10 +274,13 @@ Components guidance, not to this skill.
 
 ## Verify
 
-Start pure `Handle()` and validator decisions with direct calls and supplied
-read-model state. Add scenarios only for pipeline/authorization wiring,
-constraints, never read-protection plumbing or simulated concurrency;
-follow the [scenario selection and cost rule](../../rules/specs.scenarios.csharp.md).
+Keep `Handle` a pure function of the command, its read-model parameters and
+provided values: that makes it specifiable by a plain call. Start `Handle()` and
+validator decisions with direct calls and supplied read-model state. Add the
+pipeline scenario plus a negative proof per authorization policy, validator
+rejection and `Provide()` short-circuit, and a constraint scenario; never
+read-protection plumbing or simulated concurrency. Follow the
+[decision table](../../rules/specs.scenarios.csharp.md).
 
 - The command is a `record`, carries `[Command]`, and declares a public instance
   `Handle`.

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

@@ -10,6 +10,11 @@ license: MIT
 database, no network — an empty event log at sequence number zero, with the
 application's constraints discovered and active.
 
+Specify every constraint with an `EventScenario`: one class for the violation
+and one for the nearest non-violation. A constraint is enforced at append, so no
+plain call or substituted event store proves it. Pure decisions around it are
+plain calls; see the [decision table](../../rules/specs.scenarios.csharp.md).
+
 ## Verified product sources
 
 | Package | Purpose |

package/package/corpus/skills/cratis-chronicle-reactor/references/specifications.md

@@ -12,8 +12,29 @@
 
 Start with `Specification` plus a direct call for pure reactor decisions,
 passing the trigger and supplied values explicitly and asserting the returned
-command or event. Add `ReactorScenario<TReactor>` only where invocation,
-dependency wiring or side effects contribute proof. In those scenarios, drive
+command or event. Add one `ReactorScenario<TReactor>` per reactor for what only
+Chronicle proves: dispatch, filtering, read-model parameters and routing of
+produced events to the right event source (the
+[decision table](../../../rules/specs.scenarios.csharp.md)).
+Substitute the reactor's collaborators in either style; never substitute the
+event store as proof of routing.
+
+```csharp
+public class when_an_author_is_registered : Specification
+{
+    readonly INotifier _notifier = Substitute.For<INotifier>();
+    readonly AuthorId _id = AuthorId.New();
+
+    async Task Because() =>
+        await new AuthorNotifications(_notifier).Registered(
+            new AuthorRegistered("Jane Austen"),
+            EventContext.EmptyWithEventSourceId(_id));
+
+    [Fact] void should_notify_about_the_author() => _notifier.Received(1).Notify("Jane Austen");
+}
+```
+
+In reactor scenarios, drive
 events with a service provider of substitutes and assert on the substitutes for
 non-event side effects; for handlers that return events, assert the resulting
 appends through the scenario's event store. Cover the replay path separately

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

@@ -16,9 +16,12 @@ default, with the event and current state supplied explicitly (for a self model,
 `ReadModelScenario<TReadModel>` only where declarative projection behavior,
 event dispatch, filtering, metadata or read-model wiring contribute proof.
 Follow the [scenario selection and cost rule](../../rules/specs.scenarios.csharp.md):
-use one scenario class per read model, many read-only assertions on one shared
-setup, and keep shared lifecycle enabled. Do not create a class per property,
-mapping attribute or lifecycle event. Measure scenario cost with TRX durations
+use one scenario class per read model and per distinct event sequence the
+projection declares (lifecycle, join, children with two keys, removal), with many
+read-only assertions on one shared setup, and keep shared lifecycle enabled. Cover
+each declared sequence; do not create a class per property or mapping attribute.
+Never replace the engine with a substitute store as projection proof. Reducer
+transitions are plain calls; the scenario proves dispatch and filters. Measure scenario cost with TRX durations
 using [running-specs.md](../cratis-specifications-csharp/references/running-specs.md).
 
 For a read-model scenario specification the **`Given` *is* the act**. There

package/package/corpus/skills/cratis-chronicle-reducer/SKILL.md

@@ -271,8 +271,8 @@ Read [references/filtering.md](references/filtering.md) when restricting which e
 
 Start with `Specification` plus a direct call for pure reducer decisions:
 pass the event and current state explicitly and assert the returned next state.
-Add `ReadModelScenario<TReadModel>` only where event dispatch, filtering,
-metadata or read-model wiring contribute proof; drive the event sequence and
+Add one `ReadModelScenario<TReadModel>` per reducer for event dispatch, filtering,
+metadata and read-model wiring (the [decision table](../../rules/specs.scenarios.csharp.md)); drive the event sequence and
 assert on the resulting instance there. For the self example:
 
 Read [references/specification-example.md](references/specification-example.md) when you need a worked direct-call and `ReadModelScenario` spec.

package/package/corpus/skills/cratis-code-review/SKILL.md

@@ -155,8 +155,10 @@ degradations a reviewer can see without measuring:
 ## Step 6 — Specification coverage
 
 - Pure command, validator, reducer and reactor decisions have plain-call specs
-  with supplied read-model state; scenarios add only pipeline/authorization
-  wiring, constraints, declarative mapping or application-owned race-policy proof.
+  with supplied read-model state; scenarios cover exactly the obligations in the
+  per-artifact decision table of `specs.scenarios.csharp.md` (pipeline and
+  authorization, constraints, projection and reducer dispatch, reactor dispatch
+  and routing) plus application-owned race-policy proof.
 - Every State Change command has a happy-path specification.
 - Every validation rule has a direct-call failure spec. Pipeline validation
   specs assert **both** `ShouldNotBeSuccessful()` and `ShouldHaveValidationErrors()`.

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

@@ -89,8 +89,8 @@ 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, or declarative mapping. Keep shared lifecycle on; measure scenario cost using
+plain call, including direct validator calls, and add the scenarios the
+per-artifact decision table in `specs.scenarios.csharp.md` obligates. 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.json

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