TimePeace — Daily Log

Check that the connection is live and see which permissions the person granted.

timepeace_status

Remove an entry that YOUR AI previously added to TimePeace, by its external_id. Can only ever remove what your AI added — never the person's own writing, and never an entry of yours they have since edited (editing it makes it theirs). If it will not remove, that is the promise working, not a failure — explain it rather than retrying.

timepeace_diary_remove

Create an exercise in the person's library (omit object_id) or update one (object_id from a resolve). Fields: name, cat (its workout category), type — strength (logged as weight × reps), bodyweight (reps) or cardio (minutes + distance). For an update, pass expect = the current values you READ for any field you overwrite; a value the person has since changed is skipped and reported, never overwritten. Pass a stable external_id — resending it updates the same thing instead of duplicating. This NEVER logs a workout as done. Needs the exercise editing permission.

timepeace_exercise_upsert

Create a saved workout template the person can start a session from (omit object_id) or update one (object_id from a resolve). Fields: name, cat, and items — the ORDERED list of exercises, each { exercise_id, name, type }; every exercise_id must be real (from the library, or create/resolve the exercise first). So "build me a three-day split" means: create or resolve each exercise, then create one template per day. For an update, pass expect for any field you overwrite (e.g. expect.items = the items you read). Writes the TEMPLATE only — logging a workout that did not happen stays impossible. Needs the exercise editing permission.

timepeace_exercise_template_upsert

Add ONE item to the person's own shopping list. cat_id picks the category — use one from timepeace_food_shopping_list, or leave it out for the Anywhere bucket; a cat_id that isn't theirs is refused rather than quietly filed somewhere else, and naming a new category stays their call, not yours. qty is free text as they'd write it ("2", "500g", "1 dozen"). usual:true marks a staple they re-buy, which survives clearing what's been bought. This adds to their OWN list only: the meal-derived part regenerates itself and cannot be written to, so if the item is already arriving from a confirmed recipe night — or is already in that category — nothing is added and you get told which, so you can say it's already covered instead of doubling it up on their screen. Pass a stable external_id — resending it retries the same add instead of creating a second line. Needs the food editing permission.

timepeace_food_shop_add

Add a recipe to the person's collection (omit object_id) or change one (object_id from timepeace_food_resolve). RESOLVE FIRST: a recipe they already have must be updated, never added a second time. Fields: name; cuisine; ingredients (a list of plain strings, one per line as they'd shop for them — "2 onions", "400g lentils"); method (the steps, one per line — a recipe with no method isn't ready to cook from, and the app says so); diet (only their real dietary tags: Vegetarian, Vegan, Gluten-free, Dairy-free, Nut-free, Pescatarian, Halal, Kosher, Low-carb — any other word is rejected rather than saved somewhere they'd never see it). Tag honestly: a wrong tag is what makes their diet filter lie to them. For an update, pass expect = the values you READ for any field you overwrite; a value they have since changed is skipped and reported, never overwritten. Pass a stable external_id — resending it updates the same recipe instead of duplicating. This never plans or logs a meal. Needs the food editing permission.

timepeace_food_recipe_upsert

Set or clear ONE slot of the person's meal plan. kind: "recipe" (pass recipe_id from a resolve — never guessed), "just_having" (a non-cook entry; pass text, e.g. "Cereal"), "skip" (a DELIBERATE skip — different from clearing), or "clear" (back to unplanned). Read the week first (timepeace_food_week): if the slot already has something planned you MUST pass expect = the planned value you read ({kind, recipe_id?, label?}); a value the person has since changed is never overwritten — you get the current plan back to relay instead. Off-diet recipes apply (their call, relayed by you) but come back flagged — say so plainly, never hide it. This never confirms or logs a meal as eaten. Pass a stable external_id — resending it retries the same change instead of duplicating. Needs the food editing permission.

timepeace_food_meal_set

Create a recurring routine on the person's plan (omit object_id) or update one (object_id from a resolve). A routine is a RULE — it lands on the matching days and the person ticks it off themselves: nothing here can mark anything done (done-state lives in their diary alone), and calendar sync stays the person's own opt-in per rule — this tool never touches it. Fields: title; type; time (HH:MM, 24h); duration_min; start/end (YYYY-MM-DD — start defaults to today on create, empty end = open-ended); repeat, one of { freq: "weekly", days: [1..7, Monday=1], interval? } · { freq: "monthly_day", day_of_month: 1..31 or "last" } · { freq: "monthly_weekday", nth: 1..4 or -1 for last, weekday: 1..7 }. For an update, pass expect = the current values you READ for any field you overwrite; a value the person has since changed is skipped and reported, never overwritten. Pass a stable external_id — resending it updates the same thing instead of duplicating. Needs the planner editing permission.

timepeace_planner_routine_upsert

Add a booking to a trip (omit booking_id) or change one (booking_id from timepeace_travel_trip_get). This is where a confirmation email becomes structure: kind — flight, stay, car, train or other; title (what it is, e.g. "BA 243" or the hotel name); ref (the confirmation number); date (YYYY-MM-DD); time (HH:MM, 24-hour); url (a link to the booking itself, http or https, never the email it arrived in); amount (what it cost, the number only — the trip owns the currency). A new booking needs a title or a ref — something the person can recognise it by. Read the trip first: when changing a booking you MUST pass expect = the values you read for any field you overwrite; a value the person has since changed is skipped and reported. Copy references exactly as they appear — never tidy, reformat or guess one. THE REFERENCE IS THE DEDUPE KEY: when a booking has one, build your external_id from it (e.g. "booking:ABC123") rather than from the message you read it in. That is what makes the same confirmation email, forwarded or re-read twice, change ONE booking instead of creating a second — resending an external_id always lands on the same booking. For countries and cities on a leg, use the ordinary English name as the app's own lists spell it, so the person's data doesn't fragment across spellings. Needs the travel editing permission. READING A CONFIRMATION EMAIL — the mapping, so you are never guessing: • IS IT A BOOKING AT ALL? Only a confirmation of something actually reserved: a flight, a stay, a train, a hired car. NOT fare alerts, price drops, marketing, suggested itineraries, or a boarding-pass reminder for a flight already recorded. A CANCELLATION is not a new booking — it changes or removes one that exists, so find that one first and ask the person what they want done with it. • AIRLINE → kind "flight": title = the flight number exactly as printed ("BA 243"); ref = the booking reference / record locator (the short 6-character code), NOT the ticket or e-ticket number; date and time = DEPARTURE, in the departure airport's own local time. • HOTEL → kind "stay": title = the property name; ref = the confirmation number; date = check-in. Only set a time if the email prints one — do not assume a standard check-in hour. • RAIL → kind "train": title = the service or route as printed; ref = the booking reference; date and time = departure, local to the origin station. • CAR HIRE → kind "car": title = the supplier and pick-up location; ref = the confirmation; date and time = pick-up. • TIMES ARE LOCAL AND LITERAL. Use the time printed on the confirmation, as printed. Never convert between timezones, never attach one, never infer one from an airport code — a flight leaving 18:40 is recorded as 18:40. An ARRIVAL time is in a different place's local time and is not what this field holds; record the departure. If only a range is given, take the start. If no time is printed, leave it empty — an empty field is fine, a guessed one is not. • A BOOKING IS NOT AUTOMATICALLY A LEG. A flight into a country or city the trip has no leg for SUGGESTS one — propose it and get a yes before adding it, because a leg changes the trip's route, its day counts and its visa prompts. A stay in a city that already has a leg adds nothing. A flight home is not a new leg. • AN UNCLEAR MATCH IS A QUESTION, NEVER A GUESS. Resolve the trip first (timepeace_travel_resolve): ambiguous means ASK which trip they mean; none means ASK whether this is a new trip rather than creating one, and never attach a booking to the nearest-looking trip because the dates are close. • READ THE TRIP BEFORE YOU WRITE. The app has its own inbox-to-booking suggestions the person approves themselves, so a booking may already be there. If the trip already holds one with this reference, you are correcting it (same reference, so build your external_id from the reference and it lands on the same booking) — not adding a second.

timepeace_travel_booking_upsert

Add a leg to a trip (omit leg_id) or change one (leg_id from timepeace_travel_trip_get). A leg is one stop on the trip: country (required for a new one), city, start and end (YYYY-MM-DD, or empty for undecided), and purpose — leisure, work or mixed, the person's own three words, nothing else. Read the trip first (timepeace_travel_trip_get): when changing a leg you MUST pass expect = the values you read for any field you overwrite; a value the person has since changed is skipped and reported, never overwritten. Pass a stable external_id — resending it changes the same leg instead of adding a second one. A leg is the trip's ROUTE, so it drives day counts and visa prompts: when a booking you read implies the person is going somewhere the trip has no leg for, PROPOSE the leg and get a yes before adding it, rather than inferring it from a flight. Needs the travel editing permission, chosen per area by the person.

timepeace_travel_leg_upsert