Oleksandr Bezdieniezhnykh
7d3ba1c3fd
Updated the README.md to reflect new skill commands and improved descriptions for various workflows, including the addition of new skills like /test-spec, /code-review, and /release. Enhanced clarity on session boundaries and flow resolutions in the auto-chaining process. Removed the implementer agent file as it is no longer needed. Updated coderule and meta-rule documents to enforce stricter testing and implementation standards, ensuring real results are produced rather than simulated ones. Revised the autodev flow documentation to include a new release step and clarified the retrospective process. Adjusted the testing rules to specify coverage thresholds for critical paths. Co-authored-by: Cursor <cursoragent@cursor.com>
3.0 KiB
Phase 3: Safety Net
Role: QA engineer and developer Goal: Ensure tests exist that capture current behavior before refactoring Constraints: Tests must all pass on the current codebase before proceeding
Skip Condition: Testability Refactoring
If the current run name contains testability (e.g., 01-testability-refactoring), skip Phase 3 entirely. The purpose of a testability run is to make the code testable so that tests can be written afterward. Announce the skip and proceed to Phase 4.
3a. Check Existing Tests
Before designing or implementing any new tests, check what already exists:
- Scan the project for existing test files (unit tests, integration tests, blackbox tests)
- Run the existing test suite — record pass/fail counts
- Measure current coverage against the areas being refactored (from
RUN_DIR/list-of-changes.mdfile paths) - Assess coverage against thresholds (canonical: see
.cursor/rules/cursor-meta.mdcQuality Thresholds — never hardcode a different number):- Minimum overall coverage: 75%
- Critical path coverage: 90% floor / 100% aim — 90% is the enforcement floor (blocks Phase 4 if not met); 100% is the aspirational target. Refactors are NOT permitted to drop below 90% on the critical paths covered by the in-scope changes.
- All public APIs must have blackbox tests
- All error handling paths must be tested
If existing tests meet all thresholds for the refactoring areas:
- Document the existing coverage in
RUN_DIR/test_specs/existing_coverage.md - Skip to the GATE check below
If existing tests partially cover the refactoring areas:
- Document what is covered and what gaps remain
- Proceed to 3b only for the uncovered areas
If no relevant tests exist:
- Proceed to 3b for full test design
3b. Design Test Specs (for uncovered areas only)
For each uncovered critical area, write test specs to RUN_DIR/test_specs/[##]_[test_name].md:
- Blackbox tests: summary, current behavior, input data, expected result, max expected time
- Acceptance tests: summary, preconditions, steps with expected results
- Coverage analysis: current %, target %, uncovered critical paths
3c. Implement Tests (for uncovered areas only)
- Set up test environment and infrastructure if not exists
- Implement each test from specs
- Run tests, verify all pass on current codebase
- Document any discovered issues
Self-verification:
- Coverage requirements met (75% overall, 90% critical-path floor — 100% aim — per canonical
cursor-meta.mdcQuality Thresholds) across existing + new tests - All tests pass on current codebase
- All public APIs in refactoring scope have blackbox tests
- Test data fixtures are configured
Save action: Write test specs to RUN_DIR; implemented tests go into the project's test folder
GATE (BLOCKING): ALL tests must pass before proceeding to Phase 4. If tests fail, fix the tests (not the code) or ask user for guidance. Do NOT proceed to Phase 4 with failing tests.