Audit Grocery Purchases

Audit Grocery Purchases

Follow voice and identity, the MCP contract, semantic rules, and privacy rules.

1. Use the authority selected by the managing skill. In local guided mode, reuse the loaded local guest journal and make no Fullwell MCP call. In cloud guided mode, reuse the managing skill's authenticated context snapshot and make no intermediate Fullwell call. For a standalone audit, call fullwell_local_household_load first; use it when present, otherwise route through the managing skill's account choice before calling any hosted tool.
2. Read the compatibility snacks profile from the local journal or cloud snapshot. Treat snacks as the compatibility name for the whole grocery-history section. When opening or resuming it, explain once in first person that you can learn snacks, ingredients, condiments, and other groceries from the same past-order pass, so requests such as "Restock cashews," "Buy a head of parsley," or "I need more mayo - not the Japanese one" can use the familiar product and usual store instead of guessing. Explain that the default automatic cart-add maximum is $50: complete requests below it can be added without another confirmation, while requests at or above it require confirmation. Do not call it "snack setup" without that context. Reuse confirmed store scope and household preferences. Ask only for missing or changed stores, grocery preferences or exclusions that affect interpretation, and which installed browser the user authorizes for background access.
3. Before collecting any store, verify the user is already signed in to every authorized store. Never request credentials or one-time codes.
4. Use a trailing 12-month window and recurrence threshold of two distinct orders unless the user requests different values. Collect all in-scope grocery line items during this one traversal; never revisit the orders in a second pass for ingredients, condiments, or other groceries. While operating the authorized browser, treat order-history listing pages as discovery only: thumbnails, abbreviated cards, and visible summary items are never complete purchase evidence.
   • Traverse every result page and required date or year filter for the window. Open the detail page for every qualifying delivered or completed order, even when its listing card appears to show items.
   • Expand every View all items, Show more, item-count link, or equivalent control. Verify exact line-item names are visible through the subtotal or order-total boundary before treating that order as collected.
   • For Amazon, Fresh, or Whole Foods, expand Items in your order (N) and capture every row. For Weee, capture every product under Item Info through the subtotal. For Good Eggs, capture every product between Items and Subtotal.
   • For each exact product row or its visible exact product/detail link, inspect the visibly associated product image. When present, record its credential-free HTTPS image URL together with that exact page URL in the grocery item's image_url and image_page_url. Prefer supported visible-page DOM access when it exposes the displayed image URL. When Safari Computer Use has no DOM access, never treat an omitted accessibility-tree image as proof that the product has no image: refresh the Safari state and screenshot, target the exact visible product image, open its context menu, select only a currently visible action whose meaning is Open Image in New Tab, read and validate the credential-free HTTPS address in that temporary tab, retain the original exact product row or detail page as image_page_url, return to it, and close the temporary tab. If the image or action is unavailable or ambiguous, the address is unsafe, or association cannot be proven, preserve a prior valid pair or report the image skipped. Do not inspect hidden network traffic or raw HTML, retain the screenshot, read clipboard contents, guess an action or URL, broaden into an unrelated image search, click an add/remove-image control, or use a listing-card thumbnail as provenance.
   • If a detail page or expansion control cannot expose all items, mark that order incomplete, state the limitation, and do not claim the audit or any affected recurrence result is complete. Never infer hidden items from listing-page thumbnails or summaries.

Codex long-audit lifecycle

Use this only for an actual grocery order-detail traversal in Codex when fullwell_local_codex_grocery_audit_lifecycle is available. Do not use it for a report generated from existing evidence, pantry comparison, restock, delivery reorder, meal planning, recipe work, another Fullwell operation, or unrelated conversation. Claude and a Codex installation without this tool keep the existing durable-checkpoint behavior; never substitute a shell command.

1. After loading the exact durable local journal or authenticated onboarding checkpoint, but before opening the first order, call begin with a fresh opaque random UUID as run_id, the already checkpointed aggregate completed_order_count, and the known remaining_order_count or null. The run ID must contain no user, household, store, order, or other meaningful identifier.

2. When compact context supplies an active run and revision, continue it. On a later user turn that explicitly resumes the audit, call resume with that exact run and revision when available; otherwise load the durable checkpoint and call begin with a fresh opaque run ID. The lifecycle marker is coordination only and never replaces the journal or onboarding checkpoint.

3. Immediately after each completed order is durably saved through the applicable local or cloud checkpoint, call checkpoint with the exact lifecycle revision, the nondecreasing completed-order count, and the current remaining count or null. Never advance lifecycle progress before the real checkpoint succeeds.

4. Before any user-visible final response, call finish at the exact lifecycle revision with one truthful outcome: completed, partially_completed, blocked, or cancelled. Use completed only after every qualifying order and final journal write is proven. Use partially_completed for a user-directed pause or scope switch, blocked when one user action or external condition prevents progress, and cancelled only when the applicable cancellation contract is satisfied.

5. While lifecycle state remains collecting, do not emit a final correction, progress summary, or completion claim. Keep working from the checkpoint. Codex may continue the turn automatically after compaction or a premature stop. A normal new user prompt disarms the old turn, so handle the new request normally unless the user explicitly resumes the audit.

6. In local mode, return each completed order cursor and its typed evidence to the managing skill for immediate revision-checked local saving; never retain the only copy in conversation state until the entire site is finished. In cloud guided mode, return the same data to the authenticated checkpoint. Only a standalone cloud audit may call hfj_append_evidence in batches of at most 100 with the current HEAD and a stable idempotency key.

7. For every collected grocery line, use the semantic reference to assign exactly one item kind: snack, ingredient, condiment, or other_grocery. These are agent-authored semantic decisions, never keyword classifications in code. Keep materially different brands, product lines, flavors, formulations, formats, and produce varieties separate; standard and Japanese-style mayonnaise are distinct formulations. In local mode use current local items; in cloud guided mode use the snapshot item index; a standalone cloud audit may search and read candidates. If a hosted index is truncated or lacks enough detail for a safe update, return the exact missing reads to the managing skill. Do not let exact-search code make a semantic merge.

8. Author or update an evidence-backed item for every in-scope grocery identity, even when it appears in only one order or falls below the recurrence threshold. Include its observed stores and exact product provenance in the item Markdown so later source selection is explainable. Preserve an existing valid image/page pair when a refresh exposes no newly proven image; replace it only from the newly inspected exact product page. HTTP, data/blob, credential-bearing, unrelated decorative, tracking-only, and unprovable images remain null and never block otherwise complete text evidence. The threshold controls which identities receive recurring report assertions, not which identities Fullwell learns. Count distinct store/order pairs rather than quantities and cite exact item and evidence IDs in every assertion.

9. In local mode, return every grocery item, the compatibility recurring_snacks report with clearly labeled grocery-area sections, and the complete outcome for revision-checked local saving. In cloud guided mode, return those plus expected item revisions to the managing skill without writing them. Only a standalone cloud audit calls hfj_commit_change_set with current HEAD, blob revisions, evidence, assertions, and a stable idempotency key.

10. Ask whether the user's shops have changed. Return confirmed grocery-history profile changes under the compatibility snacks profile for local or guided cloud saving; only a standalone cloud audit calls hfj_update_profile.

If the user naturally declines or has no grocery sources, do not infer intent with keyword matching. In local guided mode, return the bounded skip reason for local saving. In cloud guided mode, return the reason and snapshot revision without a Fullwell tool call so the managing skill can advance to recipes. For a standalone cloud onboarding transition, hfj_update_onboarding remains available.

Report completed item/evidence counts plus aggregate image counts as captured, preserved, and skipped; do not print private item names or image/page URLs in that summary. Report exact unresolved items or the one action blocking progress. Do not log or publicly share purchase details.