fix: distinguish an absent commit message from an empty one - #534

Why this exists

main went red on the push run immediately after #532 merged, on test_empty_message_passes — a test that had been green on the pull request. Nothing regressed. The merge was simply the first time that test met a real commit.

CC013 ai-attribution check failed ==> Claude Code
AI-assisted commit is forbidden — detected tools: Claude Code

The bug

_get_commit_body tested stdin_text for truth, so an empty string read as not provided and the check fell through to get_commit_info("b") — the repository's HEAD commit. The test named "empty message passes" therefore never measured an empty message. Measured on a real checkout, its "empty" message resolved to 6694 characters.

That is why the timing looks strange, and it takes all three:

1. On a pull_request run, HEAD is GitHub's synthetic merge commit, whose body is empty (git log -1 --format=%b → 1 character). Empty body → early return PASS → the test passed for the wrong reason.
2. On main, HEAD became the squashed commit, which carries a Co-authored-by: trailer.
3. CC013 detected it and the test failed.

The commit that set it off was #532's own AI attribution.

This is the same shape as the merge-base defect #532 fixed: a test that looks isolated but reads ambient git state, in a repository where the PR checkout and the main checkout are structurally different commits. #532 cleaned up three such tests in MergeBaseValidator; the pattern was also sitting in AiAttributionValidator.

What changed

One line makes main green — _get_commit_body splits on None, matching _should_skip_validation and _resolve_current_author, which already did.

The same looseness was in four more readers, so they follow the same rule now: _get_commit_message, _get_subject, _get_author_value, and BranchValidator. The intent was already recorded upstream — api.validate_author distinguishes with name is not None — only these readers had not followed it.

ForcePushValidator deliberately keeps its truth test, and says so in a comment: its stdin_text carries a list of refs, where empty genuinely means nothing to check rather than a value to judge.

That surfaced a rule that could never fire. _is_empty_commit_allowed exists to reject an empty message under allow_empty_commits = false, but CommitTypeValidator returned PASS on a falsy message before ever reaching it — the rejecting branch was dead code. A supplied message now reaches the rule even when empty; one git never gave us still returns early:

validate_message("")                            -> pass   (default: empty allowed)
validate_message("", allow_empty_commits=false) -> fail   CC008

The other validators keep their early return. BodyValidator documents whitespace-only input as "no commit message at all" and has tests asserting it; allow_empty_commits is the rule that owns that judgement, so the rest defer to it.

Impact beyond the red build

The public API was answering the wrong question. validate_message("") reported on the last commit rather than on the empty message it was handed — so commit-check-mcp's validate_commit_message("") validated whatever the server's working directory had committed last. It now reports value=''.

The CLI is unaffected either way: _resolve_commit_message_source already normalises empty stdin to None.

Verification

• 514 passed (python -m pytest tests/), ruff clean and formatted.
• Three new tests, each patching get_commit_info and asserting it is never consulted, so the verdict provably comes from the supplied message and not from the repository's HEAD. The pre-existing test_empty_message_passes only holds while the checkout's own HEAD carries no AI trailers — which is exactly what made it fragile — so the replacements pin the behaviour instead of the environment.
• Non-vacuity checked by restoring each early return and confirming the matching test goes red.
• test_empty_message_returns_fail in api_test.py was vacuous for the same reason: it patched get_commit_info to "test-user" and validated that string. It now genuinely exercises the empty message.

🤖 Generated with Claude Code

https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn

Generated by Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Explicitly supplied empty commit messages, subjects, authors, and branches are now validated correctly instead of being treated as missing.
  • Empty commit messages can now trigger rules that disallow them.
  • Validation no longer falls back to the latest repository commit when an empty message is explicitly provided.
  • Commit-type validation now correctly skips only when no message is available.