An environment gate probes the live plane for a precondition it does not control, and four workers falsify it

Context

The fifth isolation defect, surfaced by the workers: 4 re-land probe on PR #17183 — and it exists because #15861's AC-2 requires two samples rather than one.

Sample 1 at head ca6152c2ea was a clean zero-retry green: 13547 passed · 120 skipped · 0 flaky. Sample 2, same head, same config, found this. One sample would have declared victory.

Both samples reported CI success. As with #17186, only the flaky count distinguished them.

The Problem

test/playwright/unit/ai/services/memory-core/HealthService.starvationFold.spec.mjs:265 — "PRODUCTION CHAIN at the composed MCP surface — degraded receipt degrades the response while ensureHealthy() tool admission stays open (#17049)"

HealthService.clearCache();
const base = await HealthService.healthcheck();
// Environment gate, asserted loudly: the admission pin needs a healthy base composition.
expect(base.status).toBe('healthy');

The spec's own comment names it: an environment gate. It clears the cache, probes the live plane, and asserts the plane comes back healthy — then proceeds to its actual subject, which is that ensureHealthy() stays resolvable when the only degradation is starvation.

The precondition is not something this test controls. At one worker the plane is quiet and reports healthy. At four, three other workers are driving load through the same composition, and healthcheck() can legitimately return something else. The assertion then fails on a true statement about a contended plane.

A different mechanism from #17186, and worth keeping separate

#17186 was a timing guess. This is isolation proper: the test reads global state that co-running workers change. Fixing one does nothing for the other, which is why this is its own leaf rather than a second AC on that one.

The Architectural Reality

The failing assertion is scaffolding, not subject. The test's actual claim is the admission pin — starvation-only degradation must not block tool capability, so ensureHealthy() resolves rather than throws. The healthy-base check exists to make that claim meaningful, and it is the only part that touches the live plane.

Three unit specs call HealthService.healthcheck(). Only this one asserts the result as a precondition; the others assert on it as their subject, which is a different and legitimate thing. That distinction should be confirmed before any of them is touched — the same restraint #17186 records, for the same reason: a probe that has never failed may be asserting something the test does control.

The Fix

Construct the base composition the test requires; do not ask the plane for it. The spec already builds degraded compositions elsewhere in the same file — the healthy baseline is the one case it delegates to a live probe, and that asymmetry is the defect.

This is the shape that landed on PR #17167 today for an unrelated ADR-0019 conflict: when a test needs a specific state from a service, the service takes an injectable seam and the test supplies the state, rather than the test reaching for whatever the environment happens to hold.

Explicitly not the fix: relaxing toBe('healthy') to tolerate degraded. That would let the admission-pin assertion run against a base composition it was never meant to run against, so the test would keep passing while no longer testing the pin. #15861's Out of Scope forbids weakening a spec to make the flip stick, and this is the case it was written for.

Acceptance Criteria

Scope corrected 2026-08-15 by the author, after @neo-gpt's RA-2 on PR #17193. A fourth AC — "the spec passes at --workers=4 with zero retries" — was removed, not deferred, and the distinction is the point.

It was first amended in place, with a long note explaining that no PR against dev can satisfy it (dev runs workers: 1, so only #17183 carries the flip). That note was accurate and it was the wrong instrument: it left an unchecked box with a caveat attached, which is precisely the disclosure-instead-of-disposition pattern I reject in other people's tickets. A criterion that another ticket owns does not belong here in any form — a reasoned excuse for an unmet AC is still an unmet AC, and Resolves against it is a contradiction whatever the prose says.

The criterion is not weakened: #15861's AC-2 already requires two zero-retry samples at one head, and those samples ARE this verification. It exists once, on the ticket that can satisfy it.

Acceptance Criteria

• The environment gate no longer depends on a live-plane probe — the healthy base composition is constructed, matching how the degraded compositions in the same file are already built.
• Red-proved: the repaired test still fails when the admission pin genuinely breaks (ensureHealthy() throwing under starvation-only degradation), so the arm keeps catching what #17049 wrote it for.
• The other two HealthService.healthcheck() callers are read and dispositioned — confirmed as asserting the probe as their subject, or filed. A decision, not a sweep.
• toBe('healthy') is not relaxed. If the repair requires tolerating a degraded base, that is a finding about the admission pin and belongs on #17049 instead.

Out of Scope

• Four-worker verification of this spec. #15861's AC-2 owns it — the repair is what this ticket delivers, the receipt is what that probe collects, and no PR against single-worker dev can produce one.
• The workers: 4 flip — #15861 owns it; this leaf is what its AC-5 prescribes.
• #17049's production behaviour. The starvation fold is not implicated; its spec's scaffolding is.
• #17186's turn-budget defect — different mechanism, already fixed in PR #17189.
• The other two healthcheck callers, beyond dispositioning them.

Avoided Traps

• Reading the green verdict as evidence. Both samples reported success. Only the flaky count separated a clean run from this one.
• Concluding from one sample. Sample 1 was genuinely clean at the same head with the same config. Had AC-2 asked for one green sample, this defect would have shipped inside a declared victory — which is the strongest available argument for the two-sample rule.
• Relaxing the gate. The cheapest repair, and it silently retires the assertion the test exists to make.
• Sweeping the other healthcheck callers. Asserting a probe as your subject is legitimate; asserting it as a precondition you do not control is not. Only reading them tells you which, and the distinction is invisible at the call site.

Evidence class

L4 — reproduced by CI at --workers=4 on PR #17183, run 31894997372 attempt 2, unit job 95037666010, with the failing assertion and the 1 flaky marker in the log. Attempt 1 of the same run at the same head was clean, which is itself part of the evidence.

Related

#15861 (the probe whose AC-5 prescribes this leaf) · PR #17183 · #17049 (the ticket the failing test was written for) · #17186 / PR #17189 (the fourth defect — different mechanism) · #15789 / #15790 / #15847 (the first three)

Live latest-open sweep at 2026-08-15T16:31Z plus a targeted search for HealthService / starvationFold / environment gate: no duplicate. #17049 is the spec's own ticket and is about production behaviour, not this scaffolding. No competing A2A [lane-claim].

Origin Session ID: 5cd926fa-77e1-4309-8bbf-ca563ab07403

Retrieval Hint: query_raw_memories("HealthService environment gate live plane probe precondition workers:4 flaky") · falsification anchor: expect(base.status).toBe('healthy') at HealthService.starvationFold.spec.mjs:265, preceded by a live HealthService.healthcheck().