Release: Fallout.Cli first-publish 403 — package not owned by org on nuget.org

[ChrisonSimtian]

Symptom

After the Fallout.GlobalTool → Fallout.Cli rename (#206) merged, the release.yml run for that commit (26483553336) failed at the publish step:

error: Response status code does not indicate success: 403
(The specified API key is invalid, has expired, or does not have permission
to access the specified package.).

Specifically on the push of Fallout.Cli.10.3.41.nupkg. Other Fallout.* package pushes in the same run did not fail (they're idempotent via --skip-duplicate, but they also have the right ownership).

Root cause

The first manual web upload of Fallout.Cli.10.3.39-g7885ec5647.nupkg (done pre-merge to satisfy the prefix-reservation gotcha) landed on nuget.org under the personal account, not the org that owns the API key used by release.yml. Result: package ID is reserved, but the org doesn't have push permission for it, so the CI key 403s on subsequent pushes.

This is a known operational footgun of nuget.org's manual-upload flow: the "Package owner" field defaults to the uploading user's profile, not whichever org their API key belongs to. There's no UI prompt to switch ownership at upload time — it requires a follow-up transfer.

Mitigation in progress

nuget.org support has been contacted to transfer ownership of Fallout.Cli to the org.

What to do once support transfers ownership

1. gh run rerun <release-run-id> --failed on the latest release.yml run for main, OR push any non-docs commit to main to retrigger.
2. --skip-duplicate means previously-published Fallout.*.10.3.41.nupkgs won't re-push or error; only the missing Fallout.Cli.10.3.41.nupkg push gets retried.
3. Verify Fallout.Cli appears on nuget.org under the org's account with 10.3.41 listed.

Lesson for next time

When manually web-uploading the FIRST version of a new Fallout.* package (the prefix-reservation gotcha workflow):

• After upload, explicitly transfer ownership to the org via Manage Package → Owners → Add owner → <org name> (then optionally remove personal account).
• OR: upload using credentials of the org's service account directly (avoids the transfer step but requires having such credentials handy).
• Verify on the package page that the listed owner is the org before the next CI push attempt.

Worth adding a one-liner to the existing prefix-gotcha note in docs/dependencies.md or wherever the gotcha is documented.

Refs

• Triggered by PR chore(globaltool)!: rename Fallout.GlobalTool → Fallout.Cli #206 (rename).
• Related to the prefix-reservation gotcha ([P4] Reserve Fallout.* package IDs on nuget.org #33 follow-ups, fix(publish): --skip-duplicate so nuget push is idempotent #108).
• See also Establish nuget.org organization account for Fallout.* packages #185 (establish nuget.org organization account for Fallout.* packages) — partial overlap; this issue is more about the manual-upload-ownership footgun specifically.

[ChrisonSimtian]

Resolved on rerun. The gh run rerun 26483553336 --failed immediately after filing this issue pushed Fallout.Cli.10.3.41 successfully (Your package was pushed. in the logs). Other Fallout.* packages skip-duplicated as expected. Either nuget support transferred ownership in the few-minute gap, or the org-permission propagation finished naturally.

Leaving this issue open for the documentation follow-up: the operational lesson (set owner = org when manually web-uploading the FIRST version of a new Fallout.* package) still needs to land in docs/dependencies.md or wherever the prefix-gotcha is currently documented. Once that's in, this can close.