spec-validate

You are running an adversarial spec review. Read the spec from docs/specs/SPEC-NNN-<slug>.md (the most recent non-shipped spec if several exist). If no spec exists, tell the user to run /kit:spec first.

The 6 reviewers

Bracket both phases this lane owns for timing (SPEC-129), before running Reviewer 1: bash lib/gate/gate-ledger.sh outcome <rid> Validate start and bash lib/gate/gate-ledger.sh outcome <rid> design-record start.

Run each reviewer sequentially. For each one, present findings and ask the user if they want to address the issues before moving to the next reviewer. Reviewers 1-5 are advisory; Reviewer 6 (below) is the one exception that can block the VALIDATED flip.

Reviewer 1: Security Auditor

Look for:

• Auth/authz gaps (who can access what? are there unprotected endpoints?)
• Input validation missing (SQL injection, XSS, path traversal)
• Secrets handling (hardcoded keys, unencrypted storage)
• Data exposure (PII in logs, verbose error messages)
• Dependency risks (known vulnerable packages)

Reviewer 2: Failure Mode Analyst

Look for:

• What happens when external services are down?
• What happens with concurrent access / race conditions?
• What happens with malformed or unexpected input?
• What happens at 10x expected load?
• What's the recovery path for each failure?
• Are there any single points of failure?
• If the spec has a ## Failure modes table, check each class is real and has both a detection signal and a mitigation; flag missing or hand-waved entries.

Reviewer 3: Assumption Destroyer

Look for:

• Unstated assumptions about user behavior
• Assumptions about data quality or format
• Assumptions about infrastructure availability
• Assumptions about third-party API stability
• "Happy path only" designs with no error handling
• Implicit ordering dependencies between tasks

Reviewer 4: Scope Critic

Look for:

• Aggressive atomicity check (critical): Each task must fit in ~50% of a fresh context window (~100k tokens). Heuristic: if a task touches more than 5 files, or its description needs more than 3 sentences, or its acceptance criteria has more than 5 bullet points, it's too large. Flag it and suggest splitting. Source: GSD's "each plan is maximum 3 tasks, each fits in 50% context" principle.
• Tasks that bundle unrelated changes (e.g., "set up auth AND create user dashboard" is two tasks)
• Features disguised as requirements (nice-to-have dressed up as must-have)
• Gold-plating (things that sound important but aren't needed for v1)
• Missing tasks (gaps between spec and acceptance criteria: does completing all tasks actually satisfy the global acceptance criteria?)
• Unclear acceptance criteria (not testable: "should be fast" is not testable, "response under 200ms at p95" is)
• Missing dependency declarations (Task B clearly depends on Task A's output but doesn't say so)
• Autonomy gate (ID-036 / SPEC-084): if the spec's behavior runs inside an autonomous loop (/kit:execute pipeline, /goal), check it does not let the loop make a scope / architecture / risk decision without a human gate; flag any loop-reachable decision point with no stop.
• Picture presence (mechanical, ID-454): on a full-lane spec, ## Picture must be present and non-empty: an ASCII/box-drawing diagram, or, for a UI-shaped spec, a pointer to a /kit:prototype run (prototype/<name> + the variant to look at). A missing or empty ## Picture on a full-lane spec is a finding. Below full lane, presence is encouraged only; do not flag its absence.
• Picture agrees with the task list (lens question, ID-454): read the picture (or the prototype it points at) against ## Task Breakdown. Every piece the picture draws should get touched by some task, and every task that adds a new piece should show up in the picture. Flag drift either direction.