ci(fuzz): root .dockerignore from #72 blanks ClusterFuzzLite's build context — scope it to the MCP image

[askalf]

The root .dockerignore added in #72 (* + !docker/pin-everything.mjs) applies to EVERY build that uses the repo root as context — including ClusterFuzzLite, whose .clusterfuzzlite/Dockerfile does COPY . $SRC/truecopy and COPY .clusterfuzzlite/build.sh. Since #72 merged (7/20 02:15Z), every cflite build fails with "/.clusterfuzzlite/build.sh": not found — first the 06:26Z weekly, then a re-dispatch reproduced it (runs 29714073815-ish and 29778246717). Last green was 7/13, before the ignore existed.

Fix: move the rules to Dockerfile.dockerignore — BuildKit's per-Dockerfile ignore, scoped to the root Dockerfile (the truecopy-mcp image) only. That image copies nothing but docker/pin-everything.mjs, so it keeps its tiny context; cflite gets the full tree back. On any builder without per-Dockerfile-ignore support the only cost is a larger MCP build context — both builds stay correct.

Verify after merge: dispatch cflite.yml on master.

[sprayberry-reviewer]

Automated review from the Sprayberry Labs fleet code reviewer.

Verdict: No blocking issues — the fix correctly scopes the ignore rule to the intended image; approving.

What I checked

• gh pr diff 76 (2 files changed: .dockerignore deleted, Dockerfile.dockerignore added, +7/-4).
• Root Dockerfile (truecopy-mcp image) — confirmed it only needs docker/pin-everything.mjs from the build context, matching the ignore rules kept in the new file.
• .clusterfuzzlite/Dockerfile — confirmed it does COPY . $SRC/truecopy and COPY .clusterfuzzlite/build.sh $SRC/build.sh from the same repo-root context, which is exactly what the PR body says the old root .dockerignore (* + !docker/pin-everything.mjs) was blanking out.
• CI rollup: all green (CI ubuntu/windows/macos × node 20/22, CodeQL, "verify pinned skills"). None of these actually build via .clusterfuzzlite/Dockerfile, so they don't directly validate the fix — the PR body already flags this and asks for a manual cflite.yml dispatch after merge, which is the right call given ClusterFuzzLite only runs on a weekly cron / manual dispatch.

Analysis

Moving the ignore rules from a root .dockerignore to Dockerfile.dockerignore (BuildKit's per-Dockerfile-ignore convention) scopes them to builds that pass -f Dockerfile explicitly, which is how the truecopy-mcp image is built, while leaving the ClusterFuzzLite build (which uses -f .clusterfuzzlite/Dockerfile against the same root context) unaffected. This is the correct mechanism for the stated problem — a root .dockerignore applies unconditionally to every build using that context regardless of which Dockerfile is targeted; the per-Dockerfile variant does not. The new file's content is otherwise identical to the deleted one (same * + !docker/pin-everything.mjs rules), and the added comments correctly document the scoping rationale and cross-reference this PR.

No correctness issues, no reuse/simplification opportunities, and no efficiency concerns in a 2-file, 11-line ignore-rule change. No new runtime code was added, so there's nothing here that needs a unit test — the real verification is the operational one already called out in the PR body (dispatch cflite.yml post-merge).

What's good

• Diff is minimal and exactly targeted at the root cause.
• The new file's comments clearly explain why this isn't a root .dockerignore and point at the two Dockerfiles/builds involved, which will save the next reader from re-deriving this.