alex
b7fea83ed6
Deliver the initial local bridge, Noctalia v4/v5 adapters, desktop client, service unit, tests, and implementation documentation for persistent Pi status and control.
28 lines
1.5 KiB
YAML
28 lines
1.5 KiB
YAML
feature_name: tauri-pi-desktop-client
|
|
problem_statement: >
|
|
The current Noctalia panel is not reliably interactive or testable, while
|
|
users need a feature-equivalent Pi desktop client that works independently
|
|
of any status bar.
|
|
constraints:
|
|
- The bridge remains the only Pi process/session/recovery owner.
|
|
- The Tauri host uses only the local Unix bridge client and never opens TCP.
|
|
- Noctalia is an optional compact launcher/status compatibility layer.
|
|
- Folder selection is explicit and canonicalized by the bridge.
|
|
- Pi owns model, thinking, queue behavior, approvals, and extension policy.
|
|
- TUI-only custom extension UI must show unsupported and never auto-approve.
|
|
out_of_scope:
|
|
- Pixel-identical terminal TUI rendering.
|
|
- Arbitrary custom TUI extension component rendering.
|
|
- Auto-starting every remembered non-Home folder at login.
|
|
key_decisions:
|
|
- decision: One default composer
|
|
rationale: Mirror the confirmed TUI workflow without bridge-owned prompt/steer decisions.
|
|
- decision: Tauri owns the primary UI
|
|
rationale: Native host IPC plus frontend/unit/E2E testing is more reliable than a declarative status-bar panel.
|
|
- decision: Noctalia is a compatibility shim
|
|
rationale: It displays compact status and opens/focuses the standalone client without owning UI behavior.
|
|
- decision: Persist remembered folders and last selection
|
|
rationale: Remove manual ID/folder setup while preserving explicit selection.
|
|
- decision: Home agent is always running
|
|
rationale: Provide an immediately available default Pi instance.
|