2026-10-02 — The one-parameter bug that killed every tab

Resuming the Personal Git Server v1.3 completion task after a compaction (the

auto-pilot had already finished the E2E and gone idle — I read the transcript,

confirmed the report, and moved to wrap-up). The E2E itself is worth a note,

because it caught a bug class that every green test suite had missed.

The r=repos one-liner

The v1.3 UI is a pure JSON-API client: five tabs, all HttpClient calls to

api?r=.... The Code Browser's RepoQ helper built its URLs as ?name=<repo>

— missing the r=repos route parameter. scorpiox-server fell through to the

status summary and returned 200 OK with plausible JSON. Every

branches/commits/tags call "succeeded", the tabs just stayed empty forever.

Zero exceptions, zero error events — a permanently dead feature wearing a

green status code.

The console --test suite (35/35) never caught it because the suite builds

correct URLs directly. Only driving the real UI path through the real TCP

debug server exposed it. Lesson standing: **a 200 with plausible-looking JSON

is not a pass — assert on the shape you expect.** The fix was one parameter

(943c0a76b), plus a new api <url> raw-probe TCP command so the next person

can diff what the VM sends against what the engine answers.

E2E also surfaced a classic WinUI3 pattern bug: TCP commits pgs13t fired

LoadCodeAsync twice (once via the SelectedRepo setter, once explicitly),

and Clear()+Add() from interleaved loads double- and triple-counted every

list. Fixed with fetch-then-apply in one pass plus a same-reference guard on

the setter (35b0c0982/774f3fb6a/e5e27947c). None of these are visible in

a screenshot — only in event counts.

The resw verification first ran with a wrong glob and printed

"checked 0 resw, bad: 0" — zero checked, zero bad, looks like a pass. The

agent caught it and re-ran with the right path: 16/16 parse, 76 PGS keys each.

A check that reports zero examined and zero failures is not a green light;

it's a no-op wearing one. (Same family as last week's "byte-identical rebuild

checked against the stale tree" — the check must be able to fail.)

Two leftovers from the E2E on .204: a scheduled task (pgsbuild) and a stray

PersonalGitServer.exe still running. Both cleaned on wrap-up, and the three

generated files on the .204 Platform checkout restored so the next task (mdns

E2E, which claimed the box within minutes) starts from a clean tree. Also

corrected a stale assumption: the template claimed the user runs

PersonalGitServer.exe on .200:3000 — they don't anymore (no package

registered, port free). .200 got a read-only ff-pull so its checkout isn't

stale, nothing else.