Fix file-length enforcement so the 600-line rule is real and consistent

[larock22]

Problem

Our current >600 file-length policy is not being enforced consistently. The repo presents this as a real rule, but in practice the enforcement has drifted enough that the signal is unreliable.

This is not just a "shorten a few files" problem. The rule implementation itself needs cleanup so the policy matches what contributors and CI actually experience.

What is wrong today

1. Oversized source files are explicitly allowlisted in scripts/check-file-length.sh.

   • src/tunacode/core/agents/main.py is currently over 600 lines and is skipped.
   • Other source files are also exempted by name.

2. Pre-commit and the shell script do not define the same policy surface.

   • tests/benchmarks/bench_discover.py is excluded in .pre-commit-config.yaml but not in scripts/check-file-length.sh.
   • That means direct script runs and CI-style runs can disagree.

3. Standalone runs can scan outside the intended project surface.

   • In this workspace, the script walks nested .worktrees/ content and reports files from nested virtualenvs and generated reports.
   • That makes the raw script noisy and undermines trust in the check.

4. The repo messaging implies a blanket rule that is not actually true.

   • PR template says: "No Python file exceeds 600 lines"
   • Actual behavior is: "No Python file exceeds 600 lines, except for a growing list of carve-outs and path-specific exclusions."

Why this matters

A policy that exists mostly in wording but not in enforcement creates the wrong incentives:

• contributors cannot tell what is truly required
• local runs and CI can disagree
• allowlists become permanent instead of temporary
• the rule stops driving modularization because violations can be normalized with exemptions

Proposed fix

Treat this as an enforcement/system issue:

• Define the scope of the rule explicitly.

  • Likely: first-party source and test files only.
  • Exclude generated artifacts, vendor code, caches, worktrees, and lockfiles centrally.

• Make one source of truth for file-length enforcement.

  • Either move the logic entirely into one script/test, or ensure pre-commit and direct invocation share the exact same exclusion model.

• Convert file-specific allowlists into explicit temporary debt with owners or linked issues.

  • If a file must remain exempt, the exemption should be documented and easy to audit.

• Make the rule output actionable.

  • Fail only on files in scope.
  • Report why a file is excluded when debugging the rule.

• Align docs with reality.

  • If the rule is strict, enforce it strictly.
  • If the rule is transitional, document the transitional policy instead of claiming a blanket 600-line rule.

Acceptance criteria

• Running the file-length check directly and via pre-commit produces materially consistent results.
• Nested worktrees / virtualenvs / generated reports are not scanned.
• Oversized first-party files are either:
  • enforced normally, or
  • listed in a clearly documented temporary exemption mechanism.
• The PR template and contributor guidance match the actual enforcement behavior.

Notes

This issue is about fixing the policy and enforcement path. Follow-up refactors to split oversized modules can happen after the rule is trustworthy.