@cratis/pi 7.114.0 → 7.115.0

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

@@ -225,7 +225,7 @@ rejects Warning-level reactor/event-type drift (not Information-level read-model
 findings). Each reactor class should have a focused purpose. Multiple handler methods in one reactor are fine if they serve the same automation concern.
 5. **Failure behavior** — If a reactor throws, *or* a returned side-effect event fails to append (constraint violation, concurrency violation, or error), the failing event-source partition pauses until the issue is resolved. Repeated failures can **quarantine** the observer: once `QuarantineOnFailedPartitionCount`/`QuarantineOnFailedPartitionPercentage` (under `Observers`) is crossed, the observer enters the `Quarantined` state — reminders cancelled, retries stopped, automatic recovery suppressed. **A quarantine ends when an operator clears it (`ClearObserverQuarantine()`), or when the observer is subscribed again** — for an application observer that is when the client connects again, for example after a redeploy; Kernel-owned observers are subscribed again when the Kernel starts. A periodic watchdog (default 60s, `WatchdogInterval`) re-routes stuck/dead observers but does not rescue quarantined ones. Design for resilience.
 6. **Don't throw to validate malformed inbound events** — reactors are not data-quality validators; invalid payloads must be rejected at the command/append site. When a malformed cross-service fact reaches a consumer, throwing just to reject it pauses the partition and can quarantine the whole observer. Instead append a clear failure/dead-letter event (e.g. `ProvisioningFailed`) or surface it via the operational failure path, and skip partial side effects.
-7. **No state** — Reactors should be stateless. Inject dependencies via primary constructor, but do not store mutable state on the class.
+7. **No state** — Reactors should be stateless. Inject dependencies via primary constructor, but do not store mutable state on the class. From Chronicle 19.90.0, the .NET client runs different partitions concurrently (one partition's batches stay ordered); shared dependencies must be thread-safe, or set `ChronicleOptions.Reactors.MaxConcurrentPartitions = 1`. See **cratis-chronicle-reactor** for verified options and limits.
 8. **A new side-effect reactor must not act on history.** A reactor that is new in a release (or has a new id) catches up from the start of the event log when it first registers, and `[OnceOnly]` does not cover that first catch-up because it is not a replay. If its handlers cause side effects (jobs, AI calls, external calls, notifications), start the observer at the tail on first registration or make the handler ignore facts that predate its registration, and specify that history causes nothing.
 9. **An unattended, irreversible pass reads the log, not the sink — and carries a fuse.** A reactor that deletes, revokes, bills or notifies *because a read model says something is absent* is trusting a materialized sink that is only as current as its observer: a paused partition, a replay in progress or a lagging projection makes "absent" true of the sink and false of the world. Decide from a **`[Passive]`** read model (computed on demand from the events at the moment the reactor runs) or from the events themselves. And the code shape cannot tell an **empty subject set** ("nothing to consider" — fail-safe) from an **empty qualifying set** ("nothing survived the filter" — fail-destructive: every subject is about to be acted on), so an unattended pass states its expected population, refuses when the count is implausible, and caps how many subjects one run may touch — the same discipline as [guards-and-fuses.md](./guards-and-fuses.instructions.md), applied to a reactor. A sweep that decides from a read model also refuses while that model's observer is replaying or behind, because a rebuilding model reads as "nothing was ever processed"; specify the replaying case.
 10. **Provider clients stay behind a translation or adapter reactor.** A `[Command]` or `IReactor` in a domain slice that injects or imports a provider client (GitHub, payment, mail SDK) is a finding: put the client behind one adapter slice and let domain slices work with our events and commands. Judgment-shaped today; a candidate for a namespace-boundary analyzer.

package/package/corpus/product-sync.json

@@ -284,9 +284,9 @@
         }
       ],
       "synced": {
-        "version": "19.81.1",
-        "date": "2026-10-17",
-        "by": "Cratis/AI#773"
+        "version": "19.110.1",
+        "date": "2026-10-25",
+        "by": "Cratis/AI#820"
       },
       "covers": {
         "skills": [
@@ -323,7 +323,7 @@
         ],
         "rules": []
       },
-      "notes": "Reviewed releases 19.65.1-19.81.1 at tags: subscription generation pins, StartAtTail, namespace removal/reconnect, storage connection resolution (deploy 19.74.2+), definition refusal recovery, conflict event fields, .NET occurrences/lifecycle/receipts and testing identities, full-history per-key reads, child all-event mapping repair, projection SoftwareVersion, bounded job acceptance/recovery, immediate-append refusal ownership and namespace subscription reconciliation. Existing protected-read guidance retained. Chronicle#5028 definition round-trip/restart-replay fix is unreleased and not taught as fixed. No new kernel/transport probe."
+      "notes": "Reviewed all 60 stable releases 19.82.0-19.110.1 against tagged v19.110.1 source: append uncertainty and constraint-index repair, .NET keyed appends and multi-scope guards, request completion ownership, concurrent reactor/reducer partitions and returned-event receipts, projection replay/upgrade repairs, seeded scenarios, SQL/composite indexes, SQL membership/schema ownership, Localhost single-writer fencing, health probes, Azure identity/Key Vault purge, webhook target validation/retries/managed identity/real-delivery probes, and disabled-by-default projection-generation groundwork. 19.110.0 .NET packages were not published; use 19.110.1. Other covered skills were reviewed for release relevance without mechanical changes. Existing protected-read guidance retained. No new kernel/transport probe or capability."
     },
     {
       "id": "arc-go",

package/package/corpus/rules/reactors.md

@@ -224,7 +224,7 @@ rejects Warning-level reactor/event-type drift (not Information-level read-model
 findings). Each reactor class should have a focused purpose. Multiple handler methods in one reactor are fine if they serve the same automation concern.
 5. **Failure behavior** — If a reactor throws, *or* a returned side-effect event fails to append (constraint violation, concurrency violation, or error), the failing event-source partition pauses until the issue is resolved. Repeated failures can **quarantine** the observer: once `QuarantineOnFailedPartitionCount`/`QuarantineOnFailedPartitionPercentage` (under `Observers`) is crossed, the observer enters the `Quarantined` state — reminders cancelled, retries stopped, automatic recovery suppressed. **A quarantine ends when an operator clears it (`ClearObserverQuarantine()`), or when the observer is subscribed again** — for an application observer that is when the client connects again, for example after a redeploy; Kernel-owned observers are subscribed again when the Kernel starts. A periodic watchdog (default 60s, `WatchdogInterval`) re-routes stuck/dead observers but does not rescue quarantined ones. Design for resilience.
 6. **Don't throw to validate malformed inbound events** — reactors are not data-quality validators; invalid payloads must be rejected at the command/append site. When a malformed cross-service fact reaches a consumer, throwing just to reject it pauses the partition and can quarantine the whole observer. Instead append a clear failure/dead-letter event (e.g. `ProvisioningFailed`) or surface it via the operational failure path, and skip partial side effects.
-7. **No state** — Reactors should be stateless. Inject dependencies via primary constructor, but do not store mutable state on the class.
+7. **No state** — Reactors should be stateless. Inject dependencies via primary constructor, but do not store mutable state on the class. From Chronicle 19.90.0, the .NET client runs different partitions concurrently (one partition's batches stay ordered); shared dependencies must be thread-safe, or set `ChronicleOptions.Reactors.MaxConcurrentPartitions = 1`. See **cratis-chronicle-reactor** for verified options and limits.
 8. **A new side-effect reactor must not act on history.** A reactor that is new in a release (or has a new id) catches up from the start of the event log when it first registers, and `[OnceOnly]` does not cover that first catch-up because it is not a replay. If its handlers cause side effects (jobs, AI calls, external calls, notifications), start the observer at the tail on first registration or make the handler ignore facts that predate its registration, and specify that history causes nothing.
 9. **An unattended, irreversible pass reads the log, not the sink — and carries a fuse.** A reactor that deletes, revokes, bills or notifies *because a read model says something is absent* is trusting a materialized sink that is only as current as its observer: a paused partition, a replay in progress or a lagging projection makes "absent" true of the sink and false of the world. Decide from a **`[Passive]`** read model (computed on demand from the events at the moment the reactor runs) or from the events themselves. And the code shape cannot tell an **empty subject set** ("nothing to consider" — fail-safe) from an **empty qualifying set** ("nothing survived the filter" — fail-destructive: every subject is about to be acted on), so an unattended pass states its expected population, refuses when the count is implausible, and caps how many subjects one run may touch — the same discipline as [guards-and-fuses.md](./guards-and-fuses.md), applied to a reactor. A sweep that decides from a read model also refuses while that model's observer is replaying or behind, because a rebuilding model reads as "nothing was ever processed"; specify the replaying case.
 10. **Provider clients stay behind a translation or adapter reactor.** A `[Command]` or `IReactor` in a domain slice that injects or imports a provider client (GitHub, payment, mail SDK) is a finding: put the client behind one adapter slice and let domain slices work with our events and commands. Judgment-shaped today; a candidate for a namespace-boundary analyzer.

package/package/corpus/skills/cratis-chronicle-client-dotnet/SKILL.md

@@ -225,6 +225,10 @@ if (!result.IsSuccess)
   several event sources in one batch.
 - **There is no `AppendAnonymous`.** It does not exist anywhere in the product.
 
+For unknown outcomes, `AppendOnce` / `AppendManyOnce`, keyed retry conflicts and
+several concurrency guards for one source, read
+[append outcomes and retry safety](references/append-outcomes.md).
+
 Reading back is on `IEventSequence`: `GetForEventSourceIdAndEventTypes`,
 `HasEventsFor`, `GetFromSequenceNumber`, `GetNextSequenceNumber`, and
 `GetTailSequenceNumber`. Redaction is `Redact`; subject erasure is a separate

package/package/corpus/skills/cratis-chronicle-client-dotnet/references/append-outcomes.md

@@ -0,0 +1,78 @@
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# Append outcomes and retry safety
+
+Verified against the tagged sources in `Source/Clients/DotNET/EventSequences/`
+(`IEventSequence.cs`, `EventSequence.cs`, `IdempotencyKey.cs`, `AppendResult.cs`,
+`AppendManyResult.cs`, `AppendError.cs`) and
+[appending events](https://github.com/Cratis/Chronicle/blob/v19.110.1/Documentation/events/appending.mdx).
+These are .NET client APIs; do not assume other SDKs expose the same methods.
+
+## Unknown is not failure-before-write
+
+Requires Chronicle 19.82.2 for the distinct unknown-outcome and index-unavailable errors.
+Requires Chronicle 19.108.0 for node-loss/timeout unknown-outcome handling.
+
+`AppendError.AppendOutcomeUnknown` means the kernel cannot confirm whether the
+events were stored, including an in-flight append interrupted by node loss or
+a grain-call timeout. Do not retry an
+unkeyed append blindly: read the source's events for the attempt's correlation
+id, and append again only when none belongs to that attempt.
+
+An `Errors` entry with value `ConstraintIndexUnavailable` means a governing unique/closing index
+still needs repair and **nothing was stored**. Retry unchanged after a short
+delay. The kernel repairs constraint indexes from the event log; restarting
+clients or removing constraints is not a repair strategy.
+
+## Append once
+
+Requires Chronicle .NET client 19.92.0 and kernel 19.91.0 for keyed appends.
+
+```csharp
+using Cratis.Chronicle.EventSequences;
+
+// Keep this key and payload unchanged across retries of this logical operation.
+var key = new IdempotencyKey("order-confirmation-42");
+var result = await eventLog.AppendOnce(orderId, new OrderConfirmed(), key);
+```
+
+- `IdempotencyKey` accepts 1–512 characters. Never put personal data in it.
+- Check `IEventSequence.SupportsIdempotentAppends`. A kernel without support
+  causes `IdempotentAppendsNotSupported` before sending; do not fall back to
+  unkeyed retries when duplicate protection is required.
+- `AppendOnce`, `AppendManyOnce`, `AppendOnceWithNamedTags` and
+  `AppendManyOnceWithNamedTags` are on `IEventSequence` (and thus `IEventLog`).
+  A batch key derives each event key with `IdempotencyKey.ForIndex(index)`;
+  preserve the batch's order and content across retries.
+- `EventForEventSourceId.IdempotencyKey` keys individual events in a batch,
+  including a mixed keyed/unkeyed batch spanning sources. Unkeyed entries do
+  not acquire duplicate protection just because other entries have keys.
+- `AppendResult.Outcome` / `AppendManyResult.Outcomes` distinguish `Appended`,
+  `AlreadyAppended`, and `AlreadyAppendedAfterErasure`. An already-appended
+  outcome is success, not permission to re-create an erased event.
+- Inspect `IdempotencyConflicts`: a key reused for different content or generation,
+  or a match that cannot still be verified, is not a successful retry. A keyed
+  retry after an unknown outcome must use the **same** key and content.
+- Keys are refused on events staged in a unit of work and on appends carrying
+  effect receipts: these throw `IdempotentAppendsNotSupported`, not an unkeyed
+  fallback. Keyed appends are not a replacement for DCB or unit-of-work ownership.
+
+Requires Chronicle Testing 19.99.0 for dropped keyed-append replies.
+
+The Testing client supports keyed appends. `DropNext(DroppedReply.Append)` can lose a keyed append reply after persistence;
+retry with the same key and assert exactly one stored event and an
+already-appended outcome. This proves retry behavior, not an exactly-once
+external side effect.
+
+## Several concurrency guards for one source
+
+Requires Chronicle 19.84.0 for multiple concurrency guards for one source.
+
+`AppendMany` overloads accept
+`IEnumerable<KeyValuePair<EventSourceId, ConcurrencyScope>>`. Repeat a source id
+for distinct stream guards; a dictionary cannot represent those entries. The
+kernel checks the conjunction before any write, preserving batch atomicity.
+A violation identifies `ScopeIndex` and `Scope`. Older kernels still refuse
+unsupported combinations with `IncompatibleConcurrencyScopesForEventSource`;
+never discard a guard to make an append work.

package/package/corpus/skills/cratis-chronicle-client-dotnet/references/connection-options.md

@@ -59,3 +59,16 @@ Read [host wiring](hosting.md) for the deployment distinction.
 > TLS enabled (the default) and no configured certificate. **A production connection string must set
 > `skipTlsValidation=false`** (or `Tls.SkipCertificateValidation = false`)
 > against a server whose certificate is actually verifiable.
+
+## Partition concurrency
+
+Requires Chronicle 19.90.0 for concurrent .NET reactor/reducer partitions.
+
+`ChronicleOptions.Reactors.MaxConcurrentPartitions` and
+`ChronicleOptions.Reducers.MaxConcurrentPartitions` independently limit parallel
+partitions per observer. Both default to processor count capped at 8 and require
+at least 1. Set 1 for one-at-a-time handling if shared state is not thread-safe;
+one partition's batches remain ordered. These are .NET client settings, not
+kernel `observers` settings. Verified at **v19.110.1**:
+`Source/Clients/DotNET/Reactors/ReactorOptions.cs`, `Reducers/ReducerOptions.cs`
+and `Observation/PartitionedDeliveryScheduler.cs`.

package/package/corpus/skills/cratis-chronicle-client-dotnet/references/hosting.md

@@ -57,3 +57,26 @@ configured, from bootstrap configuration (configured applications are recreated
 on startup). Changing the image or supplying new client credentials alone does
 not remove that old application. See **cratis-chronicle-hosting** for kernel
 certificates, private h2c and production setup.
+
+## Request completion ownership (19.110.1+ .NET packages)
+
+Verified at **v19.110.1**: `Source/Clients/DotNET/Transactions/`
+(`IUnitOfWorkCompletionOwnershipFeature.cs`, `IUnitOfWorkCompletionClaim.cs`,
+`UnitOfWorkCompletionResult.cs`), `Source/Clients/AspNetCore/Transactions/UnitOfWorkMiddleware.cs`
+and `Source/Clients/AspNetCore/ChronicleUnitOfWorkOptions.cs`.
+
+Nested hosts can claim a request's completion with
+`IUnitOfWorkCompletionOwnershipFeature.TryClaim`. Complete through the claim
+and inspect its result before writing the response. An uncompleted claim is
+rolled back by the outer middleware, never silently committed. This does not
+grant arbitrary nested code the decision-read owner capability described in
+**cratis-chronicle-decision-reads**. `UnitOfWorkCompletionOutcome.Unknown` means a
+technical commit failure, not proof of rollback. Decision conflicts also occur
+in `ConcurrencyViolations`; avoid reporting the same source's conflict twice.
+
+Compatibility middleware logs a failed post-handler commit without changing a
+response already sent. Opt in to problem responses **before headers start** with
+`ChronicleAspNetCoreOptions.UnitOfWork.ReportFailuresBeforeResponseStarts`:
+concurrency/decision conflict is 409, constraint violation is 400, other append
+failure is 500. A started response cannot be repaired; complete through the
+claim first when a success response must mean the write committed.

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

@@ -242,6 +242,12 @@ requirement is only to annotate the types.
 Key storage is per namespace and is a hosting decision, not an application one. Chronicle ships
 MongoDB (the default), SQL, in-memory, HashiCorp Vault, and Azure Key Vault key
 storage, configured under `Cratis:Chronicle:Compliance:Encryption`.
+From 19.99.1, Azure Key Vault erasure **purges every key revision**, not just
+soft-deletes it. The vault must grant purge permission and have purge protection
+disabled; a refused purge fails erasure rather than reporting success. Do not
+silently weaken the erasure contract to fit a protected vault. Verified at
+**v19.110.1**, `Source/Kernel/Storage.AzureKeyVault/AzureKeyVaultEncryptionKeyStorage.cs`
+and `Documentation/hosting/azure.md`.
 
 > **Operational trap.** Switching to a dedicated compliance key store without
 > setting `MigrateFromDefaultStorage` leaves every existing key unreachable.

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

@@ -158,10 +158,14 @@ A constraint binds every writer, whichever client or service appends, per namesp
 and per event sequence. It cannot count, sum or test a predicate; it expresses
 uniqueness (with release on a removal event), create-once and closed streams.
 
-- The claim is settled after the durable append (not yet implemented in every
-  store). A failed index update is logged and a later duplicate may pass until a
-  reindex. SQL and InMemory stores do not yet settle claims. A constraint is the
-  right mechanism, not an unconditional proof.
+- From Chronicle 19.82.2, a failed index update after a durable append marks a
+  gap. A later governed append repairs that gap from the event log or refuses
+  with a `ConstraintIndexUnavailable` error value before writing. Do not treat
+  that retryable refusal as a duplicate or remove the constraint. Verified at
+  **v19.110.1**, `Source/Kernel/Core/EventSequences/EventSequence.AppendSettlement.cs`
+  and `EventSequence.Validation.cs`; see
+  [append outcomes](../../cratis-chronicle-client-dotnet/references/append-outcomes.md)
+  for the distinct unknown-outcome case.
 - Tenants in different namespaces can claim the same value.
 - `[RemoveConstraint]` releases attribute constraints (`[Unique]` on a property or
   on the event type); on a fluent `IConstraint` it compiles and does nothing, so

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

@@ -17,11 +17,22 @@ A constraint binds **every** writer, whichever client or service appends, so it
 the mechanism for uniqueness and create-once. It cannot count, sum or test a
 predicate: capacity and stock rules need a guarded read (read protection `On`), a stream decision or an
 aggregate. Read [choosing how a rule holds](../cratis-chronicle-decision-reads/references/choosing-how-a-rule-holds.md)
-when it is unclear which one a rule needs. Limits: the claim is settled after the
-durable append, so a failed index update can let a later duplicate
-through until a reindex; constraints apply per event store namespace and event
-sequence, so tenants in different namespaces can claim the same value; and a
-constraint is not re-run when the kernel retries a duplicate sequence number.
+when it is unclear which one a rule needs.
+
+Requires Chronicle 19.82.2 for constraint-index gap repair.
+
+A failed
+post-append index update marks a gap: subsequent governed appends repair the
+index from the event log or return `ConstraintIndexUnavailable` in the result's
+error collection without writing. Do not remove the constraint or blindly retry an unknown
+append outcome; see [append outcomes](../cratis-chronicle-client-dotnet/references/append-outcomes.md).
+Constraints apply per event store namespace and event sequence, so tenants in
+different namespaces can claim the same value. A constraint is not re-run when
+the kernel retries a duplicate sequence number.
+
+Verified in the tagged kernel sources listed by [append outcomes](../cratis-chronicle-client-dotnet/references/append-outcomes.md):
+`Source/Kernel/Core/EventSequences/EventSequence.AppendSettlement.cs` and
+`EventSequence.Validation.cs`.
 
 ## Verified product sources
 

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

@@ -48,8 +48,9 @@ operator/kernel surface, not an application-profile layout rule.
   development database ports on loopback only; a host application needing MongoDB
   must be able to reach port 27017. Do not expose unauthenticated MongoDB.
 
-Read references/storage-resolution.md when choosing per-namespace destinations,
-separate schema/runtime identities, SQL schemas, or disabling automatic creation.
+Read [storage resolution](references/storage-resolution.md) when choosing
+per-namespace destinations, schema/runtime identities, Azure authentication,
+SQL schemas, or disabling automatic creation.
 
 ## Supply certificates before starting production
 
@@ -111,18 +112,29 @@ than increasing limits without accounting for memory.
 
 Set `health.port` for a dedicated HTTP/1.1 probe listener. `health.tls=false`
 removes TLS only there; `health.exclusive=true` restricts it to the configured
-health path (`/health` by default). Exclusive is **false by default**, so an
+health path (`/health` by default) and its `/live` and `/ready` subpaths. Exclusive is **false by default**, so an
 ordinary plaintext probe port also exposes other HTTP/1.1 endpoints. Keep it
 internal. `health.tls=true` needs the top-level TLS certificate even when main
 TLS is disabled. The production chiseled container has no shell/curl: use an
 orchestrator/external probe, not an in-container shell healthcheck.
 
+Requires Chronicle 19.109.0 for separate readiness/liveness routes.
+
+`/health` and `/health/ready` remain readiness (including startup
+and storage); use `/health/live` for liveness/startup so a replay backlog does
+not restart a healthy-but-unready silo. A custom base path moves all three
+routes. Verified in the tagged sources linked from [clustering and schema ownership](references/clustering-and-schema.md),
+`Documentation/hosting/configuration/health-endpoint.md`
+and `Source/Kernel/Server/KernelReadinessHealthCheck.cs`.
+
 ## Form one cluster, not several over shared data
 
-Every node must explicitly set `clustering.type=MongoDB` and share the cluster
-and service ids and MongoDB storage. Default `Localhost` forms isolated
-single-node clusters: sharing a database does not join them. Only MongoDB
-supports multi-node storage; PostgreSQL, SQL Server and SQLite are single-node.
+Every node must select shared membership and share cluster/service ids and the
+cluster database: `clustering.type=MongoDB` for MongoDB, or `Sql` for PostgreSQL
+and SQL Server. SQLite remains single-node. Default `Localhost` does not join
+nodes; persistent stores guard it with a single-writer lease. Read [clustering and schema ownership](references/clustering-and-schema.md)
+for lease failure behavior, SQL migration/Verify modes and the disabled-by-default
+projection-generation groundwork.
 `Clustering:ResponseTimeout` bounds Orleans transport waiting; increasing observer
 subscriber timeout cannot exceed that transport deadline.
 
@@ -132,12 +144,16 @@ and upgrading a cluster. See **cratis-chronicle-web-workbench** for browser
 exposure and **cratis-chronicle-cli-operations** for authorized live operations.
 Several services share one kernel with one event store each: see **cratis-multi-service-architecture**, and **cratis-multi-service-local-orchestration** for an AppHost or compose file.
 
+Read [webhook delivery policy](references/webhooks.md) for target validation,
+independent retries, managed identity and **real-delivery** quarantine probes.
+Ordinary observer quarantine guidance does not imply webhooks stay silent.
+
 ## Verify
 
 - The build/image and intended environment agree; no default development
   application remains in reused production storage.
-- Storage is reachable and MongoDB is a replica set; multiple nodes share MongoDB
-  membership, cluster id, service id and certificate ring.
+- Storage is reachable and MongoDB is a replica set; multiple nodes share valid
+  MongoDB/Sql membership, cluster id, service id and certificate ring.
 - Certificates load; clients validate production TLS (`skipTlsValidation=false`).
 - A probe observes health without publishing a plaintext Workbench/API port.
 - Proxy upstream protocol and trust are tested from the actual immediate peer.

package/package/corpus/skills/cratis-chronicle-hosting/references/clustering-and-schema.md

@@ -0,0 +1,84 @@
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# Cluster membership, fencing and SQL schema ownership
+
+Verified at Chronicle **v19.110.1**: `Documentation/hosting/configuration/`
+(`clustering.md`, `storage.mdx`, `health-endpoint.md`),
+`Source/Kernel/Core/Clustering/SingleWriterLeaseKeeper.cs`,
+`Source/Kernel/Core/Configuration/{SchemaMode,SchemaAction,Features}.cs` and
+`Source/Kernel/Server/KernelReadinessHealthCheck.cs`.
+
+## Choose membership for the storage
+
+Requires Chronicle 19.105.0 for SQL multi-node membership and provider validation.
+
+PostgreSQL and SQL Server support multi-node membership with
+`clustering.type = Sql`; MongoDB uses `MongoDB`. Every node must share the
+cluster database, `clusterId`, `serviceId` and certificates. SQL clustering with SQLite or a non-SQL provider fails at startup; it is not a
+way to cluster SQLite. Sharing a database while using `Localhost` does not form
+a cluster. Silo and gateway ports must remain reachable between nodes.
+
+## Localhost single-writer lease
+
+Requires Chronicle 19.110.0 on every contender for the Localhost lease. With MongoDB
+storage the lease requires MongoDB 5.0 or later, and it is on by default.
+
+`Localhost` on persistent storage (MongoDB, PostgreSQL, SQL Server,
+SQLite) takes the fixed `kernel` lease in the cluster database **before** Orleans
+runtime startup. `InMemory` is process-local and takes no lease; MongoDB/Sql
+membership do not use this guard. Different cluster/service ids are diagnostic,
+not a way to bypass the fixed lease.
+
+- `clustering.singleWriterLease.enabled` is automatic by default; disable it
+  only with another proven single-writer mechanism.
+- `ttl` defaults to 30 seconds (minimum 5); `acquireTimeout` defaults to 2 minutes.
+  Zero timeout makes one attempt. A second node waits or refuses startup and
+  stays unready; it does not become a safe second writer.
+- Failed renewal marks health unhealthy and starts shutdown. Failure to confirm
+  renewal within half the TTL hard-fences the process. Shutdown retains the
+  lease while silo work drains; a crash successor waits for expiry. Do not
+  delete a live lease to get another node started.
+- Every contender must support the lease; an older binary does not take it.
+
+## Least-privilege SQL deployments
+
+Requires Chronicle 19.109.0 for schema actions and Verify runtime mode.
+
+`--migrate-only` (or
+`Cratis__Chronicle__Storage__SchemaAction=MigrateAndExit`) applies SQL migrations
+for the cluster, known stores/namespaces and jobs, then exits without serving.
+Run it with the authorized schema identity before starting runtime-only nodes.
+`--verify-schema` / `SchemaAction=VerifyAndExit` checks without changing schema;
+repeatable `--event-store` and `--namespace` with migration pre-provision new
+destinations. Exit codes: 0 success, 2 schema not current, 3 lock timeout, 4
+invalid options/forbidden database creation, 1 other failure. MongoDB and
+in-memory schema actions succeed without doing work; do not call that a SQL
+migration check.
+
+`Cratis__Chronicle__Storage__SchemaMode=Verify` performs no database/schema
+creation or migrations. Missing schema at startup or a newly used namespace
+fails with instructions to migrate. `Migrate` remains the default. Provision
+new destinations before routing tenants to them; `createIfMissing=false` is
+not equivalent to Verify and does not replace the migration step.
+
+SQL schema-lock wait and recovered insert-collision metrics aid diagnosis;
+readiness stays unhealthy until startup finishes. Do not restart a migrating
+node using a readiness endpoint as liveness.
+
+## Projection generations are not enabled by these releases
+
+The tagged sources provide guarded groundwork, not an instruction to enable it.
+`Features.ProjectionGenerations` remains off by default. MongoDB generation
+sink writes need majority transactions/fences, so startup refuses a standalone
+MongoDB with the feature on. Materialization binding catalogs exist for
+MongoDB and in-memory; SQL explicitly refuses that catalog. Generation-owned
+collections refuse drop, rename or clear.
+
+The per-store generation initializer is explicit and idempotent, records durable
+receipts/blockers, and refuses adoption if it cannot prove exclusion; it is not
+run automatically and does nothing with the feature disabled. Initialized stores
+have a minimum kernel generation floor; older kernels and state reset are
+refused. Do not recommend enabling the feature, deleting fences, or resetting
+state to resolve an ordinary replay problem. Consult the tagged product sources
+and accepted design before planning adoption.

package/package/corpus/skills/cratis-chronicle-hosting/references/operations.md

@@ -26,18 +26,46 @@ clearing one does not clear the other. Inspect the cause before authorizing clea
 or retry. Subscriber timeout abandons waiting, not subscriber work: redelivery
 can overlap work that still runs, so side effects must remain idempotent.
 
+Requires Chronicle 19.109.0 for abandoned-delivery holds.
+Requires Chronicle 19.110.0 for webhook quarantine probes.
+
+`observers.abandonedDeliveryHold` defaults to 300 seconds **after the delivery
+deadline**. A positive value below `subscriberTimeout` uses that timeout instead;
+zero or less disables the hold. Retry/catch-up/replay wait for a barrier on the
+**original subscriber activation**, not a replacement client. An unavailable
+original silo is not proof that its work drained. Late results are discarded;
+a late reducer result cannot write to its sink.
+
+The hold is bounded, not cancellation: user code might still run after expiry,
+so external side effects must remain idempotent. Clearing persisted failure
+history followed by restart loses that history. Inspect abandoned-delivery logs
+and metrics before reducing the hold. Verified in
+`Documentation/hosting/configuration/observers.md` and
+`Source/Kernel/Core/Observation/Observer.DeliveryFences.cs`.
+
 Quarantine persists through grain deactivation. Watchdog ticks and catch-up/replay
 completion do not end it. An operator clear or a fresh subscription does;
 a kernel restart only helps observers that actually receive a fresh subscription.
 Event-store subscriptions remain quarantined until operator clear. Recovery can
-quarantine again if the cause remains.
+quarantine again if the cause remains. Webhooks are an exception: eligible
+quarantines can probe with a **real pending event** and
+resume after success. Read [webhook policy](webhooks.md) before promising an
+operator that quarantine prevents all traffic; webhook timeout cancellation
+also drains the HTTP operation before starting another delivery.
 
 Projection replay and catch-up each use a **single globally ordered job step**;
 a new catch-up failure stops that step rather than letting other sources proceed.
 Full replay is inactive until completion, then routes to catch-up/live unless
 quarantined. Partition quarantine stops that partition's automatic retries;
 observer quarantine suppresses automatic recovery for the whole observer.
-Sources: `Documentation/concepts/observers.mdx`,
+Projection replay skips a failed partition while continuing
+healthy partitions, then schedules failed partitions for recovery after replay
+completes. Catch-up still stops its ordered step on a new failure. Replaying
+**global** projections is refused before any write (Requires Chronicle 19.101.3). For MongoDB
+catch-up/bulk-write upgrade repairs, read
+[projection definition changes](../../cratis-chronicle-projection/references/definition-changes.md).
+
+Sources (verified through **v19.110.1**): `Documentation/concepts/observers.mdx`,
 `Documentation/projections/registration-lifecycle.md`, and
 `Source/Kernel/Core/Observation/Jobs/{CatchUpObserver,ReplayObserver}.cs`.
 

package/package/corpus/skills/cratis-chronicle-hosting/references/storage-resolution.md

@@ -46,6 +46,36 @@ access tokens refreshed through resolution. Password-based MongoDB clients do
 not acquire a new password merely because configuration changes; restart them
 when rotating that credential.
 
+## Azure identity
+
+Verified through **v19.110.1**: `Documentation/hosting/azure.md`,
+`Documentation/hosting/configuration/storage-connection-resolution.md`,
+`Source/Kernel/Core/Configuration/PostgreSqlEntra.cs` and
+`Source/Kernel/Storage.Sql/Connections/PostgreSqlEntraAuthentication.cs`.
+
+Requires Chronicle 19.96.0 for AzureCredential HTTP resolver authentication.
+
+The HTTP resolver's `Authentication.Type=AzureCredential` supports
+`Credential=ManagedIdentity` (default), `WorkloadIdentity` or `Default`, plus
+`Scope` and optional `ClientId`. The resolver identity is not the database
+identity. Prefer the specific production credential rather than accidentally
+using a developer credential through the default chain.
+
+Requires Chronicle 19.92.2 for native Azure SQL identity authentication.
+Requires Chronicle 19.109.0 for native PostgreSQL Entra authentication.
+
+Azure SQL uses Microsoft.Data.SqlClient's native authentication connection-string
+settings (managed identity, workload identity, or default chain), not a
+Chronicle-specific password flow. Native Entra authentication for
+Azure Database for PostgreSQL uses `storage.postgreSqlEntra.enabled=true`, optional
+`managedIdentityClientId`, and a PostgreSQL `Username` with **no password**.
+Tokens refresh on pooled connections. Do not combine it with a resolver that
+returns credentials; placement and schema resolution remain supported.
+
+For separate least-privilege schema/runtime deployments, read
+[clustering and schema ownership](clustering-and-schema.md): `--migrate-only`
+and `SchemaMode=Verify` are distinct from `createIfMissing=false`.
+
 ## Verify
 
 Use the real target provider in integration specs: resolve two namespace

package/package/corpus/skills/cratis-chronicle-hosting/references/webhooks.md

@@ -0,0 +1,110 @@
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# Webhook delivery policy
+
+## Contents
+
+- Validate the destination, not just the registration
+- Independent delivery retries
+- OAuth scope and token refresh
+- Managed identity
+- Quarantine probes are real deliveries
+
+Verified at Chronicle **v19.110.1**: `Documentation/webhooks/index.mdx`,
+`Source/Kernel/Core/Configuration/{Webhooks,WebhookManagedIdentity,WebhookProbe}.cs`,
+`Source/Kernel/Core/Observation/Webhooks/` (including `Validation/`) and
+`Source/Kernel/Server/Observation/Webhooks/ManagedIdentityCredentialFactory.cs`.
+Configuration below sits under `Cratis:Chronicle:Webhooks`.
+
+## Validate the destination, not just the registration
+
+Requires Chronicle 19.100.0 for webhook target validation.
+
+`Validation` is `Warn` (default) or `Enforce`. Warn logs violations without
+blocking, except unapproved cloud metadata addresses. Do not mistake the default
+for full SSRF protection or approve metadata hosts in normal deployments.
+Enforce requires HTTPS and approved hosts, checking private/special resolved
+addresses at connect time too. Redirects are not followed. OAuth authorities use the same policy.
+`AllowInsecureHttp` applies only in Development.
+
+`AllowedHosts` accepts exact hosts and wildcard subdomains; an event store's
+`EventStoreAllowedHosts` entry **replaces** the global list. An exact host entry
+can intentionally admit that host's private addresses. Bound exceptions to
+trusted receivers; wildcards approve subdomains, not their parent domain.
+Never widen the list just to silence a refusal.
+
+Requires Chronicle 19.106.0 for validation of stored active definitions.
+
+Existing active definitions are checked on activation/restart.
+Enforce quarantines a disallowed target without deleting/deactivating the
+stored definition; Warn logs once per activation and continues. Fix the target
+or approved policy, then clear quarantine: clearing revalidates, so it does not
+bypass a bad target. A connect-time policy failure is a configuration problem,
+not a transient failure retried for 24 hours.
+
+## Independent delivery retries
+
+Requires Chronicle 19.104.0 for webhook-specific retry policy.
+
+Each delivery makes one HTTP attempt. `Retry` is independent of global observer
+settings: delays are 1 s, 5 s, 30 s, 2 min, 10 min, 30 min, then hourly, with
+±20% jitter. The budget is 24 hours, then the partition is parked. Five parked
+partitions or at least half the failing partitions parked quarantines the
+observer. Override the schedule, maximum delay, attempts, budget and quarantine
+thresholds only with a bounded recovery policy. `RetryDelaySeconds` is retained
+but has no effect.
+
+Retry deadlines/counts/positions survive restart; manual partition retry overrides
+a pending deadline. A per-target (scheme/host/port) circuit defers deliveries
+without consuming attempts. `429`/`503` with valid `Retry-After` defer without
+consuming attempts, capped by `MaximumRetryAfterSeconds` (default 24 hours).
+`410` parks immediately. Other `4xx` except `408` and `429` quarantine as
+configuration failures. Catch-up/replay respect the pending deadline.
+
+## OAuth scope and token refresh
+
+Requires Chronicle 19.98.0 for OAuth scope, token reuse and one-shot 401 refresh.
+
+The .NET webhook builder accepts
+`WithOAuth(authority, clientId, clientSecret, scope)`; scope is optional, and
+re-registering without it clears a previously configured scope. Entra client
+credentials need the receiver's `api://<application-id>/.default` scope. Tokens
+are shared by token endpoint/client/scope/credentials and refreshed before
+expiry; tokens lacking expiry are not cached. A 401 refreshes and retries the
+same request once; other responses do not trigger an OAuth retry. This is
+separate from the observer retry policy. Never put credentials in examples or
+logs. Verified in `Source/Clients/DotNET/Webhooks/IWebhookDefinitionBuilder.cs` and
+the tagged webhook documentation.
+
+## Managed identity
+
+Requires Chronicle kernel 19.110.0 and .NET packages 19.110.1 for managed identity webhooks.
+
+System-assigned/user-assigned Azure managed identity and AKS workload identity
+can authorize a webhook without storing a client secret. The operator must
+allow exact scopes in `ManagedIdentity.AllowedScopes`; the empty default
+disables this. Non-empty client ids must be in `AllowedClientIds`; an empty id
+needs `AllowSystemAssigned=true`. The receiver must explicitly match the host
+allow-list **even in Warn mode**; delivery rechecks approval before acquiring a
+token. This lends the **kernel's** identity, not the registering client's. Its
+principal still needs the receiver's application role. Register with the .NET
+builder's `WithManagedIdentity(scope, clientId)` (client id optional). Tokens are
+memory-only and refreshed before expiry. A 401 discards the cached token and
+its credential instance, then retries once; Azure's own cache means a different
+token is not guaranteed. Never log tokens. Verified in
+`Documentation/hosting/azure.md` and `Source/Clients/DotNET/Webhooks/IWebhookDefinitionBuilder.cs`.
+
+## Quarantine probes are real deliveries
+
+Requires Chronicle 19.110.0 for automatic webhook quarantine probes.
+
+`Probe.Enabled` defaults to true. Retry-budget or delivery/configuration
+quarantines can probe with exponential jittered backoff (initial 60 s, maximum
+1 hour, timeout 30 s); manual quarantines and parked partitions are not
+probed. A probe sends the **first pending event** without clearing quarantine
+first. Success records it as handled, clears quarantine and resumes in order.
+Failure leaves quarantine intact. Probes revalidate targets and consume neither
+normal retry budget nor circuit samples. Set `Probe.Enabled=false` when
+quarantined receivers must get no automatic traffic. Receivers must remain
+idempotent; a probe is not a read-only health check.

package/package/corpus/skills/cratis-chronicle-projection/references/definition-changes.md

@@ -13,6 +13,18 @@ when independence cannot be proved. Counters and joins are repaired by replay,
 not by deploying corrected mappings: earlier double-counts remain until rebuilt.
 A `FromAll` subscription change redefines existing projections.
 
+Adding mappings for event types that already have history requires
+**full** replay: `Automatic` rebuilds; `PartialOnly` and `Manual` recommend it.
+The kernel no longer replays those mappings onto live state, where watermarks
+could discard historical writes or counters could count twice. No history for
+the added types means no action. Explicit partition replay is unchanged.
+Verified in `Source/Kernel/Core/Projections/Projection.cs`
+(`EvolveForAllNamespaces`).
+
+Requires Chronicle 19.101.3 for explicit refusal of global projection replay.
+
+Global projection replay (full or partition) is refused before writing. Do not promise to repair globally scoped state by replay.
+
 Projection replay and catch-up each walk the sequence in **one globally ordered
 job step**, not parallel per-source steps. A new failure during catch-up stops
 that ordered step even if other sources are healthy. Full replay keeps the
@@ -49,5 +61,26 @@ revives a retired observer, or restarts a stopped/deleted capture. A kernel
 restart or a newly added namespace still ends projection quarantine through a
 fresh subscription; do not interpret ordinary watchdog repair as operator clear.
 
+## Upgrade repair checks
+
+Verified through **v19.110.1**:
+`Source/Kernel/Storage.MongoDB/Sinks/Sink.cs`,
+`Source/Kernel/Core/Projections/Engine/KeyResolvers.ParentHistory.cs` and the
+tagged release notes:
+
+Requires Chronicle 19.110.0 for MongoDB resumed bulk-window preservation, replaced-window fencing and historical parent-key resolution.
+
+- MongoDB catch-ups resumed while clients restarted/re-registered could lose
+  unflushed writes on older kernels. Upgrade, then replay affected
+  projections, including catch-ups with `BulkWindowLost` or completed failures;
+  silent loss may leave no log entry. The fixed sink preserves the window,
+  refuses a window replaced before the first checkpoint and
+  prevents queued writes crossing replay/catch-up collections.
+- With content-keyed parents, children rebuilt before this fix may be under the
+  wrong parent. Replay after upgrading; key lookup now uses the child's event
+  position rather than the parent's latest key.
+- These are kernel-backed storage/replay behaviors. In-process projection
+  scenarios do not prove bulk durability or historical parent-key resolution.
+
 Closing a stream does not erase its events or prevent a projection replay.
 Keep the closing fact as history; see **cratis-chronicle-event-constraints**.

package/package/corpus/skills/cratis-chronicle-projection/references/fluent-builder.md

@@ -55,6 +55,12 @@ model-bound `[FromEvery]` has no opt-out. `FromAll` can count into dictionary
 properties with a per-event context key (`Projections/FromEveryBuilder.cs`,
 `IFromEveryBuilder.cs`, `Documentation/projections/declarative/`).
 
+Requires Chronicle 19.88.0 for all-event constant mappings.
+
+Fluent `FromEvery` and `FromAll` property mappings support `ToValue(...)` for
+concepts, enums and `null`, like per-event `Set(...).ToValue(...)`. Verified at
+**v19.110.1**, `Projections/AllSetBuilder.cs` and `IAllSetBuilder.cs`.
+
 ## Inherited from `IProjectionBuilder<TReadModel, TBuilder>`
 
 ```csharp
@@ -83,6 +89,12 @@ Chaining `.NotRewindable()`, `.Passive()`, `.ContainerName()`, or
 `RemovedWith` and `RemovedWithJoin` hand you the **concrete**
 `RemovedWithBuilder<,>` and `RemovedWithJoinBuilder<,>` classes, not interfaces.
 
+Requires Chronicle 19.93.0 for the root-removal-through-join startup warning.
+
+`RemovedWithJoin` removes **children**, not a root read model. The .NET client warns at startup about root removal through a join (fluent,
+model-bound or explicit); it still removes nothing. Use `RemovedWith` for the
+root. Verified in `Projections/RootRemovalViaJoin.cs` at the tag above.
+
 ## Keys live on the per-event builder
 
 `From<TEvent>` hands the callback an `IFromBuilder<TReadModel, TEvent>`, which

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

@@ -239,6 +239,18 @@ Read [references/domain-failures.md](references/domain-failures.md) when handlin
 Inject through the primary constructor; hold no mutable state (CHR0031 warning).
 Keep one automation concern per reactor; several related handlers are fine.
 
+Requires Chronicle 19.90.0 for concurrent .NET reactor partitions.
+
+Different partitions of one .NET reactor run concurrently;
+batches for one partition retain arrival order. Shared collaborators must be
+thread-safe. Set `ChronicleOptions.Reactors.MaxConcurrentPartitions = 1` when
+one-at-a-time handling is required; the default is processor count capped at 8,
+and values below 1 are refused. This is not ordering across different observers.
+Verified in the tagged sources listed in
+[connection options](../cratis-chronicle-client-dotnet/references/connection-options.md):
+`Source/Clients/DotNET/Reactors/ReactorOptions.cs`,
+`Reactors.cs` and `Observation/PartitionedDeliveryScheduler.cs`.
+
 ## Specifications
 
 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.

package/package/corpus/skills/cratis-chronicle-reactor/references/return-event-metadata.md

@@ -14,6 +14,19 @@ analyzers flag synchronous custom returns even when the runtime handler accepts
 Return events rather than inject `IEventLog`: **a convention, not an analyzer
 contract**. Returned appends stay inside Chronicle's transaction.
 
+Requires Chronicle 19.94.0 for receipt-keyed returned events.
+
+Returned events on receipt-capable kernels have stable effect keys: retries, crash redelivery and same-generation replay do not append them
+again. This covers bare, cross-source and mixed returned-event results, not
+arbitrary HTTP calls or independently injected `IEventLog` appends. Older kernels
+retain the previous at-least-once behavior. Preserve deterministic return
+ordering/content; a changed result is a conflict, not a reason to discard the
+receipt. Keep `ReactorDelivery`-based idempotency for external side effects and
+`[OnceOnly]` for deliberate replay exclusion. Verified at **v19.110.1**:
+`Source/Clients/DotNET/Reactors/SideEffects/ReactorEffectKeys.cs`,
+`EventResultHandler.cs`, `MixedSideEffectsResultHandler.cs` and
+`Documentation/reactors/side-effects.mdx`.
+
 ```csharp
 // One event, on the triggering event's own event source.
 public Task<<ResultEvent>> <MethodName>(<EventName> @event, EventContext context) =>

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

@@ -75,7 +75,9 @@ public record <ReadModelName>(
   reserves those for compliance-subject tracking, and analyzer `CHR0035`
   rejects them.
 - `Cratis.Chronicle.ReadModels.IndexAttribute` (`[Index]`) marks a property for
-  indexing in the sink.
+  indexing in the sink, including SQL. `[CompositeIndex]` on the class declares ordered multi-property indexes and
+  `[Index(IsDescending = true)]` declares descending ones. Read
+  [indexing](references/indexing.md) for valid paths, flags and store-specific limits.
 
 ### Shape the model for its consumer
 

package/package/corpus/skills/cratis-chronicle-read-model/references/indexing.md

@@ -0,0 +1,44 @@
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# Read-model indexes
+
+Verified against the tagged `Source/Clients/DotNET/ReadModels/IndexAttribute.cs`,
+`CompositeIndexAttribute.cs` and
+[indexing documentation](https://github.com/Cratis/Chronicle/blob/v19.110.1/Documentation/read-models/indexing.mdx).
+
+Requires Chronicle 19.103.0 for SQL indexes.
+Requires Chronicle 19.105.0 for SQL Server string index length bounds.
+Requires Chronicle kernel 19.110.0 for SQL nested-path indexes and PostgreSQL GIN
+collection indexes.
+Requires Chronicle .NET packages 19.110.1 for composite/descending indexes and an
+index for every use of a reused nested type.
+
+Import `Cratis.Chronicle.ReadModels`.
+
+```csharp
+[ReadModel]
+[CompositeIndex(nameof(CustomerId), nameof(Created), IsDescending = new[] { false, true })]
+public record OrdersByCustomer(
+    Guid Id,
+    [property: Index] Guid CustomerId,
+    [property: Index(IsDescending = true)] DateTimeOffset Created);
+```
+
+- `[Index]` targets a property or record parameter; `[CompositeIndex]` targets
+  a class and is repeatable. Composite property order matters.
+- Dotted paths name nested properties. `IsDescending` is one flag on `[Index]`,
+  an array on `[CompositeIndex]`; omit the array for all ascending or provide
+  one flag per property. Empty/duplicate/unknown paths and mismatched flag
+  counts are refused at registration. Indexes are not uniqueness constraints.
+  Use an event constraint for a value that must be unique at append time;
+  a read-side index is not a write-side invariant.
+- MongoDB and SQL create indexes at read-model registration. PostgreSQL uses
+  GIN for collection paths, which cannot be combined in a composite index with
+  ordinary fields. SQL Server and SQLite skip collection indexes with a warning.
+- SQL Server indexed string columns honor `MaxLength`, `StringLength` or
+  `Length`; otherwise the bound is 450 characters. Overlong writes fail the
+  projection partition. Replay existing read models to apply bounded columns.
+- Indexes on reused nested types are expanded for every path, not
+  just the first occurrence. Test the actual store's query behavior and inspect
+  its schema; an in-process scenario does not prove physical indexes exist.

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

@@ -153,6 +153,10 @@ identifier properties populate; when one does not, investigate the projection
 rather than the harness. Skip only on a reproduced harness gap, and put the
 specific reason in the skip message.
 
+For pre-seeding instances, `ProcessAppendedEvents(...)` and schema-generator
+sharing, read [seeded state and appended-event processing](references/seeded-state.md).
+These are setup/processing surfaces, not proof of kernel persistence or replay.
+
 ## Step 4 — Know what the scenario picked
 
 `WithProjection` overrides discovery, including a reducer. Otherwise:

package/package/corpus/skills/cratis-chronicle-read-model-specifications/references/seeded-state.md

@@ -0,0 +1,35 @@
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# Seeded state and appended-event processing
+
+Requires Chronicle 19.83.0 for seeded state; verified against v19.110.1 sources.
+
+Verified in `Source/Clients/Testing/ReadModels/`
+(`ReadModelSourceGivenBuilder.cs`, `ReadModelScenario.cs`) and
+`Source/Clients/Testing/Events/EventStoreForTesting.cs`.
+
+`await scenario.Given.ForEventSourceId(id).ReadModel(instance)`
+sets initial state for both `InstanceForEventSourceId(id)` and
+`scenario.ReadModels.GetInstanceById<T>(id)`; it does not create event history.
+Use it for handler setup, not as proof that a projection built the instance.
+
+Requires Chronicle 19.82.0 for appended-event processing with real contexts.
+
+`ProcessAppendedEvents(...)` folds `AppendedEvent` values rather
+than appending them a second time, preserving their real `EventContext`
+(sequence number and occurred time) and sorting across sources by sequence
+number. Use distinct sequence numbers. Bare events supplied through `Given`
+or `ProcessEventsFor` still use synthetic contexts. With seeded instances,
+the fold's results replace the scenario's `ReadModels` instances; this does
+not prove kernel storage or replay durability. Seeding the same key twice
+throws `ReadModelAlreadySeeded`; models with no projection/reducer keep
+lookup-only behavior.
+
+Requires Chronicle 19.106.0 for shared default test-store schema generation.
+
+Default test stores share a JSON schema generator per process,
+while each store gets a separate schema copy. Set
+`EventStoreForTesting.ShareSchemaGenerator = false` for per-store metadata
+providers; custom service providers already bypass sharing. Configure the
+static switch at suite setup, not concurrently between specifications.

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

@@ -245,6 +245,20 @@ same store catalog: `AmbiguousReadModelBuilder` rejects it. `[Passive]`, sequenc
 selection, filters and `[Reducer]` alone do not establish projection ownership.
 Remove the old builder when switching; registration is not a data migration.
 
+## Partition delivery
+
+Requires Chronicle 19.90.0 for concurrent .NET reducer partitions.
+
+Different partitions of one .NET reducer can run at the
+same time; batches for the same partition remain in arrival order. Keep shared
+collaborators thread-safe, or set
+`ChronicleOptions.Reducers.MaxConcurrentPartitions = 1`. The default is processor
+count capped at 8; values below 1 are refused. A global ordering assumption is
+not justified by per-partition ordering. Verified in the tagged sources listed
+by [connection options](../cratis-chronicle-client-dotnet/references/connection-options.md):
+`Source/Clients/DotNET/Reducers/ReducerOptions.cs`, `Reducers.cs` and
+`Observation/PartitionedDeliveryScheduler.cs`.
+
 ## Replay
 
 Read [references/replay-hooks-and-definition-changes.md](references/replay-hooks-and-definition-changes.md) when a self model needs `BeginReplay`/`EndReplay` hooks (they return exactly `Task`; do not assume delivery is exactly once) or when a code, key or filter change must replay (`observers.definitionEvolution`). Requires Chronicle 19.29.4 for method-fingerprint change detection; assembly versions are ignored.

package/package/corpus/skills/cratis-chronicle-reducer/references/replay-hooks-and-definition-changes.md

@@ -33,3 +33,10 @@ partial replay only when history proves they follow all previously consumed
 events per source. Interleaved history requires full replay. Manual policies
 leave recommendations; they do not silently rebuild. Source:
 `Documentation/hosting/configuration/observers.md`.
+
+At **v19.110.1**, replay writes reduced state to a separate sink and switches to
+it only when replay completes. Abandoning a failed reducer replay does not
+publish partially rebuilt state. This is a kernel sink boundary, not proof that
+external side effects are reversed. Verified in
+`Source/Kernel/Core/Observation/Jobs/ReplayObserver.cs` and the tagged observer
+configuration documentation.

package/package.json

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