Update Story Kit workflow docs and move story 26

.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/`.

.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`.

.story_kit/stories/upcoming/26_establish_tdd_workflow_and_gates.md

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

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