@cratis/pi 7.62.0 → 7.63.0

package/package/corpus/skills/cratis-screenplay-scenario-coverage/SKILL.md

@@ -7,11 +7,10 @@ license: MIT
 # Screenplay scenario coverage
 
 ## Purpose
-Turn designed slices into specifications that pin behaviour a business person would argue
-about. Decide **which** situations need a specification before writing any (coverage matrix),
-then write them with consistent example data in the form the chosen mode admits. Situations the
-language cannot express today are recorded, not faked. Grammar and outcome comparison live in
-`cratis-screenplay-specifications`; this skill owns coverage and method.
+Decide **which** situations need specifications in a coverage matrix, then use
+consistent example data and mode-admitted forms. Record inexpressible cases; never
+fake them. This skill owns coverage; `cratis-screenplay-specifications` owns grammar
+and outcome comparison.
 
 ## When / when not
 - Use: the scenario phase of `cratis-screenplay-modeling-lifecycle`; adding or changing a
@@ -33,11 +32,9 @@ Use it to seed, never replace, the matrix. Multi-step storylines remain unavaila
 lifecycle families emulate them.
 
 ## Interview phase
-**Skip if** the brief already states the coverage depth (rules, denials, state violations,
-retries, races), the critical rules with an allowed and a refused example each, how the specs
-will be used (reference only, executable, rendered and tested) and who validates them.
-Critical questions, one at a time, with follow-ups:
-Ask only what is missing: depth, known rules and edge cases (one allowed and the nearest refused request per rule), intended use (decides admitted forms), and who validates. Read [references/interview-batch.md](references/interview-batch.md) for the four questions and follow-ups.
+Ask only what is missing: coverage depth, allowed/refused rule examples, intended
+execution mode and who validates. Read [interview prompts](references/interview-batch.md)
+when these inputs are unsettled; skip answered questions.
 
 **Unattended:** assume visibly, never invent a rule, and record who actually answered; an agent asking itself four kinds of question is not four approvals.
 
@@ -64,23 +61,22 @@ Ask only what is missing: depth, known rules and edge cases (one allowed and the
    existing intentional fixtures (`references/scenario-catalogue.md` "Example data"). Shared
    fixtures may live as typed `example`s in another document beside the declarations they type
    (`cratis-screenplay-specifications` `references/examples-and-routes.md`).
-7. **Draft commands**: happy path, each rule, denial, duplicates and retries, competing claims,
-   state violations, alternative branches, compensation, external failure, evolution. In each
-   rejection vary only the value under test. Use typed `parameter`/named `case`
-   tables for a shared validation matrix, not for unrelated behaviors; rows are
-   cases, not typed fixture `example`s. `given caller as <Persona>` supplies one
-   authenticated policy witness for success/denial; use explicit callers for
-   anonymous/ownership or unsynthesizable personas. Syntax and complete model:
-   `cratis-screenplay-specifications` `references/persona-callers-and-cases.md`.
+7. **Draft commands** for each applicable scenario type below. Vary only the value
+   under test in a rejection. Read specifications'
+   [persona callers and cases](../cratis-screenplay-specifications/references/persona-callers-and-cases.md)
+   when sharing a validation matrix or choosing synthesized versus explicit callers;
+   cases are not fixture examples and do not group unrelated behaviors.
 8. **Separate view pass**: population, each update, accumulation, removal (with a surviving
    row), absence, ordering. Mark lifecycle branches. Views combining sources must
    tolerate any arrival order. Pin a child before its parent (Requires Screenplay 4.149.1 or later):
    given child, then parent, then read model; "parent never arrives" leaves the
    child absent. Evidence/example: `references/view-and-story-specs.md`.
-9. **State-dependent rules**: `reads <View>` + `require <expr> message "..."` as stated intent,
-   marked **NOT enforced in the model today** in the slice `description` (binding reports
-   PLAY0268/0271: expected in design mode; Screenplay#129), target named (Arc
-   `[ProtectedDecision]` + `DecisionRead<T>`, Chronicle DCB, or a constraint). Forbidden:
+9. **State-dependent rules**: use `reads` plus `require` over authoritative state;
+   eligible views opt into `command reads protected` (v25). Cover present/absent reads,
+   refusal and denial; matching decide/commit changes are conflicts, not refusals.
+   Read [protected reads](../cratis-screenplay-command-surface/references/protected-reads.md)
+   for admission and Stage refusal; legacy/refused shapes remain marked unenforced
+   with a named target mechanism. Forbidden:
    caller-supplied copies of state in `require`, boolean attestation inputs (`confirmsX ==
    true`) and rules hidden in `handler`/hint prose. Never drop an unresolved given or assertion
    to make a spec compile: record the blocked case and continue.
@@ -101,11 +97,10 @@ when specifying malformed keys/filters versus valid absence (ESM v18).
 Requires Screenplay 4.157.0 (`screenplay --version`) for v17, 4.161.0 for query
 validation/error assertions; older tools do not execute these contracts.
 
-**Once, idempotent, exactly once are different claims.** A `unique event` constraint proves the
-*fact* occurs once per event source; it does not make *command handling* idempotent (a retry is
-rejected, not answered with success), and nothing in the model proves an *external effect* (an
-email, a payment) happens exactly once. Say which of the three a spec proves; record the rest as
-target requirements.
+**Once, idempotent, exactly once are different claims.** `unique event` proves a once-only fact,
+not successful retry handling or an exactly-once external effect. Name the claim
+proved and keep other guarantees as target requirements; recovery cases are in
+`references/scenario-catalogue.md`.
 
 ## Rules
 ### Compiler contracts
@@ -116,7 +111,8 @@ target requirements.
   or query spec needs `given caller` or `given caller as <Persona>` (module and feature gates count); an authorized scenario
   gets no inferred fixture (PLAY0389). Unauthorized is never `then error`.
 - Duplicate and competing specs use `when <Command>`; `when append` is for projection and
-  automation triggers, and for a constraint the command's own validation would reject first.
+  automation triggers, consumed public events driving captures, and for a
+  constraint the command's own validation would reject first.
 - `null` only for optional read-model properties; constraint messages are copied verbatim.
 - Executable-only binding checks (PLAY0350/0352/0388/0389/0273) do not show in V1: run V3.
 
@@ -126,6 +122,8 @@ target requirements.
   (denial), `<View>LifecycleN<State>` for families.
 - `for` on every given, appended and expected event (plain `produces <Name>` too; inline `produces event` omits it), and on the `when` command where the
   destination matters. A competing-claim given needs a *different* `for`.
+  Foreign event fixtures feeding a capture may omit `for`; supplied `for` is
+  opaque source text, not the capture's content key.
 - Format rules belong on a `concept`: give each concept rule representative acceptance,
   rejection and boundary specs once (through one command that carries it), not on every use;
   never `n/a` automatically. Include a whitespace-only rejection for text `not empty`:
@@ -149,7 +147,16 @@ Read [references/review-questions.md](references/review-questions.md) for the ra
 
 ## Public-event coverage (ESM v9)
 
-Outbound publication needs `when append <private>` and `then <PublicEvent>`. Read [references/public-event-coverage.md](references/public-event-coverage.md) when specifying public events or routed producers and observers.
+Outbound publication needs `when append <private>` and `then <PublicEvent>`.
+Captures over public events use `given <FromEvent>` / `when append <FromEvent>`,
+not capture records (PLAY0701). Read [references/public-event-coverage.md](references/public-event-coverage.md)
+when specifying public events or routed producers and observers.
+
+Record captures distinguish first sight from updates: first root/child/nested
+records are added only, so field guards need `given capture` for the same key.
+Use a separate `when added` append when initial observations should produce a fact.
+Read captures-and-reactions `references/record-capture-specifications.md` for the
+prerequisite and runnable cases. Include first, changed and unchanged rows in the matrix.
 
 ## Version skew: reaction cascades and false PLAY0285
 Under ESM v6 a command spec's `then` lists the events reactions cascade from it; an older `cratis` bundle reports a **false PLAY0285** for it. Never delete the reaction. Read [references/version-skew.md](references/version-skew.md) when a spec with cascade events reports PLAY0285 or the bundled compiler is older than the standalone tool.

package/package/corpus/skills/cratis-screenplay-scenario-coverage/references/berth-reservations.md

@@ -1,5 +1,11 @@
 # Berth reservations: worked example
 
+This is a legacy control without `command reads protected`; the unprotected-read
+markers below describe that control, not all command reads. Eligible views can opt
+into v25; the date-rule blocker still remains. Read
+[protected reads](../../cratis-screenplay-command-surface/references/protected-reads.md)
+for admission and Stage's protected-read refusal (STAGE-ESM-044).
+
 Complete, compiled design-mode model (marina guest berths) showing a coverage matrix turned into specifications: happy path, one rejection per rule, authorization denial, duplicate and retry, competing claim, state violation, alternative branches, compensation and a view lifecycle family. The matrix for it is in `coverage-matrix.md`; the catalogue (`scenario-catalogue.md`) names its specifications.
 
 ```screenplay test=unbound

package/package/corpus/skills/cratis-screenplay-scenario-coverage/references/invoicing-dues-design.md

@@ -1,6 +1,13 @@
 # Invoicing and dues: design-mode document for the stored-state rules
 
-**Design mode, not binding-ready by design.** This document states the stored-state rules of the
+**Legacy control without `command reads protected`, not binding-ready by design.**
+Read [protected reads](../../cratis-screenplay-command-surface/references/protected-reads.md)
+for the opt-in alternative. Do not insert the preamble blindly: every read must meet
+finite event-source-keyed admission with removals. A v25 reference pass still does not
+render protected reads: Stage admits v25 but refuses them with STAGE-ESM-044. The comments and unenforced markers below describe
+this legacy control, not a general limit on command reads.
+
+**Design mode.** This document states the stored-state rules of the
 invoicing example as the skill requires (`reads <View>` + `require ... message`, marked NOT
 enforced in the slice `description`, target named). It compiles (V1, warnings as errors) but
 does not bind, and the only blockers are `reads` (PLAY0271) and `require` over
@@ -17,7 +24,7 @@ The excerpt's Stage API-availability comment describes the historical Stage 4.24
 scaffold. Stage 4.73.1's scaffold pins an Arc/Chronicle set (see the Stage skill's `references/rendered-application.md`): protected-read APIs are
 available to gap-fill (the "not in a Stage-rendered application" comment in the source is
 superseded), not emitted protection or `.play` rule admission. The
-original compiled source is retained unchanged.
+capture uses separate first-sight/update appends, with its local-event follow-up in Automation.
 
 ```screenplay expect PLAY0516 test=unbound
 // Scenario coverage design-mode example: stored-state rules of invoicing club dues (complete document).
@@ -89,6 +96,10 @@ module Invoicing
           outcome = outcome translate
             "C" => captured
             "D" => declined
+        append PaymentGatewayResultReceived
+          when added
+            outcome = $.outcome
+            reason  = $.reason
         append PaymentGatewayResultReceived
           when outcome
             outcome = $.outcome
@@ -96,15 +107,15 @@ module Invoicing
       event PaymentGatewayResultReceived
         outcome GatewayOutcome
         reason  String
-      event PaymentReceived
 
-    slice Automation TranslatePaymentGatewayResults
+    slice Automation RecordPaymentOutcome
       description "Gives PaymentReceived its producer: the translator reacts to the provider's external fact"
       reaction ReceivedTranslator
         when PaymentGatewayResultReceived
           outcome
           produces PaymentReceived
         where outcome == "captured"
+      event PaymentReceived
 
     slice StateChange SettleOrVoidInvoice
       description "An invoice ends either settled or voided, never both (SettleOrVoid, enforced at append). NOT enforced in the model today: that the invoice exists and is still open (settling) and that only an open, unpaid invoice may be voided. Stated as `reads OpenInvoice` + `require` (PLAY0271/PLAY0268 at binding; Screenplay#129). Target: Arc [ProtectedDecision] with DecisionRead, or a Chronicle DCB. Requirements to test in the target: settling an unknown invoice is rejected; voiding a paid invoice is rejected; voiding an open invoice succeeds."

package/package/corpus/skills/cratis-screenplay-scenario-coverage/references/invoicing-dues-example.md

@@ -13,8 +13,10 @@ destination-type information; a reaction can also consume events from a capture
 
 **Scope.** This document is the runnable demonstration only. It deliberately holds no rule that
 depends on stored state (the invoice must exist, only an open invoice may be voided, a reversal
-needs a received payment, `reads` + `require`): those rules cannot bind or run at Screenplay
-4.66.0 (PLAY0271, PLAY0268) and are stated in the design-mode document `invoicing-dues-design.md`,
+needs a received payment, `reads` + `require`): the legacy design control lacks
+`command reads protected` and retains PLAY0271/PLAY0268. Eligible reads can opt into
+v25; see command-surface protected-read admission and Stage refusal. The rules stay
+in the design-mode document `invoicing-dues-design.md`,
 never in prose here. It shows the category shapes; for a coverage example see `berth-reservations.md`.
 
 ```screenplay
@@ -208,27 +210,13 @@ module Invoicing
           when added
             outcome = $.outcome
             reason  = $.reason
+        append PaymentGatewayResultReceived
+          when outcome
+            outcome = $.outcome
+            reason  = $.reason
       event PaymentGatewayResultReceived
         outcome GatewayOutcome
         reason  String
-      event PaymentReceived
-      event PaymentDeclined
-        reason String
-
-    slice Automation TranslatePaymentGatewayResults
-      description "Our facts from the provider's: the translators react to the external fact the Translate slice records"
-      reaction ReceivedTranslator
-        when PaymentGatewayResultReceived
-          outcome
-          produces PaymentReceived
-        where outcome == "captured"
-      reaction DeclinedTranslator
-        when PaymentGatewayResultReceived
-          outcome
-          reason
-          produces PaymentDeclined
-            reason = reason
-        where outcome == "declined"
 
       specification TranslatingADeclinedCardResult
         when capture PaymentGatewayResults
@@ -243,6 +231,23 @@ module Invoicing
           for "9c1f0a52-6a4e-4b1c-9f55-0d2c7b8e1a01"
           reason = "Card declined"
 
+    slice Automation RecordPaymentOutcome
+      reaction ReceivedTranslator
+        when PaymentGatewayResultReceived
+          outcome
+          produces PaymentReceived
+        where outcome == "captured"
+      reaction DeclinedTranslator
+        when PaymentGatewayResultReceived
+          outcome
+          reason
+          produces PaymentDeclined
+            reason = reason
+        where outcome == "declined"
+      event PaymentReceived
+      event PaymentDeclined
+        reason String
+
     slice StateView OpenInvoices
       description "Todo list: membership means 'still to collect'; there is no status flag."
       readmodel OpenInvoice

package/package/corpus/skills/cratis-screenplay-scenario-coverage/references/public-event-coverage.md

@@ -4,9 +4,20 @@ Coverage for public events and routed producers.
 
 Outbound publication needs `when append <private>` and `then <PublicEvent>`:
 complete state, incomplete state, unchanged repeat, changed instance, separate
-source ids and the exported field boundary. Reference publication is executable;
-source-event captures and reached opaque event-target reducers are typed
-Unsupported. Read automations-and-translations `references/public-events-and-direction.md`.
+source ids and the exported field boundary. Reference publication and admitted
+source-event captures execute; reached opaque event-target reducers remain typed
+Unsupported. Read automations-and-translations `references/public-events-and-direction.md`
+for the prerequisite and complete typed capture specifications.
+
+For `source events`, use `given <FromEvent>` / `when append <FromEvent>`, not
+`given capture` / `when capture` (PLAY0701). Cover first added, unchanged overlays,
+updates after ordered givens, properties retained across different event types,
+and independent keys. The key must be required on every source event, not a
+context key (PLAY0700); optional foreign fixture `for` is not that key.
+Assertions list all follow-up facts, never the input append itself. Mixed capture
+and reaction expectations may need `then events in any order`; this is not proof
+of observer order or redelivery deduplication. Children/nested over events and
+context members other than `occurred` are not admitted execution.
 For routed producers/observers, cover override versus inherited route, skipped
 production route failure, matching/wrong source/stream and unrouted facts;
 see toolchain `references/production-routes-and-filters.md`.

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

@@ -15,8 +15,10 @@ easily. Every excerpt below is copied verbatim from the complete document in
 `invoicing-dues-example.md`, which compiles with warnings as errors and whose 23 specifications
 pass in the reference evaluator; it also holds the declarations the excerpts depend on. The two
 compensation excerpts in section 4 come from `invoicing-dues-design.md` instead: that document
-holds the stored-state rules (`reads` + `require`), compiles but does not bind (PLAY0271,
-PLAY0268), so its specifications are design mode and do not run. A second
+holds stored-state rules as a legacy control without `command reads protected`, so
+it compiles but does not bind (PLAY0271/PLAY0268) and its design specs do not run.
+Eligible reads can instead opt into v25; inspect admission and keep Stage refusal
+separate (command-surface [protected reads](../../cratis-screenplay-command-surface/references/protected-reads.md)). A second
 complete example, with competing claims and denial fixtures, is `berth-reservations.md`. The category structure and the good/bad contrast follow the worked
 examples in `eventmodeling-elaborating-scenarios` by TrogonStack and by Martin Dilger and Nebulit GmbH (`provenance.md`), translated to
 Screenplay specifications.
@@ -104,7 +106,11 @@ in `invoicing-dues-design.md`; it is never prose and never a spec that pretends
 ## 3. External failure: the capture, then the retry
 Two separate obligations. First, the **capture specification**: concrete external input in, our
 facts out. The provider's refusal is a fact (never a `then error`), kept in the provider's
-vocabulary and then translated.
+vocabulary; a separate Automation records the local outcome. The capture uses
+`when added` for first sight and a separate `when outcome` for updates. An update
+spec needs `given capture` with the same key's earlier record; the first record's
+fields are not modifications (root, child or nested). See captures-and-reactions
+`references/record-capture-specifications.md` for runnable first/update/repeat cases.
 ```screenplay excerpt parent=references/invoicing-dues-example.md#1
 specification TranslatingADeclinedCardResult
   when capture PaymentGatewayResults

package/package/corpus/skills/cratis-screenplay-scenario-coverage/references/spec-forms-by-mode.md

@@ -21,7 +21,8 @@ Typed example/override forms: `cratis-screenplay-specifications`
 | Context `from`, single-result filters, `scoped to`, `performer` or composite `by` | yes | PLAY0268: query context, collection-only filtering, opaque scope/implementation or multipart lookup are unadmitted | no |
 | `then no readmodel <RM> for "<key>"` | yes | yes | no |
 | `when query` -> `then result` / `then no result` | yes | yes | same as `then query`: only the query-only cases below |
-| `given clock` / `when clock`, `when trigger`, `given`/`when capture` | yes | yes (standalone and any cratis whose compiler admits v6; an older bundle does not, see toolchain `references/executable-subset.md`) | no |
+| `given clock` / `when clock`, `when trigger`, record-source `given`/`when capture` | yes | yes (standalone and any cratis whose compiler admits v6; an older bundle does not, see toolchain `references/executable-subset.md`) | no |
+| Event-source capture fixtures | `given <FromEvent>` / `when append <FromEvent>`, not capture records (PLAY0701) | admitted root capture behavior executes; see `public-event-coverage.md` for prerequisites and limits | separate target admission |
 | Command spec listing reaction cascade events | yes (v6 semantics) | false PLAY0285 on an older cratis bundle only; see SKILL.md "Version skew" | no: STAGE-ESM-011; generated CommandScenario does not settle reactions |
 | `generated <name> = <value>` under `when`, `then returns` (ESM v7) | yes | yes on a compiler that admits v7 (PLAY0268 on an older bundle) | yes on Stage for supported UUID/String strategies and v15 freshness and scalar/named responses; unsupported types/combinations remain -028/-038 |
 | v15 generation strategy fixtures and used-source rejection | yes | strict encoding/size/case/version/variant; Contract for invalid pins, Concurrency for reused source | supported strategies/freshness render; invalid pins refuse -011, unpinned unordered/projected assertions -038; source: command-surface `references/generated-values-and-responses.md` |
@@ -35,7 +36,10 @@ Typed example/override forms: `cratis-screenplay-specifications`
 | Composite (JSON) values in specs | yes | yes | no |
 | Rules over dates or `today`, nested paths | spec them in design | rule does not bind: `recorded` | `recorded` |
 | Bodied rules, code policies | spec them | spec reported **unsupported**, never passed | no |
-| Command handlers, `file` constraints, query `performer`s | spec them in design | blocked: PLAY0268 at binding, no spec runs (V3 blocked) | no |
+| Pending described command handlers (v23) | specify intent | binds; denial/validation execute, body-reaching specs Unsupported ImplementationBody; all-Unsupported is not green | STAGE-IMPL-002 even Stub mode |
+| Attached command handlers, `file` constraints, query `performer`s | spec them in design | blocked: PLAY0268 at binding, no spec runs (V3 blocked) | no |
+| Atomic reaction mode (v22) | declare for new models | failed batch adds no facts or view changes; earlier batches/commands remain; `then error` alone is insufficient | v22 STAGE-ESM-016; mode in admitted v23–v25 STAGE-ESM-043 |
+| Protected command reads (v25) | declare opt-in for eligible reads | absence Validation; matching intervening facts Conflict; race vectors are not a new spec construct | protected reads STAGE-ESM-044; v25 pair admitted |
 
 Requires Screenplay 4.105.0 or later (`screenplay --version`) for list-query specifications, and 4.143.0 or later for collection equality filters (ESM v14).
 
@@ -49,7 +53,7 @@ older cratis bundle is available). Mark each such spec in the coverage matrix as
 `gap: <reason>` for the narrower modes so the verification and render phases know what will not execute.
 
 ## Executable mode
-- Every gated spec has `given caller`; every given/expected event has `for`, and so does every plain `produces <Name>` (inline `produces event` omits it and defaults to the identifier).
+- Every gated spec has `given caller`; local given/expected events have `for`, and so does every plain `produces <Name>` (inline `produces event` omits it and defaults to the identifier). Foreign event fixtures driving captures may omit `for`; a supplied value is opaque source text, not the capture key.
 - Each read model has one key shared by its keyed `=> RM optional` queries; the identifier equals
   the projection's effective key (`cratis-screenplay-slice-design` `references/read-model-design.md`
   decision table). View specs assert through a keyed query.

package/package/corpus/skills/cratis-screenplay-slice-design/SKILL.md

@@ -157,7 +157,9 @@ When `.screenplay/identities.json` exists, adding, removing or renaming an addre
 Slice design is done when these hold; otherwise report what is open.
 
 - [ ] Every command: origin reachable and authorized; every input traced; rules placed by
-      layer; stored-state rules recorded NOT enforced with a named target; no form-verb name.
+      layer; stored-state rules use admitted protected reads, or name the refused shape
+      and target gap; no form-verb name. Read [protected reads](../cratis-screenplay-command-surface/references/protected-reads.md)
+      for opt-in and Stage refusal; reference protection is not target realization.
 - [ ] Every command has a refusal inventory (success, each refusal with layer and message,
       denied persona); every gated command and query has a `then denied` row.
 - [ ] Every event is past tense, a specific change, and consumed or justified.

package/package/corpus/skills/cratis-screenplay-slice-design/references/command-inventory.md

@@ -171,13 +171,13 @@ Rules for filling it:
 | AssignLocker | caller is not an attendant | `authorize IsAttendant` | denied: Customer | RefusingACustomerAssigningALocker |
 | AssignLocker | locker already has a request | constraint `OneRequestPerLocker` | "The locker is already assigned" | AppendingASecondAssignmentOfALocker (`when append`: the command's own `require` would reject first) |
 | AssignLocker | request already has a locker | constraint `OneLockerPerRequest` | "The request already has a locker" | gap |
-| AssignLocker | locker is not free | `reads` + `require`, NOT enforced today | "The locker is not free"; target: `[ProtectedDecision]` (Arc 22.39.0+; available to Stage 4.73.1 gap-fill, not emitted protection) or DCB on the locker stream | RejectingASecondAssignmentOfALocker (pins the message; blocked until the target exists) |
-| AssignLocker | request is not waiting | `reads` + `require`, NOT enforced today | "The request is not waiting for a locker" | gap (same) |
+| AssignLocker | locker is not free | Legacy example lacks protected-read opt-in; inspect v25 admission and Stage gap | "The locker is not free"; target: `[ProtectedDecision]` (Arc 22.39.0+; available to Stage 4.73.1 gap-fill, not emitted protection) or DCB on the locker stream | RejectingASecondAssignmentOfALocker (pins the message; blocked until the target exists) |
+| AssignLocker | request is not waiting | Legacy example lacks protected-read opt-in; inspect v25 admission and Stage gap | "The request is not waiting for a locker" | gap (same) |
 | LockerById, ListLockers | caller is anonymous | module `authorize IsAuthenticated` | denied: no caller | RefusingAnAnonymousLockerLookup, RefusingAnAnonymousLockerList |
 | RequestById | caller is anonymous | module `authorize IsAuthenticated` | denied: no caller | RefusingAnAnonymousRequestLookup |
 
-The gaps are the hand-off: most are cheap rejection specs, and two are blocked on a target the
-model cannot express yet. A model whose inventory shows no gaps at design time has probably
+The gaps are the hand-off: most are cheap rejection specs, and two need protected-read admission plus separately verified target realization;
+the legacy example has not opted into v25. A model whose inventory shows no gaps at design time has probably
 not been asked the refusal questions.
 
 ## Common mistakes

package/package/corpus/skills/cratis-screenplay-slice-design/references/rule-layers.md

@@ -11,14 +11,16 @@ code only as XML doc comments (Stage#178): a rule that exists only in prose is u
 | who may ask | `authorize` with a policy (role, claim, authenticated) | enclosing gates combine with AND and run first. Gates every command and query in a feature shares go on the feature or module so a new path inherits them |
 | whose instance | policy `claim "x" matches subject` (the command identifier) or `matches <command property>` | executable; renders for text, Uuid, Date and DateTime subjects; an authorized command needs exactly one identifier (STAGE-ESM-015 otherwise) |
 | uniqueness, once-only facts | `constraint` (`unique ... on`, `unique event`) | append-time; the constraint name is its identity |
-| stored state (record exists, balance, current status) | `reads <View>` + `require <expr> message "..."` | stated intent, **NOT enforced in the model today** (PLAY0268/0271 at binding are expected in design mode). Name the target: Arc `[ProtectedDecision]` + `DecisionRead<T>` (Requires Arc 22.39.0 or later), Chronicle DCB (`concurrency` scope), or a constraint |
+| stored state (record exists, balance, current status) | `reads <View>` + `require` with an indented message | opt eligible reads into `command reads protected` (v25); absence Validation, matching intervening facts Conflict. Legacy/refused shapes stay stated intent with a named target mechanism |
 
 An unguarded materialized read is unsafe for a protected decision; a guarded read is the
 supported route. Availability: `[ProtectedDecision]` and `DecisionRead<T>` exist in
 the Arc/Chronicle package set Stage scaffolds (see the Stage skill's `references/rendered-application.md`), but Stage does not emit
 protected decisions. Gap-fill must use an admitted projection/key shape and active
 unit-of-work enrollment; do not edit managed dependencies. Keep the `.play` rule
-NOT enforced until its target enforcement is separately verified. Forbidden: caller-supplied copies of state in `require`, boolean attestation
+target enforcement separate from reference semantics until target tests verify it.
+Read [protected command reads](../../cratis-screenplay-command-surface/references/protected-reads.md)
+for admission and Stage's protected-read refusal (STAGE-ESM-044); never remove protection to obtain rendering. Forbidden: caller-supplied copies of state in `require`, boolean attestation
 inputs (`confirmsX == true`), rules in `handler` / implementation-hint prose.
 
 ## Authorization is executable

package/package/corpus/skills/cratis-screenplay-slice-design/references/slicing.md

@@ -97,14 +97,15 @@ module Moorings
 Record, per slice, the events it consumes and which slice produces each. This is for
 orientation, not a build order: view specifications use synthetic `given` events, so slices
 are built and checked independently. A command or reaction may consult another slice's view
-(`reads`; unprotected in `.play`, see `rule-layers.md`). A slice never calls another slice's
+(`reads`; eligible command reads can opt into v25 protection, trigger reads cannot;
+see `rule-layers.md` for target gaps). A slice never calls another slice's
 command except through `invokes`. Dependencies run in one direction; a cycle through events
 means the story is a feedback loop that belongs in an `Automation` slice.
 
 The contract between slices is events: slice B depends on slice A because B's command, rule
 or view needs an event A produces. Two other edges are supported and recorded explicitly, never
-implied: `reads <View>` from another slice (unprotected, so a stored-state rule over it stays
-NOT enforced, `rule-layers.md`) and `invokes <Command>` from a reaction. No shared state or
+implied: `reads <View>` from another slice (declare protected-command opt-in and
+admission, or mark the legacy/refused shape and target gap, `rule-layers.md`) and `invokes <Command>` from a reaction. No shared state or
 other direct call. Name each
 slice after its element (the command, the view, the automation, the translation (capture or translator reaction)), not a broader feature name
 that spans several. Per slice, record:

package/package/corpus/skills/cratis-screenplay-slice-design/references/worked-example.md

@@ -1,13 +1,13 @@
 # Worked example: parcel lockers (design mode)
 
-One complete model for `cratis-screenplay-slice-design`. It is in **design mode**: V1 clean
-(compiles with warnings as errors); V3 is blocked on purpose by the `ListLockers` list query
-(`PLAY0268` at binding); `given clock` also failed binding on a cratis before 3.28.2 bundle (3.28.2 binds it)
-(`cratis-screenplay-toolchain` `SKILL.md`). Personas and screens are informational.
-The stored-state rules in `AssignLocker` (`reads` + `require`) are intent, not enforced today,
-and they also fail binding on their own: `PLAY0271` on each `reads`, and `PLAY0268` because the
-`require` operands (`locker.assigned`, `request.state`) must be command properties. So this
-document is design mode as a whole: V3 is blocked twice over and no specification runs here.
+One complete legacy design-mode control for `cratis-screenplay-slice-design`, without
+`command reads protected`. Its reads and read paths retain PLAY0271/PLAY0268, so no
+specification runs here. List queries and clock fixtures bind on an admitting compiler;
+they are not the remaining blocker. Personas and screens are informational.
+Eligible command reads can opt into v25; inspect every projection/key/removal before
+migration and retain Stage's separate refusal (STAGE-ESM-044; the v25 pair itself is admitted). Read
+[protected reads](../../cratis-screenplay-command-surface/references/protected-reads.md).
+The unenforced descriptions below refer to this legacy control, not all command reads.
 The specifications still seed every read-model source (`LockerInstalled`, `LockerRequested`,
 complete givens) so they are the right form once binding is possible.
 Lineage matrix: `field-lineage.md`. State-transition table and rule coverage: `slicing.md`.

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

@@ -40,41 +40,46 @@ Screenplay's reference runner executes specifications against an immutable
 in-memory world: no Arc, no Chronicle, no database, no network. Every downstream
 target has one normalized behavior to match.
 
-- It runs the capabilities the execution plan admits: declarative validation
-  and `require` over command properties, conditional production, literal tags,
-  declarative policies, `unique` constraints, and projections as Chronicle
-  lowers them. The `cratis-screenplay-model-authoring` language reference lists
-  what binds and what the plan admits.
-- Binding is not admission. These projection constructs bind, but the plan
-  refuses them: a projection-level `remove via join`; `all` beside removals,
-  `children` or `nested`; a `join`, `children` or `remove via join` inside
-  `nested`; and any `$eventContext.<path>` other than `eventSourceId`, such as
-  `$eventContext.occurred`. The limits apply at every ESM version.
-- A specification that needs **opaque code** — a bodied reducer, a rule with a
-  body, a fenced `validate` block, a code policy, or (ESM v6) a reached reaction
-  body — returns **unsupported** and
-  never passes. Authorization is evaluated first, so a `then denied` case still
-  runs when a portable policy decides it. Other specifications in the model run
-  normally.
-- Unsupported reachable declarative constructs block the whole execution plan
-  rather than running partially: no specification in the model runs, including
-  the ones that never touch the refused construct.
-- Reactions: before ESM v6 they never run, not even after `when append`. From ESM
-  v6 they run after every action, as in "Reactions and
-  cascades" ([references/reactions-and-cascades.md](references/reactions-and-cascades.md)). A compiler that stops before ESM v6 fails `when clock`, `when trigger`
-  and `when capture` binding with `PLAY0268`, and so reactions and captures.
-- Children defer until their parent exists; an ambiguous parent still fails closed.
-  [Child ordering](references/child-ordering.md): specs and routing caveat.
-
-  Requires Screenplay 4.149.1 or later (`screenplay --version`) for child deferral.
-- A rejected individual command or append leaves the world unchanged; an accepted
-  one commits once, then the read models and queries are compared. There is no
-  scenario-wide transaction in v6: when a later effect of a cascade or capture
-  rejects, the earlier accepted facts and their projections remain.
-
-Unsupported is not passed. Report it as "needs a target", not as green. "Specified"
-and "bound" are never "passing": run the reference CLI/MCP route or the owning
-target tests, and name the engine, version and expected/discovered selection.
+Binding is not plan admission. Read model-authoring's
+[language reference](../cratis-screenplay-model-authoring/references/language-reference.md)
+when distinguishing executable declarations, refused projection shapes and opaque
+code. Reached opaque code is **unsupported**, never passed; portable denial may
+still execute before it. Unsupported declarative constructs block the whole plan,
+not just the specifications that touch them.
+
+Read [reactions and cascades](references/reactions-and-cascades.md) when testing
+ESM v6 actions; older compilers fail reaction/capture binding with PLAY0268.
+Read [child ordering](references/child-ordering.md) for deferral;
+an ambiguous parent still fails closed.
+Requires Screenplay 4.149.1 or later (`screenplay --version`) for child deferral; older runners do not defer.
+
+A rejected command/append leaves the world unchanged; an accepted one commits
+before comparing views. V6 has no scenario-wide transaction: later cascade
+failure does not roll back earlier accepted facts. Atomic mode boundaries are below.
+
+Unsupported is not passed. Name a target. Run CLI/MCP reference execution
+or target tests; name engine, version and expected/discovered selection.
+
+## Batches, described bodies, protected reads and text rules
+
+- With `reaction batches atomic`, assert no facts from a failed direct-production or
+  selected refusal-branch batch and unchanged views through evaluator world assertions,
+  not only `then error`. `then no events` is acceptance and cannot accompany an error. Earlier
+  accepted batches/invoked commands remain; legacy absence retains per-fact appends.
+  Read [atomic boundaries](../cratis-screenplay-captures-and-reactions/references/atomic-batches-and-source-mappings.md).
+- A described handler binds v23, but reaching its body returns Unsupported
+  ImplementationBody, naming command/RequirementId and emitting no events. Denial and
+  validation cases still run; an all-Unsupported run is never green. Read
+  [described handlers](../cratis-screenplay-command-surface/references/described-handlers.md).
+- Protected command reads opt into v25. Test present/absent state and rule refusal;
+  matching decide/commit changes are Conflict / DecisionStateChanged, not validation
+  refusal. Race vectors are not new specification syntax. Read
+  [protected reads](../cratis-screenplay-command-surface/references/protected-reads.md).
+- Literal text rules use ordinal UTF-16 comparison (v24); matches uses a portable
+  linear matcher, not platform regex. Old invalid/refused patterns plan as
+  UnsupportedValidation, not a successful check. Read
+  [text and match rules](../cratis-screenplay-command-surface/references/text-and-match-rules.md)
+  for boundary values and PLAY0699/0787. Reference success is not Stage admission.
 
 ## Descriptions, persona callers and case tables
 
@@ -102,8 +107,7 @@ Rules the binder enforces:
 - **`then result` and `then no result` need `when query`**, and `when query`
   needs one of them, `then denied` or a sole validation `then error` (`PLAY0465`). Each argument is a `by` or
   `filter` parameter of the query (`PLAY0468`).
-- **A clock instant is ISO 8601 with an offset or `Z`**, such as
-  `"2026-10-05T08:00:00Z"` (`PLAY0461`); `given clock` appears at most once.
+- **A clock instant is ISO 8601 with an offset or `Z`** (PLAY0461); one `given clock` maximum.
 - **`then` contains either events or an error — never both.** A rejection
   specification has exactly one rejection and no success outcome.
 - **`then denied` stands alone**: not with events, errors or state assertions
@@ -114,10 +118,8 @@ Rules the binder enforces:
 - **`null` only in optional read-model values.** A `null` in a command or event
   value is `PLAY0350`: an optional fact is a separate event.
 
-`PLAY0358` is a syntax error (`PLAY0388` also at parse time for extra text after `then denied`). `PLAY0350`, `PLAY0352`, `PLAY0388` (mixed with another outcome), `PLAY0389` and
-the one-rejection rule (`PLAY0273`) are reported only when the model binds, so
-`screenplay --warnaserror` does not show them. Check executable diagnostics
-(the MCP authoring tools) as well.
+V1 does not report binding-only outcome errors; read `references/vocabulary.md`
+for parse-versus-bind diagnostics and check executable diagnostics too.
 
 ## How outcomes are compared
 
@@ -154,12 +156,12 @@ Read [references/reactions-and-cascades.md](references/reactions-and-cascades.md
 
 ## Published-event specifications (released ESM v9)
 
-Use `when append <PrivateEvent>` then `then <PublicEvent>` for outbound publication,
-not `then readmodel`. The follow-up event list is exhaustive and ordered. Read
-[publication example and fold cases](../cratis-screenplay-automations-and-translations/references/public-events-and-direction.md).
-Events-source captures and reached opaque event-target reducers return typed
-Unsupported, not a pass. Composite view fixtures need every key part but remain
-unadmitted (PLAY0268); see read-surface `references/named-keys.md`.
+Use `when append <PrivateEvent>` then `then <PublicEvent>`, not `then readmodel`;
+follow-up events are exhaustive and ordered. Read
+[publication and fold cases](../cratis-screenplay-automations-and-translations/references/public-events-and-direction.md)
+when specifying outbound facts or event-source captures: it owns the minimum
+compiler, PLAY0700/0701, key folding and Unsupported boundaries. Composite view
+fixtures remain unadmitted; see read-surface `references/named-keys.md`.
 
 ## Reusable fixtures, routes and recovery intent
 

package/package/corpus/skills/cratis-screenplay-specifications/references/actions-beyond-commands.md

@@ -7,7 +7,17 @@ A slice is not always set off by a command. Name what does:
 | A view no event builds - its query has a `performer` | `given readmodel` …, `when query <Query>`, `then result` / `then no result` |
 | An automation driven by the clock | `given clock "<instant>"`, `when clock "<later instant>"` |
 | An automation driven by an application trigger | `when trigger <Trigger>` with the values it carries |
-| A translation driven by a capture | `given capture <Capture>` (the record as it was), `when capture <Capture>` (as it is now) |
+| A translation driven by a record capture | `given capture <Capture>` (the record as it was), `when capture <Capture>` (as it is now) |
+| A capture with `source events` | `given <FromEvent>`, `when append <FromEvent>`; capture-record fixtures are PLAY0701 |
+
+A first record is `added` only, including child and nested records; field-change,
+`and`/`or` and transition guards need earlier state for the same key. For first sight
+add a separate `when added` append; for an update seed `given capture`. Requires
+Screenplay 4.175.0 or later (`screenplay --version`); older record evaluators treat
+first-record fields as changed. Complete cases: captures-and-reactions
+[record capture specifications](../../cratis-screenplay-captures-and-reactions/references/record-capture-specifications.md).
+Event captures use the typed event fixtures and overlay rules in
+[public event captures](../../cratis-screenplay-automations-and-translations/references/public-events-and-direction.md).
 
 Use `given clock`, never `given time`, to state the scenario occurrence time and
 assert a value mapped from `$context.occurred`. In a command's `produces`, that