Expand JavaFX installer with complete lifecycle and platform options

Author: mearvk

installer/README.md

@@ -4,26 +4,54 @@ Cross-platform GUI installer for Windows, macOS, and Linux.
 
 ## Installation model
 
-The GUI presents the canonical **1, 2, 3** installation stages:
+The GUI presents the canonical installation stages:
 
-1. **Core** — install the US House runtime.
+1. **Core** — install the US House/JWSTF runtime.
 2. **Tools** — install software-house tools and conveniences.
-3. **Configure** — apply selected configuration and integration options.
+3. **Configure** — apply selected configuration and integrations.
+4. **Verify** — inspect the resulting installation and produce a report.
 
-The broader evidence lifecycle remains **1 Origin → 2 Custody → 3 Production → 4 Release**. The GUI's numbered installation choices are the actionable installation subset of that lifecycle.
+The broader lifecycle is **install → update → verify → remove**, while the evidence lifecycle remains **1 Origin → 2 Custody → 3 Production → 4 Release**.
+
+## GUI options
+
+The installer should expose these options before execution:
+
+- Install / repair
+- Update
+- Verify
+- Remove installed artifacts
+- `/user` professional/user-scoped profile
+- `/deck` enterprise/machine-wide profile
+- Linux / Windows / macOS target
+- Distribution-managed or manually managed Tomcat on Linux
+- Apache integration where available
+- Java 21 prerequisite handling
+- JWSTF application, configuration, state, and log paths
+- Start/stop service after operation
+- Dry-run / review changes
+- Export an installation report
+
+The GUI must never silently delete repository source. Removal concerns installed/generated artifacts and uses the platform's normal uninstall mechanism where available.
 
 ## Integrations
 
-The UI provides Microsoft and Apple integration choices. Actual privileged changes are intentionally delegated to the platform-specific launchers under `cmd/us-house/windows`, `cmd/us-house/macos`, and the corresponding Linux implementation. This keeps the JavaFX GUI platform-neutral.
+The UI provides Microsoft and Apple integration choices. Actual privileged changes are delegated to platform-specific launchers under `cmd/us-house/windows`, `cmd/us-house/macos`, and the corresponding Linux implementation. This keeps the JavaFX GUI platform-neutral.
+
+## Standard paths
+
+The installer reads `config/preferred-install-paths.json`. `/user` and `/deck` are logical deployment profiles; they resolve to native OS locations rather than replacing OS conventions.
+
+For Linux, distribution-managed Tomcat retains its package-managed `/etc/tomcat10` and `/var/lib/tomcat10` layout. A deliberate manual Tomcat installation may use `/opt/tomcat`; these management models must not be mixed.
 
-## Build
+## Native packaging
 
-The installer requires a JavaFX-capable JDK/toolchain. The repository currently does not contain a JavaFX build descriptor, so the Java source is the GUI implementation layer; a Maven or Gradle JavaFX packaging project should be added before producing signed native installers.
+The repository should build the GUI as a Java application/JAR and use `jpackage` on the target OS for native installation artifacts:
 
-Recommended native targets are:
+- **Windows:** `.exe` and/or `.msi`
+- **macOS:** `.dmg` and/or `.pkg`
+- **Linux:** `.deb` and/or `.rpm`, plus an application image where useful
 
-- Windows: `.msi` or `.exe`
-- macOS: `.dmg` or `.pkg`
-- Linux: `.deb` and/or `.rpm`
+Native installers should be generated on their corresponding operating system, signed where appropriate, checksummed, and published as release artifacts. The repository should not contain fabricated platform binaries.
 
-Native packaging should use platform-appropriate signing and should verify the resulting artifact before release.
+The existing source is the GUI implementation layer; a JavaFX Maven or Gradle packaging project should be added/used by the release build before producing native installers.