speclisted

# spec The product spec is the team's: **what** each feature does and **when it is done**. One file per feature under docs/specs/ (`F01-<slug>.md`, `F02-<slug>.md`, …) and one index, docs/SPEC.md, with a line per feature. The team writes it; the CEO does not have to read it — the brief (docs/BRIEF.md) is what the CEO approved, and the spec is the team's expansion of it. When the CEO looks at the product later and says "이거 아닌데", the section changes and the plans follow (revision below). It never chooses how: no stack, schema design, library or alternatives — those are ADR material, decided in /plan. Link rather than paste; a section file is one to two pages at most. A section is referenced by its ID (F3) everywhere — plans, backlog, METRICS, chat; the index resolves the ID to the file, so the planner and the critic read only the file they need. ## Sources, in order of authority 1. docs/BRIEF.md — Decided lines (one section each), Non-goals (nothing crosses them), Constraints, Quality bar, the appendix (the CEO's own words about flows and screens: use them verbatim as the section's core flow and screens; they are the closest thing to a CEO round). 2. docs/CHARTER.md and docs/DECISIONS.md — earlier decisions stand; never re-decide them. 3. The planner's own defaults — every slot the sources leave open is decided with a default, written as `decided by default: <x> — <reason>` in the section's Undecided list and logged as one line in docs/DECISIONS.md. Never a guess presented as