chore: ignore Python bytecode cache artifacts

[ggallen]

Summary

Adds a root .gitignore for __pycache__/ and *.pyc. gitlint's local pre-commit environment generates gitlint_rules/__pycache__/*.pyc, and with no repo-wide .gitignore entry it gets accidentally picked up by git add -A.

Split out from #469 per review feedback there that it was unrelated scope creep on that PR (it accidentally got staged and committed there twice while working on an unrelated fix).

[qodo-code-review]

PR Summary by Qodo

Ignore Python bytecode cache artifacts in repo .gitignore

⚙️ Configuration changes 🕐 Less than 5 minutes

AI Description

• Add repo-wide ignores for Python bytecode cache directories and files.
• Prevent accidental staging of __pycache__/*.pyc generated by local tooling.

High-Level Assessment

The following are alternative approaches to this PR:

1. Rely on developers' global gitignore

• ➕ No repo change required
• ➕ Keeps ignores personalized per developer environment
• ➖ Non-portable; contributors without the global rule will still accidentally stage artifacts
• ➖ Hard to enforce consistently in CI/review

2. Add a cleanup step to pre-commit/tooling

• ➕ Actively removes artifacts rather than just ignoring them
• ➕ Can address other generated files as well
• ➖ More moving parts and maintenance than a simple ignore
• ➖ Doesn't prevent local accidental staging unless cleanup runs before every add/commit

Recommendation: Keep the repo-wide .gitignore entries as implemented. It’s the simplest, most portable fix that prevents accidental staging across all contributors without adding tooling complexity.

Files changed (1) +2 / -0

Other (1) +2 / -0

.gitignoreIgnore '__pycache__/' directories and '*.pyc' files +2/-0

Ignore 'pycache/' directories and '*.pyc' files

• Adds a root '.gitignore' to exclude Python bytecode cache directories and compiled bytecode files from version control. This prevents artifacts produced by local tooling (e.g., pre-commit/gitlint) from being accidentally staged.

.gitignore

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 4:42 PM UTC · Completed 4:52 PM UTC
Commit: d3ba95a · View workflow run →

[fullsend-ai-review]

Review

Findings

Medium

• [missing-authorization] .gitignore — New repository-wide .gitignore file has no linked issue. The PR body provides clear context (split from fix(#5188): re-trigger review via label after fix-agent push #469 per review feedback flagging the .gitignore addition as unrelated scope-creep), and the patterns are standard Python bytecode exclusions. However, no formal issue documents the motivation for this change. Consider creating a brief issue for traceability, or linking to an existing infrastructure hygiene issue.

[waynesun09]

Approving — review squad found no blocking issues. Already has ralphbean's approval and passes all checks; adding a second sign-off.

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 8:39 PM UTC · Completed 8:48 PM UTC
Commit: d3ba95a · View workflow run →

[fullsend-ai-retro]

Retro: PR #473 — chore: ignore Python bytecode cache artifacts

A trivial 2-line .gitignore addition (__pycache__/ and *.pyc) authored by a human (ggallen), split from PR #469 per review feedback about unrelated scope creep. The review agent (run 30285776114) dispatched 3 sub-agents (correctness, style-conventions, intent-coherence) plus a challenger, spending ~$1.96 and 12 minutes.

Key observation: challenger was correct but overridden

The intent-coherence sub-agent produced two findings: (1) Medium missing-authorization — no linked issue, and (2) Low scope-traceability-discrepancy — PR claims split from #469 but #469 doesn't mention gitignore. The challenger sub-agent investigated and correctly removed both: finding 1 misinterprets AGENTS.md section 3 (which is about staying within issue scope, not requiring every PR to have an issue), and finding 2 was factually false (PR #469's review comments explicitly flagged gitignore as scope-creep). However, the orchestrator hit the empty-set fallback rule — when all challenger removals leave adjudicated_findings empty, it reverts to pre-challenger findings as a parsing-error guard. The orchestrator exercised partial judgment (removed finding 2 as provably false) but kept finding 1, resulting in a Medium finding and requires-manual-review label on a 2-line config change. Both human reviewers (ralphbean, waynesun09) approved without substantive issues.

No new proposals — all findings map to existing open issues

• Review orchestrator should accept challenger findings when backed by verifiable config evidence fullsend#2485 (challenger override): This PR provides additional evidence for the empty-set fallback bug. The challenger provided evidence-based justifications for removing all findings, but the orchestrator fell back to pre-challenger findings. Same mechanism as the Renovate PR described in #2485.
• Review agent should suppress low-value compliance findings on trivial config-only PRs from repo members #150 (low-value compliance findings on trivial PRs): This PR is another instance — a 2-line config-only change by a repo member received a missing-authorization finding that added no review value.
• Review agent should use a lightweight path when it classifies a change as trivial/mechanical #301 (lightweight review path): The triage correctly classified this as "small scope" but still dispatched 3 sub-agents + challenger. A fast path skipping style/intent sub-agents would have avoided the false positive entirely and reduced cost.
• Review agent: cap missing-authorization severity at Low for human-authored PRs with descriptive bodies fullsend#2200 (cap missing-authorization severity for human PRs): The Medium severity on a human-authored PR with a descriptive body is another data point for this calibration issue.