fix(build): stop bump_version clobbering mypy python_version (main reads 2.3.0)

[plauzy]

Problem

[tool.mypy].python_version on main is "2.3.0" — the package version, not a Python target. scripts/bump_version.py rewrites it on every release because update_pyproject uses an unanchored regex:

re.sub(r'version = "[^"]+"', f'version = "{new_version}"', content)

version = "..." also matches the tail of python_version = "..." under [tool.mypy], so each bump clobbers the mypy target. This means mypy is not type-checking against the supported floor (requires-python = ">=3.10", Black py310).

Fix

• Anchor the substitution to the start of a line and cap it to the first match, so only the [project] version is rewritten:

  re.sub(r'(?m)^version = "[^"]+"', f'version = "{new_version}"', content, count=1)

• Repair the current value to python_version = "3.10".

Verification

Simulated a bump against the real pyproject.toml: the [project] version updates while python_version stays "3.10" (previously it was overwritten). Two-line change; no runtime code touched.

Co-authored-by: Kiro Agent 244629292+kiro-agent@users.noreply.github.com

---

Context / Refs #386 — surfaced while rebasing the AG-UI workstream (#386) onto latest main; a valid [tool.mypy].python_version is a prerequisite for the type-check gate to be meaningful on the feature PR (#436). This fix is independent and can merge on its own.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@8e0f0bd). Learn more about missing BASE report.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #435   +/-   ##
=======================================
  Coverage        ?   88.39%           
=======================================
  Files           ?      137           
  Lines           ?    16369           
  Branches        ?        0           
=======================================
  Hits            ?    14470           
  Misses          ?     1899           
  Partials        ?        0           

Flag	Coverage Δ
unittests	88.39% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gutosantos82]

PR Review: #435 — fix(build): stop bump_version clobbering mypy python_version (main reads 2.3.0)

• Head: 1f91b9d439314a76a3d38d59d51c4aaf8c987b88 (current at review time, 2026-07-15)
• Size: +6 / −2 across 2 files (pyproject.toml, scripts/bump_version.py) — no runtime code
• State: OPEN, MERGEABLE, reviewDecision=REVIEW_REQUIRED; all 20 CI checks pass at this
  head (Code Quality, Unit Tests 3.10/3.11, Security Scan, Trivy, Dependency Review, MCP Apps).
• Comments: Codecov bot only ("all modified and coverable lines covered"); no human feedback.
• Ref: split out of the AG-UI workstream (#386); prerequisite for a meaningful type-check
  gate on #436.

Summary

Fixes a real, verified release-tooling bug: update_pyproject in scripts/bump_version.py
used an unanchored version = "[^"]+" substitution, which also matches the tail of
python_version = "..." under [tool.mypy], so every release bump rewrote the mypy target
with the package version. The PR anchors the pattern to line start with (?m)^ and caps it
with count=1, and repairs the current corrupted value to python_version = "3.10" (matching
requires-python = ">=3.10" and Black's py310). Diagnosis, fix, and the PR body's
verification claim are all accurate. Recommend approve; two optional nits.

Blocking (must fix before merge)

None found.

Important (should fix)

None found.

Nits (optional)

• [consistency] scripts/bump_version.py:17 (get_version) — the read side still uses the
  unanchored re.search(r'version = "([^"]+)"', ...). It is correct today only because the
  [project] version (line 3) happens to be the file's first match; if the key order ever
  changed, get_version would silently pick up a wrong value and the next bump would compound
  it. Since this PR's whole point is un-fragile version rewriting, anchoring the read side the
  same way ((?m)^version = "([^"]+)") would finish the job. One-line change.
• [tests] scripts/bump_version.py — no regression test. A tiny unit test asserting that
  update_pyproject rewrites only the [project] version and leaves
  [tool.mypy].python_version untouched would prevent this exact class of regression from
  returning; scripts/ currently has no test coverage at all, so this is a nice-to-have, not
  a gate.

Prior feedback (already raised — not restating)

None — no human feedback on the PR at review time.

Tests

No tests added (see nit above). Acceptable for a two-line build-script fix: the change is
fully characterized by the simulation below, all existing suites pass at this head, and the
repaired python_version cannot break CI because every mypy step in the workflows
(ci.yml and all four provider workflows) runs with continue-on-error: true — mypy is
advisory. Note that repairing the value makes mypy actually run with a valid target for the
first time in a while, so the advisory step may start reporting pre-existing type errors that
the corrupted config previously masked; that is the intended effect (and the stated
prerequisite for the type gate on #436), not a regression.

Verification

Performed directly at this head (worktree checkout of 1f91b9d4):

• ✓ VERIFIED — the bug exists as described: simulated the old (main) regex against the
  PR-head pyproject.toml → both version and python_version rewritten to the bump value.
  Corroborated historically: my local stale origin/main shows python_version = "2.1.1" and
  the PR reports current main at "2.3.0" — i.e. successive releases each stamped the
  then-current package version, exactly the claimed clobbering.
• ✓ VERIFIED — the fix works as described: simulated the new regex
  ((?m)^version = "[^"]+", count=1) → only the [project] version changes;
  python_version = "3.10" untouched. pyproject.toml at this head contains exactly one
  line-anchored version = line (line 3), and target-version (Black) cannot match a
  ^version anchor, so count=1 selects the right line deterministically.
• ✓ VERIFIED — get_version() still resolves the correct value at this head (first match is
  the [project] version), so the read/write pair stays consistent (see nit).
• ✓ VERIFIED — no CI breakage possible from the repaired mypy target: all five mypy
  invocations across the workflows are continue-on-error: true.
• ✓ VERIFIED — all 20 checks pass at this head (gh pr checks 435).

Verdict

Approve with nits — correct, minimal, honestly described fix to real release-tooling
corruption, verified end-to-end by simulation; the two nits (anchor get_version too, add a
regression test) are optional follow-ups.