[shennarwp]

Problem

.git/hooks/ is not tracked by git, so the tracked hooks in .githooks/ had to be copied in by hand after every fresh clone.

On this clone the copy step had never actually run:

$ git config --get core.hooksPath
$ ls -A .git/hooks/ | grep -v sample
(empty)

So commits went through with no tools/validate.sh --hook and no gitleaks scan. README.md documented the copy step, but nothing enforced it — which is what TASK-22 called out.

Fix

tools/install-hooks.sh now defaults to core.hooksPath=.githooks:

• No copying, so the tracked hooks cannot go stale against a working-tree edit.
• --copy remains available for setups that cannot set core.hooksPath (older git, shared .git directory).
• --hooks-path kept as an explicit no-op alias, so existing invocations keep working.
• --uninstall unchanged: unsets the config and still only deletes copies carrying the managed-by marker.

hooks-path mode also reports stale marked copies left in .git/hooks/. core.hooksPath wins over them, so they are inert, but their presence is confusing otherwise.

Docs updated: README.md (tree, quick-commands block, Secret scanning section) and AGENTS.md.

Verification

$ tools/install-hooks.sh
core.hooksPath = /home/shennarwp/repo/dotfiles/.githooks
hooks active: pre-commit

$ git config --get core.hooksPath
/home/shennarwp/repo/dotfiles/.githooks

$ ls -A .git/hooks/ | grep -v sample
(empty)

tools/validate.sh passes. Both commits ran through the newly-activated hook, which is the fix confirming itself.

shellcheck reports SKIP on this host (not installed); CI covers it.

Note for reviewers

Editing tools/install-hooks.sh dropped its exec bit in the worktree, and core.fileMode=false meant git did not notice. chmod +x was applied before committing. Worth a look at whether core.fileMode should be true on Linux hosts — it currently hides mode drift everywhere.