[Bug] hook status reports a non-executable post-commit hook as installed

Start in packages/cli/src/repowise/cli/hooks.py, especially install and status around the cited lines, then trace the doctor check in commands/doctor_cmd/repo_checks.py:227. Confirm Git's executable-hook behavior on POSIX and the Windows distinction, then add coverage for marker-present hooks without execute permission. Done means install, status, and doctor distinguish a non-executable hook while remaining quiet on Windows.

Summary

hooks.status decides the post-commit hook is installed from the presence of the marker comment. It does not check the executable bit, and install sets that bit inside a suppressed exception.

packages/cli/src/repowise/cli/hooks.py:405-411:

content = hook_path.read_text(encoding="utf-8")
if _HOOK_MARKER in content:
    pending = husky_pending_reason(hook_path.parent)
    return f"installed ({pending})" if pending else "installed"
return "not installed"

packages/cli/src/repowise/cli/hooks.py:350-352:

# Make executable (no-op on Windows but harmless)
with contextlib.suppress(OSError):
    hook_path.chmod(hook_path.stat().st_mode | stat.S_IEXEC | stat.S_IXGRP | stat.S_IXOTH)

If that chmod raises, install still returns "installed" and status still reports installed, over a file git will not run.

Consequence

On POSIX, git skips a post-commit hook that is not executable. The user then has a repository where repowise hook status says installed, repowise doctor says the same through commands/doctor_cmd/repo_checks.py:227, and the wiki silently never updates after a commit. The symptom is "state never moves", which is the exact symptom the hook's own comment block says the .update.log capture was added to make diagnosable (hooks.py:49-55).

The realistic ways to reach it are narrow: a .git/hooks directory mounted read-only, a filesystem with no execute bit, or a restrictive umask combined with the append branch writing into a file someone else created. It is not a common case, and this is filed as a small correctness gap rather than a frequent failure.

The suppression itself is reasonable. chmod is a genuine no-op on Windows and failing an install over it would be worse. The gap is that nothing downstream ever checks whether it took.

Done looks like

status distinguishes "the block is there and git will run it" from "the block is there". Something like a third return for the marker-present but not-executable case, so hook status and doctor can say which one it is.

install reporting it is the other half and probably the more useful one, since that is the moment the user is standing there. It already has the return value to carry it, alongside the existing "installed" and "already installed".

Both need to stay quiet on Windows, where the bit is meaningless. os.access(path, os.X_OK) reports true for most files on Windows, so a stat.S_IXUSR check gated on os.name != "nt" is likely the cleaner test.

Scope note

Verified by reading install and status in full. I did not construct a repository where the chmod fails, so the failure is reasoned from the code rather than reproduced. Anyone picking this up should confirm the git behaviour they are protecting against on their own platform before choosing the test.