---
title: "Verify a cached application shell survives candidate assets"
description: "Test an externally prepared cached sandbox shell after a release, checking lazy navigation recovery and build consistency when assets have changed."
canonical_url: "https://vostride.com/agent-library/release-regression/cached-shell-loads-new-chunk.md"
md_url: "https://vostride.com/agent-library/release-regression/cached-shell-loads-new-chunk.md"
content_kind: "recipe"
topic: "release-regression"
---

# Verify a cached application shell survives candidate assets

Test an externally prepared cached sandbox shell after a release, checking lazy navigation recovery and build consistency when assets have changed.

## Risk

A landing screen can work from cache while a later route requests a removed chunk. The fixture must preserve the old shell and document the product update-recovery behavior, then exercise a previously unopened lazy route.

## Fixtures

- An owned sandbox browser session with the previous app shell cached and a lazy feature route not yet opened.
- An external release and cache fixture that serves candidate assets and reports the old shell build and current asset manifest.
- A product requirement for stale-client recovery and a disposable record available in the lazy feature after any supported reload.

## Steps

1. Verify the fixture reports the prepared cached shell, then open the previously unused feature route and observe its documented update or recovery behavior.
2. If the product requests a reload, use its visible recovery control and verify the app returns to the intended route rather than losing navigation intent.
3. Open the fixture record on that route and verify its identifier and core content are visible without a blank panel or unresolved loading state.
4. Inspect the external asset trace and build report, verifying the final shell and loaded chunks form a supported version set and the feature route completed successfully.

## Expected results

- The lazy route recovers according to the product stale-client policy.
- The intended route and record remain reachable after recovery.
- Final assets belong to a compatible build set rather than a broken mixture.

## False-pass traps

- A clean browser cache never exercises the previous-shell asset mismatch.
- A working home page does not prove an unopened lazy chunk can load.

## Cleanup

- Close the cached fixture session and reset the external asset-serving policy.

## Use with agent-qa

Adapt this test design to your application's acceptance criteria and configured target using the [recipe execution guide](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md). External fixture setup and non-UI checks require your own supported hooks or test tooling. Validate the authored test, execute it, and inspect the completed evidence; this recipe is not a recorded test result.

## References

- [agent-qa first test](/docs/agent-qa/guides/first-test.md)
- [agent-qa hooks](/docs/agent-qa/guides/hooks.md)
- [agent-qa test](/docs/agent-qa/configuration/test.md)

- [Release regression QA recipes](/agent-library/release-regression.md)
- [Software factory QA library](/agent-library.md)