[dovvnloading]

Problem

Two defects in the fix that shipped in #394 earlier today. A verification pass measured both against the merged code; neither is theoretical.

The fabricated grade was never actually closed

#394 gated the fallback on json.loads raising — which catches "the model said something unparseable" but not "the model said nothing usable". A reply that parses fine and carries no review went straight past it:

model returns {}                      -> verdict=needs_revision  score=72  risk=medium
model returns {"error":"I cannot..."} -> verdict=needs_revision  score=72  risk=medium
model returns null                    -> verdict=needs_revision  score=72  risk=medium
model returns [1,2,3]                 -> verdict=needs_revision  score=72  risk=medium

_normalize_scores defaults all eight categories to 72, so the node rendered a full verdict banner — "Needs Revision, 72/100, Release risk: Medium" — for a change no model had read. That is the exact defect #394 was written to remove, reached through a different door. And a refusal object is the single likeliest non-happy-path reply any provider gives, so this was the common case, not an edge one.

#394's narrowed shell pattern silently stopped detecting the common shapes

Replacing .* + DOTALL with a flat [^)]* correctly bounded the span to one call — but [^)] cannot cross the ) that closes a nested call, and the ordinary way to write this puts a call in the argument list:

subprocess.run(cmd, shell=True)                         DETECTED
subprocess.run(cmd, env=os.environ.copy(), shell=True)  MISSED
subprocess.run(cmd, cwd=str(path), shell=True)          MISSED
subprocess.run(" ".join(parts), shell=True)             MISSED
subprocess.run(\n    build(cmd),\n    shell=True,\n)    MISSED

Four of six real shapes. The pre-#394 pattern caught all of them — so #394 traded a false-positive class for a false-negative class in a security heuristic. My control test used the one multi-line shape with no nested parens, which is why it passed.

Change

looks_like_a_review() decides the fallback now: a real review has an overview, or a scorecard naming at least one known category, or a non-empty walkthrough/findings/errors list. A genuinely clean review still has the first two, so "nothing wrong here" is not thrown away. Both routes — the parse raising, and the parse succeeding with nothing in it — reach the same place.

The shell span allows one level of nesting ((?:[^()]|\([^()]*\))*?) and still cannot escape the call.

Test plan

• 6 parametrised cases pinning the contentless-reply shapes, and 3 pinning that a thin-but-real review (overview only / scores only / findings only) is still graded normally.
• 7 parametrised cases for shell shapes that must be detected, 4 for shapes that must not be — including a later statement in the same file, which is the false positive the bound exists for.
• Full suite: 3183 passed, 19 skipped. ruff check . clean.

🤖 Generated with Claude Code