# Audit Food Delivery Orders

> Audit, learn, index, refresh, search, or compare a user's signed-in food-delivery order history in Fullwell, including provider selection, complete order and modifier evidence, exact restaurant locations, local saving, and optional provider-by-provider household contribution.

- Skill: `moorage/audit-food-delivery-orders` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add moorage/audit-food-delivery-orders`
- Raw SKILL.md: https://api.skillmd.com/api/skills/moorage/audit-food-delivery-orders/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: moorage (https://skillmd.com/u/moorage)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/moorage/audit-food-delivery-orders

---


# Audit Food Delivery Orders

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

1. Load `fullwell_local_household_load` before choosing local or cloud authority. If and only if it returns `LOCAL_HOUSEHOLD_COMPATIBILITY_REQUIRED`, immediately call `fullwell_local_household_update` with `repair_compatibility`, reload, and resume the interrupted request without asking the user to diagnose or approve this local format-only repair. Call repair once per failure. After success, say naturally that you updated the saved delivery history and are continuing; do not expose connector, validation, schema, malformed-ID, migration-operation, or compatibility-repair terminology. The repair itself makes no cloud call and does not replace provider visibility consent. Ask which delivery sites the user uses and which installed browser with an existing signed-in session may be controlled. Offer DoorDash, Uber Eats, Grubhub, and a user-named browser-accessible provider only as examples; accept any exact supported HTTPS provider origin.
2. Preflight every selected site before collecting any history. A sign-in, MFA, CAPTCHA, browser-permission, or unsupported-origin block requires one user action and stores no partial page or order. Never request credentials or codes, bypass a challenge, crawl a provider, or run broad extraction. Use ordinary user-directed signed-in navigation.
3. Default to the trailing 12 months unless the user chooses another bounded window. Treat order-list cards as discovery only. Open every qualifying completed order, expand every item and modifier control, distinguish `delivery` from `pickup`, and verify the declared line count before saving the group. For each exact dish row or its visible exact menu/item link, inspect the visibly associated dish image and record its credential-free HTTPS URL plus that exact page URL in the history-backed delivery dish'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 dish has no image: refresh the Safari state and screenshot, target the exact visible dish 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 dish row or menu/item 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 unrelated image search, click an add/remove-image control, or use an order-list thumbnail as provenance. After each complete order, call `fullwell_local_household_update` with `save`, the exact revision, and the entire canonical local journal containing delivery evidence, dishes, profile, and report. On conflict, reload and reconcile; never overwrite.
4. Exclude canceled and failed orders. Preserve refunded, hidden, or otherwise incomplete lines only as bounded limitations; a refunded-only or partial group is not a complete reorder candidate. Include alcohol as an agent-authored `alcohol` delivery dish under the same evidence rules as food. Do not create dishes for tobacco, cannabis, prescriptions, gift cards, or other regulated/non-food lines; record only that the complete order contained excluded lines.
5. Decide dish and restaurant-location identity semantically. Keep distinct provider merchant locators or exact public merchant addresses separate until evidence justifies a merge. Preserve user-confirmed aliases with provenance. Keep same-name locations, renamed merchants, modifier variants, duplicate lines, and one-off dishes evidence-backed rather than silently merging or dropping them. Preserve an existing valid image/page pair when refresh exposes no newly proven image; replace it only from the newly inspected exact dish/menu page. HTTP, data/blob, credential-bearing, decorative, tracking-only, and unprovable images remain `null` and never block otherwise complete order evidence.
6. Group the canonical delivery index by provider and distinct restaurant location. Cite every row with the exact delivery dish and complete order-line evidence. Preserve private order date/grouping, fulfillment mode, locators, and modifier occurrences only in the private journal. Pickup establishes familiarity but is non-actionable for delivery.
7. For a cloud household audit, explain the provider-specific visibility and retention notice before the first write, then interpret the user's response naturally in the current conversation. A clear contextual affirmative such as `yes`, `sync it`, or `go ahead` confirms that provider; never require the user to repeat scripted text. If intent is unclear, ask one conversational clarification. Silence, an unrelated answer, or uncertainty is not confirmation. Only after clear intent, send `household_visibility_confirmed: true` and checkpoint each complete order and final index with `hfj_commit_delivery_index` in `connected_audit_checkpoint` mode at the current HEAD. Generic evidence, change-set, onboarding, and profile tools never write private connected delivery history.
8. For local-to-cloud collaboration, read bounded cloud candidates with `hfj_search_delivery_history`, exact groups only when needed with `hfj_get_delivery_order`, and the canonical report with `hfj_get_delivery_index`, plus current item/profile state. Reconcile and preview exactly one provider at a time. Call `fullwell_local_household_update` with `stage_delivery_promotion` before the hosted write; it uses the selected cloud IDs transiently but persists only a one-way target-binding digest and stable key. Use that key in `hfj_commit_delivery_index` with `local_promotion`, then call `record_delivery_promotion` only after a confirmed successful response so the returned linkage IDs are first persisted with the committed receipt. After a compatibility repair, rebuild the exact provider payload and fingerprint from the returned repaired revision before staging or retrying; never reuse a stale pre-repair payload merely because the user's visibility decision remains clear. Uncertain or rejected writes retain the pending key, digest, and local authority; exact retry reuses them only while the payload is unchanged. Conflict rereads and reconfirms only that provider. A committed provider never blocks another.
9. If the user declines household visibility or retention for one provider, keep that provider local or skip it and make no hosted write. Revoking browser access or leaving a household blocks later access but does not selectively erase contributed Git history.
10. Finish with complete order/dish/evidence counts and aggregate image counts as `captured`, `preserved`, and `skipped`, without printing private dish names or image/page URLs. State exact limitations or one blocking action. After success, offer one try prompt based on actual private history, such as `Reorder my most recent Wanpo delivery`, without revealing it in a public surface.
11. After every successful audit that saved new or refreshed delivery history locally but made no hosted delivery write, append an explicit cloud-sync offer. Briefly explain that a cloud household lets household members collaborate, include delivery dishes in shared collections, and use them in shared meal plans. If the loaded local household has `cloud_backup: null`, ask `Would you like to connect Fullwell cloud and sync this delivery history now?` If it has a non-null link, ask `Would you like to sync this delivery history to your linked Fullwell household now?` Interpret a clear contextual `yes`, `sync it`, or equivalent as acceptance without demanding exact wording. If intent is unclear, clarify naturally. A decline or silence leaves the index local. Acceptance starts connection or household resolution but is not yet provider visibility consent: follow steps 7 and 8, show each provider's visibility and retention preview, and accept another clear contextual affirmative before its hosted write. Omit this offer after a connected audit or successful promotion already wrote the history, and after failed, cancelled, unfinished, or no-new-evidence runs.

This skill audits history only. It does not prepare a cart, add menu items, check out, pay, tip, schedule, choose an address, or change subscriptions.