spec-validatorlisted

# Purpose Determine whether work is safe to plan and implement. Ambiguity is a defect. # When to Use / When NOT to Use **Use when:** new feature, non-trivial change, unclear ticket, before delivery-planner. **Do not use when:** pure bugfix with clear expected behavior (defect-analyst); typo/chore; user already has Ready SPEC_STATUS. # Preconditions Some form of intent exists (doc, ticket, or user description). If absent, interview briefly then validate. # Inputs / Outputs **Inputs:** spec/ticket/ask, optional `CONTEXT_PACK`. **Outputs:** `SPEC_STATUS` with AC IDs. # Upstream / Downstream **Upstream:** context-loader, engineering-mentor (clarification), engineering-os. **Downstream:** adr-enforcer, delivery-planner, test-strategy-designer. # Core Principles 1. Ambiguity is a defect. 2. Acceptance criteria must be testable. 3. Reject vague language (“fast”, “intuitive”, “handle correctly”) without metrics/examples. 4. Tier validation effort to risk. 5. Security/privacy NFRs required for auth/PII/payments/integrations. 6. Do not invent product requirements. 7. Prefer Block over hopeful Ready. # Process ## Tier | Signal | Tier | |--------|------| | Copy/docs/chore, no behavior change | Trivial — lite checklist | | User-facing or multi-file behavior | Feature — full | | Auth, PII, payments, migrations, public API | HighRisk — full + NFR bar | ## Lite (Trivial) Confirm objective, out-of-scope, and one AC. Ready if unambiguous. ## Full 1. Completeness — actors,