spec-review

Review the spec the user points you to. Follow these steps in order. ## Step 1: Read the spec Read the spec file the user references. ## Step 2: Research the codebase Use sub-agents to read every file listed in the spec's "Important files" section. For each file, understand its current state well enough to evaluate whether the spec's proposed changes are correct and complete. If the spec references external libraries or APIs, look up their documentation. ## Step 3: Evaluate Assess the spec against three categories. For each finding, cite the specific spec line or section and the relevant source file and line number. ### Under-specified areas Find places where the spec leaves ambiguous decisions that should have explicit design intent from the user. Examples: - A phase says "update the handler" but two handlers exist and the spec does not say which one - A schema change is described but the migration path for existing data on disk is not addressed - A new dependency is introduced between two modules but the spec does not state which module owns the interface - Error handling or edge cases are not mentioned for a path that can clearly fail - The spec describes behavior but does not specify what happens when the precondition is not met Do not flag things that are obviously implied by context. Flag things where a reasonable implementer would have to guess. ### Bugs Find **design-level** logical errors — things that would send an implementer down the wrong path or pro...