fix: keep the rules checkout out of zizmor's scan scope

[arootroatch]

Follow-up to #10, fixing a defect that change introduced.

The problem

#10 delivers bin/run-zizmor.sh by checking this repo out into .cc-security-rules inside the consumer's workspace, and zizmor is pointed at .. So this repo's own workflows become audit input for the consumer. The first cleancoders.com run after #10 shows it plainly:

completed ./.cc-security-rules/.github/workflows/security.yml
completed ./.cc-security-rules/.github/workflows/self-test.yml
completed ./.github/workflows/build.yml
...

It is harmless right now — those two workflows are clean, so the consumer's finding count was still 0 — and that is precisely why it would sit unnoticed. The moment a finding lands in one of them:

• every consumer reports it as its own finding, in a file that is not in its repo
• any consumer running zizmor-blocking: true fails its build on a file it cannot fix
• the fix would have to ship here, while the red X sits on their repo

That is a worse version of the silent-misattribution problem #10 set out to fix.

The fix

Stage the script into RUNNER_TEMP and delete the checkout before scanning:

cp .cc-security-rules/bin/run-zizmor.sh "$RUNNER_TEMP/"
rm -rf .cc-security-rules
bash "$RUNNER_TEMP/run-zizmor.sh" zizmor.sarif .

actions/checkout can only write inside the workspace, so staging out and deleting is the way to get the script without it being scan input. This restores the scan scope to exactly what it was before the script existed.

Verification

A clean-vs-clean comparison proves nothing here, since both repos' workflows currently pass. So I planted a workflow with no permissions: block inside a stand-in checkout:

	findings attributed to the consumer
before	3 — all in .cc-security-rules/.github/workflows/planted.yml
after	0

• 3 wiring assertions added to bin/test-run-zizmor.sh (18 total), pinning that the runner is invoked from RUNNER_TEMP, that the checkout is removed, and that it is not invoked from inside the checkout
• bin/test-detect.sh (17) and bin/test-report-sarif.sh (22) still pass
• actionlint and shellcheck clean

Note

The end-to-end behaviour from #10 is confirmed working in a real consumer run: the script is invoked, the first attempt aborts on the unreadable uses:, the ::warning:: fires, the retry completes all workflows, and the SARIF has 0 findings — a real 0, not the 0-byte unparseable file from before.

🤖 Generated with Claude Code