232 lines
11 KiB
Markdown
232 lines
11 KiB
Markdown
# Story Kit: The Story-Driven Spec Workflow (SDSW)
|
|
|
|
**Target Audience:** Large Language Models (LLMs) acting as Senior Engineers.
|
|
**Goal:** To maintain long-term project coherence, prevent context window exhaustion, and ensure high-quality, testable code generation in large software projects.
|
|
|
|
---
|
|
|
|
## 1. The Philosophy
|
|
|
|
We treat the codebase as the implementation of a **"Living Specification."** driven by **User Stories**
|
|
Instead of ephemeral chat prompts ("Fix this", "Add that"), we work through persistent artifacts.
|
|
* **Stories** define the *Change*.
|
|
* **Specs** define the *Truth*.
|
|
* **Code** defines the *Reality*.
|
|
|
|
**The Golden Rule:** You are not allowed to write code until the Spec reflects the new reality requested by the Story.
|
|
|
|
---
|
|
|
|
## 2. Directory Structure
|
|
|
|
When initializing a new project under this workflow, create the following structure immediately:
|
|
|
|
```text
|
|
project_root/
|
|
.story_kit
|
|
|-- README.md # This document
|
|
├── stories/ # The "Inbox" of feature requests.
|
|
├── specs/ # The "Brain" of the project.
|
|
│ ├── README.md # Explains this workflow to future sessions.
|
|
│ ├── 00_CONTEXT.md # High-level goals, domain definition, and glossary.
|
|
│ ├── tech/ # Implementation details (Stack, Architecture, Constraints).
|
|
│ │ └── STACK.md # The "Constitution" (Languages, Libs, Patterns).
|
|
│ └── functional/ # Domain logic (Platform-agnostic behavior).
|
|
│ ├── 01_CORE.md
|
|
│ └── ...
|
|
└── src/ # The Code.
|
|
```
|
|
|
|
---
|
|
|
|
## 3. The Cycle (The "Loop")
|
|
|
|
When the user asks for a feature, follow this 4-step loop strictly:
|
|
|
|
### Step 1: The Story (Ingest)
|
|
* **User Input:** "I want the robot to dance."
|
|
* **Action:** Create a file `stories/XX_robot_dance.md`.
|
|
* **Content:**
|
|
* **User Story:** "As a user, I want..."
|
|
* **Acceptance Criteria:** Bullet points of observable success.
|
|
* **Out of scope:** Things that are out of scope so that the LLM doesn't go crazy
|
|
* **Git:** Make a local feature branch for the story, named from the story (e.g., `feature/story-33-camera-format-auto-selection`). You must create and switch to the feature branch before making any edits.
|
|
|
|
### Step 2: The Spec (Digest)
|
|
* **Action:** Update the files in `specs/`.
|
|
* **Logic:**
|
|
* Does `specs/functional/LOCOMOTION.md` exist? If no, create it.
|
|
* Add the "Dance" state to the state machine definition in the spec.
|
|
* Check `specs/tech/STACK.md`: Do we have an approved animation library? If no, propose adding one to the Stack or reject the feature.
|
|
* **Output:** Show the user the diff of the Spec. **Wait for approval.**
|
|
|
|
### Step 3: The Implementation (Code)
|
|
* **Action:** Write the code to match the *Spec* (not just the Story).
|
|
* **Constraint:** adhere strictly to `specs/tech/STACK.md` (e.g., if it says "No `unwrap()`", you must not use `unwrap()`).
|
|
|
|
### Step 4: Verification (Close)
|
|
* **Action:** Write a test case that maps directly to the Acceptance Criteria in the Story.
|
|
* **Action:** Run compilation and make sure it succeeds without errors. Consult `specs/tech/STACK.md` and run all required linters listed there (treat warnings as errors). Run tests and make sure they all pass before proceeding. Ask questions here if needed.
|
|
* **Action:** Do not accept stories yourself. Ask the user if they accept the story. If they agree, move the story file to `stories/archive/`. Tell the user they should commit (this gives them the chance to exclude files via .gitignore if necessary).
|
|
* **Action:** When the user accepts:
|
|
1. Move the story file to `stories/archive/` (e.g., `mv stories/XX_story_name.md stories/archive/`)
|
|
2. Commit both changes to the feature branch
|
|
3. Perform the squash merge: `git merge --squash feature/story-name`
|
|
4. Commit to master with a comprehensive commit message
|
|
5. Delete the feature branch: `git branch -D feature/story-name`
|
|
* **Important:** Do NOT mark acceptance criteria as complete before user acceptance. Only mark them complete when the user explicitly accepts the story.
|
|
|
|
**CRITICAL - NO SUMMARY DOCUMENTS:**
|
|
* **NEVER** create a separate summary document (e.g., `STORY_XX_SUMMARY.md`, `IMPLEMENTATION_NOTES.md`, etc.)
|
|
* **NEVER** write terminal output to a markdown file for "documentation purposes"
|
|
* The `specs/` folder IS the documentation. Keep it updated after each story.
|
|
* If you find yourself typing `cat << 'EOF' > SUMMARY.md` or similar, **STOP IMMEDIATELY**.
|
|
* The only files that should exist after story completion:
|
|
* Updated code in `src/`
|
|
* Updated specs in `specs/`
|
|
* Archived story in `stories/archive/`
|
|
|
|
---
|
|
|
|
|
|
## 3.5. Bug Workflow (Simplified Path)
|
|
|
|
Not everything needs to be a full story. Simple bugs can skip the story process:
|
|
|
|
### When to Use Bug Workflow
|
|
* Defects in existing functionality (not new features)
|
|
* State inconsistencies or data corruption
|
|
* UI glitches that don't require spec changes
|
|
* Performance issues with known fixes
|
|
|
|
### Bug Process
|
|
1. **Document Bug:** Create `bugs/bug-N-short-description.md` with:
|
|
* **Symptom:** What the user observes
|
|
* **Root Cause:** Technical explanation (if known)
|
|
* **Reproduction Steps:** How to trigger the bug
|
|
* **Proposed Fix:** Brief technical approach
|
|
* **Workaround:** Temporary solution if available
|
|
2. **Fix Immediately:** Make minimal code changes to fix the bug
|
|
3. **Archive:** Move fixed bugs to `bugs/archive/` when complete
|
|
4. **No Spec Update Needed:** Unless the bug reveals a spec deficiency
|
|
|
|
### Bug vs Story
|
|
* **Bug:** Existing functionality is broken → Fix it
|
|
* **Story:** New functionality is needed → Spec it, then build it
|
|
* **Spike:** Uncertainty/feasibility discovery → Run spike workflow
|
|
|
|
---
|
|
|
|
## 3.6. Spike Workflow (Research Path)
|
|
|
|
Not everything needs a story or bug fix. Spikes are time-boxed investigations to reduce uncertainty.
|
|
|
|
### When to Use a Spike
|
|
* Unclear root cause or feasibility
|
|
* Need to compare libraries/encoders/formats
|
|
* Need to validate performance constraints
|
|
|
|
### Spike Process
|
|
1. **Document Spike:** Create `spikes/spike-N-short-description.md` with:
|
|
* **Question:** What you need to answer
|
|
* **Hypothesis:** What you expect to be true
|
|
* **Timebox:** Strict limit for the research
|
|
* **Investigation Plan:** Steps/tools to use
|
|
* **Findings:** Evidence and observations
|
|
* **Recommendation:** Next step (Story, Bug, or No Action)
|
|
2. **Execute Research:** Stay within the timebox. No production code changes.
|
|
3. **Escalate if Needed:** If implementation is required, open a Story or Bug and follow that workflow.
|
|
4. **Archive:** Move completed spikes to `spikes/archive/`.
|
|
|
|
### Spike Output
|
|
* Decision and evidence, not production code
|
|
* Specs updated only if the spike changes system truth
|
|
|
|
---
|
|
|
|
## 4. Context Reset Protocol
|
|
|
|
When the LLM context window fills up (or the chat gets slow/confused):
|
|
1. **Stop Coding.**
|
|
2. **Instruction:** Tell the user to open a new chat.
|
|
3. **Handoff:** The only context the new LLM needs is in the `specs/` folder.
|
|
* *Prompt for New Session:* "I am working on Project X. Read `specs/00_CONTEXT.md` and `specs/tech/STACK.md`. Then look at `stories/` to see what is pending."
|
|
|
|
|
|
---
|
|
|
|
## 5. Setup Instructions (For the LLM)
|
|
|
|
If a user hands you this document and says "Apply this process to my project":
|
|
|
|
1. **Analyze the Request:** Ask for the high-level goal ("What are we building?") and the tech preferences ("Rust or Python?").
|
|
2. **Git Check:** Check if the directory is a git repository (`git status`). If not, run `git init`.
|
|
3. **Scaffold:** Run commands to create the `specs/` and `stories/` folders.
|
|
4. **Draft Context:** Write `specs/00_CONTEXT.md` based on the user's answer.
|
|
5. **Draft Stack:** Write `specs/tech/STACK.md` based on best practices for that language.
|
|
6. **Wait:** Ask the user for "Story #1".
|
|
|
|
---
|
|
|
|
## 6. Code Quality Tools
|
|
|
|
**MANDATORY:** Before completing Step 4 (Verification) of any story, you MUST run all applicable linters and fix ALL errors and warnings. Zero tolerance for warnings or errors.
|
|
|
|
**AUTO-RUN CHECKS:** Always run the required lint/test/build checks as soon as relevant changes are made. Do not ask for permission to run them—run them automatically and fix any failures.
|
|
|
|
**ALWAYS FIX DIAGNOSTICS:** At every stage, you must proactively fix all errors and warnings without waiting for user confirmation. Do not pause to ask whether to fix diagnostics—fix them immediately as part of the workflow.
|
|
|
|
### TypeScript/JavaScript: Biome
|
|
|
|
* **Tool:** [Biome](https://biomejs.dev/) - Fast formatter and linter
|
|
* **Check Command:** `npx @biomejs/biome check src/`
|
|
* **Fix Command:** `npx @biomejs/biome check --write src/`
|
|
* **Unsafe Fixes:** `npx @biomejs/biome check --write --unsafe src/`
|
|
* **Configuration:** `biome.json` in project root
|
|
* **When to Run:**
|
|
* After every code change to TypeScript/React files
|
|
* Before committing any frontend changes
|
|
* During Step 4 (Verification) - must show 0 errors, 0 warnings
|
|
|
|
**Biome Rules to Follow:**
|
|
* No `any` types (use proper TypeScript types or `unknown`)
|
|
* No array index as `key` in React (use stable IDs)
|
|
* No assignments in expressions (extract to separate statements)
|
|
* All buttons must have explicit `type` prop (`button`, `submit`, or `reset`)
|
|
* Mouse events must be accompanied by keyboard events for accessibility
|
|
* Use template literals instead of string concatenation
|
|
* Import types with `import type { }` syntax
|
|
* Organize imports automatically
|
|
|
|
### Rust: Clippy
|
|
|
|
* **Tool:** [Clippy](https://github.com/rust-lang/rust-clippy) - Rust linter
|
|
* **Check Command:** `cargo clippy --all-targets --all-features`
|
|
* **Fix Command:** `cargo clippy --fix --allow-dirty --allow-staged`
|
|
* **When to Run:**
|
|
* After every code change to Rust files
|
|
* Before committing any backend changes
|
|
* During Step 4 (Verification) - must show 0 errors, 0 warnings
|
|
|
|
**Clippy Rules to Follow:**
|
|
* No unused variables (prefix with `_` if intentionally unused)
|
|
* No dead code (remove or mark with `#[allow(dead_code)]` if used conditionally)
|
|
* Use `?` operator instead of explicit error handling where possible
|
|
* Prefer `if let` over `match` for single-pattern matches
|
|
* Use meaningful variable names
|
|
* Follow Rust idioms and best practices
|
|
|
|
### Build Verification Checklist
|
|
|
|
Before asking for user acceptance in Step 4:
|
|
|
|
- [ ] Run `cargo clippy` (Rust) - 0 errors, 0 warnings
|
|
- [ ] Run `cargo check` (Rust) - successful compilation
|
|
- [ ] Run `cargo test` (Rust) - all tests pass
|
|
- [ ] Run `npx @biomejs/biome check src/` (TypeScript) - 0 errors, 0 warnings
|
|
- [ ] Run `npm run build` (TypeScript) - successful build
|
|
- [ ] Manually test the feature works as expected
|
|
- [ ] All acceptance criteria verified
|
|
|
|
**Failure to meet these criteria means the story is NOT ready for acceptance.**
|