Windsurf rules

1---
2name: inspect-quality
3model: sonnet
4description: "Interactive QA session where user reports bugs or issues conversationally, and the agent logs them to specs/bugs/registry.yaml with a structured audit schema. Explores the codebase in the background for context and domain language. Use when user wants to report bugs, do QA, or mentions \"QA session\"."
5---
6 
7# Inspect Quality
8> **HARD GATE** — **HARD GATE** — Quality metrics (coverage, lint, cyclomatic complexity, security scans) must be monitored. If a metric degrades, surface it as a blocker. Do NOT accept regressions.
9 
10 
11Run an interactive QA session. The user describes problems they're encountering. You clarify, explore the codebase for context, and log each issue to `specs/bugs/registry.yaml` with a structured, durable format.
12 
13## For each issue the user raises
14 
15### 1. Listen and lightly clarify
16 
17Let the user describe the problem in their own words. Ask **at most 2–3 short clarifying questions** focused on:
18 
19- What they expected vs what actually happened
20- Steps to reproduce (if not obvious)
21- Whether it's consistent or intermittent
22 
23Do NOT over-interview. If the description is clear enough to log, move on.
24 
25### 2. Explore the codebase in the background
26 
27Kick off an Agent (subagent_type=Explore) to understand the relevant area. The goal is NOT to find a fix — it's to:
28 
29- Learn the domain language used in that area (check `specs/UBIQUITOUS_LANGUAGE_LATEST.md` if present)
30- Understand what the feature is supposed to do
31- Identify the user-facing behavior boundary
32 
33### 3. Assess scope: single issue or breakdown?
34 
35Break down when:
36 
37- The fix spans multiple independent areas
38- There are clearly separable concerns that could be worked on in parallel
39- The user describes something with multiple distinct failure modes
40 
41Keep as a single issue when:
42 
43- It's one behavior that's wrong in one place
44- The symptoms are all caused by the same root behavior
45 
46### 4. Log to specs/bugs/registry.yaml
47 
48Append the issue to `specs/bugs/registry.yaml`. Create the `specs/bugs/` directory if it doesn't exist.
49 
50#### registry.yaml format
51 
52The file maintains a Markdown table with the following columns (derived from structured audit practice):
53 
54| Field | Description |
55|-------|-------------|
56| `bug_id` | `BUG-YYYY-MM-DDTHHMMSS` |
57| `date` | `YYYY-MM-DD` |
58| `severity` | `critical` / `high` / `medium` / `low` |
59| `priority` | `p0` / `p1` / `p2` / `p3` |
60| `scope` | kebab-case area (e.g. `auth`, `checkout`) |
61| `what_happened` | actual behavior (user-facing terms) |
62| `what_expected` | expected behavior |
63| `steps_to_reproduce` | numbered steps |
64| `root_cause` | one-line hypothesis |
65| `files_changed` | filled in after fix |
66| `approach` | filled in after fix |
67| `risk_level` | `low` / `medium` / `high` |
68| `new_tests` | count (filled in after fix) |
69| `type_check` | `pass` / `fail` (filled in after fix) |
70| `lint` | `pass` / `fail` (filled in after fix) |
71| `commit_type` | `fix` / `fix!` / `feat` (filled in after fix) |
72| `release_type` | `patch` / `minor` / `major` (filled in after fix) |
73| `commit_message` | Conventional Commits message (filled in after fix) |
74| `follow_ups` | semicolon-separated follow-up items |
75| `file` | path to detailed `specs/bugs/BUG-*.md` (filled in by investigate-bug) |
76| `status` | `open` / `in-progress` / `fixed` / `wont-fix` |
77 
78When a bug is fixed (via `validate-fix`), update the relevant row with the resolution fields.
79 
80#### Issue body (for context below the table)
81 
82For each bug, also append a detail section:
83 
84```markdown
85### BUG-YYYY-MM-DDTHHMMSS: [short title]
86 
87**What happened:** [actual behavior, plain language]
88**What I expected:** [expected behavior]
89**Steps to reproduce:**
901. [Step 1]
912. [Step 2]
92 
93**Additional context:** [domain-language observations, no file paths]
94```
95 
96#### Rules for all entries
97 
98- **bug_id** uses full timestamp: `BUG-YYYY-MM-DDTHHMMSS` — matches the individual bug file name in `specs/bugs/`
99- **No file paths or line numbers** — these go stale
100- **Use the project's domain language** (check `specs/UBIQUITOUS_LANGUAGE_LATEST.md` if it exists)
101- **Describe behaviors, not code** — "the sync service fails to apply the patch" not "applyPatch() throws"
102- **Reproduction steps are mandatory** — if you can't determine them, ask the user
103 
104### 5. Continue the session
105 
106After logging, ask: "Next issue, or are we done?" Keep going until the user says done. Each issue is independent — don't batch them.
107