Proof audit pass 1 — proposed plan before capture

Scope: head d2c97fc5a884c85144ddc884bbe3efb7c9343b5d versus merge-base b72740852ffb5ab727e1ae7c042d9e89533bc341, source /home/ubuntu/wt/pr-19799. Read review-A.txt and review-B.txt (both MERGE, no findings), the complete pinned diff, and collectOutput/execute context. No tests, installs, forge/network access, DB access, benchmarks, source replacement, or source edits performed. Only this report written.

Assessment: the proposed experiments are appropriate, but the plan as stated leaves required measurement and validation rows underspecified. This is a proof-plan verdict, not a new code defect or a rejection of either source review. The production change skips line-buffer work when a stream has no callback; returned decoding and byte accounting remain outside the gate. Functional preservation alone cannot prove the performance claim.

Required capture rows / acceptance criteria:

R1 — Identity and restoration. Record actual checkout SHA, clean/dirty status, hashes of head core and merge-base core, exact commands and harness source. Use the same installed head dependencies/runtime/config for both variants. Baseline replaces ONLY apps/server/src/vcs/GitVcsDriverCore.ts; retain head tests and benchmark harness. Restore head via guaranteed cleanup even on failure, then verify the core hash and final status. Label baseline as merge-base core under head dependencies, not a full merge-base checkout. Capture restoration proof before declaring completion.

R2 — Focused tests and preservation interpretation. Capture full focused driver-file output at restored/pinned head, command, exit status and test totals. Run both named new tests with only merge-base core substituted; capture names, assertions' pass/fail status and exit status. Green on both is expected preservation evidence, not a red-before/green-after regression demonstration. If either fails, explain the actual failure rather than treating all failures as evidence for the optimization. Do not infer execution from the two source reviews.

R3 — Fake-process benchmark validity. Four paired cells: 1 MiB and 4 MiB, each baseline/head, through public makeGitVcsDriverCore().execute with no progress callbacks. Define exact payload bytes (NUL-separated, no CR/LF), exact 64 KiB chunks and replayable streams per invocation. Prebuild equivalent payloads outside timing. Set an explicit maxOutputBytes above 4 MiB, disable truncation acceptance, and assert exitCode 0, both truncation flags false, exact stdout byte count/content and expected stderr for every run. NUL is not a line separator here, so this exercises repeated scanning of the growing pending line. Do not benchmark a copied collector or private helper.

R4 — Real-git benchmark validity and callback control. Four paired cells: 20,000 files baseline/head, without/with onStdoutLine. Specify fixture generation, filename lengths/distribution, Git index population, exact ls-files -z args, output bytes, and expected entry count. Files must be indexed (or the command must explicitly include untracked files); merely creating files can yield empty ls-files output. Keep fixture/index/config identical across variants, outside timing. Set an adequate explicit cap; verify identical complete output/flags/exit status in every cell. Use the same minimal callback and count delivered lines: a NUL-only listing should deliver one nonempty trailing callback at EOF, not 20,000 callbacks. Do not store or log callback payload inside timed work. This callback cell is an unchanged-path control, not a claimed optimization target.

R5 — Timing protocol and reporting. Specify at least one untimed warmup followed by five measured executions PER variant and workload/callback cell. Time awaited completion of public execute, using the same driver lifecycle, layers, runtime and timer boundary in both variants; exclude compilation/import, fixture creation, payload preparation, assertions and printing. Record all five samples, units, median and baseline/head ratio, and report callback-control regressions or noisy/neutral results candidly. Use fresh processes when swapping source so module caches cannot run the wrong version; apply equivalent startup/warmup policy. Prefer balanced variant order to reduce cache/load bias, record order, and report host load/concurrent work. Five samples support a local median comparison, not universal performance or memory claims.

R6 — Public behavior proof matrix. The two added tests already assert split UTF-8/NUL returned strings, callback lines, truncation of stderr and rejection outputLength without callbacks. Capture those actual assertions/results. Supplement public fake-driver cases where the plan claims broader coverage: stdout-only callback and stderr-only callback with independently checked stream results; truncation at a multibyte boundary and exact cap/over-cap behavior; continued callbacks after truncation when enabled, including later chunks and EOF flush. Run equivalent cases on both core variants. Compare exact expected strings/encoded bytes where valid UTF-8 is preserved; for a partial multibyte cap explicitly expect the replacement character (the returned UTF-8 encoding need not equal the raw truncated input bytes). Assert truncation flags and error outputLength, not only a matching prefix. These are preservation checks; do not require them to fail on baseline.

R7 — Machine and claim scope. Record OS/architecture, CPU, RAM, Node/runtime, Git and test-runner versions, dependency/lockfile identity, benchmark command and relevant process settings. State that real-git timings include spawn/stream overhead and synthetic timings isolate a controlled producer, both through the public API. Do not claim allocation/peak-memory improvements without measuring them. Treat supplied current-main 71a283aed2 conflict information as contextual: a test-addition/makeFailedHandle conflict does not obsolete this optimization. These pinned results do not establish merge readiness against current main or prove conflict resolution.

No fixes requested or made. Source reviewers' MERGE verdicts remain distinct from this evidence-plan completeness check. Required refinements are explicit capture/validation rows, not demands for new production machinery or repo-wide tests.

VERDICT: INSUFFICIENT R1 R2 R3 R4 R5 R6 R7
