check_interface() False-Flags a Release Gate Written as a Folded Scalar, Because #949's Fix Drops Every Block-Scalar Body Including an if: Expression

[ptr727]

#949 taught _code_view() to drop block-scalar bodies, so a token sitting in a documentation
string could not be read as structure. That defense does not distinguish a documentation
block scalar from an expression one, and if: is routinely written as a folded scalar. The
body it drops there is not prose about the gate. It is the gate.

The result is inverted: check_interface() reports a required release gate as missing on a
workflow that has it.

Reproduction, constructed

jobs:
  publish:
    name: Publish project release job
    needs: [plan, validate]
    if: >-
      ${{ needs.plan.outputs.publish == 'true' && needs.validate.result == 'success' }}
    uses: owner/repo/.github/workflows/build-release-task.yml@<pin>

requireTokensInJob looks for needs.validate.result == 'success' in this job. Run
_code_view() over it and the job reduces to:

  publish:
    name: Publish project release job
    needs: [plan, validate]
    if: >-
    uses: owner/repo/.github/workflows/build-release-task.yml@<pin>

The if: key survives and its entire condition is gone, so the token is absent and the audit
emits:

DRIFT  interface: .github/workflows/publish-release.yml job 'publish' missing required 'needs.validate.result == 'success''

Measured directly, importing the module and calling it on that job text: token present in the raw
job text True, token present in the _code_view() output False.

Writing the same condition inline on one line passes. The two forms are identical to GitHub
Actions, so the check is testing how the YAML is wrapped rather than whether the gate exists.

Where it showed up

The 2.0.577 resync pilot, audit run 2026-09-07T02:37:02Z | hub f8e7491, reported this against
PlexCleaner's publish-release.yml. The condition is present and correct there at both main
and develop, byte-identical, in the folded form above. The finding was carried into the resync
as real work before being checked, which is the cost this issue is about: a false positive on a
release gate invites someone to "fix" a workflow that is not broken, and the plausible fix is to
rewrite a correct condition.

Why a blanket rule cannot resolve it

The two cases genuinely conflict, and neither yields to a heuristic over the text:

• name: | followed by prose that happens to contain a token is what check_interface()'s token matching reads YAML block-scalar content as structure #949 closed. The body is
  documentation and must not be read as structure.
• if: >- followed by an expression is structure, and dropping it loses the only copy.

The distinguishing fact is the key, not the scalar style: if, and the other
expression-bearing keys, hold a value that is always structure. A candidate fix is to keep the
folded or literal body for a known expression-bearing key set (if at minimum) and keep dropping
it everywhere else. Parsing the YAML and reading the value, rather than substring-matching the
text, resolves it more completely, and #949's own reasoning about the text view would then apply
only to the keys where a string body really is prose.

Whichever way it goes, spec/audit.py's self-test deserves a case for each of the two forms, since
the current suite passes with the inline form only and that is why this reached a downstream
repository.

Found during the #1399 fleet resync pilot.

[ptr727]

Disposition, decided 2026-09-07: keep the block-scalar body for a known set of expression-bearing keys, and keep dropping it everywhere else. Recorded here rather than implemented.

This is the candidate the issue names. It is targeted, and it preserves #949's defense exactly where that defense was aimed, which is a documentation string whose prose happens to contain a token.

Parsing the YAML and reading values rather than substring-matching the text was weighed and not taken. It resolves the question more completely, and inside a file the size of spec/audit.py it changes what every other text-view check sees, so the blast radius reaches well past this one finding.

The accepted cost is that the key set becomes a thing to maintain: a future expression-bearing key added to GitHub Actions is silent until someone hits it. if is the floor rather than the whole set, so resolve the rest of the expression-bearing keys when implementing rather than shipping if alone.

Both self-test cases the issue asks for remain required either way, the folded form and the inline one, since the suite passing with the inline form only is why this reached a downstream repository.

[ptr727]

Duplicate of #1133. The same defect from the same root cause (#949 taught _code_view() to drop every block-scalar body, including an if: expression, so requireTokensInJob cannot see a token in the folded shape GOVERNANCE.md and WORKFLOW.md mandate). #1133 carries the reproduction, the fleet-wide table separating the two false positives from the seven true findings, and the three candidate directions.

Detail this issue held that #1133 did not has been carried forward there as a comment, so nothing is lost. Follow #1133 for the work.