dave/storkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 7 Wiki Activity

Rename workflow to story-driven test workflow

Browse Source
This commit is contained in:
Dave
2026-02-17 13:38:31 +00:00
parent 3079ea194f
commit 3302b62839
2 changed files with 9 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
.story_kit/CODE_QUALITY_CHECKLIST.md
View File

@@ -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.**

14
.story_kit/README.md
View File

@@ -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
---