Thisper/LEGACY_HARDWARE_VALIDATION.md

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.