# Legacy Hardware Validation

This report exists to close the remaining Phase 2 validation work against the target profile: older desktop hardware with limited RAM where Thisper must remain responsive and low-overhead.

## Validation Checklist

### Background Stability

- Scenario: Leave Thisper running in the tray/background for an extended period.
- Acceptance target: No crash, no hotkey loss, no visible UI freeze when restoring the window.
- Current evidence: User-reported runtime of more than 20 hours without API or stability failures.
- Status: `partially validated`

### Repeated Cross-App Rewrite

- Scenario: Use `Ctrl + Alt + R` repeatedly across plain-text targets such as Notepad and browser text boxes.
- Acceptance target: No destructive replacement on provider failure, no clipboard corruption after failures, stable repeated use without restart.
- Current evidence: Informal real-world usage is positive, but no structured pass is recorded yet.
- Status: `remaining`

### Long-Form Desktop Rewrite

- Scenario: Rewrite a multi-paragraph block through the main window and inspect diff/output toggles.
- Acceptance target: UI remains responsive during rewrite and the diff view reflects only actual edits.
- Current evidence: Main UI build path is working and has been used successfully, but no formal timing pass is logged yet.
- Status: `remaining`

### Successive Rewrites Without Restart

- Scenario: Perform multiple rewrites in sequence from both the main UI and the global shortcut flow.
- Acceptance target: No cumulative instability, no stale model state, no stuck loading state.
- Current evidence: Runtime observability is now present to support this pass, but the pass itself is still pending.
- Status: `remaining`

### Resource Footprint

- Scenario: Observe memory use and responsiveness on constrained hardware during idle, active rewrite, and tray-hidden states.
- Acceptance target: No runaway memory growth and acceptable perceived latency for short text.
- Current evidence: Build/runtime artifacts are large in development, but that is mostly `target/`; release footprint still needs explicit validation.
- Status: `remaining`

## What To Record During The Pass

- idle memory use
- active rewrite latency for short and medium inputs
- whether the tray/hotkey path remains responsive after long idle time
- whether clipboard restoration remains correct after both success and failure
- any target app classes that consistently fail or behave inconsistently

## Completion Rule

Phase 2 desktop validation is complete when each scenario above has an explicit observed result recorded here, including failures or caveats.