Fix .gitleaks.toml regex quoting

[Chris-Wolfgang]

Summary

• Changed single-quoted regex paths in .gitleaks.toml allowlist to triple-quoted strings, which is the correct TOML syntax for literal strings containing special characters.

Test plan

• Verify gitleaks runs without TOML parse errors on the updated config

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the repository’s gitleaks configuration to adjust how regex path allowlist entries are quoted in TOML.

Changes:

• Switched allowlist paths entries from single-quoted strings to triple-single-quoted (multiline literal) strings in .gitleaks.toml.

[bri-tong]

Code Review — PR #123: Fix .gitleaks.toml regex quoting

Summary

This is a minimal, low-risk change that converts two single-quoted TOML literal strings to triple-quoted TOML literal strings in .gitleaks.toml. The change produces identical parsed values — both '...' and '''...''' are literal (no-escape) string types in the TOML spec, and the regex patterns contain no single quotes or newlines that would require the triple-quoted form. The change aligns with the idiomatic convention used in gitleaks documentation and examples, which consistently use triple-quoted strings for regex patterns.

Blocking Issues

None. The change is correct and safe.

Non-blocking Suggestions

1. PR description accuracy: The description states triple-quoted strings are "the correct TOML syntax for literal strings containing special characters." This is slightly misleading — single-quoted strings ('...') in TOML are also literal strings that handle special characters identically. The real benefit here is convention alignment with gitleaks examples, not correctness. For future PRs, a more precise framing would be: "Switched to triple-quoted literal strings to match gitleaks' idiomatic config style."

2. Test plan gap: The test plan checkbox ("Verify gitleaks runs without TOML parse errors") is appropriate but was left unchecked before merge. Since the CI workflow in pr.yaml already runs gitleaks detect against the PR, the CI pass on this PR effectively validates the config. Worth noting that in the commit history for reference.

Questions / Clarifications

None — the intent and effect are clear.

---

Automated review by Pi