[ww-mw]

Two follow-ups to #80, which turned the integration suite's fixed sleeps into named waits. Both change tests only. Nothing in src/ changes.

B-38: the live-edit test waits for the change listener, not the dirty flag

Ruling (group F, the flake fixes): "convert the known members to waits on a named predicate", one that polls "the actual condition ... failing with the predicate's name on timeout". The wait has to be on the thing the next assertion needs.

What was wrong. In test-integration/suite/liveEdit.test.ts, the test 'a text-view edit dirties the shared document (single source of truth)' waited on doc0.isDirty. That flag is true as soon as the edit applies. So the "extension remains active" check after it no longer waited for the provider's onDidChangeTextDocument listener, even though the comment above the wait said it did.

Root cause. #80 named the wait after the first condition it could see (the dirty flag), not after the listener's own visible effect.

Fix. The test now builds a real SlddTextEditorProvider (imported from src) over the harness's fakePanel, on the same doc0. It sends ready, waits for the first paint (setRows) and clears the posts. After the text edit it waits for "the change listener to repaint the table for the text edit": a setRows or updateEntryRows post. Nothing else in the test makes the view repaint, so that post shows the listener ran. The existing dirty wait and asserts come after it. view.close() runs in a finally. The comments now say what the test waits for, and the findEntrySpanLocal comment no longer claims the bundle is free of jsonc-parser (it now carries it through the provider import, as the other suite files that import the provider do).

Tests, fail-before. The mutant is a provider whose changeSub never subscribes, so the listener is dropped.

• The old test passes on the mutant (8 passing in the file), which confirms the gap.
• The new test fails on the mutant for the right reason: AssertionError: timed out after 20000ms waiting for the change listener to repaint the table for the text edit. The other 7 tests in the file pass.
• On clean src, the liveEdit suite file passed 10 runs out of 10 (8 passing each). The full integration suite passed 3 runs.

Existing tests changed. Only this one test, which the row names. Its isDirty wait stood in for the listener, and the ruling removes exactly that.

B-39: a named wait's timeout says what it saw

Ruling (group F, the flake fixes): waits "failing with the predicate's name on timeout". Before #80, three of these sites also printed what they had seen (two loops, and in jsonDirtyEventRepaint a fixed sleep followed by asserts that print what they saw), and #80 dropped that for the two loops. The new test's header comment and the commit body say "loops" too; wording only.

What was wrong. On main, a timeout from these three waits says only timed out after Xms waiting for <what>:

• forgetOnDiskChange: it used to print the names the index held;
• twoTabBaseline lastRows: it used to print saw <message types>;
• jsonDirtyEventRepaint: it used to print the number of content changes and empty events it saw, and the kinds posted.

Root cause. The harness waitFor had no way to carry what a wait saw, so the conversion had to drop it.

Fix. test-integration/suite/tools/hostHarness.ts waitFor(what, done, ms = 20000, detail?):

• detail() is read once, at the timeout, and added to the message as (<detail>).
• If detail throws, the message becomes (and its detail failed: <msg>), so the timeout still names what it waited for.
• The check moved from assert.ok to if (...) assert.fail(...), so the detail is built only once, at the timeout, and not on every poll. It is still an AssertionError, and with no detail the message is unchanged.

The three sites pass what they printed before:

• forgetOnDiskChange: the index's names;
• twoTabBaseline: saw [types], the old text exactly;
• jsonDirtyEventRepaint: saw N content changes, N empties, and the posts [...]. Its default 20000 is now written out, because detail is the fourth argument.

I left the other waits #80 added in these files alone. Their old loops printed nothing extra.

Tests, fail-before. The new file is test/hostHarnessWaitFor.test.ts (vitest). It drives the real harness waitFor and mocks only vscode, which waitFor does not use. It has 8 tests:

• the timeout carries the detail;
• the detail is read at the timeout, so it shows the last state the condition saw;
• the detail is not called when the condition comes true;
• a detail that throws still leaves the message naming the wait;
• with no detail, the message is unchanged;
• a source check (TypeScript AST) that each of the three waits passes a fourth-argument detail that reads its state.

Before the change, 6 of the 8 failed for the right reason: the message had no detail, and the three sites passed 3 (or 2) arguments. The 2 that passed (no detail, detail not asked for) are trivially true today. After the change all 8 pass.

I also ran an end-to-end demo in real VS Code, not committed: I made each of the three waits impossible to meet, and each timeout printed what it saw, for example ... the index to follow the file (the index held ["GainNew"]).

Existing tests changed. Only the three waits the row names. Each gained a detail argument and keeps its condition, name and cap.

Left out

Nothing from either row.

Gates (at head bf0d592)

• npm run verify: exit 0. vitest: 184 files, 3547 tests passed. Leak checks OK.
• npm run test:integration: 275 passing, 1 pending, exit 0.
• No conflict with current main (Describe corpus files without naming them, in comments, docs and made-up test data #83 touches other files), so I did not merge main into the branch.

Review (both lenses MERGE): under the drop-listener mutant the new liveEdit test fails with its named timeout while the old one passed; with the harness hunk reverted 3 behaviour tests fail; 4 harness and 4 call-site mutants are killed.

Implements the maintainer's rulings, as audited in group H (2026-10-19).