WORKFLOW.md D1.6 Says CODECOV_TOKEN Reaches the Validator via secrets: inherit, but the Caller Stub Maps It Explicitly

[ptr727]

Evidence

WORKFLOW.md D1.6, current on main at f3b4cc9 (2.0.526), states:

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

Every other surface says the opposite for a repo that has adopted the hub-hosted validator. docs/reusable-workflows.md "Adopting the Gates" and "Adopting the Release Chain" both write the caller stub as an explicit mapping:

  validate:
    uses: ptr727/ProjectTemplate/.github/workflows/validate-task.yml@<sha> # <tag>
    permissions:
      contents: read
    secrets:
      CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}

and the live pilot, ptr727/PhotoCleaner/.github/workflows/test-pull-request.yml on main, carries that same explicit form.

Why the wording matters rather than just being stale

secrets: inherit on a cross-repository call passes the caller's whole secret store to the called workflow. For a repo like Utilities that is NUGET_USERNAME, CODECOV_TOKEN, CODEGEN_APP_CLIENT_ID and CODEGEN_APP_PRIVATE_KEY, where the validator declares exactly one optional secret and needs only that one. WORKFLOW.md D1.6 was written when the validator was a same-repo ./ call, where inherit costs nothing, and adopting the hub task changes that without the sentence changing with it.

WORKFLOW.md is carried at intent, so a downstream repo reading its own copy is being told to widen a grant its own hub-authored stub deliberately narrows. spec/project-types.json's csharp.coverage.codecov assertion carries the same clause and would need the same edit.

Where it came from

Surfaced during ptr727/Utilities' resync, ptr727/Utilities#451, which adopted the hub validator at f3b4cc9 and used the explicit mapping from the docs/reusable-workflows.md stub. A local review flagged the carried D1.6 as contradicting the workflow it governs. The repo kept the explicit mapping and is filing here rather than hand-editing carried text.

Related: the --collect:"XPlat Code Coverage" half of the same sentence was already corrected by #1107 in this release, so this is the remaining half of the same paragraph.