The following discussions from !3892 should be addressed: - [ ] @phikai started a [discussion](https://gitlab.com/gitlab-org/cli/-/merge_requests/3892#note_3831356299): > Non-blocking, but worth recording: the shared `InstalledBinary` also tightens duo. `Installed` now requires a non-empty `duo_cli_binary_version` for a managed install, where `main` only stat-ed the path. With the managed binary on disk and no recorded version, I get `installed=false` here against `installed=true` on `main`, so the footer flips to "not installed yet" plus the three install steps. > > That is the more accurate answer, since `EnsureInstalled` would re-download in that state, and `binarymgr` covers it in "managed binary without a recorded version is not installed". Two follow-ups: > > - The duo suite only exercises the custom-path branch (`TestBinaryStatus` sets `GLAB_DUO_CLI_BINARY_PATH`), so nothing in `internal/commands/duo/cli` pins the managed-path behavior. A managed-path case next to the existing "unknown version" one would lock it in. > - The description says duo just reuses the moved check. Calling out the footer change would help whoever bisects it later. - [ ] @phikai started a [discussion](https://gitlab.com/gitlab-org/cli/-/merge_requests/3892#note_3831356502): > Optional: `InstallStatus.Version` now carries display text. `"unknown version"` is what the duo footer prints, and it means a consumer cannot tell "no version recorded" from a real version string. Orbit does not read `Version` at all. > > Returning `""` and keeping the fallback in `AppendBinaryStatusFooter` would keep `binarymgr` free of user-facing strings. It also removes the mild oddity in the new tests, where `InstallStatus{Version: "unknown version", Installed: true}` is the expected value for a binary whose version is genuinely unknown. - [ ] @phikai started a [discussion](https://gitlab.com/gitlab-org/cli/-/merge_requests/3892#note_3831435650): > Version 3 addresses everything I raised, and I verified the behavior rather than just the diff: help renders instead of erroring with a stale managed binary in CI, no consent prompt or update check on the help path, and the duo footer matches `main` again when a config key cannot be read. Docs regenerate with no drift. > > The two threads I left today are not blocking. Would be good to see them in a follow-up: > > - a managed-path case in the duo `TestBinaryStatus` set, so nothing in `internal/commands/duo/cli` can silently flip the footer > - moving the `unknown version` fallback out of `binarymgr` and into the footer, ideally with wording that fits custom-path users, who are now the main audience for that string > > Approving from my side. <!-- implementation plan added during 2026-09 backlog triage --> ## Implementation plan > **Note:** This plan was drafted during an AI-assisted triage of the backlog and has not been validated by a maintainer. Treat it as a starting point: file paths, line numbers, and the approach may need adjusting. Two independent changes from !3892. They can land together or separately. 1. **Return an empty version from `binarymgr`.** In `internal/binarymgr/runner.go`, delete the `if status.Version == "" { status.Version = "unknown version" }` block at lines 241-243 so `InstallStatus.Version` carries only a real recorded version. `internal/commands/orbit/orbit.go:134` reads only `Path` and `Installed`, so it needs no change. 2. **Move the display fallback into the duo footer.** In `internal/commands/duo/cli/cli.go`, handle the empty version where the footer is rendered (`binaryStatus` at line 129, or the installed branch at lines 109-113). Because a managed binary with no recorded version now reports `Installed: false`, the only way to reach this line is a custom `duo_cli_binary_path`, where glab never records a version. Print `Installed: <path>` with no parenthetical in that case, rather than carrying "unknown version" forward; if the maintainer prefers to keep a parenthetical, "version not recorded" reads better than "unknown version" for a user-supplied binary. 3. **Update the `binarymgr` expectations.** In `internal/binarymgr/runner_test.go`, change the two assertions that expect `Version: "unknown version"` (lines 144 and 190) to expect `Version: ""`. 4. **Add a managed-path case to the duo suite.** In `internal/commands/duo/cli/cli_test.go`, add a subtest to `TestBinaryStatus` (line 278) that does not set `GLAB_DUO_CLI_BINARY_PATH`. Follow `managedSetup` in `internal/binarymgr/runner_test.go:116`: `t.Setenv("GLAB_CONFIG_DIR", t.TempDir())`, resolve `binarymgr.ManagedBinaryPath(Spec())`, write an executable file there, set `duo_cli_binary_version` on a blank config, and assert `installed` is true with that version. Add a sibling case with the version key unset that asserts `installed` is false, which is the footer flip !3892 introduced. 5. **Cover the footer wording.** Extend `internal/commands/duo/cli/cli_test.go` next to `TestAppendBinaryStatusFooter_ShowsSetupStepsWhenNotInstalled` (line 316) with an installed case that asserts the exact line the footer prints for a custom path with no recorded version. 6. **Verify.** `go test ./internal/binarymgr/... ./internal/commands/duo/... ./internal/commands/orbit/...`. No cobra `Short`, `Long`, `Example`, or flag text changes, so `make gen-docs` is not needed.