git:20260901.a6729c3 to git:20260911.246f098

3 added, 3 removed. Audit A to A.

---

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/references/advanced.md`. 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`, then its

topic-specific references as needed

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

- **testgen layer selection:** run `fslc testgen` on the spec at the **same

layer granularity as the implementation** (design `spec` for design-aligned

code). From upper layers, reuse **`forbidden` negatives only** — they stay

sound under refinement; upper **positive** scenarios can falsely fail a

sound refinement (see `../fsl/references/impl.md` §9 and

`examples/refinement_chain/{top,mid}.fsl`).

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 |

+ | 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 seam exits 1 with top-level `refinement_failed` or `impl_violated` |

| 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 lint <file>` (ID form — exits 1 on a non-canonical `"REQ-1: text"`

string tag, which `--strict-tags` accepts silently, and on an ID outside the

active policy. The canonical link is `@requirement("REQ-SCOPE-001", "text")`,

or process `covers` in the business/requirements dialects)

- `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.

+ checked safety obligations. "Green" here means `implements.result == "refines"` in the JSON — a failed seam exits 1 with

+ top-level `refinement_failed` or `impl_violated`, not a silent exit 0.

- 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:

|---|---|---|---|

| 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."