Stop ci-shared capping the pipelines' permissions

[matt-edmondson]

What the canary found

ktsu-dev/Sorting#46 adopted ci.yml and the run ended startup_failure with zero jobs.

A called workflow cannot elevate above what its caller granted, and ci-shared.yml's workflow-level permissions: contents: read became the ceiling for every pipeline it dispatches. dotnet.yml's release job asks for contents: write and packages: write, which under that ceiling can never be satisfied — so the run died before a job existed to report it.

The permission surface the pipelines actually request:

Workflow	Job	Requests
dotnet.yml	release	contents: write, packages: write
dotnet.yml	security	id-token: write, contents: write
dotnet-private.yml	build	contents: write, packages: read
dotnet-private.yml	winget	contents: write
dotnet-private.yml	security	id-token: write, contents: write

Union: contents: write, packages: write, id-token: write.

The fix

• ci-shared.yml drops its workflow-level permissions so the caller's grant flows through, and detect takes contents: read on its own — it only reads repository metadata.
• The caller template in docs/shared-ci.md now grants that union. It is the real contract between a repository and the shared pipelines, so it belongs in the caller where it is granted, rather than being discovered through a startup failure.

This widens nothing at runtime. dotnet.yml keeps its own permissions: contents: read default and its per-job overrides, behaving exactly as it did standalone. The only difference is that the ceiling above it is now high enough to permit what it already asked for.

What the canary proved before it failed

The run recorded its referenced_workflows as:

ktsu-dev/.github/.github/workflows/ci-shared.yml@release        (refs/tags/release)
ktsu-dev/.github/.github/workflows/dotnet.yml@905bdc6…          (refs/tags/release)
ktsu-dev/.github/.github/workflows/dotnet-private.yml@905bdc6…  (refs/tags/release)

The relative ./ reference inside ci-shared.yml resolves within ktsu-dev/.github, at the same commit as ci-shared.yml — not against the calling repository. That is the assumption the entire dispatcher rests on, it was the one thing the docs did not state for the nested case, and it is now settled by observation rather than inference. The @release tag also resolved correctly on its first real use.

After this merges

The release tag needs re-promoting to pick this up (Promote release, ref main), then Sorting#46 needs its ci.yml updated with the permissions block and re-run.

Testing

actionlint 1.7.7 with shellcheck clean; markdownlint-cli clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_014RABe2NufFc9hwm94iB3Rf

---

Generated by Claude Code