Cherry-pick the Fallout.GlobalTool package id onto 10.4

CONTRIBUTING.md

@@ -44,7 +44,7 @@ Fallout welcomes contributions. As a community, we want to help each other, prov
 - Branch from `main` (the base for all PRs). Name your branch `feature/<slug>`, `bugfix/<slug>`, or `chore/<slug>`.
 - Make sure your employer allows the contribution.
 - Read [AGENTS.md](AGENTS.md) for the codebase conventions — package versions go in `Directory.Packages.props`, tests live next to code, no per-file license headers (the `LICENSE` file at the root is the single source of truth). (AGENTS.md is the canonical brief for both human contributors and AI tools; GitHub Copilot reads it natively and `CLAUDE.md` points to it.)
-- The bootstrappers are now thin: `./build.ps1` / `./build.sh` provision .NET if needed, then run `dotnet tool restore` + `dotnet fallout "$@"`. The `Fallout.GlobalTools` version is pinned in `.config/dotnet-tools.json`.
+- The bootstrappers are now thin: `./build.ps1` / `./build.sh` provision .NET if needed, then run `dotnet tool restore` + `dotnet fallout "$@"`. The `Fallout.GlobalTool` version is pinned in `.config/dotnet-tools.json`.
 - Run `./build.ps1 Test` (or `./build.sh Test`, or directly `dotnet fallout Test` once your tools are restored) locally first.
 
 ### When writing the PR

README.md

@@ -52,16 +52,16 @@ fallout-migrate
 ## Install
 
 ```sh
-dotnet tool install -g Fallout.GlobalTools
+dotnet tool install -g Fallout.GlobalTool
 ```
 
 The CLI installs as `fallout`. Verify with `fallout --help`.
 
 > [!NOTE]
-> **Upgrading from `Fallout.GlobalTool`?** The dotnet-tool package is now `Fallout.GlobalTools` — same `fallout` command. Uninstall the old one first so you don't end up with two tools claiming the same command:
+> **Coming from NUKE's `10.x` tool?** Nothing to do — `Fallout.GlobalTool` is the same package id you already have pinned, so `dotnet tool update` just works. The only exception is the short-lived `Fallout.GlobalTools` (plural) id: if you installed `10.4.0-rc.4` from it, uninstall it and reinstall from `Fallout.GlobalTool` so you don't have two tools claiming the `fallout` command.
 >
 > ```sh
-> dotnet tool uninstall -g Fallout.GlobalTool
+> dotnet tool uninstall -g Fallout.GlobalTools
 > ```
 
 For per-repo manifest pinning (`.config/dotnet-tools.json`), project setup, and shell completion, see the [Installation guide on docs.fallout.build](https://docs.fallout.build/getting-started/installation).

build/Build.cs

@@ -283,8 +283,13 @@ IEnumerable<AbsolutePath> NuGetPackageFiles
         .DependsOn<IPack>()
         .Executes(() =>
         {
-            SuppressErrors(() => DotNet($"tool uninstall -g {Solution.Fallout_Cli.Name}"), logWarning: false);
-            DotNet($"tool install -g {Solution.Fallout_Cli.Name} --add-source {OutputDirectory} --version {DefaultDeploymentVersion}");
+            // Read the id off the csproj rather than hardcoding it: the tool's PackageId is
+            // deliberately decoupled from its project/assembly name (Fallout.Cli packs as
+            // Fallout.GlobalTool), so Solution.Fallout_Cli.Name would install the wrong package.
+            var packageId = Solution.Fallout_Cli.GetProperty("PackageId");
+
+            SuppressErrors(() => DotNet($"tool uninstall -g {packageId}"), logWarning: false);
+            DotNet($"tool install -g {packageId} --add-source {OutputDirectory} --version {DefaultDeploymentVersion}");
         });
 
     T From<T>()

docs/01-getting-started/01-installation.md

@@ -6,11 +6,11 @@ Before you can set up a build project, you need to install Fallout's dedicated [
 
 ```powershell
 # terminal-command
-dotnet tool install Fallout.GlobalTools --global
+dotnet tool install Fallout.GlobalTool --global
 ```
 
 :::tip
-For repos that already have a `.config/dotnet-tools.json` manifest with `Fallout.GlobalTools` pinned (this is what `fallout :setup` creates), you can skip the global install and run `dotnet tool restore` instead — the local manifest version then takes precedence.
+For repos that already have a `.config/dotnet-tools.json` manifest with `Fallout.GlobalTool` pinned (this is what `fallout :setup` creates), you can skip the global install and run `dotnet tool restore` instead — the local manifest version then takes precedence.
 :::
 
 From now on, you can use the global tool to:

docs/01-getting-started/02-setup.md

@@ -34,7 +34,7 @@ The setup will create a number of files in your repository and – if you've cho
 ```bash
 <root-directory>
 ├── .config
-│   └── dotnet-tools.json           # Local tool manifest pinning Fallout.GlobalTools
+│   └── dotnet-tools.json           # Local tool manifest pinning Fallout.GlobalTool
 │
 ├── .fallout                        # Root directory marker
 │   ├── build.schema.json           # Build schema file
@@ -51,7 +51,7 @@ The setup will create a number of files in your repository and – if you've cho
 ```
 
 :::note
-The two thin bootstrappers (`build.ps1` and `build.sh`) provision the .NET SDK locally when it's not on `PATH`, then run `dotnet tool restore` and `dotnet fallout "$@"`. They're optional once you have a global `dotnet` install and have run `dotnet tool restore` at least once — but they're the safest way to run the build in CI and on a freshly-cloned machine. The `.config/dotnet-tools.json` manifest pins the exact `Fallout.GlobalTools` version your build expects.
+The two thin bootstrappers (`build.ps1` and `build.sh`) provision the .NET SDK locally when it's not on `PATH`, then run `dotnet tool restore` and `dotnet fallout "$@"`. They're optional once you have a global `dotnet` install and have run `dotnet tool restore` at least once — but they're the safest way to run the build in CI and on a freshly-cloned machine. The `.config/dotnet-tools.json` manifest pins the exact `Fallout.GlobalTool` version your build expects.
 :::
 
 ## Project Structure
@@ -64,7 +64,7 @@ While you can enjoy writing most build-relevant logic inside your build console
 ```powershell
 <root-directory>
 ├── .config
-│   └── dotnet-tools.json    # Local tool manifest (Fallout.GlobalTools pin)
+│   └── dotnet-tools.json    # Local tool manifest (Fallout.GlobalTool pin)
 │
 ├── .fallout
 │   ├── parameters.json      # Parameters files

docs/01-getting-started/03-execution.md

@@ -34,7 +34,7 @@ fallout [arguments]
 </Tabs>
 
 :::info
-The bootstrappers are thin: they provision the .NET SDK if it isn't already installed, run `dotnet tool restore` (to pin the `Fallout.GlobalTools` version from `.config/dotnet-tools.json`), then forward to `dotnet fallout`. Once `dotnet` is on your `PATH` and tools are restored, `fallout [arguments]` and `./build.sh [arguments]` do the same thing.
+The bootstrappers are thin: they provision the .NET SDK if it isn't already installed, run `dotnet tool restore` (to pin the `Fallout.GlobalTool` version from `.config/dotnet-tools.json`), then forward to `dotnet fallout`. Once `dotnet` is on your `PATH` and tools are restored, `fallout [arguments]` and `./build.sh [arguments]` do the same thing.
 :::
 
 :::info

docs/05-cicd/github-actions.md

@@ -98,7 +98,7 @@ jobs:
 ```
 
 :::info
-The generated workflow uses `actions/setup-dotnet` to install the .NET SDK on the runner, then `dotnet tool restore` to install the `Fallout.GlobalTools` version pinned in `.config/dotnet-tools.json`, then `dotnet fallout <targets>` to run your build. Your repository needs a `.config/dotnet-tools.json` manifest with `Fallout.GlobalTools` pinned — `fallout :setup` creates one automatically.
+The generated workflow uses `actions/setup-dotnet` to install the .NET SDK on the runner, then `dotnet tool restore` to install the `Fallout.GlobalTool` version pinned in `.config/dotnet-tools.json`, then `dotnet fallout <targets>` to run your build. Your repository needs a `.config/dotnet-tools.json` manifest with `Fallout.GlobalTool` pinned — `fallout :setup` creates one automatically.
 :::
 
 </details>

docs/introduction.md

@@ -45,7 +45,7 @@ Get a feeling how your Cake scripts would look like in Fallout.
 
 ```powershell
 # terminal-command
-dotnet tool install Fallout.GlobalTools --global
+dotnet tool install Fallout.GlobalTool --global
 ```
 
 **2. Go to a repository built with Cake.**

docs/rebrand-plan.md

@@ -45,7 +45,7 @@ This is locked by the bridge-package design — `[TypeForwardedTo]` requires the
 | `Nuke.Common.Utilities` (+ `.Collections`, `.Net`) | `Fallout.Common.Utilities` | |
 | `Nuke.Common.ValueInjection` | `Fallout.Common.ValueInjection` | |
 | `Nuke.Components` | `Fallout.Components` | |
-| `Nuke.GlobalTool` (+ `.Rewriting.Cake`) | `Fallout.Cli` | Project/namespace/assembly is `Fallout.Cli`. The **published package id is `Fallout.GlobalTools`** (`dotnet tool install Fallout.GlobalTools`) — decoupled from the assembly name on purpose. Command name stays `fallout`. |
+| `Nuke.GlobalTool` (+ `.Rewriting.Cake`) | `Fallout.Cli` | Project/namespace/assembly is `Fallout.Cli`. The **published package id stays `Fallout.GlobalTool`** (`dotnet tool install Fallout.GlobalTool`) — deliberately decoupled from the assembly name and deliberately *not* renamed, so the existing `10.x` install base never has to migrate. Command name stays `fallout`. |
 | `Nuke.MSBuildTasks` | `Fallout.MSBuildTasks` | |
 | `Nuke.SourceGenerators` | `Fallout.SourceGenerators` | |
 | `Nuke.Utilities.Text.Json` | `Fallout.Utilities.Text.Json` | |

src/Fallout.Build/Execution/Extensions/UpdateNotificationAttribute.cs

@@ -33,9 +33,9 @@ private static void Notify()
         Host.Warning(
             new[]
             {
-                "--- UPDATE RECOMMENDED FROM 5.1.0 ---",
+                "--- UPDATE RECOMMENDED ---",
                 "1. Update your global tool",
-                "   dotnet tool update Fallout.GlobalTools -g",
+                "   dotnet tool update Fallout.GlobalTool -g",
                 "2. Update your build",
                 "   fallout :update",
                 "3. Confirm on update for configuration file and build scripts",

src/Fallout.Cli/BuildScaffolder.cs

@@ -57,10 +57,10 @@ public void WriteBuildScripts(
                     })),
             platformFamily: PlatformFamily.Windows);
 
-        // .config/dotnet-tools.json pins Fallout.GlobalTools as a local tool so the thin shims
+        // .config/dotnet-tools.json pins Fallout.GlobalTool as a local tool so the thin shims
         // (build.sh / build.ps1) can `dotnet tool restore` and `dotnet fallout` deterministically.
         // Skip if the consumer already has a manifest — they may have other tools pinned and we
-        // don't want to clobber. They can add the `fallout.globaltools` entry manually.
+        // don't want to clobber. They can add the `fallout.globaltool` entry manually.
         var toolManifest = rootDirectory / ".config" / "dotnet-tools.json";
         if (!toolManifest.FileExists())
         {

src/Fallout.Cli/Fallout.Cli.csproj

@@ -6,9 +6,12 @@
     <RollForward>LatestMajor</RollForward>
     <PackAsTool>true</PackAsTool>
     <ToolCommandName>fallout</ToolCommandName>
-    <!-- Published package id. Decoupled from the assembly/namespace (Fallout.Cli) on purpose:
-         the install name users type is Fallout.GlobalTools; the command stays `fallout`. -->
-    <PackageId>Fallout.GlobalTools</PackageId>
+    <!-- Published package id. Decoupled from the assembly/namespace (Fallout.Cli) on purpose, and
+         deliberately kept as the NUKE-era `Fallout.GlobalTool` (singular): it is the id the whole
+         10.2.x/10.3.x install base already has pinned, so continuing to publish under it means no
+         consumer ever has to migrate and no id ever has to be unlisted. The command stays `fallout`.
+         Do not rename this to match the assembly — see Fallout-build/Fallout#582. -->
+    <PackageId>Fallout.GlobalTool</PackageId>
   </PropertyGroup>
 
   <ItemGroup>

src/Fallout.Cli/templates/dotnet-tools.json

@@ -2,7 +2,7 @@
   "version": 1,
   "isRoot": true,
   "tools": {
-    "fallout.globaltools": {
+    "fallout.globaltool": {
       "version": "_FALLOUT_CLI_VERSION_",
       "commands": [
         "fallout"