tighten-python-types

Apply a focused workflow to files already changed for your task: replace broad Any and unparameterized containers with the narrowest types supported by evidence, then run the repository's type checker and tests. Avoid unrelated refactors and formatting churn.

Replace Any with precise types only where evidence supports it, using natural narrowing, protocols, typed boundaries, and small helpers instead of cast. For dynamic or untrusted data, validate it or keep the uncertainty visible at the boundary rather than inventing types.

Yes, the workflow first determines the configured type checker and supported Python version before choosing syntax or commands. It then runs the repository's own checker, such as ty check, along with the formatter, linter, and focused tests.

Use cast only when runtime facts cannot be expressed through natural narrowing, protocols, or typed boundaries. The workflow prefers narrowing and small typed helpers because they keep annotations honest and verifiable by the type checker.

No, the workflow explicitly preserves runtime behavior and public compatibility. It avoids unrelated refactors, blanket ignores, and formatting churn, and reports any annotations intentionally left broad after verification.