@cratis/pi 7.23.0 → 7.24.0

package/package/corpus/skills/cratis-screenplay-render-and-gap-fill/SKILL.md

@@ -28,7 +28,7 @@ Version pins live once in `cratis-screenplay-toolchain` `references/versions.md`
 | cratis CLI | `3.41.0` (`v3.41.0`) | `cratis render` options, exit codes, publication receipt, UI-profile rejection (`CLI-RENDER-007` to `CLI-RENDER-010`); tag pins Stage 4.51.3, Screenplay 4.114.0 and `Cratis.Arc.Screenplay` 22.54.0, with `cratis/stage:4.51.3` as the runtime image. UI-profile rejection and render-then-recover shipped in 3.41.0 (Cratis/cli#301). The screens release vector was verified on 3.40.7 (`af9f18e`) with `cratis/stage:4.51.1`. Reading baselines: 3.40.3, 3.39.0 and 3.28.3 (`8b43fef`) |
 | Stage | `4.51.3` (CLI 3.41.0 default) | admission (`STAGE-ESM-*`, and `PLAY0268` render refusals surfaced by the CLI), ownership manifest, `Customizations/` seams, Debug-only specifications, fail-closed guarded actions (`STAGE-SCENE-ACTION-001`) and interactions (`STAGE-SCENE-INTERACTION-001`). Older baselines: 4.49.5, 4.43.0 and `v4.24.2` (`32dcac4`) |
 | Screenplay | bundled `4.114.0`; standalone `4.127.0` | standalone compiler for V1 to V3; binding codes `PLAY0268` and the code-attachment rules, read at `v4.66.0`; claims made through `cratis` are 4.114.0 claims |
-| Rendered apps | Arc `22.25.0`, Chronicle `19.8.1`, Scene packages | `[ProtectedDecision]` (Arc 22.39.0 and later) is not available in code written into one; verify the generated package set before claiming exact Scene 4.14.0 runtime parity |
+| Rendered apps | Arc `22.50.5`, Chronicle `19.32.0`, Scene packages | Stage 4.51.3 scaffold; `[ProtectedDecision]` / `DecisionRead<T>` available to gap-fill, not emitted enforcement. Embedded reverse extraction disabled; verify generated packages before claiming exact Scene runtime parity |
 
 Facts were read at those tags and `cratis render` was run at 3.28.2 and 3.28.3 for the worked example
 (`references/worked-example.md`); with public CLI 3.40.7 it was run over the canonical
@@ -135,10 +135,11 @@ Adapters and non-renderable scope follow the contract rules of `cratis-applicati
   (`cratis-application-slice-conformance` `references/build-prompts.md`).
 - One ledger scope per `slice-implementer` brief; the brief carries addresses and paths, not contents.
 - Model-enforced rules realized in code (state-dependent rules) need a protected read or
-  concurrency scope; never claim them from prose. In a Stage-rendered app, Arc is 22.25.0.
+  concurrency scope; never claim them from prose. Stage 4.51.3 rendered apps have
+  Arc 22.50.5/Chronicle 19.32.0; API availability alone is not verified enforcement.
 - Adapters that call outside systems follow `cratis-engineering-effect-boundaries`; slice
   specifications follow `cratis-application-slice-specifications`.
-- Realization notes are the explicit realization requirements stated in a slice `description`
+- Realization notes are the explicit realization requirements stated in a slice `description` or `documentation`
   (definition: `cratis-application-slice-conformance`, `references/contract-and-precedence.md`).
   Executable parts (specifications, mappings, constraints) win over prose, and a contradicting description is a model defect to report.
 

package/package/corpus/skills/cratis-screenplay-render-and-gap-fill/references/drift-and-ledger.md

@@ -57,7 +57,7 @@ non-renderable scope:
 | fallback location | project and folder of the hand-written code |
 | spec mapping | `.play` specification to test name, one line each; missing tests listed |
 | field inventory | `n/n` command, event and read-model properties mapped; extras: none, or listed with reason |
-| realization requirements applied | explicit realization notes from slice descriptions applied, one line each; other description prose used as a hint is listed separately |
+| realization requirements applied | explicit realization notes from slice `description` or `documentation` applied, one line each; other description prose used as a hint is listed separately |
 | spec delta | at re-delivery: specifications added, changed or removed since `last verified`, each with test status |
 | divergences | where the code deliberately differs from the model, with reason and approver |
 | revisit trigger | issue and condition (for example "Stage#58 ships list queries") |

package/package/corpus/skills/cratis-screenplay-render-and-gap-fill/references/gap-fill-handoff.md

@@ -27,7 +27,7 @@ paths and addresses, not pasted contents:
   with the same name; never weaken, skip or delete one to pass. Do not edit managed files.
   Return a field inventory (command, event and read-model properties mapped to code locations)
   and list anything you added that the model does not state (expected: none). Explicit
-  realization requirements in the slice description bind adapters and fallback code, cannot
+  realization requirements in the slice `description` or `documentation` bind adapters and fallback code, cannot
   contradict executable parts and are never supplemented with inferred rules; descriptive prose
   that is not an explicit requirement is a hint. The repository's pattern wins over a
   generic template; report the mismatch. Stop on a contradiction and return an edit request.*
@@ -61,8 +61,8 @@ ambiguous addresses; contracts are never inferred from names.
 A rule that exists only in a description, or a state-dependent rule the model marks as not
 enforced, is unenforced in generated scope. List it in the ledger as a target requirement. In
 hand-written code it needs an atomic enforcement point: a protected read or a concurrency scope
-(in a Stage-rendered application Arc is 22.25.0, which has no `[ProtectedDecision]`; a
-hand-written application on a newer Arc may use it), or a Chronicle constraint. A stale view or
+(Stage 4.51.3 rendered apps have Arc 22.50.5/Chronicle 19.32.0: protected-read APIs
+are available to gap-fill, with projection/key admission and active enrollment), or a Chronicle constraint. A stale view or
 a caller-supplied status is not enforcement.
 
 ## Automation and Translate scope

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

@@ -27,9 +27,11 @@ language cannot express today are recorded, not faked. Grammar and outcome compa
 Screenplay v4.66.0 (`c89198b`) and v4.68.0 (`79801bf`, ESM v7 fixtures and `then returns`):
 `Documentation/screenplay/specifications.md` and the standalone compiler; `cratis` 3.28.2 and
 3.28.3 bundle Screenplay 4.66.0 (before 3.28.2 it bundled 4.60.1). The full pin table and the probes are in
-`cratis-screenplay-toolchain` `references/versions.md`. Specification obligations reported by
-the MCP (Screenplay#390) and multi-step storylines (Screenplay#394) are **not available**: the
-coverage matrix is built by hand and lifecycle families emulate storylines.
+`cratis-screenplay-toolchain` `references/versions.md`. At Screenplay v4.127.0,
+MCP `find-specification-obligations` derives SPEC001–SPEC008 from declarations;
+met means matching authored presence, not full coverage or passing execution.
+Use it to seed, never replace, the matrix. Multi-step storylines remain unavailable;
+lifecycle families emulate them.
 
 ## Interview phase
 **Skip if** the brief already states the coverage depth (rules, denials, state violations,
@@ -56,7 +58,9 @@ question is not four approvals.
    (Cannot lines, "only if", refusals, competition candidates, endings) as coverage seeds.
 3. **Inventory before drafting**: read commands, effective gates (own, feature, module), rules,
    constraints, productions, reactions, captures, read models and queries in scope; derive the
-   obligations from those declarations, not from specs already present.
+   obligations from those declarations, not from specs already present. Use scoped
+   `find-specification-obligations` and inspect unmet/message-specific obligations;
+   ambiguous references and opaque code are not inferred coverage.
 4. **Coverage matrix before any spec** (`references/coverage-matrix.md`). Rows: every command,
    reaction, capture, read model and gated query. Columns: the scenario types below. Each cell
    is `spec <Name>`, `n/a: <domain reason>`, `recorded: <why not expressible>`,
@@ -70,7 +74,12 @@ question is not four approvals.
    existing intentional fixtures (`references/scenario-catalogue.md` "Example data").
 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.
+   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`.
 8. **Separate view pass**: population, each update, accumulation, removal (with a surviving
    row), absence, ordering. Mark lifecycle branches as branches.
 9. **State-dependent rules**: `reads <View>` + `require <expr> message "..."` as stated intent,
@@ -97,9 +106,16 @@ question is not four approvals.
 | Ordering | Facts late or out of order? | view family with reordered givens; translation specs; else `recorded` |
 | External failure | The other system refuses, times out or answers twice? | outcome as a recorded fact (capture/translation), never a fake rejection |
 | Compensation | How is this undone, what does undoing free? | reversal command + spec showing the released claim or removed row |
-| Evolution | Do old facts still mean the same after a contract change? | spec on the new generation; compatibility note in `description` |
+| Evolution | Do old facts still mean the same after a contract change? | spec on the new generation; compatibility reasoning in `documentation` |
 | View | What does each screen show after each fact? | `given` events (`for`) -> `then query`; `when append` -> update/removal |
 
+For recovery intent, `when redelivered <Event> to <Reaction>` must select one
+definitely matching effective given and no undecided candidate. Name `stream`
+(with a complete id) or `no stream` when givens differ only by route; omitting it
+is a wildcard, not an unrouted selector. Redelivery remains authoring-only
+(PLAY0268), never evidence of an executed retry. Details:
+`cratis-screenplay-specifications` `references/examples-and-routes.md`.
+
 **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
@@ -112,7 +128,7 @@ target requirements.
 - `then` events are exact in count and order (`then events in any order` relaxes order only).
 - Command denial: `then denied` with no success or error outcome. Read-only query denial:
   `then query <Query>` with `arguments` and no `result`, then `then denied`. Every gated command
-  or query spec needs `given caller` (module and feature gates count); an authorized scenario
+  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.
@@ -130,7 +146,7 @@ target requirements.
   never `n/a` automatically. This matches `cratis-screenplay-specifications`, which also
   requires one rejection spec per concept rule. Business rules get one rejection spec each.
 - Persona Cannot lines are intent: each needs an executable gate plus a `then denied` spec whose
-  caller carries that persona's roles and claims, else record a gap.
+  caller is a synthesized persona witness or an explicit gate fixture, else record a gap.
 - Descriptions are not rendered: a rule only in prose is unenforced in rendered scope; turn it
   into a rule layer, a spec or a recorded target requirement.
 - Prove projections with events (`given`/`when append`), not `given readmodel`; seed read models
@@ -149,7 +165,7 @@ target requirements.
 - Read models are a separate, equally mandatory pass: a model with dozens of command specs and no
   read-model spec is not scenario-complete. Population, then update or removal where an event
   supersedes a row.
-- The why behind each business rule is written down (slice `description`), not only the what.
+- The why behind each business rule is written down (slice `documentation`), not only the what.
 - Good and bad forms of givens, outcomes and rejections: `references/scenario-examples.md`.
 
 ### Review questions

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

@@ -9,7 +9,7 @@
 - Worked example (`berth-reservations.md`, design mode)
 
 Write it **before** drafting specs, keep it in `.ai-work/screenplay/<model-slug>/coverage.md` (or the
-`STATE.md` beside it), and update it with the specs. Reviewers check it against the model. The Screenplay MCP does not yet report which specifications a command, read model, policy or constraint still lacks (Screenplay#390, open, not available): the matrix is that report, built by hand from the declarations.
+`STATE.md` beside it), and update it with the specs. Reviewers check it against the model. Screenplay 4.127.0 MCP `find-specification-obligations` seeds the inventory (SPEC001–SPEC008), for command success, requirements, command/concept validation, effective authorization gates, value constraints, read models, projection removals and reaction outcomes. A met row proves matching authored presence, not full coverage or passing execution: the matrix still records domain judgments and scenario types the heuristic cannot infer.
 
 ## Cell values
 - `spec <Name>` - written; the name exists in the model.

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

@@ -13,6 +13,11 @@ Keep those lines: they state real intent and are never
 replaced by prose. The runnable counterpart, which holds no stored-state rule, is
 `invoicing-dues-example.md`; `scenario-examples.md` copies `ReversingAReceivedPayment` from here.
 
+The excerpt's Stage API-availability comment describes the historical Stage 4.24.x
+scaffold. Stage 4.51.3 pins Arc 22.50.5/Chronicle 19.32.0: protected-read APIs are
+available to gap-fill, not emitted protection or `.play` rule admission. The
+original compiled source is retained unchanged.
+
 ```screenplay
 // Scenario coverage design-mode example: stored-state rules of invoicing club dues (complete document).
 // Design mode: `reads` is PLAY0271 and `require` over a view is PLAY0268 at binding (the only

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

@@ -80,9 +80,12 @@ name them as unfinished.
   (commands: no other outcome; read-only queries: `then query <Query>` with `arguments`, no
   `result`, then `then denied`; or `when query` + `then denied`). See `RefusingASkipper`.
   An empty `given caller` block is the anonymous caller.
-- Specs cannot name a persona: write the caller as the roles and claims that persona's
-  policies grant and name the spec after the persona. One denial per persona that can reach the
-  screen but may not act. Derive fixtures from the effective Boolean gate: AND - isolate each
+- Use `given caller as <Persona>` for one authenticated witness synthesized from
+  that persona's policies (4.127.0). Inspect the leftmost buildable `or` choice;
+  it does not represent every possible caller. Use explicit roles/claims for
+  anonymous or ownership fixtures, missing conjuncts, or refused synthesis.
+  One denial per persona that can reach the screen but may not act. Derive
+  fixtures from the effective Boolean gate: AND - isolate each
   missing conjunct; OR - a caller meeting any permitted alternative must succeed (a success
   spec, not `then denied`); denial only when the whole gate is false.
 - Ownership policies (`claim ... matches subject|<property>`): the denial gives the right role
@@ -184,7 +187,7 @@ name them as unfinished.
 ## 11. Evolution compatibility
 - Ask (when an event's contract changes): "Do facts already stored still mean the same?"
 - Compatible change (added property with a defined default): declare the new generation;
-  specify behaviour on the new generation; write the default for old facts in `description`
+  specify behaviour on the new generation; write the default and its reason for old facts in `documentation`
   (Screenplay does not express upcasters). Change of meaning: a new event, with its own specs.
 - Renaming a stored event keeps an `id "<OldName>"` pin. A rename the brief requests is done in
   this pass by the identity owner (`cratis-screenplay-modeling-lifecycle`); never leave it silently unapplied.

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

@@ -29,7 +29,7 @@ Screenplay specifications.
 | Then (success) | every production with payload and `for` | "an event is produced" |
 | Then (refusal) | `then error "Invoice already settled"`, the rule's own message | `then error` with no message, or `then error ""` |
 | Then (denial) | `then denied` | `then error` for a caller who is not allowed |
-| Reason | the slice `description` says why the rule exists | the rule appears only in a spec title |
+| Reason | slice `documentation` says why the rule exists | the rule appears only in a spec title |
 
 ## 1. Command: success, rule rejection and denial
 One spec for the success, one per rule (varying only the value the rule checks), one denial.

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

@@ -75,7 +75,7 @@ survive; ask what a caller who may not look sees.
 - Do not perfect a scenario in the room. Capture it with its open question and move on.
 - Every "what if...?" from anyone becomes a named candidate at once.
 - Record why a rule behaves as it does when the room explains it; the modeler puts it in the
-  slice `description`.
+  slice `documentation`.
 
 ## Multi-role check (before leaving the room)
 - Domain expert: is this the right business behaviour and message?

package/package/corpus/skills/cratis-screenplay-scenario-coverage/verification.json

@@ -6,7 +6,7 @@
     { "kind": "skill-contains", "value": "Coverage matrix before any spec" },
     { "kind": "skill-contains", "value": "Once, idempotent, exactly once are different claims" },
     { "kind": "skill-contains", "value": "Unauthorized is never `then error`" },
-    { "kind": "skill-contains", "value": "Screenplay#390" },
+    { "kind": "skill-contains", "value": "find-specification-obligations" },
     { "kind": "skill-contains", "value": "v4.68.0" },
     { "kind": "skill-contains", "value": "false PLAY0285" },
     { "kind": "skill-contains", "value": "One behaviour per spec" },

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

@@ -31,7 +31,7 @@ Lifecycle, modes and hand-offs: `cratis-screenplay-modeling-lifecycle`.
 Skip if the request already names the command origins (screens, reactions, outside systems),
 the decision behind each shown field, and how fresh each view must be. Otherwise ask, in one
 batch, only what is missing. Unattended: assume visibly, record each assumption in the phase
-report and the slice `description`, and continue.
+report and slice `documentation`, and continue.
 
 1. **Origin of each action.** Is it (A) user-initiated only, (B) automated, (C) a mix, or
    started by a clock or outside system (schedule, webhook, feed)? Impact: separates screen
@@ -80,8 +80,8 @@ report and the slice `description`, and continue.
    standing in for a rule. Place each rule in its layer (`references/rule-layers.md`). A rule
    over stored state is written as `reads <View>` + `require ... message "..."` and marked
    **NOT enforced in the model today** in the slice `description`, with its target named (Arc
-   `[ProtectedDecision]` + `DecisionRead<T>` on Arc 22.39.0+, not available in Stage-rendered
-   apps; Chronicle DCB; or a constraint). Never copy state
+   `[ProtectedDecision]` + `DecisionRead<T>` on Arc 22.39.0+ (available to gap-fill
+   code with Stage 4.51.3's Arc 22.50.5/Chronicle 19.32.0); Chronicle DCB; or a constraint). Never copy state
    into the command as input or hide a rule in `handler` / hint prose; descriptions are not
    rendered (Stage#178). Fill the **refusal inventory**: success, each distinct refusal with
    layer and message, and the denied persona.
@@ -129,7 +129,7 @@ report and the slice `description`, and continue.
    actor sees each state change's result. Beyond Level 1: `cratis-screenplay-ui-composition`.
 8. **Lineage pass.** Build the matrix in `references/field-lineage.md` from the `.play` files
    (read them), not from memory or an earlier summary. For each read model, write one line per
-   contributing event in its StateView slice `description`: which fields it sets and why. An
+   contributing event in its StateView slice `documentation`: which fields it sets and why. An
    event with no reason does not belong in the view. A field without an origin is a gap: add
    the missing input or event field, or record an open question. Never invent a source.
 9. **Slice and continue** (`references/slicing.md`): state-transition table per entity; one
@@ -163,9 +163,14 @@ report and the slice `description`, and continue.
 
 - One command per `StateChange` slice (renderable: required, plus no `produces when`).
 - One business decision usually produces one event; a decision establishing several facts the
-  business recognises separately may produce several (say why in the `description`).
+  business recognises separately may produce several (say why in `documentation`).
 - Copy an identity into an event payload only when a consumer needs it as a value.
-- Keep durable design rationale in slice `description` text, not `//` comments.
+- Keep the one-line summary in `description`, including short status markers such as
+  **NOT enforced in the model today** (with its target) or **ASSUMED**; record durable
+  reasoning, assumptions, causes and rejected alternatives in fenced Markdown
+  `documentation` on the module, feature, slice, command, event, read model or reaction, not `//` comments or disconnected notes. These are report-only, not
+  enforcement. Read [model reasoning](references/model-reasoning.md) for owners,
+  syntax, folder merge and PLAY0558/0559.
 - Rule coverage: for each value carrying a rule, list every path that sets it
   (`references/slicing.md`). A constraint on a claim covers every event setting that claim;
   value invariants live in the concept so they travel; command-level conditions are reviewed
@@ -199,7 +204,7 @@ Slice design is done when these hold; otherwise report what is open.
       denied persona); every gated command and query has a `then denied` row.
 - [ ] Every event is past tense, a specific change, and consumed or justified.
 - [ ] Every read model has a consumer and, when the scope is executable, one unambiguous key (keyed queries all using the same `by` property).
-- [ ] Every StateView `description` gives a reason per contributing event; every read-model
+- [ ] Every StateView's `documentation` gives a reason per contributing event; every read-model
       field and screen field is traced; every `from` event sets a field.
 - [ ] No `screen` without `data` or `action`; every acting screen has `data` or a stated
       exemption.

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

@@ -16,7 +16,7 @@ and each persona that must be denied becomes a `given caller` fixture. Build it
 ## Command card
 
 Fill one card per command before (or while) writing the slice. Keep it in the phase report;
-durable rationale goes in the slice `description`.
+durable rationale goes in fenced Markdown slice `documentation`.
 
 ```text
 Command:        <ImperativeBusinessName>  (one decision)
@@ -76,7 +76,8 @@ Rules for filling it:
   as a gap. Persona description text is intent only.
 - A refusal that depends on stored state is a row marked **NOT enforced in the model today**
   with its target (Arc `[ProtectedDecision]` + `DecisionRead<T>` where Arc 22.39.0 or later is
-  available, which Stage-rendered apps are not; Chronicle DCB, or a
+  available, including Stage 4.51.3's rendered package set for gap-fill, not emitted
+  protection; Chronicle DCB, or a
   constraint). It still gets a spec row, because the intended behaviour is the contract.
 - A decided refusal never goes to open questions: it goes here, then to scenarios.
 - A refusal message is a fact of the design; keep the wording identical in the rule, the
@@ -101,7 +102,7 @@ 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+; unavailable in Stage-rendered apps, so a capability gap there) or DCB on the locker stream | RejectingASecondAssignmentOfALocker (pins the message; blocked until the target exists) |
+| 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.51.3 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) |
 | LockerById, ListLockers | caller is anonymous | module `authorize IsAuthenticated` | denied: no caller | RefusingAnAnonymousLockerLookup, RefusingAnAnonymousLockerList |
 | RequestById | caller is anonymous | module `authorize IsAuthenticated` | denied: no caller | RefusingAnAnonymousRequestLookup |

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

@@ -33,7 +33,7 @@ Those are the portable sources. The event-source id is the `for` value, not a pr
 an event field (same-named fields map automatically - AutoMap is on; its matching differs between flat and scoped projections, see `read-model-design.md` "Building it");
 `$eventSourceId` (the instance identity); a literal (status words); a counter or arithmetic;
 a join on another event stream; children for collections. A reducer is opaque: write its
-lineage in the slice `description`. A read model built by a query `performer` (no events)
+lineage in slice `documentation`. A read model built by a query `performer` (no events)
 has lineage outside the model; say where.
 
 **Screen field** - from the query result named in `data ... via query`. A screen showing a
@@ -74,7 +74,7 @@ Filled for `worked-example.md`:
 
 ## The reason line per contributing event
 
-The matrix is the audit; the durable record is the StateView slice `description`: one line per
+The matrix is the audit; the durable record is StateView slice `documentation`: one line per
 contributing event saying which fields it sets and why. Write it as a tagged text block in a
 real model (a bare fence warns with `PLAY0397`). `worked-example.md` uses one-string
 descriptions only so that it stays a single compiling fence.

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

@@ -0,0 +1,87 @@
+<!-- Copyright (c) Cratis. All rights reserved. -->
+<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
+
+# Keep reasoning on the model
+
+Use `description` for a short summary and `documentation` for assumptions,
+boundaries, trade-offs and rejected alternatives. Put reasoning on the declaration
+it explains, not in comments or disconnected session notes. Modules, features,
+slices, commands, events, read models and reactions accept one nonempty block,
+directly in their body (not beneath a reaction trigger). Queries, personas and other
+declarations do not accept `documentation`: keep their intent in `description` (a
+query's ordering, "oldest first", for example). A short status marker such as **NOT
+enforced in the model today** or **ASSUMED** stays in `description`, where a reader
+sees it first; the reasoning behind it goes in `documentation`:
+
+````screenplay
+module Billing
+  documentation
+    ```markdown
+    ## Boundary
+    Billing records agreed amounts; payment delivery belongs elsewhere.
+    ```
+  feature Amounts
+    documentation
+      ```markdown
+      Keep the agreed amount, not a running total.
+      ```
+    slice StateChange RecordAmount
+      documentation
+        ```markdown
+        A recorded amount is a decision, not a recalculated view.
+        ```
+      command RecordAmount
+        documentation
+          ```markdown
+          The caller supplies the agreed amount.
+          ```
+        recordId String identifier
+        amount Int
+        produces AmountRecorded
+          for recordId
+          amount = amount
+      event AmountRecorded
+        amount Int
+      specification RecordingAnAmount
+        description "Witnesses that the agreed amount is retained"
+        when RecordAmount amount = 10
+          recordId = "amount-1"
+        then AmountRecorded amount = 10
+    slice StateView AmountHistory
+      readmodel AmountView
+        documentation
+          ```markdown
+          This view is display state, not an atomic decision input.
+          ```
+        id String
+        amount Int
+      projection AmountHistory => AmountView
+        from AmountRecorded
+          id = $eventSourceId
+          amount = amount
+      query AmountById => AmountView optional
+        by id String
+    slice Automation ObserveAmount
+      reaction ObserveAmount
+        documentation
+          ```markdown
+          Observation does not certify an exactly-once external effect.
+          ```
+        when AmountRecorded
+````
+
+A specification accepts a `description` naming the behavior it witnesses, not
+`documentation`; longer reasoning belongs to its slice. Projections and screens
+do not accept documentation. `documentation String` remains a typed property
+where properties are allowed; bare `documentation` starts metadata.
+
+Both metadata fields are report-only (PLAY0270): no executable bytes,
+`modelRevision` or ESM version change, no rule enforcement or rendered code.
+Canonical printing retains documentation on its owner; source identity changes. MCP `declaration-details` summary exposes
+`description` and `documentation` wherever supported. Folder merge keeps the
+first module/feature block: identical copies are accepted, conflicting copies
+warn PLAY0559. Malformed, empty or repeated blocks report PLAY0558; events retain
+PLAY0477. These diagnostics have no automatic repair; choose the owning text.
+
+Authority: Screenplay v4.127.0 `slices.md` and `specifications.md`. The complete
+model above validates and its specification passes on standalone 4.127.0.

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

@@ -28,7 +28,7 @@ is adapted with the agreement of Martin Dilger and Nebulit GmbH.
 | `eventmodeling-identifying-outputs/SKILL.md`: events vs read models test, recalculated-state anti-pattern, processor outputs categorized (new event, view update, notification) | `references/read-model-design.md` "Events or views" | shared with TrogonStack's version, including the processor-output categories (row above); adapted closely; the "independent means event" and "no computed fields" rows dropped because decided calculations are facts in Screenplay |
 | `eventmodeling-identifying-outputs/SKILL.md` Step 5a/5c: enumerate consumers, one component one read model, homogeneous list is one component, wide-fan-in versus cheap fields | `references/read-model-design.md` "Components" | adapted closely; "always split" softened to "split when you can name the consequence" (existing decision); screen copies become one `data` line per component |
 | `eventmodeling-identifying-outputs/SKILL.md` Step 5d: build read models from the screen's field mappings, not from its title or a summary | `references/read-model-design.md` "Components"; `references/field-lineage.md` | adapted closely |
-| `eventmodeling-identifying-outputs/SKILL.md` Step 5h.4, 5i: event-to-field reasoning note, per-node verification result list | `SKILL.md` step 8; `references/read-model-design.md` "Checks before handing off"; `references/field-lineage.md` | adapted closely; the note lives in the StateView slice `description` |
+| `eventmodeling-identifying-outputs/SKILL.md` Step 5h.4, 5i: event-to-field reasoning note, per-node verification result list | `SKILL.md` step 8; `references/read-model-design.md` "Checks before handing off"; `references/field-lineage.md` | adapted closely; the reasoning note lives in StateView slice `documentation` |
 | `eventmodeling-identifying-outputs/SKILL.md` lines 378-379: before completion re-read every read model and recheck each field and every reason note (roll-ups, additions) | `references/read-model-design.md` "Checks before handing off" | adapted closely; Cratis named-consequence threshold kept instead of "always split" |
 | `eventmodeling-identifying-outputs/SKILL.md` Interview: calculated fields confirmation wording | `SKILL.md` *Interview phase* question 3 | adapted closely |
 | `eventmodeling-identifying-inputs/SKILL.md`: automation level and outside-trigger questions, user versus processor commands marked, conditional input pattern, processor failure/retry stated | `SKILL.md` *Interview phase* question 1; `references/command-inventory.md` | adapted closely; `[USER]`/`[AUTO]` kept as plain classification |

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

@@ -127,7 +127,7 @@ it stays.
   (worklists, status awaiting an outside answer); one-shot otherwise. Design mode only
   (PLAY0268). If access can be revoked mid-session, record that the target re-checks per emission.
 - Never model paging or page size (no syntax, Screenplay#140). State the order in the query
-  `description` ("oldest first"); an unbounded list is a review question.
+  `description` ("oldest first"; queries do not accept `documentation`); an unbounded list is a review question.
 - A gated keyed query needs its own denial spec.
 
 Never drop a list query from a design model just to make it bind; record the capability gap.
@@ -260,7 +260,7 @@ module Berths
 
 ## Checks before handing off
 
-- The StateView slice `description` gives, per contributing event, the fields it sets and why
+- StateView slice `documentation` gives, per contributing event, the fields it sets and why
   (see `LockerBoard` in `worked-example.md`); extend it whenever a `from` is added. Shape of
   the note: `BerthBooked sets bookingId, status="booked": the view's creation event; the booking
   does not exist before it.` / `BoatArrived sets status="arrived", arrivedAt: the only

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

@@ -14,18 +14,18 @@ rendered code (Stage#178): a rule that exists only in prose is unenforced in ren
 | 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; Screenplay#129/#209). Name the target: Arc `[ProtectedDecision]` + `DecisionRead<T>` (Arc 22.39.0 or later), Chronicle DCB (`concurrency` scope), or a constraint |
 
 An unguarded materialized read is unsafe for a protected decision; a guarded read is the
-supported route. Availability: `[ProtectedDecision]` and `DecisionRead<T>` need Arc 22.39.0 or
-later and are **not available in Stage-rendered apps**, whose scaffold pins Arc 22.25.0 (Stage
-4.24.0); never edit the managed dependency files to get them. For rendered scope, record a
-capability gap (or a separately verified compatible enforcement path, such as a constraint or
-a Chronicle DCB scope) and keep the rule as NOT enforced. Forbidden: caller-supplied copies of state in `require`, boolean attestation
+supported route. Availability: `[ProtectedDecision]` and `DecisionRead<T>` exist in
+Stage 4.51.3's Arc 22.50.5/Chronicle 19.32.0 package set, 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
 inputs (`confirmsX == true`), rules in `handler` / implementation-hint prose.
 
 ## Authorization is executable
 
 Persona Does/Reads/Cannot text is intent. Every Cannot line resolves to an `authorize` gate
-(policy or ownership claim) plus a `then denied` spec whose `given caller` carries the roles
-and claims standing for that persona; otherwise record a gap. Every command and query under an
+(policy or ownership claim) plus a `then denied` spec using `given caller as <Persona>` or an explicit
+caller for the effective gate; otherwise record a gap. Every command and query under an
 inherited module/feature `authorize` gets its own `then denied` spec. Ownership gates need a
 second caller with another claim value.
 
@@ -33,7 +33,7 @@ second caller with another claim value.
 
 Command property values are, by default, recorded in the causation chain of the events they
 produce, so treat them as permanent. Newer Chronicle versions can omit causation properties
-(`CausationPropertyRetention.Omit`, Chronicle v19.32.0); rendered apps pin Chronicle 19.8.1.
+(`CausationPropertyRetention.Omit`, Chronicle v19.32.0); Stage 4.51.3 rendered apps pin 19.32.0.
 Verify the actual auditing and retention configuration before relying on omission, and never
 audit secrets. Classify personal values as bare `pii` and operational secrets as
 `secret` on their concepts, never the identifier concept. Use a surrogate identity

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

@@ -23,7 +23,7 @@ step at the end: design each behaviour as its slice, then audit the set.
 | `Translate` | captures, translated events | the integration (`CarrierManifests`) | see `cratis-screenplay-automations-and-translations` |
 
 Screenplay allows several commands or read models in one slice; prefer splitting unless the
-behaviour is genuinely one (and say why in the `description`).
+behaviour is genuinely one (and say why in `documentation`).
 
 ## Slice dependencies
 
@@ -142,8 +142,8 @@ result in every row and no refusal anywhere, whose event restates most of the en
    relocated).
 4. Apply rule coverage (below) to each new path.
 5. If the business treats a multi-value data-entry correction as one act, keep one correction
-   command named for the correction (never `Update`), with the reason in the slice
-   `description`; rule coverage still applies.
+   command named for the correction (never `Update`), with the reason in slice
+   `documentation`; rule coverage still applies.
 
 A repeated-field event is a review signal; it is major only when business meaning is lost, a
 rule is bypassed or consumers become ambiguous. Historical generations repeat prior shape on

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

@@ -13,9 +13,15 @@ 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`.
 Per-command refusal inventory: `command-inventory.md`.
 
-The per-event reason lines in each StateView `description` are the lineage record
-(`field-lineage.md`). Multi-line descriptions use a tagged ` ```text ` fence in a real model;
-they are written as one string here so this document stays a single compiling fence.
+This historical compiled example keeps per-event reasoning in StateView
+`description` strings. For current 4.127.0 authoring, keep descriptions as summaries
+and record lineage reasoning in fenced Markdown `documentation` (`field-lineage.md`).
+The historical source below stays unchanged; it is not the current placement recipe.
+
+The excerpt's Stage availability note is historical (Stage 4.24.x, Arc 22.25.0).
+Stage 4.51.3 pins Arc 22.50.5/Chronicle 19.32.0, so protected-read APIs are available
+to gap-fill; this neither admits these `.play` rules nor proves target protection.
+The original compiled excerpt is retained unchanged.
 
 ```screenplay
 domain Parcelpoint.Lockers

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

@@ -37,7 +37,7 @@ The update follows `commands.md`, `events.md`, `types.md` and
 `specifications.md` at that main commit (after v4.52.0). This pass compiles the
 changed examples; it does not rerun the reference runner.
 
-Current specification syntax follows Screenplay v4.125.0 `specifications.md`;
+Current specification syntax follows Screenplay v4.127.0 `specifications.md`;
 older probes in the table remain historical. Pins: `cratis-screenplay-toolchain`
 `references/versions.md`. Compile commands check source, not reference execution.
 Use `screenplay test` or MCP `run-specifications` for V4; Stage/target tests are
@@ -95,13 +95,27 @@ Unsupported is not passed. Report it as "needs a target", not as green. "Specifi
 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.
 
+## Descriptions, persona callers and case tables
+
+Use one `description "<rule or behavior>"` (or a fenced `text` description) to
+name what the specification witnesses. It is report-only (PLAY0270), changing
+neither execution nor ESM bytes. Specifications do not accept `documentation`;
+put longer assumptions and rejected alternatives on the owning slice's fenced
+Markdown `documentation` block.
+
+`given caller as <Persona>` expands to one authenticated policy witness before
+binding. Named `parameter`/`case` tables share steps and read values as
+`case.<parameter>`; each case runs independently as `<Specification>_<Case>`.
+Read [persona callers and case tables](references/persona-callers-and-cases.md)
+for synthesis refusals, selection, provenance and a complete passing model.
+
 ## The vocabulary
 
 | Construct | Meaning |
 | --- | --- |
 | `given <EventType>` | prior state, established by replaying events before the action |
 | `given readmodel <ReadModelType>` | prior read-model state, established directly — a **complete** instance including its identifier |
-| `given caller` | the caller: `authenticated`, `role "<r>"`, repeatable `claim "<type>" = "<value>"`; empty means unauthenticated |
+| `given caller` / `given caller as <Persona>` | explicit caller (`authenticated`, roles, claims; empty means anonymous), or an authenticated synthesized persona witness |
 | `when <CommandType>` | run a command |
 | `when append <EventType>` | append one event: constraints and projections run, the command does not; reactions run only from ESM v6, where `then` lists what followed |
 | `when query <Query>` | perform a query with the argument values beneath it (v4.48.0) |
@@ -146,7 +160,7 @@ Rules the binder enforces:
 - **`then denied` stands alone**: not with events, errors or state assertions
   (`PLAY0388`). For a query, pair it with one `then query` that has `arguments`
   and no `result`.
-- **Authorized commands and queries need `given caller`** (`PLAY0389`). The runner
+- **Authorized commands and queries need `given caller` or `given caller as <Persona>`** (`PLAY0389`). The runner
   never invents a caller.
 - **`null` only in optional read-model values.** A `null` in a command or event
   value is `PLAY0350`: an optional fact is a separate event.
@@ -168,7 +182,7 @@ the one-rejection rule (`PLAY0273`) are reported only when the model binds, so
 - **Rejections:** `then error "<message>"` matches the message whatever the rule's
   validation severity; no form asserts severity. Bare `then error` never matches
   a denial. Quote a localized key: `then error "$strings.invoices.reasonRequired"`.
-  The grammar takes only quoted messages here, never an unquoted `$strings` token
+  Besides a String `case.<parameter>`, the grammar takes only quoted messages here, never an unquoted `$strings` token
   (unlike a rule's `message` operand). The reference runner compares the symbolic key
   and requires the rejection to carry the string-key marker; it never loads
   translated text; resolving the key is the realization's job.
@@ -197,7 +211,10 @@ Read [references/reactions-and-cascades.md](references/reactions-and-cascades.md
 
 Use typed `example` declarations for repeated event/command/read-model values;
 step overrides keep the action/outcome visible and carry authored/example/override
-provenance. Event `stream`/`no stream` assertions bind as ESM v8; typed `for` and
+provenance. Event examples can carry routes, replaced as a whole by a step.
+Redelivery locators may state `stream` or `no stream` to select one definitely
+matching given occurrence with no undecided candidates (PLAY0543); redelivery
+remains authoring-only. Event `stream`/`no stream` assertions bind as ESM v8; typed `for` and
 stream ids are not guessed. Read [examples and routes](references/examples-and-routes.md).
 
 `given operation ... fails`, `then operation` and `then compensated` describe