---
name: audit-grocery-purchases
description: Start or continue Fullwell grocery-history onboarding and audit purchases for snacks, ingredients, condiments, and other groceries in one pass, including store scope, browser authorization, household preferences, product identities, and evidence-backed recurrence reports.
---

# Audit Grocery Purchases

Follow [voice and identity](../../references/voice-and-identity.md), [the MCP contract](../../references/mcp-tool-contract.md), [semantic rules](../../references/semantic-food-rules.md), and [privacy rules](../../references/privacy-and-sharing.md).

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`. Do not inspect hidden network traffic or raw HTML, broaden into an unrelated image search, 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.