Keep publishing the CLI as Fallout.GlobalTool

[ChrisonSimtian]

Keep publishing the dotnet tool as Fallout.GlobalTool (singular) instead of the Fallout.GlobalTools id introduced in f020810.

Fallout.GlobalTool has 52 published versions on nuget.org (10.2.12 → 10.3.49) — that's the id the entire existing install base already has pinned. Staying on it means no consumer migrates, no id gets unlisted, and no migration guide is needed. Assembly/namespace stay Fallout.Cli; the command stays fallout.

The plural id shipped exactly one prerelease, Fallout.GlobalTools 10.4.0-rc.4, so the blast radius is rc testers only — not a GA break, hence no breaking-change label. The README note covers them.

Changes

• Fallout.Cli.csproj — <PackageId>Fallout.GlobalTool</PackageId>, with a comment recording why the package id deliberately doesn't match the assembly name.
• templates/dotnet-tools.json + BuildScaffolder — fallout :setup writes a fallout.globaltool pin into consumer repos again.
• UpdateNotificationAttribute — in-tool prompt says dotnet tool update Fallout.GlobalTool -g.
• build/Build.cs — drive-by fix: the Install target installed Solution.Fallout_Cli.Name ("Fallout.Cli"), which never matched the packed nupkg id and has been broken since the id was first decoupled. Now uses a GlobalToolPackageId constant.
• Docs — repo-wide sweep of the plural id: README, CONTRIBUTING, introduction, 01-installation, 02-setup, 03-execution, github-actions, rebrand-plan. Deleted docs/migration/from-globaltool-to-cli.md (documented a GlobalTool → Cli rename that is now explicitly never happening; already draft: true, no inbound links).

Deliberately not in this PR

.config/dotnet-tools.json still pins fallout.cli 10.3.45 — the repo's own dogfood pin. Flipping it needs a published Fallout.GlobalTool newer than 10.3.49; changing it here would regress dotnet tool restore for the bootstrappers.

Verification

• dotnet pack src/Fallout.Cli → Fallout.GlobalTool.10.0.0-preview.55.g748120854f.nupkg
• Fallout.Cli.Specs 47/47 passing; build/_build.csproj compiles

Follow-ups

• Cherry-pick onto release/v10.4 before 10.4.0 GA, so GA continues the Fallout.GlobalTool sequence from 10.3.49.
• Deprecate Fallout.GlobalTools 10.4.0-rc.4 on nuget.org with Fallout.GlobalTool as the alternate package.
• Supersedes most of Switch the global tool during migration, and target the kept package id #576 — that PR moves the repo onto the plural id and adds a RewriteToolManifestStep that rewrites consumer manifests to fallout.globaltools. Needs rebasing to the singular id or closing.

🤖 Generated with Claude Code

[ChrisonSimtian]

Follow-ups from this thread are now in place:

• Normalise the package-id / project-name relationship so renames stop moving published ids #582 — issue covering the full rename history and the direction: package id is a consumer contract, project/assembly/namespace are internal and free to move. Includes acceptance criteria for an ADR, an explicit PackageId on every packable project, a published-id registry, a build check, and the rule that any future normalisation happens once at a yearly major rather than incrementally.
• Switch the global tool during migration, and target the kept package id #576 — rebased onto this branch and retargeted at Fallout.GlobalTool. It also gains a SwitchGlobalToolStep that uninstalls a retired global tool and installs the current one, so a migration fixes the machine as well as the repo.

One useful side effect: with the id back to Fallout.GlobalTool, the dogfood pin in .config/dotnet-tools.json is no longer blocked. fallout.globaltool 10.3.49 is published and restores, so #576 flips the pin off fallout.cli 10.3.45. That was the one thing this PR deliberately left alone.

[dennisdoomen]

🤔 Don't you want this on 10.4? If so, it should target the release branch.

[ChrisonSimtian]

Review round two — all threads answered.

On 10.4 (@dennisdoomen): yes, it needs to land there, but via main first rather than retargeting.

main is the integration trunk and release/YYYY-style branches are the production line, so anything that is not a release-line-only fix lands on main and gets promoted — there is already a promote/main-to-v10.4 lane doing exactly that. Retargeting would strand the Install-target fix and the docs sweep on the release branch and let main drift straight back onto the plural id. Cherry-pick before 10.4.0 GA is tracked in the PR description, so GA continues the Fallout.GlobalTool sequence from 10.3.49.

Pushed:

• a456106 — dropped the stale 5.1.0 from the update-notification header. It was hardcoded in NUKE 9885956b (March 2021) and never updated, so it named a version no Fallout consumer has run. Kept a --- UPDATE RECOMMENDED --- header rather than the bare "", since [UpdateNotification] is live on FalloutBuild and the numbered steps need context in a server-build warning.
• f7226b4 — the <PackageId> comment now points at Normalise the package-id / project-name relationship so renames stop moving published ids #582 instead of docs/rebrand-plan.md, which is being removed.

Filed:

• Expose a typed PackageId accessor on Project #589 — typed PackageId accessor on ProjectExtensions, so Install stops naming an MSBuild property in a string. Deferred out of this PR.
• Centralise Fallout's own configuration constants in one place #584 — already open, owns the wider constants centralisation (including the tool id literal in UpdateNotificationAttribute, which cannot be resolved from a csproj because it runs in a consumer build).

Separate PR incoming for removing docs/rebrand-plan.md. It is not a clean delete — five inbound references, one of them shipped to users as the NukeMigrationAnalyzer helpLinkUri — so it gets its own change rather than riding along here.