fsl-requirementslisted

# FSL Requirements Layer Use this skill to formalize PM/PdM requirements as a `requirements Name { ... }` FSL file. The deliverable is a requirements contract that development can consume: requirement IDs, source text, operations, guards, acceptance criteria, forbidden flows, and optional conformance to an upper business layer. Before writing syntax, read `../fsl/SKILL.md` and `../fsl/reference.md` for the shared FSL verifier workflow and language rules. When working inside this repository, read `examples/pm/`, `examples/layers/return_system.fsl`, and `examples/e2e/2_requirements.fsl` for the requirements dialect. Read `examples/nfr/` only when SLA/deadline behavior is in scope. ## Faithfulness gate (definition of done) The two failures this layer exists to prevent are **dropping** a requirement (a thin spec) and **inventing** a rule the source never stated. Hold both ends: - **Cover the source.** Every requirement in the document maps to at least one transition / invariant / acceptance / forbidden, or is recorded in the memo as out-of-scope or needs-decision. The step-1 coverage map forces the hard requirements in instead of stopping at the happy path. - **Ground the spec.** Every declaration carries provenance — `covers REQ-n "..."` to source text, or a `MODEL:` / `ASSUME-n:` tag for an explicit modeling choice. An untagged declaration is an ungrounded guess, not a style nit. - **Do not invent to reach green.** If `check`/`verify` needs a guard, bound, stat