Refocus workflow on TDD and reorganize stories

.story_kit/stories/upcoming/26_define_tdd_workflow_rules.md

@@ -0,0 +1,16 @@
+# 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/27_enforce_test_first.md

@@ -0,0 +1,14 @@
+# 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/28_require_unit_and_integration_tests.md

@@ -0,0 +1,12 @@
+# 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/29_block_acceptance_on_test_failures.md

@@ -0,0 +1,14 @@
+# 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

@@ -0,0 +1,13 @@
+# 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/31_standardize_acceptance_test_layout.md

@@ -0,0 +1,14 @@
+# 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

@@ -0,0 +1,13 @@
+# 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

@@ -0,0 +1,14 @@
+# 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.

.story_kit/stories/upcoming/34_backfill_tests_high_coverage.md

@@ -0,0 +1,14 @@
+# Story 34: 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.
+
+## Acceptance Criteria
+- We add unit and integration tests to existing code paths with a goal of maximizing coverage.
+- New tests are prioritized for critical workflows (filesystem access, project open/close, tool execution, chat flow).
+- Coverage improvements are measured and reported for each test backfill batch.
+- The work continues until coverage is as high as practically achievable with the current architecture.
+
+## Out of Scope
+- Major refactors solely to increase coverage (unless required to make code testable).
+- Introducing new testing frameworks beyond those listed in `specs/tech/STACK.md`.