Authorized by the administrator's explicit approval of package-read access for the test-only autocoder-test-reader account. Created AutoCoder organization team TestPackageReaders (Gitea team ID 17) and added only autocoder-test-reader (user ID 18). Team authorization is none; the sole unit is repo.packages: read; it does not include all repositories and cannot create organization repositories. No repository or issue write permission was granted.
Verification: with the existing autocoder-test-registry-cred identity from namespace autocoder-test, registry HEAD returned HTTP 200 and matching Docker-Content-Digest for backend sha256:094fc1a8dc93cce9d4fa22151e07df79eefe4375d1e2fa44736bd298b7d5de33 and frontend sha256:1dfcd9f6a7fdbb16c066e8f8e2a1de87f32b87db870872ff000a784d6bd6eef4. Gitea repository API reports push=false, admin=false for the reader. No credential values recorded.
The frontend subsequently pulled its exact digest and reached 1/1 Ready. The engine's live canonical-instructions init container was missing quota-required CPU/memory requests and limits. Applied only those fields (25m/64Mi requests, 100m/128Mi limits), matching the committed test overlay. This allowed pod creation and backend image pull, but the image cannot start: its native binary requires GLIBC_2.38 and GLIBC_2.39, while the mcr.microsoft.com/dotnet/sdk:8.0.424-bookworm-slim runtime base provides older glibc. The failed pod preserves the exact candidate digest; no image was replaced or rebuilt. Engine/test health remains failed; normal candidate admission remains disabled. A compatible build/runtime ABI and rebuilt validated candidate are required before deployment acceptance.
PR #6678 was reviewed and merged into dev at 20b1429ab63141792a8652f8b3f2de79b80736b1 after exact-head branch, native-release, and WASM-release checks passed on 409487cb246f8579cf359161d0124411a85f46fe. Candidate image assembly now pins the Ubuntu Noble .NET SDK digest and checks the assembled native binaries with ldd -r before registry push. This is source integration, not a test deployment or runtime-verification result.
Gitea shadow candidate run 3677 (internal run 8758) was dispatched on exact dev head 20b1429a. Its candidate job was admitted on dedicated runner ID 25; the deployment job was skipped. The repository variable AUTOCODER_CANDIDATE_SHADOW_ENABLED was temporarily set true for dispatch and verified false immediately after admission. AUTOCODER_TEST_CANDIDATES_ENABLED remained false throughout. Shadow run outcome and image ABI result are pending; test backend remains unhealthy until a new validated digest deploys.
Shadow run 3677 (internal 8758) ended failed during image assembly. Its exact revision 20b1429a passed unit/database validation and compiled native and WASM artifacts, but the pinned Ubuntu Noble runtime could not install azure-cli because the base image lacked Microsoft's Azure CLI apt source (E: Unable to locate package azure-cli). The runtime ABI check did not execute, no candidate receipt or test deployment occurred, and both admission variables remained false. PR #6679 adds Microsoft's signed Noble Azure CLI package source only for candidate image assembly; its exact-head CI and a new shadow build are required before test rollout. The earlier shadow run 3671 took 22m50s from Gitea run creation to finish, without test deployment; it is not counted as a healthy-test SLA run.
PR #6679 passed exact-head branch/native/WASM checks and merged into dev at c3f9a5c31d4a5ef06aad73dc4b5c5594d9b3aa9d. Shadow run 3681 (internal 8762) admitted that exact revision while normal and shadow admission variables were returned to false. It passed candidate validation and reached image assembly, but its BuildKit step stalled downloading Microsoft's signing key. The worker host and DinD pod reached https://packages.microsoft.com/keys/microsoft.asc with HTTP 200; the nested Docker bridge timed out during TLS handshake. All three Rust runner pods have 1480-byte overlay interfaces while their DinD bridges defaulted to 1500. A disposable Docker network configured at 1480 returned HTTP 200 for the same URL in 0.05 seconds; that network was removed after the probe. The exact stuck curl PID in shadow run 3681 was terminated after confirming its command and run identity; the shadow run ended failed. It did not register or deploy a candidate. Test backend remains 0/1 on the old digest; no release acceptance or promotion occurred.
PR #6680 changed the repository-managed Rust runner manifests to dockerd --mtu=1480 for all three pods and reconciled their cache-epoch annotation to the live value 2960; its applicable checks passed and it merged to dev at 7a1de84cd91079baed910c17bff04c56fe6155bb. Before rollout, Gitea showed no active tasks on current Rust runner IDs 23, 24 or 25. The reviewed manifest was applied only to candidate runner gitea-act-runner-rust-3 first. Its Recreate rollout is in progress; the old pod has a configured 20-minute graceful shutdown and no force deletion was performed. Validation runners 1 and 2 remain on their prior spec pending candidate-lane verification. Both candidate admission variables remain false. Next: verify the new pod's Docker bridge MTU and TLS, then dispatch a new exact shadow run; roll validation runners only when idle and after verifying the candidate runner.
The Recreate rollout completed without force deletion. Replacement gitea-act-runner-rust-3-8f47f58c-xfp2d was Ready on worker-01. Live pod eth0, DinD docker0, and the restored autocoder-candidate-builder-v1 BuildKit container eth0 each reported MTU 1480. A bounded HTTPS request from that BuildKit network to the formerly stalled Microsoft signing-key URL returned HTTP 200. Shadow run 3685 (internal 8766, candidate job 18503) was dispatched on exact dev head 7a1de84cd91079baed910c17bff04c56fe6155bb; its deployment job was skipped. The shadow dispatch variable was returned to false after job admission, and normal candidate admission remains false. Image assembly and ABI/push results remain pending.
After candidate runner verification, the same reviewed PR #6680 manifest was applied to idle Rust validation runners 1 and 2 sequentially, never taking both validation lanes down together. Both replacement pods became Running on worker-01, their DinD daemons reported Docker 27.5.1 with docker0 MTU 1480, and both runner processes re-registered with the existing rust-validation and rust-delivery labels. No active Gitea task was present on runner IDs 23 or 24 before their respective rollouts. Shadow run 3685 remains in validation on the candidate lane; normal candidate admission remains disabled.
Shadow run 3685 (internal run 8766, candidate job 18503) completed successfully against exact dev SHA 7a1de84cd91079baed910c17bff04c56fe6155bb. Its unit/database/native/WASM validation passed; assembled backend and frontend OCI digests were sha256:78189da787571e4d0a47b0950e99133497ea82091e4097d15f24fe2abad87b64 and sha256:1601af444ad140c56b5a85a6bb1a134528cae26d697ba05fa8d128d906312d74. The test-only package reader obtained registry HEAD HTTP 200 with matching Docker-Content-Digest for both. Runtime ldd -r verification passed. The candidate manifest was uploaded to Gitea Actions storage, but this was shadow mode: no candidate receipt, test deployment, release acceptance, or production promotion occurred. Normal candidate admission remains false.
Gitea 1.24 /actions/tasks reports the candidate job as successful and binds workflow candidate-test.yaml, event workflow_dispatch, exact SHA, and public run number 3685. A provenance defect remains: the current workflow had constructed a public URL from internal GITHUB_RUN_ID=8766 rather than public GITHUB_RUN_NUMBER=3685; its unsupported run-detail API query fell back to runner start, excluding queue time. A worktree change now uses the public run number and exact provider task timestamp, failing closed if no unique matching task exists. Static admission checks pass, but that source change is not merged or live. More importantly, the release-control receipt still does not corroborate workflow/task identity and successful required checks with Gitea before marking a candidate ready, so do not enable normal candidate admission or treat this shadow build as a deployable accepted candidate. The successful shadow elapsed about 21 minutes and is not a healthy test-deployment SLA sample.