From 03f243b6701ab4433f4be23a407fe82de1df5258 Mon Sep 17 00:00:00 2001 From: Dave Date: Mon, 23 Feb 2026 19:37:28 +0000 Subject: [PATCH] story-kit: create 92_spike_stop_auto_committing_intermediate_pipeline_moves --- ..._committing_intermediate_pipeline_moves.md | 55 +++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 .story_kit/work/1_upcoming/92_spike_stop_auto_committing_intermediate_pipeline_moves.md diff --git a/.story_kit/work/1_upcoming/92_spike_stop_auto_committing_intermediate_pipeline_moves.md b/.story_kit/work/1_upcoming/92_spike_stop_auto_committing_intermediate_pipeline_moves.md new file mode 100644 index 0000000..43b7555 --- /dev/null +++ b/.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)