Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Review the restoration contract for [mobile editor] in [platform and existing stack]. Identify saved record data, an unfinished draft, selection, navigation position, and transient interaction state. Choose the appropriate supported owner and storage mechanism for each. Define what the user expects after rotation or recreation, backgrounding, system-initiated process loss, and a fresh intentional launch.
Preserve a recoverable draft according to that policy without treating it as an accepted saved record. Validate restored references and handle a record that was changed or removed elsewhere. A success label must correspond to the actual completed storage operation.
Verify each interruption through the platform’s documented testing workflow, plus missing or invalid local data and save failure. Record which scenario was actually exercised and what state survived. Explain where temporary state restoration ends and durable storage begins.Make this prompt yours
Name the target platform and lifecycle scenario precisely. Do not treat a simple background-and-return check as proof of process-loss recovery.
You might also hear
- process death
- draft restore
- mobile editor
- saved state
- rotation
- fresh launch
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Supported: Original restoration template. Android distinguishes ViewModel/saved state from persistence and process-loss recovery. Draft ownership and test scenarios remain platform-specific implementation requirements.