Harden public showcase privacy controls

docs/architecture.md

@@ -110,7 +110,7 @@ The edge node handles always-on weather and mesh-radio functions close to the at
 client → tunnel gateway → internal reverse proxy → SSO policy → application
 ```
 
-The tunnel endpoint is the only public routing layer. Application containers do not require direct inbound router exposure.
+The tunnel endpoint is the primary public routing layer for HTTP applications. Application containers do not require direct inbound router exposure; narrowly scoped non-HTTP exceptions are documented and isolated separately.
 
 ### Internal application request
 

docs/security.md

@@ -31,9 +31,9 @@ Removing a value from the latest commit does not remove it from Git history.
 
 ## Repository controls
 
-The public repository uses two checks:
+The public repository uses layered checks:
 
-- `scripts/check-public-safety.py` rejects infrastructure identifiers, private paths, key-like files, and common secret patterns.
+- `scripts/check-public-safety.py` rejects infrastructure identifiers, private paths, key-like files, binary files, raw-export filenames, non-approved URL hosts, and common secret patterns. Its source is executed and syntax-checked rather than matched against its own detector literals.
 - Gitleaks scans complete Git history in CI.
 
 The scanner is deliberately conservative. Placeholder examples should use unmistakable values such as:
@@ -64,4 +64,4 @@ https://service.example.net
 
 ## Reporting
 
-Do not open a public issue containing a suspected secret. Revoke it first and use a private contact channel for disclosure.
+Do not open a public issue containing a suspected secret. Revoke it first, then use [GitHub private vulnerability reporting](https://github.com/fizzlepoof/homelab-showcase/security/advisories/new). The repository owner may also be contacted through an already established private channel.

docs/services.md

@@ -1,168 +1,88 @@
-# Current Service Placement
+# Representative Service Architecture
 
-This is a public-safe service inventory verified against the live hosts during the September 2026 refresh. Versions, ports, addresses, domains, device IDs, and internal paths are intentionally omitted.
+This page is a deliberately generalized snapshot of the lab's service design, informed by read-only host, container, storage, and service inspection on 2026-09-08. It is not a complete production inventory. Exact products are included only when they illustrate a reusable pattern; precise placement, versions, counts, ports, addresses, domains, and runtime identifiers remain private.
 
 ## Primary application host
 
-### Core platform
+The primary host concentrates the shared application plane:
 
-- TrueNAS SCALE
-- Docker application runtime
-- shared PostgreSQL, MariaDB, and Redis
-- Traefik internal reverse proxy
-- Newt tunnel connector
-- Tailscale private-overlay connector
-- Authentik identity and SSO
-- Authelia retained for limited legacy migration paths
-- Headscale and Headplane pilot control plane
-- Gitea source hosting
-- Dockhand and Homepage administration interfaces
+- storage-aware container runtime
+- internal reverse proxy and authenticated tunnel connector
+- identity and SSO
+- shared PostgreSQL, MariaDB, and Redis data services
+- source hosting and container administration
+- household productivity, document, photo, and media front ends
+- monitoring, metrics, logs, dashboards, uptime checks, and notifications
+- workflow automation
+- always-on local model serving, model routing, vector search, and metasearch
 
-### AI and search
+Representative technologies include TrueNAS SCALE, Docker, Traefik, Authentik, PostgreSQL, Redis, Prometheus, Grafana, Ollama, and LiteLLM.
 
-- Ollama always-on model serving
-- LiteLLM model gateway
-- Open WebUI
-- Qdrant vector database
-- SearXNG metasearch
-- Firecrawl API, browser worker, queue, and supporting data services
-- a VPN-isolated search egress path
-
-### Media and libraries
-
-- Plex
-- Tautulli
-- Audiobookshelf
-- Calibre Web Automated
-- Seerr
-- Immich application and machine-learning services
-- RomM
-- GameVault
-- Dispatcharr
-
-Large libraries remain on the storage host and are mounted by the application host.
-
-### Productivity and household applications
-
-- Paperless-ngx with document conversion and extraction sidecars
-- Karakeep with browser and search sidecars
-- n8n
-- KitchenOwl
-- Donetick and a dashboard bridge
-- Shlink and its web client
-- Qui
-- Scholarsome
-- Doris Barbell
-- Kima Hub
-
-### Monitoring and notification
-
-- Grafana
-- Prometheus
-- Loki
-- Promtail
-- cAdvisor
-- node exporter
-- Netdata
-- Uptime Kuma
-- Gotify
-
-### Radio visibility
-
-- MeshMonitor
-- local map-tile service
+Large datasets are mounted from the storage host rather than duplicated into container-local volumes.
 
 ## Storage and ingestion host
 
-### Data plane
+The storage host keeps capacity-heavy and data-local workloads together:
 
-- ZFS-backed bulk storage
-- application-data and media datasets
-- snapshot and backup targets
-- synchronized school/document storage
+- ZFS-backed bulk datasets
+- snapshots and backup targets
+- media acquisition, organization, and post-processing
+- file synchronization
+- private remote-support rendezvous and relay
+- a secondary DNS resolver
+- selected CPU-only inference utilities
+- host and container monitoring
 
-### Media ingestion
-
-- Sonarr, including a separate anime workflow
-- Radarr
-- Lidarr
-- Readarr variants
-- Prowlarr
-- Bazarr
-- qBittorrent through a VPN gateway
-- qbit_manage
-- Unpackerr
-- Autobrr
-- Notifiarr
-- Shelfmark
-
-### Supporting services
-
-- Syncthing hub
-- RustDesk rendezvous and relay
-- CPU text reranker
-- secondary Technitium DNS replica
-- Netdata
-- Hawser
-- Newt connector
+Representative technologies include Unraid, ZFS, the common media-automation ecosystem, Syncthing, RustDesk, Technitium DNS, and Netdata.
 
 ## Offline and resilience host
 
-### Offline knowledge platform
+The resilience host stays useful when the primary application host or WAN is unavailable:
 
-- Project N.O.M.A.D. administration layer
-- Kiwix
-- two Kolibri generations for retained content compatibility
-- CyberChef
-- Flatnotes
-- MeshCore Web
-- local Ollama and Qdrant
+- offline reference and educational libraries
+- local notes and browser utilities
+- local model and vector services
+- household helper and agent services
+- CPU speech-to-text
+- Home Assistant in a dedicated virtual machine
+- game-server management
+- mesh-radio observation
+- a secondary DNS resolver
+- trusted local file intake
 
-Project N.O.M.A.D.-managed containers are treated as an appliance layer and are not manually rebuilt by general maintenance automation.
+Representative technologies include Ubuntu Server, KVM, Home Assistant OS, Kiwix, Kolibri, Ollama, Qdrant, and Docker.
 
-### Local agents and household tools
-
-- Honcho API, deriver, PostgreSQL/Vector database, and Redis
-- Doris Schoolhouse
-- Doris Kitchen
-- CPU Whisper service
-- LocalSend trusted intake
-- Hawser
-- node exporter
-
-### Resilience and hardware-adjacent services
-
-- Home Assistant OS in a KVM virtual machine with a dedicated Zigbee radio
-- secondary Technitium DNS replica
-- MeshCore companion observer as a system service
-- Pelican/Wings game-server management
-- Newt tunnel connector
+Managed appliance workloads on this host are excluded from broad cleanup automation and maintained through their own control plane.
 
 ## GPU operator workstation
 
-- CachyOS desktop
-- high-performance NVIDIA GPU compute
-- optional heavy Ollama and speech workloads
-- Docker runtime
-- printing service
+The workstation provides optional accelerated capacity and daily operator tooling:
+
+- high-performance local model inference
+- accelerated speech-to-text and other GPU jobs
+- container runtime
+- printing
 - private-overlay access
-- file-synchronization client
+- file synchronization
 - 3D-printing and slicing applications
 
-The workstation is intentionally opportunistic capacity. Background services must continue when it is asleep or offline.
+The workstation is opportunistic capacity. Routine background services must continue when it sleeps or is offline.
 
 ## Low-power edge node
 
+A small independent Linux node handles hardware-adjacent, always-on functions:
+
 - weather collection and dispatch
-- mesh-radio/repeater support
-- wired server-lane placement
-- low-power always-on operation
+- mesh-radio and repeater support
+- wired placement on a server-oriented network segment
+- upstream reporting without joining the primary application failure domain
 
 ## Placement rules
 
 1. Shared applications and databases prefer the primary application host.
-2. Large data and media ingestion stay close to bulk storage.
+2. Large data and ingestion stay close to bulk storage.
 3. Offline knowledge and resilience services remain independent of the primary host.
 4. Heavy GPU work may use the workstation, but routine automation cannot require it.
 5. Hardware-adjacent radio and weather services stay on low-power edge nodes.
-6. DNS, file synchronization, and remote support span hosts to avoid a single failure domain.
+6. DNS, file synchronization, and remote support span hosts to reduce single points of failure.
+7. The complete service inventory, operational exceptions, and incident state remain in the private source-of-truth repository.