[M8] Package independent Windows Tauri client with secure Python sidecar lifecycle

[AllenXiao95]

Parent roadmap: #30

Positioning

The Windows desktop client is an independent productization track, not proof that Game Localizer needs a full agentic harness.

A Tauri shell can be valuable simply by packaging the existing Python application, Dashboard, project selection, native filesystem integration, lifecycle, and credential/session boundaries. It must not wait for a broad AgentRuntime before a technical packaging prototype is possible.

Priority is P2 within M8 because current engineering focus is Eval/TM/controlled intelligence foundations, not because desktop packaging has low product value.

Goal

Ship the first Windows x86-64 desktop client that starts and supervises a packaged Python sidecar, establishes a versioned local session securely, reuses the existing WebUI/application services, and fails closed when client/sidecar protocol or security assumptions do not match.

Phase 0: thin technical prototype

A prototype may begin independently of #7/#11 and should prove only:

Tauri -> packaged Python sidecar -> 127.0.0.1 random port -> health/protocol handshake -> existing Dashboard

Stop the prototype once packaging/lifecycle feasibility is demonstrated. Do not use it as an excuse to duplicate frontend or domain logic in Rust/TypeScript.

Production scope

Sidecar protocol

• dedicated sidecar entry point such as localizer-sidecar desktop-server --config <project.yaml> --port 0
• bind production sessions to 127.0.0.1 on a random port
• emit exactly one machine-readable startup handshake containing protocol version, port, PID, and project identity
• keep later business logs off the handshake channel
• gate writable UI readiness on /api/health plus compatible protocol/project readiness

Session/security boundary

• fresh short-lived session capability on each launch
• no session secrets in argv, URLs, local storage, Prompt files, or persistent logs
• mutating local APIs require the capability plus existing write-action protection
• fail closed on protocol mismatch
• constrain WebView external navigation; approved external links open in the system browser
• paths from native dialogs are revalidated in Python using resolved/scope-checked paths
• credentials use an OS-reviewed mechanism (or explicitly reviewed equivalent) and are injected only into the task that needs them

Lifecycle

• Tauri owns window/native picker/single-instance/sidecar lifecycle only
• Python application services remain authoritative for localization, TM, QA, build, and publish
• normal exit checks active run state before sidecar termination
• never silently kill a sidecar while checkpoint/TM writes are active
• unexpected client termination uses bounded cleanup and existing owner-lock/task-snapshot/checkpoint recovery on restart
• preserve explicit macOS/Linux packaging boundaries without requiring those platforms in the first release

Agent independence

• no AgentRun is required merely to start/use the desktop client
• if [M8] Extract minimal governed orchestration contracts when real workflows require them #7/[M8] Implement controlled Prompt Workbench with lint, patch proposals, eval, and baseline locking #10/[M8] Add TM repair advisor with reviewable proposals and human-gated apply #31/[M8] Validate and add release-readiness advisor over existing workflow evidence #11 later expose controlled intelligence capabilities, the desktop shell may surface them through the same Python APIs
• Tauri itself must never become the permission or domain authority for Apply/Release/Publish

Non-goals

• no rewrite of Python domain logic in Rust/TypeScript
• no second localization frontend/business implementation
• no multi-user account/collaboration system
• no bundled large LLM/model weights in the first installer
• no requirement to complete [M8] Validate and add release-readiness advisor over existing workflow evidence #11 before packaging the existing deterministic workflow

Acceptance criteria

• Windows x86-64 dev/package build launches sidecar + existing WebUI without a separately installed Python runtime
• sidecar selects loopback random port and emits exactly one parseable startup handshake
• incompatible protocol prevents writable-ready state
• write APIs reject missing/invalid session capabilities
• session material is absent from argv, URLs, local storage, and persistent logs
• external navigation is constrained and filesystem selections are revalidated server-side
• closing with an active task uses a safe lifecycle path rather than silently terminating writes
• crash/restart demonstrates bounded cleanup and recovery via existing task/checkpoint rules
• CLI, Dashboard, and desktop share the same Python application services
• desktop packaging works without depending on a generic Agent harness

Dependencies / priority

Priority: P2 in the M8 roadmap.

The sidecar packaging prototype is independent. Production integration should consume stable existing application/security contracts and may later expose controlled-intelligence APIs, but a full #7/#11 implementation is not a prerequisite for the desktop product itself.