TimePeace — Daily Log

Return counts of the person's entries by type over a date range (needs the reading permission) — a roll-up, not the full content.

timepeace_diary_period

Return the person's journal note and entries for a single day (needs the reading permission).

timepeace_diary_day

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 plan (omit object_id) or update one (object_id from plan_get or a resolve). kind=session: name plus blocks, the ORDERED parts of one workout. A cardio block is { kind: cardio, mins or dist_m, optional target { type: zone (value 1-5) | pace (seconds per km) | power (watts) | hr (beats per minute) | easy, value or lo/hi }, optional repeat and rest in seconds }; a strength block is { kind: strength, exercise_id (from the library) and/or name, sets, reps, load { type: pct (of their estimated max) | rpe | rir | kg | bodyweight, value } }. kind=training: name, rule (hold, add10 = ten percent more each week, or deload), optional deload_every (a lighter week every 2-12 weeks), and weeks — each { days: [{ weekday 0 = Monday … 6 = Sunday, session_plan_id }] }. Every session_plan_id must be a session plan the person already has, so create the sessions first. A malformed plan is REFUSED with the part that is wrong, never quietly fixed. This writes the plan only — it never logs a workout and never puts days on their planner; the person places a plan themselves in the app.

timepeace_exercise_plan_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

List the person's exercise setup: their workout categories, their exercise library (each exercise with its exercise_id, name, category and type) and their saved workout templates (summaries). Needs the reading AND health permissions — if refused, relay the plain message rather than retrying. Use this before building or changing a routine, so template items reference real exercise_ids.

timepeace_exercise_library

Before creating or changing an exercise or workout template, resolve what you have against what already exists. Returns one of three outcomes: match (use its object_id for your change), ambiguous (ASK the person which they mean — never pick the top candidate yourself, and never create a new one), or none (creating a new one is legitimate). Needs the exercise editing permission, chosen per area by the person.

timepeace_exercise_resolve

Read ONE saved workout template in full — its name, category and ordered items (each with exercise_id, name and type). Needs the reading and health permissions. Get the template_id from the library list or a resolve.

timepeace_exercise_template_get

List the person's structured training: their SESSION plans (one workout as ordered blocks — cardio blocks with a target and a length, strength blocks with sets, reps and a load rule) and their TRAINING plans (weeks of days, each day naming a session plan, under one progression rule). Omit plan_id for a list of summaries; pass a plan_id to read one plan in full, in exactly the shape timepeace_exercise_plan_upsert takes back. Needs the reading AND health permissions.

timepeace_exercise_plan_get

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

List the person's OWN recipe collection — each with its recipe_id, name, cuisine, how many ingredients it has, its dietary tags, and whether a method has been written yet. Needs the reading permission. A meal can only be planned to one of these ids: there is no way to plan a recipe that isn't in their collection, so read here (or resolve by name) before planning, and create the recipe first if it genuinely doesn't exist. has_method:false means they saved the recipe but never wrote the steps — it isn't ready to cook from, so say so rather than inventing a method for them.

timepeace_food_recipes

Before setting a meal to a recipe, resolve the recipe name against the person's own collection. Returns one of three outcomes: match (use its object_id as recipe_id), ambiguous (ASK the person which they mean — never pick the top candidate yourself), or none (there is no such recipe — you cannot invent one here; offer kind "just_having" with the dish as text instead). Never guess recipe ids. Needs the food editing permission, chosen per area by the person.

timepeace_food_resolve

Read ONE of the person's recipes in full — its ingredients and its method, as they wrote them. Needs the reading permission. Get the recipe_id from timepeace_food_recipes or a resolve. What you read here is the recipe as it stands RIGHT NOW: these are the values to quote back as expect if you change it, so their own edits always win.

timepeace_food_recipe_get

Read the person's planned meals: their configured eating cadence (slots — e.g. just Dinner, or Breakfast/Lunch/Dinner), their diet list, any active fasting windows, and each day's per-slot plan in their own vocabulary — a recipe, a freezer portion, eating out, takeaway, leftovers, a non-cook "just having" entry, their own dish, or a DELIBERATE skip (which is different from unplanned: planned = null means nothing was chosen). Needs the reading permission. To change a meal, read here FIRST, then use timepeace_food_meal_set with expect = the planned value you read. When suggesting, respect their diet list: flag off-diet ideas rather than hiding them, and never override what they chose to eat.

timepeace_food_week

Read the person's shopping list. TWO different things live on it and they are NOT interchangeable. `items` is their OWN list — everything they added by hand, food and non-food, in the categories THEY named (a shop, a room, a job) plus the always-present Anywhere bucket (cat_id "") — with quantity, whether it's ticked off, and whether it's a "usual" they re-buy. `from_meals` is DERIVED: it is rebuilt automatically from the recipe nights they confirmed, minus the staples they keep in, every time a meal changes — so it is read-only, and the way to change it is to plan and confirm meals, never to write to the list. Needs the reading permission. Read this before adding anything, so you never put something on the list that is already coming from their meals.

timepeace_food_shopping_list

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

Add a to-do to the person's list (omit task_id) or change one (task_id from timepeace_planner_tasks). This is the plainest thing this connection does: "add that to my list", and "I did those three today". Fields: text (the to-do itself, required when adding); done (true to tick it off, false to put it back); due (YYYY-MM-DD, or empty for no date); note; steps (plain strings). TO TICK SOMETHING OFF you must have READ it first and pass expect.done = the value you read (normally false) — otherwise it is left alone and reported back, because a to-do the person already ticked is not yours to flip. Never mark something done you were not told was done: guessing here rewrites their record of their own day. ⚠ Ticking a to-do does NOT tick its steps — the person can do those — and sending `steps` REPLACES the whole checklist and clears which are ticked, so send it only when you mean to rewrite the list. For any other change, pass expect = the values you READ for the fields you overwrite; a value they have since changed is skipped and reported, never overwritten. Pass a stable external_id — resending it changes the same to-do instead of adding a second one. Needs the planner editing permission.

timepeace_planner_task_upsert

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

List the person's routines — the recurring rules that place things on their days (each with its routine_id, title, type, time, duration, plain-words repeat, the raw repeat_rule, start/end and whether it is paused). Needs the reading permission; a routine whose type is gated by another permission (e.g. a fitness routine needs health) is only included when that permission is granted too. Use this before creating or changing a routine; when updating a recurrence, echo the repeat_rule you read here as expect.rule.

timepeace_planner_routines

List the person's to-dos — what is on their list, with each one's task_id, its words, when it is due, any note, its steps, and whether it is already done. Needs the reading permission. Read this before adding, so you don't add something they already have, and before changing one, so you can echo what you read as expect. A to-do the person typed themselves may have no task_id yet; those can be read but not changed — say so plainly rather than guessing at which one they meant.

timepeace_planner_tasks

Before creating or changing a routine, resolve the title you have against what already exists. Returns one of three outcomes: match (use its object_id for your change), ambiguous (ASK the person which they mean — never pick the top candidate yourself, and never create a new one), or none (creating a new one is legitimate). Needs the planner editing permission, chosen per area by the person.

timepeace_planner_resolve

Put a one-off thing on one of the person's days (omit plan_id) or change one (plan_id from timepeace_planner_plans). This is for a thing that happens ONCE — "the dentist on Thursday at 3". Something that repeats is a routine instead: use timepeace_planner_routine_upsert, or the person will get one dentist appointment and no more. Fields: date (YYYY-MM-DD, required when adding); text (what it is, required when adding); time (HH:MM, 24h); duration_min; type; note. ⛔ This NEVER touches the person's calendar. A plan you add is theirs alone until they choose to sync it — you cannot turn that on and must not tell them it is in their calendar. Nor can you skip a plan for them. For a change, pass expect = the values you READ for any field you overwrite; a value they have since changed is skipped and reported back, never overwritten. Pass a stable external_id — resending it changes the same plan instead of adding a second one. Needs the planner editing permission.

timepeace_planner_plan_upsert

Read what the person has planned, day by day — each with its plan_id, its words, the day it is on, the time and duration if it has them, its type, any note, and whether they have already skipped it. Needs the reading permission; a plan whose type is gated by another permission (a fitness plan needs health) is only included when that permission is granted too. Read this BEFORE adding, so you don't put a second dentist on a day that already has one, and before changing anything, so you can echo what you read as expect.

timepeace_planner_plans

Ask to take a to-do off the person's list. Unlike the other write tools this one NEVER happens on its own: removing a whole thing always waits for the person to say yes in their app, so the honest thing to tell them is that you have asked, not that it is gone. Get the task_id from timepeace_planner_tasks. A to-do that is finished is usually better ticked off by them than removed by you — removing loses it from their record. Needs the planner editing permission.

timepeace_planner_task_remove

Ask to take a one-off plan off the person's day. Like any whole-thing removal this NEVER happens on its own: it waits for the person to say yes in their app, so tell them you have asked, not that it is gone. Get the plan_id from timepeace_planner_plans. If something was simply cancelled, consider whether they would rather keep it on the day as a record — removing loses it. Needs the planner editing permission.

timepeace_planner_plan_remove

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

Put ONE item on the trip's packing list, or tick one that is already there. item = the words the person will read on their own screen ("Sun cream", "Passport"), and those words ARE the item's name: sending the same wording again lands on the SAME row rather than making a second one — which is what makes "add everything for a beach week" safe to run twice. category must be one of the app's own seven: Docs, Clothes, Tech, Toiletries, Health, Gear, Other (anything else is refused rather than quietly filed under Other). packed:true ticks it off, false un-ticks it. ALWAYS pass expect with the packed value you read on an item that already exists: an unticked box is still the person's own state, not a blank, so a tick without expect is skipped and reported back rather than applied — and since you had to read the list to get the item's words, you already have the value to quote. There is no way to REWORD an item: its words are its name, so changing them would silently point at a different row — remove it and add the new wording instead. One item per call, deliberately: each one gets its own line in the person's record and its own undo, so a list you built can be unpicked one item at a time. Pass a stable external_id — resending it retries the same add safely. Needs the travel editing permission. A trip can have TRAVELLERS, and then a list belongs to a person: for = the traveller's name exactly as timepeace_travel_trip_get returns it, and leaving it out means EVERYONE — the shared list, not a guess. That matters because the same words can now sit on two people's lists: "Sun cream" for Ella and "Sun cream" for Sam are two rows, and a call with no for lands on the shared one and only the shared one. So say who when the person did ("pack a swimsuit for Sam"), and read the trip first — travellers comes back with it, and each item says who it is for. A name the trip does not have is treated as Everyone rather than inventing a traveller. Naming a DIFFERENT person on an item that already exists moves it to them.

timepeace_travel_packing_add

Put ONE job on the trip's pre-trip list ("Notify bank of travel dates", "Out-of-office set"), or tick one that is already there. Like the packing list, the words ARE the item's name: the same wording twice lands on one row, and an item cannot be reworded — remove it and add the new wording. done:true ticks it off, false un-ticks it — and on an item that already exists, ALWAYS pass expect with the done value you read: an unticked box is the person's own state, not a blank, so a tick without expect is skipped and reported rather than applied. The app can seed a standard checklist itself, so before adding the obvious ones (passport validity, insurance, bank, roaming, out-of-office) read the trip — they may already be there, and telling the person it is already covered is better than a duplicate line. Needs the travel editing permission.

timepeace_travel_prep_add

Put ONE document on a visa's checklist, or tick one that is already there. document = the words the person will read ("Bank statements — last 3 months"), and those words ARE its name: the same wording again lands on the SAME row rather than making a second one. have:true ticks it as gathered, false un-ticks it — and on a row that already exists ALWAYS pass expect with the value you read, because an unticked box is the person's own state rather than a blank. A document cannot be reworded: remove it and add the new wording. Naming a visa type on the visa itself already brings that type's standard checklist, so read the visa before adding the obvious ones. Needs the travel editing permission.

timepeace_travel_visa_document_add

Add a visa to a trip (omit visa_id) or update one (visa_id from timepeace_travel_trip_get). country is what the visa is FOR and is required when adding. type is the person's own wording for it — the app offers Schengen, UK Standard Visitor, visa-free and Other, and naming one of those four also brings that type's standard document checklist with it, exactly as the app does when they add a visa themselves. status is their own five words and nothing else: not started, in progress, submitted, approved, refused. ref is the reference number — copy it EXACTLY, never tidy or reformat it. submitted, appointmentDate, deadline and decisionDate are dates (YYYY-MM-DD, or empty for not yet). notes is free text. RECORDING AN OUTCOME: setting status to approved or refused stamps today as the decision date when they haven't set one — the same thing the app does — which is what keeps their "decision received, what was the outcome?" prompt correct; so record an outcome only when you actually know it. For an update, pass expect = the values you READ for any field you overwrite; a value the person has since changed is skipped and reported, never overwritten. A visa is one of the most consequential things on a trip: when what you have read is ambiguous — which visa, whether it was really refused — ASK, never guess. Needs the travel editing permission.

timepeace_travel_visa_upsert

Create a trip (omit object_id) or update one (object_id from timepeace_travel_resolve or timepeace_travel_trips). Fields: name; start/end (YYYY-MM-DD, or empty for undecided); status — planning, booked, active or done, the person's own four words, nothing else; abroad (true/false); needsFlights (true/false — this is what opens the flights & bookings section on their trip, so only set it when they actually want to track flights); budget (free text, e.g. "R20 000" — currency is theirs to set in the app); notes. A new trip needs a name and starts as planning, abroad, with no flights tracked, matching what the app itself creates. This tool sets the trip's OWN fields only — legs, visas, bookings, packing and prep are the person's lists and are not touched here. For an update, 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 updates the same thing instead of duplicating. Needs the travel editing permission.

timepeace_travel_trip_upsert

List the person's trips — for each: its trip_id, name, dates, status (planning, booked, active or done), whether it is abroad, and how many legs, visas and bookings it holds. Needs the reading permission. Read the list first, then timepeace_travel_trip_get for one trip's full detail. Changing a trip is a separate per-area permission the person grants when they connect you; reading never implies it.

timepeace_travel_trips

Before creating or changing a trip, resolve the name you have against what already exists. Returns one of three outcomes: match (use its object_id for your change), ambiguous (ASK the person which they mean — never pick the top candidate yourself, and never create a new one), or none (creating a new one is legitimate). Dates sharpen the match: two trips to the same place in different months are different trips. Needs the travel editing permission, chosen per area by the person.

timepeace_travel_resolve

Read one trip in full — name, dates, status, whether it is abroad, legs (country, city, dates, purpose), visas (type, status, key dates, checklist), bookings (kind, title, reference, date, time, link and amount), packing and prep lists, budget, emergency details and notes. Use the trip_id from timepeace_travel_trips. What you read here is the trip as the person has it RIGHT NOW — if changing is ever granted to you, these are the values to quote back so the person's own edits always win. Needs the reading permission.

timepeace_travel_trip_get

Remove one booking from a trip. Like a leg, this is small and recoverable — the removed booking is journalled in full and the person can undo it in their app — so it applies straight away; the trip and everything else on it are untouched. Get the booking_id from timepeace_travel_trip_get; removing an already-removed booking is safe and simply reports it was not there. A cancelled booking is often worth keeping as a record — ask before removing rather than assuming. There is no tool for deleting a whole trip. Needs the travel editing permission.

timepeace_travel_booking_remove

Remove one leg from a trip. This is a small, recoverable change — the removed leg is journalled in full and the person can undo it in their app — so unlike deleting a whole trip it applies straight away. The trip itself, and its other legs, visas, bookings and lists, are untouched. Get the leg_id from timepeace_travel_trip_get; removing an already-removed leg is safe and simply reports it was not there. There is no tool for deleting a whole trip — that stays the person's own hand in the app. Needs the travel editing permission.

timepeace_travel_leg_remove

Take ONE item off the trip's packing list, named by its text exactly as timepeace_travel_trip_get returns it. Small and recoverable — the removed row is journalled in full and the person can undo it in their app — so it applies straight away. Removing something that is already gone is safe and simply reports it was not there. Nothing else on the trip is touched. Needs the travel editing permission. If the trip has travellers, the same words can sit on two people's lists, so say WHOSE: for = the traveller's name as the read returns it. Leaving it out means the shared everyone list and only that one — it will never take a row off a person's list because the words happened to match.

timepeace_travel_packing_remove

Take ONE job off the trip's pre-trip list, named by its text exactly as timepeace_travel_trip_get returns it. Journalled in full and undoable in the app, so it applies straight away; removing something already gone is safe and simply reports it. A job they have decided against is often still worth keeping ticked as a record — ask before removing rather than assuming. Needs the travel editing permission.

timepeace_travel_prep_remove