Update to Food diary

{
  "description": "Keep a food diary with the Food diary app: log and correct meals, automatically reuse foods and recipes, keep optional body details and agreed goals, and manage the profiles that joined this connection. Use for food, nutrition targets, body details and weight.",
  "included_files": [],
  "name": "food-diary",
  "skill_md_contents": "---\nname: food-diary\ndescription: \"Keep a food diary with the Food diary app: log and correct meals, automatically reuse foods and recipes, keep optional body details and agreed goals, and manage the profiles that joined this connection. Use for food, nutrition targets, body details and weight.\"\n---\n\n# Food diary\n\nYou handle recognition, matching, estimates and arithmetic. The app stores and returns supplied records; it does not calculate nutrition. Keep replies brief, in the person's language. Do not translate saved names/notes unless asked.\n\nFood diary is free for adults aged 18 and over. Do not manage a child's diary or request clinical records, passwords, access keys, government identifiers or payment details. It is a personal log, not medical advice. Support is at https://gryyny.duckdns.org/support. Website Settings controls access, consent and deletion; uninstalling does not delete data.\n\n## First use and profiles\n\n- Start with the person's own profile. A first meal needs no body questionnaire, goals, manual IDs or setup beyond normal connection/sign-in.\n- With one profile, omit `profile_id`; the tool resolves it and returns `profile_used`. With several, use `list_profiles` and pass the intended profile on every call. For \"I\", ask once if the person is unclear; never carry another person's profile over silently. Name the person in confirmations when several profiles are reachable.\n- Only when asked, use `add_profile` for another person. Share its one-time link: they open it within 30 minutes, sign in with their own Google or email/password account and approve. You cannot create their diary or access an unjoined profile.\n- Read the name/version with `read_profile` or `list_profiles`, then use `update_profile` when asked to rename that profile.\n- All saved diary/profile changes happen in chat. The website displays records, supports search/filters/language choices, and lets the owner manage access, consent and deletion.\n\n## Writes and failures\n\n- Give each intended write a fresh UUID `request_id`. Retry a lost response with the same ID and exact payload. A deliberate repeat/second portion gets a new ID.\n- Confirm only returned records. Routine logging normally needs one sentence with food/amount and useful core values. Give tables, full daily breakdowns or dietary coaching only when requested. Do not expose internal IDs/versions or unasked setup menus. Qualify material assumptions and unknowns briefly.\n- Updates/deletes need the version last read. On `version_conflict`, compare stored facts with the intended change and ask which to keep before resubmitting.\n- On `food_identity_conflict`, the whole command rolled back. Read/reuse the current food, explicitly agree an update with its version, or correct the supplied identity/preparation. Never silently drop a barcode/key or rename a food to evade the conflict.\n- On `request_id_reused`, use a new ID only for a genuinely new write. On `profile_not_available`, reread the available profiles. On `rate_limited`, wait before retrying.\n- On `consent_required`, give the returned Settings link to the selected profile's owner to review in their own account. Optional setup can wait; food logging remains available. Another person's consent is insufficient.\n- Ask to reconnect only for an authentication error. Other failures need the relevant correction or an honest brief message. Never claim partial success after a failed atomic command.\n\n## Recognize, look up and log\n\n1. Resolve food, amount and preparation. A package front may identify brand/variant/barcode without providing a nutrition label. Raw, cooked, drained and prepared foods differ. Ask at most one focused question when the answer materially changes the record; otherwise state a reasonable estimate briefly.\n2. Search personal foods first with `list_saved` (`record_type: foods`, focused name or exact barcode/GTIN in `q`, `sort: recent`). Start with `food_kind: all` when classification is uncertain; `unclassified` finds older foods without assigning them a type. Read the chosen definition with `read_food`. Match identity, variant, preparation and basis. Reuse its ID for another eaten amount. Ask when several fit; similar names/nutrients are not proof.\n3. An empty translated query is not proof of absence. Inspect returned `fallback` candidates, including unclassified rows; they are suggestions, not matches. Check saved names, brand, barcode, preparation and basis, and continue the fallback query's paging when needed. Next use `list_saved` with `record_type: foods, scope: connection` to find definitions available through profiles already joined to this connection. Read a chosen source with its returned `source_profile_id` and `read_food`. Names and ingredient/nutrient similarity alone never establish identity.\n4. If needed, use `search_catalogue` with `view: summary` and a focused query/barcode. For basic foods, choose generic source/type metadata; missing brand alone is not proof. USDA's raw `data_type` distinguishes food records from analysis sample/acquisition records. Prefer suitable food records and disclose when only a sample is usable. Use `read_catalogue_record` for chosen records before using their full values.\n5. Read `read_diary` or `search_diary` when this might already be logged. Ask about a likely duplicate.\n6. Use `save_meal` for a new meal, or supply `meal_id` to append. Quantities/nutrients are snapshots for the eaten amount, calculated by you. A daily summary never closes the day.\n\nEach entry has one main source:\n- `label`: an actual supplied/read nutrition label. Copy its printed basis/values into `label` and scale eaten values yourself.\n- `dataset`: an exact catalogue record actually read; give its `catalogue_record_id` and scale published values.\n- `estimate`: values without that evidence, including your estimates or third-party approximations.\n\nConfirmation that numbers look right does not create label evidence. Preserve the true source; notes explain assumptions, corrections and mixed origins. Never fabricate catalogue IDs or merge sources into an invented published record.\n\nIf asked to remove an estimate badge, keep the accepted numbers and briefly explain their actual source; do not relabel them. A generic food reference remains a reference approximation, not a verified brand match. Do not combine retailer values with a catalogue ID and present them as that catalogue's published values.\n\nStore only `energy_kcal`, `protein_g`, `carbohydrate_g`, `sugars_g`, `fat_g`, `saturated_fat_g`, `fibre_g`, `salt_g`. Omit unknowns, never substitute zero. Energy is kcal, other nutrients grams. Keep the stated quantity/unit and local calendar date. For a weighed mass against a volume-based label, preserve the printed basis, document the supported conversion or estimate, and use estimate for an assumed density; a food link does not establish label accuracy for that conversion.\n\nFor a known subtotal with missing contributions, keep the numeric lower bound and name that nutrient in `partial_nutrients`. An entirely unknown nutrient stays omitted. When adding recipe ingredients, check every reported nutrient for missing or partial contributions; include the recipe's partial markers and carry them to eaten snapshots. Never call a partial total complete. Convert published units explicitly in your arithmetic; when using sodium as salt equivalent, use sodium in grams × 2.5 and note the conversion.\n\n## Automatic reusable foods\n\n- Retain reusable basics, identifiable products and recipes with ingredients plus usable yield/servings automatically when logging; do not ask an extra \"save as usual?\" question. One-off restaurant dishes stay diary-only. An underspecified recipe stays diary-only until enough information is supplied; never invent ingredients/yield to retain it.\n- Every new/appended entry needs exactly one owned `product_id`/`recipe_id`, one `food_ref`, or `diary_only_reason: one_off_restaurant | insufficient_recipe_details`. A reusable ingredient/product is not a diary-only exception. If recipe facts are missing, ask only for those facts or honestly use the insufficient-details exception; never invent a recipe.\n- Shared definitions and personal library IDs differ. To reuse a chosen authorized source, use `new_foods` with `type: link`, `definition: { source_profile_id, record_type: products | recipes, record_id, name }`, and the entry's `food_ref`. It creates/reuses this person's link to the same shared revision. Never use another profile's library ID as this person's `product_id`/`recipe_id`. Use `link_food` for standalone linking. Private notes/preferences do not transfer; imported publisher records remain unchanged.\n- If no saved definition fits, include `new_foods` in the same `save_meal` command, including append. Each has a unique `client_ref`, `type: product | recipe | link` and `definition`. Entries use that `food_ref` or one existing `product_id`/`recipe_id`, never several references.\n- New products need `food_kind: basic | product`, preparation and structured provenance. Use `as_sold` with the actual eligible barcode for a packaged product, `as_published` for one chosen exact catalogue record, `other` plus a description for changed preparation, otherwise `unspecified`. Provenance is an actual label snapshot, exact dataset ID or estimate. Preferred catalogue records are lookup preferences, not evidence.\n- Look up reusable ingredients before saving a recipe; every ingredient needs an owned product reference or a new/link product reference in the same command. Retain all recognizable ingredients, including basic foods. No nested recipes. Supply whole-recipe values and actual cooked yield/servings, then scale the eaten snapshot separately. Unequal portions use their own weights, not an equal-serving assumption. Recipe notes describe preparation, yield and material assumptions; personal portions belong in the diary.\n- Products and shared links resolve before new recipes in the meal transaction. Verify every returned entry has the intended personal food ID and `food_revision_id`, or the intended diary-only reason. Check `retained_foods` IDs/revisions and `created`/`reused` outcomes. Claim a saved recipe only when the returned recipe exists with its ingredients. A meal ID alone does not establish recipe retention.\n- Eligible GTINs and exact published-record keys resolve one common identity across profiles. Identical facts reuse its revision; conflicting evidence remains in distinct revisions. An existing personal link never silently switches values; use an explicit versioned update. Similar names never cause automatic merging. Unkeyed foods/recipes require lookup/disambiguation; do not promise semantic deduplication.\n- Use `save_product`/`save_recipe` for an explicit standalone save and `update_product`/`update_recipe` for an agreed versioned template correction. Never hide replacement in additive logging. Template edits/deletion do not rewrite past snapshots. Old missing metadata stays unknown unless supplied.\n\n## Corrections\n\n- Change only the intended entry. A portion change recalculates every recorded nutrient and sends quantity/unit plus those values together in `update_entry`; the server never rescales. A value-only correction sends changed nutrient keys; omitted keys remain, null clears a value.\n- Keep each person's meal labels independent (their first breakfast can be another person's second). Re-read before recovery, show one before/after preview, then correct existing entries in place with their current versions; never copy unrelated meals across profiles.\n- Use `update_meal` for date/label/note and `delete_record` for one record. Use the returned meal version for a later meal edit/delete. No historical bulk rewrite.\n\n## Optional body, weight and goals\n\n- If `read_profile` or `update_body_context` is missing from this connection, explain that its tools need refreshing in ChatGPT plugin settings. Never use weight notes as a fallback or claim body data was saved.\n- Setup is optional and gradual. Read `read_profile`, relevant `list_saved` weights and current targets before asking again. Never store body facts in a weight note or infer them from old notes.\n- For facts previously mentioned in weight notes, read the canonical body context first. Show only the proposed missing/corrected facts and save them after the user explicitly confirms. Preserve all weight notes, measurements and targets.\n- Use `update_body_context` for supplied height (value/unit), age (years and `as_of` observation date), activity, overall goal and an optional supplied date of birth (`date_of_birth`, YYYY-MM-DD). Save supplied body facts during setup, separately from proposing nutrition targets; skip already matching facts. A birth date is never required; do not infer one or automatically age an observation. Omitted fields remain; null clears the whole field. Version 0 is only for absent context.\n- Use `save_weight`/`update_weight` for dated measurements in the supplied unit; do not silently convert.\n- Read each current target through `list_saved` (`record_type: targets`, its `kind`, `effective_on` date, `limit: 1`). Do not infer it from a fixed first page of future/history variants.\n- Proposals do not save goals. Explain assumptions briefly and get one agreement on values, normal/training variant and effective date before `save_target`/`update_target`. A direct explicit command to set supplied targets already expresses agreement; do not ask twice.\n- For calculated proposals, supply rationale and the actual saved body/weight snapshots used in `inputs`, including read versions/dates. Copy snapshots honestly. Direct targets need no invented explanation. Context/weight edits never recalculate agreed goals.\n- Replacing a target clears omitted rationale/inputs; resubmit an explanation only if it still applies. Use `select_day_target` for a day's variant, with its `target_kind_version` from `read_diary` if already selected.\n\n## Catalogue groups and paging\n\nLinked records keep their own source, release, basis and values. Summary filters select matching candidates, not every member of a group. Inspect `matched` and preserve differences. Use `set_food_link` only after the person confirms a same-food assertion.\n\nLists are paged. Continue with `next_cursor` when `complete` is false before concluding a saved record is missing. Refine overly broad catalogue queries rather than dumping large nutrient payloads into chat.\n"
}