If an agent begins every request by reconstructing page structure, preparation repeats before useful work starts. Northstar has a passive preparation layer for the tab being viewed or switched to. Its scope needed limits so faster reading would not turn into continuous inspection of every background page.
Choose which tab deserves preparation
Automatic preparation in the current host excludes dormant pages and requires a visible, non-minimized window. The active and reference tabs are candidates. It does not begin by repeatedly reading every open background page; the preference is for a screen likely to be used.
An explicit attachment read differs from automatic eligibility. The explicit route can bypass the automatic eligibility predicate while still respecting dormant, destroyed and loading-page conditions. Limiting background automation and refusing a requested read are different decisions.
Do not read everything immediately for each switch event
Schedule replaces a per-tab timer and calls ensure after a short delay. Repeated switch events coalesce instead of accumulating independent preparations. If a promise for the tab is already pending, ensure waits on that same operation rather than starting another.
This cannot guarantee that every page becomes ready within a fixed duration. Loading, observation cost, network behavior and document changes still vary. The timer coordinates when preparation starts; it is not a workflow completion deadline. The interface should preserve that distinction.
Reuse unchanged structure without another observation
When document epoch, destination and revision match a cached entry, preparation updates its usage time instead of observing again or flashing a new status. The existing test checks that a second unchanged ensure increases neither read count nor UI-change count.
A revision is not a fingerprint of business success. It tracks observed page changes with implementation limits. Equality cannot establish valid login or successful external storage. The reused asset is reading material, not a completed-work verdict.
Recheck reading restrictions during preparation
Prepare checks reading allowance and the public destination before observing. Private profiles and excluded screens are not automatically prepared. Peek also rechecks allowance rather than treating a cached entry as a bypass.
Observation errors produce a waiting/error state with bounded retry timing. Oversized pages receive guidance to read the needed part on request. Reporting current preparation status is better than hiding failure behind ready. A passive preparation error nevertheless does not establish failure of every manual reading route on that site.
Treat retention bounds as part of the capability
Defaults bound entry count, total bytes, per-entry bytes and age together. Count alone can retain a few huge pages, while age alone can admit too many tabs in a short interval. Least-recently-used pruning combines these concerns.
Tests use small synthetic bounds to check eviction by count, bytes and age and confirm that dormant pages are not observed. I read the implementation and those tests for this article. I did not open many operational pages for a fresh memory benchmark or establish that the defaults are optimal for every PC.
Prepared reading still needs fresh checks before action
Prepared material accelerates page description; it is not a store of indefinitely usable action references. Acting still requires current observation. Ready is neither permission to input nor proof that the desired result is correct.
Other work programs can separate preparation from execution too. Frequently viewed data can use bounded caches while saving or changing state requires a live check. I wanted responsive reading together with a rule against acting on old state. Those distinct responsibilities define the preparation layer.