Skip to content

fix: linter was dead in a personal-store-only project - #3

Merged
aoc81 merged 1 commit into
mainfrom
fix/linter-personal-only-store
Sep 12, 2026
Merged

aoc81 merged 1 commit into
mainfrom
fix/linter-personal-only-store

Conversation

@aoc81

@aoc81 aoc81 commented Sep 12, 2026 •

Copy link
Copy Markdown
Owner

The bug

verify_refs.main() bailed whenever the team store directory was missing, even
with personalStoreDir set and populated:

$ python plugin/scripts/verify_refs.py --stats
No learnings store at .../learnings - run /lore:init first.   (exit 0)

Same for the default mode, --strict, --report and --dupes.

Personal-store-only is a supported setup — it is how you keep notes you do not
want published — and in it recall and capture keep working. So the store looks
healthy while /lore:lint, /lore:stats and /lore:sweep are all silently
gone. The printed advice was wrong too: the project is initialized, just
personal-only.

The early return predates the personal store and was never revisited when it
landed.

The fix

Give up only when both stores are absent. The traversal was already correct —
creating an empty learnings/ directory made every mode work, and --stats then
reported personal store: 2 entries in .lore/personal plus per-entry recall
activity — so this is the guard clause only.

Scope decision

Deliberately unchanged: the personal store still feeds --stats and nothing
else, for the reasons documented in _personal_entries (not committed, so
nothing to index and no push boundary to secret-scan). scan_secrets.py is
untouched — skipping the personal store there is correct by design.

Two consequences are handled explicitly rather than left implicit:

  • --index becomes a no-op with a message when there is no team store, instead
    of writing a README into a directory that does not exist.
  • The check mode no longer prints "all entries have valid frontmatter file
    refs"
    after examining zero entries. A clean bill of health for a store nobody
    checked is the same failure this PR fixes, one level down.

Tests

Six cases in tests/test_verify_refs.py drive main() through a personal-only
project via CLAUDE_PROJECT_DIR. Five fail without the guard change; the sixth
pins the message for a populated team store so existing output cannot drift.
Full suite: 168 tests, OK.

Verified exit codes

scenario exit
--strict, broken ref in team store 1
same without --strict 0
--strict, personal-only 0

`verify_refs.main()` bailed whenever the team store directory was missing, even
with `personalStoreDir` set and populated:

    $ python plugin/scripts/verify_refs.py --stats
    No learnings store at .../learnings - run /lore:init first.   (exit 0)

Same for the default mode, --strict, --report and --dupes. Personal-store-only is
a supported setup — it is how you keep notes you do not want published — and in
it recall and capture kept working, so the store looked healthy while /lore:lint,
/lore:stats and /lore:sweep were all silently gone. The early return predates the
personal store and was never revisited when it landed. The advice it printed was
wrong too: the project IS initialized, just personal-only.

Give up only when BOTH stores are absent. The traversal was already fine — an
empty `learnings/` directory made every mode work — so this is the guard clause
only.

Scope is deliberately unchanged: the personal store still feeds --stats and
nothing else, for the reasons documented in `_personal_entries` (not committed,
so nothing to index and no push boundary to scan). Two consequences handled
explicitly rather than left implicit:

- --index is a no-op with a message when there is no team store, instead of
  writing a README into a directory that does not exist.
- The check mode no longer reports "all entries have valid frontmatter file
  refs" after examining zero entries. A clean bill of health for an unchecked
  store is the same failure this commit fixes, one level down.

Six tests in tests/test_verify_refs.py drive main() through the personal-only
project; five of them fail without the guard change, and the sixth pins the
message for a populated team store so the existing output cannot drift.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@aoc81
aoc81 merged commit 2c533b6 into main Sep 12, 2026
6 checks passed
@aoc81 aoc81 mentioned this pull request Sep 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant