Consolidate upcoming TDD stories

.story_kit/stories/upcoming/26_define_tdd_workflow_rules.md

@@ -1,16 +0,0 @@
-# Story 26: Define the TDD Workflow Rules
-
-## User Story
-As a user, I want a clear TDD workflow (unit + integration), so the system enforces test-first development.
-
-## Acceptance Criteria
-- The workflow explicitly requires tests before implementation.
-- Both unit tests and integration tests are required for feature work.
-- The concrete test frameworks to use are defined in `specs/tech/STACK.md`.
-- Code changes are not accepted unless all required tests pass.
-- Test removal requires explicit user approval.
-
-## Out of Scope
-- Migrating existing tests to new frameworks.
-- Backfilling missing tests for legacy code unless part of a new story.
-- Defining project-specific test frameworks beyond what is documented in `specs/tech/STACK.md`.

.story_kit/stories/upcoming/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/27_enforce_test_first.md

@@ -1,14 +0,0 @@
-# Story 27: Enforce Test-First Before Implementation
-
-## User Story
-As a user, I want the workflow to block implementation until tests are written, so test-first development is enforced.
-
-## Acceptance Criteria
-- The system prevents implementation work until required tests are created.
-- The system prompts for missing tests before allowing code changes.
-- The enforcement applies to both unit and integration tests.
-- The user can explicitly acknowledge when tests are intentionally deferred.
-
-## Out of Scope
-- Automated test generation.
-- Converting legacy code to test-first.

.story_kit/stories/upcoming/27_protect_tests_and_coverage.md

@@ -0,0 +1,14 @@
+# Story 27: Protect Tests and Coverage
+
+## User Story
+As a user, I want explicit safeguards around test deletion and coverage regression, so quality guardrails cannot be weakened silently.
+
+## Acceptance Criteria
+- Any deletion of test files requires explicit user approval.
+- Any change that disables or neuters a test (e.g., commenting out assertions) requires explicit user approval.
+- The workflow fails if coverage drops below the defined threshold.
+- Coverage regression is reported clearly before acceptance.
+
+## Out of Scope
+- Introducing new test frameworks beyond those listed in `specs/tech/STACK.md`.
+- Large refactors solely to improve coverage.

.story_kit/stories/upcoming/28_require_unit_and_integration_tests.md

@@ -1,12 +0,0 @@
-# Story 28: Require Unit and Integration Tests per Story
-
-## User Story
-As a user, I want every story to include both unit and integration tests, so behavior is verified at multiple levels.
-
-## Acceptance Criteria
-- Each story includes at least one unit test and one integration test, with integration tests using the standard Rust `tests/` layout.
-- The required test types are defined by the frameworks listed in `specs/tech/STACK.md`.
-- A story cannot be accepted if either test type is missing.
-
-## Out of Scope
-- Retrofitting legacy features without an active story.

.story_kit/stories/upcoming/28_standardize_acceptance_tests_and_todos.md

@@ -0,0 +1,16 @@
+# Story 28: Standardize Acceptance Tests and TODO Flow
+
+## User Story
+As a user, I want a consistent acceptance test layout and TODO workflow, so acceptance criteria are translated into tests in a predictable, toolable way.
+
+## Acceptance Criteria
+- A single, documented folder structure exists for acceptance tests and story TODO files.
+- Each story must have a `tests/todo/story-XX.todo` file with one comment per Acceptance Criterion using the format `// AC: story-XX#N - ...`.
+- Acceptance tests and integration tests follow the standard Rust `tests/` layout.
+- The workflow requires consuming TODOs one at a time: write a failing test, delete the TODO line, make it pass, then refactor.
+- The test plan references the frameworks and commands in `specs/tech/STACK.md`.
+
+## Out of Scope
+- Building UI surfaces for TODO visibility.
+- Migrating existing tests to the new layout.
+- Introducing new test frameworks beyond those listed in `specs/tech/STACK.md`.

.story_kit/stories/upcoming/29_backfill_tests_high_coverage.md

@@ -1,4 +1,4 @@
-# Story 34: Backfill Tests for Maximum Coverage
+# Story 29: Backfill Tests for Maximum Coverage
 
 ## User Story
 As a user, I want us to backfill tests across existing code so overall coverage is as high as we can reasonably achieve.

.story_kit/stories/upcoming/29_block_acceptance_on_test_failures.md

@@ -1,14 +0,0 @@
-# Story 29: Block Acceptance When Tests Fail
-
-## User Story
-As a user, I want the workflow to block story acceptance when tests fail, so regressions cannot be accepted.
-
-## Acceptance Criteria
-- The system runs all required tests before acceptance.
-- If any test fails, the story cannot be accepted.
-- The failure output is shown clearly to the user.
-- A successful test run is required immediately before acceptance.
-
-## Out of Scope
-- Adding new test frameworks beyond those in `specs/tech/STACK.md`.
-- Retrying tests automatically without user confirmation.

.story_kit/stories/upcoming/30_protect_against_test_deletion.md

@@ -1,13 +0,0 @@
-# Story 30: Protect Against Test Deletion
-
-## User Story
-As a user, I want explicit approval required before tests are deleted or weakened, so guardrails cannot be removed silently.
-
-## Acceptance Criteria
-- Any deletion of test files requires explicit user approval.
-- Any change that disables or neuters a test (e.g., commenting out assertions) requires explicit user approval.
-- The system reports all test deletions or weakenings clearly before acceptance.
-
-## Out of Scope
-- Refactoring tests without behavioral changes.
-- Removing obsolete tests as part of a broader system rewrite.

.story_kit/stories/upcoming/30_ui_show_test_todos.md

@@ -1,4 +1,4 @@
-# Story 35: Show Remaining Test TODOs in the UI
+# Story 30: Show Remaining Test TODOs in the UI
 
 ## User Story
 As a user, I want the UI to show the remaining test TODOs for the current story, so I can track which Acceptance Criteria are still untested.

.story_kit/stories/upcoming/31_standardize_acceptance_test_layout.md

@@ -1,14 +0,0 @@
-# Story 31: Standardize Acceptance Test Layout
-
-## User Story
-As a user, I want a consistent acceptance test layout, so tests are easy to locate, review, and run across stories.
-
-## Acceptance Criteria
-- A single, documented folder structure for acceptance tests is established.
-- The naming convention for acceptance tests is consistent across stories.
-- The chosen test frameworks are defined in `specs/tech/STACK.md`.
-- The layout is used for all new acceptance tests.
-
-## Out of Scope
-- Migrating existing tests to the new layout.
-- Introducing new test frameworks beyond those listed in `specs/tech/STACK.md`.

.story_kit/stories/upcoming/32_add_coverage_regression_guardrail.md

@@ -1,13 +0,0 @@
-# Story 32: Add Coverage Regression Guardrail
-
-## User Story
-As a user, I want coverage regression to block acceptance, so test quality cannot quietly degrade.
-
-## Acceptance Criteria
-- The workflow fails if coverage drops below the defined threshold.
-- Coverage regression is reported clearly before acceptance.
-- The coverage threshold is defined in `specs/tech/STACK.md`.
-
-## Out of Scope
-- Selecting or adding new coverage tools beyond those listed in `specs/tech/STACK.md`.
-- Retrofitting coverage reports for legacy test suites.

.story_kit/stories/upcoming/33_test_result_summary_ui.md

@@ -1,14 +0,0 @@
-# Story 33: Add Test Result Summaries in the UI
-
-## User Story
-As a user, I want test results summarized in the UI, so I can quickly review pass/fail status before acceptance.
-
-## Acceptance Criteria
-- The UI displays a summary of unit test results.
-- The UI displays a summary of integration test results.
-- Failed tests show clear error output in the UI.
-- A passing test summary is required immediately before acceptance.
-
-## Out of Scope
-- Adding new test frameworks beyond those listed in `specs/tech/STACK.md`.
-- Persisting historical test results across sessions.