Three extension budgets: data, rendering and cart changes

ShopTools AI finds offers, and its extension can test available codes in supported carts. Downloading a record, rendering a card and attempting a coupon have different costs. One shared limit does not describe all three jobs well.

The data budget

When designing a loader, bound response size, parsing cost and memory use as well as record count. A short list can still be expensive if descriptions and nested fields have no limits.

Pagination and caching need to preserve the meaning of search results. If a client has loaded only part of a dataset, it cannot present that partial count as the total number of matches.

Measure a cold load separately from a cache read. A fast repeat response says little about the resources a new user needs. Changing the download budget should not automatically change the number of cart operations allowed.

The rendering budget

Each visible card adds markup, layout work and interaction handling. Choose a separate limit for simultaneously displayed items and decide how people will reach the remaining results.

Distinguish matching records from displayed cards. Otherwise an interface limit can look like lost offers, and a larger catalog can be mistaken for a requirement to render everything at once.

• Compare initial rendering, scrolling and refiltering with the same dataset.
• Test long names, another language and a narrow popup.
• Check that refreshing the list does not accumulate event handlers.
• Exclude deals without codes from the count of coupons eligible for testing.

The checkout-operation budget

Submitting a coupon changes another application's state. The tool must wait for the merchant, read a comparable total and prepare for the next candidate. That is not equivalent to displaying one more card.

A reference design would use a separate bounded queue, captured when testing starts. Reordering catalog results would not change a scan already underway. An early-stop reason would be stored independently of the original queue length.

1. Before starting, check that an allowed action and a readable baseline are available.
2. After an attempt, observe the result for stability within a bounded observation window.
3. Stop when the state cannot be reliably restored or compared.
4. Report the candidates available, the number attempted and why testing ended.

Adjust limits using measurements

This model does not state current ShopTools quotas. Numbers from older technical write-ups are not universal settings for an API, an interface or a merchant's checkout.

Change one budget at a time and measure its resource on a reproducible test setup. Local measurements do not establish that every merchant can tolerate the same action sequence or will produce the same outcome.