Files
agent-runtime-framework/harnesses/contexts/tdd-gate/v1/CLAUDE.md
Paul O'Reilly 1ce42a9e59 fix(harness): resolve layer contradictions + context-budget caps for airouter TDD
- 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
2026-08-19 09:10:22 +12:00

1.6 KiB

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

# 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