refactor(cli, runner): replace Any with VisualQARunner/ClaimVerifier in runner-handling signatures - #290
Conversation
…in runner-handling signatures cli.py's _new_runner()/_runner_scope() and runner.py's _resolve_default_visualize() were typed Any even though every real call site passes/returns a concrete VisualQARunner or ClaimVerifier instance, continuing the same Any->concrete-type vein as #277/#281/#283/#284/#285/#289. Tightened using a TYPE_CHECKING-guarded import in cli.py (matching runner.py's own existing pattern) to avoid circular import risk. Annotation-only, zero behavior change. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FAav5x8va7JZ8E1LmLYQKy
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe changes improve static typing for CLI runner helpers and the visualizer claim verifier. Runtime behavior remains unchanged. ChangesStatic type annotation refinement
Estimated code review effort: 1 (Trivial) | ~3 minutes Merge Risk: ⚪ Minimal · up to This change narrows runner-related type annotations without changing runtime behavior, so no actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
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. Comment |
…n types (#291) BrowserManager.__aexit__ typed exc_type as bare `type | None` and traceback as `Any`, even though Python's own contextmanager protocol has concrete stdlib types for both: `type[BaseException] | None` for the exception class and `types.TracebackType | None` for the traceback. This is the same Any->concrete-type vein this repo has mined repeatedly (most recently #277-#290), just applied to a dunder signature using a stdlib type instead of a project type. Annotation-only, zero behavior change: the method body only calls self.close() and never inspects any of its three parameters. Verified BrowserManager is only ever driven through `async with` (13 call sites in tests/test_browser.py) with no direct __aexit__ invocation anywhere in the repo, so no caller depends on the old signature. Co-authored-by: Claude <noreply@anthropic.com>
…| type[ClaimVerifier] (#297) _load_class returned Any even though _DEFERRED_IMPORTS only ever names NavigatorClient or ClaimVerifier, both already imported under TYPE_CHECKING in this file, and both call sites immediately instantiate the result. Continuing the same Any/type[Any]-to-concrete-type vein as PRs #290-#296. Claude-Session: https://claude.ai/code/session_01UNp1qd4G67kz4mMxt5Z6u3 Co-authored-by: Claude <noreply@anthropic.com>
What
Continues the
Any->concrete-type tightening vein from #277/#281/#283/#284/#285/#289:cli.py's_new_runner()(-> Any) and_runner_scope()(AsyncIterator[Any]) — every real call site constructs/yields aVisualQARunner. Added aTYPE_CHECKING-guarded import ofVisualQARunner, matching the pattern already used inrunner.py/claim_verifier.py/actions.pyto avoid a circular import (cli.py->runner.py-> ... at module scope).runner.py's_resolve_default_visualize(claim_verifier: Any, fallback: bool)— its only two call sites always passself.claim_verifier, which is already typedClaimVerifier | NoneonVisualQARunner.__init__and is neverNoneby the time_resolve_default_visualizeis called.runner.pyalready had aTYPE_CHECKING-guarded import ofClaimVerifier, so this just reuses it.Why it's safe (no behavior change)
Both files already use
from __future__ import annotations, so these annotations are never evaluated at runtime — this is purely a static-typing improvement with zero effect on program behavior.getattr(claim_verifier, "_visualize", fallback)inside_resolve_default_visualizeis unchanged and still defensively falls back for any non-ClaimVerifierduck-typed test double.Verification
python3 -m py_compileon both touched files — clean.uv run ruff check src/ tests/— clean.uv run ruff format --checkon the touched files —runner.pyclean;cli.pyshows the same 2 pre-existing "would reformat" hunks (lines ~274, ~468) that exist onmaintoday and are unrelated to this diff (confirmed viaruff format --diff) — consistent with AGENTS.md's note not to reformat existing files.uv run pytest tests/— 322 passed / 21 failed, identical to themainbaseline (the 21 failures are the documented pre-existing environment-only failures from a missing Chromium binary in this sandbox).🤖 Generated with Claude Code
Generated by Claude Code
Note
Low Risk
Annotation-only change; annotations are not evaluated at runtime and duck-typed test doubles still work via getattr.
Overview
Tightens static types on runner-handling helpers with no runtime behavior change (
from __future__ import annotations)._new_runnerand_runner_scopeincli.pynow returnVisualQARunnerinstead ofAny, using aTYPE_CHECKINGimport to avoid a circular import._resolve_default_visualizeinrunner.pynow takesClaimVerifierinstead ofAny.Reviewed by Cursor Bugbot for commit 1858560. Bugbot is set up for automated code reviews on this repo. Configure here.
Summary by CodeRabbit