| 1 | # Windows application identity |
| 2 | |
| 3 | Reasonix Desktop uses the version-independent AppUserModelID |
| 4 | `io.reasonix.desktop` for its Electron windows, launcher, Go desktop process, |
| 5 | shortcuts, and notifications. Its visible notification name remains `Reasonix`. |
| 6 | This identity is separate from Reasonix Studio (`io.reasonix.studio`) and the |
| 7 | older Tauri desktop (`dev.reasonix.desktop`). Wails Studio v2.10.0 and older |
| 8 | Reasonix Desktop builds used the shared ID `Reasonix`; new Desktop builds no |
| 9 | longer claim it. |
| 10 | |
| 11 | ## Installation and upgrade |
| 12 | |
| 13 | Use `Reasonix.exe` at the installation root to open Desktop; `reasonix-cli.exe` |
| 14 | is the separate command-line entry. New installations and ZIPs extracted into |
| 15 | an empty directory contain only that GUI entry. Existing installations retain |
| 16 | `reasonix-launcher.exe` when present, with no scheduled removal, so old pins, |
| 17 | custom shortcuts and scripts continue working. Managed upgrades update both |
| 18 | names from the same verified launcher bytes. Files inside `versions/`, including |
| 19 | the Electron `app/Reasonix.exe`, remain internal components. |
| 20 | |
| 21 | Before showing any Electron window, Desktop sets its relaunch command and icon |
| 22 | to `Reasonix.exe`, falling back to the legacy launcher when necessary. New taskbar pins therefore |
| 23 | do not depend on the versioned Electron executable or its service-path environment. |
| 24 | |
| 25 | The installer applies the identity to the exact shortcuts it creates before |
| 26 | launching Desktop. It invokes the installed launcher with the maintenance |
| 27 | command `--repair-shortcuts <absolute.lnk...>`, which repairs existing, owned |
| 28 | links and exits without starting a window, a service, or a legacy migrator. |
| 29 | |
| 30 | Normal launcher and desktop startup also repair existing Reasonix-named links |
| 31 | in the installation directory, private/public desktop and Start Menu Programs |
| 32 | directories (including their Reasonix subdirectory), and the current user's |
| 33 | taskbar pin directory. A filename alone never proves |
| 34 | ownership: the resolved target must be a recognized entry inside this |
| 35 | installation. Directory junctions pointing outside it are not accepted. |
| 36 | |
| 37 | An owned shortcut with an empty ID or the old `Reasonix` ID adopts the new ID. |
| 38 | An already updated shortcut can still have a stale target or icon repaired. |
| 39 | Explicit Studio, Tauri, and unknown IDs are left unchanged, even if the link |
| 40 | is named Reasonix. Separate installations are not modified. |
| 41 | |
| 42 | Links into `versions/<version>/reasonix-desktop.exe` or |
| 43 | `versions/<version>/app/Reasonix.exe`, as well as a flat `app/Reasonix.exe`, move to the permanent |
| 44 | `Reasonix.exe` when it exists; owned links to `reasonix-launcher.exe` also move |
| 45 | to this canonical entry. With only the legacy launcher available, repair keeps |
| 46 | using that valid entry. The obsolete version can then be |
| 47 | removed without breaking that shortcut. The repair preserves launch arguments, |
| 48 | descriptions, window state, custom icons and custom working directories. Only |
| 49 | empty working directories or the migrated version's executable directory are |
| 50 | normalized to the installation root. The installer repairs existing links |
| 51 | without recreating them. An active flat Go installation keeps |
| 52 | its live Go entry point. |
| 53 | |
| 54 | Unreadable or unwritable links are left for a later launch to retry and produce |
| 55 | a warning. Repair never switches the process back to the shared old ID. Windows |
| 56 | Explorer may retain cached pins; if a repaired link still appears separately, |
| 57 | unpin it, start Desktop through its permanent launcher, and pin it again. |
| 58 | |
| 59 | ## Coexistence and rollback |
| 60 | |
| 61 | Signed update payloads and `/REASONIXSTAGE=1` still contain |
| 62 | `reasonix-launcher.exe`: already installed update helpers require this name. |
| 63 | The installed layout is selected separately. An old helper can upgrade directly |
| 64 | and may publish both entry names. A new helper preserves an existing legacy entry |
| 65 | but does not create one in a canonical-only installation. `current.json` schema 1, |
| 66 | `versioned-v1` and the signed payload schema are unchanged. |
| 67 | |
| 68 | Extract portable ZIPs into a new directory, or use in-app updates. Manually |
| 69 | overlaying a ZIP leaves old files in place and does not provide transactional |
| 70 | installation; a remaining legacy launcher can still have its previous bytes |
| 71 | until the next managed update. Do not delete it to save space if shortcuts or |
| 72 | scripts may still reference it. A damaged `current.json` requires repair with |
| 73 | a complete installer; do not point shortcuts at a retained old version. |
| 74 | |
| 75 | Upgrades deliver the launcher, Electron shell, and Go binaries together through |
| 76 | the existing release-unit mechanism. A rollback must restore the complete old |
| 77 | release. An old launcher or desktop can restore the old shortcut ID; a later |
| 78 | complete upgrade repairs owned links again. Mixing binaries from different |
| 79 | releases is not an identity compatibility guarantee. |
| 80 | |
| 81 | The old `Reasonix` notification registration and notification history are not |
| 82 | deleted or migrated: an installed Studio version may still own them. New |
| 83 | Desktop notifications use their own registration. Windows notification |
| 84 | preferences associated with the old identity are not copied to the new one. |
| 85 | |
| 86 | Studio's own Electron runtime and notification identity alignment is a separate |
| 87 | follow-up. Desktop does not change Studio files, upgrade Studio, or uninstall it. |
| 88 | |
| 89 | ## Verification before merging |
| 90 | |
| 91 | Run the Windows-native application identity, launcher, and notification tests, |
| 92 | Electron type checking and tests, and the installer packaging checks. Source |
| 93 | and mock tests do not establish Explorer's final grouping behavior. |
| 94 | |
| 95 | On Windows 11, test the candidate alongside both Studio v2.10.0 and the current |
| 96 | Studio release. Use separate test installations and data homes. Check fresh |
| 97 | installation, upgrade of existing pins, both launch orders, pin/unpin, restart |
| 98 | from each pin, minimize/restore, independent notification attribution, and |
| 99 | launch after deleting the obsolete Desktop version. Each product must keep |
| 100 | its own taskbar group and launch the correct application. Record the tested |
| 101 | builds and whether installer and portable distributions were exercised. |
| 102 |