Kompile build-rule cache returned an obsolete local artifact after a coordinate bump.

Reported (UTC): 2026-07-15 16:28

What was being attempted: Rebase BuildTestEmbedded's per-droplet phase-timestamp branch, whose build.kts coordinate changed from buildtest-embedded 0.0.299 to 0.0.300 after 0.0.299 was found already published from pre-rebase source, then run a selected local test through scripts/test.bash.

What went wrong: kompile reported BuildRuleExecutedEffect: buildtest.embedded.buildMaven() succeeded in 1ms, but no 0.0.300 artifact existed anywhere under the checkout-scoped cache. Test compilation instead used the earlier cached 0.0.299 JAR from /home/helena/.aibuildcaches/_code_workspace_BuildTestEmbedded-325/.../0.0.299/buildtest-embedded-0.0.299.jar. The resulting errors included cannot find a parameter with this name: phaseTimestamps and unresolved reference: phaseTimestamps across all six new tests. javap proved the cached 0.0.299 JAR itself had the new source field, but the selected test compiler was resolving another obsolete artifact shape; in either case buildMaven never materialized the declared 0.0.300 coordinate despite claiming success.

Impact: Selected and full test runs spend roughly six minutes scanning/compiling the workspace, then emit dozens of misleading source errors from an artifact that does not correspond to the current build.kts. This can make a correct rebase look source-incompatible and wastes every retry.

Workaround used: Delete only /home/helena/.aibuildcaches/_code_workspace_BuildTestEmbedded-325 and rerun after rebasing, forcing buildMaven and test dependency substitution to materialize the current 0.0.300 artifact.

Suggested durable fix: Include the effective build.kts source/coordinate and checked-out source hash in build-rule and workspace-substitution cache keys, verify a cached buildMaven result actually contains the coordinate declared by the current script before returning success, and print the concrete substituted artifact path/coordinate in BuildRuleExecutedEffect diagnostics.

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.