---
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.