commit-validate.js false-positives on any heredoc or -m flag, unrelated to git commit

[slava07437352641-ops]

Bug

scripts/commit-validate.js's extractMessage() misidentifies non-git commit Bash commands as commit messages, causing the PreToolUse hook to block unrelated work.

Root cause

The -m/--message/heredoc/-F/--file sub-patterns in extractMessage() run unconditionally on the full command string, with no upfront check that the command actually invokes git commit. Two concrete false positives:

1. Any heredoc in a Bash command matches the heredocAny regex (line ~30) and its first content line gets validated as a commit subject — even for something totally unrelated, e.g.:

   cat > file.py << 'EOF'
   import json
   EOF

   This blocks with "Commit message must follow conventional commits..." even though there's no git invocation at all.

2. Any -m "..." flag on any command (not just git commit -m) gets captured as a "commit message" by the shortFlag regex, e.g. tools that happen to take a -m flag for unrelated purposes.

Fix

Add a guard at the top of extractMessage() that returns early unless the command actually matches a real git commit invocation, before running any of the sub-pattern checks:

function extractMessage(command) {
  if (!command) return { msg: null, form: 'empty' };

  if (!/\bgit\s+(?:-[^\s]+\s+)*commit\b/.test(command)) {
    return { msg: null, form: 'not-a-commit' };
  }

  const shortFlag = command.match(/(?:^|\s)-m\s+(?:"((?:[^"\\]|\\.)*)"|'((?:[^'\\]|\\.)*)'|(\S+))/);
  // ... rest unchanged

Verified locally: heredoc/non-commit commands now pass through silently (exit 0), a real invalid commit message still blocks correctly (exit 2), and a valid conventional commit still passes (exit 0).

Happy to open a PR with this exact change if useful — flagging as an issue first in case there's a preferred approach or existing WIP on this.

[johnhenryiv]

Confirming this in the wild — hit it today with a plain health-check:

curl -sS -m 4 http://localhost:8643/health

curl's -m 4 (max-time) got captured by the shortFlag regex as commit message 4, failed the conventional-commits pattern, and blocked the command with exit 2. No git anywhere in sight.

One extra data point for prioritization: main is currently worse than the released 3.1.0. The 3.1.0 extractMessage() at least wraps the heredoc check in an if (isGitCommit) block; the current main version has dropped that and runs -m/--message matching completely unconditionally, so the false-positive surface is now every -m/--message flag on any tool (curl, tar, ssh, ffmpeg, …).

The early-return guard proposed here fixes both. Verified locally against 3.1.0: curl/tar -m pass silently (exit 0), valid conventional commit passes (exit 0), invalid git commit message still blocks (exit 2). +1 on the PR offer.