Skip to content

Adopt pyright: basic mode in CI, then targeted strict #245

Description

@pbean

Finding F-4 of the "Brownfield CLI/TUI Refactor Assessment" (local report, gitignored under _bmad-output/implementation-artifacts/).

Evidence

No type checker anywhere: no pyright/mypy config in pyproject.toml, .trunk/, or CI. Annotations are pervasive but unverified, so annotation drift is invisible and the refactor program's code moves lose a cheap safety net.

Recommendation — two stages

Stage 1 (basic mode):

  1. Spike: run pyright in basic mode over src/bmad_loop (exclude src/bmad_loop/data/) and count errors.
  2. If the burn-down is >~200 errors, STOP and report the count here with a proposed per-module rollout instead of landing the gate.
  3. Otherwise: fix cheap errors, add targeted per-file suppressions for the rest (each with a one-line reason), commit pyright config (pyproject [tool.pyright] or pyrightconfig.json), and add a CI job mirroring the existing lint job structure in .github/workflows/ci.yml.

Stage 2 (targeted strict): enable per-module strict checking for the pure modules only (model.py, statemachine.py, policy.py, documents.py, machine.py, checks.py, sanitize.py); fix or precisely suppress what surfaces.

No runtime behavior changes in either stage.

Ordering

Sessions 8 and 12 of the refactor program. Stage 1 should land before the Engine collaborator extractions (it fences those moves); Stage 2 requires Stage 1 merged.

Traps

  • Verify current pyright config options/versions against official docs before writing config — don't pin from memory.
  • The burn-down size is an explicitly deferred decision until the spike runs.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions