@cratis/pi 7.62.0 → 7.64.0

package/package/corpus/skills/cratis-screenplay-captures-and-reactions/references/record-capture-specifications.md

@@ -0,0 +1,60 @@
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# First sight and updates in record captures
+
+Requires Screenplay 4.175.0 or later (`screenplay --version`); older reference evaluators treat fields of a first record as changed. Upgrade before relying on added-only outcomes.
+
+For `source api`, webhook, poll and other record sources, a first record of a typed key is **added only**. `when <field>`, field-change `and`/`or` and transitions need an earlier record of that same key. For an update scenario, seed it with `given capture`. A baseline for another key does not count. To record both first sight and later changes, use separate appends with `when added` and `when <field>`; do not replace the update guard with `when added`.
+
+This applies independently to each child identity in its parent's previous collection and each nested record: a missing/null previous nested value is new, and every child of a new parent is new. Expression guards still evaluate the mapped current record on first sight; maps and unguarded appends keep their meaning. These record fixtures are not valid for `source events`: use typed events instead (automations-and-translations [public event captures](../../cratis-screenplay-automations-and-translations/references/public-events-and-direction.md)).
+
+The complete model separates a new observation, an update and an unchanged repeat:
+
+```screenplay
+domain LegacyBilling
+module Integration
+  feature Invoices
+    slice Translate ImportInvoiceStatus
+      event InvoiceStatusObserved
+        status String
+      capture InvoiceRecords
+        source api
+          api LegacyBilling
+          route /invoices
+          poll 5m
+        key id
+        append InvoiceStatusObserved
+          when added
+            status = $.status
+        append InvoiceStatusObserved
+          when status
+            status = $.status
+      specification RecordingFirstSight
+        when capture InvoiceRecords
+          id = "inv-42"
+          status = "sent"
+        then InvoiceStatusObserved
+          for "inv-42"
+          status = "sent"
+      specification RecordingAnUpdate
+        given capture InvoiceRecords
+          id = "inv-42"
+          status = "sent"
+        when capture InvoiceRecords
+          id = "inv-42"
+          status = "paid"
+        then InvoiceStatusObserved
+          for "inv-42"
+          status = "paid"
+      specification IgnoringAnUnchangedRecord
+        given capture InvoiceRecords
+          id = "inv-42"
+          status = "paid"
+        when capture InvoiceRecords
+          id = "inv-42"
+          status = "paid"
+        then no events
+```
+
+Run `screenplay <model> --warnaserror` (zero errors/warnings), then `screenplay test <model>` (all three specifications passed). Each specification supplies its own immutable baseline; no last-seen record persists between runs. Reference execution never contacts the configured API and does not prove source acknowledgement or retry safety.

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

@@ -3,7 +3,11 @@
 **Specify what sets them off** (execution from ESM v6): `when clock "<instant>"`
 for a reaction on `every` or `at`, `when trigger <Trigger>` with its values for one
 on an application trigger, and `given capture` / `when capture <Capture>` with the
-source record's fields for a capture, then the events that should follow.
+source record's fields for a record capture, then the events that should follow.
+For `source events`, use `given <FromEvent>` / `when append <FromEvent>` instead
+(PLAY0701). First sight is `added` only; update guards need the same key's prior
+record or events. See [record capture cases](record-capture-specifications.md) and
+[public event captures](../../cratis-screenplay-automations-and-translations/references/public-events-and-direction.md).
 `given clock` fixes the occurrence time, so values mapped from `$context.occurred`
 can be asserted. Excerpt of the complete example in [complete-examples.md](complete-examples.md):
 

package/package/corpus/skills/cratis-screenplay-command-surface/SKILL.md

@@ -50,9 +50,8 @@ concept InvoiceStatus : Enum
   paid
 ```
 
-The seven primitives are `Uuid`, `String`, `Int`, `Decimal`, `Bool`, `Date` and
-`DateTime`. `Enum` is **not** one of them — it is a separate concept kind, which
-is why the compiler says *expected … or Enum* rather than listing it among them.
+Primitives: `Uuid`, `String`, `Int`, `Decimal`, `Bool`, `Date`, `DateTime`.
+`Enum` is a separate concept kind; details: `references/enum-numbers.md`.
 Use bare `pii` (`personal` alias) and `secret` on concepts; **Compliance is inherited**.
 Keep protection even when a compiler or renderer refuses it. Read
 [compliance and purposes](references/compliance.md) for ESM v13, binder-only refusals,
@@ -106,12 +105,12 @@ fix to migrate. `--warnaserror` does not reject information diagnostics.
 properties, `reads`, `authorize`, `validate`, `produces`/`handler`, `concurrency`.
 Keep to it.
 
-⚠️ **`produces` and `handler` are mutually exclusive** — declaring both is an
-error. Everything else may repeat except `description` (one) and `concurrency`
-(one). A `handler` parses but **never binds**, with or without an `implementation`
-or `hint`: the binder reports `PLAY0268` ("handler requires a constrained
-implementation attachment"), and a `handler` is not one of the opaque bodies below.
-Prefer `produces` when the model must run or render.
+A file/code `handler` cannot coexist with `produces` and still fails binding
+with PLAY0268. A pending `handler implementation` beside unconditional `produces`
+is a described command (ESM v23): the body owns payload values only. Prefer plain
+`produces` for declarative logic. Read [described handlers](references/described-handlers.md)
+when logic needs prose, for the result contract, PLAY0695–0698, Unsupported
+ImplementationBody and Stage's STAGE-IMPL-002 refusal (no stubs, even in Stub mode).
 
 ## `identifier` — the stream boundary decision
 
@@ -149,18 +148,11 @@ alias on **every** read (`PLAY0410`), aliases are unique (`PLAY0411`) and must n
 match a command property (`PLAY0412`). A `require` path uses the alias, or the
 view name when that view is read once.
 
-⚠️ **`reads` is not a protected read.** It documents the read-model-to-command
-arrow of the event model; nothing checks at append time that the state is still
-current. The executable model rejects every `reads` and `concurrency` with
-`PLAY0271`, and `require` over a read-model path with `PLAY0268`, until
-decision-consistent reads exist. Adding a
-`concurrency` block does not fix this: its scope is not the read's watermark, and the
-combination is planned to become an error once protected reads ship.
-When a rule depends on state:
-
-- if it is uniqueness, declare a `unique` constraint (below);
-- otherwise state the rule, and say in review that the target implementation
-  must enforce it consistently. Do not claim the model guarantees it.
+Opt eligible state reads into application-root `command reads protected` (v25).
+Absence rejects; matching intervening facts conflict. Read [protected reads](references/protected-reads.md)
+for strict admission, paths and PLAY0780–0786. Legacy reads stay unprotected;
+reads/concurrency cannot combine (PLAY0783). Stage refuses protected reads (STAGE-ESM-044), not v25 itself.
+Uniqueness still uses a constraint; reference success is not target realization.
 
 Do not use `reads` to fetch data the caller could supply. A composite-key view's `by` block is
 `PLAY0268` (read-surface `references/named-keys.md`).
@@ -170,8 +162,11 @@ Do not use `reads` to fetch data the caller could supply. A composite-key view's
 Each rule takes an optional `severity information|warning|error` and then an
 optional `message "<text>"` (or `$strings.<key>`). The default severity is `error`.
 
-The rule vocabulary (`not empty`, `min`/`max`, comparisons, `length`, `matches`, `all`, `rule <Name>`) is in
+The rule vocabulary (`not empty`, `min`/`max`, comparisons, `length`, literal text rules, `matches`, `all`, `rule <Name>`) is in
 [references/validate-rules.md](references/validate-rules.md): read it when choosing or writing a rule form.
+Read [text and match rules](references/text-and-match-rules.md) for ordinal `contains`,
+`not contains`, `starts with`, `ends with` (v24), the portable linear match dialect,
+PLAY0699/0787, Studio repairs and public pattern checks. Text rules are not conditions.
 
 ⚠️ **Validation severity is not compiler severity.** Every failed rule and
 `require` rejects the command, at `information` and `warning` too; severity only
@@ -182,11 +177,18 @@ optional `severity`, sharing the condition grammar with `produces … when`:
 `and` binds tighter than `or`, parentheses group. A conditional rule is an
 implication: `require isExtension == false or newEndDate > endDate`.
 
+Requires Screenplay 4.199.0 (ESM v26; `screenplay --version`) for Date/DateTime
+comparisons; older binders report PLAY0268. Read [date comparisons](references/date-comparisons.md)
+when ordering a retention window with `require to >= from`, comparing instants
+across offsets, or rejecting offset-less inputs before rules. It covers admitted
+positions, PLAY0268/0273, ordinal `then` matching and Stage's v26 refusal.
+
 **Rules whose logic is code.** A bare `rule <Name>` has no portable meaning (`PLAY0268`) and a bodied rule binds only as
 opaque code. Read [references/validate-rules.md](references/validate-rules.md) when a rule's logic must live in a `file`
 or fenced code body.
 
-**Put format rules on the `concept`, not the command.** A concept carries its own
+**Put format rules on the `concept`, not the command** (except date comparisons,
+which bind only on command properties, not as concept rules). A concept carries its own
 `validate` block and every use inherits it — that is Screenplay's type system, and
 a rule that travels is worth more than one that is repeated.
 
@@ -241,8 +243,11 @@ One `concurrency` block per command; it is not bound (`PLAY0271`) and does not p
 
 UUID generation/responses bind as v7; serialized concept `generate` selects v15:
 UUIDv7/ULID/TypeID/NanoID/bytes, strict fixtures and whole-source freshness.
-Reuse rejects Concurrency, no append/retry. Generated rules/secrets and pattern/random/rule
-remain refused.
+Reuse rejects Concurrency, no append/retry. Rules select v20 (Requires Screenplay
+4.164.0, `screenplay --version`); pattern/checksum, Int random and attached rules
+select v21 (Requires 4.172.0). Older compilers refuse PLAY0268. Secrets and sequences
+remain refused. Patterns are readable references, not gapless allocators or secrets;
+check digits catch typos, not forgery. Keep uniqueness/freshness enforcement.
 Read [references/generated-values-and-responses.md](references/generated-values-and-responses.md)
 for `generated`, `generate`, `returns`, strict fixtures/freshness and renderer limits.
 
@@ -283,17 +288,19 @@ Four contexts, and **what each omits is load-bearing** — when writing a code b
       bundle compatibility and execution are separate checks.
 - [ ] No unintended `PLAY0478` or `PLAY0479` information remains.
 - [ ] At most one command property carries `identifier`, and no event property does.
-- [ ] Format rules live on the `concept`; state-dependent rules are specifications.
+- [ ] Format rules live on the `concept` except command-only date comparisons;
+      state-dependent rules are specifications. DateTime comparisons preserve UTC
+      ticks; specs include missing-offset Validation rejection.
 - [ ] Every `authorize` combining policies writes `and`/`or` explicitly.
-- [ ] No `reads` or `concurrency` is described as protecting a decision; the gap
-      is stated.
+- [ ] Protected reads opt in, meet admission and distinguish reference protection
+      from target realization; legacy reads and `concurrency` imply no protection.
 - [ ] Constraints are `unique` forms; no `file` constraint stands in for another rule.
 - [ ] Each policy has one `require` or one implementation, not both.
 - [ ] Personal data is `pii` on the concept; operational secrets are `secret`;
       no identifier or subject concept carries either. Reasons explain the value,
       while purposes declare basis/retention; run `--check purposes` separately.
-- [ ] No `handler` where the model must bind, and no bodied construct described as
-      runnable or renderable without saying which tool admits it.
+- [ ] Described handlers distinguish binding from Unsupported body execution and
+      Stage refusal; attached handlers remain unbound. Name the admitting tool.
 - [ ] No event carries an optional property covering two situations.
 
 Compiler versions and admission: `cratis-screenplay-toolchain/SKILL.md`.

package/package/corpus/skills/cratis-screenplay-command-surface/references/date-comparisons.md

@@ -0,0 +1,100 @@
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# Chronological command date comparisons
+
+Requires Screenplay 4.199.0 (ESM v26; `screenplay --version`); older binders refuse date comparisons with PLAY0268. Upgrade the compiler without weakening the rule.
+
+Use `==`, `!=`, `>`, `>=`, `<` or `<=` with matching primitives: Date/Date or
+DateTime/DateTime. A concept may type a command property; date rules on the concept
+itself remain refused. These are the admitted positions:
+
+| Position | Left | Right |
+| --- | --- | --- |
+| `require`, `produces when` | Required scalar command property | Required scalar command property of the same primitive, or literal |
+| Command/property validation rule | Subject property | Literal only |
+
+`Date` orders calendar dates without a time zone. `DateTime` compares UTC instants
+at tick precision (seven fractional digits), including `==`/`!=`: different offsets
+can name equal instants. Literal operands bind to canonical text (`yyyy-MM-dd`, or
+UTC `yyyy-MM-ddTHH:mm:ss.fffffffZ`). An unparsable date literal or an offset-less
+DateTime literal in an admitted position reports PLAY0273.
+
+Every participating DateTime input must carry an offset or `Z`. Otherwise input
+validation rejects the command with Validation **before any rule or condition**,
+even if the comparison would short-circuit or its production would be skipped.
+Targets must enforce this before deserialization attaches a local offset, and
+preserve tick precision or refuse the comparison; JavaScript `Date` alone truncates
+precision. Client validators omit date ordering rules. Optional absent values still
+pass validation rules other than `not empty`; optional condition operands refuse.
+
+PLAY0268 still refuses mixed Date/DateTime, `$context` operands (including
+`$context.occurred`), `today`, protected read paths, date rules on concepts and
+reaction `where`. A refused whole comparison reports only PLAY0268, without
+validating its literals. A `given clock` does not admit `today` or now.
+Stage refuses v26 with STAGE-ESM-016; standalone binding/reference execution is
+not rendering. Preserve the rule and route delivery to authorized gap-fill.
+
+## Retention window and rejection specifications
+
+Two required DateTime inputs express a caller-chosen interval, not the server's
+clock. Keep state-dependent retention-policy reads separately protected; this
+example models only interval ordering. `then` matching remains ordinal, as do
+keys, constraints and freshness: preserve the exact produced payload spelling,
+not a different offset that happens to name the same instant.
+
+```screenplay
+concept WindowId : Uuid
+module Retention
+  feature Windows
+    slice StateChange KeepWindow
+      command KeepWindow
+        windowId WindowId identifier
+        from DateTime
+        to DateTime
+        validate
+          require to >= from
+            message "The window must not end before it starts"
+        produces event WindowKept
+          from DateTime = from
+          to DateTime = to
+      specification AcceptingEqualInstantsWithDifferentOffsets
+        when KeepWindow
+          windowId = "3fa85f64-5717-4562-b3fc-2c963f66afa6"
+          from = "2026-10-01T10:00:00+02:00"
+          to = "2026-10-01T08:00:00Z"
+        then WindowKept
+          for "3fa85f64-5717-4562-b3fc-2c963f66afa6"
+          from = "2026-10-01T10:00:00+02:00"
+          to = "2026-10-01T08:00:00Z"
+      specification RejectingAnInvertedWindowByOneTick
+        when KeepWindow
+          windowId = "3fa85f64-5717-4562-b3fc-2c963f66afa6"
+          from = "2026-10-01T08:00:00.0000002Z"
+          to = "2026-10-01T08:00:00.0000001Z"
+        then error "The window must not end before it starts"
+      specification AcceptingAnIncreasingWindow
+        when KeepWindow
+          windowId = "3fa85f64-5717-4562-b3fc-2c963f66afa6"
+          from = "2026-10-01T08:00:00Z"
+          to = "2026-10-01T09:00:00Z"
+        then WindowKept
+          for "3fa85f64-5717-4562-b3fc-2c963f66afa6"
+          from = "2026-10-01T08:00:00Z"
+          to = "2026-10-01T09:00:00Z"
+```
+
+Extract the complete fence into an ignored `.ai-work/` model folder. Run
+`screenplay <folder> --warnaserror --no-color` (zero errors/warnings), then
+`screenplay test <folder>` (all three specifications passed, none Unsupported).
+
+## Missing-offset input rejection
+
+Add a `RejectingAMissingOffset` test at the evaluator-request or target input
+boundary: submit `from = "2026-10-01T08:00:00"` with a valid `to`, then reverse which
+input lacks an offset. Expect Validation before any rule, no facts, and the message
+`DateTime command property 'from' requires an explicit offset or Z.` (or `'to'`).
+Include a skipped-condition case where applicable. A typed `.play` fixture with
+that invalid value refuses binding with PLAY0273; `then error` does not turn it
+into an executed runtime rejection. Record the target test separately, not as a
+passing `.play` specification or a `given clock` workaround.

package/package/corpus/skills/cratis-screenplay-command-surface/references/described-handlers.md

@@ -0,0 +1,82 @@
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# Described command handlers
+
+Requires Screenplay 4.182.0 or later (`screenplay --version`); older compilers refuse pending handlers with PLAY0268.
+
+Use a described command when payload computation needs words rather than an invented
+expression. Prefer ordinary `produces` when the logic is declarative. Do not use a
+described body to reject a command or decide how many events to emit.
+
+Complete model:
+
+```screenplay
+domain Billing
+module Invoices
+  feature Fees
+    slice StateChange ApplyLateFee
+      command ApplyLateFee
+        invoiceId String identifier
+        daysOverdue Int
+        validate
+          daysOverdue >= 1 message "The invoice must be overdue"
+        handler
+          implementation
+            hint "Calculate the late fee from overdue days using the agreed daily rate"
+        produces LateFeeApplied
+          for invoiceId
+      event LateFeeApplied
+        amount Decimal
+```
+
+A pending `implementation` has no `file` or fence. Bare `implementation` is valid;
+optional `hint` lines are ordered, nonblank quoted strings, decoded without trimming.
+One wrapper and at most one payload are permitted. Attaching a file or fence stops
+being a described command: attached handlers still fail binding with PLAY0268 and
+cannot coexist with `produces`.
+
+## Result contract v1
+
+| Part | Owner |
+| --- | --- |
+| Events, count, order | Declarative; each unconditional `produces` means exactly one event |
+| Destination, routes, allocation, tags and metadata | Declarative |
+| Generated values and response | Declarative; generation precedes the body |
+| Authorization and validation | Declarative; denial or refusal never reaches the body |
+| Event payload values | Body; mappings are non-normative hints, required properties may be unmapped |
+
+Mapping type checks still apply. Neither a renderer nor reference execution evaluates
+these payload mappings. Conditional productions, repeated/occurrence productions,
+body-decided cardinality and body rejection are outside this contract.
+
+The command selects ESM v23 with `handler: { requirementId, resultVersion: 1 }`.
+The requirements sidecar carries a Pending CommandHandler requirement with ordered
+hints, context/result versions 1, and provisional/ambiguous flags. Consumers must
+explicitly admit this version, never silently drop the body.
+
+| Diagnostic | Meaning and action |
+| --- | --- |
+| PLAY0695 (information) | Described command admitted; command and RequirementId name the missing body |
+| PLAY0696 (error) | No productions, including response-only; add unconditional productions |
+| PLAY0697 (error) | Conditional productions; result v1 needs unconditional events |
+| PLAY0698 (error) | Pending intent plus another handler; keep one handler |
+| PLAY0492–0494 | Invalid wrapper, hint or payload composition; fix the source shape |
+
+## Execution and realization
+
+Reference execution runs the gates, routing and generation in ordinary order, then
+returns Unsupported (`ImplementationBody`) on reaching the body, naming command and
+RequirementId. This also applies through an invoking reaction. No payload mapping runs
+and no event is emitted. Denial and validation specifications still execute. Unsupported
+specifications are counted separately; an all-Unsupported run is never green.
+
+Stage admits v23 but refuses described handlers with STAGE-IMPL-002 in the renderer,
+Host and specification executor, including Stub mode: it emits no stubs. Hand-write
+the body against the declared contract as authorized gap-fill; do not claim that a
+pending requirement is implementation evidence. Moving the body into `handler file`
+keeps its RequirementId but does not admit that attached handler alongside `produces`.
+
+Validate the model root with `screenplay <root> --warnaserror`; expect no errors or
+warnings and PLAY0695 information. Run `screenplay test <root>` separately: body-reaching
+specifications must be reported Unsupported, not passed. Target tests are separate.

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

@@ -1,4 +1,4 @@
-# Generated values and responses (ESM v7 and v15)
+# Generated values, rule proofs and responses
 
 ## Contents
 
@@ -28,16 +28,17 @@ Only the released generation phase is taught here.
 ## Choosing a strategy
 
 Use the [threaded shop model](shop-generation.md): CustomerId is `cus_` + ULID,
-OrderId is TypeID, InviteCode is NanoID. It links the same .NET concepts but does
-not claim their received-time/tenant context or secret ApiKey Bytes(32) factory
-is executable in Screenplay. The table below owns exact strategy shapes.
+OrderId is TypeID, InviteCode is NanoID, InvoiceNumber is a readable pattern with
+Luhn check digit, and TicketNumber is a random Int value. Keep short references
+separate from event-source identities. The table below owns exact strategy shapes.
 
 ## When not to
 
 Client-minted values remain inputs. Generation is not authorization, idempotency,
-gapless invoice allocation or a credential contract. Preserve ApiKey's `secret`
-classification without generated properties; context/secret execution remains
-Screenplay#616 phases 3/4, not a reason to strip protection.
+gapless/sequential invoice allocation or a credential contract. A pattern is not
+an allocator; check digits catch typing mistakes, not forgery. Preserve ApiKey's
+`secret` classification without generated properties: generated secrets remain
+refused, not a reason to strip protection.
 
 ## The concept declares how; the property declares that
 
@@ -46,7 +47,7 @@ strategies on concepts and `generated`/`generated identifier` on properties.
 It includes whole-value fixture pins and returned IDs.
 
 A generated property must be a required scalar **concept**, not a bare primitive,
-optional value or collection. Only Uuid and String generation are executable.
+optional value or collection. Uuid/String generation and Int `random` are executable.
 A Uuid concept implicitly generates `uuid`; String needs an explicit strategy.
 Each concept owns at most one `generate` line; there is no per-property override.
 Generated identifiers need Uuid or String backing and at least 64 random bits.
@@ -59,6 +60,9 @@ Generated identifiers need Uuid or String backing and at least 64 random bits.
 | `typeid "user"` | String | TypeID 0.3, lowercase Crockford UUIDv7 suffix; 74 random bits; prefix 1–63 lowercase letters/underscores, no leading/trailing underscore; empty prefix omits separator |
 | `nanoid [size]` | String | Default 21 symbols from `A-Za-z0-9_-`; size 1–256; entropy is size × log2(alphabet size) |
 | `bytes <count> base64url` / `hex` / `base32` | String | Count 1–512; 8 × count random bits; RFC 4648 without padding; hex lowercase, base32 uppercase; unused trailing bits zero |
+| `pattern "INV-{yyyy}{MM}-#{7}" checksum luhn` | String | Finite readable reference; UTC dates and check digits add no entropy |
+| `random 100000..999999` | Int | Inclusive signed Int64 interval; numeric value, not an identifier |
+| `rule Name` | String | Exactly one file or tagged fence; opaque ValueGeneration implementation with language-neutral Now/Tenant context, String result and unknown entropy |
 
 Modifiers occur once each, in any authored order. `prefix "text"` is printable
 ASCII, at most 32 characters, on uuid/uuidv7/ulid/nanoid/bytes; UUID prefixes need
@@ -71,17 +75,31 @@ identifier; non-identifiers warn PLAY0683 unless a single-property unique
 constraint covers the mapped event property. That suppression is not a runtime collision guarantee; use the constraint when
 collisions must reject the command.
 
-`pattern`, `random`, `rule` and checksum syntax parse/print but refuse PLAY0268;
-`generate sequence` is reserved (PLAY0682). Generated-concept validation rules select ESM v20; compliance markers, including
-generated secrets, remain refused. Do not
-remove classification or pretend a random String is a credential contract.
+Requires Screenplay 4.172.0 or later (`screenplay --version`) for pattern/random/rule
+and String-concept `validate checksum luhn|mod11|mod97` (ESM v21); older compilers
+refuse them with PLAY0268. Pattern `#` draws a digit, `?` an uppercase letter,
+`*` an uppercase letter or digit; positive ASCII classes and `{n}`/`{m,n}` repeats
+up to 64 are supported. `{yyyy}`, `{yy}`, `{MM}`, `{dd}` use one UTC date.
+The expanded value, including check digits, is at most 256 characters. Only pattern
+accepts `checksum`; write literals/classes rather than prefix/case/alphabet modifiers.
+Read Cratis/Screenplay `Documentation/screenplay/generated-values/patterns.md`
+for escaping and support limits. PLAY0691 means support counting exhausted its
+budget; PLAY0692 means some date in the 100-year assessment horizon has empty
+support. Neither is a proof warning or permission to redraw.
+
+Checksum generation appends one Luhn/Mod11 digit or two Mod97 digits over preceding
+ASCII digits, including date/literal digits. Author `validate checksum` separately
+for arithmetic validation of supplied/stored values and fixtures; generation alone
+checks only suffix shape on fixtures. `generate sequence` stays reserved (PLAY0682),
+and compliance markers on generated concepts, including secrets, remain refused.
+Never remove classification to make a model bind.
 
 ## Inspect and edit generation through MCP
 
 A concept `generation` summary and entropy repairs are available.
 Use `screenplay_declaration_details` with `kind: "Concept"`, `view: "summary"`:
 only authored `generate` gets a block, with strategy, set modifiers,
-preview-only arguments, `entropyBits`, `entropyUnknownReason` when null,
+`arguments`, `supportCount`, `entropyBits`, `entropyUnknownReason` when null,
 `valuesAtOnePercentCollision` and `executable.status`. Status is `admitted` only
 after whole-model binding, `refused` for errors at this concept/generation, or
 `notAssessed` with a reason for unrelated binding failures. Empty local codes do
@@ -91,7 +109,7 @@ Set/change/remove `generate` through `screenplay_propose_ast` (replace the conce
 `GenerationSyntax`, omit/null `generation` to remove) or reviewed
 `screenplay_propose_source`; do not hand-edit the text. Inspect executable
 diagnostics independently of authoring acceptance: sequence PLAY0682;
-pattern/random/rule PLAY0268; generated-rule proofs PLAY0688/0689. Review, run candidate
+support failures PLAY0691/0692; generated-rule proofs PLAY0688/0689. Review, run candidate
 specifications where executable, then apply with revisions.
 
 `screenplay_repair_capabilities` advertises PLAY0683/0684; workspace repairs supply
@@ -104,12 +122,19 @@ individual review and `CanonicalizeTouchedDocuments`, with no pinned evidence.
 Length changes affect all concept uses; uniqueness changes append-time behavior.
 PLAY0688 repair replaces a refuted rule with the strategy-derived `matches`
 pattern. Review input/stored-value uses because this changes their validation,
-not just generation. Checksum repairs remain unadmitted.
+not just generation. A deterministic bounded pattern repair also adds the declared
+checksum validation if absent; review both rule changes. Ambiguous derived regexes
+have no repair. Date/checksum digit shapes alone do not prove containment.
 A CLI-bundled MCP can lack this summary and these repairs; it still
 supports existing typed concept proposals.
 
-Requires Screenplay 4.149.0 or later (`screenplay --version`) for the concept `generation` summary and entropy repairs. Full fields, mapping limits and tagged
-source evidence: [MCP generation guide](../../cratis-screenplay-model-authoring/references/mcp-tools.md#concept-generation).
+Requires Screenplay 4.173.0 or later (`screenplay --version`) for `arguments`,
+exact support counts, `derivedPattern` and authored-order `rules[]`; older servers
+can expose `previewArguments` instead. Read `rules[].status`, `witness` and `reason`
+instead of parsing diagnostic text. Use `derivedPattern` as `matches` through a
+typed proposal; use the discovered PLAY0688 repair to replace a refuted rule.
+A refuted rule without `diagnosticCode` was not checked by the compiler (for example,
+an unused UUID concept), so do not invent a repair. Full fields and mapping limits: [MCP generation guide](../../cratis-screenplay-model-authoring/references/mcp-tools.md#concept-generation).
 Sources: Cratis/Screenplay `Documentation/screenplay/generated-values.md`,
 `Source/DotNET/Screenplay.Mcp/McpGenerationDetails.cs`,
 `Source/DotNET/Screenplay/Workspaces/WorkspaceGenerationRepairs.cs`.
@@ -135,20 +160,27 @@ that cannot backtrack on generated values. Passing samples alone prove nothing.
 Providers validate generated values too: a failing fixture is a Contract violation,
 not client rejection or a reason to redraw. Opaque rules need a target.
 
-Rules select v20 even on implicit UUID generation. No proof status is serialized;
+Generated-concept validation rules select ESM v20 even on implicit UUID generation.
+No proof status is serialized;
 strategy changes do not silently change rules on stored/input values.
 
+Tool and renderer authors: read the toolchain's
+[generation checks](../../cratis-screenplay-toolchain/references/generation-checks.md)
+for declaration checks, value checks, strategy discovery and rule proofs.
+Proof status is not serialized; the reference evaluator always requires pins.
+
 ## Version and freshness
 
 A serialized concept `generation` member selects **v15**. Implicit Uuid generation
 and explicit unmodified Uuid `generate uuid` omit it and preserve earlier executable
-bytes/revision. A v15 model guards **all** generated destinations, including its
-implicit UUIDs. An append whose destination equals any value generated in that
+bytes/revision. Any model with a serialized strategy guards **all** generated destinations,
+including its implicit UUIDs; ESM version alone does not enable the guard. An append whose destination equals any value generated in that
 invocation requires the **whole source** to have no existing facts, regardless
 of stream or event type. Multiple initial facts in one invocation are allowed;
 a skipped production makes no freshness claim. Reuse rejects the whole command
 with `Concurrency`, appends nothing and does not silently regenerate or retry.
-Older models are Unguarded and retain legacy fixture reuse.
+Models without a serialized strategy are Unguarded and retain legacy fixture
+reuse, even if rules select v20.
 
 Freshness is neither authorization nor idempotency. Client-minted identifiers
 remain inputs; protect their invariants with constraints. Never use generation
@@ -158,7 +190,12 @@ Specifications pin values, not seeds: `for` pins a generated identifier;
 `generated <name> = <value>` pins another generated property. The reference
 evaluator draws no randomness. From v15 every pin must match exact strategy
 encoding, size, case, UUID version/variant and zero trailing bits. Invalid pins
-are Contract rejections, not client validation failures. Older models retain
+are Contract rejections, not client validation failures. Rule-bearing concepts
+also check rules, including implicit UUID. Pin date segments with `given clock`;
+all segments must match the same UTC instant. Without a clock only digit widths
+are checked, never the wall clock. Opaque generation rules consume String pins
+without executing attached code; opaque validation still yields Unsupported.
+Older rule-free implicit-UUID models retain
 canonical UUID checks without a version check. Complete executable examples:
 [generated responses](../../cratis-screenplay-toolchain/references/generated-responses-example.md)
 and [generation strategies](../../cratis-screenplay-toolchain/references/generation-strategies-example.md).
@@ -188,7 +225,7 @@ and [generation strategies](../../cratis-screenplay-toolchain/references/generat
 ## What the CLI and Stage realize
 
 Stage emits strategy-specific `IGeneratable<T>.New()` factories over Fundamentals
-7.24.0 or later (via the Arc scaffold pin in Stage's `references/rendered-application.md`). v15 generated destinations use explicit
+7.25.0 or later for pattern/random/checksum (via the Arc scaffold pin in Stage's `references/rendered-application.md`). v15 generated destinations use explicit
 `EventsWithConcurrencyScopes` with `BeforeFirst` whole-source scopes; Chronicle
 checks atomically at append: a batch's scopes are checked once against the state before
 the batch, all or nothing, and a storage retry that renumbers the append checks them again. Generated rejection specs assert
@@ -201,10 +238,12 @@ Requires Stage 4.94.0 or later for receipt-time generation; older factories use
 
 | Refusal | Still unsupported |
 | --- | --- |
-| STAGE-ESM-028 | Unknown strategies, non-concepts, optional/collection generation; every explicit strategy on the legacy syntax engine |
-| STAGE-ESM-011 | A v15 fixture that does not match its strategy shape |
-| STAGE-ESM-038 | Routing combined with generation/responses; generated-property rules/requirements or concept rules; occurrence parameter/response/factory name collisions; unsupported response sources/composites/collections; generated identifier plus destination-less plain production |
-| STAGE-ESM-038 | Unpinned generation with unordered event, read-model or query expectations |
+| STAGE-ESM-028 | `generate rule`, unknown strategies, non-concepts, optional/collection generation; every explicit strategy on the legacy syntax engine |
+| STAGE-ESM-011 | A fixture that does not match its strategy shape or concept rules |
+| STAGE-ESM-038 | Routing combined with generation/responses; generated-property rules/requirements; occurrence parameter/response/factory name collisions; unsupported response sources/composites/collections; generated identifier plus destination-less plain production |
+| STAGE-ESM-038 | Unpinned generation with any Unproven/Refuted concept rule, production-condition reads, unordered event/read-model/query expectations or collision-sensitive generated constraints |
+| STAGE-ESM-042 | Unsupported concept-rule kinds; checksum remains refused only on the legacy syntax path |
+| STAGE-ESM-005 | Opaque/unsupported generated-concept rules, before pin evaluation |
 | STAGE-ESM-004 / -006 | StateChange slices without commands / expression or enum production conditions |
 
 Sequence generation is refused at binding (PLAY0682) and never reaches Stage;
@@ -213,7 +252,22 @@ command `given clock` fixtures render when whole milliseconds at or after 1970;
 
 Requires Stage 4.95.0 for command clock fixtures, 4.98.0 for multiple commands and
 conditional productions, and 4.100.0 for generated text unique constraints; older
-renderers refuse those shapes. ESM v20 still needs a renderer that admits v20.
+renderers refuse those shapes.
+
+Requires Stage 4.109.0 for ESM v20 factories plus `ConceptValidator`; older renderers refuse v20.
+Requires Stage 4.115.0 for ESM v21 admission and all-Proven unpinned generation;
+older renderers require pins even for Proven rules. Unproven/Refuted rules still
+require pins (-038), and invalid pins fail -011.
+Requires Stage 4.117.0 for warning/info-severity generated-concept rules; older
+renderers refuse them with -038. Every severity is enforced as a generation defect.
+Requires Stage 4.118.0 for semantic checksum validation and 4.119.0 for
+pattern/random factories, Host sampling and executor fixture checks; older
+renderers refuse those constructs with -042/-028. Dated patterns use receipt-time
+context; Int ranges render as `long`. `generate rule` still refuses -028.
+Requires Arc.Screenplay 22.107.0 for pattern/random/checksum and self-contained
+String-rule recovery; older adapters leave these factories in code. Recovery is
+not Stage rendering: keep refused rule contracts for gap-fill, never delete rules
+or secret classification.
 
 Missing pins in generated Debug specs use `AllowGeneration()` with relational
 assertions against captured values; v15 captures also check strategy shape.