Update to Dayze

{
  "description": "Read the signed-in Dayze user's private life context (calendar, people, money, travel, memories, inventory, contacts' birthdays) and add to it (meals, expenses, money in or out, goals, sleep, events, place visits, favorite songs, contact touchpoints). Use when the user asks about their week, calendar, who matters, past expenses, upcoming trips, or something they saved in Dayze, or tells you something to log — not for public celebrity biographies.",
  "included_files": [
    {
      "relative_path": "references/tools.md",
      "size_in_bytes": 17473
    }
  ],
  "name": "dayze-life-context",
  "skill_md_contents": "---\nname: dayze-life-context\ndescription: >-\n  Read the signed-in Dayze user's private life context (calendar, people,\n  money, travel, memories, inventory, contacts' birthdays) and add to it (meals, expenses, money\n  in or out, goals, sleep, events, place visits, favorite songs, contact touchpoints).\n  Use when the user asks about their week, calendar, who matters, past\n  expenses, upcoming trips, or something they saved in Dayze, or tells you\n  something to log — not for public celebrity biographies.\n---\n\n# Dayze life context\n\nDayze is the user's life-in-days graph. This app reads over OAuth and, when the user allowed \"Add records\" (`context.write`), adds records. With Edit records (`context.edit`), it can correct the listed private records. It cannot delete records. Calendar and watch records added here are always private; sharing happens in Dayze. Never invent calendar events, people, or memories.\n\n## Getting started\n\nOn “I just connected”, hello, or a getting-started request, call get_context_pack once. Read sections.onboarding: first_save_complete means skip the first-use flow; first_save_needed permits one short welcome and one question about something they did or ate today. Unknown or unavailable status is not a new user. Never infer an empty account from an empty week. Never interrupt a specific task, repeat a declined offer in the conversation, demand a birthday, or save anything merely because the user connected. With permission, save their first entry using the granted tool, verify its receipt and give the Dayze link. Read-only users get the app link. A successful connected-app create supplies durable completion evidence; never mark completion from OAuth or an attempted/failed call.\n\n## Images: find, classify, attach, verify\n\n1. Use find_image_target with entity_type food, event, inventory or person and a literal name to find the existing record. Its entity_id is the attachment ID (food_id for food tools). Use a create receipt directly for a newly logged entry. Compact hashed references are not write IDs. Ask which record if ambiguous; never create a duplicate to attach an image.\n2. Ask whether it is an actual photo or an illustration if unclear. Actual photos use `upload_asset` with entity_type inventory/event/person, entity_id and role photo. Contacts keep their avatar. Food's existing actual-photo slot is managed in Dayze; do not substitute an illustration.\n3. Generated or illustrative images use `attach_food_visual_reference` for food, or `attach_visual_reference` for event/inventory/person. Set confirmed=true only after the user asks to save that image there. Use the exact label Visual reference, with source chatgpt_generated or illustration (stored as external_illustration) and generator/generated_at only when known. These are illustrations, never photographs or evidence. Never replace photos, avatars or covers.\n4. Supply the actual image via image (ChatGPT file bridge) or image_base64. A displayed image, sandbox path or file ID alone cannot be transferred. No external URL on this public connection. Retry once with the actual attached file; if bytes are still unavailable explain that nothing is confirmed saved and link the exact record when returned, otherwise its Dayze section. Never pretend the display itself proves attachment.\n5. Only attached=true plus successful byte/readback verification establishes a saved reference. A partial gallery sync is still incomplete in the app: report it and follow recovery. For uncertain reference persistence, retry the SAME request_id. Do not generate a new meal or record. Read back with get_food_visual_references or get_visual_references and give the returned inspect_url.\n\n## First call\n\n1. For a week question or a broad overview of recorded Dayze context, call `get_context_pack` once (prefer over chaining separate reads).\n2. Omit `purpose` (or use `this_week`) for the week bootstrap: `sections.events`, `sections.people`, `sections.finance`, `sections.travel`. Use `purpose` `memories` or `inventory` for those single sections.\n3. Ground the reply in the returned `sections` (each has `status`, `items`, `has_more`, `inspect_url`) and in `account_timezone`. The first `limitations` entry names the Dayze account. A record-specific source URL may appear in the item's `why_included`; items do not have an `inspect_url` field.\n\n## Follow-ups (reads)\n\n| User intent | Tool |\n| --- | --- |\n| Find a saved contact, event, merchant, item or memory by keyword | `search_dayze` (`search` = literal keyword, not the whole question) |\n| Recorded calendar in an explicit date window | `get_events` |\n| A person or saved relationship facts in Dayze Contacts | `get_people_context` |\n| Whose birthday is coming up, or whose they missed | `get_birthdays` (`days_ahead` / `days_back`, 30 each, or `from` / `to`). `age_turning` is null when the year is unknown: never guess an age. You may draft a short personal message for each; Dayze sends nothing |\n| A contact's photos as inline images | `get_person_photos` |\n| Recorded spending or merchant in an explicit date window | `get_finance_context` |\n| Recorded upcoming trips in an explicit date window | `get_travel_context` |\n| Cite a Dayze event, contact, or finance record in Sources | `search` then `fetch` |\n| Something they own: its price, value or condition | `search_inventory` (`query` = name, brand or model), then `get_inventory_item` (`inventory_id`) |\n| Where something they own is (“where is my X”) | `search_inventory`: answer from `location`, `storage_place`, `storage_building`, `storage_room` and `storage_container`. If all are empty, say Dayze doesn't know where it is. `acquired_from` is where it was bought, not where it is now; never answer from it or guess |\n| Something they sold, gave away or lost | `search_inventory` with `include_archived: true` (past items carry `past`: reason, date, details, price) |\n| How an item's value changed | `get_inventory_valuations` (`inventory_id`) |\n\nEvery read takes `query` (the user's question) except `fetch`, which takes the opaque `id` from `search`, and `get_person_photos`, which takes the exact contact name or `person_id`. Every context tool except `get_context_pack` and the citation tools (`search`, `fetch`) also needs `purpose`. `get_events`, `get_finance_context` and `get_travel_context` need `from` and `to` as `YYYY-MM-DD` civil dates in the account timezone (at most 93 days apart); turn \"this week\" or \"last month\" into explicit dates using `account_timezone` from the pack. If a section is `partial` or `has_more` is true, say the list is incomplete.\n\n## Adding records (writes)\n\n| User says | Tool |\n| --- | --- |\n| A goal they want to track | `create_goal` (life goal; numeric goals need target_value and target_unit) |\n| What they ate or drank | `log_food` (Food Diary; `dish_items` for several dishes, `with` for companions) |\n| A plan, appointment or event | `log_event` (always private; sharing happens in the Dayze app) |\n| Money in or out (a transfer, a bill, money sent or received) | `log_transaction` |\n| Money lent or repaid, or an IOU | Not on this connection: tell the user to record it in the Dayze app |\n| Something they paid for | `log_expense` |\n| How they slept | `log_sleep` (`started_at`/`ended_at` with timezone) |\n| A film they watched | `log_movie_watch` (`title`, release `year`, `watched_at`, optional explicit `rating` 0–10); saves directly to Movies |\n| A TV show or episode they watched | `log_tv_watch` (`title`, `season`, `episode`, `episode_end` for a range, `finished_season`); saves directly to TV |\n| A song they love | `log_favorite_song` |\n| A place they went | `log_place_visit` |\n| They called, messaged or met a contact | `log_interaction` (always private) |\n| A past story or memory | `log_moment` (always private; plans go to `log_event`) |\n| Someone new to remember | `create_person` (an existing match is returned unchanged) |\n| Money they received | `log_income` (plain income; loans and IOUs are recorded in the Dayze app) |\n| Something they own | `add_inventory_item` (price, currency, purchase date, condition and notes; never a serial number). Where it is kept goes in `location` and the storage fields (`storage_place`, `storage_building`, `storage_room`, `storage_container`); `acquired_from` is the shop or person it came from, never where it is kept |\n| What an item is worth now | `add_inventory_valuation` (`inventory_id` from `search_inventory`, `value` in the item's own currency), only when they ask you to save a value or confirm one you showed them; see Rules for `source`, `confidence` and `notes` |\n| A photo of an item, shared in this chat | `upload_asset` (`entity_type` `inventory`, `entity_id` = the item's `inventory_id`, `role` `photo`, the attached file itself as `image`); never a link from the web. If the answer says the photo did not arrive, call again with the attached file; if it fails again, give the user `upload_url` |\n| A photo of an event, shared in this chat | `upload_asset` (`entity_type` `event`, `entity_id` from `find_image_target` or the event's successful create receipt, `role` `photo`, the attached file as `image`). Compact search references are not attachment IDs. Only the user's own private events: a shared (`EVENT_EXPLICITLY_SHARED`), calendar-linked (`EVENT_EXTERNALLY_SYNCED`) or repeating (`EVENT_RECURRING_SERIES`) one is refused and nothing is uploaded; give the `next_step`. The photo-not-arrived recovery is the same as for an item. `gallery_synced: false` means the photo isn't showing yet: say so and follow `warning` |\n| A trip, or a city they lived in | `log_travel` (`city` + `start_date`) |\n\n## Fixing records (edits, only with Edit records)\n\nIf the connection was given Edit records, these change details of a record the user already has. Find the record first (`search_dayze`, `get_events`), say exactly what will change, and change only what the user asked for. Without Edit records, an edit answers with a Reconnect prompt; tell the user they can allow Edit records there.\n\n| User says | Tool |\n| --- | --- |\n| Move, rename or fix an event | `update_event` (private owner-authored events; explicitly shared, truly calendar-linked or recurring ones return a specific code and are changed in the Dayze app) |\n| Fix a transaction's amount, merchant, date or category | `update_expense` (not IOUs, splits or imported payments) |\n| Fix what or when they ate | `update_food` (not its price or who was there) |\n| Fix a contact's name, notes, birthday or how they met | `update_person` (not merges, aliases or accounts) |\n| Fix a movie watch’s rating, date or note | `update_movie_watch` (`watch_id` from the log receipt; `rating: null` clears it) |\n| Fix a TV watch’s rating, date or note | `update_tv_watch` (`watch_id` from the log receipt) |\n| Fix a sleep session | `update_sleep` |\n| Fix a moment's text, date or place | `update_moment` (it stays private) |\n| Fix an item's name, brand, model, condition, price, purchase date or notes | `update_inventory_item` (`inventory_id`; a new value goes to `add_inventory_valuation`) |\n| Where an item is kept changed | `update_inventory_item` with `location` and the storage fields; never `notes` or `acquired_from`. Set only what the user said; leave unknown levels empty |\n| Where an item was bought | `update_inventory_item` with `acquired_from` |\n| They sold, gave away, donated, traded, lost or threw away something, or it was stolen or broke | `update_inventory_item` with `past_reason` (sold, gifted, donated, traded, stolen, lost, broken, disposed, returned), `past_date`, `past_details`, and `sale_price` for sold or traded. It moves to Past items with its history; nothing is deleted |\n| They still have something marked as past | `update_inventory_item` with `status: owned` |\n\nRules for every write:\n\n- Pass a new `request_id` (a UUID) on every write. Reuse the same `request_id` only to retry the same write; never for a second record.\n- One thing is saved once. Confirm what you are about to add when the prompt is ambiguous (which day, which contact, which currency); never guess a date for a task with no deadline, ask.\n- Use the account timezone for dates and times. Keep the currency the user said; never convert.\n- Writes land only on the connected Dayze account. Never pass another user's id or handle; the server refuses it.\n- The result carries `provenance` (source `chatgpt`, the connected `account.handle`) and a Dayze link. Say which account the record was added to and give the link. The record is attributed to ChatGPT in the user's change history.\n- This app can edit only the listed private fields with Edit records; it cannot delete, archive, move money, book, buy, post or send. If asked, say so plainly and point to the Dayze app; do not call a read tool to \"plan\" a change.\n- A write refused with `INSUFFICIENT_SCOPE` means the connection was granted without \"Add records\": say nothing was saved and ask the user to reconnect Dayze in ChatGPT settings allowing it. `request_id_required` means a `request_id` was missing; retry with one.\n\n## Rules\n\n- Do not invent facts missing from tool results; partial or no_data answers are honest answers.\n- Do not use private Dayze tools for public biography, weather, Gmail, live location, booking, buying, messaging or reminders. If “Who is Maya?” does not say whether the user means public knowledge or Dayze Contacts, clarify before reading private data.\n- Use explicit civil dates in the account timezone for event, finance and travel windows. Bounded rows are not complete calendar or ledger totals; preserve native currencies and never sum different currencies.\n- Cite the `Source: https://dayze.com/...` URL in an item's `why_included` when present; otherwise cite the section's `inspect_url`. Never build a URL from an id. Say which Dayze account the data is from.\n- Inventory values: an estimate you worked out is a suggestion until the user asks you to save it or confirms it after seeing it. Show the number and how you got it first; never call `add_inventory_valuation` unprompted on a guess, because it replaces the item's current value (earlier values stay in its history). When saving, always pass `source` (for example \"ChatGPT estimate\", \"listing\", \"sold listing\", \"appraisal\"), `confidence` (0 to 1, lower for a rough estimate) and `notes` with the source links and comparables used, where they exist. Name the source honestly: an asking or listed price is \"listing\", never \"sold listing\"; use \"sold listing\" only for a price an item actually sold for.\n- If auth fails, tell them to reconnect Dayze in ChatGPT settings (OAuth), not to paste API keys in chat.\n- These 45 tools are the v1.7.0 candidate base catalog. A feature-gated read may also be available; use only tools actually exposed by the connection. It has no public celebrity or web lookup. For famous people, answer without Dayze and do not call these tools for them.\n\n## Output\n\nLead with what matters this week (upcoming events, then people). Keep lists short. Give dates in the account timezone. After a write, one line: what was added, to which account, with its link.\n\nFor “I watched…” use the dedicated movie or TV tool, never a calendar event or memory as a substitute. Use the account timezone: “last night” is yesterday’s civil date, not an invented precise time. Only give a rating the user supplied. A duplicate returns the stored entry unchanged; do not claim a new rating was saved. Use its watch_id for a later edit. If a title needs confirmation, ask the user and claim nothing was saved. A future watch plan belongs in the calendar, not watched history.\n\n## Food Visual reference\n\nWhen the user asks to save an illustration of food, use `find_image_target` with entity_type food to find the existing food_id; compact `search_dayze` cannot supply Food Diary attachment IDs. Call `attach_food_visual_reference` with confirmed=true, a fresh request_id and actual transferable image bytes (ChatGPT image file bridge or image_base64). Never create a duplicate meal. For a new meal, log_food first and attach to its returned food_id. Food logging never depends on imagery. Do not generate or save imagery automatically.\n\nThese images are illustrations, not photographs or evidence of the actual meal. The exact label is Visual reference. Actual photos remain unchanged. A rendered image, local file ID or sandbox URL alone is not transferable: explain the limitation and ask to re-share the file; never claim it was saved. Only attached=true with verification=stored_bytes_and_food_readback confirms attachment. Retry the same request_id after uncertainty. Use `get_food_visual_references` for owner-private signed views and provenance on that food_id.\n\nFor a daily briefing, call `get_context_pack` with `query: \"What matters today?\"`. Cite the returned source links. Preserve date-only deadlines, describe suggestions as suggestions, and report incomplete sections. Recommendation dismissal and snooze open in Dayze. Use only writes listed by the connected profile.\n"
}