A ledger-folded payload gets an omitted-count on top of folds that already account for all of it, and a [Partial signal] banner over a complete answer

[fajarhide]

Bug Description

On a payload the ledger has folded, the trailing banner block makes two false claims about
completeness. Both fire on the same command, and both are the "false claim" class from
CONTRIBUTING.md rather than lost signal: nothing is missing, the output says otherwise.

1. The omitted-count is added on top of folds that already account for the whole input.
The ledger markers plus the surviving lines sum to the entire payload, and then a further
[OMNI: N ... omitted, ... for full output] line claims more was cut. Summing what the
output states gives more lines than the command produced.

2. [Partial signal] on an output where nothing was lost. Same shape as #335, which
fixed it for the grep restructure. The guard at src/hooks/post_tool.rs:945 is
distilled_lines <= content.lines().count(), which a ledger fold passes trivially,
because folding always lowers the line count.

Steps to Reproduce

git log --oneline -40 in this repo is 40 lines, 3,238 bytes. Run it twice so the ledger
has something to fold.

Through the post-hook, second run:

[OMNI: 25 lines identical to an earlier run, omni retrieve 809993a8233d63f7]
f06a101 test(bench): resolve headroom from the command, and fail when a named arm is silent (#730)
[OMNI: 14 lines identical to an earlier run, omni retrieve c7c1d5a32e077257]
[OMNI: 1 bytes omitted, omni retrieve 6e784bc201bed9c1 for full output]

25 + 1 + 14 = 40, the whole input, before the fourth line claims anything. (1 bytes
also disagrees with itself on plural.)

Through omni exec, isolated OMNI_DB_PATH, second run:

b12235d test(hooks): say what the Codex arm does not prove
...
f06a101 test(bench): resolve headroom from the command, and fail when a named arm is silent (#730)
[OMNI: 14 lines not shown here, omni retrieve c7c1d5a32e077257]
[Partial signal]

26 printed + 14 folded = 40. Nothing was omitted, and the banner says the signal is partial.

The count also moves between runs of byte-identical input. Twice through the installed
post-hook in one session, the same 40 lines, with the ledger markers summing to 40 both
times:

run 1: [OMNI: 27 lines omitted, omni retrieve 9de61c2903b1d433 for full output]
run 2: [OMNI: 36 lines omitted, omni retrieve 9de61c2903b1d433 for full output]

Handles resolve correctly in every case, so #388 has not regressed. 9de61c2903b1d433
returns all 40 lines and 3.2 KB.

Expected Behavior

The line numbers a reader can sum should not exceed the input, and a payload that lost
nothing should carry no [Partial signal].

Context

omni 0.7.9 (homebrew), macOS 15 / darwin 25.5.0, Claude Code. Evidence is this repo's own
git log, so nothing is redacted.

Relevant Logs

rewind_marker (src/hooks/post_tool.rs:172) computes
omitted_lines = input_lines - kept_lines, and its doc comment at :166 says kept_lines
describes what the distiller produced. The ledger runs after distillation and rewrites the
output, so the banner's figures and the ledger's markers measure two different stages of the
same payload and land in one blob with nothing telling them apart.

What I did not trace: why the count reads 27 then 36 for byte-identical input. A figure taken
from the distiller alone should be stable across both runs, so on that path something is
reading the count after the ledger. That variance is the part to chase, and I would not fix
this from the doc comment's intent alone.

Why it matters

An agent reading the git log output sums the markers and concludes 67 or 76 lines existed
where 40 did, and [Partial signal] tells it to retrieve or re-run a command that already
returned everything. Both cost a round trip on a complete answer.

How this differs from #767

#767 is about what a fold marker says, the wording a reader stops on, and it is blocked on
#766. This is the arithmetic: the numbers are wrong and mutually inconsistent whatever wording
carries them. Fixing #767's sentence would leave both claims here false.

[fajarhide]

The variable count is the ledger's net line delta, read after the fold.

Two runs of git log --oneline -40 (40 lines) through the installed 0.7.9 post-hook, same session:

run A: 8 shown + [14 lines not shown] + 1 shown + [17 lines not shown]          = 40
       [OMNI: 29 lines omitted, omni retrieve 91e7492e2c005907 for full output]
run B: [8 lines identical] + [14 not shown] + 1 shown + [17 not shown]          = 40
       [OMNI: 36 lines omitted, omni retrieve 91e7492e2c005907 for full output]

29 = 31 folded lines minus 2 marker lines. 36 = 39 folded minus 3 markers. Both exact, and
the same handle carries both counts. So the figure is pre_ledger_lines - post_ledger_lines,
not input_lines - distilled_lines, which is why it moves on byte-identical input: the
second run folds more. That is the "27 then 36" variance in the body. The call at
post_tool.rs:1000 does pass the pre-ledger distilled_lines, so either that is not the
call emitting this marker or distilled_lines is not holding what :840 intends on this
path.

[Partial signal] reproduced on a second cat README.md in the same session, where every
removed run carried a retrieve handle. grep -c "Partial signal" README.md is 0, so the
banner is appended, not quoted.

Also of note for the repro: omni exec git log --oneline -40 against an isolated
OMNI_DB_PATH returned all 40 lines verbatim on the first, second and third run, with no
markers at all. The double accounting only appeared on the post-hook path.

omni 0.7.9 (homebrew), Claude Code, macOS.

[fajarhide]

Claim 1 is fixed. Claim 2 did not reproduce, and the difference between those two sentences
is the whole of this comment.

Reproduced first, on the installed 0.7.9 through the post-hook with an isolated DB.
git log --oneline -40, twice, second run:

[OMNI: 22 lines identical to an earlier run, omni retrieve 87538eab3c7f9929]
[OMNI: 17 lines identical to an earlier run, omni retrieve c7ca76c26123fa4d]
<one surviving line>
[OMNI: 1 bytes omitted, omni retrieve 91e7492e2c005907 for full output]

22 + 17 + 1 = 40, the whole input, and then a fourth line claims a byte more.

The mechanism is narrower than the doc comment suggests. The banner's numbers do come
from the distiller, correctly and deliberately (#519). What did not was the test that
decides whether to print it: final_out.len() + marker.len() < content.len(), and
final_out at that point is the ledger's output. So the ledger's saving paid for a
marker describing the distiller's cut, and here that cut was one byte, almost certainly a
trailing newline. It reads distilled_len now, so the marker is affordable only when the
cut it describes can pay for it.

The first version of that fix broke a real saving, and the second commit is that. The
else arm throws the entire reply away and passes through, which was right when the
distiller was the only stage that touched it. With the ledger running first it turned a
3,257 byte reply folded to 325 into a passthrough. It now passes through only when the
ledger left the reply alone. After both, the same command delivers 252 bytes and the
markers sum to exactly 40.

Claim 2, [Partial signal] over a complete answer: could not reproduce. Three
attempts, all on 0.7.9 with isolated databases: the post-hook on the reported command, the
same through omni exec, and a constructed 130 line log payload chosen to land the
distiller in a partial route. None emitted it. That is not a verdict that it is unreal, you
saw it: [Partial signal] needs route == Route::Soft and a partial rather than
whole-output fold, and every payload I could build folded whole or did not reach Soft. The
guard is the same class of stage-mixing and probably wants the same treatment, so this
issue stays open on that half with a note of what the fixture has to hit.

The 27 then 36 variance you did not trace has an explanation that fits. The scorer
reads session history, so OMNI's output is not deterministic against a warm ~/.omni, and
distilled_lines moves with it. On a cold isolated database the distiller cut no lines at
all, which is why my repro says 1 bytes where yours said 27 lines. Stated as the
likely cause rather than a proven one, since I did not hold the DB state constant and
watch it move.

[fajarhide]

Reopened, and the closure was my mistake rather than a decision.

#777 merged as cdb4b35 and fixes claim 1. My first commit on that branch wrote
Closes #775 before I had established that claim 2 does not reproduce, and GitHub
evaluates that keyword at merge time, so the issue closed with half of it outstanding.

What remains open here is only claim 2, [Partial signal] over an output where nothing was
lost. Three attempts to reproduce it are recorded in the comment above, along with the two
conditions a fixture has to hit at once: route == Route::Soft and a partial rather than
whole-output fold.

The recoverability question #777's review surfaced is #778, not this issue.

Board Status was cleared to Todo before reopening, because this project's auto-close
workflow fires again on an item already marked Done the moment it is touched.