`gitnexus status` reported "stale (re-run gitnexus analyze)" whenever the
working tree held any modified or untracked file, including files the index
never reads. Because `analyze` cannot commit, stash or delete such a file,
the remedy it prescribed could not clear the verdict — the only way back to
up-to-date was to remove the file.
`meta.fileHashes` already records the exact set of files a run covered, so
answer the question directly: compare those hashes against disk, reusing
analyze's own scan, hash and diff helpers so the two cannot disagree about
what "changed" means. A new coverable file still counts as stale (the index
is genuinely incomplete then), but one `analyze` now settles it. The
repo-wide dirty flag survives only as the fallback for metadata written
before `fileHashes` existed.
Both freshness checks now read GitNexus's own analyze output (AGENTS.md,
CLAUDE.md, the agent skill mirrors) from one shared list. They previously
held separate copies, and since analyze rewrites those files after
recording hashes, a per-file comparison that missed them would report a
freshly indexed repository as permanently stale.
Closes#3077
Co-authored-by: Gergo Magyar <gergomagyar0@gmail.com>
Co-authored-by: Cursor <cursoragent@cursor.com>