doctor: a hand-rolled pre-commit gate that runs fieldnotes reports as "no fieldnotes pre-commit hook"

[Wynelson94]

Problem

git_hook_installed (githook.py:103) identifies a gate by the HOOK_MARKER string this tool bakes in — "fieldnotes pre-commit gate". A repo whose gate was written by hand rather than by install-git-hook fails that test even when it genuinely runs fieldnotes verify on every commit.

Real case (bsoi-crm-app, 2026-07-24). The repo tracks its own .githooks/pre-commit, wired via core.hooksPath, documented in its CLAUDE.md:

$ grep -c "fieldnotes pre-commit gate" .githooks/pre-commit   # marker
0
$ grep -c fieldnotes .githooks/pre-commit                     # real calls
7
$ git config --get core.hooksPath
.githooks
$ fieldnotes doctor
✗   git pre-commit gate   no fieldnotes pre-commit hook in this repo
  git pre-commit gate: Run `fieldnotes install-git-hook` to block commits that stale a note.

The gate is armed and demonstrably blocking — a test commit that staled note 0028 was rejected — while doctor says it doesn't exist.

Why the advice is worse than the ✗

The suggested fix is install-git-hook, which resolves to the configured core.hooksPath (correctly — githook.py:49-54 honors it). In this repo that's .githooks/, i.e. tracked. install_git_hook refuses to overwrite a hook it didn't write, so it should decline rather than clobber, but following doctor's advice here is at best a no-op and at worst noise in a tracked directory.

Suggested fix

Treat "runs the fieldnotes binary in a pre-commit hook" as installed, marker or not — e.g. fall back to grepping the resolved hook for a fieldnotes verify invocation when HOOK_MARKER is absent, and report it as a distinct state:

✓   git pre-commit gate   custom hook at .githooks/pre-commit (not tool-managed)

That keeps the ✓ honest, tells the reader the tool doesn't own the file, and drops the misleading fix line.

Not a core.hooksPath bug

Worth recording, since it's the obvious first guess: githook.py already resolves core.hooksPath correctly, including relative values against the work tree. This is purely marker-based detection.