fsl-delivery git:20260727.e00cfd1A

Immutable. This exact content is served forever at /api/v1/blob/fd5ba23562e3dd5e.

---
name: fsl-delivery
description: Orchestrate an FSL-centered delivery workflow from business planning through PM requirements, engineering design, verification, refinement, scenarios, testgen/replay, and implementation conformance. Use when the user asks to drive a feature/project "from planning to implementation" with FSL as the backbone, connect business to requirements to design to implementation, create an end-to-end FSL development plan, or coordinate the existing fsl-business, fsl-requirements, fsl-design, and fsl-design-review skills.
---

# FSL Delivery

## Overview

Use this skill as the lifecycle coordinator for FSL-based delivery. It does not
replace the layer-specific skills; it routes work to them, preserves the layer
boundaries, and keeps proof, refinement, and implementation-conformance claims
separate.

FSL is the checkable contract spine, not the entire product process — but that
spine is broad by default: a spec replaces the prose business/requirements/design
doc you would write anyway, so wide coverage across those layers needs no
per-feature verification-ROI case. Natural language discovery, UI/API design,
coding, and testing still happen in their normal tools; FSL supplies the
machine-checkable contracts and counterexamples that constrain those artifacts.

The resulting spec corpus is the project's living single source of truth: each
layer is re-verified on every change (regression, drift, and cross-layer
change-impact via `refine`), and it doubles as onboarding context for humans and AI
approaching the flow it documents.

## Routing

Before authoring a layer, read and follow the corresponding skill:

- Business process, As-Is/To-Be, controls, KPIs, goals: `../fsl-business/SKILL.md`
- PM/PdM requirements, acceptance criteria, forbidden flows, NFR/SLA:
  `../fsl-requirements/SKILL.md`
- Engineering design, internal state/actions, refinement mapping, testgen/replay
  handoff: `../fsl-design/SKILL.md`
- Design review, variants, substitutability, SOLID/LSP/OCP judgment:
  `../fsl-design-review/SKILL.md`
- Cross-cutting dialect concerns — DB migration compatibility (`dbsystem`,
  `fslc db`), Functional DDD / async effects (`domain`, `fslc domain`), AI
  tool-boundary and agent contracts plus statistical evidence (`ai_component`/
  `agent`, `fslc ai`): `../fsl/SKILL.md` → "Advanced features". These sit
  outside the business→requirements→design progression and are not stage-gated
  by this skill.
- Syntax, verifier commands, JSON repair protocol: `../fsl/SKILL.md` and
  `../fsl/reference.md`

Load only the skills needed for the current stage. Do not duplicate their syntax
rules in this skill.

## Workflow

1. Identify the entry point and scope:
   - No stable business/PM material: start with business discovery.
   - Stable business contract exists: start or update requirements.
   - Stable requirements exist: start or update design/refinement.
   - Code or logs exist: connect implementation conformance with `testgen` or
     `replay`.
   - User asks whether a change/variant is safe: use design review.
2. Post a compact delivery memo before writing new FSL:
   - target flow and risk reason
   - available source artifacts
   - planned FSL layers and filenames
   - upper contract for each lower layer
   - acceptance/forbidden examples and implementation anchor, if known
   - behavior-changing assumptions and open questions
3. Author or update one layer at a time. Do not let lower-layer detail leak upward:
   business speaks in business stages and controls; requirements speak in
   externally observable behavior; design speaks in internal mechanics.
4. Verify each layer before depending on it:
   - `fslc check <file>`
   - `fslc verify <file> --depth 8`
   - `fslc verify <file> --engine induction`
5. Connect layers downward. Each handoff is a **refinement seam (a contract), not a
   plain baton pass** — the seam itself is verified, and a green chain is exactly as
   strong as the soundness of these seams:
   - requirements implements/refines business (`implements`, reported under the
     `implements` field of the requirements `verify` JSON)
   - design refines requirements with an explicit mapping (`fslc refine`)
   - implementation conforms through generated tests or event-log replay
   - gate the whole chain at once with `fslc chain` when a manifest exists
6. Report proof categories separately. Never collapse "model is verified",
   "design refines requirements", and "implementation conforms" into one claim.

## Stage Gates

| Stage | Deliverable | Required checks |
|---|---|---|
| Business | `business` spec with policies, KPIs, goals | check, verify, induction |
| Requirements | `requirements` spec with REQ IDs, acceptance, forbidden, NFRs | check, verify, induction, scenarios; when `implements` is present, assert `implements.result == "refines"` in the JSON (or gate with `fslc chain`) — a failed business seam still exits 0 |
| Design | kernel `spec` plus mapping to requirements | check, verify, induction, refine |
| Implementation | Adapter or event log connected to real behavior | testgen pytest or replay; do not claim conformance before this |
| Review/change | proposal spec or before/after contract | verify each side, refine against frozen contract, optional mutate/vacuity |

For every layer, also run:

- `fslc verify <file> --strict-tags` (traceability — untagged declarations and
  unreferenced requirement IDs)
- `fslc explain <file> --readable` (renders the spec as a readable digest; this is
  the spec's documentation, not a separate report)

For high-risk contracts, add the more expensive checks:

- `fslc verify <file> --vacuity error`
- `fslc mutate <file> --by-requirement`

## Claim Discipline

- A green business layer means the business model is internally consistent under
  the stated interpretation.
- A green requirements layer means the requirements model is internally
  consistent; if `implements` is green, it also preserves the business contract's
  checked safety obligations. "Green" here means `implements.result == "refines"`
  in the JSON — not exit 0, which stays 0 even when the seam fails.
- A green design layer means the design model is internally consistent.
- A green `refine` means lower-layer observable behavior conforms to the upper
  contract for checked safety behavior.
- Liveness/progress does not automatically propagate through refinement. Verify
  response properties at each layer that owns progress.
- A green `testgen` pytest run or `replay` result is the implementation-conformance
  anchor. Without an Adapter or log, the implementation is not yet checked.

## Human Decision Gates

Stop and ask for a product/business/design decision before changing behavior when:

- a guard, exception, deadline, retry rule, ownership rule, or state transition is
  missing from the source
- a counterexample can be fixed either by weakening a contract or by changing the
  lower layer
- a refinement mapping or stutter correspondence is not obvious from the source
- an implementation Adapter must decide how to project real state into FSL state

Representation-only modeling choices, such as finite domain sizes for model
checking, may be chosen by the agent. Label them separately from product
assumptions.

## Output Format

When reporting progress or completion, include a compact status table:

| Layer | File | Result | Notes |
|---|---|---|---|
| Business | ... | proved/verified/not used | ... |
| Requirements | ... | proved + implements/refines | ... |
| Design | ... | proved + refines | ... |
| Implementation | ... | conformant/not anchored | ... |

Then list open human decisions and the next concrete command or file to inspect.

## Common Prompts

- "Use $fsl-delivery to take this cancellation flow from business policy to
  implementation conformance."
- "Use $fsl-delivery to decide which FSL layers we need for this feature."
- "Use $fsl-delivery to connect these requirements to a design spec and generated
  conformance tests."
- "Use $fsl-delivery to review whether this implementation-oriented design still
  preserves the PM requirements."