Add Server Buddy desktop app with local Linux assessment and reporting

docs/DEVELOPMENT.md

@@ -0,0 +1,29 @@
+# Development guide
+
+Run commands from the repository root. Use a Python 3.11+ virtual environment and requirements.txt. Start with `python -m server_buddy.main`. Assets are resolved relative to the module, independent of the user's working directory; tests use repository-relative schema/fixture paths.
+
+## Phase 1 behavior
+
+Qt widgets stay on the GUI thread. CollectionJob loads the bundled JSON in a QThread and delivers stage/result/error signals. Analyze and import buttons are disabled until the worker finishes; closing an active job is deferred to avoid destroying a running thread. Demo loading is finite local I/O; production timeout/cancellation and process lifecycle management are Phase 3 requirements. No subprocesses are launched in Phase 1.
+
+Tables use Qt proxy filtering across all columns with native numeric sorting. Session history records repeated fixture loads without changing fixture timestamps. Dashboard counts unique hostnames from fixture/import history, while history counts runs. High-risk findings refer to the current assessment. Two OS-specific fixtures supply the demo; user input cannot relabel synthetic evidence as a live server assessment.
+
+Risk rules live in analyzers/assessment.py. Each finding contains classification, evidence, severity and points. Score is the sum capped at 100: 0 informational, 1–29 low, 30–59 medium, 60–89 high, 90–100 critical. These preliminary rules are demonstration logic, not a validated production risk model. Severity is an individual finding's severity, while overall risk is the aggregate. Observation limits always contribute uncertainty.
+
+Collection JSON uses schemas/inventory-v1.schema.json. Export JSON wraps the collection as inventory_result and includes the derived assessment. Do not treat the report wrapper as collection JSON. Live collection must enforce the schema at the boundary and tighten field schemas as PowerShell contracts are implemented. Never replace failed checks with synthetic values.
+
+## Verification in this development environment
+
+Python 3.12.3 is available. `python3 -m unittest discover -s tests -v`: four tests passed; schema and Qt smoke tests skipped because jsonschema and PySide6 are absent. An isolated installation under /tmp failed due to package server DNS/network resolution. GUI launch and visual appearance have not been verified here. Run the documented tests after installing dependencies on Linux Mint; also test a Windows desktop before distribution.
+
+No PowerShell collection scripts or production collector exist yet, so there is no real PowerShell output to validate. Phase 1 requires no remote accounts, remoting configuration, or administrative privilege.
+
+## Follow-up verification
+
+After dependencies were installed in the project virtual environment: `.venv/bin/python -m unittest discover -s tests -v` passed all 12 tests, including two offscreen Qt tests, schema validation, Linux inventory import/NFS evidence, sensitive-field exclusion and startup diagnostics. Source compilation passed. Normal X11 startup is blocked by the confirmed missing `libxcb-cursor.so.0`; the launcher prints Mint installation instructions. Windows execution and real RHEL collection remain untested/unimplemented as described in PLATFORMS.md.
+
+## Local Linux collector
+
+`collectors/linux.py` executes fixed argument lists from system binary directories with a restricted environment, no shell or user hostname, DEVNULL stderr and no sudo. Each process is polled for cancellation, an eight-second time limit and a 10 MiB output limit; the process is killed and reaped on interruption/failure. Overall collection is bounded to approximately 60 seconds for command execution. Local /proc and /etc/os-release reads do not access mounted remote filesystems. There is no arbitrary command UI. Collection source is included in server metadata; JSON import strips that source field and treats imported evidence as unverified. GUI workers retain the previous assessment on cancellation. New local checks intentionally return partial/missing statuses rather than asserting full coverage.
+
+Verification: 21 unit/UI tests passed, plus a real local read-only smoke collection validated against the JSON schema with HTML/JSON generation. Tests use both RPM and dpkg fixtures, check service/IPv6 parsing and unknown-service classification, command timeout/reaping, cancellation, and source labels. Real RHEL and Windows execution is still pending.

docs/IMPLEMENTATION_PLAN.md

@@ -0,0 +1,24 @@
+# Implementation plan
+
+Repository inspection: empty project directory with reserved environment directories; no existing application or repository instructions.
+
+1. **Phase 1 (implemented):** offline PySide6 dashboard, six navigation pages, ten inventory tabs, hostname validation, background demo loading, searchable/sortable tables, session history, explicit execution selection, synthetic fixture, local demo exports and preliminary evidence/risk presentation.
+2. **Phase 2:** independent read-only PowerShell modules for system/roles, services, TCP/processes, scheduled tasks, registry software, volumes/shares and public certificate metadata. Versioned JSON envelope with per-check statuses. Optional AD enrichment interface; no AD requirement.
+3. **Phase 3:** Windows execution-host collector using existing authorized Invoke-Command sessions. Resolve trusted script paths; pass validated hostname as an argument to a fixed script via subprocess argument lists (never shell=True). Enforce timeouts, cancellation, process cleanup, bounded output and schema validation. Linux remains offline. No remoting setup.
+4. **Phase 4:** expand transparent weighted rules, role/process mappings, service account and inbound connection correlation; distinguish observed activity from potential dependencies and unknown evidence. Review critical infrastructure role rules before live use.
+5. **Phase 5:** production reports, redaction of sensitive service/task arguments, failed-check visibility, export validation and report metadata. Existing Phase 1 exports contain synthetic records only.
+6. **Phase 6:** collector contract tests, PowerShell validation on Windows, failure/timeout tests, Windows packaging and signed release guidance.
+
+## Structure and boundaries
+
+`server_buddy/ui`: Qt views and background worker. `core`: input validation and future orchestration. `collectors`: platform-specific collection backends. `models`: future typed schema adapters. `analyzers`: evidence and heuristic rules. `reporting`: local exports. `assets`: bundled offline fixture. `powershell`: future Windows-only scripts. `schemas`: collection contract. `tests`: fixture, core and optional Qt tests.
+
+History is session-only; timestamps are original fixture timestamps. No SQLite or remote collection in Phase 1. A missing check never means a negative result. Synthetic demo is bound to a reserved example.test hostname and documentation-only IP addresses. Export pipeline must gain production redaction before any live collection is enabled.
+
+## Scope expansion: Linux targets and desktop startup
+
+The target scope now includes Windows Server 2016 onward and RHEL-based Linux, with either Windows or Mint as the reporting desktop. Added a RHEL synthetic dataset, target selector, background schema-validated JSON intake, OS-neutral report labels, NFS/Samba dependency rules, and a pre-Qt diagnostic for the missing Mint xcb cursor library. Live collection remains outside the current Phase 1 implementation. See PLATFORMS.md for transport boundaries, Linux inventory mappings and the required test matrix.
+
+## Local Linux testing implementation
+
+Added real read-only local collection for Mint and RPM-based Linux, a direct Analyze This Linux PC action, Settings mode, cancellation, command time/output bounds and headless JSON export. Real local results have distinct banners/history/report labels. Missing service identities, user/cron tasks, share exports, disk capacity, role correlation and certificate checks remain explicit. Both package formats are covered by parser tests; full RHEL and Windows validation remains pending. No remote transport is enabled.

docs/PLATFORMS.md

@@ -0,0 +1,34 @@
+# Platform support and collection plan
+
+## Current functionality
+
+| Desktop | Windows inventory reporting | RHEL-based inventory reporting | Live collection |
+| --- | --- | --- | --- |
+| Linux Mint, Python 3.11+ | Synthetic demo and schema-validated local JSON import | Synthetic demo and schema-validated local JSON import | Local read-only Linux collector on Linux; no remote collection |
+| Windows 10/11, Python 3.11+ | Same application code; Windows desktop testing pending | Same application code; Windows desktop testing pending | Not implemented |
+
+**Update:** Local Linux Mint/RHEL-based collection is now implemented via `collectors/linux.py`, with direct GUI and headless CLI entry points. It uses RPM on hosts where RPM is available and dpkg on Mint. Mint-like package parsing and mocked RPM output are tested; real RHEL release validation remains pending. See README for exact coverage and missing checks. Windows live collection remains unimplemented.
+
+Qt is a desktop dependency, not a dependency to install on assessed servers. Headless RHEL servers will produce JSON through a separate collector and do not need PySide6. Reporting does not require Windows administrative modules on Linux.
+
+## Target collection support
+
+Windows targets: Windows Server 2016 onward. Use read-only PowerShell compatible with Windows PowerShell 5.1 from an existing authorized Windows execution host. Linux Mint can import that execution host's JSON. A future transport to a Windows execution host must be explicit and authenticated; never run Windows administration modules natively on Linux. Feature availability and permissions vary, so every module reports complete/partial/failed/not_collected separately. Test each supported Windows Server release before claiming collection compatibility.
+
+RHEL-based targets: RHEL and compatible distributions, initially validate supported enterprise 8/9/10 families individually; older versions require explicit compatibility testing. The offline local collector can run on the Linux execution host and export JSON for manual transfer. Future remote collection will use existing authorized SSH. No agent installation, automatic SSH enablement, privilege escalation or remote configuration. Windows desktop SSH support must be checked at runtime. Offline JSON remains the common fallback.
+
+Linux inventory requirements:
+
+- `/etc/os-release`, kernel, boot time, addresses, interfaces and directory integration evidence.
+- systemd services with state, unit path and execution identity; no secret-bearing environment or command arguments.
+- `ss` TCP observations, with unprivileged process attribution explicitly marked incomplete where necessary.
+- system and accessible user timers, cron/anacron schedules; inaccessible accounts and application schedulers remain missing evidence.
+- RPM package inventory; never install or alter packages.
+- mounts, local/remote filesystems, free space, NFS exports and Samba shares. Distinguish remote mounts from exported storage and avoid reading protected configuration secrets.
+- Configured public certificate metadata from explicit locations. Linux has no single Windows-style machine certificate store; do not claim full certificate coverage or inspect private keys.
+
+Common analysis must distinguish observations, inferred workloads and unknowns. Windows roles and Linux package/service workload hints are not equivalent evidence. NFS, Samba and SMB exports all require dependency review; listing a share does not prove active consumers. Account and critical infrastructure rule mappings need OS-specific coverage before production deployment.
+
+## Validation remaining
+
+Windows GUI and collection tests; Windows Server release matrix; RHEL/compatible distribution matrix; SSH authentication and host-key checks; PowerShell transport; timeout/cancellation and output bounds; incomplete permissions; production field redaction; signed packaging. No real enterprise server is contacted during development without an explicit target and authorization.