`zizmor` invoked on single file path, not repo root — may behave differently across target repos

[smartwatermelon]

Non-Blocking Review Concern: zizmor invoked on single file path, not repo root — may behave differently across target repos

Source: pre-push whole-codebase review
Location: scripts/retry-noop-approve-zizmor-fixes.sh:189
Date: 2026-08-03

What was flagged

zizmor "${workflow_path}" passes a single file path rather than the repository root. For the three findings being validated (unpinned-uses, bot-conditions, dangerous-triggers), single-file invocation is sufficient and will likely work correctly. However, some zizmor audits rely on cross-file context (e.g., use-trusted-publishing or excessive-permissions may read the whole repo). If zizmor exits 0 on a single file but would exit 1 on the full repo, the gate here passes a repo it shouldn't. The risk is bounded: this script is fixing pre-existing findings, not gating a production security boundary. But if a target repo has additional zizmor findings in other workflow files, this check won't catch them — those repos will get a clean commit from this script while still having unresolved findings. Consider using zizmor "${clone_dir}" instead of zizmor "${workflow_path}" to gate on the full repo state.

Context

This issue was automatically created from a non-blocking concern identified
during pre-push whole-codebase review. It was flagged for tracking.

---

Created by lib-review-issues.sh

[smartwatermelon]

Fleet-wide issue triage cleanup (2026-08-07). Non-blocking tech-debt observation about a one-off remediation script (scripts/drop-noop-approve-step.sh / retry-noop-approve-zizmor-fixes.sh) from a completed fleet remediation pass. The scripts already documented the idempotent/safe behavior; low-value to keep tracking separately. Closing as stale. No code changes made as part of this triage.