2 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	f1e63d207f	fix(plugin): the sweep missed the arm that fires most — two ledger directories (#4101) ... CI caught two things in c61f730, and the second is the one that mattered. 1. `scribe_autoinject.sh` keeps its note ledger in `${TMPDIR}/scribe-autoinject`, not `scribe-priorart`. Every ledger NAMED in the hooks was in the one directory the sweep visited, so it read as complete — and the arm that fires most (598 calls in five days) was the only one still carrying the bug. The clear ran, found nothing to remove, and exited 0. `SCRIBE_LEDGER_DIRS` in `scribe_defs.sh` is now the roster, and the guard reads that string rather than a copy of it, so a test can no longer agree with itself forever. 2. The convention guard over-reached: it flagged `<sid>.snap` and `<sid>.blocked`, which live in `scribe-afterwrite` and `scribe-reportcheck` and can never be touched by the sweep. It is now two tests keyed on the directory, because the two assumptions fail differently — one lets a ledger sit where nothing sweeps, the other lets it sit in the right place under a name the sweep does not match. `test_only_the_rule_ledger_is_cleared_and_the_note_ledgers_are_left` also went red, correctly: the note arms' exemption was a real decision, recorded in a test, and my commit message said nothing about it had been decided. That was wrong and the test was right to stop me. The decision is reversed rather than ignored, and the reasoning is that #4101 removed its premise: it rested on a note repeat being WITHHELD, so clearing the ledger meant re-injecting whole menu lines the session already had. Now a repeat is rendered with a `seen` marker, so the ledger only decides whether that marker is true — and across a compaction it is false, telling a freshly-summarised session it has already seen a record that is nowhere in its context. The test keeps its name and records the reversal with the reason, rather than being deleted. Verified by running the hook directly: all six ledgers across both directories gone on `compact`, `<sid>.unreached` left standing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 21:11:43 -04:00
bvandeusenandClaude Opus 5	c61f7301bc	fix(plugin): a compaction clears every session ledger, not the two on the list (#4101) ... `scribe_session_context.sh` cleared `.rules.ids` and `.opened.ids` by name and left `.ids`, `.sync.ids` and `.derive.ids` standing, under a comment asserting that was a decision. Reading the note arms says it was not: their exclusions go straight into `semantic_search_notes`, so a surfaced note leaves the result set rather than being rendered as a reference the way #3750 gave a repeated rule, and unlike the rules ledger they never age. Hard, permanent, never cleared — a note surfaced in a session's first minute is unreachable for the rest of it, which is milestone 386's own defect alive on the arms that fire most often. The list was the bug, so the fix is not a longer list. `scribe_clear_session_ ledgers` matches the naming convention instead — a per-session ledger is `<sid>[.<kind>].ids` — which covers all five and covers the sixth on the day it is written. `<sid>.unreached` is deliberately outside it: that records an outage, not held context, and #2932 needs it to survive. tests/test_session_ledger_clear.py runs the hook rather than grepping it for `rm -f`, since grepping for the names is the pattern being removed. It pins both directions — `compact`/`clear` take all five, `startup`/`resume` take none — plus the convention the glob rests on, checked against the hooks themselves so a ledger named outside it fails loudly instead of silently never clearing. Also drops a stale comment pointing at a rules-etag marker that milestone 394 retired. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy	2026-09-16 21:00:42 -04:00