Critic

• No arguments: git diff + git diff --cached (all uncommitted work)
• Branch name: git diff main...$ARGUMENTS
• Commit range: git diff $ARGUMENTS
• File path/glob: git diff -- $ARGUMENTS + git diff --cached -- $ARGUMENTS

If the diff is empty, tell the user there's nothing to review and stop.

2. Identify relevant specs

For each changed file, find the closest matching spec under /specs/:

• Map file paths to spec domains:
  • packages/cyan/src/** → specs/cyan-ds/
  • app/cyan-ds/** → specs/cyan-ds/ (Note that app/cyan-ds maps directly to specs/cyan-ds/ for DS rules)
  • app/pelilauta/** → specs/pelilauta/
  • packages/shell/** → specs/shell/
• Read each relevant spec. If no spec exists for a changed area, note this as a gap (not a violation).

Also check for AGENTS.md in the repo root (constitutional constraints, especially Astro vs Svelte Architecture).

3. Identify relevant ASDLC patterns

Search the ASDLC knowledge base for patterns relevant to the type of changes being reviewed. For example:

• Token/design system changes → search for design token patterns
• Data model changes → search for schema patterns
• Component changes → search for relevant architectural patterns

Use findings as additional review context, not as hard requirements.

4. Review the changes

Analyze every changed file against three lenses:

Lens 1: Spec Compliance

• Does the code satisfy the spec's Contract (Definition of Done, Scenarios)?
• Does the code violate any Anti-Patterns documented in the spec?
• Does the code break any Regression Guardrails?
• Are there behavioral divergences from what the spec describes?

Lens 2: Constitutional / Architectural

• Does the code follow Astro SSR/CSS vs Svelte 5 CSR progressive enhancement architectural constraints defined in AGENTS.md?
• Are there security issues (injection, XSS, exposed secrets, auth bypasses)?
• Are there performance anti-patterns (N+1 queries, unbounded loads, memory leaks)?
• Is error handling appropriate (no silent failures, no swallowed exceptions)?
• Are types used correctly (no any, no unsafe casts)?

Lens 3: Correctness & Edge Cases

• Are there logic errors, off-by-one bugs, or race conditions?
• Are edge cases handled (empty inputs, null/undefined, boundary values)?
• Are there dead code paths or unreachable branches?
• Could this break existing functionality (regression risk)?

5. Produce the verdict

Output a structured review using this format:

## Adversarial Review — [scope description]

**Specs reviewed:** [list of spec files read, or "none found"]
**Files reviewed:** [count of files in diff]
**Verdict:** PASS | PASS WITH NOTES | FAIL

---

### Violations

> Only present if FAIL. Each violation must reference a specific file and line.

#### [V1] [Category] — [Short description]
- **File:** `path/to/file.ts` Line NN
- **Contract broken:** [Which spec clause or architectural principle]
- **Impact:** [Why this matters — security, correctness, performance, maintainability]
- **Remediation:** [Ordered steps to fix. Prefer standard patterns.]
- **Test requirement:** [What test would prevent regression]

---

### Notes

> Present for PASS WITH NOTES or FAIL. Non-blocking observations.

- [Observation about code quality, style, or potential improvements]
- [Questions about intent that only the author can answer]

---

### Gaps

> Spec or documentation gaps discovered during review.

- [Missing spec for area X]
- [Spec Y is ambiguous about Z — consider clarifying]

6. Verdict rules

• FAIL — At least one violation found (spec violation, security issue, correctness bug)
• PASS WITH NOTES — No violations, but there are observations worth considering
• PASS — Clean. No violations, no notes worth raising.

Bias toward false positives over false negatives. It is better to flag something that turns out to be fine than to miss a real issue. The author can dismiss notes; they can't un-ship bugs.

7. Review principles

• Be specific — "Line 42 uses any" not "types could be better"
• Be adversarial — Your job is to find problems, not to be encouraging
• Cite the contract — Every violation must reference a spec clause, architectural principle, or ASDLC pattern
• Don't rewrite — You are a reviewer, not a pair programmer. Describe what's wrong and the fix direction, don't produce replacement code blocks
• Respect scope — Only review what's in the diff. Don't critique pre-existing code unless the change makes it worse
• Flag spec gaps — If you can't determine correctness because the spec is vague or missing, that's a finding

Do NOT auto-commit or modify any files. This command is read-only.