A blank workspace can resemble lost tabs and logins even when the original material still exists. The same executable may have selected another user-data location. Northstar's path correction made identifying the chosen store more important than moving files first.
Installation and data folders have different roles
The executable location, project program/notebook folders and user store containing sessions and tabs are different resources. Runtime-paths reads explicitly configured absolute folders and uses data-relative defaults only for missing settings. Malformed configuration raises an error rather than silently choosing fresh folders.
That allows portability without imposing the maker's drive layout while retaining existing program locations. The source connector also changes developmentSource alone. Moving source must not replace program IDs and existing journals with a new empty list. Naming the role of each path is the first step toward preserving continuity.
A shortcut-only correction had a limited scope
The 0.1.210 record explains that Explorer and the earlier launch environment resolved AppData differently. An explicit existing userData restored the workspace, and shortcut metadata was pinned. Direct executable launch and fresh-install automatic selection were not fixed by that step.
Calling the shortcut correction a complete product fix would leave another entry point able to reproduce the issue. The later 0.1.211 app reads a location record during startup. Local configuration recovery and a changed application selection rule therefore remain different results. One normal relaunch cannot establish identical selection across every launch route.
A location record does not copy authentication material
Startup assigns the resolved root to both userData and sessionData. The location record stores root, directory identity, owner and initialization state, not website cookies or manuscripts. Selecting an existing store differs from copying an authentication database into another profile.
Reading the pin checks actual directory identity and required storage. Missing/replaced roots or ambiguous candidates stop instead of silently continuing with an empty profile. Explicit development/QA paths use another branch that does not change the normal pin. Filesystem identity supports store selection; it does not prove a website account remains authenticated.
Check argument-free launch and updating separately
The actual 0.1.211 report checks argument-free desktop, Start-menu and direct-EXE launches plus NSIS update/reinstallation against the same root. Thirteen tabs and three projects receive identity/relationship checks, with authentication and manuscript fingerprints recorded separately. One count does not stand in for all preservation.
The evidence concerns the same PC and Windows user under named launch routes. It does not solve other PCs, changed OS accounts or provider expiry. Selected handles numbered zero at this goal's start; an earlier audit's seven handles cannot be claimed preserved here. Accurate comparison begins with the actual before state.
A location error is not a signal to invent new data
Starting normally with an empty screen after failing to locate the store can make retained work appear lost. An explicit stop and location check preserve the meaning of continuity. The error does not authorize automatic new logins or projects.
This article compares source and historical reports without changing the current app location or profiles. The shared preservation comparator reads synthetic aliases and digests and implements no root resolver. Beyond installability, an update should explain which existing work it continues opening. A path is a configuration detail with direct consequences for the user's accumulated time and work.