Record follow up launcher review findings

docs/roadmap/remediation.md

@@ -224,3 +224,57 @@ result can appear valid for the wrong candidate.
 or clear `CDPATH` for those two directory changes. The number of lookups is
 already fixed; the change corrects which directory is selected. Verify the
 copyable recipe with a conflicting `CDPATH` entry.
+
+## Follow-up review after remediation
+
+Reviewed all six implementation stages at `9797f43`. The focused launcher,
+delivery, and recovery tests and the public API and dependency checks passed.
+The host discovery work remains bounded to a fixed number of calls per
+invocation, and recovery replacement relocation now visits each directive
+once. No additional scaling issue was identified.
+
+### Stages 1, 2, and 6: Invoke the exact registered Go tool
+
+**Evidence:** The [multi-module launcher](../../examples/multi-module/release.sh)
+and both consumer Woodpecker templates
+([single-module](../../examples/woodpecker/tag-delivery.yml),
+[multi-module](../../examples/multi-module/woodpecker.yml)) register the
+full ReleaseKit package path, but invoke the short name `releasekit`. The
+[adoption launcher](../consumers/adoption.md#select-the-go-host-target) and
+[multi-module smoke recipe](../../examples/multi-module/README.md) also use
+the short name. Go allows two different package paths with the same final
+component in the tool declarations. With a second local tool ending in
+`/cmd/releasekit`, the maintained launcher and both extracted CI command
+blocks prepared the intended module, then exited with an ambiguous-tool
+error. Changing only the invocation to the full package path ran the
+intended host-native tool in all three probes. Recovery already invokes
+the full path and is unaffected.
+
+**Fix:** Invoke the same full package path used for registration in the
+maintained launchers, templates, and copyable consumer recipes. Preserve
+the selected module version, arguments, and exit status. Extend an
+existing launcher fixture with a second registered tool of the same short
+name and verify that only the intended tool runs.
+
+### Stage 3: Build the manual retry tool only from a clean tagged checkout
+
+**Evidence:** The [manual retry block](../release.md) runs `git fetch` and
+`git checkout --detach` before the subshell that enables `set -e`. A
+failed checkout can therefore be followed by dependency preparation, a
+build, and execution from the wrong source. A successful checkout can
+also carry local edits forward. Both cases were reproduced with the
+documented block in disposable Git repositories and a local bare remote:
+a checkout refused because of conflicting edits still ran a fixture
+built from the edited source, and checking out the already selected tag
+succeeded while retaining and executing a local edit. The fixture exited
+successfully in both cases. ReleaseKit's normal delivery guards check
+the tagged checkout after the executable has already been built and
+started; they do not protect this bootstrap.
+
+**Fix:** Include the fetch and checkout in the fail-fast subshell. Resolve
+the literal tag to its commit and require a clean checkout before
+downloading dependencies or building the CLI, as the
+[source delivery template](../../examples/woodpecker/releasekit-source-delivery.yml)
+does. Preserve the scoped host target, dependency download before the
+offline build, and the existing retry arguments. Verify that checkout
+failure and carried-over edits both stop before the first Go command.