Launch lifecycle: keep ordinary saves and confirm saving only after explicit Exit game #49

Current owner decision — Home is not an exit request

#112 owns the adaptive physical Home/Guide menu. Pressing Home opens that menu; it must not immediately ask whether the user saved, start graceful termination or end the recorded play session.

Only choosing Exit game starts the exit flow in this issue. This supersedes the earlier direct Home → save question interaction, not the ordinary-save safety model.

Start retains its existing settings, power and quick device controls under #86. Do not copy those controls into Home. #111 owns the new five-tab navigation and launch/return route migration.

Ordinary saves remain authoritative

TrainerOS does not create, manage or resume emulator savestates in the normal product flow. The authoritative game state is the game's own ordinary save/autosave data.

Relaunch after termination starts the game normally and lets it load its own save. In contrast, Continue in an open Home menu simply returns input/display to the same still-running process: no launch, savestate restore or save rewrite occurs.

This preserves the earlier decision superseding ResumePoint/save-state-based Continue. A runtime's internal transient netplay synchronization is not permission to introduce persistent TrainerOS ResumePoints; its compatibility is independently reviewed by #107.

Why

A second persistent RAM/savestate timeline conflicts with safe save-backed features such as Care Center services, Party/Storage changes, healing, native Link exchanges, live Field Guide progress, Journey/Hall, backup/restore and future exact-game adapters.

Keep one authoritative ordinary-save path. Opening a menu, viewing friends or changing a visual preset must not imply either that the game was saved or that its save is safe for external mutation.

Exit flow

Home → adaptive menu (#112)
    ├─ Continue / Home again / Back → same live game
    ├─ Appearance / friends / eligible actions → remain in the active session
    └─ Exit game
          → capture clean current game image
          → inspect the exact title's save policy
             ├─ manual / unknown → ask whether the user saved
             │      ├─ Yes → graceful exit
             │      └─ Not yet → same live game, no termination
             └─ verified autosave → graceful exit without the manual question
          → confirmed process exit → restore the original shell context

Revalidate the actual running owner/Adventure/session before capture, confirmation and close. A mutable selected game in another UI must not retarget an existing exit attempt.

A new explicit exit attempt requires fresh input. Repeated Home/A events, stale asynchronous capture results or an earlier session's confirmation cannot trigger another close. Cancel and failure do not mark the session as successfully ended.

Screenshot-first requirement

Capture a clean current frame from the game after explicit exit intent and before the save question, without including the Home menu, chat, appearance picker or any confirmation overlay.

The Home menu may already cover the game at that point. #112 must supply game-only capture or a guarded overlay-hide/capture sequence that preserves input isolation. Do not simply capture the composite screen and assume it is clean. Do not relabel an old Home-menu preview or another game's image as a fresh exit screenshot.

The verified exit image powers Home backgrounds (#15), Y/recent cards (#9), play history and optional explicitly selected Hall media. It is not a savestate thumbnail.

Retain existing capture-failure safeguards. Missing capture must not invent image freshness, force termination or turn an unsuccessful exit into a successful history record. Record the actual outcome through the existing lifecycle/media service.

Save policy metadata

Do not guess autosave behavior from platform alone. Use the exact title/integration's verified policy:

savePolicy = manualConfirm | autosave | unknown

• manualConfirm: ask after Exit game is selected.
• autosave: omit only that manual question; still use the verified graceful-close and safety path.
• unknown: ask conservatively after explicit exit.

The prompt is a user confirmation, not a claim that TrainerOS detected a successful in-game save. Do not force-kill a game or ignore a known active write merely because its general policy is autosave.

Manual-save UX and input

The user-facing idea remains: save in the game, then choose Exit game.

Not yet dismisses the exit UI and returns to the same process, without rewinding state. While a game is not paused, time may continue: do not promise a frozen frame or pause every multiplayer session. #112 owns any independently verified pause policy and input/focus handoff.

B backs out of appearance/chat subpanels normally. In the save question it cancels the exit. No Home/B path may silently accept that question. Preserve release/neutral requirements between layers, helper/watchdog recovery and the existing handling of spontaneous process exit.

Safe system activities are separate

Home may offer invitations to native TrainerOS Link actions as well as runtime multiplayer, but save-changing native execution stays behind #42/#45/#75/#76 and #109/#110.

Pausing or covering a game does not make its ordinary save safe to edit. Where a chosen activity requires the game closed, use this explicit safe-exit flow first. Cancelling the exit must not leave an automatically executing trade or bypass current-source/bilateral approval checks.

No savestate product surface

Retire normal TrainerOS ResumePoint, state-slot, state-thumbnail, restore-from-state and hidden automatic state-capture paths. Keep existing ordinary saves and independently useful media/history.

Y remains a Choose Adventure / recent selector: A selects, normal launch starts the game, and the game loads its ordinary save. It never restores suspended RAM. Returning to a still-running game through Home is different from relaunch after termination.

Developer/maintenance inspection of runtime capabilities does not create a second user-state ownership model.

Crash / forced termination

A crash, OS kill, power loss or emulator failure is not a safe confirmed exit. Preserve previous valid history/media as appropriate, report interruption honestly and rely on the last actual game save/autosave. Do not fabricate save confirmation, a clean capture or bilateral transaction success.

Helper or menu failure must not force-kill the game. Pending native Link journals remain owned by their recovery service, not by menu teardown.

Multiverse and migration

The same normal no-ResumePoint and explicit-exit rules apply beyond Pokémon. Unsupported/manual/unknown titles do not gain fake autosave or instant-resume support.

Migration retires only clearly owned obsolete TrainerOS state artifacts; never delete user/emulator ordinary saves or unrelated files. Preserve useful media and history. Follow #111 when restoring old launch/return checkpoints: old Journey/Hall routes now map into Trainer, not into the new Social tab.

Update active Help and lifecycle guidance to describe Home menu → Exit game → save confirmation, while preserving dated evidence of the older direct-question implementation as historical.

Tests and acceptance

• Opening/closing Home does not ask about saves, terminate a game or close its history session.
• Continue restores the same live process without launch or persistent savestate operations.
• Explicit Exit game alone starts capture and the save-policy flow.
• Manual/unknown titles ask; verified autosave titles omit only the manual question.
• Not yet/Home cancellation returns safely without termination or a false successful-exit record.
• Exit images contain the actual game, never Home, chat, appearance or confirmation UI.
• Capture failure, stale session results, repeated/held input and spontaneous process exit remain safe.
• Graceful-close failure and helper loss preserve a recoverable live session where it still exists.
• Native save-changing actions cannot execute while the relevant game remains active or after cancelled exit.
• Y/Home media, ordinary relaunch, existing saves and per-Trainer ownership survive migration.
• Launch/return restores the correct new Navigation: merge Trainer and Journey, and dedicate the rightmost primary tab to Social #111 page/face without losing historical records.
• Physical acceptance covers supported manual/unknown/autosave routes, repeated Home open/close, cancellation and clean capture on the actual handhelds; untested runtime routes remain unproven.

#112 owns menu/input presentation, this issue owns safe termination and ordinary-save lifecycle, and #111 owns primary/secondary navigation migration. Do not implement parallel competing exit controllers.