Audit Food Delivery Orders

Audit Food Delivery Orders

Follow voice and identity, the MCP contract, semantic rules, privacy rules, and food-delivery safety.

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.