Validator blocks unrelated edits when test.json contains failing tests from a different change

[mlugo-apx]

Summary

When test.json contains failing tests from one change (Step A), the validator blocks implementation edits for a completely unrelated change (Step B) with "Over-implementation violation" — even though Step B has its own valid TDD justification.

Scenario

Working through a multi-step plan with independent changes:

1. Step A (trophy wiring): Write failing test → implement → tests pass. test.json now shows the failing test result from earlier in the cycle.
2. Step B (error boundary): Need to wrap init() in try/catch — a separate, independent change.

When attempting the Step B edit, the validator sees the Step A failing tests in test.json and blocks with:

Over-implementation violation. The failing tests indicate specific issues with 'handleReset not storing resetCount' and missing stats in 'checkBadges', but the implementation adds generic error handling around init() instead.

The validator assumes every edit must directly address whatever is currently failing in test.json, but:

• The Step A tests were from a previous TDD cycle (already resolved)
• Step B is a separate concern with its own justification
• The developer had to manually update test.json with a new failing test for Step B before the validator would allow the edit

Expected Behavior

The validator should not require every implementation edit to directly correspond to the most recent failing test in test.json. It should either:

1. Consider that failing tests may be stale (from a previous cycle), or
2. Allow implementation edits when the change is clearly independent of the failing tests, or
3. Only block when the edit directly contradicts a failing test (e.g., test says "Calculator is not defined" but edit adds something unrelated to Calculator)

Workaround

Manually update test.json with a failing test that matches the intended edit before making the change. This works but defeats the purpose of automated TDD enforcement.

Environment

• tdd-guard with custom browser-based test framework (no supported reporter — test.json managed manually)
• Multi-step implementation plan with independent changes across different files

Related

• PR fix(prompt): resolve contradiction blocking without test output #97 fixes a different issue in the same response.ts prompt (blocking when no test output exists)
• Issue TDD guard blocks removal of dead code and its tests during refactoring phase #83 describes a similar "validator too strict" problem in the refactoring phase