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

Remove test_plan gate from the codebase

Browse Source 
The test_plan field was a gate from the old interactive web UI workflow
where a human would approve a test plan before the LLM could write code.
With autonomous coder agents, this gate is dead weight — coders sometimes
obey the README's "wait for approval" instruction and produce no code.

Removes: TestPlanStatus enum, ensure_test_plan_approved checks in fs/shell,
set_test_plan MCP tool + handler, test_plan from story/bug front matter
creation, test_plan validation in validate_story_dirs, and all related tests.
Updates README to remove Step 2 (Test Planning) and renumber steps.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Dave
2026-02-23 19:12:05 +00:00
parent cc2511b792
commit 31037f5bf5
7 changed files with 23 additions and 363 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
.story_kit/README.md
View File

@@ -26,7 +26,7 @@ Instead of ephemeral chat prompts ("Fix this", "Add that"), we work through pers
* **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 the story and the test plan is approved.
**The Golden Rule:** You are not allowed to write code until the Acceptance Criteria are captured in the story.
---
@@ -91,14 +91,12 @@ 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 story via MCP tool `create_story` (guarantees correct front matter and auto-assigns the story number).
* **Front Matter (Required):** Every work item file MUST begin with YAML front matter containing `name` and `test_plan` fields:
* **Front Matter (Required):** Every work item file MUST begin with YAML front matter containing a `name` field:
```yaml
---
name: Short Human-Readable Story Name
test_plan: pending
---
```
The `test_plan` field tracks approval status: `pending` → `approved` (after Step 2).
* **Move to Current:** Once the story is validated and ready for coding, move it to `work/2_current/`.
* **Tracking:** Mark Acceptance Criteria as tested directly in the story file as tests are completed.
* **Content:**
@@ -108,21 +106,12 @@ When the user asks for a feature, follow this 4-step loop strictly:
* **Story Quality (INVEST):** Stories should be Independent, Negotiable, Valuable, Estimable, Small, and Testable.
* **Git:** The `start_agent` MCP tool automatically creates a worktree under `.story_kit/worktrees/`, checks out a feature branch, moves the story to `work/2_current/`, and spawns the agent. No manual branch or worktree creation is needed.
### Step 2: Test Planning (TDD)
* **Action:** Define the test plan for the Story before any implementation.
* **Logic:**
* Identify required unit tests and integration tests.
* Confirm test frameworks and commands from `specs/tech/STACK.md`.
* Ensure Acceptance Criteria are testable and mapped to planned tests.
* Each Acceptance Criterion must be traceable to a specific test.
* **Output:** Show the user the test plan. **Wait for approval.**
### Step 3: The Implementation (Code)
### Step 2: The Implementation (Code)
* **Action:** Write the code to satisfy the approved tests and Acceptance Criteria.
* **Constraint:** adhere strictly to `specs/tech/STACK.md` (e.g., if it forbids certain patterns, you must not use them).
* **Full-Stack Completion:** Every story must be completed across all components of the stack. If a feature touches the backend, frontend, and API layer, all three must be fully implemented and working end-to-end before the story can be accepted. Partial implementations (e.g., backend logic with no frontend wiring, or UI scaffolding with no real data) do not satisfy acceptance criteria.
### Step 4: Verification (Close)
### Step 3: Verification (Close)
* **Action:** For each Acceptance Criterion in the story, write a failing test (red), mark the criterion as tested, make the test pass (green), and refactor if needed. Keep only one failing test at a time.
* **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 `work/5_archived/`.
@@ -233,7 +222,7 @@ If a user hands you this document and says "Apply this process to my project":
## 6. Code Quality
**MANDATORY:** Before completing Step 4 (Verification) of any story, you MUST run all applicable linters, formatters, and test suites and fix ALL errors and warnings. Zero tolerance for warnings or errors.
**MANDATORY:** Before completing Step 3 (Verification) of any story, you MUST run all applicable linters, formatters, and test suites 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.