fix: refuse a tracked file in any repo, not just the running package (0.7.1)

[vib795]

The bug

insideCheckout asked whether the running package had a .git. That is true from a checkout and false from an installed package — but a registered path can point into a checkout regardless of where the running code lives.

running from	registered path → tracked file	guard
the checkout	tracked	fires ✅ (the 0.6.x fix)
installed package	tracked	doesn't fire ❌

Switching a machine from npm install -g . to the published package leaves exactly such a path behind in skillPaths. The next compact wrote a machine-specific digest into a tracked skills/recall/SKILL.md.

This is the same failure that shipped one machine's note count for twenty releases, reached from the other direction. Observed on a real install during the 0.7.0 upgrade, not hypothesised.

The fix

The question was always about the target, never about where the code runs from. So ask git about the target:

git ls-files --error-unmatch -- <basename>   (cwd: dirname)

A non-zero exit covers both "not tracked" and "not in a repository", and both mean the same thing here: writing publishes nothing. ENOENT means git is missing, which is not an answer — that falls back to the previous package-root heuristic. A machine with no git also has no tracked file to damage.

realpathSync runs first, because the path arrives as a symlink setup planted. Asking about the link answers "not tracked" and then writes straight through it into the repository.

Results are cached per process — one process, one answer, so the cache cannot go stale.

Proof the test is not vacuous

Replicating the old guard and pointing it at a tracked file in another repo:

OLD guard on a tracked file in another repo : false   <- false means it would WRITE
NEW guard on the same file                  : true    <- true means refused

The new test also covers an untracked file in the same repository, which must still be written — the guard is about tracked-ness, not about being near a .git.

Verification

• 106 tests pass, up from 105
• Zero dependencies; node:child_process was already in use in staleness.js
• All version locations synced to 0.7.1, covered by the existing sync test

🤖 Generated with Claude Code

https://claude.ai/code/session_014fSLBRUVVhAauWDuzJM4mc

[coderabbitai]

Warning

Review limit reached

Next included review available in 1 minute.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 4847fb70-3671-4c09-99ad-d2fe8027f1c2

📥 Commits

Reviewing files that changed from the base of the PR and between fda2dc5 and 4b8dabf.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (6)

• .claude-plugin/marketplace.json
• .claude-plugin/plugin.json
• README.md
• package.json
• src/compact.js
• test/integration.test.js

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}