Skip to content

Project Roadmap

🧪 Partially validated — project status

Shared application behavior is developed on Windows, and selected deployment paths have been exercised in a nested Proxmox lab. The physical target and production Linux/GPU stack still require validation. See the status key and individual phases below for the scope of each result.

Where to start

This roadmap tracks implemented work, remaining phases, and future concepts. Use it to understand current progress and what must be verified before the project moves to its intended physical server.

Status key

  • Done (Windows prototype) — implemented and verified in the active Windows build environment, or with focused mocks where noted. This counts as project implementation for shared behavior; it does not imply target-host validation for OS-, hardware-, network-, or service-specific behavior.
  • Partial — some implementation or integration is complete, but the stated capability or validation remains incomplete.
  • In progress — implementation is actively underway.
  • Not started — planned, but implementation has not begun.
  • Experimental / waiting for server — unsupported-by-vendor work that depends on the Proxmox host, its kernel, or the production hardware; staged investigation is possible, but runtime validation is still required.
  • Concept — a candidate future capability in the backlog; it is not scheduled or implemented unless explicitly stated otherwise.

Current status summary

The Windows environment is the active place for shared application and API development. Status below distinguishes implemented behavior from nested-lab evidence, plans, and physical-host validation; portability must be verified through tests rather than assumed.

Application and account data

  • The dashboard, Windows backend foundation, operational logging, and interface polish are implemented. Dashboard-owned login/session management and per-account SQLite conversation history are implemented and verified in the Windows prototype.
  • Explicitly curated admin-only shared operational notes are implemented. AI Chat conversations remain private to each account. The AI Interface is a separate admin-shared transcript with attributed turns and does not load private AI Chat history.

AI output and conversation memory

  • Standard and streaming user-facing replies are filtered server-side for raw <think> blocks. Assistant transcripts are sanitized on write, read, and reuse as model context. llama.cpp generation-time suppression is defense-in-depth, not a reliable Qwen3 safety boundary with the current no-Jinja setup.
  • Conversation history is separate from diagnostic incident history and retrieval. Automatic fact extraction and model training from conversations are not implemented.

Diagnostics and maintenance

  • Observe-only diagnostics and persistent incident history are implemented locally. A reviewed local lexical runbook-retrieval prototype and disconnected maintenance/remediation simulations are also implemented.
  • Semantic/vector retrieval and live remediation remain outstanding.

Deployment and validation

  • Shared behavior is developed on Windows and carried forward for Proxmox integration. Verify portability through tests; do not assume that only platform-specific changes will be needed.
  • Proxmox API integration and HTTPS access through NGINX have been exercised in the nested lab. These results do not establish physical-host acceptance.
  • The production Linux/Proxmox stack is unvalidated; physical-host and production acceptance remain outstanding.

Inference profiles

  • The proposed single-GPU Utility AI plus Household/Maintenance profile architecture is planned, not implemented. The current model manager runs one active model at a time.
  • Persistent model residency, request routing, and combined VRAM feasibility remain unverified.

Phase status at a glance

Phase Status Evidence and next gate
Phase 1 — Local Test Environment Done (Windows prototype) Core dashboard, backend, bot, telemetry, chat, and logging work in the Windows environment; target-platform work is tracked in later phases.
Phase 2 — Portable Backend and Reliability Partial Major portable behavior is implemented; scheduled maintenance remains not started and physical-host acceptance is outstanding.
Phase 3 — Mocked Integrations and Portable Feature Work Partial Portable contracts and selected nested-lab integration checks are complete; continue using the numbered integration-priority order below.
Phase 4 — Proxmox Readiness and Compatibility Gate In progress Pre-host planning is underway; actual inventory and recovery details must be confirmed before deployment.
Phase 5 — Physical Target-Host Deployment and Core Integration Experimental / waiting for server Nested-lab checks do not count as physical-host acceptance; the physical Proxmox server is the next gate.
Phase 6 — Live Server-Dependent Product Integrations Not started Gated on Phase 5 physical-host core stability, access control, and recovery.
Phase 7 — Polish Partial Core interface polish is implemented; full real-device mobile layout and interaction testing remains.

Phase status is scoped to the evidence named in each section. Windows tests and nested-lab validation do not imply physical-host or production acceptance.

Sequencing and portability rule

All remaining work is directed toward the planned Proxmox server. Proxmox VE 9.1-1 is running as a nested Hyper-V guest on the Windows PC and is available as an additional Linux/Proxmox deployment and integration environment. Rootless Podman/Quadlet backend and dashboard containers are loopback-bound; boot auto-start and clean/forced guest recovery have passed in the nested lab. The latest release, 20261106-updater-verify, was healthy immediately after its switch. NGINX/TLS access from Windows and iPhone and one signed Stage 1 bundle verification were also tested. A two-release rollback, some Stage 1 negative and large-upload tests, post-release reboot recovery, and physical-host acceptance remain unverified. Use the guest to prepare and test suitable OS/API/deployment work before the physical server is available. It does not validate the physical host's hardware, GPU/ROCm, storage/network topology, sustained performance, or recovery behavior. Windows remains the active shared-application build environment, not the deployment target.

  • Pre-physical-server work: use portable contracts, deterministic tests, and the nested Proxmox lab for Proxmox API, permissions, VM workflows, and Linux service/deployment integration. Identify all lab results as nested-lab evidence, not physical-server acceptance.
  • Server-gated: requires the actual Proxmox release, kernel, GPU, network, service manager, installed services, or production proxy. Schedule it in Phase 5 or later; do not mark it done based on Windows, mocks, or nested-lab success where the physical server is required.
  • Post-integration: enable live operations only after their target-host integration, permissions, and recovery path are tested.

Phase 1 — Local Test Environment

Status: Done (Windows prototype)

Evidence: The local dashboard, backend, Discord foundation, system monitoring, chat/model discovery, and operational logging are implemented and exercised in the Windows test environment.

Next gate: No remaining work is identified within this phase's local test-environment scope. Linux/Proxmox integration and acceptance are tracked in later phases.

Completed

  • Dashboard UI and panel navigation
  • Dashboard behavior is organized into native browser modules without a build step; browser loading and focused module ownership are documented in the frontend guide. Playwright browser regressions now cover module loading, sign-in gating, viewer/operator/admin UI behavior, panel navigation, and persisted preferences. They found and fixed CSS that had overridden the standard hidden attribute on styled controls.
  • FastAPI backend foundation
  • Discord bot foundation
  • System monitoring in the Windows test environment
  • Local chat interface and model discovery/switching
  • Operational logging

Phase 2 — Portable Backend and Reliability

Status: Partial

Evidence: The portable backend, authentication, chat/research, saved conversations, observe-only diagnostics, and responsive interface work below have been implemented with Windows test coverage; selected authentication and proxy behavior has also been exercised in the nested lab.

Next gate: The admin-configurable scheduled-maintenance feature remains not started. Physical Linux/Proxmox behavior remains subject to later target-host validation.

Completed

  • Validated configuration loader
  • FastAPI routes organized into auth, chat, memory, research, and operations modules while retaining the main:app deployment entry point. Full backend regression suite passes against the modular app.
  • Console and rotating-file backend logging
  • WebSocket streaming for local chat
  • CORS and WebSocket origin restrictions for configured dashboard origins
  • Windows SearXNG test setup and dashboard web-research integration
  • Cited web research with bounded public-page retrieval, explicit excerpt fallback status, and authenticated SSE streaming. Focused unit/API tests pass. A live Windows browser smoke test on 2026-11-04 verified local Qwen2.5 1.5B chat and the Research Web path through WSL SearXNG to llama.cpp; the research response included source links. This does not establish Linux/Proxmox or physical-host acceptance.
  • Dashboard-owned authentication: local and mapped Proxmox login, persistent revocable sessions, role authorization, protected REST/WebSocket routes, CSRF and origin checks, login throttling, CLI account/mapping management, and browser login/logout flow. Windows and mocked-provider tests pass. A real Proxmox identity was mapped to the viewer role and authenticated in the nested lab; viewer reads succeeded and higher-role access was denied. Middleware ordering was corrected so allowed dashboard origins can read authorization errors, and the backend suite passes. A lab image update attempt was rolled back after the backend did not remain reachable; API health recovered, but the cause was not isolated. At that time the middleware fix was not deployed; it was later deployed in release 20261106-frontend. HTTPS login and proxy-aware lockout behavior were subsequently verified from Windows/iPhone against the nested lab. Physical-server acceptance remains outstanding.
  • Proxmox authentication interface and HTTPS ticket client with mocked responses. These tests establish client behavior, not real-provider integration.
  • Per-account conversational history: isolated SQLite storage, saved-chat listing/resume/delete, and bounded recent-turn context for the local chat model. Bot API requests remain stateless. This does not implement automatic fact extraction, semantic/vector retrieval, or the separate diagnostics RAG system. History is retained locally until its owner deletes it.
  • Admin shared insight memory: each note must be explicitly published by an admin; any admin can read or remove it. Admin identity and a bounded set of approved notes are supplied to AI Chat and research. Private account transcripts are not shared, scraped, or used for model training. The newest private AI Chat conversation resumes at sign-in.
  • AI Interface: a single persistent admin-shared operational transcript with authenticated admin attribution, separate from AI Chat history. Server-side authorization limits it to admins. Only explicitly requested read-only diagnostics can run; general server command execution and maintenance are not implemented.
  • Read-only GET /api/backend/logs endpoint and dashboard panel: configurable tail bounded to 500 lines, defaults to the latest 200; manual refresh and five-second auto-refresh only while open. Access is admin-only.
  • Persistent, bounded observe-only diagnostics: observations, incident state/transitions, and audit events in the local SQLite database; open incidents and pending threshold evidence restore on backend restart. Collection remains explicitly triggered and read-only. The expanded checks include backend process state and a read-only SQLite integrity probe; resource thresholds use duration confirmation, bounded observation gaps, and recovery hysteresis. Viewer-readable evidence reports summarize the selected saved observation, including incident state/evidence at that time, without running probes.

Planned behavior and design constraints

  • Not started — admin-configurable scheduled maintenance window: add an admin-only Diagnostics/Maintenance setting for enablement, recurrence days, start/end time, and explicit IANA timezone. Show the configured timezone and next scheduled window, validate and audit changes, and define persistence and activation semantics. The proposed environment values are defaults, not the admin UI. Keep scheduling disabled and do not execute maintenance until the setting, scheduler, and target lifecycle are separately validated. See the AI Diagnostics & Self-Healing design.
  • Network services autonomy policy: keep future DHCP/DNS/web/routing and firewall integrations observe-only by default, whether services run on the Proxmox host or inside VMs. Do not expose mutation endpoints or automated remediation in the initial monitoring integration. Any later move to limited AI-assisted action must be a separate admin-authorized phase with explicit per-action boundaries, audit evidence, verification, and tested rollback/out-of-band recovery. Full autonomy is a distinct later gate; the AI must never promote its own authority or infer permission from successful monitoring.

Completed — dashboard and responsive-layout refinements

  • Optional HTTPS launchers for whole-dashboard testing from a mobile device on a trusted private LAN. They bind to one configured private IPv4 address and serve only public UI assets. Phone certificate trust and dashboard access have been verified on the local device; firewall rules were not changed. Mobile chat panels keep the header and composer visible while conversation content scrolls; the AI Interface console badge stays beside its title, and its safety notice can be dismissed until reload. Short landscape layouts (600px high or less) retain compact horizontal navigation without a sidebar toggle. Portrait chat controls are condensed; short landscape layouts keep the controls horizontal, place Research Web beside the input, and trim vertical spacing to reserve conversation space, with Transmit beside the message field.
  • System Monitor telemetry is arranged in a responsive two-column metric grid, collapsing to one column on very narrow screens. Four line charts show one-hour, session-only GPU, VRAM, CPU, and RAM trends sampled from the existing telemetry poll; no historical samples are persisted.
  • Collapsed desktop sidebar navigation icons are centered within the narrow rail.
  • Tablet navigation uses a full-width grid, with six columns in landscape and four in portrait; the header toggle hides or restores the navigation row to preserve active-panel space when requested.

Phase 3 — Mocked Integrations and Portable Feature Work

Status: Partial

Evidence: Read-only inventory, portable diagnostic knowledge and contracts are implemented; selected deployment, service-lifecycle, and authorization checks have passed in the nested lab only.

Next gate: Continue the numbered integration-priority order below. Nested-lab results do not satisfy physical-host acceptance.

Completed — interface groundwork and read-only inventory implementation

  • Virtual Machines panel has a read-only Proxmox VM/container inventory provider, authenticated viewer-level API route, and refreshable UI. The integration is implemented, covered by mocked tests, and connected to the nested Proxmox lab with its dedicated inventory token. On 2026-10-16, the host-installed client successfully retrieved one guest with only the five dashboard fields; transient Linux backend/dashboard startup and stop checks passed with loopback-only listeners and rejection of an unauthenticated inventory request. A later rootless Podman deployment also passed dashboard, OpenAPI, health, and anonymous-route checks. After adding a host-gateway hostname mapping, the live inventory client inside the backend container returned one guest with the expected five dashboard fields. Rootless service lifecycle, boot auto-start, and clean/forced guest recovery have since been tested in the nested lab. All results are nested-lab evidence, not physical-host acceptance. No VM management or console controls are exposed.
  • Network Services panel has planning-only views for DHCPv4, DHCPv6, DNS, web hosting, and routing/firewall. The intended initial integration is observe-only, including services hosted inside VMs: discover their owning guest and report approved service health/metrics without changing guest services or network configuration. Service ownership, scopes, monitoring interfaces, and configuration remain undecided; no backend or network-service monitoring API is connected.

Completed — portable diagnostics knowledge, simulation, and contracts

  • Added versioned, bundled diagnostic runbooks with a deterministic local lexical search and viewer-authorized list, detail, and search endpoints. Current procedures cover Proxmox API/TLS, empty/forbidden VM inventory, and local diagnostics storage. Retrieval returns reviewed procedures only; incident-derived drafts, embeddings, vector databases, and model-driven diagnosis are not connected.
  • Added deterministic in-memory maintenance and remediation simulations with a fixed-start mock clock. Tests cover preflight and drain skips, missing diagnostic context, restoration failure, registered-action validation, verification, rollback, and escalation. Simulations have no service, process, shell, Proxmox, database, or network action adapter and cannot execute live work.
  • Added read-only Proxmox inventory and proposal-only VM, network-service, and game-server contracts. Change intents require the declared admin role and exact confirmation phrase; no mutation routes or provider are implemented.

Pre-physical-server work — portable and nested-lab eligible

  • Partial — nested-lab integration: the inventory token's live read permission and transient loopback backend/dashboard startup and stop were verified on 2026-10-16. Rootless Podman/Quadlet units and container health checks are now implemented; at this point in the 2026-10-17 timeline both containers were active and loopback-only, and boot auto-start was not yet configured. The container's original route to the guest API was refused; the backend Quadlet now maps the API hostname to Podman's host gateway. The deployed mapping and live inventory request were verified: the container returned one guest with the expected five fields. On 2026-10-17, explicit stop/start was verified: units stopped cleanly, containers exited, listeners closed, then both services restarted healthy. A controlled backend-container kill triggered one systemd restart; the backend returned healthy, OpenAPI returned HTTP 200, anonymous inventory remained HTTP 401, and the live inventory client returned the expected record. The dashboard remained healthy and both ports stayed loopback-only. A separate start-limit boundary check allowed three automatic restarts and blocked the fourth failure within 60 seconds; resetting the failed unit and starting it manually restored a healthy backend. See the testing-environment guide. On 2026-10-17, deployment rollback from an intentionally unavailable image candidate to a saved pre-test Quadlet/image snapshot also passed. The candidate was prevented from pulling from a registry; after the unit hit its start limit, restoring the snapshot, resetting the failed unit, and starting it manually restored healthy API and live inventory. The snapshot is of the current build, not a previous application release. Subsequent nested-lab checks verified boot auto-start and clean/forced guest recovery. Rollback between distinct application releases and physical-host acceptance remain outstanding.

Integration-priority order

The numbering is the deliberate rank order for integration work. Update each item's status in place; do not reorder the list by completion state or by phase.

  1. Linux deployment and service lifecycle — partial, nested-lab checks passed. Podman/Quadlet was selected for the lab. Rootless backend and dashboard definitions now use loopback-only ports, explicit environment/CA mounts, persistent runtime state, health checks, and bounded restart behavior. The containers are active and configured for boot auto-start. The updated host-gateway hostname mapping and live inventory request now pass in the nested lab. Stop/start, controlled backend failure/restart, start-limit behavior, and rollback from an unavailable candidate to a saved pre-test snapshot passed. The rollback baseline is the current build, not a previous application release. Portable tests now guard the checked-in Containerfile and Quadlet lifecycle/security contract and exercise the HTTP health probe. These tests do not invoke Podman/systemd. Boot auto-start and reboot recovery (done 2026-11-05, nested lab only): an opt-in Quadlet drop-in and an optional post-boot housekeeping timer (prunes old build directories/logs only when both containers are healthy) were installed on the guest. After a clean reboot both containers came up healthy without a manual start and the docs routes stayed 404. A forced guest power-off also recovered both containers to healthy with all four SQLite files passing integrity_check. Not yet verified: the first timer-driven cleanup run, physical power loss, and physical-host acceptance.
  2. Proxmox identity and dashboard authorization — partial. A real mapped viewer login and role denial were tested in the nested lab; HTTPS login and proxy-aware lockout behavior were later verified from Windows/iPhone. Repeat the full authorized-route, CSRF/origin, and role-boundary checks after deployment changes. Use least privilege; nested-lab success is not physical-host acceptance.
  3. Linux application smoke coverage — partial (2026-11-05). An unauthenticated loopback check passed: both ports bound to 127.0.0.1, all 32 non-parameterized protected routes returned 401 anonymously, and login enforced the Origin check. Still unverified: SQLite paths/permissions, logs, authenticated reads, and diagnostics, which need ai-server account access that ai-deploy lacks. Container health was confirmed after release 20261106-updater-verify (both containers healthy about 45 seconds after the switch). /docs, /redoc, and /openapi.json are disabled by default (AI_SERVER_ENABLE_API_DOCS), and /docs returned 404 after deployment. Boot/reboot recovery passed earlier in the nested lab and should be repeated after future releases as needed. Add llama.cpp, SearXNG, bot, and proxy checks only when those services are installed and configured.
  4. Deployment-script lab checks — --check and --report run on the nested guest (2026-11-05); installer modes not run. Both read-only modes ran as the non-root ai-deploy account on the Proxmox VE 9.1.1 guest (kernel 6.17.2-1-pve). --check exited 2 and reported the ROCm gate blocked as designed (no RX 6800 XT in the guest, and the AMD matrix lists neither the GPU nor Proxmox VE 9); --report wrote an owner-only (0600) file, exited 0, and omitted hostnames and addresses. No packages or configuration changed. A cosmetic memory-label defect (MemTotal::) seen in the first run was fixed and re-verified on the guest. Nested-lab evidence only; it does not validate physical hardware, GPU/ROCm, or the installer modes, which must not be run from the nested guest. An automatic application deployment installer is planned, not started, and remains separate from prepare-ai-host.sh. The current nested-lab release procedure is manual. Keep the eventual installer scoped to the existing rootless backend/ dashboard image and Quadlet deployment, with read-only preflight, explicit confirmation, protected secret/config handling, pinned versions, health checks, and rollback that preserves persistent data. Keep SearXNG optional; exclude ROCm and inference until their separate compatibility gates pass. Lab redeploys (nested lab only): the manual release procedure in the runbook was executed twice on 2026-11-05. The first (20261105-docs-off) fixed a Containerfile gap (missing api/ packages) and brought both services up, with /docs 404, dashboard CSP and X-Frame-Options: DENY, loopback binds, and protected routes 401. It also exposed a regression: the backend had stopped loading its .env (loader path wrong since the api/ move), so it ran on empty default databases while the real data stayed untouched under /var/lib/ai-server/data/. The second (20261105-dotenv) fixed the loader; the backend now resolves the .env paths (/var/lib/ai-server/data/{auth,memory}.sqlite3, /var/lib/ai-server/logs) and both containers are healthy. This historical check preceded the later HTTPS login and signed-bundle tests. Boot auto-start and reboot recovery passed before the latest release; repeat reboot recovery after that release. See the Linux/Proxmox transition runbook. The planned deployment workflow now includes an admin-uploaded signed release bundle verified before apply (Stage 1 verify-only is implemented and deployed; one signed test bundle was verified through the dashboard on 2026-11-05, and Discard appeared to work. Tamper/wrong-key rejection, expiry, and a large upload through NGINX remain untested. The OCI-image payload and Apply remain design-only). A separate least-privilege updater is required to survive backend restarts, coordinate only backend/dashboard services, run health checks, and restore the prior image on failure. This is a design only; trust-key rotation, replay protection, database backup/schema compatibility, and updater permissions/status remain unimplemented. Model weights are not part of the application bundle: they live in the persistent AI_SERVER_MODEL_DIR and exceed the source-bundle size limits. Planned, not started: a separate admin-only signed model-package flow that verifies package metadata and content before installing into the persistent model directory. It must check available disk space, avoid overwriting or deleting installed models, and keep model installation independent from application update rollback. Installing a model must not load it automatically; selection remains an explicit existing operation.
  5. Linux AMD GPU telemetry — provider implemented; target validation pending. A platform dispatcher now selects the Windows provider or Linux amdgpu sysfs provider. Deterministic fixtures cover utilization, VRAM, optional hwmon sensors, invalid/missing counters, and ambiguous adapters. No ROCm/HIP runtime is installed or implied. Verify driver-exposed counters, service permissions, adapter identity, and idle/inference readings on the target Linux host before treating telemetry as operational.
  6. Lower integration priority product contracts. Define model-agnostic image job contracts and build the workspace-restricted website agent only after deployment permissions, workspace boundaries, and recovery behavior are decided. Keep file/command integrations disabled until then; do not prioritize a Windows-only image runtime.

Existing Proxmox UI status: the VM panel already distinguishes loading, not-configured, connected-empty, live inventory, and unavailable states. The read-only API rejects unauthenticated requests and does not return cached or sample inventory. No VM mutation or console controls are exposed. Further UI guidance, such as linking a failure state to a reviewed runbook, is a non-blocking improvement rather than a prerequisite for the next integration step.

Planned (not started): admin-only VM management. The Virtual Machines panel is read-only today, and its "Connected · read-only" label, the "Read-only access" notice, and the "Inventory scope" card are accurate only for that reason. Administrator-only guest actions (for example start/stop) are a planned later feature. Before it is built, it needs: a separately scoped, least-privilege Proxmox token distinct from the inventory token; dedicated admin-only routes with CSRF, Origin and exact-confirmation checks; audit logging; and the diagnostics and AI components remaining unable to invoke these routes. When it exists, the backend should report whether the token can write and the dashboard should derive the label from that capability: plain "Connected" for an administrator with write access, and "Connected · read-only" otherwise, with the static notices updated to match. This is design intent only; no mutation route, token or UI exists, and the current safety constraint against exposing mutation endpoints stays in force until then.

Phase 4 — Proxmox Readiness and Compatibility Gate

Status: In progress — waiting on target details

Evidence: The planned host, compatibility risks, and deployment constraints are documented; the nested lab supports eligible pre-host validation.

Next gate: Finalize the readiness decisions and confirm actual hardware, network, storage, and recovery details before starting physical deployment.

This phase closes decisions and preflight work, but does not claim the target host has been integrated. Hardware-dependent conclusions remain unverified until checked against the actual machine.

Readiness work in progress

  • Finalize the planned host specification and deployment inputs: intended Proxmox point release, CPU/GPU, boot mode, network topology, storage layout, recovery method, and service placement. Confirm these against the delivered server and installed OS in Phase 5; do not treat plans as verified inventory.
  • Current planned platform: Z590 motherboard with Intel Core i9-11900KF and RX 6800 XT. Start with 32 GB system RAM, with a possible 64 GB upgrade, 2 TB initial NVMe, and HDD-backed bulk/lower-I/O workloads. Confirm the exact board model, delivered hardware, firmware/boot configuration, and actual memory needs against Proxmox, planned VMs, inference, and concurrent services before deployment.
  • Select the host storage topology: actual HDD count, RAID/ZFS layout, controller mode, usable capacity, and expansion plan remain undecided. The household NAS concept proposes up to four SATA HDDs in RAID 5, but this is not a selected or validated host storage implementation. Redundancy is not a backup; plan a separate backup and test restoration. Consider NVMe for databases, active VM disks, and frequently used model files; model tiering improves load/switch time, not inference speed after model load.
  • Research compatibility for the intended Proxmox release, RX 6800 XT, ROCm/HIP, and application versions. Confirm the installed Proxmox release and running kernel, and re-check compatibility on-host in Phase 5. AMD does not list the planned GPU/Proxmox combination as officially supported; community reports are leads, not proof. Ubuntu and Proxmox share Linux kernel and Debian-related foundations, making compatibility investigation plausible, but they are distinct distributions; that shared foundation does not establish low risk or AMD support for Proxmox. GPU passthrough is not planned. Follow the staged recovery and acceptance requirements in the GPU plan.
  • Select pinned versions, host-vs-container boundaries, persistent paths, service accounts, least-privilege GPU access, firewall policy, TLS/proxy design, secrets handling, and rollback procedures before installation.

Gate to begin deployment

  • Planned hardware, intended Proxmox release, and recovery method are documented; actual host inventory and recovery access must be confirmed before deployment on the delivered server.
  • A separate app-deployment installer contract has been documented for later exploration; no such installer is implemented. The existing host-preparation script remains separate, and the initial planned installer scope excludes GPU/inference components and defaults to non-persistent, loopback-only deployment.
  • Storage, backup/restore, service, and network plans are reviewed.
  • Experimental GPU risk is explicitly accepted or GPU-dependent features are deferred.
  • Deployment steps are pinned, reviewed, and have a recovery path. Source-level review of the host-preparation script can happen pre-host; do not treat its --check, installer, or report modes as validated until run on the target. The script does not install ROCm or the inference stack.

Phase 5 — Physical Target-Host Deployment and Core Integration

Status: Experimental / waiting for server

Evidence: Selected service, HTTPS/authentication, recovery, and updater checks have been exercised in the nested lab. These results are not physical-host acceptance.

Next gate: The physical Proxmox server must be available to confirm host inventory, validate the target GPU/runtime, and complete core integration.

The nested Hyper-V Proxmox installation is a development lab only. Do not mark physical-host acceptance complete from Windows runs, mocks, or nested-lab results.

Physical-host work

  • Record the actual host inventory, installed Proxmox release/running kernel, and recovery access. Validate the host-preparation script's --check, --report, and reviewed installer modes on that host, then install only reviewed prerequisites.
  • Build and validate ROCm/HIP and ROCm llama.cpp/llama-server for the exact host; record device identity, build flags, versions, and smoke-test results. This remains experimental for the planned RX 6800 XT/Proxmox combination.
  • Implement the proposed single-GPU runtime profiles: keep Qwen2.5 1.5B Utility AI resident while Household mode loads Qwen3 8B or Maintenance mode loads Qwen2.5 Coder 7B. The current model manager only supports one active llama.cpp model; persistent Utility residency, profile routing, and concurrent VRAM use are not implemented. Measure combined VRAM/RAM, context/KV-cache, latency, swap recovery, and failure behavior before enabling either profile on the target host.
  • Integrate the Linux telemetry provider with the actual GPU and validate adapter identity, utilization, and VRAM against a host tool during idle and inference. Return unavailable/null if the deployed source cannot provide trustworthy readings.
  • Validate the observe-only resource threshold defaults under representative Proxmox server workloads, including inference and integrated-service activity. Measure false-alert rates, persistence across explicit sampling gaps, and recovery hysteresis before adopting production values. Collection must remain explicitly triggered; do not enable automatic execution as part of validation. Windows and generic Linux/CI results are not Proxmox acceptance evidence.
  • Create Linux service management using Podman/Quadlet or systemd as appropriate. Cover the backend, llama-server, NGINX, SearXNG, and only runtimes that are actually integrated; use persistent paths, health checks, least privilege, startup ordering, and controlled restart/recovery.
  • Validate dashboard-owned and real Proxmox login, role mapping, cookies, CSRF/origin checks, HTTPS reverse proxy, firewall rules, and browser access from a separate LAN client. Keep the API and inference service private until this gate passes. See authentication.md. Status: executed on the nested lab (2026-11-05). NGINX TLS with a local CA was installed and verified from a Windows PC and an iPhone (HTTPS redirect, trusted certificate, sign-in, loopback-only backend ports). The /ws/chat WebSocket connects through the proxy; token streaming is untested because the lab has no llama.cpp. A lockout test on the lab showed the backend treats all LAN clients as one address; fixed with AI_SERVER_TRUST_PROXY_HEADERS, deployed in 20261106-frontend, and a repeat test passed (an iPhone lockout no longer blocked the administrator on the desktop). Remaining: certificate renewal and the physical host.
  • Dashboard Settings is a tabbed page. Its admin-only Setup / Deployment tab holds the Firmware File picker and Verify button. Updater Stage 1 (verify-only) is implemented, deployed, and partly lab-verified: one signed .aibundle upload verified in the dashboard and Discard appeared to work. Tamper/wrong-key rejection, expiry, and a large upload through NGINX remain unverified. Apply (Stage 2) is planned and not started; a rollback between two distinct releases remains outstanding, while health and guest reboot recovery have passed in the nested lab.
  • Frontend polish (implemented, tested in Playwright, deployed to the nested lab as 20261106-frontend and verified over HTTPS): live CPU values, visibility-aware polling, self-hosted fonts, an offline banner, a web-app manifest with icons, larger mobile labels, no iOS input zoom, and a stacked Diagnostics header. iPhone home-screen install is verified on the lab (the phone must trust the lab CA or iOS shows a letter icon); the phone layout beyond that is not fully verified.
  • Integrate the existing dashboard, backend, model discovery/switching, chat and streaming, SQLite history, logging, optional research/bot, and observe-only diagnostics. Verify Linux dependencies, permissions, service recovery, proxy/WebSocket routing, and host reboot using the Linux/Proxmox transition runbook.
  • Validate real maintenance pause/restore/recovery against deployed services only after the mocked lifecycle is complete. Keep the control plane and recovery path available; fault-inject every gate. Host, kernel, firmware, and GPU driver/ROCm updates remain approval-only.

Phase 6 — Live Server-Dependent Product Integrations

Status: Not started — gated by Phase 5

Evidence: No live server-dependent product integration in this phase is considered complete.

Next gate: Begin only after Phase 5 core stability, access control, and recovery have been demonstrated on the physical target host.

Planned integrations

  • Integrate ONNX Runtime ROCm and ComfyUI ROCm. Validate model load, GPU offload, VRAM/RAM headroom, latency, output quality, and failure recovery.
  • Connect VM lifecycle and guest console using least-privilege Proxmox API permissions, server-side authorization, bounded operations, explicit confirmation for destructive actions, task/audit history, and tested guest recovery.
  • Connect DHCPv4/DHCPv6, DNS, web hosting, and routing/firewall in observe-only mode first, including discovery and health reporting for services hosted in VMs. Decide ownership, scopes, segmentation, supported read-only telemetry, and out-of-band recovery before integration. Keep mutation and automated remediation unavailable until a separately reviewed limited-autonomy phase; full autonomy requires a later explicit readiness and authorization gate. Network changes must not make the AI host the sole unprotected network edge or strand the dashboard.
  • Integrate the selected game-server manager; start with the family Minecraft use case only after edition/version, isolation, resource limits, allowlists, backups, world restore, and family-safety requirements are settled.
  • After validating the planned single-GPU Utility/profile routing, evaluate the dual-GPU service-separation concept against that baseline: Utility and Maintenance AI on the Operations GPU, Household AI on a future second GPU. Compare runtime/ROCm support, VRAM, throughput, latency, power, isolation, and recovery before enabling concurrent workloads.
  • Enable any real repair or scheduled maintenance actions only after independent executor validation, per-action policy/approval, audit evidence, and tested rollback. Model output or prior user feedback never grants authority.

Phase 7 — Polish

Status: Partial

Evidence: The interface and navigation polish listed below is implemented.

Next gate: Complete full real-device mobile layout and interaction testing; LAN HTTPS and certificate trust alone do not satisfy this gate.

Completed

  • Panel fade-in and sidebar transition; reduced-motion preference respected
  • Persistent dark/light theme
  • Responsive compact header and scrolling navigation on layouts 760px wide or less, or 600px high or less
  • Persistent collapsible icon-only desktop sidebar
  • Persistent accent-colour selection

Remaining

  • Full real-device mobile layout and interaction testing; HTTPS LAN access and certificate trust have been verified on the phone, but broader device and interaction coverage remains outstanding

Forward-work summary

The highest-priority eligible work remains the Linux deployment/service lifecycle and portable integration checks. A Linux AMD GPU telemetry provider is now implemented and fixture-tested, but live kernel/GPU readings remain target-host validation. The VM panel already has its principal failure states. Image contracts and website-agent groundwork remain lower integration priority. Record lab results as nested-lab validation and document limitations; do not substitute Windows-only runtimes for the planned Proxmox stack.

Once the physical server is available, confirm the installed host inventory and complete the Phase 4 readiness gate, then execute Phase 5 physical-host validation in controlled steps. This includes threshold validation under representative server workloads, GPU/ROCm telemetry, service and reboot recovery, and production authentication/proxy/network checks. Phase 6 live product integrations remain gated on physical Phase 5 stability, access control, and recovery. Keep the production backend local-only until HTTPS/proxy behavior, firewall/network controls, and deployment have been validated on the physical target.

Candidate backlog not scheduled

  • Household File Server / NAS (Concept)

Status: Concept

Objective: Provide a simple, locally hosted household file-storage service on the AI Server, using RAID 5 to increase usable capacity over mirrored storage while retaining single-drive failure tolerance, and leave a path to expand storage capacity.

Responsibilities:

  • AI Server: host and manage the initial household file-storage service using up to four SATA hard drives in a RAID 5 configuration.
  • Future NAS expansion: provide additional storage through either a dedicated USB 3.1 connection to a NAS box or a separate NAS connected over Ethernet, preferably with two 2.5 Gbps connections.

Design notes:

  • RAID implementation, filesystem, usable-capacity requirements, sharing protocols, household access controls, and service isolation remain to be selected and validated.
  • RAID 5 is intended to provide single-drive failure tolerance, not protect against multiple drive failures, corruption, accidental deletion, or other data loss. It is not a backup strategy. A separate backup and recovery plan must be defined before household data is trusted to the service.
  • Expandability is a goal for the overall storage design. Whether the initial RAID 5 array itself can be expanded, and what procedure that would require, depends on the selected RAID and filesystem implementation and remains unverified. Additional NAS hardware is a possible capacity expansion path.
  • The external NAS connection method is undecided. For the Ethernet option, link aggregation, failover, addressing, and required switching equipment are not yet specified; two 2.5 Gbps connections do not by themselves establish a particular throughput or resilience behavior.
  • Storage-device compatibility, drive health monitoring, failure handling, restore procedures, and performance require validation on the target Proxmox host.

Implementation status: Concept only. No household file-sharing service, RAID array, external NAS attachment, or backup/recovery workflow is configured or validated.

  • Household AI ↔ Maintenance AI Delegation Model (Concept)

Status: Concept

Objective: Separate conversational interactions from operational analysis by establishing Maintenance AI as the authoritative diagnostics engine and Household AI as the user-facing communication layer.

Responsibilities:

  • Household AI: chat, research, voice interactions, and user-facing explanations.
  • Maintenance AI: diagnostics, incident analysis, infrastructure awareness, maintenance workflows, and runbook execution.

Design notes:

  • Maintenance AI primarily communicates through the AI Interface/Dashboard.
  • Household AI may request diagnostics on behalf of a user.
  • Maintenance AI findings are persisted as operational records.
  • Household AI translates operational findings into audience-appropriate responses.

Implementation status: The single-GPU Utility/Household/Maintenance model-profile architecture is planned separately, but the backend does not provide it yet. This broader delegated workflow and runbook execution also remain unimplemented. Any future diagnostic request, operational record, and execution path must preserve the project's authorization, audit, and observe-first constraints.

  • Maintenance AI Context Inference Layer (Concept)

Status: Planned

Phase: Future Development

Priority: Medium-High

Overview: Provide the future Maintenance AI with relevant operational context on demand, so responses can be grounded in current platform state and historical operational knowledge rather than conversation history and static system prompts alone. Keep retrieval request-scoped and bounded; the goal is to avoid permanently expanding model context requirements, VRAM use, or prompt size. Retrieved context may add tokens to an individual request, but must not become permanently resident model context.

Objectives:

  • Improve Maintenance AI accuracy by supplying relevant current evidence before generation.
  • Help distinguish resource pressure from model-management, process-state, or tracking issues using actual telemetry and operational records.
  • Reuse historical operational knowledge when relevant without loading an unbounded conversation or history into every request.

Illustrative example: These values are hypothetical, not live readings.

  • Current response: “VRAM usage appears high. Consider upgrading to a GPU with more VRAM.”
  • Desired response: “Current VRAM utilization is 9.2 GB out of 16 GB. Available headroom remains approximately 6.8 GB. The reported issue is more likely related to model management or process tracking than GPU memory availability.”

Design notes:

  • Candidate context includes current telemetry, model/runtime state, reviewed runbooks, and relevant historical incidents. Source selection, freshness, retrieval method, context budget, and integration with the future diagnostic retriever remain to be designed.
  • Knowledge-data provisioning is a prerequisite to resolve. The current reviewed runbooks are Python-defined in ai-backend/diagnostic_knowledge.py and searched in process memory; there is no runbook/context SQLite schema, import or seed tool, or separate content-deployment path. The configured SQLite memory file currently holds conversation/admin-note tables and observe-only diagnostic history, not a curated knowledge catalog.
  • Decide whether curated runbooks and operational context belong in a separate persistent database or in dedicated tables in an existing store. Keep them logically separate from private chats, admin-shared notes, and diagnostic event history, with clear ownership, access, and retention.
  • Research a reviewed, versioned data format and a validated, idempotent import/seed process. Define provenance and review metadata, schema/content versioning, update and retirement behavior, transaction boundaries, compatibility checks, backup, rollback, and repeat-import tests.
  • Deployment must not assume a pre-populated database can ship in an application release: the Stage 1 bundle verifier rejects SQLite/database files and releases requiring data migrations, and Stage 1 only verifies and stages bundles. Evaluate a separate signed knowledge-data package or an explicitly designed migration/import workflow; neither exists today.

Context Collection Framework:

Before Context Inference is implemented, define how operational context is collected, refreshed, validated, stored, and expired. Operational context records should be populated and refreshed automatically from authoritative platform sources, not manually entered or maintained. Collection cadence, refresh triggers, failure handling, and expiry rules remain to be designed.

Potential collectors:

  • Hardware inventory collector
  • Model inventory collector
  • Runtime profile collector
  • Deployment status collector
  • Diagnostics collector
  • Proxmox inventory collector
  • Service state collector

Record and authority boundaries:

  • Store collected snapshots as structured SQLite records. Choose the database and table boundary as part of the storage decision above. Records should retain source identity, observation/refresh time, schema or source version, and freshness/expiry state; stale or unavailable data must not be presented as current.
  • Platform services remain the source of truth. Collectors may read from approved authoritative sources and update derived context records; the Maintenance AI may retrieve those records but must not create or modify authoritative platform facts. Any model-generated hypotheses must remain separate and explicitly non-authoritative.
  • A Diagnostics collector may ingest already-persisted observations and incidents. It must not itself trigger probes, scheduled diagnostics, or remediation; those require separate approval and design. This preserves the current manually triggered, observe-only diagnostics boundary.

  • Automatically refreshed context snapshots are distinct from curated runbooks: runbooks remain versioned, human-reviewed source material and require the separate provisioning path described above.

  • Retrieved evidence must be bounded and attributable to its source. Missing or stale data must be reported as unavailable rather than inferred.

  • Context retrieval does not grant authority to execute commands, change configuration, or perform repairs.
  • The Maintenance AI role itself is planned, not implemented. Existing diagnostics are manually triggered and observe-only; local lexical runbook retrieval does not invoke the model, and historical-case retrieval and model-assisted diagnosis remain unimplemented.
  • See the AI Diagnostics design for the broader future retriever and diagnostics workflow.

Implementation status: Planned concept only. No general Maintenance AI context inference layer, historical operational retrieval, context collectors, SQLite context schema, or data provisioning path is implemented.

  • Shared Incident Reporting and Administrative Visibility (Concept)

Status: Concept

Objective: Ensure diagnostics, incidents, and maintenance findings generated by the Maintenance AI are recorded as operational events in the AI Interface/Dashboard rather than existing only in individual user conversations. This extends the existing bounded diagnostics incident history: household-request attribution, a shared operational timeline, and updates linked to the same incident are not implemented.

Planned scope:

  • Record diagnostics initiated by household members.
  • Associate incidents with the reporting user while preserving operational visibility.
  • Expose findings, status changes, and resolution history to authorized administrators.
  • Maintain a timeline of infrastructure-related incidents and investigations.
  • Allow Household AI to translate Maintenance AI findings into user-friendly explanations without duplicating operational records.

Example workflow:

  1. A household member reports a problem.
  2. Household AI requests diagnostics from Maintenance AI.
  3. Maintenance AI generates findings and records an incident.
  4. The incident appears in the AI Dashboard for authorized administrators.
  5. Household AI translates the findings into a user-friendly response.
  6. Future updates and resolution activity attach to the existing incident record.

Long-term vision: Treat diagnostics and maintenance activities as shared operational records instead of private chat messages, enabling historical analysis, administrative oversight, and future automated maintenance workflows.

Implementation status: Concept only. No household incident attribution, shared Maintenance AI event workflow, or linked household-facing incident updates are implemented.

  • Network-Aware Diagnostics (Concept)

Status: Concept

Objective: Extend the Maintenance AI's diagnostics from AI Server health to household network and infrastructure awareness, so reported connectivity problems can be investigated using correlated, evidence-based observations.

Responsibilities:

  • Maintenance AI: gather configured read-only telemetry from supported access points, routers, switches, and relevant services; correlate WAN, LAN, wireless, and client evidence; distinguish possible ISP outages, routing faults, wireless congestion, access-point failures, and client-specific issues; and produce findings and recommendations.
  • Household AI: accept household questions such as “The internet is down,” “The Wi-Fi is slow,” or “The Quest headset is lagging”; request diagnostics on the user's behalf; and explain findings in a user-appropriate way.

Design notes:

  • Initial integrations must be observe-only and use explicitly configured, least-privilege read access. Unavailable telemetry must not be presented as healthy.
  • Findings, evidence, and incident history should support trend and recurring-issue analysis; recommendations must remain separate from operational actions.
  • The proposed single-GPU runtime keeps Utility AI available while an on-demand diagnostic request activates the Maintenance profile. The current one-model llama.cpp manager cannot do this: profile routing, resident Utility availability, and safe transitions are not implemented or validated. This is separate from scheduled maintenance and does not itself authorize remediation.
  • Any guided or automated recovery requires separately reviewed authorization, confirmation, audit, verification, and recovery controls. The AI must not change network configuration or promote its own authority.

Implementation status: Concept only. It is not assigned to a phase or selected as the next priority. No network telemetry provider or end-to-end network diagnostic workflow is implemented. See the diagnostics design, and infrastructure contracts for current constraints and safety boundaries.

  • Conversational Household Interface (Concept)

Status: Concept

Objective: Let household members interact naturally with household services, diagnostics, and maintenance through a user-facing conversational interface, without requiring direct dashboard access for every request.

Configuration:

  • An administrator can configure a household-shared Household AI display name in the Dashboard. The display name appears in the Dashboard and conversational interfaces.
  • Configure a separate phonetic pronunciation for future speech recognition and voice interactions. The system may suggest a pronunciation from the display name, but an administrator must be able to review and override it.

Responsibilities:

  • Household AI: handle chat and research, accept future voice requests, provide spoken or written status and explanations, and route authorized diagnostic requests to Maintenance AI.
  • Maintenance AI: perform the delegated operational analysis and provide diagnostic findings for user-facing explanations and maintenance summaries.

Design notes:

  • Local speech-to-text (STT) and text-to-speech (TTS) are candidate capabilities; technologies, models, microphones, speakers, and deployment topology have not been selected.
  • Use the configured pronunciation, rather than assuming the display name will be spoken or recognized consistently, for future spoken invocation. When the AI is addressed by its configured name, the interface should recognize that it is being queried, accept the following request, and provide an appropriate response. Design clear listening-state feedback and safeguards against unintended activation.
  • Consider a future voice-recognition test that lets a user verify recognition confidence for the configured invocation name.
  • The display name, pronunciation, invocation cue, and recognition confidence must not establish identity, authentication, authorization, or privileges.
  • Household enrollment, consent, audio retention, and safeguards against unintended or overheard requests must be defined before implementation.
  • No STT/TTS engine, phonetic standard, external pronunciation service, or implementation method is selected at this stage.
  • Requests must remain within the caller's authorized role. A symptom request may use the bounded Maintenance AI handoff described in the Network-Aware Diagnostics concept above, but operational changes require separate approval and recovery controls.
  • Any proactive notifications for critical incidents or maintenance events must be opt-in and avoid exposing sensitive household or infrastructure details to unauthorized listeners.

Implementation status: Concept only; none of this voice-interface capability is implemented. No Dashboard name/pronunciation setting, pronunciation suggestion, invocation recognition, confidence test, local STT/TTS integration, household enrollment/authorization workflow, or notification channel has been selected or implemented.

  • Dual-GPU Service Separation (Concept)

Status: Concept

Objective: Evolve from a single runtime that swaps models to separate, simultaneously available Utility, Maintenance, and Household AI services. Avoid model swapping between Household and Maintenance workloads.

Responsibilities:

  • GPU 0, the planned RX 6800 XT Operations GPU, would keep Qwen2.5 1.5B Utility AI resident alongside Qwen2.5 Coder 7B Maintenance AI. Its responsibilities include Discord operations, diagnostics, runbooks, and infrastructure analysis.
  • GPU 1 would be a future, unselected Household GPU running Qwen3 8B and possible household-specific models for chat, research, voice, and family-facing services.
  • Users would select services and roles rather than model files. Utility AI could acknowledge an operational request and route analysis to Maintenance AI while Household AI remains available.

Design notes:

  • The RX 9070 XT is the current second-GPU candidate, not a selection or claim of confirmed suitability. Selection depends on ROCm support, VRAM, power/cooling, and measured local AI performance.
  • This is a service-per-GPU workload split, not a proposal to combine VRAM by splitting one model across both cards.
  • The physical server is not built and the second GPU is not selected or acquired. Simultaneous Utility/Maintenance residency on the RX 6800 XT, Household inference on GPU 1, runtime compatibility, service routing, and recovery have not been validated.

Implementation status: Concept only. The current model manager runs one active model and restarts it when switching. No dual-GPU routing or concurrent service implementation exists. See the GPU plan.

Documentation References