diff --git a/.story_kit/README.md b/.story_kit/README.md index 1384b68..80df039 100644 --- a/.story_kit/README.md +++ b/.story_kit/README.md @@ -13,7 +13,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 a test TODO file 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 and the test plan is approved. --- @@ -47,7 +47,7 @@ When the user asks for a feature, follow this 4-step loop strictly: * **User Input:** "I want the robot to dance." * **Action:** Create a file in `stories/upcoming/` (e.g., `stories/upcoming/XX_robot_dance.md`). * **Move to Current:** Once the story is validated and ready for coding, move it to `stories/current/`. -* **Create Test TODOs:** Create `tests/todo/story-XX.todo` with one comment per Acceptance Criterion (e.g., `// AC: story-XX#1 - ...`). +* **Tracking:** Mark Acceptance Criteria as tested directly in the story file as tests are completed. * **Content:** * **User Story:** "As a user, I want..." * **Acceptance Criteria:** Bullet points of observable success. @@ -61,7 +61,7 @@ When the user asks for a feature, follow this 4-step loop strictly: * 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 appear as a single TODO comment in `tests/todo/story-XX.todo`. + * 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) @@ -69,7 +69,7 @@ When the user asks for a feature, follow this 4-step loop strictly: * **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:** For each TODO comment, write a failing test (red), delete the comment, make the test pass (green), and refactor if needed. Keep only one failing test at a time. +* **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 `stories/archived/`. Tell the user they should commit (this gives them the chance to exclude files via .gitignore if necessary). * **Move to Archived:** After acceptance, move the story from `stories/current/` to `stories/archived/`. diff --git a/.story_kit/stories/current/26_establish_tdd_workflow_and_gates.md b/.story_kit/stories/current/26_establish_tdd_workflow_and_gates.md new file mode 100644 index 0000000..3024de4 --- /dev/null +++ b/.story_kit/stories/current/26_establish_tdd_workflow_and_gates.md @@ -0,0 +1,15 @@ +# Story 26: Establish the TDD Workflow and Gates + +## User Story +As a user, I want a clear, enforceable TDD workflow with quality gates, so development is test-first and regressions are blocked. + +## Acceptance Criteria +- [ ] A test-first workflow is defined and enforced before implementation begins. +- [ ] Each story requires both unit tests and integration tests (standard Rust `tests/` layout). +- [ ] A test plan is produced and approved before any code changes. +- [ ] Stories cannot be accepted unless all required tests pass. +- [ ] Only one failing test is allowed at a time during red-green-refactor. + +## Out of Scope +- Backfilling tests for legacy code (covered by a separate story). +- Adding new test frameworks beyond those defined in `specs/tech/STACK.md`. \ No newline at end of file diff --git a/.story_kit/stories/upcoming/26_establish_tdd_workflow_and_gates.md b/.story_kit/stories/upcoming/26_establish_tdd_workflow_and_gates.md deleted file mode 100644 index 48a759b..0000000 --- a/.story_kit/stories/upcoming/26_establish_tdd_workflow_and_gates.md +++ /dev/null @@ -1,15 +0,0 @@ -# Story 26: Establish the TDD Workflow and Gates - -## User Story -As a user, I want a clear, enforceable TDD workflow with quality gates, so development is test-first and regressions are blocked. - -## Acceptance Criteria -- A test-first workflow is defined and enforced before implementation begins. -- Each story requires both unit tests and integration tests (standard Rust `tests/` layout). -- A test plan is produced and approved before any code changes. -- Stories cannot be accepted unless all required tests pass. -- Only one failing test is allowed at a time during red-green-refactor. - -## Out of Scope -- Backfilling tests for legacy code (covered by a separate story). -- Adding new test frameworks beyond those defined in `specs/tech/STACK.md`. \ No newline at end of file diff --git a/.story_kit/stories/upcoming/31_directory_based_workflow_coordination.md b/.story_kit/stories/upcoming/31_directory_based_workflow_coordination.md new file mode 100644 index 0000000..b8a079a --- /dev/null +++ b/.story_kit/stories/upcoming/31_directory_based_workflow_coordination.md @@ -0,0 +1,15 @@ +# Story 31: Directory-Based Workflow Coordination and Locks + +## User Story +As a user, I want directory-based story workflow coordination with lock tracking, so multiple agents can pick up work with minimal context while keeping coordination in `master`. + +## Acceptance Criteria +- Add a `stories/check/` directory for review/verification handoff. +- Define a lock file format in `master` (e.g., `.story_kit/locks.json`) that tracks story assignment, agent identity, worktree path, and last update time. +- Document the story lifecycle across `upcoming/`, `current/`, `check/`, and `archived/` directories. +- Document that code changes happen in worktrees, while coordination files and story movement live in `master`. + +## Out of Scope +- Implementing the lock mechanism or agents in code. +- Enforcing locks at runtime. +- Multi-agent orchestration beyond documenting the workflow. \ No newline at end of file