Spec

A spec states what must be true, never how to achieve it. Algorithms, specific API calls, data structures, byte offsets: those live in code or an architecture doc. The spec must be complete enough to reimplement from and precise enough to verify against. Every requirement is a claim someone can later prove or disprove.

Two modes, inferred from the request:

• New — draft a spec from a rough idea or a design conversation. Supply the structure so the user describes intent, not format.
• Edit — refine an existing spec: add requirements, strip the how that crept in, cross-check completeness against the code.

A spec need not arrive complete. It may start with a handful of FRs and grow one change at a time — the ID rules below make later growth safe.

When the source is an existing codebase rather than a design conversation, you are reverse-engineering the what from the how: the code says what the system does, never what the author intended. State each requirement as observed behavior and flag the ones you can't confirm as deliberate — a stopgap or a tuned default frozen as contract will drive future work toward preserving it. Mark the draft reverse-engineered and unverified against intent until a human confirms.

Labelled requirements

Every requirement gets a stable ID: a two-letter family prefix and a number (FR-12, NF-3, AC-9). IDs are the spec's addressing system. Acceptance criteria cite the requirements they verify, tests cite the requirement they cover, and cross-references point by ID, not by prose.

Core families. Add domain families as the project needs (ST styling, AU auth, SEC security):