# Autoresearch: tauri-runtime-lifecycle-acceptance ## Objective Harden the Tauri desktop runtime manager around lifecycle acceptance so the saved runtime flow stays trustworthy from configuration through apply/start behavior. This segment focuses on the app-surface contract: local/remote mode transitions should show the right controls immediately, local startup should stay driven by the saved runtime state, and the verification harness should score the desktop runtime instead of the old CLI surface. ## Metrics - **Primary**: runtime_lifecycle_score (percent, higher is better) - **Secondary**: unit_passed, build_passed, cargo_check_passed, local_mode_cta_passed, saved_startup_flow_passed, local_onboarding_flow_passed, health_revalidation_passed ## How to Run - `./autoresearch.sh` - `cd tauri-app && npm test -- src/features/runtime/runtime-utils.test.ts src/features/runtime/components/RuntimeSurface.test.tsx` - `cd tauri-app && npm run build` - `cargo check --manifest-path tauri-app/src-tauri/Cargo.toml` ## Files in Scope - `tauri-app/src/App.tsx` - app shell ownership for runtime and model connectivity - `tauri-app/src/components/Sidebar.tsx` - sidebar entry point for runtime controls - `tauri-app/src/features/runtime/` - unified runtime domain, UI, utils, and Tauri API wrappers - `tauri-app/src/index.css` - global visual tokens for the desktop app - `tauri-app/src/hooks/useModels.ts` - model loading through resolved runtime connection - `tauri-app/src-tauri/src/runtime/` - backend source of truth for runtime config/state - `tauri-app/src-tauri/src/lib.rs` - command wiring and legacy compatibility seams ## Off Limits - `models/` model binaries - `vendor/` third-party sources and prebuilt llama binaries - unrelated CLI autoresearch files and crates unless a runtime experiment explicitly needs them - unrelated latency/template experiments ## Constraints - Backend/Tauri remains the source of truth for runtime config and process state. - The frontend should expose one startup/config flow, not parallel state machines. - Remote mode must never silently fall back to localhost. - Verification must include `npm test`, `npm run build`, and `cargo check`. - Preserve existing chat/model behavior outside the runtime-management refactor. ## What's Been Tried - Earlier autoresearch segments 0-17 focused on latency, dynamic chat templates, and a CLI management surface. The latest completed CLI segment (`localllm-cli-ureq-transport`) reached `100.0%` on run 39 (`9860d64`), but that objective is now stale for the desktop app work. - The Tauri chat layer was previously fixed so new conversations persist correctly, `...` content is separated into a collapsible thinking panel, and per-message/per-chat token accounting is stored and rendered. - The first runtime-manager slice introduced a backend runtime domain in `tauri-app/src-tauri/src/runtime/`, a frontend runtime feature in `tauri-app/src/features/runtime/`, a compact sidebar status card, and a settings drawer. - Review of that slice exposed two major correctness issues that were fixed: remote mode no longer falls back to localhost, and runtime config changes that would drift away from a running child process are now blocked with a restart-required error. - Even after those fixes, the runtime manager still failed in practice because the app kept two frontend control planes: the new runtime card/drawer started the backend from `RuntimeState.inner.config`, while the embedded legacy `ServerPanel` still edited local model/runtime settings through `save_config`, which only wrote the config file and did not update the in-memory runtime state used by the new start buttons. - The latest experiment resolves that split by removing `useServerProcess` and the embedded legacy `ServerPanel` from the active sidebar flow, moving local runtime configuration into the unified runtime drawer, and making the sidebar card either open setup or start the saved runtime config from the same domain. - The runtime visuals were also refactored toward a cleaner AI-desktop feel with updated runtime card/drawer styling, a more deliberate font stack, cooler blue-cyan accents, and less of the earlier purple-heavy sidebar look. - The current experiment hardens readiness detection in `tauri-app/src-tauri/src/runtime/health.rs` so startup now waits for a successful `GET /health` response with `{"status":"ok"}` instead of treating any open TCP port as ready. Rust tests now cover healthy HTTP, unhealthy payloads, and plain-open-port false positives. - The latest experiment adds app-surface smoke coverage for `RuntimeStatusCard` and `RuntimeSettingsDrawer`, then fixes a real regression in `chooseModel()` so a previously saved model path is preserved when a folder rescan returns no models. This keeps the unified drawer start action available for valid saved configs instead of silently disabling it. - The current experiment re-initializes the harness around the Tauri desktop surface by replacing the stale CLI benchmark with `experiments/bench_tauri_runtime_surface.py`, updating `autoresearch.sh` to score runtime-focused frontend tests plus build/check verification, and fixing a real drawer regression where switching from remote to local mode hid the primary local CTA until after save. - The latest experiment extends the runtime lifecycle acceptance contract with two hook-backed smoke checks: a saved local config must surface `stopped -> starting -> ready` through `useRuntimeManager`, and local onboarding via folder browse must auto-select a model, persist it, and reach a ready local runtime from the same drawer flow. - The latest experiment adds periodic runtime truthfulness checks after startup: `refresh_process_state()` now revalidates `/health` while the managed child is still running, downgrades stale `ready` state to `degraded` when the process stops serving correctly, and restores `ready` after recovery. The desktop surface test already rendered degraded snapshots correctly; the missing correctness gap was backend state revalidation. - Current keep criteria for this segment are: the desktop runtime benchmark targets the active Tauri surface, switching into local mode keeps the apply/start CTA visible immediately, saved local startup exposes `starting` before `ready`, onboarding can browse/save/start from one local flow, stale managed processes demote from `ready` to `degraded` when `/health` stops reporting ready, and verification stays green across Vitest, TypeScript/Vite build, and Rust compilation.