Problem
AppToHTML currently treats crawls as independent crawl sessions. For a given target application, the product should maintain only one saved crawl at a time and let the user either start over or continue from a previously captured screen.
Resume should not be modeled as a separate backend mode for "last place." The last visited screen is simply a known screen ID and should use the same resume-from-screen behavior as any other captured screen.
Requirements
1. One saved crawl per target app
For each target application package, AppToHTML must store only one crawl.
When the user starts a New Crawl for an app that already has saved crawl data:
- Delete or replace the existing crawl for that app immediately.
- Create a fresh crawl session for the same package.
- Ensure stale screens, manifests, graph files, logs, HTML, and XML files are not mixed into the new crawl.
2. Crawl start choices
The crawler UI must offer two top-level options for the selected app:
New Crawl starts a fresh crawl and replaces the existing crawl for that app.
Resume Crawl is available only when the selected app has an existing saved crawl with at least one captured screen.
3. Unified resume screen picker
When the user chooses Resume Crawl, the app must show a list of previously captured screens from the saved crawl.
The first option should be the last visited screen, labeled clearly, for example:
The user may either select that first option or choose any other captured screen from the list.
There should be no separate backend mode such as ResumeFromLastPlace.
All resume choices should resolve to:
ResumeFromScreen(screenId)
The last visited option is simply:
ResumeFromScreen(lastVisitedScreenId)
4. Resume behavior
When resuming from a selected screen:
- Load the saved crawl manifest for the selected app.
- Identify the selected screen record by
screenId.
- Restore or relaunch the target app.
- Replay the saved route from the app entry screen to the selected screen.
- Rescan the selected screen.
- Replace the old child subtree below that selected screen.
- Continue crawling deeper from the refreshed selected screen.
The resumed crawl should preserve the existing crawl as the same app-level crawl, not create a second crawl for the app.
5. Last visited screen tracking
The crawler must persist enough progress metadata to know the last visited screen.
"Last visited" means the most recent captured screen that the crawler was actively preparing to expand or expanding.
This value should be written into the saved crawl state/manifest during crawl progress so it survives app or process interruption.
6. Saved crawl screen list
The saved crawl should expose a screen list for the UI containing enough data to render useful choices, such as:
- Screen ID
- Screen name
- Depth
- Parent/route context if available
- Whether it is the last visited screen
The resume picker must avoid duplicate entries if the last visited screen is also present in the normal captured screen list.
Acceptance Criteria
- Starting
New Crawl for an app with an existing crawl leaves only one saved crawl for that app.
Resume Crawl is disabled or hidden when no saved crawl exists for the selected app.
Resume Crawl opens a screen picker.
- The first picker item is the last visited screen and is labeled
(Last Visited).
- Selecting the last visited item and selecting any other screen both use the same
ResumeFromScreen(screenId) path.
- Resuming from a screen navigates to that screen, rescans it, removes its stale child branch, and continues crawling deeper.
- Existing live pause/continue checkpoint behavior remains separate and continues to work.
- Completed crawls can still be resumed from any captured screen.
Suggested Tests
- New crawl replacement deletes/replaces prior app crawl artifacts.
- Manifest read/write round trip preserves screen records and last visited screen ID.
- Resume picker ordering puts the last visited screen first.
- Resume picker does not duplicate the last visited screen.
ResumeFromScreen(lastVisitedScreenId) follows the same code path as any other selected screen.
- Resuming from a chosen screen prunes its old descendants and captures the refreshed child branch.
- Existing pause/resume checkpoint tests continue passing.
Problem
AppToHTML currently treats crawls as independent crawl sessions. For a given target application, the product should maintain only one saved crawl at a time and let the user either start over or continue from a previously captured screen.
Resume should not be modeled as a separate backend mode for "last place." The last visited screen is simply a known screen ID and should use the same resume-from-screen behavior as any other captured screen.
Requirements
1. One saved crawl per target app
For each target application package, AppToHTML must store only one crawl.
When the user starts a
New Crawlfor an app that already has saved crawl data:2. Crawl start choices
The crawler UI must offer two top-level options for the selected app:
New CrawlResume CrawlNew Crawlstarts a fresh crawl and replaces the existing crawl for that app.Resume Crawlis available only when the selected app has an existing saved crawl with at least one captured screen.3. Unified resume screen picker
When the user chooses
Resume Crawl, the app must show a list of previously captured screens from the saved crawl.The first option should be the last visited screen, labeled clearly, for example:
The user may either select that first option or choose any other captured screen from the list.
There should be no separate backend mode such as
ResumeFromLastPlace.All resume choices should resolve to:
ResumeFromScreen(screenId)The last visited option is simply:
ResumeFromScreen(lastVisitedScreenId)4. Resume behavior
When resuming from a selected screen:
screenId.The resumed crawl should preserve the existing crawl as the same app-level crawl, not create a second crawl for the app.
5. Last visited screen tracking
The crawler must persist enough progress metadata to know the last visited screen.
"Last visited" means the most recent captured screen that the crawler was actively preparing to expand or expanding.
This value should be written into the saved crawl state/manifest during crawl progress so it survives app or process interruption.
6. Saved crawl screen list
The saved crawl should expose a screen list for the UI containing enough data to render useful choices, such as:
The resume picker must avoid duplicate entries if the last visited screen is also present in the normal captured screen list.
Acceptance Criteria
New Crawlfor an app with an existing crawl leaves only one saved crawl for that app.Resume Crawlis disabled or hidden when no saved crawl exists for the selected app.Resume Crawlopens a screen picker.(Last Visited).ResumeFromScreen(screenId)path.Suggested Tests
ResumeFromScreen(lastVisitedScreenId)follows the same code path as any other selected screen.