@cratis/pi 7.32.0 → 7.34.0

package/package/corpus/skills/cratis-screenplay-delivery-planning/references/parallel-delivery.md

@@ -0,0 +1,45 @@
+# Parallel delivery
+
+Read when splitting work across people or agents, building the dependency table or grouping issues.
+
+## Why slices can run in parallel
+A slice consumes events and views and produces events and views. Those are its contracts. A slice that needs `OrderConfirmed` can be built and specified against synthetic `given` events before the slice that produces it exists, because the model fixes the event's shape. When the producer lands, the consumer's specifications already describe what it expects. Slice design records this per slice (`cratis-screenplay-slice-design`, `references/slicing.md`); planning reads it.
+
+This holds only for event and view contracts. Edges through `reads` of another slice's view, `invokes` of another slice's command from a reaction, and shared streams are real coordination points: record them as edges and plan an owner for each.
+
+## Derive the dependency table
+Use the Screenplay MCP rather than a board or memory (`cratis-screenplay-model-authoring`):
+- `describe-application` for slice counts and children,
+- `dependency-graph` at slice level (`from`/`to`) with its `edges`, `cycles` and `order` views as the starting point for the waves; its order is advisory and covers only `usesFactsFrom`/`reactsTo`/`decidesFrom` edges (`reads` maps to `decidesFrom`; only `asks` edges from invokes, actions and forms, and `shows` edges are left out of order and cycles),
+- `dependencies` and `find-references` for each slice's consumed and produced contracts and for the `reads` and `invokes` edges; `invokes`, action and form edges are not ordered by the graph, and `reads` is ordered but still a coordination point.
+
+`complete: false`, uncovered declarations or ambiguous bindings mean the table is incomplete; list them as unknown and resolve them in the model before relying on parallelism. Container `depends on` declarations are orientation, not execution order.
+
+Table, one row per slice:
+
+| Slice | Type | Realization | Consumes (from slice) | Produces | Waits on | Wave |
+|---|---|---|---|---|---|---|
+
+## Waves
+- Wave 1: slices that consume nothing, or only events their own scope produces.
+- Wave n: slices whose producers are all in earlier waves.
+- Slices in one wave are independent and can run in parallel.
+- A cycle means feedback; model it as an Automation slice or return to slice design. Do not schedule a cycle.
+
+Because consumers can build against synthetic events, a wave boundary is an integration check (producer and consumer agree on the contract), not a hard start gate. Say which waves you started early and where the contract check will happen.
+
+## Contract ownership
+- Each event and view has one owning slice; its shape is changed in the model, never in a consumer.
+- A contract change reopens every consumer in the table: recount and notify their owners.
+- When people or agents work in parallel, brief each from the model's slice and its consumed contracts (a brief states the goal, the files owned, the exact verification command, the done condition, the stop conditions and the report format); one writer per branch or worktree.
+
+## Slice groups and issues
+- One GitHub issue per slice group: slices that share a view, a stream or an owner, small enough for one person to finish.
+- Status block lists the slices (name, type, realization), the wave, blockers and each slice's planning status (todo, in progress, blocked, done). That vocabulary is per slice; the issue's own state follows the repository's hygiene (in progress, in review, paused, blocked, done when delivered). Update the block rather than adding progress comments.
+- Claim before starting: assign the issue, keep an in-progress status in its body and check for an existing claim (for example `issue_work` where the harness provides it). If the group is already in progress, choose another; do not take over.
+- Mark `blocked` only with the named producer, decision or outside party.
+
+## Parallelism that does not pay
+- Slices writing the same file, stream or external resource.
+- Two hand-written slices that depend on the same unresolved integration.
+- A wave with one slice: no parallelism, use the time for integration, review or the next wave's briefs.

package/package/corpus/skills/cratis-screenplay-delivery-planning/references/provenance.md

@@ -0,0 +1,29 @@
+# Provenance
+
+## Method lineage
+The planning method (count the modeled units, let explicit contracts allow parallel work, estimate from the team's measured throughput, plan capacity and review with retrospective metrics) comes from the Event Modeling community: Adam Dymitruk's Event Modeling, and Martin Dilger's writing on estimating from event models. They are cited as practice. The text of this skill is written for Screenplay slices and Cratis delivery.
+
+## Adapted closely (Martin Dilger and Nebulit GmbH)
+
+Source: https://github.com/Nebulit-GmbH/agentic-engineer at commit `07b0f30648d663cb588d7e2c7aa031af9dfc21f2`,
+by Martin Dilger and Nebulit GmbH (https://nebulit.de), used with the explicit consent of Martin Dilger and Nebulit GmbH.
+
+| Source file | Used in | How |
+|---|---|---|
+| `.claude/skills/eventmodeling-orchestrating-event-modeling/references/project-planning-with-event-modeling.md`: contracts let steps proceed in parallel | `SKILL.md` ground rules, `references/parallel-delivery.md` | adapted closely; steps become slices, contracts are the events and views a slice consumes and produces in the `.play` model |
+| same: velocity measured from history, estimating a project by counting | `SKILL.md` procedure, `references/velocity-and-capacity.md` | adapted closely; velocity becomes throughput of weighted slices from issue history, results are ranges with a stated basis |
+| same: variable complexity (typical, complex, simple steps) | `references/slice-counting.md` "Weights" | adapted; weights are by slice type and realization and are calibrated by the team |
+| same: capacity planning, dependency handling across teams, organization-level velocity | `references/velocity-and-capacity.md` "Capacity", `references/parallel-delivery.md` "Waves" | adapted; waves derived from the model's dependencies instead of a spreadsheet |
+| same: common estimation mistakes (equal weights, non-implementation work, ignoring dependencies) | `references/slice-counting.md` "What not to count", `references/parallel-delivery.md` | adapted closely |
+| same: retrospectives and key metrics table | `references/velocity-and-capacity.md` "Retrospective metrics" | adapted closely; metrics extended with cycle time by class, blocked time and rework |
+| `.claude/skills/update-slice-status/SKILL.md`: closed slice status vocabulary and the already-in-status guard | `SKILL.md` "Status vocabulary" | adapted; four statuses (todo, in progress, blocked, done) applied to GitHub issues, the board API dropped; the guard becomes "pick another slice" and `issue_work` claim |
+
+## Not adopted
+| Source material | Why |
+|---|---|
+| "±50% versus ±10%" accuracy claims and "4-6 months guess, 6-9 months actual" comparisons | no source or data given; Cratis estimates are ranges derived from the team's own counts and rates |
+| "Flat cost curve" diagrams and fixed example numbers (3 steps per sprint, 1 week per step) | illustrative figures, not facts; a team's throughput is measured, not assumed |
+| Sprint and week-based schedule spreadsheets | replaced by waves, slice groups and ranges |
+| The eventmodelers board, token and slice-status API, MCP slice listing, and node events | Screenplay MCP navigation and GitHub issues replace them |
+| Statuses Created, Planned, Review, Assigned, Informational | replaced by the four-status set; review is a gate in the lifecycle, assignment is the issue assignee |
+| Autonomous continue-without-asking behavior in the upstream orchestration | Cratis keeps the model-first gates and user authority; planning never skips review or acceptance |

package/package/corpus/skills/cratis-screenplay-delivery-planning/references/slice-counting.md

@@ -0,0 +1,43 @@
+# Slice counting
+
+Read when counting, classifying or weighing the slices of an accepted model.
+
+## What counts
+One unit per slice of an accepted model. The type is the slice's declared type; the model decides it, not the planner.
+
+| Type | What it delivers | Usually realized by |
+|---|---|---|
+| StateChange | a command, its rules and the events it produces | Stage renders it where admitted; else hand-written |
+| StateView | a read model with its projection and query | Stage renders it where admitted; else hand-written |
+| Automation | a reaction, todo list or trigger doing follow-up work | hand-written against the model (gap-fill) |
+| Translate | a capture or translator turning outside data into events | hand-written against the model (gap-fill) |
+
+Screens and UI composition belong to the slice whose data and actions they show. Count a screen separately only when the plan has a separate frontend owner, and then count it as its own line, not as a slice.
+
+Count a rendered slice and a hand-written slice in different rows even when they share a type. The first row's effort is review, verification and customization; the second's is implementation.
+
+## What not to count as slices
+Plan these as separate lines, not slice weight:
+- modeling, review and acceptance gates (lifecycle phases P0 to P6); P7 to P9 verification is part of each slice's done criteria,
+- environment, hosting, deployment, identity and authorization provider setup,
+- integration with an outside system beyond the slice's own adapter (credentials, sandboxes, contract tests with the other party),
+- migration of existing data,
+- documentation and training.
+
+## Realization check
+Before pricing a slice as rendered, run the admission probe in `cratis-screenplay-render-and-gap-fill` for the whole model. Do not restate version pins in a plan; cite `cratis-screenplay-toolchain` `references/versions.md` for the pair you used. A slice Stage refuses (an `STAGE-ESM-*` code) is hand-written work with the model as contract: price it as hand-written and record the refusal code.
+
+## Weights
+Weights are the team's, calibrated from completed slices, not constants of the method. Start with a simple scale and let history replace it:
+
+| Class | Starting weight (first estimate without history) |
+|---|---|
+| rendered StateChange or StateView, no customization | 1 (the reference) |
+| StateChange or StateView with customization or hand-written | 2 |
+| Automation or Translate | 3 |
+| any slice with an outside system on the critical path | add a separate integration line |
+
+These starting weights are placeholders to be replaced. State them as assumptions in the plan. After the first completed groups, derive each class's weight as its median actual effort divided by the median effort of the reference class.
+
+## Re-count triggers
+Recount when: the model's slice set changes, a slice's type changes, a slice splits or merges, Stage admission changes after a tool upgrade, or a hand-written slice turns out renderable (or the reverse).

package/package/corpus/skills/cratis-screenplay-delivery-planning/references/velocity-and-capacity.md

@@ -0,0 +1,48 @@
+# Velocity and capacity
+
+Read when producing or updating an estimate, or when running a retrospective.
+
+## Measure throughput from history
+Throughput is the number of weighted slices a team completes per period, measured from the team's own finished slices.
+
+1. List the completed slices of the last few periods (weeks or iterations). A slice is completed when it is `done` in the status vocabulary: built, specifications passing, conforming to the model.
+2. Take dates from the issue or pull request history (opened and closed, or claimed and merged), not from memory.
+3. Record per period: slices completed by class, effort spent (person-days or agent-sessions), and anything unusual (leave, outages, a model rework).
+4. Compute the median and the lowest and highest period. Report all three.
+
+With fewer than about three completed periods or a handful of slices, the number is a first estimate without history: say so, keep the range wide, and do not extrapolate a trend.
+
+## Estimate as a range
+```
+remaining weighted slices  = sum over classes (count x team weight)
+duration low / expected / high = remaining / (high, median, low throughput)
+```
+- Report the range and its basis in one line: "N weighted slices; throughput X to Y per week from the last K weeks (slices ...)". Include the separate lines for work that is not slice work.
+- Do not state accuracy percentages or comparisons with other methods; they cannot be derived from your data. Calibrate by comparing your past ranges with what happened (below).
+
+## Capacity
+Throughput scales with people only along the dependency table: the useful parallelism of a wave is the number of independent slices in it, capped by the number of people or agents. A slice has one owner, so its work cannot be split across workers.
+```
+lower bound for a wave  = (weighted slices in the wave / workers in use) / throughput per worker
+elapsed time for a wave = (largest total weight assigned to one worker) / throughput per worker
+total elapsed time      = sum over waves (waves are sequential)
+```
+- Assign the wave's slices to workers first (heaviest first, each to the least-loaded worker), then take the most-loaded worker. The aggregate formula is only a lower bound; the wave can never finish before its heaviest single slice.
+- Example: three independent slices weighted 1, 1 and 3, three workers at one weighted unit per week. The lower bound says 5 / 3 = 1.7 weeks; the assignment gives loads 3, 1 and 1, so the wave takes 3 weeks. Split a heavy slice in the model (slice design) if it dominates a wave, never by sharing it between workers.
+- Throughput per worker comes from history with that many workers; adding a worker adds coordination cost, so measure after the change rather than assuming it multiplies.
+- Shared contracts (one event consumed by several slices) need one owner; count that integration as work.
+- Capacity levers other than people: faster verification (spec run time, CI queue), fewer hand-written slices (a model change that Stage admits), better adapters. Estimate their effect from a before and after measurement, not a promise.
+
+## Retrospective metrics
+After each completed group or iteration, record:
+
+| Metric | How | What it shows |
+|---|---|---|
+| Throughput | weighted slices done per period | the rate used for the next range |
+| Slice cycle time by class | claimed to done, per class | which classes carry the cost; recalibrates weights |
+| Estimate fit | planned range versus actual, per group | whether ranges were too narrow or too wide |
+| Parallel share | slices worked in parallel / slices in waves that allowed it | whether parallelism was used |
+| Blocked time | time in `blocked` and the named cause | dependency, decision or external waits |
+| Rework | slices reopened after done, or recounted after a model change | model stability |
+
+Use the results to adjust weights, widen or narrow ranges, and decide what to unblock first. Write them in `.ai-work/<task>/delivery-plan.md`; a pattern that must outlive the session becomes an issue.

package/package/corpus/skills/cratis-screenplay-delivery-planning/verification.json

@@ -0,0 +1,16 @@
+{
+  "skill": "cratis-screenplay-delivery-planning",
+  "input": "The model is accepted. How long will delivering it take, in what order, and how do we split it across three people?",
+  "fixtures": [],
+  "assertions": [
+    { "kind": "skill-contains", "value": "first estimate without history" },
+    { "kind": "skill-contains", "value": "Count slices, not features." },
+    { "kind": "skill-contains", "value": "`dependency-graph`" },
+    { "kind": "skill-contains", "value": "already `in progress`" },
+    { "kind": "skill-contains", "value": "Automation` and `Translate` are hand-written" },
+    { "kind": "skill-contains", "value": "Never quote an accuracy", "file": "SKILL.md" },
+    { "kind": "skill-contains", "value": "Estimate fit", "file": "references/velocity-and-capacity.md" },
+    { "kind": "skill-contains", "value": "Wave 1", "file": "references/parallel-delivery.md" },
+    { "kind": "skill-contains", "value": "One GitHub issue per slice group", "file": "references/parallel-delivery.md" }
+  ]
+}

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

@@ -31,5 +31,5 @@ SOFTWARE.
 
 This skill also adapts material from agentic-engineer by Martin Dilger and Nebulit GmbH
 (https://github.com/Nebulit-GmbH/agentic-engineer, commit 07b0f30648d663cb588d7e2c7aa031af9dfc21f2;
-https://nebulit.de), used with the agreement of Martin Dilger and Nebulit GmbH. That repository
-carries no licence file; the adapted material remains credited to Martin Dilger and Nebulit GmbH.
+https://nebulit.de), used with the explicit consent of Martin Dilger and Nebulit GmbH. The adapted
+material remains credited to Martin Dilger and Nebulit GmbH.

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

@@ -42,9 +42,9 @@ syntax and tool commands in `cratis-screenplay-toolchain`.
 
 ## Verified product sources
 
-Pins (Screenplay v4.66.0 `c89198b`, cratis CLI v3.28.3, Stage v4.24.2, Arc v22.50.5, Chronicle
-v19.32.0) are listed once in `cratis-screenplay-toolchain` `references/versions.md`.
-Statements here were checked at those tags:
+Current pins are listed once in `cratis-screenplay-toolchain` `references/versions.md`. The
+statements below were checked at these older tags (Screenplay v4.66.0 `c89198b`, cratis CLI v3.28.3,
+Stage v4.24.2, Arc v22.50.5, Chronicle v19.32.0), kept as provenance, not as current pins:
 
 | Fact used here | Source |
 | --- | --- |
@@ -57,7 +57,7 @@ Statements here were checked at those tags:
 | Any `@pii` or `@sensitive` on a concept fails binding (PLAY0268) at 4.66.0; current markers are in `cratis-screenplay-command-surface` | `v4.66.0:Source/DotNET/Screenplay/Semantics/SemanticModelBinder.Concepts.cs:21-24` |
 
 Every complete `screenplay` fence in this skill compiles with the standalone compiler
-4.68.0 (`--warnaserror`) and with `cratis screenplay validate --warnings-as-errors` 3.28.2.
+4.139.0 (`--warnaserror`).
 
 ## Interview phase
 
@@ -174,7 +174,7 @@ decided apart from what you assumed. Never guess silently.
   (`only if ...`), marked as stated intent not enforced in the model today, with its target
   enforcement named for `cratis-screenplay-streams-and-consistency` and
   `cratis-screenplay-slice-design`. Never state copies, attestation booleans or rules living
-  only in prose: `description` text is never rendered.
+  only in prose: `description` text reaches code only as XML doc comments, never as behavior.
 - Ask how the work is done today without the system; question steps that exist only for software.
 
 ### Review questions (ask; do not apply mechanically)
@@ -238,6 +238,7 @@ and the report says which verdicts were not run (V2 to V5 are not run in discove
 - `references/event-naming.md` - naming rules, not-an-event filter, repairs.
 - `references/personas-and-causes.md` - role catalogue, Cannot resolved to executable gates.
 - `references/divergent-sweep.md` - lenses for the wide pass.
+- `references/domain-analysis-template.md` - read when requirements arrive as prose and a person must confirm your reading before you model: the note shape, requirement checks, expert questions.
 - `references/plotting-and-handoff.md` - after / caused by / only if, plot format, whose turn it is, Storyline seed, handoff packet.
 - `references/facilitation.md` - running sessions, disagreement, closing, unattended runs. Read when facilitating a group, handling disagreement, or closing an attended or unattended session.
 - `references/human-workshop.md` - supporting a human workshop: preparation, run sheet, live scribing.

package/package/corpus/skills/cratis-screenplay-discovery/references/divergent-sweep.md

@@ -20,6 +20,7 @@ stage of the story:
 | Afterwards | Renew, reopen, roll over, appeal, refund? | follow-on stories or branches |
 | On behalf | Can someone act for another, or override? | Does/Cannot lines (denial specs) |
 | Proof later | What will an auditor, regulator or angry customer ask to see? | facts that looked like detail |
+| Without software | How would this run on paper, with people? Who acts, what triggers each action, what must they know first? Which step exists only because of the system (a loading state, a cache refresh, a session check)? | the real business steps; steps to drop; missing human hand-overs |
 | Hotspots | For each hotspot named in step 2: what goes wrong there today? | the deepest branch set |
 
 Outcome per lens and stage: modeled fact, set-aside (with why), open question, or "does not

package/package/corpus/skills/cratis-screenplay-discovery/references/domain-analysis-template.md

@@ -0,0 +1,92 @@
+# Domain analysis note
+
+Use this when requirements arrive as prose (a brief, tickets, a recorded session, an interview
+transcript) and you want one readable summary before or alongside the first `.play` edits. The
+`.play` model is the source of truth; this note is a work record that points to it. It lives in
+`.ai-work/screenplay/` (session state), never in the model folder or `.cratis/`, and is replaced
+by the model once the model says the same things. Adapted from Martin Dilger and Nebulit GmbH's
+brainstorming-events domain analysis (see `provenance.md`), reshaped for Screenplay.
+
+## When to write one
+- The input is long or scattered and a person must confirm your reading before you model.
+- A workshop produced notes that need turning into candidate events, roles and rules.
+- A reviewer or domain expert needs one page to answer, without reading `.play`.
+
+Skip it when the input is already short and structured; go straight to `references/storming-loop.md`.
+
+## Working it out
+1. Read the requirements and list the processes mentioned: who starts them, what steps follow,
+   where decisions and integrations occur.
+2. Extract the state changes. Each completed change is a candidate event ("Customer places order"
+   becomes `OrderPlaced`): "payment processed" becomes a confirmation fact; "item shipped" becomes a
+   shipment fact.
+3. Write the rules and invariants as stated ("can only ship once paid", "cancel within 24 hours").
+   Do not decide where they are enforced here.
+4. Name the entities as event timelines: each is the story its events tell, with a business
+   identity. These are groupings of events, not attribute lists.
+5. Note the questions the requirements do not answer.
+
+## Template
+```markdown
+# Domain analysis: <domain>
+
+Source: <documents, session, date>      Participants: <roles, if a workshop>
+
+## Roles
+Human roles, then system actors (internal or external; what sets them off).
+- <Role>: <description>. Does: <key actions>. Reads: <what it sees>. Cannot: <boundary>.
+- <System actor> (internal | external): <description>. Triggers: <what it starts>.
+
+## Entities (event timelines)
+- <Entity> (identity: <business identity>)
+
+## Business processes
+1. <Process>: initiated by <actor>; steps <1 -> 2 -> 3>; outcome <what changes>.
+
+## Candidate events
+- <Entity>: <PastTenseEvent>: when, why, who or what causes it.
+
+## Rules and constraints
+- <Rule>: condition and consequence, as stated in the source.
+
+## Questions for the domain expert
+- <Unclear process, missing actor, boundary condition>.
+
+## Where this went
+<Pointers to the `.play` declarations once modeled, or "not yet modeled">
+```
+
+## Requirements that make a good source
+Ask for, or write down as assumptions, each of these:
+- **Specific scope.** "Orders have items, pricing, a delivery address and can be cancelled within
+  24 hours", not "handle orders".
+- **Domain language**, not technical wording: "Customer places order with products", not "obj1
+  references obj2".
+- **Explicit constraints.** "Authorize payment before confirming the order; refund if shipment
+  fails", not "process payments".
+- **A complete role list.** Every actor an event or process mentions is in Roles, and every
+  event traces to one of them ("orders can be created" by whom?).
+- **Edge cases.** What if payment is declined? Can an order change once shipping starts? What
+  triggers cancellation?
+
+## Questions for the domain expert
+Keep them concrete and one decision each; send the three that unblock the most. Examples:
+- "When a payment is declined, does the order stay open, or end?"
+- "Who may cancel after shipping starts, and what happens to the goods?"
+- "Is a refund a separate step someone decides, or automatic?"
+
+Answers become events, rules or specifications; unresolved ones stay in STATE.md as open
+questions with the assumption in use (`cratis-screenplay-modeling-lifecycle` `references/stop-or-assume.md`).
+
+## Not every failure is an event
+A declined payment may be a refusal (nothing recorded) or a recorded fact that others react to
+(`PaymentDeclined`). Ask which; do not turn every error condition into an event. Most rejections
+are specifications (`then error`), recorded facts are the exception. See `references/event-naming.md`.
+
+## Quality checks before sharing
+- [ ] Every candidate event is past tense, one purpose, and names a completed change.
+- [ ] No generic update or delete events (`RecordUpdated`); events describe business moments.
+- [ ] Every role is distinct, and each event traces to one of them.
+- [ ] No two candidate events mean the same thing.
+- [ ] Rules are stated as the source states them, with unknowns left as questions.
+- [ ] Work is not wasted on attributes: fields wait until commands and views are designed.

package/package/corpus/skills/cratis-screenplay-discovery/references/personas-and-causes.md

@@ -55,7 +55,7 @@ declares the same policies and persona with the one-line form.
 ## What a Cannot line becomes
 
 The persona block is report-only: Screenplay neither binds nor enforces it, and no rendered
-code contains it (`description` text is never rendered). Cannot text is intent, not
+code contains it (`description` text reaches generated code only as XML doc comments). Cannot text is intent, not
 protection. Discovery lists the candidates; each stays pending until a later phase resolves it
 into exactly one of these:
 
@@ -64,7 +64,7 @@ into exactly one of these:
    plus a `then denied` specification using `given caller as <Persona>` for a
    synthesized witness, or an explicit effective-gate caller (`cratis-screenplay-scenario-coverage`). Every command and query
    under an inherited module or feature `authorize` gets its own denial spec. Ownership
-   against a Uuid-backed identifier is not renderable today (STAGE-ESM-015): note it.
+   against a text, Uuid, Date or DateTime subject renders at Stage 4.73.1; other subjects are STAGE-ESM-015: note it.
 2. **Gap or target requirement.** The check depends on stored state ("only the requester may
    withdraw") or cannot be gated today. Record it as a gap with its target enforcement for
    `cratis-screenplay-streams-and-consistency`; it is not enforcement and not a passed denial.

package/package/corpus/skills/cratis-screenplay-discovery/references/provenance.md

@@ -20,11 +20,10 @@ the `.trogonai/interviews/` trail file (replaced by bounded STATE.md); e-commerc
 Gherkin forms; the `total (calculated)` field example (contradicts the calculated-value rule);
 "capture every error condition as an event" (most failures are rejections).
 
-## Adapted closely (Martin Dilger and Nebulit GmbH, with agreement)
+## Adapted closely (Martin Dilger and Nebulit GmbH)
 
 Source: https://github.com/Nebulit-GmbH/agentic-engineer at commit `07b0f30648d663cb588d7e2c7aa031af9dfc21f2`,
-by Martin Dilger and Nebulit GmbH (https://nebulit.de). The repository carries no licence file; this material
-is adapted with the agreement of Martin Dilger and Nebulit GmbH.
+by Martin Dilger and Nebulit GmbH (https://nebulit.de), used with the explicit consent of Martin Dilger and Nebulit GmbH.
 
 | Source file | Used in | How |
 |---|---|---|
@@ -36,6 +35,8 @@ is adapted with the agreement of Martin Dilger and Nebulit GmbH.
 | same: essential fields only, no padding, payload-free simple transitions (lines 159-160) | `SKILL.md` step 6, `references/storming-loop.md` | now adapted closely; identity, concepts and `@pii` rules kept |
 | same: handover from an outside party is a single moment, not a relocation | `SKILL.md` Modeling defaults | idea; our own wording kept |
 | `.claude/skills/eventmodeling-storyboarding-events/SKILL.md`: "whose turn is it in the story?" (consistent actor perspective) | `references/plotting-and-handoff.md` "Whose turn is it in the story?" | adapted closely; lanes, columns and screen placement not adopted |
+| `.claude/skills/eventmodeling-brainstorming-events/SKILL.md`: Domain Analysis document (roles, entities, processes, candidate events, rules, questions), "Questions for Domain Expert", "Best Practices for Requirements Analysis", quality checklist | `references/domain-analysis-template.md` | Adapted closely as an optional work record in `.ai-work/screenplay/`; roles use Does/Reads/Cannot, chapters, cells, swimlane rules and `meta.fields` dropped, "all error conditions have events" replaced by the refusal-versus-fact question |
+| `.claude/skills/eventmodeling-core-rules/SKILL.md`: Offline-First Thinking | `references/divergent-sweep.md` lens "Without software" | Promoted to a named lens; our own wording |
 
 Not adopted: board, chapter, column and `place-element` mechanics; the board API and `connect` skill.
 

package/package/corpus/skills/cratis-screenplay-discovery/verification.json

@@ -11,7 +11,7 @@
     { "kind": "skill-contains", "value": "what can happen next *instead*" },
     { "kind": "skill-contains", "value": "No generic edit event or command name" },
     { "kind": "skill-contains", "value": "V2 to V5 are not run in discovery" },
-    { "kind": "skill-contains", "value": "`description` text is never rendered" },
+    { "kind": "skill-contains", "value": "`description` text reaches code only as XML doc comments" },
     { "kind": "skill-contains", "value": "do not ask questions whose answers you" },
     { "kind": "skill-contains", "value": "Storyline" },
     { "kind": "skill-contains", "value": "do not pad events with fields just to reach a count" },

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

@@ -5,5 +5,5 @@ Licensed under the MIT license. See LICENSE file in the project root for full li
 
 This skill adapts material from agentic-engineer by Martin Dilger and Nebulit GmbH
 (https://github.com/Nebulit-GmbH/agentic-engineer, commit 07b0f30648d663cb588d7e2c7aa031af9dfc21f2;
-https://nebulit.de), used with the agreement of Martin Dilger and Nebulit GmbH. That repository
-carries no licence file; the adapted material remains credited to Martin Dilger and Nebulit GmbH.
+https://nebulit.de), used with the explicit consent of Martin Dilger and Nebulit GmbH. The adapted
+material remains credited to Martin Dilger and Nebulit GmbH.

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

@@ -73,6 +73,7 @@ at the phase where they belong and run the downstream gates for the changed scop
 | Existing system into a model (replaces P1-P2) | `cratis-screenplay-legacy-extraction` |
 | P7-P9 execute, render, fall back, verify | `cratis-screenplay-render-and-gap-fill` |
 | Tools, versions, verdict commands, diagnostics | `cratis-screenplay-toolchain` |
+| Estimate, order or split delivery of an accepted model | `cratis-screenplay-delivery-planning` |
 
 **4. Nine steps to phase skill.** [references/nine-steps.md](references/nine-steps.md)
 keeps the activities, Screenplay output and facilitation questions of each step:
@@ -107,9 +108,12 @@ is the fallback, and neither names the other's verdict. Versions and commands:
 - [ ] 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, check it binds with the tool that will
-      consume it. The standalone 4.68.0 binder admits Automation and Translate slices
-      (ESM v6) and generated values and responses (ESM v7); Stage 4.24.0 admits ESM v1 to v3 (4.24.2: v1 to v4, evolved events refused with `STAGE-ESM-026`) and renders only `StateChange` and
-      `StateView` slices, so automations and translations are gap-fill there.
+      consume it. Current pins: `cratis-screenplay-toolchain` `references/versions.md`. Stage 4.73.1
+      (in CLI 3.53.1) admits ESM v1 to v10 by version and renders `StateChange` and `StateView`
+      slices; reactions, captures, Automation and Translate, and the v7+ constructs in Stage's
+      admission table refuse with their own `STAGE-ESM-*` code, so those scopes are gap-fill with
+      the model as the contract. A reaction that produces events and invokes commands is refused
+      (`STAGE-ESM-037`) although Arc 22.72.0 and later can run it (the Stage scaffold's Arc 22.68.0 needs a proven override): hand-write it as one reactor, never split the modeled reaction.
 
 ## Parsed is not runnable
 
@@ -124,10 +128,9 @@ The independent verdicts V1 to V5 that report them are in
 
 What binds depends on **which tool** you ask, so name the tool and its version:
 
-- `Automation` and `Translate` slices, reactions, captures and triggers: the
-  standalone `screenplay` 4.66.0 or later and the `cratis` 3.28.2 bundle (4.66.0) bind them (ESM v6).
-  The `cratis` 3.27.1 bundle (Screenplay 4.60.1) reported *Slice '<name>' of type '<type>'
-  is not admitted by ESM v1.* Stage 4.24.2 admits only ESM v1 to v4 and renders none of them.
+- `Automation` and `Translate` slices, reactions, captures and triggers bind (ESM v6) on the
+  standalone tool and the CLI bundle. (Historical: the cratis 3.27.1 bundle, Screenplay 4.60.1,
+  reported *Slice '<name>' of type '<type>' is not admitted by ESM v1.*) Stage 4.73.1 renders none of them.
 - `reads` and `concurrency` on a command do not bind (`PLAY0271`), so no decision is
   protected against stale state. A reaction trigger's `reads` that only `invokes` is
   report-only intent (`PLAY0270`); one that `produces` directly fails binding (`PLAY0268`).
@@ -135,12 +138,14 @@ What binds depends on **which tool** you ask, so name the tool and its version:
   concepts do block binding (`PLAY0268`). Keep them anyway: the classification is
   part of the model. Report the block.
 - Generated values/responses bind and reference-execute as v7; sources, streams
-  and command/specification routes as v8; reaction `runs as` identity as v10 on
-  standalone 4.125.0. Use `screenplay test` or MCP `run-specifications` for V4.
-  Operations/systems, exact numbers and refusal/redelivery remain unadmitted.
-  Historical CLI 3.41.0 rejected `runs as` syntax and its Stage 4.51.3 check
-  refused generated values/responses with STAGE-ESM-028/029. CLI 3.50.0 bundles
-  Screenplay 4.131.0/Stage 4.67.0; v10 reaches construct admission, not full support.
+  and command/specification routes as v8; reaction `runs as` identity as v10;
+  qualifying Double literals lower exactly as v11 and non-positional enum numbers
+  as v12. Use `screenplay test` or MCP `run-specifications` for V4.
+  Operations/systems, the `numbers exact` **source mode** (PLAY0268) and
+  refusal/redelivery remain unadmitted. Stage still refuses generated values and
+  responses (`STAGE-ESM-028`/`029`). For the pinned CLI/Stage pair
+  (`cratis-screenplay-toolchain/references/versions.md`), v10 reaches construct
+  admission, not full support.
   Source/binding admission and target realization are separate gates.
 
 The ESM versions, the full disposition table and the Step 7 clock example's binding
@@ -166,21 +171,17 @@ source is the single flow model.
 
 ## Verified product sources
 
-| Package | Version | Purpose |
-| --- | --- | --- |
-| `Cratis.Screenplay` | `4.31.0` | Compiler: parser, validator, diagnostics, folder merge, semantic binder |
-| `Cratis.Screenplay.Tool` | `4.31.0` | The `screenplay` dotnet tool |
-| `Cratis.Screenplay` | main `fd18129` | Inline contracts and event context; changed nine-step examples compiled |
-| `Cratis.Screenplay.Tool` | `4.68.0` (`79801bf`) | Checked at 4.68.0 (current pins in `cratis-screenplay-toolchain` `references/versions.md`): the nine-step examples compile and their specifications run in the reference runner; generated values and responses (ESM v7) were read at this tag |
-| `Cratis.Screenplay.Tool` | `4.66.0` (`c89198b`) | Persona, operation and stream dispositions below were read at this tag, and the Step 7 clock example was probed through MCP on it |
-
-The pin set for the whole Screenplay family, and which tool reports what, lives only in
-`cratis-screenplay-toolchain` `references/versions.md`. Read `cratis-screenplay-toolchain`'s `references/versions.md` before choosing a tool or reporting a version-dependent verdict. The `fd18129` update follows
-`commands.md`, `events.md` and decision 0023 at that main commit (after v4.52.0);
-compilation does not establish reference execution. The original baseline was checked at
-tag `v4.31.0` (commit `355dffb`): `Documentation/screenplay/{slices,commands,folders,printing,interactions,specifications}.md`,
-`projections/keys.md`, and decisions 0001 to 0014. Changed [nine-step examples](references/nine-steps.md)
-use the newer commit and the 4.66.0 and 4.68.0 tools; do not attribute them to the old tag.
+Current pins and which tool reports what live only in `cratis-screenplay-toolchain`
+`references/versions.md`; read it before choosing a tool or reporting a version-dependent verdict.
+The nine-step examples compile with the standalone compiler 4.139.0 and their specifications run
+in the reference runner (compilation does not establish reference execution).
+
+Historical provenance (not current pins): the original baseline was read at Screenplay tag
+`v4.31.0` (commit `355dffb`: `Documentation/screenplay/{slices,commands,folders,printing,interactions,specifications}.md`,
+`projections/keys.md`, decisions 0001 to 0014); the inline-contract and event-context changes
+follow `commands.md`, `events.md` and decision 0023 at main `fd18129` (after v4.52.0); persona,
+operation and stream dispositions were read at `v4.66.0` (`c89198b`) and generated values and
+responses at `v4.68.0`.
 
 Read [references/slice-type-rules.md](references/slice-type-rules.md) when deciding if a behavior is an Automation or a Translate slice.
 
@@ -231,7 +232,7 @@ 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> [as <alias>] [by <property>]` so the
   model shows what a state-dependent decision consulted. **It is not a protected
-  read at Screenplay 4.68.0:** nothing checks at append time that the state is still current,
+  at Screenplay 4.139.0 (Screenplay#129 open):** 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).
   Write a state-dependent rule as `reads <View>` plus `require <expr> message "..."`

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

@@ -198,9 +198,11 @@ system state?"* If no, it is co-production — one `StateChange` slice with seve
 `produces` blocks, not an `Automation` slice.
 
 **Output:** the `reaction`, in an `Automation` slice. It binds on the standalone
-`screenplay` 4.66.0 and the `cratis` 3.28.2 bundle (ESM v6; the 3.27.1 bundle rejected the slice
-at binding) and Stage 4.24.2 renders none, so the automation is gap-fill there (versions:
-`cratis-screenplay-toolchain`). When the automation decides from a view, declare it under
+`screenplay` and the `cratis` bundle (ESM v6; the 3.27.1 bundle rejected the slice at binding) and
+Stage 4.73.1 renders none, so the automation is gap-fill there (versions:
+`cratis-screenplay-toolchain`). A reaction that `produces` and `invokes` stays one reaction: Stage
+refuses it (`STAGE-ESM-037`) but Arc 22.72.0 and later run it as one reactor (events first, then
+commands; no cross-effect transaction; the Stage scaffold's Arc 22.68.0 needs a proven override), so gap-fill it whole, never split it. When the automation decides from a view, declare it under
 the trigger with `reads` (see `cratis-screenplay-captures-and-reactions`).
 
 The example below is a complete document: a Monday-morning clock occurrence invokes a command
@@ -211,7 +213,7 @@ event source, so the invoked command binds its own identifier (`weekly`).
 
 **What the model does and does not do.** The view stores the deadline (`dueDate`), never an
 "overdue" flag: overdue is a comparison with the clock, not a fact to materialize. The
-reaction's `reads UnpaidInvoice` is report-only metadata at 4.66.0 (information `PLAY0270`);
+reaction's `reads UnpaidInvoice` is report-only metadata (information `PLAY0270`, checked at 4.139.0);
 it does not make the model consult the view. Binding therefore admits only a scheduled
 invocation that records a timestamp. Choosing which invoices are overdue (due date before the
 clock instant) is a target-side decision: record it as gap-fill with the model as the
@@ -277,7 +279,7 @@ module Invoicing
           issuedAt = "2026-10-05T07:30:00Z"
 ```
 
-At the example's verified Screenplay 4.66.0 version, iterating the overdue items needs code (a clock trigger reads the whole view and takes
+At the example's verified Screenplay version (4.139.0), iterating the overdue items needs code (a clock trigger reads the whole view and takes
 no `by`); see `cratis-screenplay-automations-and-translations`. A reaction that `produces`
 directly while it `reads` fails binding (`PLAY0268`): decide in a command instead.
 

package/package/corpus/skills/cratis-screenplay-event-modeling/references/parsed-not-runnable.md

@@ -1,8 +1,9 @@
 # Parsed is not runnable: ESM versions and dispositions
 
-Checked at Screenplay v4.125.0: `SemanticModelBinder.cs`, `Versions.cs`,
-`Documentation/screenplay/{commands,operations,event-sources,reactions,tool}.md`.
-The binder selects v8 for event routes and v10 for declared reaction identity.
+Checked at Screenplay v4.139.0: `SemanticModelBinder.cs`, `Versions.cs`,
+`Documentation/screenplay/{commands,operations,event-sources,reactions,tool,interoperability}.md`.
+The binder selects v8 for event routes, v10 for declared reaction identity, v11 for retained
+exact-lowered Double-mode literals and v12 for non-positional enum numbers.
 Pins and consumer boundaries: toolchain `references/versions.md`.
 
 ## Which ESM version a model needs
@@ -14,12 +15,14 @@ Pins and consumer boundaries: toolchain `references/versions.md`.
 - v7 for generated command values, responses, fixtures/return assertions and policy negation.
 - v8 for sources/streams and command/specification routes.
 - v9 for public-event contracts; v10 for reaction `runs as system` identity.
-- Operations/systems, exact numeric mode and refusal/redelivery remain unadmitted
-  (PLAY0268). Version allocation is not inferred from an older planning decision.
+- v11 for exact lowering of qualifying Double-mode number literals; v12 for non-positional
+  enum member numbers (`cratis-screenplay-command-surface` `references/enum-numbers.md`).
+- Operations/systems, the exact numeric **source mode** (`numbers exact`) and refusal/redelivery
+  remain unadmitted (PLAY0268). Version allocation is not inferred from an older planning decision.
 
 ## Dispositions to keep apart
 
-| Construct | Standalone disposition (checked at v4.125.0) |
+| Construct | Standalone disposition (checked at v4.125.0; v4.139.0 unchanged for these rows) |
 | --- | --- |
 | `persona`, domain/authentication metadata | Report-only; unknown named policies remain source defects |
 | Compliance concepts | Bare `pii`/`secret` (4.127.0); binding still refuses PLAY0268, never remove protection |
@@ -27,10 +30,10 @@ Pins and consumer boundaries: toolchain `references/versions.md`.
 | Composite stream ids | v8 routing; complete named parts/canonical comparisons, PLAY0515 refuses protected keys/sources; not a legacy text split |
 | Command reads/concurrency | Legacy unprotected decisions, PLAY0271 |
 | Invokes-only trigger reads | Report-only, not protected state; direct production with reads refuses |
-| Generated values/responses | v7 binding/reference execution; historical Stage 4.51.3 check: member refusals STAGE-ESM-028/029 |
-| Sources/streams and command/specification routes | v8 binding/reference execution; CLI 3.50.0 reaches Stage construct checks through v10 |
+| Generated values/responses | v7 binding/reference execution; Stage 4.73.1 member refusals STAGE-ESM-028/029 |
+| Sources/streams and command/specification routes | v8 binding/reference execution; the pinned CLI (toolchain `references/versions.md`) reaches Stage checks through v10 |
 | Declared reaction invocation actor | v10 binding/reference execution; older CLI parser PLAY0137; Stage planner refuses v10 |
-| Operations/systems, exact numbers, refusal/redelivery | Source accepted; whole binding refuses PLAY0268 |
+| Operations/systems, `numbers exact` source mode, refusal/redelivery | Source accepted; whole binding refuses PLAY0268 |
 | UI | Authoring/deferred metadata; runtime support is a separate consumer contract |
 
 Run standalone `screenplay test` or MCP `run-specifications` for V4. Compile
@@ -42,7 +45,7 @@ and captures-and-reactions `references/invocation-identity.md`.
 ## The Step 7 clock example
 
 The complete example in [nine-steps.md](nine-steps.md) (Step 7) had historical
-4.66.0 compile/binding evidence (zero errors/warnings, executableReady true).
+4.66.0 compile/binding evidence (re-compiled at 4.139.0) (zero errors/warnings, executableReady true).
 Its invokes-only reads still record intent rather than execute the overdue
 selection. Run its admitted specifications with the current reference route
 before claiming a V4 pass; no overdue-selection proof follows from binding.