Add FTS5 project search with dual-backend indexing

.claude/commands/implement.md

@@ -16,10 +16,18 @@ You implement features as small, complete vertical slices with continuous testin
 
 ## Workflow
 
-### 1. Load Spec & Assess Blast Radius
+### 1. Load Spec & Search for Context
 
 Read the relevant `/specs/{feature}.md` file. If multiple specs exist and it's unclear which one, ask the user.
 
+**Search for related code**: Before writing any code, use the spec's title and key terms to search the codebase for relevant existing code:
+
+```bash
+draft search "<spec title and key terms>" --limit 10
+```
+
+Review the search results to understand existing patterns, related modules, and potential conflicts. Use these results to inform your implementation approach.
+
 Before writing any code, assess the change:
 
 - **Which modules/files will this touch?** List them. If the spec has an "Affected Modules" section, verify it's still accurate.

.claude/commands/refine.md

@@ -57,7 +57,18 @@ Refine an existing specification based on new insights, feedback, or changing re
 **Refinement 2026-01-25**: Updated approach to use WebSocket instead of polling based on performance testing results. Added new acceptance criterion for connection handling. Blast radius unchanged — change is contained within the `transport` module.
 ```
 
-Remember:
+## Update Search Index
+
+After saving the refined spec, update the project search index:
+
+```bash
+draft index
+```
+
+This runs incrementally (~50ms). Do not show the output to the user unless it fails.
+
+## Reminders
+
 - Keep refinements focused and minimal
 - Preserve the spec's history through notes
 - Suggest new specs for major scope changes

.claude/commands/spec.md

@@ -77,6 +77,16 @@ Present the spec summary and ask: "Does this capture what you want? I'll impleme
 
 If the user wants changes, revise the spec and confirm again.
 
+### Phase 4: Update Search Index
+
+After writing the spec file, update the project search index so the new spec is immediately discoverable:
+
+```bash
+draft index
+```
+
+This runs incrementally (~50ms) and only re-indexes the changed file. Do not show the output to the user unless it fails.
+
 ## Reference
 
 See `/specs/TEMPLATE.md` for the spec file format.

.claude/rules/draft-search.md

@@ -0,0 +1,19 @@
+## Code Search
+
+Use `draft search` for finding relevant code and context:
+- `draft search "query"` — find files by concept, feature, or pattern
+- `draft search "query" --files-only` — file paths only
+
+Prefer `draft search` over Grep/Glob when:
+- Looking for where a feature or concept is implemented
+- Checking what exists before writing new code or specs
+- Searching with natural language rather than exact patterns
+- Searching for partial identifiers or symbol names
+
+Prefer Grep when:
+- Matching an exact string or regex
+- Counting occurrences
+- Searching within a single known file
+
+The search index updates automatically after `/spec` and `/refine`.
+Run `draft index` manually after `git pull` or branch switches.

.cursor/rules/draft-search.md

@@ -0,0 +1,19 @@
+## Code Search
+
+Use `draft search` for finding relevant code and context:
+- `draft search "query"` — find files by concept, feature, or pattern
+- `draft search "query" --files-only` — file paths only
+
+Prefer `draft search` over Grep/Glob when:
+- Looking for where a feature or concept is implemented
+- Checking what exists before writing new code or specs
+- Searching with natural language rather than exact patterns
+- Searching for partial identifiers or symbol names
+
+Prefer Grep when:
+- Matching an exact string or regex
+- Counting occurrences
+- Searching within a single known file
+
+The search index updates automatically after `/spec` and `/refine`.
+Run `draft index` manually after `git pull` or branch switches.

.cursor/skills/implement/SKILL.md

@@ -15,10 +15,18 @@ You implement features as small, complete vertical slices with continuous testin
 
 ## Workflow
 
-### 1. Load Spec & Assess Blast Radius
+### 1. Load Spec & Search for Context
 
 Read the relevant `/specs/{feature}.md` file. If multiple specs exist and it's unclear which one, ask the user.
 
+**Search for related code**: Before writing any code, use the spec's title and key terms to search the codebase for relevant existing code:
+
+```bash
+draft search "<spec title and key terms>" --limit 10
+```
+
+Review the search results to understand existing patterns, related modules, and potential conflicts. Use these results to inform your implementation approach.
+
 Before writing any code, assess the change:
 
 - **Which modules/files will this touch?** List them. If the spec has an "Affected Modules" section, verify it's still accurate.

.cursor/skills/refine/SKILL.md

@@ -58,7 +58,18 @@ Refine an existing specification based on new insights, feedback, or changing re
 **Refinement 2026-01-25**: Updated approach to use WebSocket instead of polling based on performance testing results. Added new acceptance criterion for connection handling. Blast radius unchanged — change is contained within the `transport` module.
 ```
 
-Remember:
+## Update Search Index
+
+After saving the refined spec, update the project search index:
+
+```bash
+draft index
+```
+
+This runs incrementally (~50ms). Do not show the output to the user unless it fails.
+
+## Reminders
+
 - Keep refinements focused and minimal
 - Preserve the spec's history through notes
 - Suggest new specs for major scope changes

.cursor/skills/spec/SKILL.md

@@ -76,6 +76,16 @@ Present the spec summary and ask: "Does this capture what you want? I'll impleme
 
 If the user wants changes, revise the spec and confirm again.
 
+### Phase 4: Update Search Index
+
+After writing the spec file, update the project search index so the new spec is immediately discoverable:
+
+```bash
+draft index
+```
+
+This runs incrementally (~50ms) and only re-indexes the changed file. Do not show the output to the user unless it fails.
+
 ## Reference
 
 See `/specs/TEMPLATE.md` for the spec file format.

cmd/draft/templates/.claude/commands/implement.md

@@ -0,0 +1,99 @@
+---
+name: implement
+description: Implement features with phase checkpoints. Use after a spec exists in .claude/specs/ or when implementing a confirmed specification.
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, TodoWrite, AskUserQuestion
+---
+
+# Implementation
+
+You implement features as small, complete vertical slices with continuous testing.
+
+## When to Activate
+
+- After the spec skill has created and confirmed a specification
+- When user says "implement" and a spec file exists
+- When user explicitly references a spec file
+
+## Workflow
+
+### 1. Load Spec & Search for Context
+
+Read the relevant `/specs/{feature}.md` file. If multiple specs exist and it's unclear which one, ask the user.
+
+**Search for related code**: Before writing any code, use the spec's title and key terms to search the codebase for relevant existing code:
+
+```bash
+draft search "<spec title and key terms>" --limit 10
+```
+
+Review the search results to understand existing patterns, related modules, and potential conflicts. Use these results to inform your implementation approach.
+
+Before writing any code, assess the change:
+
+- **Which modules/files will this touch?** List them. If the spec has an "Affected Modules" section, verify it's still accurate.
+- **Are we modifying shared code?** Changing a shared utility, interface, or base class affects every consumer. Flag this to the user.
+- **Can we contain the change?** Prefer adding new files/functions over modifying widely-imported ones. Prefer narrow interfaces that isolate the new behaviour from the rest of the codebase.
+- **Are we adding new dependencies?** Each dependency is a coupling point. Avoid unless clearly justified.
+
+If the blast radius is wider than expected, flag it: *"This will touch N modules beyond what the spec anticipated. Want to proceed or restructure?"*
+
+
+### 2. Implement
+
+Implement the spec as **one integrated piece** — types, logic, wiring, and tests together. A small vertical slice doesn't need artificial separation into "foundation" and "core logic" and "integration" phases.
+
+Important: Follow the design principles outlined in .principles/design-principles.md
+
+Use TodoWrite to track progress against the spec's acceptance criteria.
+
+**Design for modularity as you go:**
+- Place new behaviour behind clear interfaces — functions, types, modules — so callers don't depend on implementation details.
+- Avoid reaching into the internals of other modules. If you need something, use or extend its public interface.
+- Keep new files/functions narrowly focused. One responsibility per unit.
+- If a change to shared code is unavoidable, make the interface change first, verify existing tests still pass, then build the new behaviour on top.
+
+**Test continuously:**
+- After each meaningful change, run existing tests to catch regressions early.
+- Write tests for new behaviour as you implement it, not after.
+- If the project has a linter or build step, run it periodically — don't wait until the end.
+
+**Follow design principles:**
+- 
+
+### 3. Verify & Complete
+
+Before marking the feature complete:
+
+1. Run the **full test suite** — not just new tests.
+2. Run the **build/linter** if the project has one.
+3. Re-read the spec's acceptance criteria and check each one explicitly.
+4. Report: "Criterion met" or "Needs attention: {issue}" for each.
+
+Only mark complete when all criteria pass and the build is green.
+
+After successful implementation:
+- **Update spec status** from `proposed` to `implemented`
+- Check off completed acceptance criteria in the spec file
+- Add any notes about implementation decisions
+
+## Checkpoint Behaviour
+
+Since each spec is a small vertical slice, heavy checkpointing is unnecessary.
+
+**Do checkpoint** (pause and ask the user) when:
+- The blast radius turns out wider than expected
+- You face a design decision with trade-offs the user should weigh
+- A test failure reveals a deeper issue that changes the approach
+
+**Skip checkpoint** for:
+- Normal forward progress within the spec
+- Minor follow-up fixes
+- Formatting/cleanup
+- When user explicitly says "continue without asking"
+
+## Recovery
+
+If implementation is interrupted:
+- TodoWrite preserves progress
+- Spec file shows which criteria are done
+- User can say "continue implementing {feature}" to resume

cmd/draft/templates/.claude/commands/refine.md

@@ -0,0 +1,74 @@
+---
+description: Refines existing specs
+---
+
+# Refine Existing Spec
+
+Refine an existing specification based on new insights, feedback, or changing requirements.
+
+**Feature to refine:** $ARGUMENTS
+
+## Instructions
+
+1. **Load the existing spec** from `/specs/{feature}.md`
+   - If no spec exists for this feature, suggest using `/spec` instead
+   - If multiple specs match, ask the user which one to refine
+
+2. **Ask 2-3 focused refinement questions** (one at a time):
+   - What aspect needs refinement? (goals, criteria, approach, scope)
+   - What new information or feedback has emerged?
+   - Are there specific pain points with the current spec?
+
+3. **Check scope and modularity:**
+   - Does the refinement keep the spec small enough for a single vertical slice?
+   - If criteria are being added, does the total still stay at ~5 or fewer?
+   - Does the refinement change which modules are affected? Update the "Affected Modules" section.
+   - If the refinement significantly expands scope or blast radius, suggest a separate spec instead.
+
+4. **Update the spec in place**:
+   - **Preserve front-matter**: Keep all existing front-matter fields (title, description, author). Keep `status: proposed` (refinements don't change status)
+   - Preserve completed acceptance criteria checkboxes
+   - Update goals, criteria, or approach as needed
+   - Update "Affected Modules" and "Test Strategy" if the changes alter them
+   - Add to "Out of Scope" if removing features
+   - Add refinement notes to the "Notes" section with timestamp
+
+5. **Show a diff summary**:
+   - Highlight what changed (goals, new criteria, removed items, affected modules, etc.)
+   - Ask for confirmation before saving
+
+6. **Get user confirmation** before proceeding to implementation
+   - If confirmed, use the **implement** skill with the refined spec
+   - If not, ask if they want to refine further
+
+## Refinement Guidelines
+
+- **Preserve progress**: Don't uncheck completed criteria unless they're no longer valid
+- **Be additive when possible**: Add new criteria rather than rewriting existing ones
+- **Document changes**: Always add a timestamped note explaining what was refined and why
+- **Validate scope**: Check if refinements are expanding scope significantly - if so, suggest a new spec
+- **Validate modularity**: If the refinement introduces new module dependencies or widens the blast radius, flag it explicitly
+
+## Example Refinement Note
+
+```markdown
+## Notes
+
+**Refinement 2026-01-25**: Updated approach to use WebSocket instead of polling based on performance testing results. Added new acceptance criterion for connection handling. Blast radius unchanged — change is contained within the `transport` module.
+```
+
+## Update Search Index
+
+After saving the refined spec, update the project search index:
+
+```bash
+draft index
+```
+
+This runs incrementally (~50ms). Do not show the output to the user unless it fails.
+
+## Reminders
+
+- Keep refinements focused and minimal
+- Preserve the spec's history through notes
+- Suggest new specs for major scope changes