Report exempt-path merge blocks instead of merging over them

[gnguralnick]

Problem

uncommitted_exempt_paths lets a dir declare that some subtree holds expected machine-generated state -- the setting's own comment names "a vendored subtree a dev loop rsyncs into the working tree". But it was wired into the clean-tree check only, and step 4 then runs a bare git merge. Git refuses to merge over working-tree state it would overwrite no matter what that check was told to ignore, so the merge aborted on exactly the state the config had just declared uninteresting.

It is not a rare case either. The base branch is where such generated state gets updated -- a release-time sync lands it on main -- so whenever such a sync is in the incoming range, the merge collides with the files the dev loop just rewrote and reports a merge conflict listing hundreds of vendored files. It is not every merge: git only refuses when the incoming change actually touches the dirty paths, so a base branch that has not re-vendored merges fine. But the collision recurs by design rather than by accident, and it is opaque when it happens.

Concretely, in mngr's .external_worktrees/default-workspace-template (which sets uncommitted_exempt_paths: ["system/vendor/mngr"] and fetch_and_merge: true), just minds-start rsyncs the local mngr tree into system/vendor/mngr on every run, deliberately uncommitted.

Fix

The first commit on this branch resolved it by resetting the exempt paths to HEAD before the merge. That was the wrong actor, so this branch drops that behavior and reports instead:

• The hook does not know how to regenerate an exempt path -- only the repo does. Resetting it silently stripped a dev loop's live working copy, and invisibly: the log line announcing the reset never reaches anyone, because a dir's stderr is relayed only when that dir fails.
• It also fired on any dirt under an exempt path, not just dirt the incoming merge would actually have collided with.

So _merge_ref now classifies the failure. Git's refusal names the paths it would overwrite; when every one of them is a dirty path matching the exempt pathspecs, the hook reports that specific cause and the response it calls for -- drop the generated state, merge, regenerate -- rather than "resolve the merge conflicts", which is not the fix here. Anything else still gets the generic report. Git does the pathspec matching (via ls-files/diff --cached against the configured pathspecs), so real pathspec semantics hold rather than string prefixes.

Both of git's refusals are covered: tracked modifications ("Your local changes to the following files would be overwritten by merge") and untracked collisions ("The following untracked working tree files..."). The latter is the likelier real case -- a dev loop generates files that a later base-branch sync then commits.

• README: the row for the setting states that the hook never discards the state, and what it does instead.
• plugin.json: 0.3.0 -> 0.4.0 (unreleased; carried from the first commit).

The consuming repo supplies the regeneration step. mngr does this in CLAUDE.md plus a just sync-vendor-mngr-live recipe, in imbue-ai/mngr-internal#374.

Also here: per-dir settings resolution in the skill prose

Riding along because it is the same "a secondary dir is not the root" class of bug, found while testing this change.

autofix and verify-architecture Phase 0 read settings twice. Step 1 (the root) says ".reviewer/settings.json (and .reviewer/settings.local.json if present)"; step 2 (each additional dir) said only "{dir}/.reviewer/settings.json". So an agent following the letter read the committed file for a secondary dir and missed whatever its gitignored local override changed. The runtime never had this bug -- read_json_config derives the .local.json sibling of whatever path it is handed, and stop_hook_gates.sh hands it each dir's path -- so this was purely the prose disagreeing with the code.

Both steps now state the same precedence explicitly.

The reported symptom was actually one step further out: an agent concluded a dir had autofix disabled, reading autofix.is_enabled from that dir's committed settings.json while its settings.local.json re-enabled it. Neither skill ever asks for that read -- per-dir gate enablement is stop_hook_gates.sh's decision -- so both now say not to do it.

Testing

bash tests/test_multi_dir_stop_hook.sh -- 60 passed, 0 failed (14 pre-existing scenarios unchanged).

Three scenarios cover the merge behavior, each with a base branch that advances and touches the exempt subtree:

• 15 -- a blocked merge reports the exempt-path cause, names the blocking file, is not reported as a merge conflict, and leaves both the tracked and untracked local state intact. Then, restoring only the tracked file, the untracked collision blocks the same way and classifies the same. Finally, dropping the generated state lets the merge land, proving the message's own remedy works.
• 16 -- dirt outside the list gets the generic conflict report and is not misattributed to the exempt path, even with exempt dirt present alongside it.
• 17 -- exempt-path dirt the incoming merge does not touch is a non-event: the merge proceeds and the local copy is untouched.

shellcheck -x on the changed script is clean.

[hynek-urban]

Throwing away changes is fundamentally a bit dangerous. As a user, I wouldn't expect the plugin to delete my data in paths that I simply marked as "exempt" (the doc nothwithstanding). Would it make sense to rename the config key so that the danger is obvious?

(Side note: If we follow semver then this probably warrants a major version bump - not sure if it matters since I'm not a user of code-guardian :) )

In any case, up to you :) LGTM - feel free to merge as soon as you're happy with it.