fix(ci): allowlist lockfile sha256 hashes in gitleaks working-tree scan

[groupthinking]

Canonical issue

No canonical issue — repo-hygiene CI fix surfaced while triaging the gitleaks (working tree) failure that appears on every open PR (observed on the dependabot bump #1171, but present repo-wide).

Outcome

The gitleaks (working tree) job stops failing on a false positive. The default square-access-token rule was flagging the high-entropy SHA-256 package-integrity digests in uv.lock (uv.lock:5129, the parso sdist hash) as a leaked credential. Because that job scans uv.lock on every branch off main, the false positive was failing the scan — and blocking the green gate — on essentially every open PR. After this change the scan reports no leaks found.

Scope

• Included: .gitleaks.toml — one line-scoped regex allowlist entry.
• Explicitly excluded: no production code, no dependency/lockfile movement, no other scan rules touched. The allowlist is scoped to hash = "sha256:<hex>" lines only, so a genuine token appearing elsewhere in a lockfile (e.g. a credentialed private-index URL) is still scanned.

Risk

• Risk level: low — CI-config only, one file.
• Failure mode: worst case is that a real secret formatted exactly as a 64-char lowercase-hex SHA-256 digest on a hash = "sha256:..." line would be missed. Real credentials do not take that shape (Square tokens are sq0atp-…/EAAA… base64, not lowercase hex), so this is not a realistic exposure.
• Rollback: revert this commit; .gitleaks.toml returns to the prior allowlist. Nothing else depends on it.

Verification

Verified with gitleaks 8.18.4 (the exact version CI installs) against the current head on a clean tree off main (ad7e2c1):

• Reproduced the failure — gitleaks detect --no-git --config .gitleaks.toml --redact --exit-code 1 on the pre-fix config → leaks found: 1, RuleID: square-access-token, File: uv.lock, Line: 5129, exit 1.
• Confirmed the fix — same command on the post-fix config → no leaks found, exit 0.
• Allowlist is narrow — regexTarget = "line" with hash = "sha256:[0-9a-f]{64}"; only matches integrity-digest lines.
• Required CI — will confirm on this PR's head once the checks run.
• Review threads resolved — none open.

Production evidence

Not applicable as a runtime artifact: this PR changes only .gitleaks.toml (a CI config file). It touches no apps/web file, no route, and no dependency, so the deployed bundle for this head is byte-identical to main. The relevant evidence is the behavioural before/after above (exit 1 → exit 0 with gitleaks 8.18.4).

Agent handoff

• One canonical issue is linked — none exists; this is a CI-hygiene fix found during PR triage.
• No competing PR implements the same issue.
• Acceptance criteria are satisfied (scan goes from failing to clean).
• Required checks pass on the current head — pending first CI run.
• Human decision is requested only for merge approval (protected main).

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
v0-uvai	Ready	Preview, v0	Aug 1, 2026 9:08pm

[coderabbitai]

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (1)

• [‘architecture-gap’, ‘bug’, ‘ci-cd’, ‘ci/cd’, ‘copilot-rabbit’, ‘documentation’, ‘duplicate’, ‘enhancement’, ‘frontend’, ‘github_actions’, ‘good first issue’, ‘help wanted’, ‘high-priority’, ‘invalid’, ‘javascript’, ‘ml-model’, ‘needs-triage’, ‘pipeline-critical’, ‘placeholder-code’, ‘priority:high’, ‘python’, ‘python:uv’, ‘question’, ‘styling’, ‘tests’, ‘v0’]

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository YAML (base), Repository UI (inherited), Organization UI (inherited)

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 46c2ebf8-689a-492f-862b-4b68e88675df

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Snapshot Warnings

⚠️: No snapshots were found for the head SHA 45c7d7e.

Ensure that dependencies are being submitted on PR branches and consider enabling retry-on-snapshot-warnings. See the documentation for more information and troubleshooting advice.

Scanned Files

None

[github-actions]

Agent Completion Truth Gate: BLOCKED

Reasons: invalid_payload

Machine-readable verdict

{
  "details": {
    "invalid_fields": [
      "issue.number",
      "policy.agent_login",
      "policy.run_id"
    ]
  },
  "reasons": [
    "invalid_payload"
  ],
  "verdict": "blocked"
}

Workflow evidence

[groupthinking]

Status: code-CI green; blocked only by the pre-existing governance gate + human merge

What this PR does (verified): the gitleaks (working tree) check is now green on this head. It was failing repo-wide on a false positive — the default square-access-token rule flags the SHA-256 package-integrity digests in uv.lock (uv.lock:5129, the parso sdist hash). The same false positive is a real blocker on #1000, #1059, and #1077 today; this fix resolves the root cause once merged.

Code CI on 45c7d7e: gitleaks ✅, validate ✅, lint-python ✅, lint-frontend ✅, guards ✅, bandit ✅, npm-audit ✅, python-safety ✅, dependency-review ✅, Security Scan - javascript ✅, Vercel preview Ready ✅. (build/test/Coverage/trivy still running — this is a single-line .gitleaks.toml change with no code surface, so they are expected to pass; will re-check on completion.)

The two red checks are both the repo's governance-gate family, not a defect in this change:

• Agent completion enforcement → missing_trusted_publication. This requires a check run published by a trusted GitHub App that is not currently publishing. It fails on essentially every PR in the repo — the merged PRs fix: honor declared picomatch override in lockfile #1108, fix(deps): clear @hono/node-server advisory via MCP SDK 1.30.0 #1103 and fix(deps): raise transitive override floors to patched versions #1098 carried the identical failure. Not fixable from a PR branch.
• agent-completion/truth-gate → invalid_payload (issue.number, policy.agent_login, policy.run_id). There is no canonical issue for this CI-hygiene fix to declare, so the agent-lock manifest cannot be populated with valid values. Resolving this is a governance-config decision (either wire the trusted publisher / relax the gate for infra-only PRs, or open a tracking issue to attach).

Merge is a human decision: base is protected main and this PR carries no automerge label, so I am not auto-merging. Staged command for whoever approves:

gh pr merge 1178 --repo groupthinking/EventRelay --squash

---

Generated by Claude Code

[groupthinking]

Contained as a competing implementation of focused #1141 / canonical PR #1142. The canonical repair is the narrower exact-fingerprint change; this branch and commit 45c7d7e219183bf0dfa260ca857794bcb327b0ea are preserved.