Bundled low-priority items surfaced during review of PR #10. Each is a small standalone fix.
1. PR comment deduplication (gitleaks.yml L113)
The comment step calls `issues.createComment` with no idempotency check. On a PR with multiple pushes, the same finding generates one `@CivicTechWR/organizers` alert per push. Consider checking for an existing workflow comment and updating it instead of creating a new one.
2. Response guide missing CI re-run step (docs/gitleaks-response.md L20)
The old guide instructed responders to re-trigger the CI workflow after remediation to confirm cleanliness. The current guide only says to run `gitleaks detect --redact` locally. A local run uses local config and tooling — it does not validate that the pinned workflow version and org config also pass. Add a step: "Push the cleaned branch and confirm the gitleaks workflow passes in CI before merging."
3. README CODEOWNERS wording (README.md L20)
`CODEOWNERS` is listed under "Default files that appear in all CivicTechWR repositories (unless overridden)." GitHub does not propagate `CODEOWNERS` from the org `.github` repo — the governance doc correctly states this. The README heading is imprecise and could lead a maintainer to assume code-owner enforcement is already active on their repo without adding their own file.
4. No `--config` flag in workflow or guide (gitleaks.yml L29)
`gitleaks detect --source .` auto-discovers `.gitleaks.toml` from the source root, which works in CI. But `docs/gitleaks-response.md` tells maintainers to run `gitleaks detect --redact` locally to verify fixes. If run from a subdirectory, the config is silently skipped and allowlist entries don't apply. Adding `--config .gitleaks.toml` explicitly to both the workflow command and the guide's verification step would close this gap.
Bundled low-priority items surfaced during review of PR #10. Each is a small standalone fix.
1. PR comment deduplication (
gitleaks.ymlL113)The comment step calls `issues.createComment` with no idempotency check. On a PR with multiple pushes, the same finding generates one `@CivicTechWR/organizers` alert per push. Consider checking for an existing workflow comment and updating it instead of creating a new one.
2. Response guide missing CI re-run step (
docs/gitleaks-response.mdL20)The old guide instructed responders to re-trigger the CI workflow after remediation to confirm cleanliness. The current guide only says to run `gitleaks detect --redact` locally. A local run uses local config and tooling — it does not validate that the pinned workflow version and org config also pass. Add a step: "Push the cleaned branch and confirm the gitleaks workflow passes in CI before merging."
3. README CODEOWNERS wording (
README.mdL20)`CODEOWNERS` is listed under "Default files that appear in all CivicTechWR repositories (unless overridden)." GitHub does not propagate `CODEOWNERS` from the org `.github` repo — the governance doc correctly states this. The README heading is imprecise and could lead a maintainer to assume code-owner enforcement is already active on their repo without adding their own file.
4. No `--config` flag in workflow or guide (
gitleaks.ymlL29)`gitleaks detect --source .` auto-discovers `.gitleaks.toml` from the source root, which works in CI. But `docs/gitleaks-response.md` tells maintainers to run `gitleaks detect --redact` locally to verify fixes. If run from a subdirectory, the config is silently skipped and allowlist entries don't apply. Adding `--config .gitleaks.toml` explicitly to both the workflow command and the guide's verification step would close this gap.