@cratis/pi 6.2.0 → 6.3.0

package/package/corpus/skills/cratis-screenplay-command-surface/verification.json

@@ -1,6 +1,6 @@
 {
   "skill": "cratis-screenplay-command-surface",
-  "input": "Declare a Screenplay command with validation, authorization and concurrency.",
+  "input": "Declare a Screenplay command with validation, authorization, a uniqueness constraint and a state-dependent rule.",
   "fixtures": [],
   "assertions": [
     {
@@ -26,6 +26,38 @@
     {
       "kind": "skill-contains",
       "value": "`identifier` on an **event** property is an error"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "`reads` is not a protected read"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "Adding a\n`concurrency` block does not fix this"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "Validation severity is not compiler severity"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "Chronicle's constraints enforce **uniqueness only**"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "Do not use `constraint … file <Path>` for other rules"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "combine with AND, in authored"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "(`PLAY0441`)"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "never both (`PLAY0440`)"
     }
   ]
 }

package/package/corpus/skills/cratis-screenplay-event-modeling/SKILL.md

@@ -32,11 +32,14 @@ source is the single flow model.
 
 | Package | Version | Purpose |
 | --- | --- | --- |
-| `Cratis.Screenplay` | `4.12.1` | Compiler: parser, validator, diagnostics, folder merge, semantic binder |
-| `Cratis.Screenplay.Tool` | `4.12.1` | The `screenplay` dotnet tool |
+| `Cratis.Screenplay` | `4.31.0` | Compiler: parser, validator, diagnostics, folder merge, semantic binder |
+| `Cratis.Screenplay.Tool` | `4.31.0` | The `screenplay` dotnet tool |
 
-Read from the Screenplay repository at tag `v4.12.1` (commit `122eee8`). Reverify
-before claiming another version behaves the same.
+Checked against the Screenplay repository at tag `v4.31.0` (commit `355dffb`):
+`Documentation/screenplay/{slices,commands,folders,printing,interactions,specifications}.md`,
+`projections/keys.md`, and decisions 0001 to 0014. The examples in
+[nine-steps.md](references/nine-steps.md) compile with that version's compiler.
+Reverify before claiming another version behaves the same.
 
 > **Method lineage.** The two-phase process, the nine steps, the four patterns and
 > the GWT discipline follow **Event Modeling** (Adam Dymitruk; Martin Dilger,
@@ -83,9 +86,9 @@ Every behavior is exactly one. An unknown slice type is a compile error:
 appear as many times as the behavior needs. Only `description` is limited to one.
 
 **Automation has four required components** — a triggering occurrence, the state
-it consults, conditional logic, and a resulting command or event. If the events
-are always unconditionally co-produced, it is **not** an automation: model it as
-one `StateChange` slice with several `produces` blocks.
+it consults (the trigger's `reads`), conditional logic, and a resulting command
+or event. If the events are always unconditionally co-produced, it is **not** an
+automation: model it as one `StateChange` slice with several `produces` blocks.
 
 **Translation is workflow-specific anti-corruption.** Generic infrastructure every
 workflow needs (event persistence, message transport) is not a `Translate` slice.
@@ -96,11 +99,16 @@ Two divergences matter, and getting them wrong produces a model that will not
 compile or will not be safe. Both are deliberate.
 
 - **A command may read state.** The generic method forbids `ReadModel → Command`
-  edges. Screenplay ships `reads <ReadModel> [by <property>]` on a command
-  precisely so a state-dependent rule can be decided under concurrency. Use it for
-  genuine consistency boundaries, and pair it with `concurrency` so the decision is
-  enforced at append time rather than merely consulted. Do not use it to fetch
-  data the command could carry as input.
+  edges. Screenplay ships `reads <ReadModel> [as <alias>] [by <property>]` so the
+  model shows what a state-dependent decision consulted. **It is not a protected
+  read today:** nothing checks at append time that the state is still current,
+  the executable model rejects `reads` and `concurrency` (`PLAY0271`), and adding
+  `concurrency` does not make the decision safe (decision 0003, Screenplay #129).
+  Model uniqueness as a `unique` constraint; for any other state-dependent rule,
+  record that the target must enforce it consistently. Do not use `reads` to
+  fetch data the command could carry as input. A reaction trigger declares the
+  views an automation decides from with the same `reads`, and the same caveat
+  applies.
 - **Some validation *does* belong in the model.** The generic method routes format
   rules to the type system. Screenplay's type system *is* the `concept`, and a
   concept carries its own `validate` block — so a format rule lives on the concept
@@ -122,7 +130,7 @@ compile or will not be safe. Both are deliberate.
   `Created`. One purpose per event; an event needing an optional property to cover
   two situations is two events.
 - **The event-source identity is never an event property.** The command binds it
-  with `identifier` on exactly one property; marking an *event* property
+  with `identifier` on at most one property; marking an *event* property
   `identifier` is an error: *an event never carries its event source id*.
 - **Domain facts, not runtime context.** Test: would this field have the same value
   if the event were replayed on a different machine? If not, it does not belong.
@@ -170,8 +178,13 @@ produced in another resolves. Compiling files individually reports unknown types
 events and policies (`PLAY0165`, `PLAY0166`, `PLAY0167`) that are not missing.
 Duplicates *across* files are real errors naming both ends (`PLAY0172`, `PLAY0173`).
 
-Round-tripping a folder does not preserve **declaration order** — modules, features
-and slices come back sorted by name. Never encode meaning in order.
+Round-tripping a folder does not preserve the order of **modules, features and
+slices**: they come back sorted by name, and members of one module or feature
+that come from different files print in canonical kind order. Order *within* one
+file is kept, and some order carries meaning: `authorize` gates and policy
+operands evaluate left to right, and specification events compare in authored
+order unless `then events in any order` is stated. Never encode meaning in the
+order of modules, features or slices.
 
 ## Verify
 
@@ -188,26 +201,45 @@ screenplay .cratis/screenplay/ --warnaserror
 - [ ] Personal data is classified on the `concept`, with a reason.
 - [ ] Specifications name the rejections, not only the happy path.
 - [ ] If the model must reach a runtime, every slice is `StateChange` or
-      `StateView` and stays inside the admitted vertical (below).
+      `StateView` and binds to the executable model (below).
 
 ## Parsed is not runnable
 
 The compiler accepts far more than anything executes. Between the syntax tree and
-any runtime sits the **executable semantic model (ESM v1)**, and it fails closed.
-`SemanticSliceKind` has exactly three members — `Unknown = -1`, `StateChange`,
-`StateView` — so an `Automation` or `Translate` slice is rejected outright:
-*Slice '<name>' of type '<type>' is not admitted by ESM v1.*
-
-**Exactly 40 constructs** bind to `UnsupportedSemanticSyntax` (`PLAY0268`) rather
-than to a weaker model — imports, policies, personas, triggers, `authorize`, event
-and produced-event tags, conditional `produces … when`, code-backed validation,
-query filters/scope/performers, `@pii` concepts, projection parent keys, reducers,
-reactions, captures and constraints among them.
-
-Model the wider language freely when the `.play` file **is** the deliverable —
-documentation, review, a shared description of a system. Stay inside the admitted
-vertical when it must reach a runtime. Never read a clean `screenplay` run as
-evidence a construct works downstream.
+any runtime sits the **executable semantic model (ESM)**, and it fails closed:
+what it cannot represent reports `PLAY0268` or `PLAY0271` and the model does not
+bind. Keep four states apart when you report on a model: **parsed** (the
+`screenplay` tool), **bound** (ESM), **reference-executed** (specifications pass
+the reference runner) and **target-executed** (Stage or a rendered application).
+
+The ESM version follows from what the model uses: v1 by default, v2 for typed
+event-source facts (`produces … for <identifier>` when the event does not repeat
+the identifier, `for` values in specifications, and `$context.occurred` or caller
+identity in `produces`), v3 for code the model hands off (bodied reducers, code
+validation, code policies). Code binds as an opaque requirement; the reference
+runner reports any specification that needs it as unsupported.
+
+For event modeling, the consequential boundaries today are:
+
+- `Automation` and `Translate` slices, reactions, captures and triggers do not
+  bind: *Slice '<name>' of type '<type>' is not admitted by ESM v1.*
+- `reads` and `concurrency` do not bind (`PLAY0271`), so no decision is protected
+  against stale state.
+- `persona` and `@pii`/`@sensitive` concepts do not bind yet. Keep them: the
+  classification is part of the model.
+- UI constructs are deferred with information `PLAY0269`; they never block.
+
+The full disposition table is in the `cratis-screenplay-model-authoring` language
+reference. Model the wider language freely when the `.play` file **is** the
+deliverable — documentation, review, a shared description of a system. Never
+read a clean `screenplay` run as evidence a construct works downstream.
+
+Decision 0006 shipped in Screenplay 4.31.0: a reaction trigger can declare the
+views it decides from with `reads` (see `cratis-screenplay-captures-and-reactions`),
+but nothing enforces them yet. Decisions 0007 to 0014 (affected read-model
+instances, one data subject per event, external event origin, query paging and
+live change sets, event generations, typed context descriptors) are accepted but
+**not available**. Do not write their syntax; note the need in prose instead.
 
 ## Route near misses
 

package/package/corpus/skills/cratis-screenplay-event-modeling/references/nine-steps.md

@@ -18,7 +18,8 @@ module Invoicing
 ```
 
 `description` is the optional **first body line** of a module, feature, slice,
-persona or command; at most one. Use a fenced ``` block when one line is not enough.
+persona or command; at most one. Use a fenced block tagged ` ```text ` when one line
+is not enough (a bare fence warns with `PLAY0397`).
 
 ## Step 2 — Brainstorm events
 
@@ -39,8 +40,8 @@ does not belong in an event.
 Arrange into the timeline — the plot. *"What happens first? And then what
 happens?"* Identify the happy path **and** the alternative and error paths.
 
-**Output:** the order the slices will be written in. Note that folder round-trip
-does not preserve declaration order, so the timeline is documentation, not
+**Output:** the order the slices will be written in. A folder round-trip sorts
+modules, features and slices by name, so the timeline is documentation, not
 structure.
 
 ## Step 4 — Create wireframes
@@ -48,7 +49,7 @@ structure.
 These need not be the real UI. Their purpose is a complete accounting of what a
 user can **see** and what they can **do** at each interaction point.
 
-```
+```text
 +-------------------------------+
 |  Register Invoice             |
 +-------------------------------+
@@ -67,7 +68,11 @@ input** (something provided). If you cannot trace a field, something is missing.
 same time?"* If yes, the wireframe shows a list or table, not a single-item view.
 
 **Output:** the `screen` declarations, at Level 1 (intent) for now —
-`data <ReadModel> via query <Query>` plus `action <Command>`.
+`data <ReadModel> via query <Query>` plus `action <Command>`. When the wireframe
+says what a click, submit or screen entry *does* (confirm, refresh, navigate,
+open a dialog), capture it as an `on` block or a named `behavior` attached with
+`uses` — see `cratis-screenplay-ui-composition`. An `action` alone does not say
+what happens afterwards.
 
 ## Step 5 — Identify commands
 
@@ -77,8 +82,10 @@ did they provide? Under what circumstances would this NOT happen?"*
 Commands are imperative and present tense: `RegisterInvoice`, `ProcessPayment`.
 **Commands can fail; events cannot.**
 
-**Output:** the `command` declaration with its properties, exactly one
-`identifier` property, `authorize`, and `produces`.
+**Output:** the `command` declaration with its properties, its `identifier`
+property (at most one; leave it out only when the runtime should allocate a new
+identity), `authorize`, and `produces`. Excerpt: the concepts, the policy and the
+event are declared elsewhere in the model.
 
 ```screenplay
 slice StateChange RegisterInvoice
@@ -107,7 +114,7 @@ need to determine its next action?"*
 
 Verify **every** field traces back to an event:
 
-```
+```text
 InvoiceListReadModel:
   invoiceId      <- InvoiceRegistered.invoiceId
   invoiceNumber  <- InvoiceRegistered.invoiceNumber
@@ -121,15 +128,21 @@ a collection type, not a singular value.
 builds it. **Exactly one thing may build a read model** — two builders is a
 compile error (`PLAY0191`).
 
+Key **every** `from` on the value that identifies the instance. A `from` without a
+key routes by the event's event source id, not by the key of another `from`, and
+a `key` written directly on the projection routes nothing (`PLAY0381`). Excerpt:
+the concepts and events are declared elsewhere, and both events carry `invoiceId`.
+
 ```screenplay
 slice StateView InvoiceList
   readmodel InvoiceListReadModel
+    invoiceId     InvoiceId
     invoiceNumber InvoiceNumber
     status        InvoiceStatus
   projection InvoiceList => InvoiceListReadModel
     from InvoiceRegistered key invoiceId
       status = "draft"
-    from InvoiceSent
+    from InvoiceSent key invoiceId
       status = "sent"
   query ListInvoices => InvoiceListReadModel[]
 ```
@@ -148,7 +161,11 @@ event. **Test:** *"Can this automatic response ever be skipped or vary based on
 system state?"* If no, it is co-production — one `StateChange` slice with several
 `produces` blocks, not an `Automation` slice.
 
-**Output:** the `reaction`, in an `Automation` slice.
+**Output:** the `reaction`, in an `Automation` slice. It documents the automation;
+it does not bind to the executable model today. When the automation decides from
+a view, declare it under the trigger with `reads` (see
+`cratis-screenplay-captures-and-reactions`). Excerpt: the event and the
+command are declared in their own slices.
 
 ```screenplay
 slice Automation ChaseOverdueInvoices
@@ -179,7 +196,9 @@ need it?"* If every workflow needs it, it is cross-cutting infrastructure, **not
 a `Translate` slice.
 
 **Output:** the `capture` in a `Translate` slice, and any `trigger` declaration
-for a name only an integration knows.
+for a name only an integration knows. A `trigger` is an application signal a
+reaction consumes; it is not how a button click is modeled (that is a UI `on`
+clause).
 
 ```screenplay
 trigger BuildFinished
@@ -201,8 +220,11 @@ Bad slices: *"Set up database"* (technical, no user value), *"Implement invoicin
 **Slice independence.** Slices sharing an event schema are **independent** —
 connected by the event contract, not by execution order. A `StateChange` slice is
 specified by asserting on produced events; a `StateView` slice is specified with
-synthetic `given` events. Neither needs the other implemented first. Do not build
-artificial dependency chains.
+synthetic `given` events, or with `when append <Event>` to run one event through
+constraints and projections. Neither needs the other implemented first. Do not
+build artificial dependency chains. An authorized command's specifications state
+the caller explicitly with `given caller` and assert refusals with `then denied`
+(see `cratis-screenplay-specifications`).
 
 **Output:** the complete `feature` → `slice` tree, ready for the specifications.
 

package/package/corpus/skills/cratis-screenplay-event-modeling/verification.json

@@ -30,6 +30,18 @@
     {
       "kind": "skill-contains",
       "value": "is not admitted by ESM v1"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "It is not a protected"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "**reference-executed**"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "are accepted but\n**not available**"
     }
   ]
 }

package/package/corpus/skills/cratis-screenplay-model-authoring/SKILL.md

@@ -12,8 +12,21 @@ the compiler already knows declarations, references, hierarchy and source owners
 
 Screenplay remains experimental. **Valid source is not necessarily executable.**
 It does not generate or run an application; Stage owns rendering/runtime admission.
-See the [language reference](references/language-reference.md) for constructs and
-the complete canonical model.
+See the [language reference](references/language-reference.md) for constructs,
+the executable profile and the complete canonical model.
+
+## Verified product sources
+
+| Package | Version | Purpose |
+| --- | --- | --- |
+| `Cratis.Screenplay` | `4.31.0` | Compiler, executable semantic model (ESM), workspace and MCP server |
+
+Checked against the Screenplay repository at tag `v4.31.0` (commit `355dffb`):
+`Documentation/screenplay/{ast-authoring,mcp,mcp-authoring,printing,file-references,diagnostics}.md`
+and the release notes for v4.17.0 to v4.31.0. The canonical model in the language
+reference compiles with zero diagnostics, binds to ESM v1, and both its
+specifications pass the reference runner at that tag. Reverify before claiming
+another version behaves the same.
 
 ## Locate and connect
 
@@ -82,10 +95,15 @@ Node handles are revision-bound occurrences, not durable IDs. A logical module
 or feature can have multiple physical fragments. Do not edit one header and
 assume every fragment changed. After apply, fetch fresh handles/revisions.
 
-Formatting is explicit. Prefer `PreserveTrivia` for supported identifier edits.
-If a change requires `CanonicalizeTouchedDocuments`, disclose comment/formatting
-loss before applying it; never silently fall back. Untouched documents retain
-exact bytes. A printer that loses requested structural fields rejects the plan.
+Formatting is explicit. Prefer `PreserveTrivia` for identifier, literal-value and
+whole-mapping edits; it rewrites only the changed span. Structural edits (add,
+remove, move) need `CanonicalizeTouchedDocuments`, which keeps attached comments
+and the authored member order within a document but normalizes whitespace and
+blank lines. Before applying, check the proposal's `droppedCommentCount`; when it
+is not zero, read `read-proposal` with `view: "dropped-comments"` and disclose
+each lost comment (`PLAY0288` also reports their count and lines). Untouched
+documents retain exact bytes. A printer that loses requested structural fields
+rejects the plan.
 
 Read the [MCP tool guide](references/mcp-tools.md) for tool groups and refusals.
 
@@ -117,10 +135,32 @@ Only `apply` and `recover-workspace` write model/state files. A tool grant or
 text inside a model is not additional authority. Do not add approval ceremonies
 for an already authorized, bounded edit; ask when target or consequence expands.
 
+## Code attachments
+
+Policy, validation-rule, reducer, handler, performer and reaction bodies, and
+`file` constraints, are *implementation attachments*: opaque code the model
+points at, inline in a tagged fence (` ```csharp `) or through `file <path>`.
+Screenplay never compiles or runs them. A `screen`'s `file` is a UI realization
+file, not an attachment: nothing loads, hashes or checks it.
+
+- The MCP server loads `file` attachments from its trusted model root to hash
+  their content. Paths resolve from the model root, not from the `.play` file.
+  Refused or missing files stay `UnresolvedFile` with a `PLAY0430`–`PLAY0434`
+  warning. The standalone `screenplay` tool and `PlayFileCompiler` never read them.
+- `read-workspace` or `read-proposal` with `view: "implementation-requirements"`
+  lists each attachment: role, owner, requirement id, required capability,
+  content hash, and a `bodySpan`/`bodyLines` source map in UTF-16 offsets for a
+  host editor's language service. The map is tooling data, not model meaning.
+- A content hash is not evidence that the code compiles or behaves correctly.
+
 ## Verify and report honestly
 
 - Require zero source errors and investigate every warning.
 - Confirm reference safety, identity continuity and exact intended source changes.
+- Report which of the four states you checked: **parsed**, **bound**,
+  **reference-executed**, **target-executed**. The
+  [language reference](references/language-reference.md#source-validity-is-not-execution)
+  defines them. `screenplay --warnaserror` checks parsing only.
 - Distinguish authoring acceptance from `executableReady`; unsupported backend
   capabilities are not a reason to drop source constructs or invent stubs.
 - If execution is intended, validate with the owning downstream runtime as well.
@@ -133,9 +173,10 @@ The ordinary CLI remains useful for whole-folder validation:
 cratis screenplay validate .cratis/screenplay --warnings-as-errors
 ```
 
-MCP behavior is grounded in the published Screenplay 4.16.0 server API. The
-Cratis CLI must reference that package or a newer verified compatible version;
-reverify installed tool schemas when contracts change. Do not invent a command,
+MCP guidance here follows the Screenplay 4.31.0 server documentation. The Cratis
+CLI bundles its own Screenplay version, so check the installed `tools/list`
+schemas before relying on a view or argument named here (for example
+`dropped-comments` or `implementation-requirements`). Do not invent a command,
 parameter, syntax node or downstream capability.
 
 ## Route near misses

package/package/corpus/skills/cratis-screenplay-model-authoring/references/language-reference.md

@@ -6,16 +6,20 @@
 The `.play` source is plain UTF-8 text. Nesting is indentation-based, without
 braces or terminators. A construct owns the content indented beneath it. `//`
 starts a comment; escape reserved words inside a block with a leading `@`.
+The grammar in `Documentation/screenplay/grammar.md` of the Screenplay
+repository is the full list; this page is the authoring summary.
 
 ## Accepted constructs
 
 **Top level:** `domain`, `import`, `concept`, `type`, `policy`, `persona`,
-`authentication`, `module`, `seed`, `trigger`, `ui profile`, `theme`, `layout`.
+`authentication`, `trigger`, `theme`, `layout`, `ui profile`, `behavior`,
+`module`, `seed`.
 
-**Inside a module:** `description`, `screen`/`dialog` templates, `form`,
-`contribute`, `feature`.
+**Inside a module:** `description`, `authorize`, `screen`/`dialog` templates,
+`form`, `contribute`, `on`/`uses` behavior attachments, `feature`.
 
-**Inside a feature:** `description`, nested `feature`, `slice`, `contribute`.
+**Inside a feature:** `description`, `authorize`, nested `feature`, `slice`,
+`contribute`, `on`/`uses` behavior attachments.
 
 | Slice type | Meaning | Typical contents |
 | --- | --- | --- |
@@ -24,23 +28,27 @@ starts a comment; escape reserved words inside a block with a leading `@`.
 | `Automation` | React to something happening | Reaction |
 | `Translate` | Translate external data into events | Capture |
 
-Any slice can contain `description`, `event`, `command`, `query`, `projection`,
-`capture`, `reaction`, `screen`, `constraint`, `specification`, `readmodel` and
-`reducer`. An unknown slice construct is only a warning and its block is skipped;
-never accept a warning-free claim without compiling the entire document set.
+Any slice can contain `description`, `file`, `event`, `command`, `query`,
+`projection`, `capture`, `reaction`, `screen`, `constraint`, `specification`,
+`readmodel` and `reducer`. An unknown slice construct is only a warning
+(`PLAY0029`) and its block is skipped; never accept a warning-free claim without
+compiling the entire document set.
 
-Concept primitives are `Uuid`, `String`, `Int`, `Decimal`, `Bool`, `Date`,
-`DateTime` and `Enum`. Enum members are indented below their concept. Concepts
-can carry `@pii`, `@sensitive`, reasons and validation.
+Concept primitives are `Uuid`, `String`, `Int`, `Decimal`, `Bool`, `Date` and
+`DateTime`; `Enum` is a separate concept kind whose members are indented below
+it. Concepts can carry `@pii`, `@sensitive`, reasons and validation.
 
-Projections and captures use their dedicated sub-grammars. Query the MCP's
-`syntax-schema` instead of inventing JSON members or translating names from
-memory.
+Projections and captures use their dedicated sub-grammars. Inline code uses a
+tagged fence (` ```csharp `); the older language-line form still parses with
+warning `PLAY0397`. Query the MCP's `syntax-schema` instead of inventing JSON
+members or translating names from memory.
 
 ## Canonical complete model
 
 The RegisterProject conformance vector is the narrow executable example shared
 by downstream tooling. Its source is shipped in `Cratis.Screenplay.CanonicalCorpus`.
+At v4.31.0 it compiles with zero diagnostics, binds to ESM v1, and both
+specifications pass the reference runner.
 
 ```screenplay
 concept ProjectId : Uuid
@@ -94,15 +102,63 @@ module Projects
 
 ## Source validity is not execution
 
-The parser accepts more than ESM v1 can execute. Automation/translation slices,
-imports, policies, personas, triggers, authorization, opaque handlers and many
-advanced query/projection forms may be valid source but unsupported by the
-backend. Authoring must retain that source rather than downgrade it to a stub.
+A construct can be in one of four states. Say which one you checked.
 
-Check `sourceSuccess`/authoring diagnostics and `executableReady`/backend
-diagnostics separately. The MCP does not run specifications, compile embedded
-code, generate an application or follow external realization files. Stage owns
-rendering and runtime admission.
+| State | What establishes it | What it does not prove |
+| --- | --- | --- |
+| **Parsed** | `screenplay <folder> --warnaserror` or MCP authoring diagnostics: syntax plus model consistency | Binding, execution, or anything about attached code (the tool never reads `file` attachments) |
+| **Bound** | Semantic binding to the executable semantic model (ESM): MCP `executableReady`, executable diagnostics | That the reference execution plan admits the model, or that any specification passes |
+| **Reference-executed** | The reference runner passes the specification | Target behavior; opaque code never runs here |
+| **Target-executed** | Stage or a rendered application runs it with the implementations supplied | Nothing further in Screenplay |
+
+The ESM version is selected by what a model uses, never by the author:
+
+- **v1** is the default.
+- **v2** is selected by typed event-source facts: `produces … for <identifier>`
+  when the event does not repeat the identifier, `for` values in specifications,
+  and `$context.occurred` or caller identity in `produces`.
+- **v3** is selected by implementation attachments: a reducer whose rules all
+  have bodies, a named `rule` with a body, a fenced `validate` block, or a
+  `policy` implemented in code or a file. They bind as opaque requirements with
+  capability `pure`. The reference runner returns `SemanticUnsupported` whenever
+  it would need one, so a specification that depends on one never passes.
+
+Binding is not the last gate before the reference runner. The runner needs an
+execution plan, and the plan is created only when every reachable capability is
+admitted. One refused construct blocks the whole plan, so no specification in
+the model runs, including specifications that never touch it.
+
+What binds today, what the reference execution plan refuses, what is opaque, and
+what blocks binding (Screenplay v4.31.0):
+
+| Disposition | Constructs |
+| --- | --- |
+| Binds and runs in the reference runner | `StateChange`/`StateView` slices; `produces` including `when` conditions over command properties and literal tags; the portable validation rules, `matches email`, quoted `matches` patterns and `require` over command properties; declarative policies and `authorize` on modules, features, commands and keyed queries; `unique` constraints; projections as Chronicle lowers them, including variants, except the projection constructs in the next row; specifications, including `given caller`, `then denied` and `when append` |
+| Binds, but the reference execution plan refuses it | A projection-level `remove via join`; `all` beside removals, `children` or `nested`; a `join`, `children` or `remove via join` inside `nested`; any event-context value other than the event source identity in a projection mapping or key, such as `$eventContext.occurred`, `$eventContext.sequenceNumber` or `$eventContext.causedBy.subject` (`$eventSourceId` and `$eventContext.eventSourceId` run) |
+| Binds as opaque code (v3); reference runner reports unsupported | Bodied reducers, bodied named rules, fenced `validate` blocks, code or file policies |
+| Blocks binding (`PLAY0268`) | `Automation` and `Translate` slices, reactions (with or without trigger `reads`), captures, top-level `trigger`, `persona`, `@pii`/`@sensitive` concepts, command `handler`, bare `rule <Name>`, `require` or conditions over read-model paths, dates and `today` in comparisons, `$context.tenant`/claims/roles/causation in `produces`, `$env` conditions, `file` constraints, a read model whose keyed queries in its own slice do not share one `by` property (none, or two different properties; several queries over the same property bind), any query other than `=> <ReadModel>?` with one caller-supplied `by` argument (so also observable, filtered, scoped and performer-backed queries), `$causedBy` and templates in projections |
+| Blocks binding (`PLAY0271`, legacy meaning) | Command `reads` and `concurrency` |
+| Deferred (`PLAY0269`, information) | Screens, layouts, templates, forms, contributions, UI profiles, themes, behaviors and `on`/`uses` |
+| Metadata only (`PLAY0270`, information) | `domain`, `seed`, descriptions and `file` provenance on declarations |
+
+The table is a snapshot, not a contract: ask the binder (MCP executable
+diagnostics) rather than extrapolating from it. Retain valid source that the
+backend cannot represent rather than downgrading it to a stub. The MCP does not
+run specifications, compile embedded code, generate an application, or follow
+realization files. Stage owns rendering and runtime admission.
+
+## Not in the language yet
+
+Decision 0006 shipped in Screenplay 4.31.0: a reaction trigger may declare
+`reads <View> [as <alias>] [by <trigger value>]` (see
+`cratis-screenplay-captures-and-reactions`). Reactions still block binding, so
+those reads are declared, not enforced.
+
+Screenplay decisions 0007 to 0014 are accepted but not implemented. Do not write
+their syntax: affected-instance declarations, per-event data subjects, external event origin, query paging/sorting/change-set delivery, event
+generations, a typed context descriptor or command-handler role, code round-trip
+equivalence, or typed diagnostic repairs. Model today's syntax and record the
+gap in prose or an issue.
 
 ## Editor support
 

package/package/corpus/skills/cratis-screenplay-model-authoring/references/mcp-tools.md

@@ -19,9 +19,9 @@ these short descriptions.
 | Understanding | `describe-application`, `search-declarations`, `find-declaration`, `declaration-details` | Navigate logical hierarchy and inspect bounded details |
 | References and examples | `find-references`, `dependencies`, `find-fixtures`, `find-assertion-gaps` | Inspect declared relationships and authored examples, not executed coverage |
 | Source and validation | `diagnostics`, `read-document`, `merged-document`, `syntax-schema` | Read exact source or typed structure and diagnose problems |
-| Workspace inspection | `open-workspace`, `read-workspace`, `read-ast`, `workspace-state`, `export-workspace` | Obtain current identities, handles, readiness and durable-state status |
+| Workspace inspection | `open-workspace`, `read-workspace`, `read-ast`, `workspace-state`, `export-workspace` | Obtain current identities, handles, readiness, code attachment requirements and durable-state status |
 | Planning | `propose-ast`, `propose-rename`, `propose`, `recommend-layout`, `expand-layout` | Produce validated, reviewable candidates without writing them |
-| Review | `read-proposal`, `discard-proposal` | Inspect exact changes or abandon a connection-local proposal |
+| Review | `read-proposal`, `discard-proposal` | Inspect exact changes, dropped comments and proposed attachments, or abandon a connection-local proposal |
 | Effects | `apply`, `recover-workspace` | Apply an accepted plan or explicitly recover an interrupted write |
 
 `propose` is the executable-only whole-document interface. Prefer `propose-ast`
@@ -62,9 +62,25 @@ expand the user's requested authority.
 
 ## Formatting and recovery limits
 
-Verified trivia patches preserve bytes outside the changed members. General AST
-replacement may require canonical printing and can remove comments in touched
-files; that choice must be explicit. Untouched files remain byte-identical.
+Verified trivia patches (`PreserveTrivia`) preserve bytes outside the changed
+identifier, literal or mapping. Structural edits require explicit
+`CanonicalizeTouchedDocuments`: attached comments and authored member order
+within a document are kept, whitespace and blank lines are normalized, and a
+comment that cannot be placed is dropped. Every proposal reports
+`droppedCommentCount`; `read-proposal` with `view: "dropped-comments"` lists each
+one with path, line, column and text. Disclose non-zero counts before applying.
+Untouched files remain byte-identical.
+
+## Code attachments
+
+`read-workspace` and `read-proposal` accept `view: "implementation-requirements"`.
+Each entry names the role, owner, requirement id, required capability,
+attachment resolution and content hash, plus `bodySpan` and `bodyLines`: a source
+map in UTF-16 offsets for a host editor's language service. The server loads
+`file` attachments from its trusted root for hashing only and warns with
+`PLAY0430` to `PLAY0434` for refused or missing files. Attachment hashes can change between
+pages without changing `expectedRevision`; re-read the view when you need a
+stable snapshot. No tool compiles or runs attached code.
 
 Apply journals its inverse before changing source/state, stages private bytes and
 verifies results. Recovery refuses unexpected third-party content. The model root

package/package/corpus/skills/cratis-screenplay-model-authoring/verification.json

@@ -42,6 +42,22 @@
     {
       "kind": "skill-contains",
       "value": "`Safe`"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "Report which of the four states you checked"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "`view: \"dropped-comments\"`"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "`view: \"implementation-requirements\"`"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "Screenplay never compiles or runs them"
     }
   ]
 }