WORKFLOW.md D1.6 says secrets: inherit while reusable-workflows.md says it is never used, and the carried file is the wrong one

[ptr727]

WORKFLOW.md D1.6 says CODECOV_TOKEN reaches the reusable validator via secrets: inherit. docs/reusable-workflows.md says secrets: inherit is not used at all. Both are hub content, they cannot both be right, and the wrong one is in the file every repository carries.

Reported by the ptr727/Utilities session while adopting 2.0.536, and verified here against main at 1fe2537.

The contradiction

WORKFLOW.md:157 (D1.6), identical in 2.0.526 and 2.0.536:

CODECOV_TOKEN lives in the repo's actions secret store and reaches the reusable validator via secrets: inherit

docs/reusable-workflows.md:71:

secrets: inherit is not used, since it is documented for a caller in the same organization or enterprise as the called workflow and the fleet is a personal account.

Which one the implementation follows

.github/workflows/validate-task.yml:23-25 declares the secret rather than expecting it inherited:

    secrets:
      CODECOV_TOKEN:
        required: false

That is the explicit-mapping shape. ptr727/Utilities maps CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }} in both callers and its CI passes, which is the live evidence. So D1.6 is the stale text.

The hub's own two callers of validate-task.yml pass no secrets at all, since it is source-only and uploads no coverage, so the hub tree alone cannot settle it. That is worth knowing: no hub gate can catch this, which is why it survived to a carrier.

It is a three-way contradiction, not two

docs/reusable-workflows.md also contradicts itself. Its own stub at line 324 carries secrets: inherit:

  smoke-build:
    needs: [changes]
    if: needs.changes.outputs.release == 'true'
    uses: ./.github/workflows/build-release-task.yml
    secrets: inherit

So whichever way D1.6 is resolved, that stub needs resolving with it, and the distinction the three texts blur is probably same-repository (./) versus cross-repository (owner/repo@sha) calls, where the line 71 reasoning actually bites.

Suggested wording

The Utilities session already carries a corrected D1.6 locally, and preserving it is what surfaced this (a straight re-vendor would have replaced a correct local rule with text contradicting that repo's own CI). Its wording is worth adopting so the delta disappears on the next resync: the token "is mapped to the reusable validator explicitly, under the calling job's own secrets: block", plus a sentence noting that a cross-repository call would otherwise hand the validator every secret the caller holds.

Note

carried-instruction-file-guard is what caught this downstream. It is working, and this issue is the upstream half it exists to route to.

[ptr727]

Rolled up per #1315 into the unit tracker(s) #1369, #1360: every finding this issue enumerates appears there as a numbered line naming this issue. Closing as a duplicate of those trackers so no finding is lost and this bundle stops being a unit of work.