prepare: fabricated SyntaxError finding — readiness agent parses source with an interpreter older than the project's target version

[ellen-goc]

Summary

askcc prepare reported a false blocking defect — a non-existent SyntaxError — as the headline finding of a readiness review, and wrote it into the GitHub issue body as a blocking dependency and a blocking acceptance criterion. The cause appears to be that the readiness agent parsed project source with an interpreter older than the project's declared target version.

Observed on weyucou/mther-backend (Python 3.14 project) at 2026-08-27 12:43 JST, exit code 0.

What happened

The agent read bishop/accounts/views.py:318:

except InvalidToken, TokenError:

and reported:

Key finding: not development-ready yet — bishop/accounts/views.py:318 has a pre-existing except InvalidToken, TokenError: syntax error (Python 2 style, invalid under 3.14) on main, so the module currently fails to import. I confirmed this directly by reading the file.

It then edited the issue body to add a ## ⚠️ Blocking issue found during readiness review section, an acceptance criterion "Fix the pre-existing syntax error … required for the module to import at all", and a ## Dependencies entry "Blocking (in-repo): syntax error".

Why it is wrong

PEP 758 ("Allow except and except* expressions without parentheses") shipped in Python 3.14. Unparenthesized multiple exception types are valid syntax on 3.14+ and a SyntaxError on 3.13 and earlier.

The project declares 3.14 in both places that matter:

Where	Value
pyproject.toml [tool.ruff]	target-version = 'py314'
.github/workflows/ci.yml	python-version: "3.14"

Verified by compiling the exact main file content under both interpreters:

python3.14  ->  COMPILES OK on 3.14.3
python3.12  ->  SyntaxError: multiple exception types must be parenthesized

Ruff reproduces the same version split (--target-version py314 passes, py312 errors), and the repository's CI has been green on that line since 2026-07-04 — about eight weeks. The agent's own claim ("the module currently fails to import") is contradicted by eight weeks of passing manage.py test runs.

Impact

Worse than a missed finding, because the output is confidently wrong and self-certifying ("I confirmed this directly by reading the file"):

1. The issue body is corrupted with a fabricated blocker. A downstream develop run would have "fixed" working code and shipped a commit message asserting a bug that never existed.
2. It is indistinguishable from a true finding without independent verification. The reasoning is plausible, cites a real file and line, and quotes a real error string.
3. It will recur on every 3.14 project using PEP 758 syntax — and generalizes to any language feature newer than the interpreter the agent reaches for.
4. action:develop was applied anyway, despite the run's own conclusion being "not development-ready yet" — so the fabricated blocker was left in the body while the issue was simultaneously marked ready. (Related to bug: develop transitions action:develop→action:review even when the agent produced no PR (stop-and-ask outcome) #116's class of label/deliverable mismatch, though the trigger here is different.)

Suggested fixes

Roughly in order of cost:

1. Resolve the project's target version before parsing. Read requires-python / [tool.ruff] target-version / the CI matrix, and use a matching interpreter — or at minimum state the interpreter used in the finding.
2. Do not assert a SyntaxError from a bare read. If a syntax defect is suspected, verify against the project's own gates (ruff check, the configured test command) rather than an ad-hoc parse. Those gates already encode the correct target version.
3. Cross-check against CI before reporting a blocking defect on main. A claim of the form "main does not import" is falsified by a green required check on main, which is one API call away and would have caught this.
4. Suppress readiness-blocking claims the run cannot substantiate, or downgrade them to "possible finding — verify" so they are not written into the issue body as acceptance criteria.

Reproduction

Any file targeting Python 3.14 containing:

try:
    pass
except ValueError, TypeError:
    pass

in a project whose pyproject.toml declares target-version = 'py314'. Run askcc prepare against an issue naming that file under ## Affected Files.

---

Reported per the weyucou operating rule that askcc defects are filed upstream rather than worked around locally. The affected issue (weyucou/mther-backend#114) has been corrected by hand and carries the full evidence.