--- name: revalidate-without-reset description: Refresh an already-rendered stateful application view in place instead of rebuilding it from empty. Use when a view the user is already looking at is re-fetched because of app or window activation, focus or visibility change, reconnect, polling, a manual refresh control, mutation success, or a change in which resource the view shows, and when deciding what to keep, what to replace, and what to ask about. Not for first load, form save semantics, data-fetching library choice, or server-side cache revalidation. --- # Revalidate Without Reset **Counterexample:** A genuine identity, authorization, safety, or freshness-boundary change may correctly require a full reset or block the view. Treat those transitions as distinct from ordinary same-resource revalidation. **Default:** A refresh is not a reload. Re-fetch an already-rendered stateful view in place instead of rebuilding it from empty. ## 1. Know What Changed - Inventory every refresh producer: app or window activation, focus or visibility change, reconnect, polling, a manual refresh control, mutation success, and a change in which resource the view shows. Carry its semantic reason through the request and state transition. - Never merge independent refresh producers into one value. Producers that require different behavior need distinct signals even when they eventually invoke the same request. - Separate same-resource revalidation from identity, authorization, safety, and freshness-boundary changes. **Reset only when the identity of what is shown changes.** Block or replace state when an authorization, safety, or freshness boundary makes the existing view invalid. - Key refresh behavior, request latches, and derived values to stable resource identity rather than mutable wrapper objects. A tenant, repository, permission scope, or equivalent semantic identity change must not inherit stale resource-bound state. - Preserve the user's lens even during an identity reset: search, filters, sorting, pane sizes, and view mode remain unless they are invalid in the next identity. ## 2. Keep What the User Built - Preserve valid selection, rendered depth, dirty drafts, position, focus, and the last successful derived state. Replace only the state invalidated by the refresh reason or returned data. - Request at least as much data as is already rendered. Revalidate the visible depth instead of shrinking a deep view back to its initial page. - Deduplicate merged results and advance cursors from what actually arrived, not what the request expected to receive. - Only the newest request for a concern may write. Track ordering separately for concerns that may complete independently so a slow stale response cannot overwrite newer state. - A background refresh that fails keeps the last good state. Report the failure without blanking the view and provide a retry path. ## 3. Ask When Context Cannot Be Preserved - Require an explicit user decision before discarding affected unsaved work. State which work the incoming data invalidates and offer safe choices. - Hold structural updates when installing them immediately would move content the user is reading. Keep the current structure stable and provide an accessible apply action that explains the pending change. - Confirm user-initiated refreshes with an observable result, including a no-op success when the data is already current. - Name what the user would lose before adding hold-and-apply machinery. Apply the response in proportion to the view: 1. Always classify intent, separate identity loading, reject stale responses, and retain the last good state. 2. Preserve richer context only when the view contains it. 3. Add hold-and-apply UI only when immediate installation would destroy work or disorient the reader. If a refresh would move the user elsewhere to recover missing context or complete a prerequisite, load the peer `move-them-lose-them` skill and preserve a reliable return path. ## Boundaries Do not apply this skill to first load, renderer or process restarts, browser document reloads, server or CDN cache revalidation, data-fetching-library selection, offline merge architecture, or form-save semantics. Process destruction requires persistence and hydration, not in-memory revalidation.