basket

Basket — grocery price comparison

Compares a whole basket, not individual items. Cheapest-per-item is a lookup; cheapest-basket is arithmetic nobody does by hand, and it frequently flips the answer — a platform wins on two items and loses on the other ten.

Every price is fetched live from the platform at run time. Nothing is hardcoded — no price list, no pack table, no fee table. When the tool doesn't know a number it says so instead of supplying a plausible one. Preserve that when you relay results: don't fill gaps with your own estimates.

Before anything else: check the environment

Every search runs as a real webcmd command against a browser webcmd owns.

basket doctor

That checks Node, webcmd, the browser bridge, the four adapters, and the data directory — and prints a fix under anything that fails. Run it first whenever something looks wrong; it is faster than reading errors from a failed run.

If it reports problems, basket setup fixes most of them non-interactively (clears the stale cloak lock, regenerates adapters) and then walks the user through setting delivery locations.

Two failure modes worth recognising by name, because webcmd's own messages don't spell them out:

• "profile is already in use by another instance of Chromium" — an orphaned cloak browser holds a lock on ~/.webcmd/cloak/profiles/default. basket setup clears it, or kill *cloakbrowser* processes and remove Singleton{Lock,Cookie,Socket} from that directory.
• fetch failed on first run — cloak is downloading ~150 MB of Chromium into ~/.cloakbrowser/. Needs network and patience, not debugging.

Delivery location lives in the webcmd browser profile. Set it once per platform by hand and it persists (siteSession: 'persistent' keeps it alive across commands). If a platform returns "results never rendered", the location is missing — fix it in the browser, don't debug the adapter:

WEBCMD_WINDOW=foreground \
  printf 'await page.goto("https://www.bigbasket.com/");' \
  | webcmd browser setloc run --stdin