Summary
validate_mutation_boundary flags test files that are co-authored with the implementation as "outside affected_files", emitting a Scope warning that blocks the first validate_step 2.4 call — on essentially every subtask. The decomposer's blueprint affected_files lists only production files, but the plan's own test policy is "tests alongside implementation (validation = pytest green)". So a test file like python/pipeline/test_<module>.py is always "unexpected".
Environment
- mapify_version:
3.10.0
- workflow:
/map-efficient (batch), 25-subtask plan; test-alongside policy.
Repro
- Implement a subtask producing
python/pipeline/foo.py (in affected_files) and its test python/pipeline/test_foo.py (NOT in affected_files, but required by the test policy / HC-3 contract).
- Run
validate_step 2.4 --recommendation proceed with the changes uncommitted (working tree dirty).
Actual
{"valid": false, "message": "Scope warning (mutation-boundary): these files are outside ST-002's affected_files: ['python/pipeline/test_evidence_graph.py']. Revert the out-of-scope changes; OR, if they are genuinely required, STOP and report a blocker for a contract update — do not silently keep them. ..."}
A second validate_step 2.4 passes (once-per-subtask scope_feedback_subtasks guard, map_orchestrator.py:1184).
Root cause (hypothesis)
The decomposer (task-decomposer) emits affected_files containing only production modules, even when the subtask's validation_criteria explicitly require pytest coverage (HC-3 [AC-x] tags). validate_mutation_boundary then treats the accompanying test file as out-of-scope.
Suggested fix (one of)
- In
validate_mutation_boundary, auto-allow files matching test conventions (test_*.py, *_test.py, conftest.py, files under tests/) that sit beside a declared affected_file — they are implied by any subtask whose contract requires tests.
- OR have the decomposer automatically add the corresponding test path(s) to each subtask's
affected_files when the validation_criteria/test_strategy require tests.
- OR add a blueprint field
test_files: [] that the boundary check unions into affected_files.
Impact
A spurious "revert the out-of-scope changes / report a blocker" warning on nearly every subtask; requires a redundant second validate_step 2.4. Combined with the False-progress issue (separate report), the close path needs two validate calls regardless of whether you commit before or after validation.
Summary
validate_mutation_boundaryflags test files that are co-authored with the implementation as "outside affected_files", emitting a Scope warning that blocks the firstvalidate_step 2.4call — on essentially every subtask. The decomposer's blueprintaffected_fileslists only production files, but the plan's own test policy is "tests alongside implementation (validation = pytest green)". So a test file likepython/pipeline/test_<module>.pyis always "unexpected".Environment
3.10.0/map-efficient(batch), 25-subtask plan; test-alongside policy.Repro
python/pipeline/foo.py(inaffected_files) and its testpython/pipeline/test_foo.py(NOT inaffected_files, but required by the test policy / HC-3 contract).validate_step 2.4 --recommendation proceedwith the changes uncommitted (working tree dirty).Actual
A second
validate_step 2.4passes (once-per-subtaskscope_feedback_subtasksguard,map_orchestrator.py:1184).Root cause (hypothesis)
The decomposer (
task-decomposer) emitsaffected_filescontaining only production modules, even when the subtask's validation_criteria explicitly require pytest coverage (HC-3[AC-x]tags).validate_mutation_boundarythen treats the accompanying test file as out-of-scope.Suggested fix (one of)
validate_mutation_boundary, auto-allow files matching test conventions (test_*.py,*_test.py,conftest.py, files undertests/) that sit beside a declaredaffected_file— they are implied by any subtask whose contract requires tests.affected_fileswhen the validation_criteria/test_strategy require tests.test_files: []that the boundary check unions intoaffected_files.Impact
A spurious "revert the out-of-scope changes / report a blocker" warning on nearly every subtask; requires a redundant second
validate_step 2.4. Combined with the False-progress issue (separate report), the close path needs two validate calls regardless of whether you commit before or after validation.