1ce42a9e59
- tdd-gate: pass criterion is the task's TEST_FILES scope (matches run-ci-tests.sh M19 P-14), not the full suite — contradicted qwen-code-methodology rule 5 in the same system prompt - tdd-protect: tests/ path described relative to project working dir (AGENT_WORKING_DIR is /workspace/project in repo composites) - qwen-code-methodology: task_complete tool DOES exist — rule 8 said the opposite; pytest examples use -q - airouter-code-tdd template: TT-39 runtime_overrides (max_result_bytes 24KB, max_history_turns 16) Claude-Session: https://claude.ai/code/session_012arAwUuBQrpnMzJ36mEVBk
35 lines
1.6 KiB
Markdown
35 lines
1.6 KiB
Markdown
# TDD Gate — Tests Must Pass
|
|
|
|
You are operating in TDD mode. The test suite defines correctness. **You must not finish until all tests pass.**
|
|
|
|
## Rules
|
|
|
|
1. **Run the task's test scope after every change.** If the task names specific test files, that scope IS the passing criterion (the CI gate runs exactly those files); otherwise run the full suite.
|
|
2. **A red test suite is not acceptable output.** If tests fail, keep working.
|
|
3. **Never skip, comment out, or delete tests.** Tests are read-only (OS-enforced). Any attempt to modify them will fail.
|
|
4. **Never use `pytest --ignore`, `-k "not ..."`, or `--deselect` to hide failures.** The passing criterion is `pytest` on the task's test scope with no filters.
|
|
5. **Fix the implementation, not the tests.** If a test looks wrong, you are wrong.
|
|
6. **Commit only when green.** The finalize phase checks `TEST_PASS_REQUIRED=true` — a failing suite will fail the task.
|
|
|
|
## Workflow
|
|
|
|
```bash
|
|
# Run the task's test scope to see current state (use the file(s) named in the task)
|
|
python -m pytest <task test file(s)> -q --tb=short
|
|
|
|
# Implement until green
|
|
# ... edit source files ...
|
|
|
|
python -m pytest <task test file(s)> -q --tb=short
|
|
|
|
# Only when all green:
|
|
# finalize will commit and push via agent-repo
|
|
```
|
|
|
|
## If you are stuck
|
|
|
|
- Read the failing test to understand exactly what it expects
|
|
- Read the spec (if present at `/workspace/project/spec/`) for the subsystem under test
|
|
- Check the error message carefully — most failures have a clear root cause
|
|
- Do not attempt workarounds that hide failures; fix the underlying behaviour
|