feat(desktop): install the t3 command from Settings#16683

🟡 Medium app/DesktopCliCommand.ts:178

On Windows, uninstall removes binDirectory from the user's PATH even when the user added it before installing T3, deleting user-managed configuration and potentially hiding other commands in that directory. Since install leaves an existing entry untouched, track whether T3 added the entry and remove it only when that ownership is recorded.

No longer relevant as of 47a4932f6f2007f74e6a538a199d76b5f2707938

🟠 High app/DesktopCliCommand.ts:98

After Windows Install or Remove, existing shells keep the old PATH, so terminals launched from them still cannot find t3 even though state.onPath reports true. writeUserPath updates the registry without broadcasting WM_SETTINGCHANGE with lParam = "Environment"; broadcast it after each successful registry edit so existing processes pick up the change.

No longer relevant as of b705c1914d8110e4cd12cea2a9643fbf576245fe

🟡 Medium app/DesktopCliCommand.ts:182

If writing ownedPathMarker fails, install leaves binDirectory in the user PATH without recording ownership, so installedAt reports no installation and uninstall cannot remove the entry; retries also skip recording it because the PATH entry already exists. Record ownership before updating the PATH so a marker-write failure leaves the PATH unchanged.

🟠 High app/DesktopCliCommand.ts:190

Installing after the T3 home changes leaves the existing t3 link pointing to the old launcher, so terminal commands keep using the old app or fail if it was removed even though Install reports success. The early return at installedAt skips updating that owned link; repoint it to the current launcher before returning.

No longer relevant as of b705c1914d8110e4cd12cea2a9643fbf576245fe

🟡 Medium settings/settingsSearch.ts:511

Desktop builds without CLI support still show the “t3 command” search result, which leads users to a setting that CliCommandSettingsRow does not render. desktopOnly checks only isElectron, and filterAvailableSettingsSearchItems does not check CLI availability; gate discovery on the same bridge-method and getState().supported checks as the row.

🟠 High app/DesktopCliCommand.ts:49

Installing or removing t3 converts an expandable user Path to REG_SZ, so entries such as %USERPROFILE%\tools stop expanding and existing tools disappear from PATH in new processes. The read preserves unexpanded tokens, but Environment.SetEnvironmentVariable writes the value as REG_SZ; update the registry value while retaining its original kind and notifying processes of the change.

No longer relevant as of b705c1914d8110e4cd12cea2a9643fbf576245fe

📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win

Give DesktopCliCommandError structured attributes and a cause.

The error has only a free-form message. fail is a mapper that only wraps the constructor. Each Effect.mapError(() => fail(...)) call drops the underlying PowerShell or filesystem failure. The guidelines require an operation or stage attribute and the resource path. A wrapping error must keep the immediate underlying error as cause. A helper that only does new SomeError({ ...args }) is not allowed.

Fix:

• Add operation (for example "readPath" | "writePath" | "link" | "remove") and path fields.
• Add an optional cause field.
• Build the message from those fields.
• Construct the error inline at each failure site, and pass the original error as cause.

As per coding guidelines: "Failures are Schema.TaggedError classes with structured attributes" and "An error that wraps a failure keeps the immediate underlying error as cause".

Also applies to: 88-88

Source: Coding guidelines

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

On Windows, Install has no effect when the user already added the launcher folder to PATH.

Trigger: the user PATH already contains binDirectory. In that case Install skips both the PATH write and the ownedPathMarker write. state then returns installedPath: null, because installedAt requires the marker. The test at apps/desktop/src/app/DesktopCliCommand.test.ts Line 227 confirms this state.

Result: the row keeps showing "Install". Each click succeeds without an error and changes nothing.

Fix: report the existing entry as installed, without claiming ownership. One option is to return Option.some(launcher) from installedAt when the entry is present. Then make Remove act only when the marker exists, and tell the user that a PATH entry they added stays in place. A second option is to show a distinct state that says t3 is already on PATH.