@cratis/pi 7.34.1 → 7.35.0

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

@@ -20,6 +20,7 @@ A command's `Handle()` is an ordinary method; with dependencies resolved by `Pro
 |---|---|---|
 | `Specification` (plain call) | `Handle()`, `Handle(providedValue)`, reducer logic or a reactor's decision as a method call; or an isolated class with mocked collaborators | **default** for a decision that is a pure function of its arguments |
 | `CommandScenario<TCommand>` | the real Arc command pipeline — authorization + validators + `Provide()` + `Handle()` + appended events | the pipeline, validation, authorization, or appended events matter (State Change slices) |
+| `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) | **default for projections**, which are declarative (State View slices) |
 | `ReactorScenario<TReactor>` | reactor handler invocation + side effects via mocked services | the reactor wiring and side effects (Automation / Translation slices) |
@@ -74,7 +75,7 @@ public class and_all_information_is_valid : Specification
 - `CommandScenario<TCommand>` exposes `Services` (an `IServiceCollection`), `Context`, `Execute(command[, ct])`, `Validate(command)`, `LastResult`, `Operations` and the operation assertions `ShouldHaveExecutedOperation<T>()` / `ShouldHaveCompensatedOperation<T>()` / `ShouldHaveNoOperationInvocations()`; with the Chronicle integration it also gains `Given`, `EventScenario`, `EventLog`, `EventSequence` and `AppendedEvents` as extension members. Everything else is configured through `Services` and asserted with extension methods.
 - **Event assertions are extension methods on the scenario** (from the Chronicle testing package), keyed by **command + event** type: `await _scenario.ShouldHaveAppendedEvent<TCommand, TEvent>(eventSourceId)` or the `(eventSourceId, Func<TEvent,bool> predicate)` overload; plus `await _scenario.ShouldHaveTailSequenceNumber<TCommand>(...)`. They return `Task`, so the fact is `async Task`.
 - **`CommandResult` assertions** (Arc extensions): `ShouldBeSuccessful()`, `ShouldNotBeSuccessful()`, `ShouldBeValid()`, `ShouldHaveValidationErrors()`, `ShouldHaveValidationErrorFor(message)`, `ShouldBeAuthorized()`, `ShouldNotBeAuthorized()`, `ShouldHaveExceptions()`/`ShouldNotHaveExceptions()`.
-- **Seed prior state through `_scenario.Given` or `_scenario.Services`.** `_scenario.Given.ForEventSource(id).Events(...)` materializes the seeded events into an **in-memory read-model dictionary** the harness answers keyed reads from — it never reaches the event log (see the false-greens list below). To populate the DCB read models the validator/`Provide()`/`Handle()` inject, substitute `IReadModels` and register it (`_scenario.Services.Replace(new ServiceDescriptor(typeof(IReadModels), mock))`, mocking `GetInstanceById(...)`) or register projections with `_scenario.Services.AddReadModels(...)`.
+- **Seed prior state through `_scenario.Given` or `_scenario.Services`.** `_scenario.Given.ForEventSource(id).Events(...)` materializes the seeded events into an **in-memory read-model dictionary** the harness answers keyed reads from — in **legacy mode** it never reaches the event log (see the false-greens list below). To populate advisory read models the validator/`Provide()`/`Handle()` inject, substitute `IReadModels` and register it (`_scenario.Services.Replace(new ServiceDescriptor(typeof(IReadModels), mock))`, mocking `GetInstanceById(...)`) or register projections with `_scenario.Services.AddReadModels(...)`.
 - **Validator/`Provide()` dependencies:** register them in `_scenario.Services`; Arc testing discovers the concrete validator automatically. When several specs need different injected validator states, test rejected variants by instantiating the validator directly (per-scenario state can be order-sensitive under parallel xUnit).
 - **`Provide()`:** drive it through `CommandScenario` end-to-end; when the handler's decision is pure given provided data, test `Handle(providedValue)` directly as the default decision spec and keep the scenario for the wiring.
 - **Command operations:** use **cratis-arc-command-operation** for decision/adapter specs and real `CommandScenario` execution, forward failure, compensation, and Chronicle commit rejection; a direct `Handle()` does not execute operations.
@@ -99,14 +100,29 @@ Each of these passes while proving nothing. They are the reason the two-assertio
 1. **A discarded assertion `Task`.** The `IEventSequence` assertions `ShouldHaveAppendedEvent`/`ShouldHaveTailSequenceNumber` (Chronicle Testing) are genuinely `async`: in a `void [Fact]` that does not `await` them the exception lands on a `Task` nobody observes and the spec passes regardless of behavior, while the compiler's `CS4014` stays silent outside an `async` method. (The same-named `CommandScenario` overloads in Arc's Chronicle.Testing throw synchronously and only *return* a completed `Task`, so those fail even when discarded — but you cannot tell the two apart at the call site.) Make the fact `async Task` and `await` every `Task`-returning `Should*`. Chronicle's analyzer **`CHR0039` (`NonAwaitedAssertion`)** reports any discarded `Task`/`ValueTask`-returning `Should*` call from a Cratis testing package (Chronicle's and Arc's alike).
 2. **A dependency the spec forgot to seed.** When a validator's constructor, `Provide()` or `Handle()` asks for a read model that does not exist for the command's key, the validator is never built and no rule runs — yet the command is rejected (one validation result, reason **`DependencyUnavailable`**, HTTP 400), so `ShouldNotBeSuccessful()` passes and keeps passing with the rule it is named after deleted. `ShouldHaveValidationErrors()` **refuses** a result whose only errors carry that reason and tells you to seed the read model — or, when that rejection *is* the behavior under spec, assert it deliberately with `ShouldHaveValidationErrorBecauseOf(ValidationResultReason.DependencyUnavailable)`. A missing *service* (not a read model) surfaces as an exception instead (`ShouldHaveExceptions()`), and `ShouldNotBeSuccessful()` alone cannot tell the two apart from a genuine rejection.
 3. **`.Validate()` authorizes first.** `Validate(command)` runs the command filters, and authorization filters are ordered before validation. A validate-only spec on a `[Roles]`/`[Authorize]` command with no identity registered is denied for authorization — the rule it is named after never ran. Register the identity, or assert `ShouldNotBeAuthorized()` and say so in the name.
-4. **Constraint preconditions go to the event log, not `CommandScenario.Given`.** `_scenario.Given.ForEventSource(id).Events(...)` on a `CommandScenario` seeds an **in-memory read-model materialization only**; nothing reaches the event log a `[Unique]`/`IConstraint` is enforced against, so a "second registration with the same name" spec passes because the first one was never appended. Seed constraint preconditions through **`EventScenario`**'s `Given`, and assert the violation by constraint **name** (`ShouldHaveConstraintViolationFor`) — the same helper exists on `CommandResult` and on `IAppendResult`.
-5. **`GetInstances<T>` is not harness-backed.** Under `CommandScenario` the read-model harness answers keyed reads (`GetInstanceById`) from its seeded dictionary and forwards `GetInstances<T>`/`GetSnapshotsById`/`Watch` to the real client, which is not there. Code under spec that enumerates a read model needs a fake lookup registered in `Services`, not `Given`.
+4. **Legacy-mode constraint preconditions go to the event log, not `CommandScenario.Given`.** `_scenario.Given.ForEventSource(id).Events(...)` on a `CommandScenario` seeds an **in-memory read-model materialization only**; nothing reaches the event log a `[Unique]`/`IConstraint` is enforced against, so a "second registration with the same name" spec passes because the first one was never appended. Seed constraint preconditions through **`EventScenario`**'s `Given`, and assert the violation by constraint **name** (`ShouldHaveConstraintViolationFor`) — the same helper exists on `CommandResult` and on `IAppendResult`.
+5. **Legacy `GetInstances<T>` is not harness-backed.** Under legacy `CommandScenario` the read-model harness answers keyed reads (`GetInstanceById`) from its seeded dictionary and forwards `GetInstances<T>`/`GetSnapshotsById`/`Watch` to the real client, which is not there. Code under spec that enumerates a read model needs a fake lookup registered in `Services`, not `Given`.
 6. **One child is not a children spec.** `[ChildrenFrom<T>]` without `key:` identifies children by the **event source id**, so every child event on one stream upserts the same child and a one-child spec stays green with the key wrong. Drive **two** children with distinct keys and assert the count.
 7. **Independently derived expectations.** An expected value computed in the spec with the same expression as the code under spec agrees with it by construction. Write the expected literal.
 
 The `ReadModelScenario` and `EventScenario` equivalents of these live in the **cratis-chronicle-read-model-specifications** and **cratis-chronicle-event-specifications** skills.
 
-> **Validator-state order-sensitivity:** the command-scenario pipeline can cache enough state to make injected-validator branches order-sensitive when xUnit runs classes in parallel. Use `CommandScenario` for the valid path, test rejected state-variants by **instantiating the validator directly**, and — only for that validator-state case — put the command's specs in a **small xUnit `[Collection]`**. (This is distinct from the unique-value-collision rule below, where `[Collection]` is the *wrong* fix.)
+> **Historical validator-state order-sensitivity:** observed in the 22.16-era harness. Arc 22.23.2 stopped replacing the process-wide provider; later releases isolated scenario stores and event-source services. Reproduce at 22.75.0 before applying the old direct-validator/small `[Collection]` workaround. No current reproduction is verified here.
+
+#### Query and protected-decision modes (Arc v22.75.0)
+
+`QueryScenario<TReadModel>` (`Cratis.Arc.Testing.Queries`) runs `Perform(nameof(Model.Method),
+arguments?, paging?, sorting?)`; `Observe(...)` returns `QueryObservation.Initial`
+and buffered `Next()`. Configure principal/policies in `Services`; schemes fail
+closed without HTTP. Chronicle query `Given` can seed keyed models/events.
+
+For guarded commands use `UseDecisionReads()` **before** seeding events. Given
+state, guarded reads and appends share one real in-process log, unlike legacy
+mode above. Pinned models cannot supply guards. Use `OnRoute(route)` and
+`AppendConcurrently` to prove conflicts; `ShouldHaveCompletedStream` proves
+completion and `DecisionReadAdmissions.ShouldAdmitDecisionReadsIn(assembly)`
+checks admission. See **cratis-application-slice-specifications**,
+`references/query-and-decision-scenarios.md`, for sources and limitations.
 
 ### `EventScenario` — constraints & append semantics
 
@@ -144,6 +160,14 @@ Use the named-parameter constructor when services/initial state are needed: `new
 
 **Bridging `IReadModels` into a `CommandScenario`** (current harness limitation): when a command handler injects `IReadModels` directly, build a focused `ReadModelScenario<T>`, seed it via `Given.ForEventSourceId(id).ReadModel(...)`, then register its read models into the command scenario — `_scenario.Services.AddSingleton(readModelScenario.ReadModels)`. Pass `scenario.ReadModels` into code under test for keyed `GetInstanceById` reads; for non-key searches/filters, register a fake lookup or an `IMongoCollection<T>` mock in the scenario services instead.
 
+**Chronicle v19.50.0 scenario additions** (`Source/Clients/Testing/ReadModels/`):
+`WithProjection(Action<IProjectionBuilderFor<T>>)` overrides discovery, including
+reducers. `Given.ForEventSource(id).OnStream(eventSourceType, eventStreamType,
+eventStreamId).Events(...)` seeds routing for filtered reducers; unrouted events
+do not reach a differently filtered handler. Dispose scenarios in `Destroy()`.
+Per-run `Defaults(clientArtifactsProvider, serviceProvider, options)` supports
+`InMemoryClientArtifactsProvider` and `ExplicitArtifacts` without global discovery.
+
 **Skip discipline:** don't pre-emptively `[Fact(Skip=...)]` a read-model assertion — assume scalar `ConceptAs<string>`, enum, and identifier properties populate correctly; if one fails, investigate the projection. Only skip on a *reproduced* harness gap, and put the specific reason in the skip message.
 
 ### `ReactorScenario<TReactor>` — Automation / Translation
@@ -160,6 +184,13 @@ async Task Because() => await _scenario.Given.ForEventSource(_id).Events(new Aut
 [Fact] async Task should_notify() => await _service.Received(1).Notify("Jane Austen");
 ```
 
+In **Chronicle v19.50.0** (`Source/Clients/Testing/Reactors/`), `OnStream` also
+applies to class-based and fluent reactors. `ProducedEvents` carries payload and
+destination; `ShouldHaveProduced<TEvent>(eventSourceId)` or the predicate
+`((produced, @event) => ...)` verifies cross-stream routing. The non-generic
+`ReactorScenario(reactorId, defaults)` exercises an explicitly registered reactor.
+Dispose each scenario in `Destroy()`; await async assertions (CHR0039).
+
 #### Read-model setup — Chronicle 19.46.0+
 
 In a class-based `ReactorScenario<TReactor>`, `Given` events invoke the reactor;

package/package/corpus/rules/specs.typescript.md

@@ -78,7 +78,8 @@ export class an_events_command_response_value_handler {
 ```
 
 - Properties are public (not protected) — tests access them via `context.propertyName`.
-- Import `given` from the package root: `import { given } from '../../given';`.
+- `given` is a package-local helper file, not a published export. Import it with the relative path to that file, for example `import { given } from '../../given';`; create it if absent. Fundamentals v7.23.0 constructs parameterless contexts; Arc v22.75.0 passes the Mocha Suite and binds callback `this` to it.
+- Configure Vitest's setup file to call `chai.should()` and register `sinon-chai` and `chai-as-promised`. Load the reflection polyfill for metadata-dependent specifications.
 - Simple tests without shared setup don't need a reusable context.
 
 ## Simple Test Pattern (without context)

package/package/corpus/rules/storybook.md

@@ -17,7 +17,7 @@ Good candidates: a presentational card/list-item/form-field with multiple visual
 
 ## Preview infrastructure (what you get for free)
 
-A configured `.storybook/preview` should wrap every story in `CratisComponentsProvider` (from `@cratis/components`) and import `@cratis/components/tokens`, `@cratis/components/styles` and (for the baseline look) `@cratis/components/theme` — the same three entries the app imports — so components render styled. With that in place:
+A configured `.storybook/preview` should wrap every story in `CratisComponentsProvider` (from `@cratis/components`) with `toaster` when stories show notifications. Import one `index.css` containing `@import '@cratis/components/tokens'`, `@import '@cratis/components/styles'` and (for the baseline look) `@import '@cratis/components/theme'`, each terminated by a semicolon — the same entries as the app. CSS imports from TypeScript need ambient declarations on TypeScript 6; keeping the subpaths in CSS avoids TS2882. Mount only one toaster. With that in place:
 
 - **Auto prop tables** via `react-docgen-typescript` — a component's `interface` + per-prop JSDoc renders as a Docs prop table, and union props become `select` controls automatically. Keep a JSDoc comment on every prop. **`argTypes` is an override layer** (change control type, group under `table.category`, disable a control) — don't re-list every prop.
 - **Accessibility panel** (`@storybook/addon-a11y`) scans each story with axe-core. Treat new violations as defects.

package/package/corpus/rules/typescript.md

@@ -121,7 +121,7 @@ All identifiers, comments, JSDoc, and string literals must use **American Englis
 
 ## Folder Structure
 
-- **Never give a `.tsx` the same basename as a `.ts` in the same folder.** The Arc proxy generator emits `<Slice>.ts` beside the slice's C#; a component named `<Slice>.tsx` next to it is **silently dropped from the program**: for one basename TypeScript keeps only the `.ts`, so the component's type errors are never reported and `tsc -b` stays green while the file is broken (reproduced on TypeScript 6.0.3 and 7.0.2 with `include: ["src/**/*"]`). Name the component for what it renders (`Listing.tsx`, `RegisterAuthor.tsx`), never for the slice, and consider a repository spec that fails on any `.tsx` with a sibling `.ts` of the same name.
+- **Never give a `.tsx` the same basename as a `.ts` in the same folder.** The Arc proxy generator emits `<Slice>.ts` beside the slice's C#; a component named `<Slice>.tsx` next to it is **silently dropped from the program**: for one basename TypeScript keeps only the `.ts`, so the component's type errors are never reported and `tsc -b` stays green while the file is broken (reproduced on TypeScript 6.0.3 and 7.0.2 with `include: ["src/**/*"]`). At Arc v22.75.0 use `<CratisProxiesUseProxyFileSuffix>true</CratisProxiesUseProxyFileSuffix>` to emit `<Slice>.proxy.ts` with matching barrels; that is the clean generator fix. Otherwise name the component for what it renders (`Listing.tsx`, `RegisterAuthor.tsx`), never for the slice, and consider a repository spec that fails on any `.tsx` with a sibling `.ts` of the same name.
 - Do not prefix a file, component, type, or symbol with the name of its containing folder or the concept it belongs to. Instead, use folder structure to provide that context.
 - Favor functional folder structure over technical folder structure.
   - Group files by the feature or concept they belong to, not by their technical role.

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

@@ -88,7 +88,7 @@ The command carries input from the caller. `Handle()` is defined directly on the
 | Reusable value invariant (length, format, range) | `ConceptValidator<T>` on the concept type |
 | Command-input / cross-field / pre-handler rule (incl. injected read-model/service/identity checks) | `CommandValidator<TCommand>` with `RuleFor(...)` |
 | Handler needs fetched/computed data before it can build the event | `Provide()` — fetches the data; may validate it and short-circuit |
-| State-dependent rule that must hold **under concurrency** | inject the read model into `Handle()`, return `Result<TEvent, ValidationResult>` |
+| State-dependent rule that must hold **under concurrency** | `IStreamReads`/`StreamDecision` for one stream, or `[ProtectedDecision]` + `DecisionRead<T>` for admitted projected state; plain injection is advisory |
 | Uniqueness | Chronicle `[Unique]` / `IConstraint` (race-safe) — not a read-model pre-check |
 | Genuinely exceptional failure (bug, missing infra) | `throw` a domain exception |
 
@@ -164,7 +164,7 @@ Return the event(s) directly — Arc appends them; never inject `IEventLog` to a
 | `(EventSourceId, TEvent)` | command decides the event source id (tuple order doesn't matter) |
 | `(TResponse, TEvent)` | a response value plus an event |
 | `IEnumerable<object>` | multiple events; `EventForEventSourceId(id, @event)` wrappers for cross-stream |
-| `Result<TEvent, ValidationResult>` | success event or a typed validation error (concurrency-sensitive rule) |
+| `Result<TEvent, ValidationResult>` | success event or a typed validation error; does not itself guard concurrency |
 | `ICommandOperation` / `CommandOperations` | immediate server-side work after event enrollment, never the client response |
 | `void` | no event |
 
@@ -182,7 +182,25 @@ Three attributes scope an append broad→narrow, and each one *also* (only with
 
 Each attribute always tags the appended events (visible in `EventContext`). **Only when the command also carries `concurrency: true`** does each dimension join the server-side `ConcurrencyScope` (plus the event source id), with the optimistic strategy supplying the expected tail sequence number. A command **without** `concurrency: true` contributes no scope of its own, and the append falls to whatever concurrency strategy the event sequence is configured with — by default the optimistic one, scoped to the event source. So the attribute chooses *which dimensions* bound the check, not whether a check happens at all. Reach for it on high-contention state transitions where a stale read would let two commands both "win" — it narrows the boundary so appends that are genuinely independent stop colliding (concurrency failures surface on `CommandResult`/`AppendResult`). Adopt it deliberately per behavior, not as a blanket default.
 
-When the stream id is known only at runtime, implement `ICanProvideEventStreamId.GetEventStreamId()` instead of `[EventStreamId]`. ⚠️ Combining `ICanProvideEventStreamId` with a non-null `[EventStreamId]` attribute on the same command throws `AmbiguousEventStreamId` when that command is executed (the check runs while Arc builds the command context, not at startup) — pick one (or set the attribute value to `null` to defer to the interface).
+At Arc v22.75.0, prefer `IStreamReads.ForCommand()` in `Provide()` and return
+`StreamDecision.Append(...)` when deciding over one routed stream. For projected
+state use `[ProtectedDecision]` + `DecisionRead<T>`; plain injection and keyed
+reads are advisory, including in `Handle()`. Protected projections must be
+Chronicle-admitted (direct source key, known events; not reducers, joins, children
+or passive shapes); validators must be parameterless and certified by Arc.
+Exact returned scopes replace automatic `concurrency: true` capture.
+
+`[EventStreamId("{ReportingScopeId}:{Period}")]` resolves command property values
+after validation; concepts supply their underlying values. An interface can
+compute an id too. `AmbiguousEventStreamId` rejects any non-NotSet attribute
+value combined with `ICanProvideEventStreamId`, including a template; pick one.
+`[EventSource<TSource>(stream)]` selects a definition-backed route on commands and
+aggregate roots. `EventRoute`/`IEventRoutes` reuse it; explicit wrapper routing
+wins over command context. `[EventTag]`, `ICanProvideEventTags`, returned
+`EventTags` and discovered `ICanProvideCommandEventTags` add tags to returned
+events. `CompleteStream` runs after commit, not atomically with append, and closes
+stream type/id across the log, not just one source. Read the Arc command skill's
+`references/decisions-and-routing.md` for source-pinned contracts and limitations.
 
 ### Event-source id resolution order **[contract]**
 
@@ -232,6 +250,14 @@ public record AuthorRegistered(AuthorName Name);
 
 **[contract]** `[ReadModel]` records expose queries as `public static` methods; dependencies are plain method parameters (no `[FromServices]`). Default to model-bound projection shape; drop to fluent only when needed. For step-by-step creation, invoke the **cratis-chronicle-read-model** skill.
 
+Use `[ReadModel(RequireQueryAttribute = true)]` with `[Query]` on intended
+endpoints when public folds/helpers exist (ARC0026/ARCCHR0019). `[Query]` alone
+does not hide siblings; private/compiler-generated statics are never queries.
+A `CancellationToken` is supplied by Arc; concept arguments come from the caller,
+not DI. Bad GET/QUERY argument conversions return 400. Single-instance MongoDB/EF
+observations emit `default` on absence/deletion/filter exit: guard `hasData` and
+`isReady` in React. Verified at Arc v22.75.0; see the read-model query reference.
+
 ### Query return shapes **[contract]**
 
 Stay within analyzer-supported shapes: the read model, `T?`, a collection/array/`IQueryable<T>` of it, `Task<...>` of those, `IAsyncEnumerable<T>`, or `ISubject<...>` of read model/collection.
@@ -268,7 +294,7 @@ query reference for versioned behavior and composition trade-offs.
 
 ### Choosing read-model access in command-side code **[convention]**
 
-Ladder, first that fits: (1) direct read-model (DCB) injection — only when keyed by the command's own event-source id; (2) a `[Passive]` projection; (3) `IReadModels.GetInstanceById<T>((EventSourceId)key)` for a different/derived key; (4) a materialized projection. A lookup *interface* is justified **only** for a genuine non-key search (e.g. find-by-email) — never to wrap a keyed `GetInstanceById`.
+Ladder, first that fits: (1) advisory direct read-model injection — only when keyed by the command's own event-source id; (2) a `[Passive]` projection; (3) `IReadModels.GetInstanceById<T>((EventSourceId)key)` for a different/derived key; (4) a materialized projection. A lookup *interface* is justified **only** for a genuine non-key search (e.g. find-by-email) — never to wrap a keyed `GetInstanceById`.
 
 **[contract] Passive state is not sink state.** `IMongoCollection<T>` cannot
 compute a passive read model; any leftover documents are not maintained state.
@@ -366,7 +392,13 @@ Redaction is a system-event request that removes payload availability from the e
 
 Cross-slice access is **read-only and goes through Chronicle** — inject another slice's read model (validator/`Provide()`/`Handle()`), read by explicit key with `IReadModels.GetInstanceById`, mark a `[Passive]` projection for command-side decisions, or react to its events. **Never** instantiate or DI another slice's command/handler/service.
 
-**DCB (Dynamic Consistency Boundary):** a command's consistency boundary is exactly the state its validator/`Provide()`/`Handle()` reads — determined at runtime, not pre-declared. Pair with `concurrency: true` stream metadata when a stale read could let two commands both "win."
+**DCB (Dynamic Consistency Boundary):** the boundary is the event state explicitly
+enrolled in guarded decisions, not every model a command reads. Use stream
+reads/exact scopes or `[ProtectedDecision]` + admitted `DecisionRead<T>`;
+plain validator/`Provide()`/`Handle()` injection is advisory. Stream-level
+`concurrency: true` scopes are another explicit boundary, not protection for an
+arbitrary snapshot. Specify conflicts with `UseDecisionReads()` and actual seeded
+events, not pinned models.
 
 ## Dialogs
 

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

@@ -132,8 +132,10 @@ behavior truly requires DOM events — do not make it the default. Avoid
 snapshots; they hide behavior and make refactors noisy.
 
 Cratis Components mount inside `CratisComponentsProvider`, so a specification
-that renders one for real must provide it, and jsdom needs a `ResizeObserver`
-stub for the table and split-pane components.
+that renders one for real must provide it (enable `toaster` only when asserting
+toasts). In jsdom, provide a `ResizeObserver` stub for any Components area that
+observes size, including observable tables, Filter and toolbars. Source-checked
+at Components v4.26.4 (`Source/**`); this is not a split-pane-only requirement.
 
 ## Async and time
 

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

@@ -23,12 +23,14 @@ This skill decides **when to add a scenario** and **what to cover**. The C# mech
 
 | Package | Version | Purpose |
 | --- | --- | --- |
-| `Cratis.Arc.Testing` | `22.16.0` | `CommandScenario<TCommand>` and the `CommandResult` assertions |
-| `Cratis.Arc.Chronicle.Testing` | `22.16.0` | `Given`, `EventLog`, `AppendedEvents` and the appended-event assertions on a command scenario |
+| `Cratis.Arc.Testing` | `22.75.0` | `CommandScenario<TCommand>` and the `CommandResult` assertions |
+| `Cratis.Arc.Chronicle.Testing` | `22.75.0` | `Given`, `EventLog`, `AppendedEvents` and the appended-event assertions on a command scenario |
 | `Cratis.Chronicle.Testing` | `18.3.0` | `EventScenario`, `ReadModelScenario<T>`, `ReactorScenario<T>` |
 | `Cratis.Specifications.XUnit` | `4.x` | The `Specification` base and the `ShouldXxx` assertions |
 
-> 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.
+> Arc command/query/decision scenario surface rechecked at v22.75.0. Arc depends
+> on Chronicle 19.39.1; later Chronicle reactor setup below has its own minimum
+> version and is not downgraded by this Arc verification.
 
 Reactor read-model setup and the `EventContext.From` UTC default below are
 verified separately at **Chronicle 19.46.0**, the minimum version for that
@@ -112,6 +114,7 @@ keep a scenario for that wiring and for appended-event behavior.
 | Pure command decision, reducer logic or reactor decision | Plain method call with `Specification` (default) | `cratis-specifications-csharp` |
 | State Change — command pipeline and appended events | `CommandScenario<TCommand>` | this one |
 | Append semantics, a constraint | `EventScenario` | `cratis-chronicle-event-specifications` |
+| Query pipeline — arguments, authorization, validation, interceptors | `QueryScenario<TReadModel>` | [query and decision scenarios](references/query-and-decision-scenarios.md) |
 | State View — a projection or reducer | `ReadModelScenario<TReadModel>` | `cratis-chronicle-read-model-specifications` |
 | Automation or Translation — a reactor | `ReactorScenario<TReactor>` | `cratis-specifications-csharp` |
 | A host, transport, or real-infrastructure boundary | Out-of-process integration | `cratis-specifications-csharp` |
@@ -203,6 +206,13 @@ produces. Pin an instance only when the events would be noise.
 
 Both builder methods return `void`; there is nothing to await.
 
+That is **legacy** read-model mode: seeded events populate an in-memory model,
+not the append log. For protected or stream decisions call `UseDecisionReads()`
+before seeding; actual events and decisions then share one in-process log.
+Pinned models cannot supply decision guards. Read
+[query and decision scenarios](references/query-and-decision-scenarios.md) when
+specifying query pipelines, routed conflicts, projection admission or completion.
+
 Validator and `Provide()` dependencies are registered in `_scenario.Services`;
 the concrete validator itself is discovered automatically.
 
@@ -296,11 +306,11 @@ ideas recorded in `references/provenance.md`. Read `references/provenance.md` wh
 - **The command scenario reports success but nothing was appended.** The
   assertion is on `CommandResult` only; add a
   `ShouldHaveAppendedEvent<TCommand, TEvent>` fact.
-- **Injected-validator branches flip with test ordering.** The command-scenario
-  pipeline can cache enough state that a validator branch depends on execution
-  order under parallel xUnit runs. Use `CommandScenario` for the valid path, test
-  rejected state variants by instantiating the validator directly, and only then
-  put that command's specifications in a small `[Collection]`.
+- **Injected-validator branches flip with test ordering.** This was observed in
+  the 22.16-era harness. Arc 22.23.2 stopped replacing the process-wide provider;
+  later releases isolated stores and event-source services per scenario. Reproduce
+  at 22.75.0 before applying the old direct-validator/small `[Collection]`
+  workaround; no current reproduction was verified here.
 
 ## How it is proven
 

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

@@ -0,0 +1,65 @@
+# Query and decision scenarios
+
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+Verified at **Arc v22.75.0**. Use the plain `Specification` base for pure decisions;
+these helpers add proof of framework composition, not HTTP transport.
+
+## Query pipeline
+
+`QueryScenario<TReadModel>` is in `Cratis.Arc.Testing.Queries` (`Cratis.Arc.Testing`).
+Configure `Services` before the first call. `Perform(nameof(Model.Method),
+arguments?, paging?, sorting?, cancellationToken?)` returns `QueryResult` through
+conversion, validation, authorization and rendering. Use `QueryArguments` from
+`Cratis.Arc.Queries`; there is no principal parameter. Register the principal
+under test with `ICurrentPrincipalAccessor` in `Services`. Scheme-selected queries
+fail closed in-process: HTTP authentication needs a hosted integration spec.
+
+At Arc 22.75.1+ (re-verified at 22.76.0), both query and command scenarios preserve
+explicit `ICurrentPrincipalAccessor`, `ICurrentPrincipalOverride` and
+`IAuthorizationPolicyRuntime` registrations rather than replacing them with defaults.
+Configure them before first execution and specify both authorized and denied callers.
+Source: `Source/DotNET/Testing/ScenarioServices.cs`, `Queries/QueryScenario.cs`,
+`Commands/CommandScenario.cs`.
+
+`Observe(...)` returns a disposable `QueryObservation`; `Initial` includes the
+first result or rejection and `Next(timeout?, cancellationToken?)` reads the next
+buffered emission (not necessarily distinct). Default deadlines are five seconds;
+timeouts throw. Dispose asynchronously to await cleanup. Interceptors and guards
+run when emissions are consumed. MongoDB `.Observe()` still needs a real DB with
+change streams; the harness does not emulate it.
+
+The discovered `IQueryScenarioExtender` supports additional context/services.
+With `Cratis.Arc.Chronicle.Testing` and its Queries namespace, use
+`Given.ForEventSource(id).ReadModel(instance)` or `.Events(...)` before performing.
+The query must read that source via injected `IReadModels`; seeding does not
+replace arbitrary stores or produce later observable emissions after appends.
+
+## Guarded decisions
+
+Call `new CommandScenario<TCommand>().UseDecisionReads()` before seeding. This
+mode shares **one real in-process event log** among given events, guarded reads,
+constraints and returned appends. Seed actual events, not pinned read models.
+`Given.ForEventSource(id).OnRoute(route).Events(...)` preserves routing;
+`scenario.EventRoutes.For<TSource>(stream).WithStreamId(...)` creates the route.
+Queue interference using `AppendConcurrently(id, route, event)` and assert a
+nonempty decision is rejected on the intended boundary. An empty identical-retry
+append deliberately returns no scope and cannot prove the conflict guard.
+
+`ShouldHaveCompletedStream(type, id)` proves successful completion.
+`DecisionReadAdmissions.ShouldAdmitDecisionReadsIn(assembly)` checks projection
+admission in assembly-wide specs. These APIs are in
+`Cratis.Arc.Chronicle.Testing.Commands`. Routed seeding is refused in legacy mode.
+
+The old warnings that command `Given` never reaches the event log and that its
+read-model dictionary is the only backing are **legacy-mode** warnings, not a
+reason to fake protected decision readers. Keep non-key enumeration/provider
+boundaries explicit in either mode; decision mode is not a MongoDB substitute.
+
+## Sources
+
+- [Query scenarios](https://github.com/Cratis/Arc/blob/v22.75.0/Documentation/backend/csharp/testing/query-scenario.md)
+- [Stream decisions and routed specs](https://github.com/Cratis/Arc/blob/v22.75.0/Documentation/backend/csharp/chronicle/commands/stream-decisions.md)
+- [Decision-mode extension](https://github.com/Cratis/Arc/blob/v22.75.0/Source/DotNET/Chronicle.Testing/Commands/CommandScenarioChronicleExtensions.cs)
+- [Admission assertion](https://github.com/Cratis/Arc/blob/v22.75.0/Source/DotNET/Chronicle.Testing/Commands/DecisionReadAdmissions.cs)

package/package/corpus/skills/cratis-arc-authentication-authorization-and-identity/SKILL.md

@@ -15,12 +15,14 @@ told about them. Each has its own extension point.
 
 | Package | Version | Purpose |
 | --- | --- | --- |
-| `Cratis.Arc.Core` | `22.41.1` | `Cratis.Arc.Identity`, `Cratis.Arc.Authorization`, `Cratis.Arc.Authentication`, `Cratis.Arc.Tenancy` |
-| `Cratis.Arc` | `22.41.1` | ASP.NET Core hosting, `AddMicrosoftIdentityPlatformIdentityAuthentication` |
-| `@cratis/arc` | `22.41.1` | `IdentityProvider`, `IIdentity` |
-| `@cratis/arc.react` | `22.41.1` | `IdentityProvider` component, `useIdentity`, `RequireRole` |
+| `Cratis.Arc.Core` | `22.75.0` | `Cratis.Arc.Identity`, `Cratis.Arc.Authorization`, `Cratis.Arc.Authentication`, `Cratis.Arc.Tenancy` |
+| `Cratis.Arc` | `22.75.0` | ASP.NET Core hosting, `AddMicrosoftIdentityPlatformIdentityAuthentication` |
+| `@cratis/arc` | `22.75.0` | `IdentityProvider`, `IIdentity` |
+| `@cratis/arc.react` | `22.75.0` | `IdentityProvider` component, `useIdentity`, `RequireRole` |
+| Cratis AuthProxy (`cratis/authproxy`) | `v2.30.5` | the trusted ingress described in [AuthProxy](references/authproxy.md) |
 
-> Re-verified at `22.41.1` (the latest release when written) against that tag's source and Arc's documentation: the types, attributes and members this skill names exist, and the authorization, introspection, identity and emission-guard behavior it describes matches them. **Authorization behavior changed materially after `22.16.0`**, the version this skill used to pin: named policies, schemes, fallback baselines, guest policies and Microsoft-attribute enforcement all arrived later. [authorization](references/authorization.md) has a version table; check it if you run an older version.
+> Rechecked at Arc v22.75.0 against the source-pinned authentication, identity,
+> discovery and authorization references below. **Authorization behavior changed materially after `22.16.0`**, the version this skill used to pin: named policies, schemes, fallback baselines, guest policies and Microsoft-attribute enforcement all arrived later. [authorization](references/authorization.md) has a version table; check it if you run an older version.
 
 Reverify before claiming support for another version.
 
@@ -43,14 +45,17 @@ is the trust boundary. But it means:
   the application itself to validate a token, that is ordinary ASP.NET Core
   authentication you configure yourself.
 
-At `22.41.1` the default is that a plain `builder.AddCratis()` host registers the
-unsigned-header scheme as its **default** authentication scheme, so any caller who
-can reach it can forge a principal for every authorized command and query (open
-Arc#2946). Run it only behind that ingress; otherwise use `AddCratisArc()` and
-configure a credential-validating scheme. Arc itself refuses the unsigned headers
-in one place — protected introspection — until
-`Cratis:Arc:Introspection:TrustForwardedIdentityHeaders` is set; see
-[authentication](references/authentication.md).
+At **Arc v22.75.0**, forwarded identity headers are ignored unless the host opts
+in with `Cratis:Arc:TrustForwardedIdentityHeaders=true` or
+`builder.AddCratis(options => options.TrustForwardedIdentityHeaders = true)`.
+Header-only requests otherwise remain anonymous. `AddCratis()` still registers
+the header scheme; it does not make the headers trusted. Opt in only behind the
+ingress above, otherwise configure a credential-validating scheme. The old
+`Introspection:TrustForwardedIdentityHeaders` setting is obsolete and enables the
+same host-wide flag. See [authentication](references/authentication.md).
+Source: [Arc v22.75.0 secure defaults](https://github.com/Cratis/Arc/blob/v22.75.0/Documentation/upgrading/secure-defaults.mdx).
+
+Cratis AuthProxy is the ingress that meets these obligations for Cratis applications. Read [AuthProxy](references/authproxy.md) when the application is deployed behind it (header contract, `/.cratis/me` fail-closed verification, tenant headers).
 
 ## Identity details — what the frontend is told
 
@@ -85,45 +90,36 @@ public class <Name>IdentityDetailsProvider : IProvideIdentityDetails<<Details>>
 
 | Route | What it does |
 | --- | --- |
-| `GET /.cratis/me` | The current identity. 401 when not authenticated, 403 when the provider says not authorized, otherwise the result plus the identity cookie |
+| `GET /.cratis/me` | The current identity. 401 when not authenticated, 403 when the provider says not authorized, otherwise the principal-derived identity JSON |
 | `GET /.cratis/identity-details/schema` | The JSON schema of the details type (`{}` without a details provider) |
 | `GET /.cratis/users` | Development tooling — aggregates every `ICanProvideUsers` |
 | `GET /.cratis/tenants` | Development tooling — aggregates every `ICanProvideTenants` |
 | `GET /.cratis/commands`, `GET /.cratis/queries` | Introspection catalogs of operation names, types and routes (`MapIntrospectionEndpoints()`) |
 
-Normal `UseCratisArc()` activation maps all of these `AllowAnonymous` by default,
-**including in Production**, unless an endpoint of the same name already exists; `/.cratis/me`
-does its own 401/403. There is no public constant for the identity routes — they
-are string literals in the endpoint mapper.
-
-⚠️ **A fallback policy does not protect an endpoint that is explicitly anonymous**,
-and the word "development" is not an environment check. At `22.41.1` the default is that
-these routes are public and expose your command, query, user and tenant surface;
-the exposure is tracked in open Arc#2834. To change it:
-
-- the two catalogs: configure `Cratis:Arc:Introspection` (`Enabled: false` unmaps
-  them; `RequireAuthentication`/`Roles` protect them; the
-  `TrustForwardedIdentityHeaders` opt-in is for the header handler only behind a
-  trusted ingress) — options table in [authentication](references/authentication.md);
-- `/.cratis/identity-details/schema`, `/.cratis/users` and `/.cratis/tenants` are
-  **not** affected by those options. Return fixtures only from the user and tenant
-  providers, and restrict all three at the trusted ingress.
-
-Test the discovery endpoints under Production settings, with your fallback policy
-enabled.
-
-`/.cratis/me` writes the result as JSON **and** as a base64 cookie named
-`.cratis-identity`, deliberately **not `HttpOnly`** so the frontend can read it
-without a round trip. `Secure` follows whether the request is HTTPS, `SameSite`
-is `Lax`, `Path` is `/`.
-
-⚠️ A non-`HttpOnly` cookie the browser can read is a cookie the user can edit.
-Treat everything in it as a **display** input. Never let it decide anything the
-server has not already decided. At `22.41.1` the default is that `/.cratis/me` returns
-whatever a presented `.cratis-identity` cookie decodes to *before* it looks at the
-authenticated principal, so a client can make it report any identity or roles
-(open Arc#2939). Commands and queries authorize on the request principal and are
-not affected; a frontend that shows or branches on `/.cratis/me` can be misled.
+At **v22.75.0**, discovery is anonymous only when the host's
+`IHostEnvironment.IsDevelopment()` is true. Elsewhere it requires authentication;
+if the host cannot authenticate callers, the routes are not mapped (404) and a
+warning is logged. `RequireAuthentication` unset selects that environment default;
+explicit `true` requires authentication everywhere (startup fails if unavailable);
+explicit `false` exposes discovery anonymously everywhere, warning outside
+Development. `Roles` implies authentication and cannot combine with explicit
+`false`. `Enabled=false` removes the two catalogs; `IdentityDiscovery=false`
+removes users, tenants and the details schema. Setting both removes all discovery
+without authentication checks; `/.cratis/me` remains. `[ExcludeFromDiscovery]`
+hides commands, read models, queries and controllers from catalogs/OpenAPI, **not
+from invocation or authorization**. These are .NET settings, not a JVM contract.
+Source: [secure defaults](https://github.com/Cratis/Arc/blob/v22.75.0/Documentation/upgrading/secure-defaults.mdx).
+
+`/.cratis/me` derives identity only from the authenticated request principal,
+never from `.cratis-identity`. The details provider runs for each authenticated
+identity request; `ModifyDetails` changes only the current response. Arc no
+longer writes the readable identity cookie (it expires a legacy one). Identity
+responses carry `Cache-Control: no-store, private` and `Vary: Cookie`.
+Stop reading the cookie; use `IdentityProvider.getCurrent()`/`refresh()` and
+`clearCache()` on logout. The frontend caches in memory, with a warned legacy
+cookie fallback **only after a 404**, never after 401/403.
+Sources: [IdentityProvider.cs](https://github.com/Cratis/Arc/blob/v22.75.0/Source/DotNET/Arc.Core/Identity/IdentityProvider.cs),
+[IdentityProvider.ts](https://github.com/Cratis/Arc/blob/v22.75.0/Source/JavaScript/Arc/identity/IdentityProvider.ts).
 
 ## Authorization — what Arc evaluates
 
@@ -144,10 +140,10 @@ and `AuthenticationSchemes` enforce nothing, and Microsoft's `[Authorize]` is **
 honored on model-bound commands and read models, so a command protected only by it
 is open. From `22.21.0` Microsoft's `[Authorize]`/`[AllowAnonymous]` are enforced on
 the ASP.NET Core host (never on the standalone Core host), and from `22.23.0` named
-policies and schemes are evaluated. The rest of this section is `22.41.1` behavior;
+policies and schemes are evaluated. The rest of this section is `22.75.0` behavior;
 see [authorization](references/authorization.md) for the version table.
 
-At `22.41.1`:
+At `22.75.0`:
 
 - **Named policies work.** `[Authorize(Policy = "…")]` requires the policy to
   succeed asynchronously. Implement
@@ -204,7 +200,8 @@ restrictive verdict wins, and a guard that throws, or cannot be constructed, fai
 closed — the latter denies every observable query in the process. The principal comes
 from `ObservableQueryEmissionContext.Principal`, never from ambient accessors or
 `IHttpContextAccessor`; the guard is constructed per emission, so keep it cheap and
-cache in a singleton. Guards do not protect the HTTP snapshot path. Read
+cache in a singleton. Since 22.69.1, guards and read-model interceptors also
+protect plain HTTP snapshots, waits and long polls. Read
 [observable emission guards](references/observable-emission-guards.md) when implementing or reviewing revocation of an observable-query subscription.
 
 ### Validators are not an authorization boundary
@@ -281,7 +278,7 @@ no details to give, not only when the identity is explicitly unset.
 `whileLoading` and `forbidden` slots.
 
 ⚠️ **`RequireRole` hides UI; it does not protect data.** The identity it reads
-comes from the deliberately non-`HttpOnly` cookie above. Every rule it expresses
+comes from the principal-derived identity endpoint, but browser state is editable. Every rule it expresses
 must also exist on the server as `[Authorize]`/`[Roles]` or an authorization
 filter.
 
@@ -300,11 +297,10 @@ implements as `ICanProvideUsers` and `ICanProvideTenants`.
 To run locally with an identity, supply the forwarded headers yourself — see
 [local development](references/local-development.md).
 
-⚠️ Those two endpoints are `AllowAnonymous` and mapped unconditionally, in
-Production too, and a fallback policy does not protect them. If your
-`ICanProvideUsers` implementation returns real users, that list is public. Return
-development fixtures only, and gate the implementation on a development
-environment check.
+Those endpoints follow the discovery exposure settings above. Return development
+fixtures from development providers; test deployed discovery access explicitly.
+Forwarded headers sent locally require the host-wide trust opt-in too; do not
+carry that shortcut into a directly reachable deployed host.
 
 ## Verify
 
@@ -330,7 +326,7 @@ environment check.
 - Discovery endpoints (`/.cratis/commands`, `/.cratis/queries`,
   `/.cratis/identity-details/schema`, `/.cratis/users`, `/.cratis/tenants`) are
   tested under Production settings; introspection is restricted or disabled where it
-  must not be public, and the rest are restricted at the ingress.
+  must not be public, including identity discovery.
 - `TrustForwardedIdentityHeaders` is set only behind an ingress that authenticates
   callers, strips caller-supplied identity headers, writes trusted ones and blocks
   direct backend access; custom handlers honor it.