@cratis/pi 7.33.0 → 7.34.1

package/package/corpus/skills/cratis-screenplay-automations-and-translations/references/automation-patterns.md

@@ -12,8 +12,8 @@
 - 8. Chain completion checkpoint
 - 9. Fan-out
 
-Complete compiled example: `todo-list-example.md` (binds on Screenplay 4.66.0; the list query
-and retry sweep that do not bind are shown there as marked excerpts).
+Complete compiled example: `todo-list-example.md` (binds on Screenplay 4.66.0 and later; the list query
+excerpt binds too, and the retry sweep that needs code is shown as a marked excerpt).
 
 ## 1. Deciding whether it is an automation
 Write the four parts in one line each:
@@ -44,12 +44,12 @@ Outcomes:
 - A projection that adds an item `from <OpeningFact>` and removes it with
   `remove with <ClosingFact>`. Several facts may open or close; they need not match one to one.
 - A keyed query (`…ById => Item optional` + `by itemId`) for specs and executable scope; a
-  list query for the visible queue (design-only: a list query reports PLAY0268 at binding on 4.66.0).
+  list query for the visible queue (`=> Item[]` binds since Screenplay 4.105.0; a snapshot list is refused by Stage, `STAGE-ESM-010`).
 - A reaction `when <OpeningFact>` that invokes the command producing the closing fact.
   The trigger may `reads` the item view to document its input; that is not protection.
 - A retry sweep on a clock reads the whole view (no `by` on clock reads). Iterating its items
-  declaratively (`for each <View>`) is reserved syntax; on Screenplay 4.66.0 the sweep needs a code body,
-  which the reference never runs. Durable fan-out is outside Screenplay 4.66.0 (Screenplay#286).
+  declaratively (`for each <View>`) is reserved syntax; at Screenplay 4.139.0 the sweep needs a code body,
+  which the reference never runs. Durable fan-out is outside the language (Screenplay#286).
 - Specify the list as a small story: empty -> item present (`then query …ById`) -> closed
   (`when append <Closing>` + `then no readmodel … for`), plus "not opened" for facts that
   must not queue work.

package/package/corpus/skills/cratis-screenplay-automations-and-translations/references/effects-and-idempotency.md

@@ -59,7 +59,7 @@ See "Effect guarantees and recovery traps" in SKILL.md.
 - A capture spec does not acknowledge the source or store a new last-seen record; prefix
   facts that were accepted do not mean the record was processed (Screenplay `captures.md`).
   Record how the target acknowledges.
-- Delivery guarantees, acknowledgements and durable fan-out are outside Screenplay 4.66.0 (Screenplay#286);
+- Delivery guarantees, acknowledgements and durable fan-out are outside the language (Screenplay#286);
   never describe them as provided.
 
 ## Projection lag and rebuild

package/package/corpus/skills/cratis-screenplay-automations-and-translations/references/provenance.md

@@ -15,11 +15,10 @@ defaults for missing data) is replaced by "never fabricate a default"; its log-a
 handling is replaced by recorded failure facts. `plugins/trogonstack-eda` was skimmed; nothing
 adopted.
 
-## 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 |
 |---|---|---|

package/package/corpus/skills/cratis-screenplay-automations-and-translations/references/public-events-and-direction.md

@@ -123,8 +123,7 @@ Keep correlation and resulting private events in the model and report the runtim
 ESM v9 shipped in Screenplay 4.117.0 and is selected only by use of public events,
 origins, direction, event-target builders or events-source captures. At 4.135.0,
 publication reference scenarios execute; imported shapes still refuse binding.
-Stage 4.52.0 (previous CLI 3.46.1) audits only through v7: CLI-RENDER-004 precedes
-its STAGE-ESM-016 version refusal. The pinned CLI/Stage pair (toolchain `references/versions.md`)
+Stage 4.52.0 (previous CLI 3.46.1, history) audited only through v7. The pinned CLI/Stage pair (toolchain `references/versions.md`)
 reaches construct admission through v10 but still refuses publication (STAGE-ESM-032), foreign
 events/events-source captures (STAGE-ESM-033); source admission is not rendering.
 

package/package/corpus/skills/cratis-screenplay-automations-and-translations/references/realization-and-gap-fill.md

@@ -5,11 +5,15 @@ the automation-and-translation addendum to `cratis-screenplay-render-and-gap-fil
 skill for the admission, publication and ownership rules.
 
 ## What Stage does not do
-Stage 4.24.2 renders no Automation or Translate slice (Stage#79). A model that contains one is not
-admitted: it needs ESM v6, and Stage admits ESM v1 to v4 (STAGE-ESM-016 for the whole model; probed
-with `cratis render` 3.28.2 and 3.28.3, whose bundled compiler binds these slices, where 3.27.1 stopped earlier
-with PLAY0268). So the automation or translation is
-hand-written delivery with the model as its contract. A `Customizations/` file never makes a
+Stage 4.73.1 renders no Automation or Translate slice, reaction or capture (Stage#79): each reaction
+or capture refuses with `STAGE-ESM-024` (plus `-034` runsAs, `-035` filters, `-037` mixed effects). So the
+automation or translation is hand-written delivery with the model as its contract. (History: cratis
+3.28.2 and 3.28.3 refused such a model whole with `STAGE-ESM-016`, and 3.27.1 stopped earlier with PLAY0268.)
+
+A reaction that both `produces` events and `invokes` commands stays one modeled reaction. Hand-write one
+reactor that returns the events and the commands: Arc 22.72.0 and later append the events first as one
+batch, then run the commands in order, with no transaction across them (a retry can repeat both, so keep
+both repeatable); the Arc the Stage scaffold pins (see `cratis-stage-rendering-and-sandbox` `references/rendered-application.md`) accepts a collection in a command handler only when every element is a command, so a rendered app needs a proven dependency override to Arc 22.72.0 or later. Never split the reaction to dodge `STAGE-ESM-037`. A `Customizations/` file never makes a
 rejected model renderable, and never claim a whole-application V5 from a subset. Choose the route
 with `cratis-screenplay-render-and-gap-fill`.
 

package/package/corpus/skills/cratis-screenplay-automations-and-translations/references/todo-list-example.md

@@ -6,7 +6,7 @@
 
 A complete model: a result opens a work item, a reaction invokes a command, the command's fact
 closes the item. It binds on Screenplay 4.66.0 (`executableReady: true`), standalone and through `cratis screenplay mcp`
-3.28.2; `cratis render` 3.28.2 refuses it whole (`STAGE-ESM-016`). The cratis 3.27.1 bundle (4.60.1)
+3.28.2; `cratis render` refuses the Automation slice (3.28.2: whole, `STAGE-ESM-016`; Stage 4.73.1: `STAGE-ESM-024`). The cratis 3.27.1 bundle (4.60.1)
 rejected the Automation slice at binding with PLAY0268. Versions: `cratis-screenplay-toolchain` `references/versions.md`.
 
 The first spec lists the whole cascade (`then` names every new fact: `CoursePassed`, and
@@ -190,10 +190,10 @@ module Certification
 
 ## Design-only additions
 
-Two things a real queue often wants do not bind on 4.66.0 and stay out of the complete model
-above: a list query (the visible queue) and a retry sweep that reads the whole view. Both parse
-(V1) and report PLAY0268 at binding; durable per-item fan-out is outside the language
-(Screenplay#286). Keep them in the model only when the document is the deliverable and say so
+Two things a real queue often wants stay out of the complete model above: a list query (the
+visible queue) and a retry sweep that reads the whole view. The list query binds (Screenplay 4.105.0
+or later; it was PLAY0268 at 4.66.0, and Stage refuses a snapshot list); the sweep needs a code body the
+reference does not run, and durable per-item fan-out is outside the language (Screenplay#286). Say so
 in the verdict.
 
 ```screenplay excerpt parent=assets/pending-certificates.play
@@ -205,7 +205,7 @@ query PendingCertificates => PendingCertificate[]
 // Parent: the complete document above, slice Automation SendCertificates, after CertificateSender.
 // The sweep reads the whole view (a clock trigger takes no `by`); iterating items needs code.
 reaction CertificateRetrySweep
-  description "Retries items still pending; per-item fan-out needs code on Screenplay 4.66.0 (#286)"
+  description "Retries items still pending; per-item fan-out needs code (#286)"
   every 15 minutes
     reads PendingCertificate
     file Reactions/RetryPendingCertificates.cs

package/package/corpus/skills/cratis-screenplay-automations-and-translations/references/translate-example.md

@@ -4,7 +4,7 @@ A complete model: a webhook record from an outside proctoring service is capture
 external fact in the provider's vocabulary, then translated by reactions into our facts. It
 binds on Screenplay 4.66.0 (`executableReady: true`), standalone and through `cratis screenplay mcp`
 3.28.2; the cratis 3.27.1 bundle (Screenplay 4.60.1) compiled it (V1) but rejected the Translate
-slice at binding (PLAY0268). `cratis render` 3.28.2 refuses it whole (`STAGE-ESM-016`).
+slice at binding (PLAY0268). `cratis render` refuses it (3.28.2: whole, `STAGE-ESM-016`; Stage 4.73.1: `STAGE-ESM-024`).
 
 Read the slice `description`: it is the per-field disposition (map, translate, ignore) and it
 states what this example does not do. Examples never show the whole integration contract; use

package/package/corpus/skills/cratis-screenplay-captures-and-reactions/SKILL.md

@@ -36,16 +36,15 @@ decides, not the slice type:
   `Translate` slices, reactions, declared triggers and captures bind, and the
   reference runner executes them. Probed: the complete example below is
   `executableReady` over `screenplay mcp`.
-- **Historical CLI 3.28.2 / Screenplay 4.66.0 probe:** complete examples validated
-  and were executableReady through MCP. Earlier 4.60.1 bundles refused v6 at
-  binding and falsely reported PLAY0285 on cascades. Toolchain `references/versions.md`
-  separates that history from current pins.
-- **Stage 4.24.2** admits ESM v1-v4 and renders no `Automation` or `Translate`
-  slice. The automation is gap-fill, with the `.play` slice and its specifications
-  as the contract: `cratis-screenplay-render-and-gap-fill`.
+- **History:** the CLI 3.28.2 bundle (Screenplay 4.66.0) bound v6; the earlier 4.60.1 bundles
+  refused it and falsely reported PLAY0285 (`references/versions.md`).
+- **Stage 4.73.1** admits ESM v1-v10 by version but renders no `Automation`, `Translate`, reaction or
+  capture (`STAGE-ESM-024`; `-037` for a reaction that produces and invokes, which Arc 22.72.0+
+  runs as one reactor; scaffold Arc needs override). The automation is gap-fill; the `.play` slice and its specifications
+  are the contract: `cratis-screenplay-render-and-gap-fill`.
 
 Model them whenever the `.play` file is the deliverable, and say which tool bound
-them. Read `cratis-screenplay-toolchain` (`references/versions.md`) when selecting a compiler version or interpreting version-dependent messages.
+them (`cratis-screenplay-toolchain` `references/versions.md` for versions and messages).
 Method (the four-part automation test, loops, translations versus automations):
 `cratis-screenplay-automations-and-translations`.
 
@@ -123,7 +122,8 @@ Read [references/capture-map-and-example.md](references/capture-map-and-example.
 `api` (`api`, `route`, `poll`), `webhook` (`path`) and `message` (`topic`).
 ⚠️ The grammar is **open** — the parser accepts any kind and any setting name as
 free-form name/value pairs, so a typo is not caught. The three kinds are
-convention, not enforcement.
+convention, not enforcement. `source events` (`from <Event>` lines, ESM v9) is the exception, with
+its own closed grammar (PLAY0610/0612/0616/0619/0620).
 
 **`key <property>`** names the source property identifying an instance. From ESM v6
 a capture without a `key` does not bind (`PLAY0268`). In a specification the
@@ -131,9 +131,9 @@ reference is handed records (`given capture`, `when capture`) and never contacts
 `source`, which stays realization metadata; events append to the event source the
 record's `key` names, and `$context.occurred` is the scenario's `given clock`.
 
-Declaring an event's external origin on the `event` itself is accepted as
-Screenplay decision 0009 but **not in the language**; a `capture` in a
-`Translate` slice is how outside data enters a model in the verified Screenplay versions.
+An event's external origin is declared on the `event` itself with `event X from "<origin>"` (ESM v9);
+outside records still enter through a `capture` in a `Translate` slice
+(`cratis-screenplay-automations-and-translations` `references/public-events-and-direction.md`).
 
 **`map`** reshapes properties before events are appended (rename, template, `translate`, `split`; mapping sources are `$.`, `$context.` and `$env.`); syntax is in the reference file linked above.
 
@@ -297,7 +297,8 @@ open. The type on a value is optional; a bare name is already a useful statement
 the document declares → triggers registered with the compiler, plus the built-in
 host signals. A registration wins over a built-in of the same name. Only when all
 three miss is the name reported unknown — a **warning** (`PLAY0248`), because the
-name may be known outside the document. A malformed reaction body is an error.
+name may be known outside the document. A malformed reaction body is an error. If an event
+and a trigger share a name, the event wins for value validation and binding.
 
 **Built-in triggers:** `Startup` and `Shutdown`. The clock is built in too, but
 with its own syntax rather than a name.

package/package/corpus/skills/cratis-screenplay-command-surface/SKILL.md

@@ -26,17 +26,14 @@ source is the single flow model.
 
 ## Verified product sources
 
-| Package | Version | Purpose |
-| --- | --- | --- |
-| `Cratis.Screenplay` | `4.31.0` | Original examples and executable boundaries |
-| `Cratis.Screenplay` | main `fd18129` | Inline events, repairs and canonical `optional`; changed examples compiled |
-| `Cratis.Screenplay` | `4.66.0` (`c89198b`) | Binding behaviour of `handler`, code attachments, `persona` and compliance attributes: `Semantics/SemanticModelBinder*.cs`, `Diagnostics/DiagnosticCodes.cs` |
-| `Cratis.Screenplay` | `4.68.0` (`79801bf`) | Historical generated-value/response rule probes (ESM v7) |
-| `Cratis.Screenplay` (historical check) | `4.127.0` | Identity and compliance guidance checked at this release: released `identity.md`, `context.md`, `concepts.md`, `purposes.md`, `events.md`, `diagnostics.md`; changed examples compiled |
+Current pins: toolchain `references/versions.md`; the claims here were read at 4.139.0 and at
+the older tags below (provenance). Compilation checks syntax and
+model consistency, not reference execution.
 
-Historical examples/probes retain the table's original versions; current source
-guidance is not a relabeled old execution result. Compilation checks syntax and
-model consistency, not reference execution. Pins: toolchain `references/versions.md`.
+- `4.31.0`: original examples and executable boundaries; main `fd18129`: inline events, repairs, canonical `optional`.
+- `4.66.0` (`c89198b`): `handler`, code attachments, `persona` and compliance binding (`Semantics/SemanticModelBinder*.cs`, `Diagnostics/DiagnosticCodes.cs`).
+- `4.68.0` (`79801bf`): generated-value/response rule probes (ESM v7).
+- `4.127.0`: identity and compliance guidance (`identity.md`, `context.md`, `concepts.md`, `purposes.md`, `events.md`, `diagnostics.md`).
 
 "Parses" and "runs" are different claims. The executable profile, and what
 each construct binds to, is in the `cratis-screenplay-model-authoring` language
@@ -173,7 +170,8 @@ When a rule depends on state:
 - otherwise state the rule, and say in review that the target implementation
   must enforce it consistently. Do not claim the model guarantees it.
 
-Do not use `reads` to fetch data the caller could supply.
+Do not use `reads` to fetch data the caller could supply. A composite-key view's `by` block is
+`PLAY0268` (#599; read-surface `references/named-keys.md`).
 
 ## `validate`
 
@@ -242,7 +240,7 @@ choosing or omitting `for` on a production, or fixing `PLAY0469`-`PLAY0478`.
   computed expressions parse but block binding (`PLAY0268`).
 - **`for <identifier>`** on an indented line names the event source the event is
   appended to. At most one per `produces`. To bind, it must name the command's
-  `identifier` property (`PLAY0273` otherwise); fanning out to another event
+  `identifier` property (`PLAY0273` otherwise; a `generated identifier` command, ESM v7, may name another required scalar property); fanning out to another event
   source parses but does not run today.
 - **`tag`** lines apply literal tags to this append. Tags also exist on the
   `event` declaration, where they apply to every append of that type.
@@ -341,7 +339,8 @@ constraint OneRegistrationPerInvoice
 hand-written Chronicle `IConstraint`, which can only declare uniqueness; it warns
 (`PLAY0396`) and the executable model rejects it. A state transition rule
 belongs in `validate`/`require`. Use a constraint when two concurrent appends must
-not both win — a `validate` rule cannot do that.
+not both win — a `validate` rule cannot do that. Stage renders only single-text-property and
+`unique event` constraints (`STAGE-ESM-014`; `cratis-stage-rendering-and-sandbox` `references/admission.md`).
 
 ## `policy` and `persona`
 

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

@@ -70,7 +70,9 @@ Reverse generation is not the C# provider mapping above. Source authority: Arc
 `v22.70.0:Documentation/backend/csharp/generating-a-screenplay.md` (Operational
 secrets), `Source/DotNET/Screenplay/Emission/Concepts/ConceptSyntaxBuilder.cs`
 and `Source/DotNET/Screenplay/Analysis/Types/PersonalDataMarkings.cs`.
-Check the generator package actually loaded; the CLI's bundle may be older.
+SP0058 to SP0060 exist from Arc.Screenplay 22.61.0 (or earlier); SP0061 to SP0063 first ship in 22.70.0 (read at
+v22.70.0 and v22.72.0), so the full set described here needs 22.70.0 or later. CLI 3.53.1 bundles an Arc.Screenplay older than that (its version is in `cratis-screenplay-toolchain` `references/versions.md`), which has
+none of SP0061 to SP0063, so the CLI shows none of them; check the generator package actually loaded.
 
 - Both `[Encrypted]` and `[NotAudited]` must be on the concept to recover
   `secret`. Partial or member-specific markings report SP0058 (Information),

package/package/corpus/skills/cratis-screenplay-command-surface/references/generated-values-and-responses.md

@@ -3,8 +3,8 @@
 A `generated` command property and `returns` response bind and reference-execute
 as ESM v7 (checked at 4.68.0). Current pins:
 `cratis-screenplay-toolchain/references/versions.md`. CLI#261 is closed: CLI now admits v7
-to Stage planning. The historical CLI 3.41.0 v7 canonical corpus received Stage
-generated-value and response refusals STAGE-ESM-028/029. Do not turn this into a blanket compiler
+to Stage planning, and the 4.137.0 compiler in CLI 3.53.1 binds it. Stage 4.73.1 still refuses
+generated values and responses with STAGE-ESM-028/029 (Stage#175), as the historical CLI 3.41.0 corpus did. Do not turn this into a blanket compiler
 refusal or promise a render from binding alone. Preserve the contract for gap-fill
 where admission refuses. Historical rules below were read at 4.68.0. Complete compiled example:
 `cratis-screenplay-toolchain` `references/generated-responses-example.md`.

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

@@ -32,5 +32,7 @@ A bodied rule or fenced block on a validation, rule or policy binds as opaque co
 implementation. Two exceptions never bind: the command `handler`, and a `file`
 constraint (the binder records the requirement, then rejects it with `PLAY0268`;
 only `unique` constraints bind).
-Stage 4.24 admits only pure reducer bodies, so such a body is gap-fill code there. Prefer a
-declarative rule when one can say it.
+Stage 4.73.1 renders pure reducer transitions and opaque policy bodies, but refuses command and
+concept code validations and rule predicates (STAGE-ESM-005): those are gap-fill code. Prefer a
+declarative rule when one can say it. What binds and what the executable model rejects (Date and
+DateTime comparisons, nested-path rules): `cratis-screenplay-toolchain` `references/executable-subset.md`.

package/package/corpus/skills/cratis-screenplay-delivery-planning/LICENSE

@@ -0,0 +1,9 @@
+Copyright (c) Cratis. All rights reserved.
+Licensed under the MIT license. See LICENSE file in the canonical Cratis/AI repository for the full license text.
+
+## Third-party notices
+
+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 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-delivery-planning/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: cratis-screenplay-delivery-planning
+description: "Plan and estimate the delivery of an accepted Screenplay model by slices: count slices by type (StateChange, StateView, Automation, Translate), derive the slice dependency table from the model, split work in parallel along event contracts, track slice groups as GitHub issues with a closed status vocabulary, and turn the team's own completed-slice history into ranged estimates, capacity math and retrospective metrics. Use when asked how long a modeled scope will take, how to split it across people or agents, what to build first, or how to track and re-plan delivery. Not for: deciding what to model (use `cratis-screenplay-event-modeling`), rendering or gap-filling a slice (use `cratis-screenplay-render-and-gap-fill`), or reviewing the model (use `cratis-screenplay-model-review`)."
+license: MIT
+---
+
+# Delivery planning
+
+## Purpose
+Turn an accepted `.play` model into a delivery plan: how many slices of which type, in which
+order, who can work in parallel, what each group costs, and when it is done. The model already
+cuts the work into slices and names the events between them, so the plan counts and orders
+those slices instead of guessing at features.
+
+Planning does not replace modeling, review or the render and gap-fill gates. A plan is a
+working note, not a contract: when the model changes, recount; when a slice is not accepted,
+it is not planned work yet.
+
+## Ground rules
+- **Count slices, not features.** The unit is one slice of one type
+  (`StateChange`, `StateView`, `Automation`, `Translate`). Method and weights:
+  `references/slice-counting.md`.
+- **Estimates are ranges from the team's own history.** State the basis (which completed slices,
+  how many, how long). With no history the estimate is a *first estimate without history*:
+  say so, give a wide range, and replace it as soon as slices complete. Never quote an accuracy
+  figure or a duration you cannot trace to a count and a rate.
+- **Events are the contract.** Slice B depends on slice A because B needs an event or view A
+  produces. Anyone can build B against the events A will produce, with synthetic `given`
+  events, before A is finished. Dependencies are read from the model, not remembered.
+- **Render is not free of effort, and gap-fill is not free of risk.** Stage renders
+  `StateChange` and `StateView`; `Automation` and `Translate` are hand-written against the
+  model as contract. Check admission per slice with `cratis-screenplay-render-and-gap-fill`
+  (version pins: `cratis-screenplay-toolchain` `references/versions.md`) before pricing a slice as
+  rendered.
+- **Plans live in `.ai-work/`; tracking lives in GitHub issues** where the repository works
+  that way. Never put a plan in the model, in `.cratis/`, or in a documentation folder.
+
+## Procedure
+1. **Confirm the scope is accepted.** Only slices of a committed model under the root count
+   as planned delivery. Drafts and open questions are listed separately as unplanned. If the
+   model is still moving, plan only the stable modules and say what is excluded.
+2. **Inventory the slices.** Use the Screenplay MCP: `describe-application` for counts and
+   paged children, `dependency-graph` at slice level for edges, cycles and an advisory
+   order, `dependencies` and `find-references` per slice for the contracts it consumes and
+   produces and for the `invokes`, action and form edges the graph does not order (`reads` maps to `decidesFrom`, which it does order, but it stays a coordination point). Treat `complete: false` or an ambiguous binding as unknown, never as no
+   dependency (`cratis-screenplay-model-authoring`). Without the MCP, read the `.play` files.
+3. **Classify each slice** by type and by realization: rendered (Stage admits it) or
+   hand-written (gap-fill, adapter, external call). Record the reason for each hand-written one.
+4. **Build the dependency table** (`references/parallel-delivery.md`): per slice, the events
+   it consumes, who produces each, and the slices it waits on. A cycle means a feedback loop:
+   return it to slice design (usually an Automation slice); never schedule around it.
+5. **Group into waves.** Slices with no unmet producers form wave 1; each next wave needs
+   only earlier waves. Within a wave, slices are independent and can run in parallel. Group
+   slices that share one view or one stream into one slice group (one issue).
+6. **Weigh and estimate** (`references/velocity-and-capacity.md`): apply the team's weights per
+   type and realization, divide by measured throughput, and report a range with its basis. Add
+   separate lines for what is not slice work: modeling and review gates, integration with
+   outside systems, environment and deployment, specifications that need new infrastructure.
+7. **Track.** One GitHub issue per slice group, in the repository's own issue practice
+   (assign the issue, keep an in-progress status in the issue body, check for an existing claim
+   before starting): the status block lists the slices, their
+   type, the wave, the blockers and each slice's planning status below. The issue's own state
+   follows the repository's hygiene (in progress, in review when the PR opens, paused, blocked,
+   done only when delivered). Keep the working plan in
+   `.ai-work/<task>/delivery-plan.md`.
+8. **Re-plan after each completed group.** Update throughput, recount if the model changed,
+   restate the range. Record the retrospective metrics from `references/velocity-and-capacity.md`.
+
+## Status vocabulary
+Per-slice planning status, a closed set recorded inside the plan and the issue's status block.
+It is not the issue's state: the enclosing issue keeps the repository's own states (for example
+in progress, in review, paused, blocked, done), and is done only when its slices are
+delivered (merged and released where the repository releases).
+
+| Status | Meaning |
+|---|---|
+| todo | accepted in the model, not started |
+| in progress | one owner is working on it |
+| blocked | waiting on a named producer, decision or external party; say which |
+| done | built, its specifications pass, and the slice conforms to the model |
+
+Before claiming a slice, check its current status. If it is already `in progress`, someone else
+holds it: pick another slice, do not take it over and do not report an error. Move a status only
+to a different value; a repeated update is a signal that another worker got there first.
+Check for an existing claim (assignee and in-progress status) before starting; where the harness
+provides a claim tool such as `issue_work`, its claim step is that guard.
+
+## What a plan states
+- Scope: the modules and slices counted, and what was excluded and why.
+- Slice counts by type, split into rendered and hand-written.
+- The dependency table and the waves.
+- The estimate as a range with its basis, or "first estimate without history".
+- Capacity assumptions: who or what works in parallel, and the constraints on it.
+- Risks that move the range: hand-written slices, outside systems, open questions, a model
+  likely to change.
+
+## Limits
+- A rate from one project or one person does not transfer to another team or another kind of
+  slice; say when the sample is small or mixed.
+- Counting hides unusually large slices. A slice that needed a design discussion is two slices
+  or a modeling question; recount rather than weigh it as "big".
+- Parallel work only pays when slices are truly independent in the dependency table and
+  integration of the shared events is owned. Shared writes to one file, one stream or one
+  external system serialize the work.
+
+## References
+- `references/slice-counting.md` - types, realization, weights, what to count and exclude.
+  Read when counting or classifying slices.
+- `references/velocity-and-capacity.md` - measuring throughput, ranges, capacity math,
+  retrospective metrics. Read when producing or updating an estimate.
+- `references/parallel-delivery.md` - dependency table, waves, event contracts, issue
+  grouping. Read when splitting work across people or agents.
+- `references/provenance.md` - sources and what was not adopted.
+
+## Related skills
+`cratis-screenplay-slice-design` (slice dependencies), `cratis-screenplay-model-authoring`
+(MCP navigation), `cratis-screenplay-render-and-gap-fill` (what renders, gap-fill handoff),
+`cratis-screenplay-modeling-lifecycle` (phases and gates).

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" }
+  ]
+}