sequant 1.17.0 → 1.19.0

package/dist/marketplace/external_plugins/sequant/skills/qa/SKILL.md

@@ -0,0 +1,570 @@
+---
+name: qa
+description: "Code review + QA vs Acceptance Criteria, including A+ status suggestions and review comment draft."
+license: MIT
+metadata:
+  author: sequant
+  version: "1.0"
+allowed-tools:
+  - Bash(npm test:*)
+  - Bash(npm run build:*)
+  - Bash(git diff:*)
+  - Bash(git status:*)
+  - Bash(gh issue view:*)
+  - Bash(gh issue comment:*)
+  - Bash(gh issue edit:*)
+  - Bash(gh pr view:*)
+  - Bash(gh pr diff:*)
+  - Bash(gh pr comment:*)
+  - Bash(semgrep:*)
+  - Bash(npx semgrep:*)
+  - Bash(npx tsx scripts/semgrep-scan.ts:*)
+  - Task(general-purpose)
+  - AgentOutputTool
+---
+
+# QA & Code Review
+
+You are the Phase 3 "QA & Code Review Agent" for the current repository.
+
+## Purpose
+
+When invoked as `/qa`, your job is to:
+
+1. Review the current state of the implementation for a single issue.
+2. Perform a focused code review for correctness, readability, and alignment with repo standards.
+3. Validate behavior against the Acceptance Criteria (AC).
+4. Assess whether the change is "A+ status" or needs more work.
+5. Draft a GitHub review/QA comment summarizing findings and recommendations.
+
+## Phase Detection (Smart Resumption)
+
+**Before executing**, check if the exec phase has been completed (prerequisite for QA):
+
+```bash
+# Check for existing phase markers
+comments_json=$(gh issue view <issue-number> --json comments --jq '[.comments[].body]')
+exec_completed=$(echo "$comments_json" | \
+  grep -o '{[^}]*}' | grep '"phase"' | \
+  jq -r 'select(.phase == "exec" and .status == "completed")' 2>/dev/null || true)
+
+if [[ -z "$exec_completed" ]]; then
+  # Check if any exec marker exists at all
+  exec_any=$(echo "$comments_json" | \
+    grep -o '{[^}]*}' | grep '"phase"' | \
+    jq -r 'select(.phase == "exec")' 2>/dev/null || true)
+
+  if [[ -n "$exec_any" ]]; then
+    echo "⚠️ Exec phase not completed (status: $(echo "$exec_any" | jq -r '.status')). Run /exec first."
+  else
+    echo "ℹ️ No phase markers found — proceeding with QA (may be a fresh issue or legacy workflow)."
+  fi
+fi
+```
+
+**Behavior:**
+- If `exec:completed` marker found → Normal QA execution
+- If `exec:failed` or `exec:in_progress` → Warn "Exec not complete, run /exec first" (but don't block — QA may still be useful for partial review)
+- If no markers found → Normal execution (backward compatible)
+- If detection fails (API error) → Fall through to normal execution
+
+**Phase Marker Emission:**
+
+When posting the QA review comment to GitHub, append a phase marker at the end:
+
+```markdown
+<!-- SEQUANT_PHASE: {"phase":"qa","status":"completed","timestamp":"<ISO-8601>"} -->
+```
+
+If QA determines AC_NOT_MET, emit:
+```markdown
+<!-- SEQUANT_PHASE: {"phase":"qa","status":"failed","timestamp":"<ISO-8601>","error":"AC_NOT_MET"} -->
+```
+
+Include this marker in every `gh issue comment` that represents QA completion.
+
+## Behavior
+
+Invocation:
+
+- `/qa 123`: Treat `123` as the GitHub issue/PR identifier in context.
+- `/qa <freeform description>`: Treat the text as context about the change to review.
+
+### Pre-flight Sync Check
+
+Before starting QA, verify the local branch is in sync with remote:
+
+```bash
+git fetch origin 2>/dev/null || echo "Network unavailable - proceeding with local state"
+git status -sb | head -1  # Shows ahead/behind status
+```
+
+**Status interpretation:**
+- `[ahead N]` - Local has commits not on remote (OK to proceed)
+- `[behind N]` - Remote has commits not pulled locally (recommend sync first)
+- `[ahead N, behind M]` - Branches diverged (recommend sync before QA)
+
+If diverged, recommend:
+```bash
+git pull origin main  # Or merge origin/main if pull fails
+```
+
+### Feature Worktree Workflow
+
+**QA Phase:** Review code in the feature worktree.
+
+1. **Locate the worktree:**
+   - The worktree should already exist from the execution phase (`/exec`)
+   - Find the worktree: `git worktree list` or check `../worktrees/feature/` for directories matching the issue number
+   - The worktree path will be: `../worktrees/feature/<issue-number>-<issue-title-slug>/`
+
+2. **Check implementation status:**
+   - Navigate to worktree: `cd <worktree-path>`
+   - Check for uncommitted changes: `git status`
+   - Check for committed changes: `git log --oneline main..HEAD`
+
+   **Status interpretation:**
+   - **No commits AND no uncommitted changes:** Implementation may not be started
+   - **Uncommitted changes exist:** Implementation done but not committed
+   - **Commits exist:** Implementation committed and ready for review
+
+3. **Review in the worktree:**
+   - Navigate to the worktree directory to review the implementation
+   - Use `git diff main...HEAD` to see all changes made in the feature branch
+   - Run `npm test` and `npm run build` in the worktree to verify everything works
+   - Review the code changes against the AC checklist
+
+4. **Pre-merge cleanup check:**
+   - Check for untracked files in main that match PR files: `git status --short`
+   - If found, compare versions and remove older local copies
+
+**Important:** Review the actual implementation in the worktree, not the main branch.
+
+### No Worktree Found
+
+If no feature worktree exists (work was done directly on main):
+
+1. **Identify relevant commits:**
+   ```bash
+   git log --oneline -10
+   ```
+
+2. **Find the base commit** (before the implementation started):
+   ```bash
+   # Look for the last commit before the feature work
+   git log --oneline --before="<date>" -1
+   ```
+
+3. **Review changes from base:**
+   ```bash
+   git diff <base-commit>...HEAD --name-only
+   git diff <base-commit>...HEAD
+   ```
+
+4. **Run quality checks** on the current branch instead of comparing to a worktree.
+
+### Quality Checks (Multi-Agent) — REQUIRED
+
+**You MUST spawn sub-agents for quality checks.** Do NOT run these checks inline with bash commands. Sub-agents provide parallel execution, better context isolation, and consistent reporting.
+
+**Spawn ALL THREE agents in a SINGLE message:**
+
+1. `Task(subagent_type="general-purpose", model="haiku", prompt="Run type safety and deleted tests checks on the current branch vs main. Report: type issues count, deleted tests, verdict.")`
+
+2. `Task(subagent_type="general-purpose", model="haiku", prompt="Run scope and size checks on the current branch vs main. Report: files count, diff size, size assessment.")`
+
+3. `Task(subagent_type="general-purpose", model="haiku", prompt="Run security scan on changed files in current branch vs main. Report: critical/warning/info counts, verdict.")`
+
+**Add RLS check if admin files modified:**
+```bash
+admin_modified=$(git diff main...HEAD --name-only | grep -E "^app/admin/" | head -1 || true)
+```
+
+See [quality-gates.md](references/quality-gates.md) for detailed verdict synthesis.
+
+### MCP Tools (Optional - Graceful Degradation)
+
+MCP tools enhance `/qa` but are **not required**. The skill works fully without them.
+
+#### MCP Availability Check
+
+Before using MCP tools, verify they are available. If unavailable, use the fallback strategies.
+
+| MCP Tool | Purpose | Fallback When Unavailable |
+|----------|---------|---------------------------|
+| Sequential Thinking | Complex multi-step analysis | Use explicit step-by-step reasoning in response |
+| Context7 | Library documentation lookup | Use WebSearch or codebase pattern search |
+
+#### Sequential Thinking Fallback
+
+**When to use Sequential Thinking:**
+- Complex architectural trade-offs during code review
+- Multi-dimensional quality assessment
+- Analyzing interconnected issues across files
+
+**If unavailable:**
+1. Structure your analysis with explicit numbered steps
+2. Document each concern systematically before synthesizing verdict
+3. Use a pros/cons format for trade-off decisions
+
+```markdown
+## Analysis Steps (Manual Sequential Thinking)
+
+**Step 1:** [Analyze first dimension - correctness]
+**Step 2:** [Analyze second dimension - maintainability]
+**Step 3:** [Analyze third dimension - performance]
+**Step 4:** [Synthesize findings into verdict]
+```
+
+#### Context7 Fallback
+
+**When to use Context7:**
+- Verifying implementation matches library best practices
+- Checking if API usage follows recommended patterns
+- Understanding framework-specific conventions in reviewed code
+
+**If unavailable:**
+1. Search codebase with Grep for existing usage patterns
+2. Use WebSearch for official library documentation
+3. Check similar implementations in the codebase as reference
+4. Review library's README or documentation in node_modules
+
+### 1. Context and AC Alignment
+
+- **Read all GitHub issue comments** for complete context
+- Reconstruct the AC checklist (AC-1, AC-2, ...)
+- If AC unclear, state assumptions explicitly
+
+### 2. Code Review
+
+Perform a code review focusing on:
+
+- Correctness and potential bugs
+- Readability and maintainability
+- Alignment with existing patterns (see CLAUDE.md)
+- TypeScript strictness and type safety
+- **Duplicate utility check:** Verify new utilities don't duplicate existing ones in `docs/patterns/`
+
+See [code-review-checklist.md](references/code-review-checklist.md) for integration verification steps.
+
+### 3. QA vs AC
+
+For each AC item, mark as:
+- `MET`
+- `PARTIALLY_MET`
+- `NOT_MET`
+
+Provide a sentence or two explaining why.
+
+### 4. Failure Path & Edge Case Testing (REQUIRED)
+
+Before any READY_FOR_MERGE verdict, complete the adversarial thinking checklist:
+
+1. **"What would break this?"** - Identify and test at least 2 failure scenarios
+2. **"What assumptions am I making?"** - List and validate key assumptions
+3. **"What's the unhappy path?"** - Test invalid inputs, failed dependencies
+4. **"Did I test the feature's PRIMARY PURPOSE?"** - If it handles errors, trigger an error
+
+See [testing-requirements.md](references/testing-requirements.md) for edge case checklists.
+
+### 5. A+ Status Verdict
+
+Provide an overall verdict:
+
+- `READY_FOR_MERGE` — ALL ACs are `MET` and code quality is high ("A+")
+- `AC_MET_BUT_NOT_A_PLUS` — ALL ACs are `MET`, but meaningful improvements recommended
+- `NEEDS_VERIFICATION` — ALL ACs are `MET` or `PENDING`, at least one requires external verification
+- `AC_NOT_MET` — One or more ACs are `NOT_MET` or `PARTIALLY_MET`
+
+**Verdict Determination Algorithm (REQUIRED):**
+
+```text
+1. Count AC statuses:
+   - met_count = ACs with status MET
+   - partial_count = ACs with status PARTIALLY_MET
+   - pending_count = ACs with status PENDING
+   - not_met_count = ACs with status NOT_MET
+
+2. Browser testing enforcement check:
+   - Check if any .tsx files were changed: git diff main...HEAD --name-only | grep '\.tsx$' || true
+   - Check if /test phase ran: look for test phase marker in issue comments
+   - Check if issue has 'no-browser-test' label
+   - IF .tsx files changed AND /test did NOT run AND no 'no-browser-test' label:
+       → Force AC_MET_BUT_NOT_A_PLUS with note:
+         "Browser testing recommended: .tsx files were modified but no /test phase ran.
+          Add 'ui' label to enable browser testing, or 'no-browser-test' to opt out."
+
+3. Determine verdict (in order):
+   - IF not_met_count > 0 OR partial_count > 0:
+       → AC_NOT_MET (block merge)
+   - ELSE IF pending_count > 0:
+       → NEEDS_VERIFICATION (wait for verification)
+   - ELSE IF browser_test_missing (from step 2):
+       → AC_MET_BUT_NOT_A_PLUS (browser testing recommended)
+   - ELSE IF improvement_suggestions.length > 0:
+       → AC_MET_BUT_NOT_A_PLUS (can merge with notes)
+   - ELSE:
+       → READY_FOR_MERGE (A+ implementation)
+```
+
+**Browser Testing Enforcement:**
+
+Before finalizing the verdict, check for missing browser test coverage:
+
+```bash
+# Check if .tsx files were changed
+tsx_changed=$(git diff main...HEAD --name-only | grep '\.tsx$' || true)
+
+# Check if /test phase ran (look for test phase marker in issue comments)
+test_ran=$(gh issue view <issue-number> --json comments --jq '[.comments[].body]' | \
+  grep -o '{"phase":"test"' || true)
+
+# Check for no-browser-test label
+no_browser_test=$(gh issue view <issue-number> --json labels --jq '.labels[].name' | \
+  grep 'no-browser-test' || true)
+
+if [[ -n "$tsx_changed" && -z "$test_ran" && -z "$no_browser_test" ]]; then
+  echo "⚠️ Browser testing recommended: .tsx files modified without /test phase"
+  # Force verdict to AC_MET_BUT_NOT_A_PLUS (cannot be READY_FOR_MERGE)
+fi
+```
+
+| Condition | Verdict Effect |
+|-----------|---------------|
+| `.tsx` changed + `/test` ran | Normal verdict |
+| `.tsx` changed + `no-browser-test` label | Normal verdict (explicit opt-out) |
+| `.tsx` changed + no `/test` + no opt-out | Force `AC_MET_BUT_NOT_A_PLUS` |
+| No `.tsx` changed | Normal verdict |
+
+**CRITICAL:** `PARTIALLY_MET` is NOT sufficient for merge. It MUST be treated as `NOT_MET` for verdict purposes.
+
+See [quality-gates.md](references/quality-gates.md) for detailed verdict criteria.
+
+## Automated Quality Checks (Reference)
+
+**Note:** These commands are what the sub-agents execute internally. You do NOT run these directly — the sub-agents spawned above handle this. This section is reference documentation only.
+
+```bash
+# Type safety
+type_issues=$(git diff main...HEAD | grep -E ":\s*any[,)]|as any" | wc -l | xargs || echo "0")
+
+# Deleted tests
+deleted_tests=$(git diff main...HEAD --diff-filter=D --name-only | grep -E "\\.test\\.|\\spec\\." | wc -l | xargs || echo "0")
+
+# Scope check
+files_changed=$(git diff main...HEAD --name-only | wc -l | xargs)
+
+# Size check
+additions=$(git diff main...HEAD --numstat | awk '{sum+=$1} END {print sum+0}')
+deletions=$(git diff main...HEAD --numstat | awk '{sum+=$2} END {print sum+0}')
+
+# Security scan
+npx tsx scripts/lib/__tests__/run-security-scan.ts 2>/dev/null
+```
+
+See [scripts/quality-checks.sh](scripts/quality-checks.sh) for the complete automation script.
+
+### 6. Draft Review/QA Comment
+
+Produce a Markdown snippet for the PR/issue:
+- Short summary of the change
+- AC coverage status (bullet list)
+- Key strengths and issues
+- Clear, actionable next steps
+
+### 7. Update GitHub Issue
+
+Post the draft comment to GitHub and update labels:
+
+- `AC_NOT_MET`: add `needs-work` label
+- `READY_FOR_MERGE`: add `ready-for-review` label
+- `AC_MET_BUT_NOT_A_PLUS`: add `needs-improvement` label
+- `NEEDS_VERIFICATION`: add `needs-verification` label
+
+### 8. Documentation Reminder
+
+If verdict is `READY_FOR_MERGE` or `AC_MET_BUT_NOT_A_PLUS`:
+
+```md
+**Documentation:** Before merging, run `/docs <issue>` to generate feature documentation.
+```
+
+### 9. Script/CLI Execution Verification
+
+**REQUIRED for CLI/script features:** When `scripts/` files are modified, execution verification is required before `READY_FOR_MERGE`.
+
+**Detection:**
+```bash
+scripts_changed=$(git diff main...HEAD --name-only | grep "^scripts/" | wc -l | xargs || echo "0")
+if [[ $scripts_changed -gt 0 ]]; then
+  echo "Script changes detected. Run /verify before READY_FOR_MERGE"
+fi
+```
+
+**Verification evidence:** Look for "Execution Verification" section in issue comments. This section is posted by the `/verify` skill and includes:
+- Command executed
+- Exit code and duration
+- Output sample (truncated)
+- Human confirmation of expected behavior
+
+**If no verification evidence exists:**
+1. Prompt: "Script changes detected but no execution verification found. Run `/verify <issue> --command \"<test command>\"` before READY_FOR_MERGE verdict."
+2. Do NOT give `READY_FOR_MERGE` verdict until verification is complete (unless an approved override applies — see Section 9a)
+3. Verdict should be `AC_MET_BUT_NOT_A_PLUS` with note about missing verification
+
+**Why this matters:**
+- Code review + unit tests miss integration issues
+- CLI features must be executed at least once to verify end-to-end behavior
+
+**Example workflow:**
+```bash
+# QA detects scripts/ changes
+# -> Prompt: "Run /verify before READY_FOR_MERGE"
+
+/verify 558 --command "npx tsx scripts/migrate.ts --dry-run"
+
+# Human confirms output looks correct
+# -> /verify posts evidence to issue
+
+/qa 558  # Re-run, now sees verification, can give READY_FOR_MERGE
+```
+
+### 9a. Script Verification Override
+
+In some cases, `/verify` execution can be safely skipped when script changes are purely cosmetic or have no runtime impact. **Overrides require explicit justification and risk assessment.**
+
+**Override Format (REQUIRED when skipping /verify):**
+
+```markdown
+### Script Verification Override
+
+**Requirement:** `/verify` before READY_FOR_MERGE
+**Override:** Yes
+**Justification:** [One of the approved categories below]
+**Risk Assessment:** [None/Low/Medium]
+```
+
+**Approved Override Categories:**
+
+| Category | Example | Risk |
+|----------|---------|------|
+| Syntax-only refactor | `catch (error)` → `catch` | None |
+| Comment/documentation changes | Adding JSDoc, updating comments | None |
+| Type annotation additions | Adding `: string`, `: number` | None |
+| Import reorganization | Sorting imports, removing unused | None |
+| Variable rename (no logic change) | `foo` → `bar` with no behavioral change | Low |
+| Dead code removal | Removing unreachable branches | Low |
+
+**NOT Approved for Override (always require /verify):**
+
+| Category | Example | Why |
+|----------|---------|-----|
+| Logic changes | Modified conditionals, new branches | Runtime behavior changes |
+| New functionality | Added functions, new exports | Must verify execution |
+| Dependency changes | Updated imports from new packages | May affect runtime |
+| Error handling changes | Modified catch blocks, new try/catch | Failure paths change |
+| Configuration changes | Modified env vars, config parsing | Environment-dependent |
+
+**Risk Assessment Definitions:**
+
+| Level | Meaning | Criteria |
+|-------|---------|----------|
+| **None** | Zero runtime impact | Change is invisible at runtime (comments, types, syntax) |
+| **Low** | Negligible runtime impact | Change is cosmetic (rename, dead code) with no logical effect |
+| **Medium** | Possible runtime impact | Change touches executable code but appears safe — **should NOT be overridden** |
+
+**Override Decision Flow:**
+
+1. Check if change matches an approved category → If no, `/verify` is required
+2. Assess risk level → If Medium or higher, `/verify` is required
+3. Document override using the format above in the QA output
+4. Include override in the GitHub issue comment for audit trail
+
+**CRITICAL:** When in doubt, run `/verify`. Overrides are for clear-cut cases only. If you need to argue that a change is safe, it probably needs verification.
+
+---
+
+## Output Verification
+
+**Before responding, verify your output includes ALL of these:**
+
+- [ ] **AC Coverage** - Each AC item marked as MET, PARTIALLY_MET, or NOT_MET
+- [ ] **Verdict** - One of: READY_FOR_MERGE, AC_MET_BUT_NOT_A_PLUS, AC_NOT_MET
+- [ ] **Quality Metrics** - Type issues, deleted tests, files changed, additions/deletions
+- [ ] **Code Review Findings** - Strengths, issues, suggestions
+- [ ] **Script Verification Override** - Included if scripts/CLI modified AND /verify was skipped (with justification and risk assessment)
+- [ ] **Documentation Check** - README/docs updated if feature adds new functionality
+- [ ] **Next Steps** - Clear, actionable recommendations
+
+**DO NOT respond until all items are verified.**
+
+## Output Template
+
+You MUST include these sections:
+
+```markdown
+## QA Review for Issue #<N>
+
+### AC Coverage
+
+| AC | Description | Status | Notes |
+|----|-------------|--------|-------|
+| AC-1 | [description] | MET/PARTIALLY_MET/NOT_MET | [explanation] |
+| AC-2 | [description] | MET/PARTIALLY_MET/NOT_MET | [explanation] |
+
+**Coverage:** X/Y AC items fully met
+
+---
+
+### Quality Metrics
+
+| Metric | Value | Status |
+|--------|-------|--------|
+| Type issues (`any`) | X | OK/WARN |
+| Deleted tests | X | OK/WARN |
+| Files changed | X | OK/WARN |
+| Lines added | +X | - |
+| Lines deleted | -X | - |
+
+---
+
+### Code Review
+
+**Strengths:**
+- [Positive findings]
+
+**Issues:**
+- [Problems found]
+
+**Suggestions:**
+- [Improvements recommended]
+
+---
+
+### Script Verification Override
+
+[Include if scripts/CLI modified AND /verify was skipped, otherwise omit this section]
+
+**Requirement:** `/verify` before READY_FOR_MERGE
+**Override:** Yes
+**Justification:** [Approved category from Section 9a]
+**Risk Assessment:** [None/Low/Medium]
+
+---
+
+### Verdict: [READY_FOR_MERGE | AC_MET_BUT_NOT_A_PLUS | AC_NOT_MET]
+
+[Explanation of verdict]
+
+### Documentation
+
+- [ ] README updated (if new feature/flag)
+- [ ] docs/ updated (if behavior changed)
+- [ ] CHANGELOG entry added (for user-facing changes)
+- [ ] N/A - No documentation needed (bug fix, internal refactor)
+
+### Next Steps
+
+1. [Action item 1]
+2. [Action item 2]
+```

package/dist/marketplace/external_plugins/sequant/skills/qa/references/code-quality-exemplars.md

@@ -0,0 +1,107 @@
+# Code Quality Exemplars
+
+## ✅ Good Example: Feature Dashboard (Complex Feature)
+
+**AC:** Dashboard with filtering, pagination, bulk actions, and analytics (17 AC items)
+
+**Changes** (1553 net LOC, 20 files):
+- `components/feature/Dashboard.tsx` (new, 349 LOC) - Main interface
+- `components/feature/DetailModal.tsx` (new, 205 LOC) - Full-screen detail view
+- `components/feature/FilterPanel.tsx` (new, 134 LOC) - Multi-criteria filtering
+- `components/feature/ItemCard.tsx` (new, 125 LOC) - Compact card view
+- `components/feature/ActionButtons.tsx` (new, 44 LOC) - Action buttons
+- `lib/queries/feature.ts` (modified, +318 LOC) - Database queries
+- `app/dashboard/page.tsx` (modified, +137 LOC) - Main route
+- `types/feature.ts` (new, 87 LOC) - Type definitions
+- 5 API routes (create, update, delete, bulk actions)
+
+**Why it's A+:**
+- ✅ Every file directly serves an AC item (17 AC → ~1500 LOC = 88 LOC/AC)
+- ✅ Size proportional to scope (complex feature with 6 components + 5 API routes)
+- ✅ Zero scope creep - no refactoring of unrelated code
+- ✅ Type safety maintained (proper types, no `any` usage)
+- ✅ Follows existing patterns in codebase
+- ✅ Clear separation of concerns (UI, data, types, API)
+- ✅ Build succeeds, all tests pass
+
+**Automated Checks:**
+- Type issues: 0
+- Deleted tests: 0
+- Files changed: 20
+- Diff size: +2107 -554 (net: +1553)
+- LOC per AC: 88 (reasonable for complex feature)
+
+**Verdict:** `READY_FOR_MERGE` - Gold standard A+ implementation
+
+---
+
+## ⚠️ Acceptable but Not A+
+
+**AC:** Add bulk edit modal (6 AC items)
+
+**Changes** (420 net LOC, 12 files):
+- `components/feature/BulkEditModal.tsx` (new, 280 LOC)
+- `lib/queries/items.ts` (modified, +85 LOC)
+- `app/feature/actions.ts` (modified, +45 LOC)
+- 9 other files (minor changes, imports, types)
+
+**Issues:**
+- ⚠️ BulkEditModal is 280 LOC - could be split into smaller components
+- ⚠️ Added 3 utility functions not directly used by AC
+- ⚠️ Changed formatting in 2 unrelated files ("while I was here" changes)
+
+**Why it's acceptable:**
+- ✅ All AC met
+- ✅ No type safety violations
+- ✅ Tests pass
+- ⚠️ Some scope creep (utility functions, formatting)
+- ⚠️ Could be cleaner (large component, unrelated changes)
+
+**Automated Checks:**
+- Type issues: 0
+- Deleted tests: 0
+- Files changed: 12 (higher than expected for 6 AC)
+- Diff size: +445 -25 (net: +420)
+
+**Verdict:** `AC_MET_BUT_NOT_A_PLUS` - Works but has technical debt
+
+**Recommendations:**
+1. Split BulkEditModal into 3 components (Form, Preview, Actions)
+2. Remove unused utility functions
+3. Revert formatting changes in unrelated files
+
+---
+
+## ❌ Needs Rework
+
+**AC:** Display reviews on detail page (3 simple AC items)
+
+**Changes** (890 net LOC, 23 files):
+- Rewrote entire reviews system (not in AC)
+- Added new API routes (not in AC)
+- Refactored unrelated queries (not in AC)
+- Changed database schema without migration (BLOCKER)
+- Removed type annotations from 5 functions (type safety violation)
+- Deleted 2 test files to "make build pass" (BLOCKER)
+
+**Issues:**
+- ❌ Massive scope creep - AC only asked for display, got full rewrite
+- ❌ Schema changes without migration
+- ❌ Type safety violations
+- ❌ Deleted tests
+- ❌ Changed 20 unrelated files
+
+**Automated Checks:**
+- Type issues: 5
+- Deleted tests: 2 ❌ BLOCKER
+- Files changed: 23 (way too many for 3 simple AC)
+- Diff size: +920 -30 (net: +890)
+
+**Verdict:** `AC_NOT_MET` - Scope creep and quality violations
+
+**Required Fixes:**
+1. Revert all changes
+2. Start over with minimal implementation (display only)
+3. Do NOT refactor, rewrite, or change schema
+4. Do NOT delete tests
+5. Target <100 LOC for 3 simple AC