sgc-electron-app-relaunch

Electron App Restart

Provide users with an entry point to truly restart the desktop app, and maintain the correct process lifecycle in development mode, production mode, and during update installation.

Triggers

Activate when

The user says "add a restart App to the menu", "implement restart Yoda", or "fully restart Electron".
The user conflates Cmd+R, reload, relaunch, and quit-and-reopen, and the actual behavior needs to be fixed.
User asks to “restart the app from a menu”, “use app.relaunch”, or “make Electron dev restart reliable”.

Do not activate when

The user only needs to refresh the page or recover a certain renderer error boundary; use renderer reload.
The user wants to restart a single Agent/terminal session; use the session lifecycle or PTY workflow.

Workflow (MANDATORY)

You MUST follow these steps in order.

Step 0: Name the intended action

Map every proposed UI entry to exactly one intent: renderer reload, full app relaunch, or update installation handoff.
Do not bind a standard reload shortcut to full relaunch by accident. In Electron, the built-in View reload role commonly owns Cmd+R / Ctrl+R.
Read references/relaunch-contract.md before implementation.

Step 1: Centralize the relaunch path

Put full-app restart in one main-process function, then invoke it from the native menu or typed IPC.
In packaged production, call app.relaunch() followed by app.quit().
In development, relaunch the actual dev entrypoint with the Node executable and arguments that started the app; do not assume a packaged executable exists.
Keep renderer reload separate and label it accordingly in the UI.

Step 2: Preserve process ownership

Let main-process shutdown hooks complete according to the product's session policy.
Do not use the ordinary relaunch function to install an update. The updater must take control only after cleanup and staging have completed.
When child processes, PTYs, local servers, or single-instance locks exist, define whether each survives, shuts down, or is reattached after restart.

Step 3: Verify the real instance

Add focused tests for the dev command construction and production relaunch path.
Run the app, record its PID, executable path, working directory, and start time.
Trigger the native menu item once, then confirm a replacement instance is running with a newer start time and the intended executable.
Do not accept bundle text, menu existence, renderer reload, or a successful build as proof of full restart.

Dependencies

Electron main-process access to app and the target project's development command.

General Feedback Loop

When the user raises modification feedback during a Skill-driven task, before continuing the current artifact you must perform:

First determine whether the feedback is task-specific(this time only) or reusable(reusable across tasks).
task-specific Only modify the current task, do not change the Skill.
reusable First determine the scope: for domain rules, first update the corresponding canonical Skill; for rules that apply to all Skills, first update the shared specification.
After completing the rule update, versioning, lint, and distribution verification, then apply the modification to the current task.
reusable The modification invalidates previous "confirm", "continue", and "send it"; after completing the current artifact modification and read-back, you must stop and wait for the user's next instruction, and must not automatically proceed to publishing, committing, or other external writes.