@cratis/pi 7.27.3 → 7.28.1

package/package/corpus/rules/reactors.md

@@ -278,4 +278,34 @@ async Task Because() => await _scenario.Given.ForEventSource(_id).Events(new Inv
 [Fact] async Task should_notify_about_the_issued_invoice() => await _notifications.Received(1).Notify(Arg.Is<string>(_ => _.Contains("INV-1001")));
 ```
 
+### Read-model dependencies in scenarios — Chronicle 19.46.0+
+
+`ReactorScenario<TReactor>` does **not** build read models from `Given` events,
+including `[Passive]` models. Seed the handler's read-model parameter explicitly
+before firing the trigger:
+
+```csharp
+void Establish() => _scenario.Given.ForEventSourceId(_id).ReadModel(_order);
+async Task Because() => await _scenario.Given.ForEventSource(_id).Events(_orderPlaced);
+```
+
+In a separate absence specification, replace the seeding with
+`_scenario.Given.ForEventSourceId(_id).NoReadModel<Order>()` to deliberately pass
+`null` to an `Order?` parameter. Without either setup, resolution to `null` throws
+`ReadModelNotSeededForReactorScenario` (`Cratis.Chronicle.Testing.Reactors`), even
+for a nullable parameter. Its message names the type and missing key, suggests
+both setup methods, and lists other seeded keys for that type when any exist.
+Use the key from `ICanResolveReadModelKey.Resolve` for seeding or absence when
+implemented, not the triggering source id. `NoReadModel<T>()` does not remove a
+seeded instance. This guard applies to `EventStoreForTesting`, not an explicitly
+supplied store of another type; production read-model resolution is unchanged.
+
+Also in Chronicle 19.46.0+, `Events(...)` surfaces a synchronously throwing
+handler's own exception, preserving its stack, rather than the reflection
+`TargetInvocationException`. Capture it with `Catch.Exception` and assert the
+handler's exception type. `EventContext.From(...)` now defaults an omitted
+`occurred` to `DateTimeOffset.UtcNow`, not local `Now`; scenario contexts,
+`EventContext.Empty` and `EmptyWithEventSourceId(...)` use that helper. An
+explicit occurrence time is preserved, not normalized to UTC.
+
 For reactors that return side-effect events, assert the resulting appends through the scenario's event store; for non-event side effects, assert on the mocked services (as above). See [specs.scenarios.csharp.md](./specs.scenarios.csharp.md) for the full `*Scenario` family.

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

@@ -160,6 +160,47 @@ async Task Because() => await _scenario.Given.ForEventSource(_id).Events(new Aut
 [Fact] async Task should_notify() => await _service.Received(1).Notify("Jane Austen");
 ```
 
+#### Read-model setup — Chronicle 19.46.0+
+
+In a class-based `ReactorScenario<TReactor>`, `Given` events invoke the reactor;
+they **do not materialize read models**, even `[Passive]` ones. For each
+read-model handler parameter, choose one setup before `Because()`:
+
+```csharp
+// Present-state specification: supply the instance the handler must receive.
+void Establish() => _scenario.Given.ForEventSourceId(_id).ReadModel(_author);
+
+// Separate absence specification: deliberately let an Author? parameter receive null.
+void Establish() => _scenario.Given.ForEventSourceId(_id).NoReadModel<Author>();
+```
+
+These are alternatives in **separate specification classes**, not two
+`Establish()` methods in one class. Both builders return
+`ReactorSourceGivenBuilder<TReactor>` for chaining; neither setup is async.
+Use the triggering event-source id by default, or the key returned by the
+reactor's `ICanResolveReadModelKey.Resolve` when implemented. An absence
+declaration is for that exact type and key and does not delete a seeded model.
+
+If a recognized read-model parameter resolves to `null` without declared absence,
+`Events(...)` throws `ReadModelNotSeededForReactorScenario` from
+`Cratis.Chronicle.Testing.Reactors`, even if the parameter is nullable. The
+message names the full type and missing key, explains `ReadModel(...)` and
+`NoReadModel<T>()`, and lists seeded keys for that type when any exist. Fix the
+fixture or its key; do not add `NoReadModel<T>()` just to silence missing setup.
+The guard applies to `EventStoreForTesting`; it does not alter production
+resolution or an explicitly supplied event store of another type.
+
+**Handler failures:** in Chronicle 19.46.0+, a synchronous handler throw surfaces
+its own exception, not `TargetInvocationException`, with its handler stack
+preserved. Use `await Catch.Exception(() => _scenario.Given.ForEventSource(_id).Events(...))`
+and assert the handler's exception type.
+
+**Occurrence time:** in Chronicle 19.46.0+, `EventContext.From(...)` uses
+`DateTimeOffset.UtcNow` when `occurred` is omitted (previously local `Now`).
+`ReactorScenario` builds its contexts through this helper, as do
+`EventContext.Empty` and `EmptyWithEventSourceId(...)`. Explicit occurrence times
+keep their supplied offset; the positional constructor has no such default.
+
 ## Out-of-process Chronicle integration specs (advanced)
 
 Reserve these for the host/transport boundary the scenario helpers can't reach. They test a complete slice — HTTP request → command → append → constraint → projection — against a real Chronicle store, and live under `when_<behavior>/` directly inside the slice folder (no `for_` folder; the "unit" is the whole slice).

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

@@ -30,6 +30,10 @@ This skill decides **when to add a scenario** and **what to cover**. The C# mech
 
 > Re-verified at the versions above by **symbol and signature**: every type, attribute and member this skill names exists at that tag, and the public surface it describes is unchanged since the previous verification (Chronicle 16.45.x / Arc 22.10.4 — the Chronicle 16→18 client diff is converters, options and doc comments; no type was removed or renamed). Behavior claims were verified at the earlier tag unless a section says otherwise.
 
+Reactor read-model setup and the `EventContext.From` UTC default below are
+verified separately at **Chronicle 19.46.0**, the minimum version for that
+guidance; see `cratis-chronicle-reactor/references/specifications.md` for sources.
+
 `Cratis.Testing` is the meta-package that brings `Cratis.Arc.Testing` and
 `Cratis.Arc.Chronicle.Testing` together. Reverify against the owning product
 repository before claiming support for another version.
@@ -112,6 +116,15 @@ keep a scenario for that wiring and for appended-event behavior.
 | Automation or Translation — a reactor | `ReactorScenario<TReactor>` | `cratis-specifications-csharp` |
 | A host, transport, or real-infrastructure boundary | Out-of-process integration | `cratis-specifications-csharp` |
 
+For a class-based reactor scenario on **Chronicle 19.46.0+**, explicitly seed
+handler read-model parameters with `Given.ForEventSourceId(id).ReadModel(instance)`
+or declare intentional absence with `.NoReadModel<T>()`. An unseeded model throws
+`ReadModelNotSeededForReactorScenario` even if nullable; `Given` events do not
+build read models, including passive ones. Use the reactor's resolved key, not
+necessarily the trigger's source id. This is **not** the command-scenario event
+seeding described in Step 5. Read `cratis-chronicle-reactor` for the setup examples,
+exception diagnostics, synchronous handler throws and UTC context defaults.
+
 ## Step 3 — Cover every outcome of a State Change slice
 
 One specification class for **each** of:

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

@@ -75,8 +75,9 @@ Rules the framework actually enforces:
   operation collections, and `ARC0018` checks generated-invoker accessibility.
 - Name the command as the action — `OpenDebitAccount`, not
   `OpenDebitAccountCommand`.
-- `Handle` parameters are resolved from DI, so ask for services there rather
-  than through a constructor.
+- Unmarked `Handle` parameters resolve from `Provide()` or DI; ask for services
+  there rather than through a constructor. Server-owned new values use
+  `[GeneratedValue]` instead (below).
 - Never inject `IEventLog` into `Handle` to append the command's own events —
   `ARCCHR0007` warns, and it bypasses Arc's append pipeline. Express the append
   through the return type.
@@ -137,8 +138,8 @@ Two consequences worth knowing before writing the first command:
   the events in that same tuple are appended to. Returning more than one
   unhandleable element throws `MultipleUnhandledTupleValues`. When the command
   also returns an operation keyed by that id, have the caller supply the id
-  instead of calling `New()` in `Handle()`, so a retried request reuses the same
-  ownership key.
+  instead of generating a new value, so a retried request reuses the same
+  ownership key. A generated value alone does not provide idempotency.
 - **Events never carry their own event source.** Cross-stream writes use
   `EventForEventSourceId`; they are not expressed by a property on the event.
 
@@ -146,11 +147,8 @@ Two consequences worth knowing before writing the first command:
 [Command]
 public record Register<Thing>(<ConceptType> <Name>)
 {
-    public (<ThingId>, <ThingRegistered>) Handle()
-    {
-        var id = <ThingId>.New();
-        return (id, new(<Name>));
-    }
+    public (<ThingId>, <ThingRegistered>) Handle([GeneratedValue("thing")] <ThingId> id) =>
+        (id, new(<Name>));
 }
 ```
 
@@ -166,6 +164,28 @@ public record Transfer(<AccountId> From, <AccountId> To, <Money> Amount)
 }
 ```
 
+## Generate a server-owned new identifier
+
+**Arc 22.66.0+**, verified at **v22.68.0**: the create-command example above
+requires `<ThingId>` to implement `IGeneratable<ThingId>` with a static `New()`
+strategy (Fundamentals 7.23.0+; see `cratis-fundamentals-concept`). Replace
+`Guid.NewGuid()` or `<ThingId>.New()` inside `Handle()` with a generated parameter,
+not a new request property. Return the id as the ordinary response or in the
+id/event tuple so the caller receives it.
+
+`[GeneratedValue]` is in `Cratis.Arc.Commands.ModelBound` and applies only to
+parameters of a non-static command `Handle()`. Arc generates after `Provide()`
+control results permit execution, validates the concept, then invokes `Handle`.
+`Provide()` and DI cannot override it. Use a non-nullable self-generatable type,
+not raw `Guid`; names default to the parameter name or an explicit attribute name
+and are case-sensitive, non-empty and unique within the command.
+
+Keep client-chosen ids/references as inputs and services/read models as ordinary
+dependencies. A UUID is not a secret, token, authorization proof, idempotency key,
+or a gapless/sequential invoice number. For validation failures, captures,
+ARC0022–ARC0025, migration and the pinned-spec workflow, read
+[generated values](references/generated-values.md).
+
 ## Where the event source id comes from
 
 Chronicle resolves the command's event source id in this order:
@@ -330,8 +350,11 @@ Components guidance, not to this skill.
 - The event source id resolves from exactly one place; `ARCCHR0002` is silent.
 - `[Key]`, where used, is `Cratis.Chronicle.Keys.KeyAttribute`.
 - No `IEventLog` is injected into `Handle`.
-- Every value `Provide` returns is consumed by `Handle`.
-- Rejections are validation results, never thrown exceptions.
+- Every value `Provide` returns is consumed by an unmarked `Handle` parameter.
+- Generated parameters follow [generated values](references/generated-values.md)
+  and are pinned before scenario execution (`cratis-specifications-csharp`).
+- User-correctable rejections are validation results, never thrown exceptions;
+  `GeneratedValueRejected` instead signals a defective server generation strategy.
 - Every secret or personal value is marked before it can reach the event log.
 - `dotnet build` is clean in Debug and Release, with no suppressed `ARC*` or
   `ARCCHR*` diagnostic left unjustified.

package/package/corpus/skills/cratis-arc-command/references/generated-values.md

@@ -0,0 +1,166 @@
+# Server-generated Handle values
+
+## Contents
+
+- Declare the value and command
+- Resolution, validation and captures
+- Analyzer diagnostics
+- Migrate generation inside Handle
+- Pin generated values in specifications
+- Verified sources and release boundary
+
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+## Declare the value and command
+
+Generated parameters arrived in Arc **22.66.0**, scenario pinning in **22.67.0**,
+and analyzers in **22.68.0**. The examples and behavior here are verified at
+**v22.68.0**, which pins Fundamentals **7.23.0**.
+
+Use a concept for a server-owned new identifier. This standalone Arc example
+allocates an id; it does not append an event or persist a cart:
+
+```csharp
+// Copyright (c) Cratis. All rights reserved.
+// Licensed under the MIT license. See LICENSE file in the project root for full license information.
+
+using Cratis.Arc.Commands.ModelBound;
+using Cratis.Concepts;
+
+namespace Shopping.Carts;
+
+/// <summary>
+/// Represents a cart identifier.
+/// </summary>
+/// <param name="Value">The underlying identifier.</param>
+public record CartId(Guid Value) : ConceptAs<Guid>(Value), IGeneratable<CartId>
+{
+    /// <summary>
+    /// Creates a new cart identifier.
+    /// </summary>
+    /// <returns>A new cart identifier.</returns>
+    public static CartId New() => new(GenerateValue.Uuid());
+}
+
+/// <summary>
+/// Allocates a server-owned cart identifier.
+/// </summary>
+[Command]
+public record AllocateCartId
+{
+    /// <summary>
+    /// Returns the allocated identifier to the caller.
+    /// </summary>
+    /// <param name="cartId">The server-generated identifier.</param>
+    /// <returns>The allocated identifier.</returns>
+    public CartId Handle([GeneratedValue("cart")] CartId cartId) => cartId;
+}
+```
+
+For a Chronicle stream identity, derive `CartId` from `EventSourceId<Guid>`
+instead; see `cratis-fundamentals-concept`. Return `(id, event)` to both append
+and give the caller the new stream id, as in SKILL.md. An identifier is not an
+event, and generation alone does not persist anything.
+
+Keep existing/client-chosen identifiers and references on command properties.
+Services and read models remain ordinary dependencies, not generated values.
+UUID generation does not establish authorization, secrecy, idempotency, storage
+freshness, or gapless/sequential numbering. Use the domain's authoritative
+allocation mechanism for invoice numbers, not a random UUID strategy.
+
+## Resolution, validation and captures
+
+`GeneratedValueAttribute` targets parameters only. Use it on a command's public
+instance `Handle()`, not a property, constructor or `Provide()` parameter.
+The type must be non-nullable and implement `IGeneratable<TSelf>` for itself;
+a raw `Guid`, nullable concept or by-reference parameter is invalid. Use domain
+concepts; the runtime's type check is the self-generatable interface contract.
+
+`[GeneratedValue]` uses the parameter name. `[GeneratedValue("cart")]` keeps the
+pin/capture name stable across a parameter rename. Names are case-sensitive,
+non-whitespace and unique within the command.
+
+Arc first runs `Provide()` and checks its control results. Only if execution may
+continue does it call the concept's `New()` strategy and validate the value before
+invoking `Handle()`. Neither a provided value nor a DI registration overrides a
+generated parameter. Unmarked parameters retain their normal resolution.
+
+Discoverable concept validators run with the command's scoped provider and
+cancellation token. Errors produce `GeneratedValueRejected`, an exception
+outcome in `CommandResult`: a server-generation defect, not a request-validation
+400. Warnings/information allow execution. Fix the strategy or invariant; do not
+turn the defect into a user rejection or disable validation to make it pass.
+
+Validated values enter `CommandContext.GeneratedValues` in parameter-resolution
+order. Each capture has zero-based `Order`, `Name`, declared `Type` and `Value`;
+`Get<CartId>("cart")` retrieves the latest matching capture. Rejected values are
+not captured. A Handle parameter is not a request property and is not audited
+as command input. Do not log or trace captures or validator failure text, which
+can contain values. Returning a value or putting it in an event still follows the
+ordinary response, event and compliance contracts.
+
+## Analyzer diagnostics
+
+Arc v22.68.0 reports these at compile time; none has a code fix. Runtime
+handler-construction checks remain for declarations compiled without analyzers.
+
+| Diagnostic | Severity | Fix |
+| --- | --- | --- |
+| ARC0022 | Error | Use a non-nullable type implementing `IGeneratable<TSelf>` for itself; no raw `Guid` or by-reference parameter. |
+| ARC0023 | Error | Move the attribute to a non-static command `Handle()` parameter, not `Provide()`, a read model or controller. |
+| ARC0024 | Error | Give each generated parameter a non-empty unique name; comparison is case-sensitive. |
+| ARC0025 | Warning | Remove a redundant provided value of the generated type, or remove the attribute if `Provide()` should supply it. An unmarked parameter can still consume that provided type. |
+
+## Migrate generation inside Handle
+
+For `var id = new CartId(Guid.NewGuid());` or `var id = CartId.New();` in
+`Handle()`, keep the request contract unchanged:
+
+1. Make the concept implement `IGeneratable<CartId>` with static `New()` using
+   `GenerateValue.Uuid()` or `GenerateValue.UuidV7()`.
+2. Replace the local allocation with `[GeneratedValue("cart")] CartId cartId`
+   on `Handle()`, then use that parameter in the existing return/operation shape.
+3. Return the id if the caller needs it; a capture is not an automatic response.
+4. Pin the concept by generated name in pipeline specifications. For a pure
+   direct-call specification, pass the known concept to `Handle()` yourself.
+
+Do not migrate caller-owned inputs into server generation. A retried request
+would otherwise allocate a different value; random generation is not an
+idempotency mechanism. UUIDv7 reveals creation time and is not monotonic within
+a millisecond; choose it for index locality only after checking storage ordering.
+
+## Pin generated values in specifications
+
+Use `cratis-specifications-csharp` and its `references/application-scenarios.md`
+for the complete pinned example. `Cratis.Arc.Testing.Commands` supplies
+`PinGeneratedValue(name, concept)`, `AllowGeneration()` and the `GeneratedValues`
+capture helpers on `CommandScenario<TCommand>`.
+
+Scenarios default to strict: an unpinned generated parameter yields
+`GeneratedValueNotPinned` in the command result, not a throw from `Execute`.
+Configure before execution. Nested pins use both generic arguments at the call
+site: `PinGeneratedValue<TCommand, TOtherCommand>(name, concept)`.
+
+## Verified sources and release boundary
+
+Published guides:
+
+- [Generated values](/arc/backend/csharp/commands/generated-values/)
+- [Pin generated values in command specs](/arc/backend/csharp/testing/generated-values/)
+- [Migrate generated identifiers](/arc/upgrading/generated-values/)
+- Analyzer pages: [ARC0022](/arc/backend/csharp/code-analysis/arc0022/),
+  [ARC0023](/arc/backend/csharp/code-analysis/arc0023/),
+  [ARC0024](/arc/backend/csharp/code-analysis/arc0024/),
+  [ARC0025](/arc/backend/csharp/code-analysis/arc0025/).
+
+Source at **Arc v22.68.0**: `Source/DotNET/Arc.Core/Commands/ModelBound/GeneratedValueAttribute.cs`,
+`Commands/GeneratedValueParameters.cs`, `GeneratedValueFactories.cs`,
+`CommandHandlerArgumentResolver.cs`, `GeneratedValueResolution.cs`;
+`Source/DotNET/Arc.Core.CodeAnalysis/DiagnosticDescriptors.cs`; and
+`Source/DotNET/Testing/Commands/CommandScenarioGeneratedValueExtensions.cs`.
+
+This release has no freshness/collision guard, contextual clock/tenant/pattern
+generation, or additional built-in strategies beyond Fundamentals' UUID/UUIDv7
+helpers. Do not teach proposals as available APIs or invent Screenplay `generate`
+syntax for this feature.

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

@@ -45,6 +45,11 @@ This skill is verified against these exact sources:
 | `Cratis.Chronicle` | `18.3.0` | `Cratis.Chronicle.Reactors`, `Cratis.Chronicle.Reactors.SideEffects`, `Cratis.Chronicle.EventSequences`, `Cratis.Chronicle.Events` |
 | `Cratis.Chronicle.CodeAnalysis` | `18.3.0` | `CHR0004`, `CHR0005`, `CHR0008`, `CHR0013`, `CHR0022`, `CHR0031`, `CHR0032` |
 
+Scenario read-model seeding/absence, synchronous handler exception propagation,
+and the `EventContext.From` UTC default are verified separately at **Chronicle
+19.46.0**; they require **19.46.0+**. See the source paths in
+[references/specifications.md](references/specifications.md).
+
 Reverify product sources before claiming support for another version.
 
 > **There is no `ReactorSideEffect` type.** It does not exist in Chronicle, in
@@ -363,7 +368,17 @@ when they serve that concern.
 
 Start with `Specification` plus a direct call for pure reactor decisions; add `ReactorScenario<TReactor>` only where invocation, dependency wiring or side effects contribute proof. Specify the contract, not only the happy path: field lineage, contract-authorized filtering, repeated delivery, and unrelated events.
 
-Read [references/specifications.md](references/specifications.md) when writing or reviewing reactor specifications.
+In Chronicle **19.46.0+**, a handler's unseeded read-model parameter throws
+`ReadModelNotSeededForReactorScenario`, even if nullable. Seed it through
+`Given.ForEventSourceId(id).ReadModel(instance)`, or declare intentional absence
+with `.NoReadModel<T>()`. Use the resolved read-model key; `Given` events do not
+build read models, including passive ones. A synchronous handler throw surfaces
+the handler's exception rather than a reflection wrapper, and the scenario's
+`EventContext.Occurred` defaults to UTC.
+
+Read [references/specifications.md](references/specifications.md) before writing
+or reviewing reactor specifications; it shows both setup alternatives and the
+scope of these scenario-only guards.
 
 ## Verify
 

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

@@ -1,3 +1,12 @@
+# Reactor specifications
+
+## Contents
+
+- Specifications
+- Read-model setup — Chronicle 19.46.0+
+- Exceptions and occurrence time — Chronicle 19.46.0+
+- Contract coverage
+
 ## Specifications
 
 Start with `Specification` plus a direct call for pure reactor decisions,
@@ -9,6 +18,82 @@ non-event side effects; for handlers that return events, assert the resulting
 appends through the scenario's event store. Cover the replay path separately
 when the reactor has `[OnceOnly]` or `[Replay]` handlers.
 
+## Read-model setup — Chronicle 19.46.0+
+
+Class-based `ReactorScenario<TReactor>` does not build read models from `Given`
+events, **including passive models**. Seed a pre-built instance in `Establish()`:
+
+```csharp
+void Establish() => _scenario.Given.ForEventSourceId(_id).ReadModel(_order);
+async Task Because() => await _scenario.Given.ForEventSource(_id).Events(_orderPlaced);
+```
+
+For a **separate absence specification**, use this setup instead, so an `Order?`
+handler parameter deliberately receives `null`:
+
+```csharp
+void Establish() => _scenario.Given.ForEventSourceId(_id).NoReadModel<Order>();
+```
+
+The builders live in `Cratis.Chronicle.Testing.Reactors`. Exact signatures on
+`ReactorSourceGivenBuilder<TReactor>` (`where TReactor : class, IReactor`):
+
+```csharp
+public ReactorSourceGivenBuilder<TReactor> ReadModel<TReadModel>(TReadModel readModel)
+    where TReadModel : class;
+public ReactorSourceGivenBuilder<TReactor> NoReadModel<TReadModel>()
+    where TReadModel : class;
+public Task Events(params object[] events);
+```
+
+Both `Given.ForEventSource(EventSourceId)` and
+`Given.ForEventSourceId(EventSourceId)` return this builder. Seed or declare
+absence using the triggering source id by default, or the key returned by
+`ICanResolveReadModelKey.Resolve` when implemented. Declarations are shared
+across the scenario's builders, match the **exact type and key**, and do not
+remove a seeded instance. Do not declare absence to hide forgotten setup.
+
+If a recognized read-model parameter resolves to `null` without declared
+absence, `Events(...)` throws `ReadModelNotSeededForReactorScenario` from
+`Cratis.Chronicle.Testing.Reactors`, **even for nullable parameters**. Its message
+names the full read-model type and key, tells you to seed via `ReadModel(...)`
+or declare `NoReadModel<T>()`, and lists other seeded keys for that type when
+any exist. Check the key first if the fixture already seeds that type. This
+guard applies only when the scenario uses `EventStoreForTesting` (including an
+explicit instance); an explicitly supplied store of another type and production
+read-model resolution are unchanged.
+
+## Exceptions and occurrence time — Chronicle 19.46.0+
+
+`Events(...)` rethrows a synchronously throwing handler's **own exception**,
+unwrapping the `TargetInvocationException` previously surfaced by reflection,
+and preserves the handler stack. Capture with
+`await Catch.Exception(() => _scenario.Given.ForEventSource(_id).Events(_orderPlaced))`
+and assert the handler's exception type, not a reflection wrapper.
+
+`EventContext.From(...)` defaults omitted `occurred` to `DateTimeOffset.UtcNow`
+(previously `DateTimeOffset.Now`). `ReactorScenario` uses this helper, as do
+`EventContext.Empty` and `EmptyWithEventSourceId(...)`. Explicit timestamps keep
+their supplied offset; the positional constructor does not default `Occurred`.
+For deterministic time-dependent plain-call specs, supply a fixed occurrence
+time rather than asserting an exact current instant.
+
+Verified against **Chronicle tag `v19.46.0`**:
+
+- `Source/Clients/Testing/Reactors/ReactorSourceGivenBuilder.cs` and
+  `ReactorScenarioGivenBuilder.cs`: seeding, absence and builder signatures.
+- `Source/Clients/Testing/Reactors/ScenarioReactorMethodArgumentsResolver.cs` and
+  `ReadModelNotSeededForReactorScenario.cs`: guard scope, resolved key and message.
+- `Source/Clients/Testing/Reactors/ReactorScenario.cs`: synchronous exception
+  unwrapping and context creation.
+- `Source/Clients/DotNET/Events/EventContext.cs`: UTC default and explicit time.
+- `Source/Clients/Testing.Specs/Reactors/for_ReactorScenario/when_resolving_read_model_dependencies/`:
+  seeded, absent, nullable, passive, custom-key and explicit-store examples.
+- `Source/Clients/Testing.Specs/Reactors/for_ReactorScenario/when_a_reactor_handler_throws_synchronously.cs`
+  and `when_a_reactor_reads_the_occurrence_time.cs`: handler exception and UTC specs.
+
+## Contract coverage
+
 Specify the contract, not only the happy path:
 
 - **Field lineage.** For each returned command or event, a specification asserts

package/package/corpus/skills/cratis-fundamentals-concept/SKILL.md

@@ -78,10 +78,14 @@ Do not assume `string.Empty`, `0`, or `Guid.Empty` is universally invalid.
 
 ## Let a concept generate its own value
 
-Check the Cratis.Fundamentals version the project resolves first. Arc and
-Chronicle can bring an older one; when it is below 7.23.0, add a direct
-`Cratis.Fundamentals` 7.23.0 or later package reference, or keep the existing
-`static New()` (without the interface) until you can.
+Check the Cratis.Fundamentals version the project resolves first. Arc first
+pinned **7.23.0 in v22.66.0** (also verified at v22.68.0); the older-version
+caveat is not a reason to add a direct reference for Arc 22.66.0+ when it already
+resolves 7.23.0 or later. Chronicle **v19.43.0** still pins **7.22.0** in
+`Directory.Packages.props`. For older Arc or Chronicle-only applications, when
+the resolved version is below 7.23.0, add a direct `Cratis.Fundamentals` 7.23.0
+or later package reference, or keep the existing `static New()` (without the
+interface) until you can.
 
 When the system, not the caller, creates a value, the concept declares how by
 implementing `IGeneratable<TSelf>` (`Cratis.Concepts`, Cratis.Fundamentals
@@ -123,7 +127,11 @@ Do not generate when:
 
 In specifications, construct the concept from a known value
 (`new <ConceptName>(Guid.Parse("…"))`) and assert against it. Do not seed or
-replace the generator. Guide: `/fundamentals/csharp/generating-values/`.
+replace the generator. In Arc **22.66.0+**, let a server-owned new identifier
+reach `Handle()` through `[GeneratedValue]` rather than calling `New()` inside
+it; see `cratis-arc-command` for declaration and migration, and
+`cratis-specifications-csharp` for named scenario pins (Arc **22.67.0+**).
+Guide: `/fundamentals/csharp/generating-values/`.
 
 ## Create a Guid-backed Chronicle stream identity
 

package/package/corpus/skills/cratis-screenplay-automations-and-translations/SKILL.md

@@ -34,8 +34,9 @@ identity, effect and pending-work contract at that point; do not postpone it to
   planner audits through v7. Deliver that scope as authorized gap-fill
   (`references/realization-and-gap-fill.md`).
 - Reaction `runs as system role "<Role>"` declares an invocation actor (ESM v10).
-  Without it the invoke has no caller. CLI 3.41.0's 4.114.0 compiler rejects the
-  new syntax (PLAY0137). Checked model/diagnostics: captures-and-reactions
+  Without it the invoke has no caller. Historical CLI 3.41.0's 4.114.0 compiler
+  rejected the syntax (PLAY0137); current CLI 3.46.1 instead refuses ESM v10
+  at render admission (CLI-RENDER-004). Checked model/diagnostics: captures-and-reactions
   `references/invocation-identity.md`.
 
 ## Effect guarantees and recovery traps

package/package/corpus/skills/cratis-screenplay-automations-and-translations/references/audit-format.md

@@ -11,8 +11,8 @@ technique: partial work stays visible and nothing is skipped because it looked r
 
 Result is `complete` only when every column is filled or says why it does not apply (for example
 "direct effect: immediate, internal, cannot fail"). `open` names the unresolved decision and who
-answers. `blocked` names the actual capability gap (for example CLI 3.41.0's
-older compiler cannot parse a declared ESM v10 reaction actor) with intended behavior.
+answers. `blocked` names the actual capability gap (for example current CLI
+3.46.1 refuses ESM v10 at render admission with CLI-RENDER-004) with intended behavior.
 
 ## Per translation (capture or translator reaction)
 | Source and type | Location | Correlation | Field dispositions | Target fields traced | Dedup and ordering | Trust boundary | Recovery owner | Named cases | Result |

package/package/corpus/skills/cratis-screenplay-automations-and-translations/references/automation-patterns.md

@@ -71,8 +71,10 @@ When a todo list is not needed: the effect is immediate, internal and cannot fai
 Screenplay 4.125.0 declares the actor with reaction-level `runs as system role
 "<Role>"` (ESM v10); without it a gated invocation has no caller and denies.
 `given caller` is not an invocation actor. Role requirements remain enforced;
-claim conditions for this system principal remain unknown. CLI 3.41.0's older
-compiler rejects the syntax (PLAY0137), and Stage 4.51.3 admits through v7 only.
+claim conditions for this system principal remain unknown. Historical CLI 3.41.0's
+older compiler rejected the syntax (PLAY0137). Current CLI 3.46.1 bundles
+Screenplay 4.130.0 / Stage 4.52.0 and refuses v10 at render admission
+(CLI-RENDER-004; toolchain `references/versions.md`).
 Use the checked model in captures-and-reactions `references/invocation-identity.md`.
 Arc gap-fill uses `[ExecuteCommandsAsSystem("<role>")]` for returned commands,
 not identity inferred from prose or an imperative pipeline call.

package/package/corpus/skills/cratis-screenplay-automations-and-translations/references/provenance.md

@@ -40,7 +40,9 @@ Changes in this version: the examples are complete fenced documents that compile
 example's anonymous-booking spec gained the `given caller` PLAY0389 requires; the todo-list
 example's list query, `reads` and retry sweep moved to marked design-only excerpts so the core
 binds); tool-qualified verdict text; the trusted-actor text now names `[ExecuteCommandsAsSystem]`
-(Arc v20.56.0). Current actor syntax was reverified at Screenplay v4.125.0
+(Arc v20.56.0). Actor syntax was reverified at Screenplay v4.125.0
 `reactions.md`, `ReactionIdentityParser.cs`, `ReactionRefusalValidator.cs` and the
-binder's v10 selection; the checked scenario passes reference execution. CLI
-3.41.0's older parser and Stage 4.51.3's v7 planner remain target limits.
+binder's v10 selection; the checked scenario passed reference execution. CLI
+3.41.0's older parser and Stage 4.51.3's v7 planner were historical target limits.
+Current CLI 3.46.1 bundles Screenplay 4.130.0 / Stage 4.52.0 and still refuses
+v10 at render admission (CLI-RENDER-004; toolchain `references/versions.md`).

package/package/corpus/skills/cratis-screenplay-captures-and-reactions/SKILL.md

@@ -75,8 +75,9 @@ reference invocation's authenticated system principal with exactly those roles;
 Read [invocation identity](references/invocation-identity.md) for the checked
 scenario, claim/unknown semantics and PLAY0647–0652/0557 diagnostics.
 
-CLI 3.41.0's 4.114.0 compiler rejects this source with PLAY0137; its version gate
-and Stage 4.51.3 planner admit only through v7. Target realization is gap-fill,
+Historical CLI 3.41.0's 4.114.0 compiler rejected this source with PLAY0137.
+Current CLI 3.46.1 bundles Screenplay 4.130.0 / Stage 4.52.0; its render version
+gate still admits only through v7 (CLI-RENDER-004 for v10). Target realization is gap-fill,
 using Arc `[ExecuteCommandsAsSystem]` for returned commands. Without that attribute
 Arc supplies no principal and `[Authorize]`/`[Roles]` deny. Each invoked command
 is atomic, not the whole cascade; earlier accepted facts remain after a later refusal.

package/package/corpus/skills/cratis-screenplay-captures-and-reactions/references/invocation-identity.md

@@ -69,11 +69,12 @@ module Work
   denial; opaque/unknown cases are not guessed. `--check privilege` (PLAY0652)
   reviews whether event producers require every elevated role, not runtime safety.
 
-CLI 3.41.0 bundles Screenplay 4.114.0, which does not parse `runs as`: the example's
-`cratis screenplay validate --executable --warnings-as-errors` returns PLAY0137,
-exit 5. It cannot render this source. Its render version gate separately admits
-only through v7 (CLI-RENDER-004 for newer admitted compiler output), while Stage
-4.51.3's direct planner audits through v7 and refuses v10 with STAGE-ESM-016.
+Historical CLI 3.41.0 bundled Screenplay 4.114.0, which did not parse `runs as`:
+the example's `cratis screenplay validate --executable --warnings-as-errors`
+returned PLAY0137, exit 5. This is not a current parser claim. Current CLI 3.46.1
+bundles Screenplay 4.130.0 but its render gate still admits only through v7
+(CLI-RENDER-004 for v10); bundled Stage 4.52.0's direct planner audits through
+v7 and refuses v10 with STAGE-ESM-016 (`references/versions.md` in toolchain).
 Clock/application-trigger identities have no Stage Arc realization either.
 Use authorized gap-fill with the model as contract; returned-command Arc identity
 uses `[ExecuteCommandsAsSystem]`, never permission inferred from a model header.

package/package/corpus/skills/cratis-screenplay-captures-and-reactions/references/specifying-triggers-and-clock.md

@@ -19,7 +19,7 @@ specification IssuingTheWeeklyDigest
 
 Under `cratis` before 3.28.2 these actions parsed and were checked against the application
 but bound to nothing (`PLAY0268` names ESM v6, decision 0022); on 3.28.2 they bind.
-Current standalone 4.125.0 executes admitted scenarios through `screenplay test`
+Standalone 4.125.0 (checked; current pins in the toolchain `versions.md`) executes admitted scenarios through `screenplay test`
 or MCP `run-specifications`; source compilation alone is authored evidence.
 Clock rules: the clock is UTC and exact; an
 occurrence fires once when it is **due after `given clock` and at or before