@cratis/pi 2.23.1 → 2.24.1

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

@@ -0,0 +1,111 @@
+# Contexts and context expressions
+
+Four contexts, one per job. What each **omits** is as deliberate as what it
+carries: a validation rule cannot see the caller's roles, and a policy cannot see
+the causation chain.
+
+## The four contexts
+
+```csharp
+public record CommandContext(
+    dynamic Command, TenantId Tenant, Identity Identity,
+    CausedBy CausedBy, Causation Causation, DateTimeOffset Occurred);
+
+public record QueryContext(
+    dynamic Arguments, TenantId Tenant, Identity Identity,
+    CausedBy CausedBy, Causation Causation, DateTimeOffset Occurred);
+
+public record RuleContext(
+    dynamic Artifact, dynamic Value, string Property,
+    TenantId Tenant, CausedBy CausedBy, DateTimeOffset Occurred);
+
+public record PolicyContext(
+    dynamic Artifact, string Subject, Identity Identity,
+    TenantId Tenant, DateTimeOffset Occurred);
+```
+
+| Context | In scope for | Omits | Why |
+| --- | --- | --- | --- |
+| **Command** | a command `handler` | — | the full picture |
+| **Query** | a query `performer` | — | same, with `Arguments` instead of `Command` |
+| **Rule** | a `validate` rule body | **`Identity`** | a rule *may* reject based on who sent it — "you may not approve your own request" is validation, and `CausedBy` carries the caller's identifier for it. Inspecting **roles or claims** is authorization and belongs in a `policy`; leaving those out is what keeps the two apart |
+| **Policy** | a `policy` code block | **`CausedBy`, `Causation`** | a decision about the caller, not an audit record |
+
+`RuleContext` carries `Artifact` (the whole thing under validation), `Value` (the
+value the rule is declared on) and `Property` (where it sits — empty for a
+whole-command `require`).
+
+## The values they carry
+
+| Type | Members |
+| --- | --- |
+| `Identity` | `Id`, `Name`, `UserName`, `IsAuthenticated`, `Roles`, `Claims` |
+| `Claim` | `Name`, `Value` |
+| `CausedBy` | `Subject`, `Name`, `UserName` |
+| `Causation` | `Type`, `Occurred`, `Properties` |
+
+`Identity` is the **authorization** view of the caller — what a policy decides on.
+`CausedBy` is the **audit** view of the same caller — the three values that travel
+with an appended event.
+
+## Reaching the context declaratively
+
+Usable wherever a mapping source is — `produces` mappings, `seed` values, capture
+`append` mappings, query `from` parameters:
+
+| Path | Yields |
+| --- | --- |
+| `$context.occurred` | when the command or query was received |
+| `$context.tenant` | the tenant |
+| `$context.command.<property>` | a command property (in commands) |
+| `$context.arguments.<name>` | a query argument (in queries) |
+| `$context.identity.id` | the caller's identifier |
+| `$context.identity.name` / `.userName` | display name / user name |
+| `$context.identity.isAuthenticated` | whether the caller is authenticated |
+| `$context.identity.roles` | the caller's roles |
+| `$context.identity.claims.<name>` | one claim value |
+| `$context.causedBy.subject` / `.name` / `.userName` | the audit view |
+| `$context.causation.type` | the causation type |
+
+An unknown `$context.` path is reported, so a typo does not silently become null.
+
+## The other expression roots
+
+| Root | Where | Yields |
+| --- | --- | --- |
+| `$env.<VAR_NAME>` | mapping sources | an environment variable |
+| `$eventContext.<property>` | **projections only** | `occurred`, `sequenceNumber`, `correlationId`, `eventSourceId` |
+| `$eventSourceId` | **projections only** | shorthand for `$eventContext.eventSourceId` |
+| `$causedBy.<property>` | **projections only** | `subject`, `name`, `userName` — an unknown one is an error naming all three |
+| `$.` | **captures only** | a value from the current source item |
+| `$strings.<dotted.key>` | labels, titles, messages | a localized string from a `.strings` file |
+
+## Templates and literals
+
+A template is backticked with `${}` substitutions:
+
+```screenplay
+fullName = `${firstName} ${lastName}`
+```
+
+Literals are `true` / `false`, `"quoted text"`, numbers (`42`, `-3.14`), and
+`null`. In a projection, `literal <value>` forces a value to be read as a literal
+rather than a property path — that is how a constant key is written:
+
+```screenplay
+from UserLoggedIn key literal "site-stats"
+  count TotalLogins
+```
+
+⚠️ A template expression is **not allowed in a composite key**, and a composite
+key with no parts is an error.
+
+## Escaping
+
+A reserved word used as a property name is escaped with a leading `@` —
+`@with`, `@file`, `@validate`. This matters most in three places:
+
+- a `trigger` body reserves `file`, so a trigger value named `file` is `@file`;
+- an `Enum` concept value named `validate` is `@validate`, or it reads as an
+  empty validate block;
+- a projection clearing a property named `with` is `clear @with`.

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

@@ -0,0 +1,23 @@
+{
+  "skill": "cratis-screenplay-command-surface",
+  "input": "Declare a Screenplay command with validation, authorization and concurrency.",
+  "fixtures": [],
+  "assertions": [
+    {
+      "kind": "skill-contains",
+      "value": "A second `identifier` on the same command is an error"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "`produces` and `handler` are mutually exclusive"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "Two adjacent policies synthesize an implicit `and`"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "`identifier` on an **event** property is an error"
+    }
+  ]
+}

package/package/corpus/skills/cratis-screenplay-event-modeling/LICENSE

@@ -0,0 +1,2 @@
+Copyright (c) Cratis. All rights reserved.
+Licensed under the MIT license. See LICENSE file in the project root for full license information.

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

@@ -0,0 +1,204 @@
+---
+name: cratis-screenplay-event-modeling
+description: Facilitate an Event Modeling session and land the result as Cratis Screenplay `.play` source — domain discovery, the nine-step workflow per behavior, the four slice types, information completeness, and the model-validation gate. Use when designing an information system, mapping a business process or information flow, deciding the event vocabulary or stream boundaries, or turning a whiteboard model into `.play`. Do not use for the language and compiler mechanics alone, and do not use to render a settled model into an application.
+license: MIT
+---
+
+# Event modeling with Screenplay
+
+Event Modeling is the **method**: walk a business process left to right and write
+down every behavior as a command that changes the system, a view that reads it,
+an automation that runs off it, or a translation of outside data. Screenplay is
+the **artifact**: one language that holds that whole model — concepts, commands,
+events, read models, queries, screens, specifications — in files that compile.
+
+You are a **facilitator, not a stenographer.** Ask probing questions. Challenge
+assumptions. Keep asking *"and then what happens?"* after every event, every
+command, every answer. Use business language. Do not discuss databases, APIs, or
+frameworks during modeling.
+
+## Verified product sources
+
+| 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 |
+
+Read from the Screenplay repository at tag `v4.12.1` (commit `122eee8`). 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,
+> *Understanding Eventsourcing*), as structured in
+> [jwilger/agent-skills `event-modeling`](https://github.com/jwilger/agent-skills/tree/main/skills/event-modeling).
+> Screenplay adopts that vocabulary directly: *"Slices are the atom — everything
+> lives inside a typed slice aligned with Event Modeling's vocabulary."*
+> Where Cratis deliberately diverges, this skill says so.
+
+## Two phases — discovery, then design
+
+**Never jump into detailed workflow design without broad domain understanding.**
+Phase 1 maps the territory; Phase 2 explores each region.
+
+**Phase 1 — Domain discovery.** What does the business do? Who are the actors?
+What major processes exist? What external systems integrate? Which workflow is
+most critical? *Ask the user; do not assume answers.* Lands as the `module` set,
+`persona` declarations, and the `import` list.
+
+**Phase 2 — Workflow design.** One workflow at a time, all nine steps, before
+starting the next. Read **[nine-steps.md](references/nine-steps.md)** — it carries
+each step's activities, its Screenplay output, and the facilitation questions.
+
+## The prime directive: do not lose information
+
+Store what happened (events), not just current state. Events are immutable
+past-tense facts in business language. **Every read-model field must trace back to
+an event.** If a field has no source event, something is missing from the model —
+it is not an optional column.
+
+## The four patterns → the four slice types
+
+Every behavior is exactly one. An unknown slice type is a compile error:
+*Unknown slice type '<x>' - expected StateChange, StateView, Automation or Translate*.
+
+| Pattern | Slice type | Screenplay constructs |
+| --- | --- | --- |
+| Command → Event | `StateChange` | `command` → `produces` → `event`, plus `validate`, `authorize`, `constraint` |
+| Events → Read Model | `StateView` | `readmodel`, `projection` or `reducer`, `query`, `screen` |
+| Event → decision → Command/Event | `Automation` | `reaction` |
+| External data → Event | `Translate` | `capture` |
+
+**A slice is one behavior, not one artifact of each kind.** Every construct may
+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.
+
+**Translation is workflow-specific anti-corruption.** Generic infrastructure every
+workflow needs (event persistence, message transport) is not a `Translate` slice.
+
+## Where Cratis diverges from the generic method
+
+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.
+- **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
+  and travels with every use, while a state-dependent rule stays a specification.
+  The split is the same; the place is different.
+
+## Naming the primitives is the highest-value work
+
+- **Concepts before events.** `concept InvoiceId : Uuid` once, and every construct
+  using it is typed end to end. The seven primitives are `Uuid`, `String`, `Int`,
+  `Decimal`, `Bool`, `Date` and `DateTime`; `Enum` is a separate concept kind,
+  with its values indented beneath.
+- **Classify personal data at the concept**, with a reason:
+  `concept PersonName : String @pii` plus an indented `pii reason "..."`. Every
+  usage inherits it; a reason for an attribute the concept does not declare is an
+  error. Decide this before fixing event shapes — erasure follows the subject and
+  the subject follows the stream.
+- **Events are past tense and self-describing** — `InvoiceRegistered`, never
+  `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
+  `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.
+
+## Model validation — the gate before implementation
+
+Run this after the GWT specifications are written. **Do not proceed with gaps.**
+When one is found, ask the user to clarify, create the missing element, re-validate.
+
+1. Every `readmodel` property traces to an `event` (**backward trace**).
+2. Every `event` feeds a projection, reaction, or capture target (**forward trace**).
+3. Every `command` has documented rejection conditions.
+4. Every `reaction` has a termination condition and cannot loop forever.
+5. No `given`/`when`/`then` clause references an undefined element.
+6. Every behavior is exactly one slice type.
+7. Read-model fields use collection types where the domain allows concurrent
+   instances — ask *"can there be more than one of these at once?"* for each field.
+8. No cross-cutting infrastructure is modeled as a `Translate` slice.
+
+## One file, or a folder
+
+Start with one file, read top to bottom. Reach for a folder when it stops being
+navigable — the invoicing sample is 981 lines with **one** module.
+
+The folder layout mirrors the language, one folder per level: `application.play`
+at the root (`domain`, `import`, `concept`, `type`, `policy`, `persona`,
+`authentication`, `seed`), then `<Module>/<Module>.play`,
+`<Module>/…/<Feature>/<Feature>.play`, and `<Module>/…/<Slice>/<Slice>.play` for
+one slice, whole. A slice file restates its `module` and `feature`; nothing is
+written twice.
+
+⚠️ **Compile the folder as one application.** `screenplay <folder>` merges every
+`.play` beneath the root *before* resolving, so an event declared in one file and
+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.
+
+## Verify
+
+```shell
+screenplay path/to/model --warnaserror
+```
+
+- [ ] Zero errors **and zero warnings**. An unrecognized construct inside a slice
+      is only a warning (`PLAY0029`) and its block is **silently dropped** — a typo
+      can delete a whole projection while the exit code stays `0`.
+- [ ] Every behavior is exactly one slice type, and the whole model validates
+      against the eight checks above.
+- [ ] Every event is past tense, single-purpose, and carries no event-source id.
+- [ ] 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).
+
+## 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.
+
+## Route near misses
+
+| Need | Skill |
+| --- | --- |
+| Commands, validation, authorization, `produces`, concurrency, `$context` | `cratis-screenplay-command-surface` |
+| Projections — PDL keys, joins, children, removal, arithmetic | `cratis-screenplay-projections` |
+| Read models, queries, screens | `cratis-screenplay-read-surface` |
+| Layouts, templates, forms, contributions, themes, i18n | `cratis-screenplay-ui-composition` |
+| Captures (CDL), reactions, triggers | `cratis-screenplay-captures-and-reactions` |
+| Given/when/then specifications | `cratis-screenplay-specifications` |
+| Language mechanics, the compiler, the admitted set | `cratis-screenplay-model-authoring` |
+| Rendering a settled model into an application | `cratis-stage-rendering-and-sandbox` |
+| Drawing the model as a Mermaid diagram | `cratis-event-model-diagram` |
+| Modeling against hand-written Chronicle C# | `cratis-chronicle-event-modeling` |

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

@@ -0,0 +1,219 @@
+# The nine-step workflow design process
+
+Follow all nine steps for each workflow. Do not skip steps, do not combine them,
+and do not start workflow 2 while workflow 1 is incomplete — **discovery is
+design**. Each step has a defined Screenplay output; produce it.
+
+## Step 1 — Identify the user goal
+
+Ask until the goal is unambiguous: *"What exactly is the user trying to
+accomplish? What does success look like? What would make this fail?"*
+
+**Output:** the `feature` name and its `description`.
+
+```screenplay
+module Invoicing
+  feature InvoiceManagement
+    description "Registering and managing the lifecycle of invoices"
+```
+
+`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.
+
+## Step 2 — Brainstorm events
+
+Sticky-note style, no ordering yet. *"What facts need recording? What happened
+that we care about? What would an auditor want to know?"* Keep asking *"what
+else?"*
+
+Past tense, business language, facts: `InvoiceRegistered`, `PaymentReceived`.
+
+**Domain facts vs runtime context.** Events must be true regardless of which
+machine replays them. A working directory, PID or hostname is runtime context and
+does not belong in an event.
+
+**Output:** a list of `event` names. Shapes come later.
+
+## Step 3 — Order events chronologically
+
+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
+structure.
+
+## Step 4 — Create wireframes
+
+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.
+
+```
++-------------------------------+
+|  Register Invoice             |
++-------------------------------+
+|  Customer:  [dropdown]        |
+|  Lines:     [list]            |
+|  Total:     $XX.XX            |
+|                               |
+|  [Register]                   |
++-------------------------------+
+```
+
+Every field traces to an **event field** (something displayed) or a **command
+input** (something provided). If you cannot trace a field, something is missing.
+
+**Concurrency check:** *"Can there be more than one of these in progress at the
+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>`.
+
+## Step 5 — Identify commands
+
+For each event: *"What triggered this? Who issued that command? What information
+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`.
+
+```screenplay
+slice StateChange RegisterInvoice
+  command RegisterInvoice
+    invoiceId     InvoiceId identifier
+    invoiceNumber InvoiceNumber
+    authorize CanManageInvoice
+    validate
+      invoiceNumber not empty  message "Invoice number is required"
+    produces InvoiceRegistered
+      invoiceId     = invoiceId
+      invoiceNumber = invoiceNumber
+      registeredAt  = $context.occurred
+```
+
+The "under what circumstances would this NOT happen" answers become `validate`
+rules, `authorize` policies, `constraint` declarations, and the rejection
+specifications.
+
+## Step 6 — Design read models
+
+Read models exist to support what wireframes display and what automations need.
+For each actor at each point, and for each automation: *"What does this person
+need to see? What information do they need to decide? What does this automation
+need to determine its next action?"*
+
+Verify **every** field traces back to an event:
+
+```
+InvoiceListReadModel:
+  invoiceId      <- InvoiceRegistered.invoiceId
+  invoiceNumber  <- InvoiceRegistered.invoiceNumber
+  status         <- InvoiceRegistered, InvoiceSent, InvoicePaid
+```
+
+**Concurrency check per field:** if the domain supports concurrent instances, use
+a collection type, not a singular value.
+
+**Output:** the `readmodel` shape and the one `projection` or `reducer` that
+builds it. **Exactly one thing may build a read model** — two builders is a
+compile error (`PLAY0191`).
+
+```screenplay
+slice StateView InvoiceList
+  readmodel InvoiceListReadModel
+    invoiceNumber InvoiceNumber
+    status        InvoiceStatus
+  projection InvoiceList => InvoiceListReadModel
+    from InvoiceRegistered key invoiceId
+      status = "draft"
+    from InvoiceSent
+      status = "sent"
+  query ListInvoices => InvoiceListReadModel[]
+```
+
+**Do not model infrastructure preconditions as read models.** "Does the directory
+exist?" is not domain state.
+
+## Step 7 — Find automations
+
+*"Does anything happen automatically after this event? What business rules trigger
+other processes? Does the system need to check anything before acting?"*
+
+**All four components are required for a true automation:** a triggering
+occurrence, state it consults, conditional logic, and a resulting command or
+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.
+
+```screenplay
+slice Automation ChaseOverdueInvoices
+  reaction OverdueChaser
+    when InvoiceRegistered
+      invoiceId
+      dueDate
+      invokes MarkInvoiceOverdue
+        invoiceId = invoiceId
+    where dueDate < today
+```
+
+`produces` and `invokes` are indented **inside** the trigger; only `description`
+and `where` sit at reaction level. Outdenting an effect gives `PLAY0137`.
+
+`produces` appends a fact nothing can refuse. `invokes` asks for a command, which
+may still validate and reject. The words are different on purpose.
+
+Every automation needs a **termination condition**. Watch for infinite loops.
+
+## Step 8 — Map external integrations
+
+*"Does this workflow receive data from outside? Does it send data outside?"* Note
+names and purposes only — no APIs, webhooks or protocols yet.
+
+**Ask:** *"Is this integration specific to THIS workflow, or would every workflow
+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.
+
+```screenplay
+trigger BuildFinished
+  repository
+  outcome
+```
+
+A `trigger` declares that the name exists and what an occurrence hands the
+reaction — deliberately **not** what makes one occur.
+
+## Step 9 — Decompose into vertical slices
+
+List every slice grouped by type. A good slice is a complete interaction,
+independently valuable, testable in isolation, small enough for 1–2 days.
+
+Bad slices: *"Set up database"* (technical, no user value), *"Implement invoicing"*
+(too broad), *"Create Invoice table"* (implementation detail).
+
+**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.
+
+**Output:** the complete `feature` → `slice` tree, ready for the specifications.
+
+## Facilitation questions quick reference
+
+| Topic | Questions |
+| --- | --- |
+| Domain discovery | What does the business do? Who are the actors? What are the major processes? What external systems exist? Which workflow is most critical? |
+| Events | What facts need recording? What happened here? Would the business need to know this? |
+| Timeline | What happens first? And then? Can these happen in parallel? |
+| Commands | Who initiates this? User-triggered or automatic? What intent does this represent? |
+| Read models | What does this actor need to see? What queries do users run? Can multiple instances be active at once? |
+| Automations | Does anything happen automatically? What business rules apply? Can this response ever be skipped? |
+| Edge cases | What if this fails? What if the user cancels? What if the external system is down? |

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

@@ -0,0 +1,23 @@
+{
+  "skill": "cratis-screenplay-event-modeling",
+  "input": "Facilitate an event modeling session and land the model as .play source.",
+  "fixtures": [],
+  "assertions": [
+    {
+      "kind": "skill-contains",
+      "value": "expected StateChange, StateView, Automation or Translate"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "**Every read-model field must trace back to"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "references/nine-steps.md"
+    },
+    {
+      "kind": "skill-contains",
+      "value": "is not admitted by ESM v1"
+    }
+  ]
+}

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

@@ -92,7 +92,7 @@ Translate`:
 
 **Inside any slice:** `description`, `event`, `command`, `query`, `projection`,
 `capture`, `reaction`, `screen`, `constraint`, `specification`, `readmodel`,
-`reducer`. An unrecognised word here is a **warning**, not an error, and its
+`reducer`. An unrecognized word here is a **warning**, not an error, and its
 block is skipped — a typo can silently drop a whole construct, so treat slice
 warnings as failures.
 
@@ -207,16 +207,20 @@ The language service ships two ways: the Monaco package
 (marketplace id `cratis.screenplay`), which is the same service plus a `.play`
 file icon.
 
-⚠️ Its keyword list has drifted from the parser. `theme`, `ui`, `form`,
-`contribute`, `dialog` and `reducer` have no keyword, tokenizer or completion
-entry in the Monaco package (the words occur only in prose and theme names),
-although all six are real constructs the compiler accepts. They get no
-highlighting and no completion. Absent highlighting is not evidence that a
-construct is wrong — check `screenplay` instead.
+Its keyword list had drifted from the parser: `capture`, `projection`, `reducer`,
+`contribute`, `dialog`, `form`, `theme` and `ui` were constructs the compiler
+accepts with no keyword entry, so they got no highlighting and no completion.
+Fixed in `Cratis/Screenplay#199`, which also added a specification deriving the
+dispatched set from the parsers so the two cannot drift apart again silently.
+
+⚠️ The general lesson stands regardless: **absent highlighting is not evidence
+that a construct is wrong** — check `screenplay` rather than the editor.
 
 The repository's TypeScript workspaces are **not** built, linted or tested by any
-pull-request workflow; they run only inside the release job. Do not read a green
-pull request as evidence the language service still compiles.
+pull-request workflow; only `dotnet-build.yml` runs tests on a pull request. Do
+not read a green pull request as evidence the language service still compiles —
+and put any guard on the language service in the C# suite, which is the one that
+actually runs.
 
 ## Verify
 
@@ -232,6 +236,18 @@ pull request as evidence the language service still compiles.
 
 ## Route near misses
 
+This skill is the language and compiler reference. For the constructs themselves:
+
+| Need | Skill |
+| --- | --- |
+| Facilitating the model and the nine-step method | `cratis-screenplay-event-modeling` |
+| `command`, `event`, `validate`, `authorize`, `produces`, `concurrency`, `$context` | `cratis-screenplay-command-surface` |
+| `projection` and the PDL, `reducer` | `cratis-screenplay-projections` |
+| `readmodel`, `query`, `screen` | `cratis-screenplay-read-surface` |
+| `layout`, templates, `form`, `contribute`, `theme`, `$strings` | `cratis-screenplay-ui-composition` |
+| `capture` and the CDL, `reaction`, `trigger` | `cratis-screenplay-captures-and-reactions` |
+| `specification` | `cratis-screenplay-specifications` |
+
 - Turning a model into an application, or the runtime sandbox:
   `cratis-stage-rendering-and-sandbox`.
 - Designing an event model as a diagram rather than as a `.play` file:

package/package/corpus/skills/cratis-screenplay-projections/LICENSE

@@ -0,0 +1,2 @@
+Copyright (c) Cratis. All rights reserved.
+Licensed under the MIT license. See LICENSE file in the project root for full license information.