Kompile local cache reused a stale Maven artifact after API source changes.

Reported (UTC): 2026-07-13 20:38

What was being attempted: I ran 'scripts/test.bash --test typedGitOperationsContractTest' in GithubProxyApi to perform the red/green TDD cycle for newly added Repository methods and DTOs.

What went wrong: The initial red run correctly reported unresolved symbols. After adding those exact symbols to src/githubproxy/api/GithubProxyApi.kt and bumping build.kts from 0.2.0 to 0.3.0, the second run still compiled the test against the pre-change artifact and repeated 'error: unresolved reference: createBranch', 'commitFiles', 'enqueue', 'FileChange', and 'CommitResult'. The build-rule event claimed 'githubproxy.api.buildMaven() (succeeded in 7ms)', indicating the old artifact was reused. The runner also printed repeated '[ERROR] Unhandled effect: kompile.executionenvironment.BuildScriptStderrEffect' and '[ERROR] Unhandled effect: kompile.BuildRuleExecutedEffect' stack traces for ordinary cache diagnostics, obscuring the actionable compiler failure.

Impact: Local TDD could not observe the implementation change and produced misleading failures, while several thousand lines of unhandled-effect output made diagnosis unnecessarily difficult.

Workaround used: invalidate only GithubProxyApi's repository-scoped cache at ~/.aibuildcaches/_code_workspace_GithubProxyApi before rerunning the test.

Suggested durable fix: kompile-cli/buildSimpleKotlinMavenArtifact should include source contents (and artifact coordinates) in its cache key and invalidate dependent @WithArtifact build-rule results when those sources change. BuildScriptStderrEffect and BuildRuleExecutedEffect should be handled as structured diagnostics instead of being surfaced as unhandled errors with stack traces.

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.