Calendar maintenance

Change posts that are already planned in Artima without losing track of them, publishing them by accident, or doing the same thing twice.

Ground rules

• Consent. Before any change, state exactly what will happen: which account, which post (its first line), and old → new time or text. Then get a clear yes. A yes covers the list you showed and nothing you add later. If the user's own message already identifies the exact post and the exact change and tells you to go ahead, that is consent for exactly that change.
• A request by date or category is not consent. "Cancel everything on Thursday", "delete all old drafts" or "clear my week" does not tell you which posts the user has in mind, because they have not seen the list. Look the posts up, show them, and wait for a yes in the user's next message before you change anything.
• Deleting needs a yes to the list you showed. delete_draft is permanent. Call it only after you have listed the exact posts to delete and the user has confirmed that list. When the user says "cancel" or "zruš", also offer to pause instead (unschedule_post keeps the post as a draft).
• Role. Editing a post's content needs Reviewer or higher. Changing times, scheduling, pausing, deleting and publishing need Editor or higher. Check with list_workspaces.
• Local time with an explicit offset. Artima does not know the user's timezone. If you don't know it, ask once. Send every time as ISO 8601 with the offset valid on that date, for example 2027-04-02T09:00:00+02:00, never a bare Z. Daylight saving changes the offset: in the EU on the last Sunday of March and of October.
• One post at a time. Make one change, read the result, update your notes, then move to the next post.

Which tool for which change

Post IDs that change

Some operations replace the post with a copy and return deprecatedPostId and newPostId:

• update_draft on a plain draft (one without a time; a scheduled or planned post keeps its ID);
• unschedule_post;
• update_schedule with an empty scheduleDate to clear the time.

From then on the old ID is dead. Use newPostId for every later call, including get_post_detail, schedule_post and delete_draft. If the result also has stalePostId, the old copy could not be removed. Tell the user, and with their OK call delete_draft on that stale ID; deleting does not publish anything.

Results you must handle

• TimedOut, or an error saying the backend did not respond in time. The change may have happened anyway. Do not repeat the call, and don't try to get the same result with a different tool. Wait a few seconds and check: get_post_detail on the post, and after an edit or pause also list_posts, looking for a duplicate draft. Report what you find. If it is still unclear, ask the user to look at the calendar in Artima before anything else is tried.
• TooCloseToFire (with secondsUntilFire): the post publishes in under about 90 seconds and can no longer be moved or paused safely. The only way to stop it is delete_draft. Ask the user right away: delete it, or let it go out.
• AlreadyPublished, CannotDelete, or unchanged on a posted post: it is live. Artima cannot edit or remove a published post from the network. The user has to edit or delete it on the platform itself.
• unchanged: true: nothing changed (for example, it was already a draft). Say so.
• "is in the past": ask for a future time.
• Status Idea, ToCheck, Approved, Cancelled or Failed: update_draft cannot edit these. Suggest opening the post in Artima.

Editing rules

• text replaces the whole caption. To fix a typo, send the full corrected caption.
• hashtags replaces the whole list, without #.
• mediaUrls replaces all media, so include every file that should stay.
• The caption plus its hashtags must fit the platform limit: X 280 (weighted characters), Threads 500, Pinterest 500, Instagram 2,200, TikTok 2,200, LinkedIn 3,000, Facebook 5,000, YouTube 5,000.

Workflow

1. Find the posts. list_accounts gives the socialAccountIds. Call list_posts once per account with either range (day, week or month, plus referenceDate) or startDate with endDate, never both. posts is a sample (default 25, maximum 100); filter it by status. Then call get_post_detail on each post you will touch, for its exact text, status and scheduledAt (UTC).

2. Plan. Show a before → after table in the user's local time:

   Post	Account	Now	After	Change
   "Spring blend is here…" (pst_123)	Instagram	Thu 1 Apr 09:00	Fri 2 Apr 09:00	move

   Ask for a yes, unless the request already was one for exactly these changes.

3. Apply the changes one post at a time with the tool from the table. After each call, read status, newPostId and note, and update your table.
4. Verify each changed post with get_post_detail, using its current ID.
5. Report the final table: post, account, old → new, final post ID, status. Point out anything left for the user, such as a stale copy to delete or a post that is already live.

When you move several posts "to Friday", keep each post's local time and work out the offset for the new date. It can differ across a daylight-saving change.