kevin
5100f215cf
CI / build (push) Successful in 1m33s
Five tests pinning the invariants that decide WHICH turn a reply belongs to. These protect against a silent correctness bug — a reply attributed to the wrong turn — not against a crash, which is why they were worth picking over higher-percentage coverage gaps. Chosen by blast radius, not by uncovered-line count. Both guards are compound conditions with a side that never executed, i.e. exactly the shape where a clause can be deleted as "redundant" and every existing test still passes. CompletionResolver: - The CB-115 misattribution guard suppresses a completion when the scrape is byte-identical to the pane at delivery. Its !scrapeFailed clause was unexercised: delete it and a FAILED read is misread as "no output change", so the send is suppressed and hangs to the caller's timeout instead of resolving. The new test sets the baseline to "" so the empty tail from a failed read would byte-match and wrongly suppress — built to die precisely when that clause dies. - The fail() guard leaves an already-resolved waiter alone. The new test also asserts agent.read is never called, so the worker is not scraped for a send nobody is waiting on. Rendezvous: a second resolution of an already-completed waiter returns false and does not overwrite the first value, for both resolveCompletion and resolveFailure. Verified by sabotage, one guard at a time: removing !scrapeFailed reds resolvesWhenTheScrapeItselfFailsEvenWithABaselinePresent; removing the isDone() clause reds failLeavesAnAlreadyResolvedWaiterUntouchedAndSkipsTheScrape. (The first attempt at the second sabotage reported a false pass — the patch hit an identically-worded guard earlier in the file. Line-targeted and re-run.) 346 tests, was 341. Worker-implemented on the local-vLLM profile; it noticed three of the eight cases I asked for already existed and said so with names rather than duplicating them. Also of note: the first delegation of this ticket wedged the worker — the pane showed a zsh parse error and it went idle with an untouched worktree, task stuck pending. The retry differed only in phrasing the same requirements as prose instead of quoting Java boolean expressions. Filed as a bridge robustness concern: injected content shares a channel with control, and a wedged turn is invisible in both the task view and /metrics.