From 0530aec8f4a9908a54e095cc09952a654417ba1e Mon Sep 17 00:00:00 2001 From: Dave Date: Mon, 23 Feb 2026 12:44:43 +0000 Subject: [PATCH] story-kit: create 66_story_pipeline_stage_state_machine_spike --- ...tory_pipeline_stage_state_machine_spike.md | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 .story_kit/work/1_upcoming/66_story_pipeline_stage_state_machine_spike.md diff --git a/.story_kit/work/1_upcoming/66_story_pipeline_stage_state_machine_spike.md b/.story_kit/work/1_upcoming/66_story_pipeline_stage_state_machine_spike.md new file mode 100644 index 0000000..a3339dd --- /dev/null +++ b/.story_kit/work/1_upcoming/66_story_pipeline_stage_state_machine_spike.md @@ -0,0 +1,25 @@ +--- +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