From 4294b48af0e761b9ae21bc509581c1687dd87c7d Mon Sep 17 00:00:00 2001 From: Dave Date: Mon, 23 Feb 2026 15:52:02 +0000 Subject: [PATCH] story-kit: remove 66_spike_pipeline_stage_state_machine --- .../66_spike_pipeline_stage_state_machine.md | 25 ------------------- 1 file changed, 25 deletions(-) delete mode 100644 .story_kit/work/1_upcoming/66_spike_pipeline_stage_state_machine.md diff --git a/.story_kit/work/1_upcoming/66_spike_pipeline_stage_state_machine.md b/.story_kit/work/1_upcoming/66_spike_pipeline_stage_state_machine.md deleted file mode 100644 index a3339dd..0000000 --- a/.story_kit/work/1_upcoming/66_spike_pipeline_stage_state_machine.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -name: Pipeline Stage State Machine Spike -test_plan: pending ---- - -# Story 66: Pipeline Stage State Machine Spike - -## User Story - -As a Story Kit developer, I want to explore a generalised pipeline stage pattern where each stage is defined by filesystem convention (config.toml, setup script, verify script) and the server drives a uniform loop: enter, validate, setup, execute agent, verify, gate, advance. - -## Acceptance Criteria - -- [ ] Document the proposed directory structure: .story_kit/pipeline/{stage}/config.toml|setup|verify -- [ ] Document how work/ directories mirror pipeline/ definitions -- [ ] Document config.toml schema: agent name, gate policy (advance vs hold) -- [ ] Document how setup and verify scripts work (executables, exit 0 = pass, env vars passed in) -- [ ] Document how custom stages would work (user-defined, no Rust changes needed) -- [ ] Document how human-in-the-loop gates work at each stage (configurable auto-advance vs hold-for-approval) -- [ ] Evaluate trade-offs vs current hardcoded stage approach -- [ ] Recommend: implement as-is, simplify, or defer - -## Out of Scope - -- TBD