Install, update and release experience — how should WorldScript stay current without interrupting writing?

[qnbs]

Why this exists

Authors need WorldScript to stay current without interrupting an active writing session. Issues #485 and #486 provide the primary Service Worker and installed-PWA context for this product conversation.

Product decision space

Consider browser tabs, installed PWAs, and packaged desktop builds separately. Update-ready messaging should be visible without being noisy. Dirty work, acknowledged edits, multi-tab or multi-window activity, and offline operation should be able to defer an unsafe activation or restart until the state is safe.

Discuss release notes, version and build diagnostics, rollback and recovery, and how users understand whether they are running a current build. Zero-install convenience and packaged-native integration have different update mechanics. Stable and beta channels are open questions, not commitments.

Notifications and badges should be restrained and actionable. A user should not be pressured into losing work for an update, but security updates should have a clear path and an honest explanation of urgency. The same lifecycle model should avoid silent data loss across browser, installed-PWA, and desktop surfaces.

Role perspectives

Role-perspective note: The viewpoints below are maintainer-curated, AI-assisted design lenses. They are not separate community members, votes, user testimony, or evidence of consensus.

• ✍️ Author in a long writing session: never interrupt or discard acknowledged work; make deferral predictable.
• 🌐 PWA user: understand tab, installed-PWA, offline, and reload behavior without platform jargon.
• 🖥️ Packaged-desktop user: receive safe updater, restart, rollback, and version diagnostics.
• 🧪 Update reliability: prove lifecycle state transitions, multi-client coordination, recovery, and failure handling.
• 🔐 Security-update perspective: make important updates visible and actionable without unsafe forced reloads.
• 🧭 Release maintainer: keep channels, notes, badges, and operational support bounded and truthful.

Questions

• How should an update-ready state appear during active writing?
• When should a dirty tab, installed PWA, or desktop window defer activation?
• What release-note and build-diagnostic detail is useful to authors?
• How should offline updates, failed updates, rollback, and recovery be explained?
• Would stable/beta channels help, and what support cost would they introduce?
• Which notifications or badges are helpful rather than distracting?
• What must be identical across PWA and packaged desktop, and what may be platform-specific?

Relationship to implementation

This Discussion is install, update, and release UX exploration. #485 and #486 remain the implementation and acceptance authorities; this Discussion does not change their priority, roadmap admission, acceptance criteria, or execution sequencing.