Skip to content

fix(ledger): close-out count derives from ledger's own lines, never below them#33

Merged
andrewwint merged 1 commit into
mainfrom
fix/ledger-count-own-lines
Jul 10, 2026
Merged

fix(ledger): close-out count derives from ledger's own lines, never below them#33
andrewwint merged 1 commit into
mainfrom
fix/ledger-count-own-lines

Conversation

@andrewwint

Copy link
Copy Markdown
Owner

A real integration test (feeding genuine PostToolUse/Stop JSON to the shipped hook) surfaced a visible contradiction: the Stop close-out printed "lanes recorded this session: 0" directly above 2 lane lines.

Cause: the count read only .agents/runs/lane_spawns.jsonl (written by the separate record_lane_spawn.py sidecar), while the lane lines are written by ledger.py's own PostToolUse handler. When the sibling hasn't fired, the count reads 0 despite ledger.py having just written N lines — two sources for one fact that can visibly disagree.

Fix: lane_count() now returns max(own lane lines in ledger.md, sibling lane_spawns.jsonl) — never lower than the visible lines, and a sibling-only observation isn't lost. A shared _LANE_MARK couples the writer (lane_line) and reader (_own_lane_lines) so they can't drift.

Test: new group G runs only ledger.py through N spawns + a Stop (no lane_spawns.jsonl seeded) and asserts the count matches the N lines — the coupling can't hide the bug. Reproduced the exact reported scenario: 2 lanes → "lanes recorded this session: 2", Read event ignored.

Robustness/consistency fix — in a fully-wired session both hooks co-fire and the count was already right. Independent cold-read review: pass, no blockers.

🤖 Generated with Claude Code

…elow them

A real integration test surfaced a visible contradiction: the Stop close-out printed
"lanes recorded this session: 0" directly above 2 lane LINES. Cause — the count read
ONLY .agents/runs/lane_spawns.jsonl (the separate record_lane_spawn.py sidecar), while
the lines came from ledger.py's own PostToolUse handler; when the sibling hasn't fired
the count reads 0 despite ledger.py having just written N lines.

Fix: lane_count() now returns max(own lane lines in ledger.md, sibling lane_spawns.jsonl),
so the count is never lower than the lines shown and a sibling-only observation isn't lost.
A shared _LANE_MARK couples the writer (lane_line) and reader (_own_lane_lines) so they
can't drift. New test group G runs ONLY ledger.py through N spawns + a Stop (no
lane_spawns.jsonl seeded) and asserts the count matches the N lines — the coupling can't hide.

Robustness/consistency fix; in a fully-wired session both hooks co-fire and the count was
already right. Independent cold-read review: pass, no blockers.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
@andrewwint
andrewwint merged commit 97d9102 into main Jul 10, 2026
2 checks passed
@andrewwint
andrewwint deleted the fix/ledger-count-own-lines branch July 10, 2026 13:51
andrewwint added a commit that referenced this pull request Jul 10, 2026
… own lines (#34)

Bumps 1.3.0 -> 1.3.1 (plugin.json, runtime/package.json, lockfile) + CHANGELOG 1.3.1 entry.
Patch: the ledger close-out count now derives from ledger.py's own recorded lane lines
(reconciled with the sibling lane_spawns.jsonl), so it can never read lower than the lines
it displays. Trail-only; no enforcement/verdict change. Fix landed in #33.

Co-authored-by: Claude Opus 4.8 <[email protected]>
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