cratis-screenplay-delivery-planning

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 (tool versions: cratis-screenplay-toolchain SKILL.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.