Follow-up: kompile buildMaven cache ignored an artifact coordinate bump as well as dirty source.

Reported (UTC): 2026-07-13 13:37

What was being attempted: after https://github.com/CodexCoder21Organization/PlanRepository/blob/main/challenges/2026-07-13-1308-kompile-buildmaven-reused-a-stale-artifact-after-local.md, I changed build.kts from buildtest-embedded:0.0.273 to 0.0.274 and reran the required rebase plus scripts/test.bash invocation.

What went wrong: buildMaven still reported success in 3ms and the test compiler still emitted the exact stale-API errors "cannot find a parameter with this name: clock" and "cannot find a parameter with this name: rpcCallTimeoutMs". Changing the output Maven coordinate did not invalidate buildRuleResultIndex.

Impact: the originally documented version-bump workaround was ineffective; tests continued compiling against obsolete code and could not validate the production fix.

Workaround used: delete only /home/leslie/.aibuildcaches/_code_BuildTestEmbedded-task19/buildRuleResultIndex and persistent-scratchspace, then rebuild. The next build compiled source in about 34 seconds and the test passed.

Suggested durable fix: make the build-rule result key depend on dirty source contents and effective output coordinates, and have cached result validation reject artifacts whose coordinate or source fingerprint differs from the current build rule inputs.

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.