lov-electron-delta-updater

Electron Incremental Updates · Electron Delta Updates

Deliver a verifiable incremental update pipeline for an existing Electron app; judge by the user's actual installed package, public update feed and installation result, not by CI success.

Triggers

Activate when

The user says "add incremental auto-updates to this Electron app" or "check for updates keeps spinning".
The user mentions macOS Sparkle, appcast, DMG, blockmap, signing, notarization or delta update packages.
User asks to “add a delta updater”, “ship Sparkle updates”, or “verify an Electron update release”.

Do not activate when

The user only wants to change the version number, changelog or an ordinary download page; use version management or a release workflow.
The user wants web hot updates, PWA cache updates or mobile OTA; use the update mechanism of the corresponding platform.

Workflow (MANDATORY)

Follow these steps in order.

Step 0: Establish the update contract

Confirm the target platform, package format, current updater, update feed, signing responsibility, release channel and rollback expectations.
Commit to macOS delta-only as a release promise only after explicitly ruling out full packages.
Split check, download/staging, install handoff and post-restart verification into four states.
When handling macOS Sparkle, read references/electron-macos-delta.md; before changing the release pipeline, read references/release-verification.md。

Step 1: Make checks bounded and recoverable

Keep only one in-flight check per update service.
Pass AbortSignal to every layer of network calls, including the appcast request.
After a timeout, abort the request, wait for the old update state and connection to settle, then allow subsequent retries.
Configure the updater's own network session, avoiding treating the developer terminal proxy as runtime configuration.
After every timeout, download failure or feed format error, the UI keeps a retryable state.

Step 2: Enforce the artifact policy

Generate feed entries separated by architecture, and make each delta correspond to an explicit source version and target version.
Verify signature, length, architecture and URL before staging.
In delta-only mode, when a full-package fallback occurs, stop the current pipeline and show the manual installation path to avoid silently downloading a larger archive.
When a local feed proxy is needed, bind only to loopback, restrict to verified delta URLs, preserve HTTP Range behavior, and ensure resource URLs end with .delta .

Step 3: Coordinate install and restart

Hand off to the native updater only after app cleanup is complete.
Keep the process alive until the asynchronous install handoff is confirmed.
Use references/release-verification.md to verify the staged update and the installed version after restart.
Ordinary user-initiated restarts use lov-electron-app-relaunch。

Step 4: Validate the deliverable

Add tests for single-flight checks, timeout aborts, recovery of old checks, full-package fallback interception, feed proxy Range and asynchronous install handoff.
Run the project's applicable formatting, lint, type checking, test, packaging, signing and notarization gates.
Verify direct responses from the public release page and from appcast and delta resources; check the final artifacts' version, digest, size, signature and notarization status.
Report the update backend, supported platforms, verified URLs, installed-version evidence and any manual installation conditions.

Runtime context

Before running, read the skill.yamlin the same directory; it is injected by the host's skill-runtime in the order "current request, project context, personal configuration, brand Profile, secure defaults", using only the fields declared in the manifest.

Missing required: true field, follow questions to ask the user one focused question; the answer is used only for this run unless the user explicitly asks to save it.
Profile is used only for public brand facts; personal configuration is used only for decisions and is not automatically written into artifacts or source code.
Debug errors provide a copyable context_id, field path and source, without outputting secrets, full private paths or raw content.

Dependencies

An Electron project with a defined packaging and signing owner.
Sparkle tooling only for macOS Sparkle paths.

Runtime context (shared)

Before running, read this Skill package's skill.yaml, with the host providing the skill-runtime/v1 context. Field resolution order: current request, project context, personal Preferences, brand Profile, general defaults.

Use only the fields declared in the Manifest; Profile holds public brand facts, Preferences holds personal work preferences.
required: true When a field is missing, ask the user one focused question according to the Manifest's question configuration; save the answer only after the user explicitly agrees.
Errors provide a copyable context_id, field path and source, and diagnostic content avoids secrets, full private paths and raw configuration.

General feedback loop

When the user gives revision feedback during a Skill-driven task, the following must be done before continuing the current artifact:

First determine whether the feedback is task-specific(this run only) or reusable(reusable across tasks).
task-specific modifies only the current task, not the Skill.
reusable first determines the scope: domain rules update the corresponding canonical Skill first; rules applicable to all Skills update the shared specification first.
After completing the rule update, versioning, lint and distribution verification, apply the changes to the current task.
reusable A modification invalidates previous "confirm", "continue" and "send it" approvals; after completing the current artifact modification and reading it back, you must stop and wait for the user's next instruction, without automatically proceeding to publishing, committing or other external writes.