[zili-amd]

Summary

Provision the Forge engine in Docker and reject added runtime patching or library delegation before candidate scoring. Concurrent Forge campaigns keep their own engine installation, and custom C++ methods remain usable.

• Resolve the committed engine revision before preflight and worker startup. Install its exported source into a staging directory, lock setup for that revision, and publish atomically. Python cache tag, container image identity and engine revision select separate cache directories; setup never removes an active campaign's installation.
• Support both the keyword implementer API and the grouped ImplementerSetup API. Preserve task instructions, protected paths, correctness-only gates, usage and time limits. After initialization, refresh the loop's remaining budget and forward the same absolute deadline when supported.
• Normalize bare, qualified and imported-alias reflective builtins. Mask C++ comments and literals correctly, including URL strings, raw strings and line continuations. Identify Tensor member operators without rejecting same-named methods on custom types.
• Record the effective source policy in workspace context. Old snapshots without initial site counts explicitly report this policy as disabled.

The shared guard applies to every agent's evaluation. Non-Forge runs receive no new engine mount or engine environment. The runner also forwards ANTHROPIC_CUSTOM_HEADERS for GEAK/Forge and provides a noninteractive Docker exec command. No task packages, numerical tolerances, workloads or scoring/timing helpers are changed.

Validation

• Linux focused guard, lifecycle, GEAK and Forge regression suites: 935 passed, 32 skipped. The skips cover optional installed-engine checks and existing gated GEAK cases.
• Real installed engine bb2da63332dcbc46bdf10702c516ef43eb80a016 (1.1.4), Linux amd64 / Python 3.12: 109 passed in the Forge integration suites, including initialization retries, harness tampering, timeout, complete candidate delivery and loop handoff. Provider responses are scripted CPU fixtures; these are not model-driven GPU optimization results. The new API/budget mapping cases also passed separately.
• Docker runner mock suite: passed. Python compilation and git diff --check: passed.
• Fresh Fleet GPU tests on MI350X, gfx950, in the pinned ROCm development image: native HIP GELU and the shared TaskSession baseline/candidate compile, correctness and performance actions passed. The custom Accumulator::sum implementation remained allowed and numerically correct. An added ATen call after a URL string was rejected, and a zero-output GPU mutant failed correctness. Jobs job-48b54231 and job-5d97db84 exited 0; task-owned resources are released.
• GPU replay checks used a 1 GiB read-only eviction sweep before each complete graph replay, with replay outputs checked outside timing. Raw samples and source/runtime receipts are retained. This is a small integration fixture, not a speedup claim or retained-task qualification.

Limits

The source check is structural, not a C++ type checker or security sandbox. Initial per-file site counts remain the comparison boundary; semantic task review and numerical checks are still required. The grouped engine's new-file allowlist supports helpers in existing directories of declared editable trees; helpers in newly created directories are rejected by that engine.

A fresh model-driven Forge optimization campaign and other agents' GPU score comparisons were not rerun. The earlier author's MI300X campaign evidence applies to 11cc060d; it is separate from the fresh tests above. Full repository CI must finish on the current head before merging.

[zili-amd]

@irvineoy This is ready for review. Since opening it I ran a smoke on this exact commit on MI300X: make docker-setup-forge, docker_benchmark.sh exec, and a 45-minute Forge run end to end. The results are under Validation.