The config loader applies neither scoping field at load time, even though `matcher` and `if` follow different rules. The post quotes the hooks documentation directly: a matcher on an event without matcher support is silently ignored [2]. The `if` field is a narrower filter that tests a tool name together with its arguments, which is why the documentation scopes it to the five tool events [6]. An event with no tool in scope has nothing for the condition to read, so the handler never runs [7].
Put the two lists side by side and none of the ten matcher-less events is one of the five tool events [16]. On `Stop`, then, both scoping fields are inert, and they fail in opposite directions: write `matcher` and the handler runs on every stop, write `if` and it runs on none [16]. Neither state produces an error [8]. The post's judgement is that the over-firing case is the worse of the two, because a filter you believe you applied is worse than a hook you know is absent [5].
A third failure drops nothing at all. Tools from an MCP server bundled by a plugin carry the plugin name inside the tool name, in the form `mcp__plugin_<plugin-name>_<server-name>__<tool>`, so a matcher written against the bare server key, `mcp__db__.*`, is evaluated exactly as written and matches nothing; `mcp__plugin_my-plugin_db__.*` is the form that fires [11].
The same silence covers handler bodies. A handler of `{ "type": "command" }` with no `command` key does nothing, and the shape the post reports most often is a type switched from `command` to `http` with the old `command` left behind and no `url` added [10].
The author gave ccheck one rule: a finding may exist only if the official documentation says the thing errors, is skipped, or is ignored, and every finding prints the URL that says so [12]. Its sample output flags a matcher on `CwdChanged` as an error and `ignorePatterns` as deprecated in favour of `permissions.deny` [13]. That constraint is paid for in coverage: model name validity, path pattern correctness and unknown keys all go unchecked, because each would be a guess, and a checker stops being read after its first false positive [14].
The documentation table has to be the authority on what the loader actually does for the output to be worth anything in your repo, since the tool reports what the docs call ignored, not what the binary ignores [12]. If an event gains matcher support, or the loader diverges from the table, the checker goes stale in the docs' direction.
The silence itself is the post's observation rather than a documented guarantee: clean startup, nothing from `--debug`, and a hook that does not run [1]. Which is why the only place the mismatch is visible is a reader outside the session, comparing each field against the event it was written on.
