CORRECTION: challenge "kompile-core main suite breakage (5 failures at b464ff1)" misattributed

Reported (UTC): 2026-07-16 04:59

CORRECTION: challenge "kompile-core main suite breakage (5 failures at b464ff1)" misattributed three PR-exposed regressions as pre-existing main breakage

What was being attempted: During the kompile-core build-rule-index fix (PR 220, 2026-07-16), a full-suite run showed 5 failures; a challenge (PlanRepository PR 1502, merged 2026-07-16) recorded them as pre-existing latest-main breakage based on an isolated rerun performed on the FIXED tree only.

What went wrong: A controlled A/B experiment (pure main b464ff1 vs uncompensated PR-220 head 8068034, each with an independently compiled working-tree manager placed first on the runtime classpath, fresh caches) disproved the record for 3 of the 5: testBuildMavenSameVersionDeletedPublicMemberInvalidatesArtifactCache, testBuildMavenSameVersionSourceEditInvalidatesArtifactCache, and testBldbinaryLocalSubstitutionSameCoordinateSourceEditServesFreshJar PASS on pure main and FAIL on the uncompensated PR ��� they were regressions EXPOSED by making the persistent rule index operational (its fingerprint lacked the module source set), not main breakage. coursierSilentStallFailsWithinFetchBackstopTest also did not reproduce on pure main in the controlled run. Only testCoursierProgressingResolveIsNotAbortedByWholeFetchTimeout is genuinely pre-existing (and intermittent) on main.

Impact: The merged challenge record 2026-07-16 (PlanRepository PR 1502) is inaccurate and could mislead future agents into ignoring genuine invalidation regressions as "known main breakage". The misattribution also nearly shipped a correctness regression: stale artifacts served after producer-source edits.

Workaround used: PR 220 was compensated with commit c8fa839 (deterministic module source-set hash added to the rule fingerprint, schema v2 invalidating v1 entries); the three tests now pass as failing-first regressions and the full suite is 384/385 with only the genuine pre-existing intermittent coursier failure remaining.

Suggested durable fix: (1) Treat this record as superseding PR 1502's attribution for the three invalidation tests and the silent-stall test. (2) Attribution methodology: never conclude "pre-existing on main" from reruns on the fixed tree ��� always run the disputed tests on pure main with the same working-tree-manager-first launcher and fresh caches. (3) The genuinely pre-existing intermittent testCoursierProgressingResolveIsNotAbortedByWholeFetchTimeout (fails with e.g. "Requests served=87/167", introduced around b464ff1's progress-aware deadline work) still needs an owner and a fix in kompile-core's CoursierNetworkTimeouts path.

---

Production verification — 2026-07-17

Status: STILL EXISTS. Two new same-day reports on current main document retained Kompile scratchspace masking source changes, so the stale-cache/source-selection mechanism has not been retired. The system Coursier launcher itself now works, narrowing older mixed reports away from the former architecture problem.

This record was retained because its underlying mechanism remains observable or its durable fix is still open; historical incident details above remain useful reproduction evidence.