Coordinate a console’s service worker and running page releases

Decide what the update notice actually means

A fictional AI console has a public help view, document D-A running release R-A, and a trusted worker W-A. A newly reviewed worker W-B belongs to release R-B. An “update ready” notice is ambiguous: are new bytes installed, is W-B active, or has a new document actually loaded R-B?

The reader’s decision is whether to keep the declared waiting rollout or force an immediate takeover. This worksheet selects waiting for one already-owned registration and public-help surface. It supplies no registration, interception, cache strategy or automatic reload implementation. Protected answers and tools stay on their separate authorization paths.

All eight cards are PROPOSED_UNRUN. R-A, R-B and the document and worker labels are invented associations, not observed browser objects or authenticated release identifiers.

Read the default lifecycle before changing it

MDN’s replacement-worker walkthrough describes the previous worker continuing to control its clients while its replacement installs. After successful installation, the replacement waits. Default retirement follows closure of the old controlled pages and completion of the old worker’s pending events; activation then precedes control of newly opened in-scope pages.

Keep those stages distinct. “Installed” does not mean “currently controlling this page.” Closing one visible tab does not establish that every relevant client and pending event has gone. This plan introduces no timer, client-enumeration algorithm or observation mechanism that could prove those conditions.

The proposed team records lifecycle evidence without treating an update notice as permission to discard resources or continue an old operation under a different release. Unknown state stays unknown; an operator’s expectation is not a substitute for the actual registration and client association.

Separate forced activation from adopting clients

The skipWaiting reference describes moving a waiting worker toward activation without normal waiting. Its promise resolves with undefined after trying to activate the newly installed worker; the method has an effect only when such a worker would otherwise wait.

The Clients.claim reference instead describes an active worker adopting clients in its scope and triggering controllerchange for clients that become controlled. Those documents may already have loaded over the network or through another worker. Its example explicitly avoids requiring a reload before their subsequent fetches use that worker.

These are different transitions. Neither return value is a release-compatibility certificate. A controller change does not establish replacement of the document’s already-loaded application code. Accordingly, this profile adds neither forced activation nor client adoption to bypass an inconvenient waiting state. A team choosing takeover needs a separately supported mixed-release design.

Keep a release ledger with independent evidence columns

Use one row per relevant document, not a single global “version” badge. The ledger is an audit design, not an authentication or coordination service.

PROPOSED_UNRUN — symbolic public-help ledger
Document: D-A | loaded code: R-A | established controller: W-A
Candidate: W-B / R-B | lifecycle: installed and waiting
Chosen policy: retain normal waiting; no forced takeover
Later admission: new D-B + established R-B + established W-B
Missing evidence: hold; never infer from a matching label

Attach provenance, actual registration and scope, document-code identity, controller association, compatibility review and evidence time to the row. Keep “expected” separate from “established.” A coherent pair does not prove safe application behavior.

The useful conditional positive preserves D-A’s existing public-help plan while W-B waits. Later, a separately established D-B/R-B/W-B association may admit that same bounded public-help function after the compatibility and lifecycle prerequisites are satisfied. This is neither a method for detecting that association nor evidence that any real browser reached it.

Walk eight release-admission cards

Make compatibility and current authority separate gates

Before a future implementation review, identify which old page and worker combinations the application actually supports. Record how its public resources remain usable during waiting, what happens on failure, and how a genuinely new document is distinguished. Do not delete an old release dependency merely because a replacement was downloaded. This worksheet provides no cache-cleanup recipe.

If waiting leaves a release unavailable, report that limitation honestly. Do not replace it with an unreviewed reload, adoption message or executable fallback. Any live-work handoff, pending effect, recovery mechanism or state migration needs its own evidence; none is selected here.

A new controller cannot refresh expired user rights or carry approval into a changed request. Conversely, keeping an older page open does not freeze authorization. Current server-side rights remain independent of the release ledger. Broader offline storage and retained-copy questions belong to the Cache API admission guide.

State exactly what remains unverified

The three maintained MDN bodies were read on 30 October 2026; their displayed modification dates were 25 September 2026, 13 May 2024 and 24 September 2024 respectively. They identify no tested browser build or deployed console. Actual provenance, secure-context registration, scope, controller association, loaded code, compatibility and current rights remain unimplemented prerequisites; unknown evidence blocks real admission.

For these proposed cases, no service worker was registered or updated, no lifecycle method or cache operation ran, and no browser, message or executable fixture was exercised. Boundary is prelaunch and does not ship this rollout controller. Its synthetic action exercise and existing mock evidence cover different behavior. No atomic rollout, immediate fleet upgrade, data erasure or security guarantee is claimed.