# Health Dashboard and Backup Operations Hardening

Use when the Health dashboard must survive reboot, the encrypted weekly backup fails, or HealthManager code/docs must be published safely.

## Reboot-safe dashboard service

- Serve the generated static dashboard with a `systemd --user` service rather than a manually launched process.
- Required service properties:
  - explicit `HEALTH_DASHBOARD_FILE`, host, and port environment values;
  - `Restart=on-failure` plus a short restart delay;
  - `WantedBy=default.target` and `systemctl --user enable --now`;
  - hardening such as `NoNewPrivileges`, `PrivateTmp`, read-only system/home access where compatible.
- Check `loginctl show-user <user> -p Linger`; enabled lingering lets the user service start after reboot without an interactive login.
- Verification sequence:
  1. `systemctl --user daemon-reload`
  2. enable/start service
  3. verify `is-enabled` and `is-active`
  4. restart the service deliberately
  5. retry HTTP briefly to avoid a startup race
  6. verify localhost and Tailnet HTTP 200 plus non-empty content.
- Keep a versioned service template in the HealthManager repository and install a copy under `~/.config/systemd/user/`.

## Encrypted weekly backup hardening

- Make the SQLite copy with Python's `sqlite3.Connection.backup()` after `PRAGMA integrity_check`.
- Produce the portable schema/data SQL dump with `sqlite3.Connection.iterdump()` so the backup does not depend on an external SQLite CLI.
- Load GOG/keyring credentials from runtime environment or a mode-600 secret env file. Never hardcode the value in runtime code, repository code, logs, or commands.
- Encrypt the archive with GPG AES256 and a local passphrase file; enforce mode 600 on the passphrase, encrypted archive, and local manifest.
- Upload only the encrypted archive. Keep DBs, PDFs, raw documents, reports, exports, and secrets out of GitHub.
- A successful process exit is not sufficient verification. For a real test backup:
  1. decrypt into a temporary directory;
  2. list/extract the archive;
  3. run `PRAGMA integrity_check` on the backed-up DB;
  4. parse the manifest;
  5. verify the schema dump is non-empty;
  6. securely remove temporary plaintext.
- If file permission logic changes, test encryption on a tiny temporary file before repeating a large offsite upload.

## Architecture documentation and publication

Document the current data flows, runtime paths, pipeline components, scheduler jobs, dashboard service, backup/restore process, and JARVIS sanitizing boundary. Explicitly distinguish:

- local productive runtime and medical data;
- GitHub code/schema/docs without patient data;
- encrypted offsite backup;
- Health detail dashboard versus sanitized JARVIS cockpit.

Before publishing:

1. compile/check changed scripts;
2. run `git diff --check`;
3. scan changed files for PATs and assigned password/passphrase/token literals;
4. reject staged DB, SQLite, PDF, image, export, report, or encrypted-backup artefacts;
5. commit coherent operational changes;
6. push with a one-shot credential helper that reads the token file without printing it;
7. verify the exact remote branch ref equals local HEAD.