RE-VERIFY (2026-10-01 ~01:40Z, lane K58 verify-and-disposition pass): Everything in the table below was checked firsthand at that time against GitHub (GraphQL), a fresh clone of BuildTestEmbedded main dd7b4641a7a9b6a336b03546efbaee0826f38d53 (2026-10-01 00:31Z, PR 1179), https://buildtest.kotlin.build/api/runs?limit=500, and raw run logs. Older sections further down are history only. Re-check grep -n "shardCount > 1 && cacheBuildRules.isNotEmpty()" src/buildtest/embedded/BuildTestEmbeddedService.kt and DEFAULT_IMAGE in src/buildtest/embedded/DropletManager.kt before acting.

Remaining work

1. Decision (owner of BuildTestEmbedded shared preparation): does one-shard cross-run workspace cache reuse still pay for itself after the PR 1082 / PR 1168 redesign? Precondition is met (PR 1082 merged). Evidence below leans toward won't-do; if the owner decides to do it, it is a port onto current main, not a rebase of the old branch.
2. Image rebake (production action, needs operator authorization; owned by the BuildTestEmbedded / droplet-image owner): the fleet image 245388985 was baked with buildtest-runner 0.0.104 warm, but production now runs runner 0.0.119, so every run's shard 0 downloads the runner closure cold during workspace preparation. This is a NEW reason to rebake; the rebake this handoff originally named (runner 0.0.96, image 242809349) is long superseded.

Verified state table

Value evidence for the item-1 decision

• Frequency: 31 of the last 500 runs (~12 h window, 9021 total) had fewer than 50 tests (single-shard territory at minTestsPerShard=25); most were one ScreenshotTestServerService commit rerun repeatedly.
• Cost of a one-shard cold build is small (about 2.5 min of droplet time in run 3af77e00) and overlaps test dispatch in the work-queue runner; a restore would add an artifact transfer of hundreds of MB (multi-shard artifacts were 371 MB - 1.17 GB) and only hits on byte-identical archives.
• Recommendation for the owner: complete this handoff as won't-do unless measurements show repeated identical one-shard reruns are a material share of fleet time. If doing it: rescue 9edb6fcb, port onto current main (drop the shardCount > 1 term, pass the cache into the inline one-shard pipeline, keep e2eSingleShardBuildDoesNotStartSharedCacheServer green by restoring from the store without a cache server), fail-first test first.

Next steps

1. Owner of BuildTestEmbedded shared preparation: make the item-1 decision; complete as won't-do or port as above.
2. Operator: authorize (or decline) a rebake to warm runner 0.0.119; coordinate with hf-2026-09-30-buildtest-restart-recovery-... since preparation time is the live problem there.
3. Once both are dispositioned this handoff can be completed.

History (pre-2026-10-01 sections, stale)

RE-VERIFY (2026-09-24, sweep3 re-verification): The body below the 2026-09-24 section was written 2026-08-28 and is STALE: PR 747 no longer carries the single-shard change (it merged test-only), and the branch/SHA/image references describe state that no longer exists. Read "## 2026-09-24 re-verification and rescope" at the bottom first. Before acting, re-check gh pr view for https://github.com/CodexCoder21Organization/BuildTestEmbedded/pull/1082 and grep current BuildTestEmbedded main for shardCount > 1 && cacheBuildRules.isNotEmpty().

Handoff: Review single-shard workspace cache reuse PR

Written 2026-08-28 05:43 UTC.

RE-VERIFY: This is a write-time snapshot. The authoritative checks at write time were git ls-remote origin refs/heads/feat/single-shard-workspace-cache-reuse, gh pr view for pull requests 714, 741, 747, and 722, and the locked local targeted test commands below. Re-run those commands before taking further action; current GitHub state and fresh test output take precedence.

Mission summary

Review and land the single-shard workspace cache reuse change in https://github.com/CodexCoder21Organization/BuildTestEmbedded/pull/747 once its required checks and review are handled. The source change is complete and pushed at 9edb6fcba717d08eb5fec607f79564a33dbd43eb; no merge, queue action, deployment, image change, or rebake was performed.

What was found and done

1. The former gate constructed SharedShardBuildCache only when shardCount > 1. The inline one-shard call to runShardPipeline also omitted the already-created cache object, so one-shard runs skipped restore, preparation, publication, and reuse.

2. The cache gate is now based only on whether the normalized build-rule set is non-empty. The single-shard pipeline receives the cache object, enters the existing shard-zero restore-or-prepare path, and publishes the same cache artifact. Single-shard log wording says for this shard; existing multi-shard wording is preserved.

3. Cache identity and validation were not changed. The existing fingerprint still covers the complete submitted archive, normalized build-rule key, runner version, kompile-manager version, and droplet image. Restore still checks the manifest, artifact size/hash, and valid .buildcache tar structure. Publication remains atomic and bounded by entry and byte limits.

4. No evidence showed that the old gate provided shard isolation or prevented cache poisoning. The single-shard test runs two separate service generations against fresh fake droplets and checks public logs, module-build count at the fake service boundary, and the persisted cache-entry directory.

5. The fail-first test was run on current main before the change with:

   flock /tmp/buildtest-remote.lock scripts/test.bash --local --test crossRunModuleBuildCacheReusesSingleShard

   Both builds completed with 2 passed, 0 failed, 2 total, but the assertion observed moduleBuilds=2, persisted entries [], and no public preparation or restore messages. This is the valid baseline; earlier empty-XML fixture failures and a same-coordinate stale artifact were corrected before recording this result.

6. After the fix, the focused test completed ALL TESTS PASSED (1/1 tests completed successfully). The existing multi-shard reuse, source-change invalidation, corrupt-artifact fallback, and toolchain-skew invalidation tests also completed successfully, each under the shared lock:

   • crossRunModuleBuildCacheReusesIdenticalInputs
   • crossRunModuleBuildCacheMissesWhenSourceChanges
   • crossRunModuleBuildCacheFallsBackFromCorruptArtifact
   • crossRunModuleBuildCacheMissesOnToolchainVersionSkew

7. The branch was fetched and rebased onto origin/main immediately before the final focused run and PR creation. It is clean, has no stash or local-only commit, and its remote head matches the local head.

Relevant PRs / refs

Related pull requests, all write-time verified:

• BuildTestEmbedded PR 714 is MERGED; the ownership blocker is gone.
• BuildTestEmbedded PR 741 is MERGED; the runner pin is 0.0.96.
• BuildTestEmbedded PR 722 is CLOSED as superseded by PR 747. Its stale image-only branch was not merged unchanged.
• The cache gate's fan-out origin is BuildTestEmbedded PR 334.

Deployed or published but not merged

This lane deployed nothing, published no production artifact, changed no production route, and rebaked no image. Image 242809349 already exists in sfo3 and nyc3, as recorded in PR 722; no action was taken on the image. The 0.0.68271805 coordinate is the source build coordinate used by the test harness, not a production deployment.

Next steps

1. Re-check PR 747 before any branch update. The user explicitly prohibited CI watching in this lane; the write-time check snapshot is recorded above and must not be represented as green.
2. Obtain the user's review/merge decision. Do not merge or enqueue automatically.
3. If source changes are requested, check the PR is still OPEN, rebase on current origin/main immediately before any new build/test, rerun the targeted cache tests under flock /tmp/buildtest-remote.lock, and update this handoff with the new remote SHA.

Reusable operational knowledge

• rg is unavailable in this checkout; grep was used for repository searches.
• The shared test lock is /tmp/buildtest-remote.lock; never bypass it. Remote execution initially hit a 30-second getBuildRun RPC timeout, so the fail-first and final verification used the locked local harness. This was infrastructure/harness behavior, not the cache verdict.
• The test's @Timeout(120) is the same budget used by neighboring multi-node cache tests and was not changed during the fix. No test iteration budget was reduced.
• The test fixture uses an OS-assigned SSH port and cleans the service, fake droplet, temporary data directory, and generated key material in finally blocks. It uses a fake implementation only at the infeasible external droplet boundary and executes real tar archive commands.
• The final source commits, in order, are b3f113d0 (fail-first test), ef793794 (gate/log change), ee94d8e5 (artifact coordinate), and 9edb6fcb (single-shard cache wiring).

2026-09-24 re-verification and rescope

Remaining work (new mission): After https://github.com/CodexCoder21Organization/BuildTestEmbedded/pull/1082 lands, decide whether single-shard runs still need cross-run workspace cache reuse under the new SharedShardBuildCache design. If so, port it onto then-current main: drop the shardCount > 1 condition on the cache gate, pass the cache object into the inline one-shard pipeline, and add a fail-first one-shard reuse test (the old crossRunModuleBuildCacheReusesSingleShard from branch feat/single-shard-workspace-cache-reuse at 9edb6fcb is a starting point). If the new design makes it moot, complete this handoff as won't-do with that reasoning.

Findings (verified 2026-09-24 ~02:25 UTC):

• https://github.com/CodexCoder21Organization/BuildTestEmbedded/pull/747 is MERGED (2026-09-23 18:54Z, merge commit 9d4f771f) but was repurposed during the 2026-09-23 old-PR cleanup: it is now titled "Cover quoted runner cache paths" and merged ONLY tests/buildRunnerCommandExecutesSpecialCharacterCachePath.kts (+87). Its body says the one-shard production change was dropped because main had substantially changed that pipeline, and lists the port as remaining work.
• BuildTestEmbedded main 073b3523 still has the old gate at src/buildtest/embedded/BuildTestEmbeddedService.kt:17511: if (shardCount > 1 && cacheBuildRules.isNotEmpty()). There is no crossRunModuleBuildCacheReusesSingleShard test on main. One-shard runs still skip the cross-run workspace cache; the original mission did NOT land.
• The same code is being rewritten right now: https://github.com/CodexCoder21Organization/BuildTestEmbedded/pull/1082 (branch fix/r218-shared-preparation-coordination, SharedShardBuildCache + shared preparation: followers await shard 0, single common compile; last push 2026-09-24 01:46Z by another live agent; checks red at the time) and https://github.com/CodexCoder21Organization/BuildTestEmbedded/pull/1084 (touches the shared-cache merge; last push 01:19Z). Porting now would collide with a moving target.
• Rebaking the buildtest droplet image is a production action and requires explicit operator authorization; it is NOT part of this handoff's automated scope.

Supervisor ruling (2026-09-24 ~02:35 UTC): rescope in place (no duplicate handoff) rather than complete-as-superseded or drop. Whether single-shard cross-run reuse is still the right design can only be judged against the PR 1082 rewrite, so this handoff now depends on url://handoff/handoffs/hf-2026-09-23-fix-coordinator-shared-preparation-and-follower-waiting (the open handoff that owns branch fix/r218-shared-preparation-coordination / PR 1082) and stays BLOCKED until that lands.