fix(ci): stop a broken workflow step reporting clean, and the guard rewriting it into something that parses (#15152)

[mrveiss]

Thinking Path

Re-scoped. This PR originally cited #15122, which has since been closed not_planned because its premise was wrong. The premise deserves a correction on the record, and then the two defects that survive it.

What was wrong. #15122 claimed test_every_extracted_program_parses fails on the base and that the failure is "environment-independent — no package, Python version or checkout layout is involved". It is not. PEP 701 made an f-string reusing its own quote type inside the expression legal from 3.12. CI runs 3.12/3.14, where shard 12 is green. The red was a 3.10-only artifact. My earlier framing of this PR repeated a different piece of that error — I described the extractor as truncating its capture. It does not: _INLINE_PYTHON's (?:\\.|(?!\1).)* alternation is escape-aware, the capture ends on %"), and the next character after the match is a space. The fragment in the failure message is code[:60], display truncation inside the assertion itself.

What survives, and why it is worth more than the original claim. Two strings were being conflated:

• A — what sh hands the interpreter for a single-quoted -c argument, backslashes intact: … print(f"…{r.get(\"overall_maturity\", 0):.1f}%")
• B — what the extractor produced after _unescape_shell stripped \" → ": … print(f"…{r.get("overall_maturity", 0):.1f}%")

Measured with ast.parse on four interpreters:

	3.10	3.11	3.12	3.14
A — runtime truth	SyntaxError: f-string expression part cannot include a backslash	same	SyntaxError: unexpected character after line continuation character	same
B — extractor output	SyntaxError: f-string: unmatched (	same	parses	parses

A fails on every version. B is version-dependent. _unescape_shell was quote-blind — it applied double-quote rules to a single-quoted program that sh never escape-processes — so it turned A into B. That is not a cosmetic infidelity: it is the transformation that converts a program broken on every interpreter into one that parses on the two CI runs.

The consequence, measured against the unmodified base in the same checkout:

Interpreter	unparseable programs the base guard reports	imports it extracted for the broken step
3.10	[('phase_validation.yml', …)]	[]
3.14 (CI)	[]	['json']

On the interpreter CI actually runs, the base guard reports zero problems and claims to have checked json — for a step that cannot start. A guard that rewrites its subject into something that passes is indistinguishable from a guard that passes. That is the same theme as the sibling PR, one layer earlier: not a skipped subject, a silently substituted one.

And the step really is broken. phase_validation.yml:52 pins setup-python at 3.14; run verbatim under bash with that interpreter:

SyntaxError: unexpected character after line continuation character

With the step's own 2>/dev/null || echo "Results not available" attached, the observed output is Results not available. The job summary has been printing the fallback in place of the maturity figure for as long as the line has existed — a live defect in what a workflow reports, independent of any test.

What Changed

.github/workflows/phase_validation.yml:126 — the maturity value is bound to a name and formatted with .format, so the program carries no backslash and needs no nested quoting. Verified under 3.14: **Overall System Maturity:** 42.5%.

repo_tests/test_ci_import_smoke_paths_14252.py

• _unescape_shell(code, quote) unescapes only for ". A single-quoted program is returned exactly as sh delivers it.
• _imported_names no longer catches SyntaxError. A caller receiving [] could not distinguish "imports nothing" from "could not be read", and the assertion passed either way.
• _uncaptured_invocations() + test_no_python_dash_c_invocation_escapes_the_extractor — every python -c site must be captured as one whole shell argument. A site the pattern cannot close on previously produced no scan entry at all, so nothing iterated over it.
• test_phase_validation_inline_programs_are_actually_checked, plus direct assertions that single-quoted backslashes survive and that unreadable input raises.
• The stale docstrings are corrected. _INLINE_PYTHON's comment and test_every_extracted_program_parses's docstring both described the pre-fix truncation as current; that text produced two independent mis-diagnoses. Both now state that the capture is complete and point at _unescape_shell and the code[:60] slice instead.
• The parse-failure message now names the interpreter and says the result is version-dependent, so a 3.10-only failure cannot again be read as environment-independent.

Sweep: 4 backslash-carrying python -c sites. auto-fix-generated-types.yml:153, coverage.yml:178, verify-generated-types.yml:258 are double-quoted, where \" is correct shell escaping and the existing unescaping is right. phase_validation.yml:126 was the only single-quoted one, and the only defect.

Verification

Module lands in shard 12 of 12 (stable_shard.shard_of against .test_durations).

Criterion	Evidence	Kind
The step works under the pinned interpreter	original line under bash + 3.14 → SyntaxError then Results not available; fixed line → **Overall System Maturity:** 42.5%	static
Quote-blindness is real and fixed	test_a_single_quoted_program_keeps_its_backslashes asserts both directions of _unescape_shell	unit
The base guard was falsely green on CI's interpreter	base module executed under 3.10 and 3.14 in the same checkout — table above	static
The fixed guard catches it on CI's interpreter	with only the broken line restored, the fixed guard reports it unparseable on both 3.10 and 3.14 — the version-dependence for single-quoted programs is gone	static
Guard green	pytest repo_tests/test_ci_import_smoke_paths_14252.py → 30 passed	unit
Shard not otherwise disturbed	shard 12 as CI invokes it → 182 passed, 1889 deselected	unit
Sweep	4 sites classified; test_no_python_dash_c_invocation_escapes_the_extractor enforces it continuously	static + unit

Contrast mutations, all against final head aa8a9ca:

Mutation	Observed failure
Restore the escaped f-string in phase_validation.yml	AssertionError: inline python that the extractor could not parse under python 3.10 — its imports are checked against nothing: [('phase_validation.yml', …)]. Whether a program parses is version-dependent (PEP 701); confirm on the version CI runs before calling this a base failure.
Make _unescape_shell quote-blind again	assert 'print(f"{d.get("k")}")' == 'print(f"{d.get(\"k\")}")'
Restore return [] on SyntaxError in _imported_names	Failed: DID NOT RAISE <class 'SyntaxError'>
Add a python -c with a '"'"' splice the pattern cannot close on	AssertionError: python -c invocations the extractor did not capture as one whole argument -- their imports are checked against nothing: [('phase_validation.yml', 124, 'capture ends mid-argument at \'"\'')]

No new KNOWN_LARGE entry and no ceiling change — the module is 308 lines against a 600 ceiling and appears in neither ratchet carrier.

Not proven here: that no other workflow program is version-dependent in the same way. A double-quoted program using nested same quotes is legal on 3.12+ and a SyntaxError on 3.10/3.11, so this guard can still disagree with itself between a developer checkout and CI. None of the four current sites has that shape. The versioned failure message makes the next such disagreement self-explaining rather than mysterious, but it does not prevent it.

Model Used

Claude Opus 5 (1M context)

Closes #15152

[github-actions]

✅ SSOT Configuration Compliance: Passing

🎉 No new hardcoded values of either class — ssot and other both block.

Known backlog in pipeline-scripts/hardcoded_values_baseline.txt is suppressed and tracked in #14371.