Found in the 2026-08-01 top-to-bottom read-only code review (commit 1e59027).
What
hooks.run_hook (hooks.py:664) is the dispatcher every Claude Code hook event flows through. For PostToolUse it must, in order: reset the loop guard, record MCP usage, run the Layer-E compliance detector, and run the Layer-C verifier:
ai_usage.record_mcp_response(omi_dir, event)
compliance.record_post_tool(event)
verify.verify_consult(event, omi_dir)
The whole body is wrapped in try/except Exception → _record_failure and returns 0, by design ('never block the agent'). The compliance module itself is well unit-tested (test_compliance.py: detector, opt-in, torn-line, gate exclusion). What is not covered anywhere is the wiring: a regression that deletes, reorders, or exception-swallows the compliance.record_post_tool(event) line would leave every existing test green while the compliance log silently stops growing — exactly the failure class the hook-failure breadcrumb exists to surface, except this path leaves no breadcrumb at all if the line is dropped rather than failing.
tests/test_hooks.py covers journal append + format; tests/test_compliance.py covers the detector. No test asserts run_hook("PostToolUse", ...) actually invokes the detector (e.g. by spying/monkeypatching compliance.record_post_tool and asserting call count on a Bash event).
Candidate fix (not implemented — review-only)
One small test: monkeypatch omind.compliance.record_post_tool (and verify.verify_consult) with a recorder, call hooks.run_hook("PostToolUse", omi_dir, stdin=…) with a minimal Bash event, assert the recorder saw exactly one call. Cheap, and it pins the integration contract the two layers depend on.
Severity: test-coverage gap; no runtime impact.
Found in the 2026-08-01 top-to-bottom read-only code review (commit 1e59027).
What
hooks.run_hook(hooks.py:664) is the dispatcher every Claude Code hook event flows through. ForPostToolUseit must, in order: reset the loop guard, record MCP usage, run the Layer-E compliance detector, and run the Layer-C verifier:The whole body is wrapped in
try/except Exception→_record_failureand returns 0, by design ('never block the agent'). The compliance module itself is well unit-tested (test_compliance.py: detector, opt-in, torn-line, gate exclusion). What is not covered anywhere is the wiring: a regression that deletes, reorders, or exception-swallows thecompliance.record_post_tool(event)line would leave every existing test green while the compliance log silently stops growing — exactly the failure class the hook-failure breadcrumb exists to surface, except this path leaves no breadcrumb at all if the line is dropped rather than failing.tests/test_hooks.pycovers journal append + format;tests/test_compliance.pycovers the detector. No test assertsrun_hook("PostToolUse", ...)actually invokes the detector (e.g. by spying/monkeypatchingcompliance.record_post_tooland asserting call count on a Bash event).Candidate fix (not implemented — review-only)
One small test: monkeypatch
omind.compliance.record_post_tool(andverify.verify_consult) with a recorder, callhooks.run_hook("PostToolUse", omi_dir, stdin=…)with a minimal Bash event, assert the recorder saw exactly one call. Cheap, and it pins the integration contract the two layers depend on.Severity: test-coverage gap; no runtime impact.