From 3302b62839c1d7a338e882b8c1042f32cf1190b9 Mon Sep 17 00:00:00 2001 From: Dave Date: Tue, 17 Feb 2026 13:38:31 +0000 Subject: [PATCH] Rename workflow to story-driven test workflow --- .story_kit/CODE_QUALITY_CHECKLIST.md | 4 ++-- .story_kit/README.md | 14 +++++++------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/.story_kit/CODE_QUALITY_CHECKLIST.md b/.story_kit/CODE_QUALITY_CHECKLIST.md index 0961480..fce4f0c 100644 --- a/.story_kit/CODE_QUALITY_CHECKLIST.md +++ b/.story_kit/CODE_QUALITY_CHECKLIST.md @@ -220,8 +220,8 @@ const code = ({ className, children }: { className?: string; children?: React.Re } ``` -## Integration with SDSW +## Integration with SDTW -This checklist is part of **Step 4: Verification** in the Story-Driven Spec Workflow. +This checklist is part of **Step 4: Verification** in the Story-Driven Test Workflow. **You cannot proceed to story acceptance without passing all checks.** \ No newline at end of file diff --git a/.story_kit/README.md b/.story_kit/README.md index 309e435..1384b68 100644 --- a/.story_kit/README.md +++ b/.story_kit/README.md @@ -1,4 +1,4 @@ -# Story Kit: The Story-Driven Spec Workflow (SDSW) +# Story Kit: The Story-Driven Test Workflow (SDTW) **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. @@ -10,7 +10,7 @@ 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*. +* **Tests** define the *Truth*. * **Code** defines the *Reality*. **The Golden Rule:** You are not allowed to write code until the Acceptance Criteria are captured in a test TODO file and the test plan is approved. @@ -26,7 +26,7 @@ project_root/ .story_kit |-- README.md # This document ├── stories/ # Story workflow (upcoming/current/archived). - ├── specs/ # The "Brain" of the project. + ├── specs/ # Minimal guardrails (context + stack). │ ├── README.md # Explains this workflow to future sessions. │ ├── 00_CONTEXT.md # High-level goals, domain definition, and glossary. │ ├── tech/ # Implementation details (Stack, Architecture, Constraints). @@ -65,7 +65,7 @@ When the user asks for a feature, follow this 4-step loop strictly: * **Output:** Show the user the test plan. **Wait for approval.** ### Step 3: The Implementation (Code) -* **Action:** Write the code to match the *Spec* (not just the Story). +* **Action:** Write the code to satisfy the approved tests and Acceptance Criteria. * **Constraint:** adhere strictly to `specs/tech/STACK.md` (e.g., if it says "No `unwrap()`", you must not use `unwrap()`). ### Step 4: Verification (Close) @@ -88,7 +88,7 @@ When the user asks for a feature, follow this 4-step loop strictly: * 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/` + * Updated guardrails in `specs/` (if needed) * Archived story in `stories/archived/` --- @@ -113,11 +113,11 @@ Not everything needs to be a full story. Simple bugs can skip the story process: * **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 +4. **No Guardrail Update Needed:** Unless the bug reveals a missing constraint ### Bug vs Story * **Bug:** Existing functionality is broken → Fix it -* **Story:** New functionality is needed → Spec it, then build it +* **Story:** New functionality is needed → Test it, then build it * **Spike:** Uncertainty/feasibility discovery → Run spike workflow ---