story-kit: queue 92_spike_stop_auto_committing_intermediate_pipeline_moves for QA

.story_kit/work/2_current/92_spike_stop_auto_committing_intermediate_pipeline_moves.md

@@ -1,56 +0,0 @@
----
-name: "Stop auto-committing intermediate pipeline moves"
-agent: "coder-opus"
----
-
-# 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 -> done -> archive) while still committing at terminal states (creation in upcoming, acceptance in done and 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)