Cleanup

.github/workflows/release.yml

@@ -595,30 +595,11 @@ jobs:
 
               match = matches[-1]
               numbers = [int(part) for part in match.group("core").split(".")]
-              prerelease = match.group("pre") or ""
-              prerelease_parts = prerelease.split(".") if prerelease else []
-              prerelease_build = None
-
-              if prerelease.isdigit():
-                  prerelease_build = int(prerelease)
-              elif prerelease_parts:
-                  # Legacy PR/manual tags used base-pr.<number>.<run> and
-                  # base-manual.<run>. Sort them by the trailing run number so
-                  # current review builds are not treated as older than stable
-                  # base releases only because they carry a non-numeric label.
-                  if prerelease_parts[0] in {"main", "manual"} and prerelease_parts[-1].isdigit():
-                      prerelease_build = int(prerelease_parts[-1])
-                  elif (
-                      prerelease_parts[0] == "pr"
-                      and len(prerelease_parts) >= 3
-                      and prerelease_parts[-1].isdigit()
-                  ):
-                      prerelease_build = int(prerelease_parts[-1])
 
               while len(numbers) < 3:
                   numbers.append(0)
               if len(numbers) < 4:
-                  numbers.append(prerelease_build or 0)
+                  numbers.append(0)
 
               return tuple(numbers[:4])
 

.gitignore

@@ -9,6 +9,7 @@
 *.user
 *.userosscache
 *.sln.docstates
+.quasar-install-dir
 
 # User-specific files (MonoDevelop/Xamarin Studio)
 *.userprefs

Docs/BuildingAndDevelopment.md

@@ -22,7 +22,7 @@ utilities. For the runtime design see [Architecture](QuasarArchitecture.md).
   Quasar, Quasar.Agent, and companion plugins.
 - Quasar UI plugins
   Optional UI extensions are discovered through QuasarHub and installed into the
-  Quasar data directory at runtime. Entity Viewer now lives in the external
+  Quasar install directory at runtime. Entity Viewer now lives in the external
   `CometWorks/viewer` repository and is installed as a Quasar UI plugin instead
   of being staged from this repository during the core Quasar build.
 
@@ -119,20 +119,34 @@ For local web UI development, run the worker directly:
 dotnet run --project Quasar/Quasar.csproj
 ```
 
-This uses the development launch profile and the normal Quasar data directory
-(`~/.config/Quasar` on Linux unless `QUASAR_DATA_DIR` is set). The Bootstrap
+This uses the development launch profile. Without `QUASAR_INSTALL_DIR`, the
+direct worker uses its app base directory as the install root. The Bootstrap
 launcher and release/update cutover paths are covered by the packaged installer
 and release workflows rather than a local deploy helper.
 
+To run the UI worker from Rider against an installed service/deployed tree,
+write that root path into `.quasar-install-dir` at the repository root. The file
+is ignored by git and is read through `QUASAR_INSTALL_DIR_FILE` from the worker
+launch profile:
+
+```bash
+printf '%s\n' "$HOME/.local/share/Quasar" > .quasar-install-dir
+```
+
+`QUASAR_INSTALL_DIR` still works and wins when set directly. The worker launch
+profile deliberately does not set `applicationUrl`, so host/port come from that
+install root's `appsettings.json`. Packaged assets and helper scripts are also
+probed from the same install root.
+
 Generate synthetic analytics data for local testing:
 
 ```bash
 python3 scripts/generate-analytics-data.py
 ```
 
 Optional `--server <name>` to target one server, `--days <n>`, `--seed <n>`,
-`--raw-hours <hours>`, `--raw-interval <seconds>`. Uses `QUASAR_DATA_DIR`
-automatically if set, otherwise defaults to the local Quasar data root.
+`--raw-hours <hours>`, `--raw-interval <seconds>`. Uses `QUASAR_INSTALL_DIR`
+automatically if set, otherwise defaults to the local Quasar install root.
 
 When refreshing the local graphify graph, prune generic framework plumbing after
 `.graphify_extract.json` is produced and before graph build/report generation:

Docs/Configuration.md

@@ -71,26 +71,18 @@ Magnetar log file. Auto-refresh and the Refresh button are active only for
 ## Where configuration is read from
 
 Both the **Bootstrap launcher** (`Quasar`/`Quasar.exe`) and the replaceable **web
-worker** read JSON config from these locations, later ones overriding earlier:
-
-1. The install directory `appsettings.json` (next to the executable). Auto-updates
-   preserve this file during Bootstrap self-updates. UI-worker activation updates
-   it from the staged, resolved `appsettings.json` so Bootstrap and the managed
-   worker keep the same base settings.
-2. The Quasar **data directory** `appsettings.json`. Bootstrap uses the install
-   root as the default data directory, so this is normally the same file as item
-   1. Set `QUASAR_DATA_DIR` (or `--data-dir <dir>` on Linux installs) to keep
-   persistent local overrides in a separate directory.
-
-When Bootstrap starts without a custom `QUASAR_DATA_DIR`, it migrates legacy
-default data roots (`~/.config/Quasar` on Linux/macOS,
-`%APPDATA%\Quasar` on Windows) into the install root.
+worker** read JSON config from the Quasar install root. Auto-updates preserve
+`appsettings.json` during Bootstrap self-updates, and UI-worker activation
+updates it from the staged, resolved `appsettings.json` so Bootstrap and the
+managed worker keep the same base settings. Set `QUASAR_INSTALL_DIR`, or create
+the ignored `.quasar-install-dir` file used by the development launch profile,
+for direct worker/dev runs that need to target a deployed Quasar root.
 
 The shipped defaults are defined in [`Quasar/appsettings.json`](../Quasar/appsettings.json).
 
 During UI-worker staging, Quasar performs a three-way merge for `appsettings.json`:
-the previous release base stored under the data directory is the merge base, the
-current install-directory `appsettings.json` supplies local values, and the new
+the previous release base stored under the install root is the merge base, the
+current install-root `appsettings.json` supplies local values, and the new
 release file supplies new defaults. Clean local changes are carried into the
 staged version automatically. If both the local file and the release changed the
 same setting differently, the Updates page shows a conflict editor with
@@ -130,7 +122,7 @@ mounted network share:
 }
 ```
 
-Relative paths are resolved under the Quasar data directory. If the folder is on
+Relative paths are resolved under the Quasar install directory. If the folder is on
 a network share, make sure it is mounted before Quasar starts and that the
 Quasar service account can create, list, read, and delete files in it. Changes
 from the Backup page apply to new stored-backup operations immediately; direct
@@ -308,9 +300,13 @@ trust broad networks unless every host in that range is under your control.
 ### Development port
 
 Running the worker directly with `dotnet run --project Quasar/Quasar.csproj` uses
-[`Quasar/Properties/launchSettings.json`](../Quasar/Properties/launchSettings.json),
-which sets `applicationUrl` to `http://0.0.0.0:8080`. Change `applicationUrl` there
-to use a different port for local `dotnet run` sessions.
+[`Quasar/Properties/launchSettings.json`](../Quasar/Properties/launchSettings.json)
+only for development environment variables. It does not set `applicationUrl`, so
+the worker still reads `Quasar:Host` / `Quasar:Port` from normal configuration.
+Set those values in `QUASAR_INSTALL_DIR/appsettings.json`, or in the root named
+by `.quasar-install-dir`, when running the worker from Rider against an
+installed Quasar root. Use `QUASAR_WEB_HOST` / `QUASAR_WEB_PORT` for a one-off
+direct-worker override.
 
 ## Browser auto-open on start
 

Docs/LinuxDeploymentAndUpdates.md

@@ -73,11 +73,8 @@ review builds per PR/manual stream.
 ## First Start
 
 The default systemd user service runs Bootstrap from the extracted install root
-and sets `QUASAR_DATA_DIR` to that same directory. It also sets
-`QUASAR_SYSTEMD_SERVICE` and `QUASAR_SYSTEMD_SCOPE` so the web UI's **Shutdown
-Quasar** action can request `systemctl --user stop quasar.service` instead of
-only exiting the launcher. A machine-wide service is still available with
-`install.sh --system`.
+and sets `QUASAR_INSTALL_DIR` to that same directory. A machine-wide service is
+still available with `install.sh --system`.
 
 If Bootstrap has no usable `Updates/active-release.json` and no packaged
 `WebService/Quasar`, it downloads the latest Linux web asset from GitHub,
@@ -93,19 +90,21 @@ The downloaded archive must match the release's `SHA256SUMS` entry before it is
 extracted.
 When running as a systemd service, Bootstrap ignores a stale active-release
 pointer that targets a random external build directory. Only packaged
-`WebService/` workers, managed web releases, staged legacy workers, or explicitly
-configured `QUASAR_WEB_EXE` / `QUASAR_WEB_DLL` workers are trusted. If Bootstrap
-finds an older active pointer that still targets `Updates/Staged/<version>`, it
-migrates that release into `ManagedRuntime/WebService/<version>` before launch.
-On startup, Bootstrap also migrates a legacy default data root at
-`~/.config/Quasar` into the install root unless `QUASAR_DATA_DIR` points to a
-custom directory.
+`WebService/` workers, managed web releases, or explicitly configured
+`QUASAR_WEB_EXE` / `QUASAR_WEB_DLL` workers are trusted.
 
 Bootstrap always captures the managed web UI worker's stdout/stderr and mirrors
 it to its own console. For systemd installs, Quasar web UI warnings and errors
 therefore appear in the service journal as well as in the configured Quasar log
 files.
 
+The UI **Shutdown Quasar** action drains the web worker, preserves managed
+servers, and leaves Bootstrap running without a worker. Because Bootstrap is
+still alive and exits successfully only when the service is stopped, systemd does
+not restart the worker by itself. Run `systemctl --user restart quasar.service`
+for the default user service, or `sudo systemctl restart quasar.service` for a
+system service, to start the UI and supervisor again.
+
 ## UI Worker Updates
 
 The running Quasar UI checks GitHub releases every 15 minutes by default. The
@@ -118,9 +117,9 @@ are only queued until the operator stages the selected version. Staging requires
 a matching `SHA256SUMS` entry for the downloaded asset.
 
 Staging also resolves `appsettings.json`. Quasar uses the stored release base in
-the data directory (`$QUASAR_DATA_DIR/Updates/appsettings.base.json`) as the
-merge base, applies local values from the install directory
-(`<install-root>` by default), and writes the resolved file into the staged worker. If the merge
+the install root (`$QUASAR_INSTALL_DIR/Updates/appsettings.base.json`) as the
+merge base, applies local values from the install directory, and writes the
+resolved file into the staged worker. If the merge
 conflicts, auto-staging stops with a warning and `/settings/updates` shows a
 git-style conflict editor. Resolve and save the JSON there, or choose **Force
 release defaults** to stage the release file without local appsettings values.
@@ -224,26 +223,17 @@ tar -xzf quasar-installer-linux.tar.gz -C ~/.local/share/Quasar --strip-componen
 ```
 
 For extracted release installers, `install.sh` uses the script directory as the
-default install directory and the default Quasar data directory. Source installs
-keep using `~/.local/share/Quasar` as the default install root, with state stored
-there as well. Use `--system` with `sudo` for a machine-wide service,
-`--install-dir <dir>` to copy Quasar elsewhere, or `--data-dir <dir>` to place
-Quasar state elsewhere. The generated service sets `HOME` and `QUASAR_DATA_DIR`
-explicitly so Bootstrap and the worker agree on the update/runtime state root.
-It also records the unit name/scope in `QUASAR_SYSTEMD_SERVICE` and
-`QUASAR_SYSTEMD_SCOPE`; with those set, the UI shutdown button asks systemd to
-stop the installed unit. The
-installer enables the service but does not start or restart it unless `--start`
-is passed; start it later with `systemctl --user restart quasar.service`. When
-installing from source instead of an extracted release archive, the installer
-stamps the launcher with `VERSION`, an exact git tag, or a short commit-derived
-prerelease identity so Bootstrap update comparisons do not fall back to plain
-`1.0.0`.
-
-If a previous `/opt/quasar` system install exists, the new user-mode installer
-installs the new Bootstrap and user service first, then calls the old
-`/opt/quasar/uninstall.sh --purge` through `sudo` to stop and remove the old
-system service and files.
+install root. Source installs keep using `~/.local/share/Quasar` as the default
+install root. Use `--system` with `sudo` for a machine-wide service or
+`--install-dir <dir>` to install Quasar elsewhere. The generated service sets
+`HOME` and `QUASAR_INSTALL_DIR` explicitly so Bootstrap and the worker agree on
+the unified update/runtime state root.
+The installer enables the service but does not start or restart it unless
+`--start` is passed; start it later with
+`systemctl --user restart quasar.service`. When installing from source instead
+of an extracted release archive, the installer stamps the launcher with
+`VERSION`, an exact git tag, or a short commit-derived prerelease identity so
+Bootstrap update comparisons do not fall back to plain `1.0.0`.
 
 Raising managed server priority no longer requires granting `CAP_SYS_NICE` to
 the whole Quasar service. The installer can build and install a narrow setuid
@@ -273,11 +263,9 @@ to remove a machine-wide service.
 For the web UI host/port (including how to change the listening port, default
 `8080`) and browser auto-open behavior, see [Configuration](Configuration.md).
 
-Update defaults live in `Quasar:Updates`. Packaged defaults come from the install
-directory, and operator overrides can live in the Quasar data directory
-(`<install-root>/appsettings.json` by default for Linux systemd installs, or
-`QUASAR_DATA_DIR/appsettings.json` when overridden). The worker and Bootstrap
-both read that data-directory file on startup.
+Update defaults live in `Quasar:Updates`. Packaged defaults and operator
+overrides live in the install root (`$QUASAR_INSTALL_DIR/appsettings.json`).
+The worker and Bootstrap both read that install-root file on startup.
 
 ```json
 {
@@ -316,7 +304,7 @@ until the operator chooses a version and presses Stage.
 Quasar can check GitHub releases without a token, but hosts on shared servers,
 NAT gateways, and public cloud IP ranges can hit GitHub's unauthenticated rate
 limit. The Updates page lets an admin save a GitHub token for release checks.
-It is stored in `github-updates.json` under the Quasar data directory with the
+It is stored in `github-updates.json` under the Quasar install directory with the
 same Data Protection encryption model and owner-only Unix permissions used for
 the Steam Workshop API key.