Found adopting the hub workflow tasks in ptr727/NxWitness, audit run 2026-09-26T15:37:07Z | hub 45669468 | branch override develop.
The defect
check_interface searches each requireTokensInJob token in _code_view(job) (spec/audit.py line 1749), which drops every block-scalar body so that prose in a name: | cannot fake a token. A folded if: >- is a block scalar too, so its body is dropped. publish-release.yml's contract requires needs.validate.result == 'success' in the publish job, and that token lives in the job's if:. The fleet's own Workflow YAML convention requires if: >- for a multi-line condition, so a caller that follows the convention is reported as missing the token it carries.
A constructed case:
jobs:
publish:
needs: [plan, validate]
if: >-
${{ needs.plan.outputs.publish == 'true'
&& needs.validate.result == 'success' }}
uses: ptr727/ProjectTemplate/.github/workflows/build-release-task.yml@<sha>
_code_view of that job keeps if: >- and drops both condition lines, so the audit reports job 'publish' missing required 'needs.validate.result == 'success''. Written on one line as if: ${{ ... }}, the same condition passes.
Who it hits
- NxWitness: its
publish condition is multi-line.
- PhotoCleaner, the adopted pilot: its
main publish-release.yml shows the same false positive, since its publish job also uses if: >- and _code_view hides the token there too.
Suggested fix
Keep the body of a block scalar whose key is if:, since an if: value is always an expression rather than prose. Alternatively, read the parsed YAML's if string for the token checks.
Found adopting the hub workflow tasks in
ptr727/NxWitness, audit run2026-09-26T15:37:07Z | hub 45669468 | branch override develop.The defect
check_interfacesearches eachrequireTokensInJobtoken in_code_view(job)(spec/audit.pyline 1749), which drops every block-scalar body so that prose in aname: |cannot fake a token. A foldedif: >-is a block scalar too, so its body is dropped.publish-release.yml's contract requiresneeds.validate.result == 'success'in thepublishjob, and that token lives in the job'sif:. The fleet's own Workflow YAML convention requiresif: >-for a multi-line condition, so a caller that follows the convention is reported as missing the token it carries.A constructed case:
_code_viewof that job keepsif: >-and drops both condition lines, so the audit reportsjob 'publish' missing required 'needs.validate.result == 'success''. Written on one line asif: ${{ ... }}, the same condition passes.Who it hits
publishcondition is multi-line.mainpublish-release.ymlshows the same false positive, since itspublishjob also usesif: >-and_code_viewhides the token there too.Suggested fix
Keep the body of a block scalar whose key is
if:, since anif:value is always an expression rather than prose. Alternatively, read the parsed YAML'sifstring for the token checks.