Background
From observing tdd-guard in a real session, two quality gaps emerged:
Problem 1: Stale test.json gives a misleading block
When tests haven't been run yet (or were run from a subdirectory before the VitestReporter wrote the file), tdd-guard blocks with:
"No failing test found"
This is factually correct but misleading — the failing tests exist in the test file, they just haven't been flushed to test.json yet. The developer has to debug why before realizing they just need to run the test suite first.
Proposed fix: Detect when test.json is missing or older than the test files, and surface a specific message:
"test.json is missing or stale — run your test suite first to flush results (e.g. npx vitest run)"
This could be a timestamp comparison between test.json mtime and the newest *.test.* file mtime in the project.
Problem 2: TDD enforcement raises the floor but not the ceiling
tdd-guard correctly enforces "write a failing test before implementing." But it doesn't nudge toward testing edge cases — malformed input, missing fields, error paths. In practice, developers write one happy-path test to satisfy the gate, then implement.
The result: tests cover the happy path but not:
- Malformed stdin / missing
hook_event_name
- Case sensitivity edge cases
- Error handling paths
Proposed fix: After the implementation passes its first test, tdd-guard's AI prompt could check whether the passing tests cover only the happy path and suggest (not require) an edge case test before closing the TDD loop. This would be opt-in via config (tdd-guard: suggest-edge-cases: true) to avoid being annoying on trivial changes.
Problem 3: "File created successfully" with no file on disk
Separate from tdd-guard: the Write tool reported success for a stub file that didn't appear on disk. This cost a full debug cycle. Likely a hook interaction (tdd-guard bridge returned exit 2 after the Write tool reported success, and the file was rolled back silently). The user-visible message should distinguish "write attempted but blocked by hook" from "write succeeded."
This may be a Claude Code issue rather than a project issue — worth investigating whether the hook's exit code is being handled correctly in the bridge.
Priority
P2 — quality of life improvements, not blockers.
Background
From observing tdd-guard in a real session, two quality gaps emerged:
Problem 1: Stale
test.jsongives a misleading blockWhen tests haven't been run yet (or were run from a subdirectory before the VitestReporter wrote the file), tdd-guard blocks with:
This is factually correct but misleading — the failing tests exist in the test file, they just haven't been flushed to
test.jsonyet. The developer has to debug why before realizing they just need to run the test suite first.Proposed fix: Detect when
test.jsonis missing or older than the test files, and surface a specific message:This could be a timestamp comparison between
test.jsonmtime and the newest*.test.*file mtime in the project.Problem 2: TDD enforcement raises the floor but not the ceiling
tdd-guard correctly enforces "write a failing test before implementing." But it doesn't nudge toward testing edge cases — malformed input, missing fields, error paths. In practice, developers write one happy-path test to satisfy the gate, then implement.
The result: tests cover the happy path but not:
hook_event_nameProposed fix: After the implementation passes its first test, tdd-guard's AI prompt could check whether the passing tests cover only the happy path and suggest (not require) an edge case test before closing the TDD loop. This would be opt-in via config (
tdd-guard: suggest-edge-cases: true) to avoid being annoying on trivial changes.Problem 3: "File created successfully" with no file on disk
Separate from tdd-guard: the Write tool reported success for a stub file that didn't appear on disk. This cost a full debug cycle. Likely a hook interaction (tdd-guard bridge returned exit 2 after the Write tool reported success, and the file was rolled back silently). The user-visible message should distinguish "write attempted but blocked by hook" from "write succeeded."
This may be a Claude Code issue rather than a project issue — worth investigating whether the hook's exit code is being handled correctly in the bridge.
Priority
P2 — quality of life improvements, not blockers.