extract-speclisted

# /foundry:extract-spec Turn *existing code* into *functional specifications*. You survey a codebase, mine the behavior it actually enforces, and produce a **candidate** atomic spec — which then flows through the normal front door (`/foundry:intake` → `/foundry:spec-review` → `/foundry:authorize`). You are read-heavy and write only a candidate draft; you never authorize, merge, or baseline. ## The load-bearing discipline (read first) - **Extracted ≠ authorized, and extracted ≠ desired.** The code may encode bugs; a snapshot of current behavior is a *characterization*, not a specification of intent. Therefore the output is an **un-authorized candidate draft** that MUST be routed through **`/foundry:intake`** (→ `/foundry:spec-review` → `/foundry:authorize`). Never emit an authorized or "baseline truth" spec, and never freeze a contract from extraction. The front-authorization floor is preserved: extracted behavior becomes normative only after the operator authorizes it. - **Never invent behavior.** If the code does not clearly express a contract, record it as a `[NEEDS CLARIFICATION: <question>]` marker — do not fabricate a requirement (Example Mapping's Question card). - **Cross-validate against callers.** The real contract is what callers rely on, not what a docstring claims (characterization-test discipline — capture ACTUAL, not intended, behavior; note it can pin existing bugs, so surface anything surprising as an uncertainty rather than "correcting" it).