docs: rewrite README for current windows details, reformat

README.md

@@ -24,18 +24,16 @@ The application follows a layered architecture:
 
 ### Windows Service Layer
 
-The Windows service layer implements a legitimate Windows service that receives control signals through the Windows Service Control Manager (SCM). It uses Go project's [/x/sys/](https://pkg.go.dev/golang.org/x/sys) module (for [/x/sys/windows/svc](https://pkg.go.dev/golang.org/x/sys/windows/svc)) to interface with the SCM.
+The Windows service layer implements a pseudo-Windows service that mimics the behavior of a real service, but does not actually run as a service.
 
-- In development (i.e. ran directly, or with `go run`), the service layer detects this and runs as a 'debug' service, which imitates the behavior of a real service, but does not actually run as a service.
+- This is required because tray icons are not supported by Windows services, as they run in the system space, and cannot interact with the user space.
-- The service is fully responsive to most standard commands, including Start, Stop, Pause, Continue, and Interrogate.
-
-For local development, you can run and build directly, or use `task service` to quickly install a service. `task package` provides a quick way to build and package the application using WiX.
 
 Currently, I only have a MSI installer developed for Windows. I'm considering creating a specialized CLI-based installation method for Windows, one that will match the Linux experience, but that is yet to be completed.
 
 ### Linux Service Layer
 
 The Linux service layer implements a systemd service 'notify' type service.
+
 - Note that we don't take advantage of most modern systemd features, such as `notify-reload`, `ReloadSignal=SIGHUP`, and so on.
   - This is because I use WSL2 as my primary development environment, which only has systemd v249.
 - It uses the go-systemd package to interface with systemd, enabling proper handling of startup and reload signals.
@@ -44,39 +42,40 @@ The Linux service layer implements a systemd service 'notify' type service.
 Currently, the Linux service layer is only installed via the `task service` command.
 
 Ideally, I plan to provide at least two different methods for installation:
+
 - A one-command remote bash script that will download the binary, install the systemd unit file, and start the service.
 - An internal CLI-based method that provides customized systemd unit file generation & simple management commands.
 
 ### Feature Targets
 
-- [X] Cross-platform Background Service (Linux, Windows)
+- [x] Cross-platform Background Service (Linux, Windows)
 - [ ] Windows
-    - [X] Windows Service Implementation
+  - [x] MSI-based Installer
-    - [X] MSI-based Installer
   - [ ] CLI-based Installer
   - [ ] Winget Package Publishing
 - [ ] Linux
-    - [X] `systemd` Service Implementation
+  - [x] `systemd` Service Implementation
   - [ ] CLI-based Installer
   - [ ] Script-based Installer
   - [ ] `systemd` Unit File Templating/Generation
   - [ ] Smart `journalctl` logging bypass
 - Application
   - [ ] TOML Configuration
-    - [ ] Health Checks
+  - [x] Health Checks
-    - [ ] Tray Icon, Tray Menu
+  - [x] Tray Icon
-    - [X] Structured Logging
+  - [ ] Tray Menu
+  - [x] Structured Logging
     - [ ] Configurable
     - [ ] Better library (logrus, zap, zerolog, etc.)
   - [ ] Testing
     - [ ] Unit Tests
     - [ ] Integration Tests
     - [ ] Code Coverage
-- [X] Development Tooling
+- [x] Development Tooling
-- [X] Conventional Commits
+- [x] Conventional Commits
-- [X] GitHub Actions
+- [x] GitHub Actions
-    - [X] Per-commit Artifacts
+  - [x] Per-commit Artifacts
-    - [X] MSI Packages
+  - [x] MSI Packages
   - [ ] Automatic Releases (GitHub Releases, Winget)
   - [ ] Testing, Linting, and/or Formatting
 - [ ] README Documentation Links