story-kit: create 92_spike_stop_auto_committing_intermediate_pipeline_moves

.story_kit/work/1_upcoming/92_spike_stop_auto_committing_intermediate_pipeline_moves.md

@@ -0,0 +1,55 @@
+---
+name: "Stop auto-committing intermediate pipeline moves"
+---
+
+# Spike 92: Stop auto-committing intermediate pipeline moves
+
+## Goal
+
+Determine how to stop the filesystem watcher from auto-committing every pipeline stage move (upcoming -> current -> qa -> merge) while still committing at terminal states (creation in upcoming, acceptance in archived). This keeps git history clean while preserving cross-machine portability for completed work.
+
+## Context
+
+The watcher in `server/src/io/watcher.rs` currently auto-commits every file change in `.story_kit/work/`. A single story run generates 5+ commits just from pipeline moves:
+- `story-kit: create 42_story_foo`
+- `story-kit: start 42_story_foo`
+- `story-kit: queue 42_story_foo for QA`
+- `story-kit: queue 42_story_foo for merge`
+- `story-kit: accept 42_story_foo`
+
+Since story runs complete relatively quickly, the intermediate state (current/qa/merge) is transient and doesn't need to be committed. Only creation and archival are meaningful checkpoints.
+
+## Questions to Answer
+
+1. Can we filter `stage_metadata()` to only commit for `1_upcoming` and `5_archived` stages while still broadcasting `WatcherEvent`s for all stages (so the frontend stays in sync)?
+2. Should we keep `git add -A .story_kit/work/` for the committed stages, or narrow it to only the specific file?
+3. What happens if the server crashes mid-pipeline? Uncommitted moves are lost — is this acceptable given the story can just be re-run?
+4. Should intermediate moves be `.gitignore`d at the directory level, or is filtering in the watcher sufficient?
+5. Do any other parts of the system (agent worktree setup, merge_agent_work, sparse checkout) depend on intermediate pipeline files being committed to master?
+
+## Approach to Investigate
+
+### Option A: Filter in `flush_pending()`
+- In `flush_pending()`, still broadcast the `WatcherEvent` for all stages
+- Only call `git_add_work_and_commit()` for stages `1_upcoming` and `5_archived`
+- Simplest change — ~5 lines modified in `watcher.rs`
+
+### Option B: Two-tier watcher
+- Split into "commit-worthy" events (create, archive) and "notify-only" events (start, qa, merge)
+- Commit-worthy events go through git
+- Notify-only events just broadcast to WebSocket clients
+- More explicit but same end result as Option A
+
+### Option C: .gitignore intermediate directories
+- Add `2_current/`, `3_qa/`, `4_merge/` to `.gitignore`
+- Watcher still sees events (gitignore doesn't affect filesystem watching)
+- Git naturally ignores them
+- Risk: harder to debug, `git status` won't show pipeline state
+
+## Acceptance Criteria
+
+- [ ] Spike document updated with findings and recommendation
+- [ ] If Option A is viable: prototype the change and verify git log is clean during a full story run
+- [ ] Confirm frontend still receives real-time pipeline updates for all stages
+- [ ] Confirm no other system depends on intermediate pipeline commits being on master
+- [ ] Identify any edge cases (server crash, manual git operations, multi-machine sync)