@cratis/pi 7.123.0 → 7.125.0

package/package/corpus/skills/cratis-chronicle-read-model-specifications/references/view-lifecycle-checks.md

@@ -16,9 +16,12 @@ Martin Dilger and Nebulit GmbH's build-state-view (see `provenance.md`), with th
 migrations and projection specification harness replaced by `ReadModelScenario<TReadModel>`.
 
 Take the contract first (the `.play` read model, its projection and its specifications, or the
-agreed outline). Write one specification per contract specification, using its example values, and
-add the cases below only where the contract states the behavior; an uncontracted rule found in the
-projection is a proposal for the contract, not silent coverage.
+agreed outline). Give each contract specification assertions using its example
+values in **one shared scenario class per read model**, not a class per property
+or lifecycle event. Capture intermediate values or immutable snapshots in `Because`
+as the event sequence advances; facts only inspect them. Add the cases below only
+where the contract states the behavior; an uncontracted rule found in the projection
+is a proposal for the contract, not silent coverage.
 
 ## How to use this list
 For each read model, list its properties and its events in a small table (property, events that

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-code-review/SKILL.md

@@ -84,8 +84,11 @@ there is nothing to review under a red build.
 - Read protection is `Off` by default; new code sets `<CratisReadProtection>On</CratisReadProtection>`.
   Under `Off` an injected model or validator read is advisory, not a concurrency guard.
   Under `On`, review that state rules sit in validators or handlers with the model as
-  a parameter, `[Unprotected("why")]` carries a real reason, and a conflict spec
-  (`AppendConcurrently` plus `ConcurrencyViolation`) exists.
+  a parameter and `[Unprotected("why")]` carries a real reason. Apply
+  [specs.scenarios.csharp.md](../../rules/specs.scenarios.csharp.md): business
+  decisions use direct `Handle()`/validator calls with supplied state. Require
+  one cheap assembly-level admission spec for the application's own shapes,
+  not per-decision concurrency/conflict/isolation tests; Arc/Chronicle own that matrix.
 - Use `Cratis.Arc.Core.CodeAnalysis` and `Cratis.Arc.Chronicle.CodeAnalysis`.
   ARCCHR0011 (Info, `Off` only) and 0012 flag unprotected reads/immediate
   bypasses; 0013 (Info) recommends definitions; 0014 checks declared observer
@@ -151,12 +154,12 @@ degradations a reviewer can see without measuring:
 
 ## Step 6 — Specification coverage
 
-- Pure command, reducer and reactor decisions have plain-call specifications
-  (`Specification` plus a direct call); scenarios are added where pipelines,
-  validation, constraints, projections or wiring contribute proof.
+- 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.
 - Every State Change command has a happy-path specification.
-- Every validation rule has a failure specification asserting **both**
-  `ShouldNotBeSuccessful()` and `ShouldHaveValidationErrors()`.
+- Every validation rule has a direct-call failure spec. Pipeline validation
+  specs assert **both** `ShouldNotBeSuccessful()` and `ShouldHaveValidationErrors()`.
 - Every business-rule rejection has a specification.
 - Every constraint has an `EventScenario` specification asserting the constraint
   **name** by default.

package/package/corpus/skills/cratis-screenplay-command-surface/references/generated-values-and-responses.md

@@ -259,7 +259,11 @@ Stage emits strategy-specific `IGeneratable<T>.New()` factories over Fundamental
 checks atomically at append: a batch's scopes are checked once against the state before
 the batch, all or nothing, and a storage retry that renumbers the append checks them again. Generated rejection specs assert
 `ValidationResultReason.ConcurrencyViolation`, not Arc's message text. This is
-Stage's explicit realization, not a claim that Arc delivers the same guard.
+Stage's explicit realization and renderer-owned smoke coverage, not a claim that
+Arc delivers the same guard or an instruction to hand-write an application guard
+matrix. Application decisions use direct `Handle()`/validator calls with supplied
+state; the one cheap application-shape admission spec is their only decision-read
+obligation. See [specs.scenarios.csharp.md](../../../rules/specs.scenarios.csharp.md).
 Time-based factories use the command's receipt time through `IGeneratableInContext<T>`
 and `GenerationContext`, the same instant as `$context.occurred`.
 

package/package/corpus/skills/cratis-screenplay-scenario-coverage/references/chronicle-verification.md

@@ -7,9 +7,11 @@ or `question` cells).
 
 - **Claims**: different-source collision, same-source reclaim, change or release, a legitimate
   repeat.
-- **Decision reads**: never-created absence, removal then recreation, a relevant concurrent
-  change, an irrelevant one, rejected or no-fact outcomes, refusal of an incompatible
-  projection or key.
+- **Decision reads**: application specs call `Handle()` or the validator directly
+  with supplied state and assert business outcomes. Their only decision-read
+  obligation is one cheap assembly-level admission spec for the application's
+  own models/projections; see [specs.scenarios.csharp.md](../../../rules/specs.scenarios.csharp.md).
+  The concurrency, conflict-refusal and isolation matrix belongs only to Arc/Chronicle.
 - **Namespaces**: identical business keys in different tenants, background target selection,
   independent observer progress, every namespace covered by erasure.
 - **Compliance**: subject resolution, unreadable values after erasure, fenced new writes,

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

@@ -13,10 +13,10 @@ 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, routed conflicts or protected projection reads.
-Seed actual events for a guarded command; pinned models cannot supply a guard.
-`new CommandScenario<T>()` selects the in-process decision log from the command's
-read-protection mode and dependencies, so `UseDecisionReads()` is not called. `Perform`/`Observe` need configured services/principal, and
+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;
 MongoDB observations still need real infrastructure.
 
 ## Verified product sources
@@ -77,20 +77,21 @@ before changing runner or package family.
 
 | Situation | Surface |
 | --- | --- |
-| Pure `Handle()` / `Handle(providedValue)`, reducer logic or reactor decision (default) | Plain method call with `Specification` |
+| Pure `Handle()` / `Handle(providedValue)`, validator, reducer or reactor decision (default) | Plain method call with `Specification`, supplying read-model state |
 | Isolated class, collaborators can be substituted | `Specification` + NSubstitute |
 | Arc command pipeline (validators, `Provide()`, `Handle()`, appended events) | `CommandScenario<TCommand>` |
 | Arc query conversion, validation, authorization and interceptors | `QueryScenario<TReadModel>` (`Cratis.Arc.Testing.Queries`) |
-| Chronicle append semantics, constraints, concurrency | `EventScenario` |
-| Projection or reducer state from a sequence of events | `ReadModelScenario<TReadModel>` |
+| Append-time domain constraints | `EventScenario` |
+| Declarative mapping or reducer wiring | One `ReadModelScenario<TReadModel>` class per read model, many read-only assertions on shared setup |
 | Reactor invocation and its side effects | `ReactorScenario<TReactor>` |
 | Host, transport, or real-infrastructure boundary | Out-of-process Chronicle integration specification |
 | Setup shared by many specifications | Reusable context under `given/` |
 
 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 and add the scenario helpers where the pipeline, validation,
-constraints or declarative projections contribute proof; read
+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
+[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
 boundaries the scenario helpers cannot reach — see
@@ -99,8 +100,12 @@ boundaries the scenario helpers cannot reach — see
 ⚠️ `EventScenario` wires a strategy that always answers `ConcurrencyScope.None`,
 which the validator skips, so an append that lets the strategy choose the scope
 never produces a concurrency violation. `ShouldHaveConcurrencyViolations()`
-cannot pass for such an append and its negation passes vacuously — specify concurrency against the
-real kernel with an out-of-process integration specification instead.
+cannot pass for such an append and its negation passes vacuously. Arc/Chronicle
+alone prove the platform concurrency, conflict-refusal and isolation matrix,
+with real-kernel integration where required. The application's only decision-read
+spec obligation is one cheap assembly-level shape-admission check from the
+[scenario rule](../../rules/specs.scenarios.csharp.md); business decisions take
+supplied state in direct `Handle()`/validator calls.
 
 For a class-based `ReactorScenario<TReactor>` on a recent Chronicle (Requires Chronicle 19.46.0), seed each
 handler read-model parameter with `Given.ForEventSourceId(id).ReadModel(instance)`
@@ -224,9 +229,9 @@ convention — there are no attributes on them.
 The shared lifecycle is the default: one instance and one Establish/Because
 execution per specification class. Facts must not mutate that shared context;
 `CRSPEC0008` is an error when one does. Read
-[shared-lifecycle.md](references/shared-lifecycle.md) for eligibility, opting a
-class, assembly or project out with `[PerFactSpecificationLifecycle]`, and
-fixing `CRSPEC0008`.
+[shared-lifecycle.md](references/shared-lifecycle.md) for eligibility, auditing
+mutation, class-only `[PerFactSpecificationLifecycle]` exceptions and fixing
+`CRSPEC0008`. Do not opt the assembly or project out.
 
 ## Step 4 — Extract a reusable context
 

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

@@ -9,23 +9,22 @@
 - Application conventions
 
 The four scenario helpers exercise the real Arc and Chronicle pipelines
-in-process. Use them for event-sourced *application* behavior where the pipeline,
-validation, constraints or projections matter; a pure decision (`Handle()`,
-`Handle(providedValue)`, reducer or reactor logic) is specified first as a plain
-call. A library or framework repository reaches for a scenario only to test the
+in-process. Follow the [scenario selection and cost rule](../../../rules/specs.scenarios.csharp.md):
+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 guarded command scenarios.
-Guarded decisions need actual seeded events, not pinned models; their given
-state and appends share one in-process log, unlike legacy dictionary seeding.
+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 | State Change behavior |
+| `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 | Constraints, raw sequencing, concurrency |
-| `ReadModelScenario<TReadModel>` | Projection or reducer state from a sequence of events | State View 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 |
 | `ReactorScenario<TReactor>` | Reactor invocation and its side effects | Automation and Translation behavior |
 
 Wrap scenario specification files in `#if DEBUG … #endif` only when they compile
@@ -83,9 +82,9 @@ from `Cratis.Arc.Chronicle.Testing`.
   `AppendedEvents`. `Given.ForEventSource(id).Events(…)` seeds the events an
   injected read model is then materialized from by its own projection or
   reducer; `Given.ForEventSource(id).ReadModel(instance)` pins a specific
-  read-model value instead. Both return `void`. Prefer seeding events — it
-  exercises the projection production depends on, so the specification cannot
-  pass against a read-model shape the projection never produces.
+  read-model value instead. Both return `void`. Supply state for business
+  decisions; seed events only when history/mapping is part of the example, never
+  solely to satisfy read-protection infrastructure.
 - **Validator and `Provide()` dependencies** are registered in
   `_scenario.Services`; the concrete validator is discovered automatically.
 - **Caller setup (Requires Arc 22.75.1):** register a substituted
@@ -233,18 +232,20 @@ async Task Because() =>
     Assert.True(_scenario.Instance!.<Property>);
 ```
 
-The helper auto-detects a model-bound projection, a fluent projection, or a
-reducer. Use the named-parameter constructor when services or initial state are
+Use one scenario class per read model, many read-only facts and shared lifecycle.
+Apply its event sequence once; capture intermediate states in `Because` for
+lifecycle assertions. Do not split startup per property, attribute or event.
+Pure reducer decisions remain plain calls. The helper auto-detects a model-bound
+projection, a fluent projection, or a reducer. Use the named-parameter constructor when services or initial state are
 needed: `new ReadModelScenario<<ReadModelType>>(initialState: null,
 serviceProvider: services)`. Pre-seed a keyed read model with
 `Given.ForEventSourceId(id).ReadModel(instance)` for code that calls
 `IReadModels.GetInstanceById`. Cross-stream projections are supported — seed each
 contributing stream with its own `Given.ForEventSource(…)`.
 
-To bridge read models into a command scenario, build a focused
-`ReadModelScenario<T>`, seed it, then register its read models into the command
-scenario with `_scenario.Services.AddSingleton(readModelScenario.ReadModels)`.
-For non-key searches, register a lookup double in the scenario services instead.
+Do not build a projection scenario merely to feed a pure command decision.
+Pass state directly or substitute the application's lookup collaborator; provider
+behavior belongs in provider integration specs.
 
 Do not pre-emptively skip a read-model assertion. Assume scalar concept, enum,
 and identifier properties populate; if one does not, investigate the projection.

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

@@ -3,6 +3,14 @@
 
 # Running specifications and migrating to 5.0
 
+## Contents
+
+- Project shape
+- Local loop
+- Measure specification cost
+- Filters
+- Migrate from 4.x to 5.0
+
 Requires `Cratis.Specifications.XUnit.v3` 5.0 on `net10.0`. Check the
 `PackageReference` versions in the specification project; 4.x projects follow the
 checklist below before the executable loop applies.
@@ -50,6 +58,28 @@ passed count.
 Where a solution mixes Microsoft.Testing.Platform and VSTest projects, run each
 project on its own; `dotnet test` on the whole solution does not work there.
 
+## Measure specification cost
+
+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,
+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,
+use `dotnet test <project> --no-build --configuration Release --logger "trx;LogFileName=specs.trx" --results-directory <results>`.
+For the built xUnit v3 `mtp-off` executable, use `-trx <results>/specs.trx`;
+check `<executable> -h` for other runner flavors rather than mixing switches.
+Use separate result paths for each run, under `.ai-work/` for local work.
+
+Inspect `UnitTestResult` entries: rank `duration` by `testName`, group by spec
+class, and compare pure calls, command scenarios and read-model scenarios. Shared
+setup may be charged to one fact, so also compare class totals and suite wall
+time; an individual fact's duration is not its isolated startup cost. Keep package
+versions, configuration, filters, concurrency/shards and machine fixed; preserve
+discovered/passed/failed/skipped counts and investigate any change. Do not count
+restore/build time as test execution or repeat unchanged runs merely for reassurance.
+
 ## Filters
 
 The executable accepts the filters of the xUnit v3 runner flavor the project
@@ -81,7 +111,8 @@ and record the spec count and outcomes first.
 4. Delete any `[assembly: Xunit.TestFramework(...)]` that registers Cratis
    Specifications.
 5. Fix each `CRSPEC0008` error by moving the change into `Establish` or `Because`; use
-   `[PerFactSpecificationLifecycle]` only when the fact genuinely needs a fresh instance.
+   `[PerFactSpecificationLifecycle]` only on a class whose facts genuinely mutate shared
+   state and cannot move that mutation into `Because`.
 6. Change assertion delegates typed as `Predicate<T>` to `Func<T, bool>`; for
    NUnit 4 comparisons that relied on unordered `ShouldEqual(params)`, use
    `ShouldEqualInAnyOrder`. Null actual values now fail, including nullable

package/package/corpus/skills/cratis-specifications-csharp/references/shared-lifecycle.md

@@ -3,6 +3,13 @@
 
 # Shared specification lifecycle
 
+## Contents
+
+- Eligibility
+- Native runner teardown outcomes
+- CRSPEC0008
+- Keep shared execution on
+
 Requires `Cratis.Specifications.XUnit.v3` or `.XUnit` 5.0. Before 5.0 the shared
 lifecycle was an opt-in on xUnit and `CRSPEC0008` was informational; check the package
 version before relying on either. NUnit, TUnit and the native runner always share the
@@ -35,7 +42,8 @@ the lifecycle; earlier versions use per-fact construction. With shared lifecycle
 construction happens once, and `Destroy` runs followed by
 one `Dispose` after the last fact, even when `Destroy` fails. Class/collection fixtures remain owned by xUnit,
 with assembly fixtures also supported on v3. Use
-`[PerFactSpecificationLifecycle]` when a fresh instance per fact is needed.
+`[PerFactSpecificationLifecycle]` only on the class whose facts genuinely mutate
+shared state and cannot move the mutation into `Because`; state the reason locally.
 
 `Specification.InitializeAsync()` is idempotent for a single instance. It does not make
 an ineligible class shared or cache instances across classes.
@@ -59,8 +67,18 @@ Requires Specifications 5.0.2 for Received.InOrder verification recognition; che
 Calls inside NSubstitute `Received.InOrder(...)` delegates are recognized as
 verification, but assignments and increments there still mutate state and are
 reported. Theories, per-fact classes/assemblies, immutable collection calls and
-collection calls whose return value is used are excluded. Move actual mutations
-into `Establish` or `Because`:
+collection calls whose return value is used are excluded.
+
+Since Specifications 5.2.0, `CRSPEC0008` also reports indirect changes it can prove:
+writes through nested members and indexers (also `?.`), `Dispose`/`DisposeAsync` on a
+shared field, reconfiguring a shared NSubstitute substitute (`Returns`, `Throws`,
+`When`, `ClearReceivedCalls`), and calls to a method in the same file that does any of
+these. The warning `CRSPEC0012` reports calls that usually change state, judged by
+name: `Execute`/`Handle`, destructive reads (`Take`, `Dequeue`, `Pop`, `MoveNext`) and
+`Push`, `Enqueue`, `TryAdd`, `Reset`, or `Add`/`Remove`/`Clear` on a collection reached
+through a field. Helpers in other files (such as a `given` context) and Moq `Setup`
+are not followed, so audit those classes by hand before turning the shared lifecycle
+back on. Move actual mutations into `Establish` or `Because`:
 
 ```csharp
 public class when_registering : Specification
@@ -74,18 +92,19 @@ public class when_registering : Specification
 }
 ```
 
-Do not lower the severity to pass the gate. When the repository must lower it, set it in
-`.editorconfig` with `dotnet_diagnostic.CRSPEC0008.severity = warning`.
-
-## Keep per-fact execution
+Do not lower the severity to pass the gate. The analyzer is not a complete mutation
+audit: also inspect helper calls, nested/indexer writes, command execution,
+destructive reads, disposal and substitute reconfiguration inside facts. Awaiting
+a read-only assertion is not itself a mutation.
 
-Use the narrowest scope; the reason is a fact that genuinely needs a fresh instance.
+## Keep shared execution on
 
-| Scope | How |
-| --- | --- |
-| One class | `[PerFactSpecificationLifecycle]` on the class |
-| The assembly | `[assembly: PerFactSpecificationLifecycle]` |
-| The project | `<CratisSpecificationsSharedLifecycle>false</CratisSpecificationsSharedLifecycle>` |
+Do not opt the assembly or project out for a few mutating facts. Remove blanket
+opt-outs only after auditing fact mutations; move actions into `Because` where
+possible and put `[PerFactSpecificationLifecycle]` on the remaining concrete
+classes, with a reason. Compare discovered/passed/failed/skipped counts and TRX
+durations before and after with unchanged concurrency. A clean analyzer run alone
+does not prove that all facts are read-only.
 
 Read [running-specs.md](./running-specs.md) for the executable loop and the 4.x → 5.0
 checklist.

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

@@ -40,7 +40,7 @@ Requires Stage 4.136.0 to render `generate rule`: the attached C# body becomes t
 opaque/unsupported rules refuse -005 before pin evaluation. Independent execution
 always needs pins.
 Requires Stage 4.124.0 for v24 text-rule admission (`cratis --version` identifies the CLI bundle); older renderers refuse v24 with STAGE-ESM-016.
-Requires Stage 4.127.0 for v25 version admission; older renderers refuse v25 with STAGE-ESM-016. Requires Stage 4.138.0 for the Cratis renderer to render protected reads as Arc read protection (`[ReadProtection(On)]`, a nullable read-model `Handle` parameter per read with `[LookUpBy]`, the `<View> '<key>' does not exist.` rejection, requirements evaluated in `Handle` after the reads; generated specifications run in decision mode); `cratis render` gets it from the first CLI that bundles Stage 4.138.0, and earlier bundles (CLI 3.75.0 bundles 4.137.0) refuse every protected read with STAGE-ESM-044. Reads it cannot preserve faithfully stay STAGE-ESM-044 and name the reason: constrained events, read paths in `produces when`, mappings to optional, collection, composite or mistyped event properties, generated-value freshness scopes. See [protected reads](../../cratis-screenplay-command-surface/references/protected-reads.md).
+Requires Stage 4.127.0 for v25 version admission; older renderers refuse v25 with STAGE-ESM-016. Requires Stage 4.138.0 for the Cratis renderer to render protected reads as Arc read protection (`[ReadProtection(On)]`, a nullable read-model `Handle` parameter per read with `[LookUpBy]`, the `<View> '<key>' does not exist.` rejection, requirements evaluated in `Handle` after the reads; the renderer owns generated specification plumbing; application spec authors do not select decision modes); `cratis render` gets it from the first CLI that bundles Stage 4.138.0, and earlier bundles (CLI 3.75.0 bundles 4.137.0) refuse every protected read with STAGE-ESM-044. Reads it cannot preserve faithfully stay STAGE-ESM-044 and name the reason: constrained events, read paths in `produces when`, mappings to optional, collection, composite or mistyped event properties, generated-value freshness scopes. See [protected reads](../../cratis-screenplay-command-surface/references/protected-reads.md). For hand-written application coverage, use direct `Handle()`/validator calls with supplied state and the single cheap assembly-level shape-admission spec in [specs.scenarios.csharp.md](../../../rules/specs.scenarios.csharp.md); do not reproduce Arc/Chronicle's platform guard matrix.
 Requires Stage 4.129.0 for semantic Host/executor protected reads; older engines refuse STAGE-ESM-044. Required absence rejects before requirements or generation; read-backed requirements and produced-event mappings execute. Non-Error protected requirements refuse STAGE-ESM-045, including reaction invocations. See [sandbox boundaries](sandbox-and-specrunner.md#protected-command-reads) for ordering and outside-append commit boundaries.
 Described handlers still refuse STAGE-IMPL-002, even in Stub mode. Query
 performers have a separate implementation-gap contract; gaps are not completed

package/package.json

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