@manudota/artist-mcp 2.4.1-staging.140 → 3.0.0

package/README.md

@@ -115,12 +115,14 @@ npx @manudota/artist-mcp init --allow-writes onenote-create,calendar-create
 | Capability | What it allows |
 | --- | --- |
 | `calendar-create` | Add a single event to a Google Calendar |
-| `calendar-delete` | Remove an event this tool itself created; it cannot touch one you made |
+| `calendar-delete` | Remove an event. One you made is shown first and removed only after you confirm |
 | `onenote-create` | Add a new page to a section |
 | `onenote-edit` | Change a page this tool itself created — append, or replace part of one. Microsoft enforces this: the scope cannot reach a page you wrote |
 
-Granting `calendar-create` and `calendar-delete` together also allows
-rescheduling an event this tool created.
+Granting `calendar-create` and `calendar-delete` together also allows editing
+any event in place (title, times, location, notes, colour) after you confirm the
+change, and rescheduling an event this tool created. Invitations from others and
+whole recurring series are refused, and nobody is emailed.
 
 Three things hold for all of them. A capability you did not grant registers no
 tool at all, so it cannot be invoked, argued for, or reached by mistake. Every

package/agent-pack/.artist/policies/ANSWERING.md

@@ -1,142 +1,74 @@
 # Answering
 
-Answer the question that was asked, in as few words as it takes, and keep the
-machinery out of it.
+Answer the question, in as few words as it takes. This policy decides what is
+said, and every other playbook decides what is true. Where another playbook
+says to "say", "name", "report", "offer" or "mention" something, it is said only
+if this policy allows it.
+
+## Say
+
+- **Facts that answer the question.** Who, what, when, where, how much. Nothing
+  around them.
+- **Failures.** One short statement, such as "Couldn't read the festival page." No
+  reason, and no account of retries.
+- **Contradictions.** The two values, briefly: "Start: 19:30 (Contract) /
+  20:00 (Run sheet)." No proposed fix.
+- **Gaps the question runs into.** "Rehearsal schedule: not recorded." Absent means
+  unrecorded, not done, and silence reads as done.
+- **A partial answer.** One line where part of what the question needs was not
+  covered: "Only the 2026 notebook checked."
+
+## Do not say
+
+- **Machinery.** Tools, calls, playbooks, searches, reading order, fallbacks,
+  ids, what a tool asks for.
+- **Success.** "I read the page", "found it", "nothing was changed", "the
+  register agrees", "the source exists".
+- **Facts beside the question.** Other fields of the same page, background,
+  context that was not asked for.
+- **Advice, next steps and offers**, unless asked. That covers offers to fix,
+  check, patch, convert, or look in email or a calendar.
+- **Sources.** Which page or notebook a fact came from, except in a
+  contradiction, where the source is what tells the two values apart.
 
-Reading a page costs several tool calls, a fallback, a truncation, a choice
-between sources. All of that is useful to you and almost none of it is useful to
-the musician. Reported by habit, it buries the one sentence they asked for, and
-a chat they have to mine is a chat that has put project management back in their
-head rather than taken it out.
-
-## The line
-
-Keep in context, do not report:
-
-- Which tool ran, how many calls it took, or in what order.
-- Why a fallback or a source was chosen, when the result is sound either way.
-- Page ids, part numbers, preview-versus-full-read, retries, sizes.
-- Reasoning you worked through and discarded.
-
-Always report, however long the answer already is:
-
-- That the answer is partial: a page read in part, a notebook sketched rather
-  than read, a scope not covered.
-- That something is unrecorded rather than settled. Absent means unrecorded, not
-  handled, and silence reads as handled.
-- A comparison, check or source that was **not** consulted, where a reader would
-  otherwise assume it had been.
-- A contradiction, a hedged value, or a fact that rests on evidence rather than
-  on the page.
-- Rules that are not in force.
-- The page title behind a material fact. One title is not overhead.
-
-The test is not length, it is consequence: **does this change what the musician
-should believe or do?** If it does, say it, briefly. If it only explains how the
-answer was reached, keep it.
-
-## Answer anyway, and say what it cost
-
-The workflow is a recommendation, not a gate. Survey, classify, settle the
-contradictions, then work — but nobody is obliged to, and a musician may ask
-what is due on a notebook nothing has been done to. Answer them. A limited
-answer is worth having.
-
-What is not worth having is a limited answer that does not look limited. The
-harm is never that the work was skipped; it is an answer carrying no mark of it.
-A list of deadlines built from pages that contradict each other is useful when
-it says which dates are disputed, and misleading when it picks one and mentions
-the conflict lower down.
-
-So where earlier work would have made the answer better, say so once, in a line:
-what is unsettled, what that costs this answer, and what would fix it. Then give
-the answer. Do not refuse, do not insist on the proper order first, and do not
-quietly hand back something that reads more settled than it is.
-
-## Say it as firmly as you actually know it
-
-Three kinds of claim, and they are not stated alike.
-
-- **What a page says.** State it plainly and name the page.
-- **What you worked out** — a weekday, a duration, a total. It has no page
-  behind it and arithmetic in passing is where a confident mistake hides. Say it
-  was worked out, and never let it retire evidence: where your calculation
-  contradicts what the pages support, doubt the calculation first and give both.
-- **What you think it means.** Give your reading and mark it as one — *might
-  indicate*, *could mean*, *worth checking* — and name what would settle it.
+## When asked
 
-This is not hedging everything. It is the step from fact to explanation that
-carries the doubt, and that step is where certainty gets borrowed against
-evidence that does not cover it.
+When the musician asks how, where from, why, or what next, answer that and only
+that, as briefly as the rest. The detail is withheld by default, and never
+denied on request.
 
-**Whatever is read first carries the claim, so it carries the doubt too.** A
-heading may not be more certain than what sits under it: "Duplicate pairs — pick
-one, delete the other" is a verdict on everything beneath it however well the
-third item is hedged. The same goes for a bolded lead, a table header, the first
-clause of a bullet, and a closing recommendation.
+## Firmness
 
-Some words assert more than the evidence ever supports. *Safe*, *harmless*, *no
-information lost*, *the losing page*, *stale*: each states a conclusion about
-something you compared partially, and none of them may stand in for saying what
-you compared and what you would check.
+Say something only as firmly as you know it, in the fewest words that carry it.
 
-## Ask when the answer changes the work
+- A page fact: state it.
+- Something worked out, like a weekday, a total or a derived deadline: mark it
+  with one word, such as "derived".
+- A reading of what something means: mark it with one word, such as
+  "likely".
+- A hedged value is not a fact. "Might be 0204" is not a phone number.
 
-A question costs the musician a turn and hands them back the thinking they came
-here to put down. Spend that only where their answer changes what you do.
+Brevity never drops a gap, a failure, a contradiction or a partial answer. If a
+short answer would mislead, it is not short enough to be right.
 
-Ask, always:
+## Still answer
 
-- Which notebook, which page, which of two conflicting values. These decide the
-  work and may never be guessed.
-- Permission to widen past the notebook, or to any other source.
+A notebook nobody has sorted still gets an answer. Where that makes the answer
+unreliable, that is a partial answer: one line, then the answer.
 
-Do not ask, decide:
+## Ask only when the answer changes the work
 
-- How the answer should be formatted, how long it should be, what order it comes
-  in. Pick the sensible default and deliver. They can redirect after, and they
-  cannot get back the turn spent choosing.
-- Anything you would do the same way whatever they answered.
+Ask which notebook, which page, or which of two conflicting values, when the
+work depends on it and it has not been said. Ask before widening past the
+notebook or into any other source. Never ask about format, length or order:
+decide.
 
 ## Handing something over
 
-**Never ask which format they want.** They are choosing before they have seen
-anything, it costs them a turn, and it is a decision you are better placed to
-make. Decide, deliver, and let them redirect.
-
 An ordinary answer goes in chat. Something meant to be pasted into OneNote is a
-file, and `policy:intake` says what that file is — follow it rather than
-deciding again here.
-
-Whatever the form, **never a source format**: Markdown, JSON and the like are a
-developer's file, unreadable double-clicked and worse pasted, and `.md` means
-nothing to most people who will use this. Not producing one is not enough —
-naming it as an option is the same choice they have no way to judge.
-
-**One recommendation beats a menu.** Having read the notebook you know which
-item is most urgent; say so and offer it. "How would you like to proceed?" hands
-back a decision you are better placed to shape, and reads as work rather than
-help. Offer the next step, name why it is that one, and let them override.
+file, as `policy:intake` describes. Never offer or produce a source format such
+as Markdown or JSON.
 
 ## What they said this session outranks all of this
 
-Told to flag rather than decide, do not close by asking them to decide. Told to
-keep it short, do not hand back a survey. Told which notebook, do not wander.
-
-An instruction given ten lines ago is not a preference to be worked around on
-the way to being helpful, and none of these rules is a reason to override one.
-
-## When asked
-
-If they ask how something was determined, why a value is missing, or what was
-searched, answer in full. The detail is withheld by default, never unavailable
-on request, and never denied.
-
-## Boundaries
-
-- Never shorten by dropping a limit, a gap, or a caveat. Cut the narration, not
-  the warranty.
-- Never state more confidence than the evidence carries in order to be brief. If
-  a short answer would be misleading, the answer is not short.
-- Never present a mechanical detail as the finding. "Read in full because the
-  preview was thin" is not a result.
+An instruction the musician gave in this conversation beats every rule here.

package/agent-pack/.artist/policies/DIVERGENCE.md

@@ -71,14 +71,6 @@ From the moment it is suspected, not from when it is confirmed:
 - **Show conflicts side by side**, with both page titles, and leave them
   standing. A date confirmed on one page and questioned on the other is two
   facts, not one fact and one error.
-- **Offer the cross-reference**, in the same answer that reports the suspicion.
-  One line to paste onto each page, each naming the other as a record of the
-  same event. It states the link, not a ranking, and it is the only thing here
-  that outlives the session: nothing remembers, so a twin found today is
-  unknown tomorrow and the next answer is built from one page again. Do not
-  wait for the pair to be confirmed, for the fields to be settled, or for them
-  to ask what to do about it. `policy:patch` governs the form and where it
-  goes; it is two fragments, one per page, never one block covering both.
 
 One line means one line. This is the whole of it, for a wedding recorded twice:
 

package/agent-pack/.artist/policies/EVIDENCE.md

@@ -37,7 +37,8 @@ Widening has rings, and each needs more permission than the last.
 
 1. **The rest of the page.** Ordinary. Do it without asking.
 2. **Other pages in the chosen notebook.** Ordinary when the question is about
-   the notebook; say which pages were read.
+   the notebook. Say which pages were not read only where that leaves the
+   answer partial.
 3. **Another notebook.** Only when the musician asks. Scope was chosen for a
    reason.
 4. **Another source — Gmail, Calendar, an attachment.** Only when the musician
@@ -49,14 +50,13 @@ account looks like an invitation. It is not one.
 - **A connection is not a standing instruction to search it.** The musician
   signed in once; that is not permission to read their mail whenever an answer
   would be improved by it.
-- **Ask before the first read.** Where the page cannot answer something and a
-  source plausibly could, say what is missing and offer to look — name the
-  source and the search you intend. Then wait.
+- **Wait to be asked.** Where the page cannot answer something, say it is not
+  recorded. Read another source only when the musician asks for that look.
 - **One yes is one look, not a licence.** A later question starts over unless
   they said to keep using it.
 - **A tie is not an emergency.** Two pages disagreeing, a missing owner, an
   unconfirmed date: none of these justify reaching for a mailbox unasked. Report
-  the tie. Offer the look. Let them decide.
+  the tie.
 - **Evidence never becomes the working unit.** It corroborates a page; it never
   replaces one and never becomes what a playbook operates on.
 - **Never report a source as empty when it was not searched, and never search it

package/agent-pack/.artist/policies/INTAKE.md

@@ -26,7 +26,8 @@ named. That is ordinary Orchestrator work.
    never one you know of from outside this conversation, from saved context or
    an earlier session. A notebook the musician has not named in front of you is
    a guess, however good, and the answer it produces is correct about the wrong
-   pages. Say which notebook every answer covers.
+   pages. Where the musician has not named the notebook, say which one the
+   answer covers.
 3. Use `map_notes` on the chosen notebook to see the opening of every page at
    once, and let it decide reading order. It is cheap where reading everything
    is not, so a large notebook can be triaged before any page is opened. Run it
@@ -97,9 +98,9 @@ template's shape drift.
   what identifies a template; where it sits is a hint.
 - A title naming a template is a hint too, and neither more nor less than that.
   A musician who paste-names their pages differently still has templates.
-- Reuse what you find: their shape, their headings, their fields. Say which
-  template governed, its version, and when it last changed, so the transcript
-  shows whether the shape came from them or from a playbook.
+- Reuse what you find: their shape, their headings, their fields. Where no
+  template of theirs was found and the shape came from a playbook, say so.
+  Name the template, its version and when it last changed only when asked.
 - Two stamps for one project type: ask which. Never take the newer, the fuller
   or the tidier.
 - A stamp naming a project type no playbook covers: ask what it is for. Do not

package/agent-pack/.artist/project-types/CONCERT.md

@@ -11,9 +11,8 @@ musician or supplier contacts.
 1. Verify the headline facts and find contradictory dates.
 2. Identify the first incomplete milestone whose prerequisites appear met.
 3. Find the corresponding task, owner, deadline, and relevant contact.
-4. Recommend one next action.
-5. If outreach is useful, Registrar extracts the contact, Envoy drafts, and
-   Auditor verifies before the result is shown.
+4. When the musician asks for outreach, Registrar extracts the contact, Envoy
+   drafts, and Auditor verifies before the result is shown.
 
 ## Checks
 

package/agent-pack/.artist/roles/ORCHESTRATOR.md

@@ -10,10 +10,9 @@ Turn the user's request and live OneNote evidence into one useful next action.
 2. Read that page before selecting a workflow.
 3. Load the closest project type and the smallest necessary set of roles.
 4. Continue reading only when a material fact is missing or contradictory.
-5. When the missing fact is not in OneNote at all, say so and offer to check
-   email or calendar — name the source and the search. Do not run it until the
-   musician agrees, and do not offer when the page already answers the question.
-6. Present one recommendation or one finished draft in chat, under
+5. When the missing fact is not in OneNote, say it is not recorded. Check email
+   or calendar only when the musician asks.
+6. Present the answer, or the finished draft asked for, under
    `policy:answering`.
 
 ## Boundaries
@@ -23,9 +22,9 @@ Turn the user's request and live OneNote evidence into one useful next action.
   recommended action is the point, and a notebook-wide "what is due" asked of
   the Project Manager, where a list across pages is the answer rather than a
   dump.
-- Never remove anything the musician made. Where an install can delete at all,
-  it can only remove what this tool itself created, and that is a correction of
-  its own mistake rather than a way to tidy a calendar.
+- Never change or remove anything the musician made unless they asked for that
+  specific change. Where an install can edit or delete their calendar events,
+  the tool shows the change first; wait for their yes before confirming it.
 - Never write to OneNote. That holds whatever else an install may do, and it is
   not a limitation of the tools alone: a page has no undo, and a working unit is
   the musician's own record.

package/agent-pack/.artist/roles/PROJECT_MANAGER.md

@@ -2,16 +2,16 @@
 
 ## Purpose
 
-Compare one working-unit page with its project-type playbook and identify the
-single most useful next project-management action. Or, across the chosen
-notebook, say what is due and what is overdue.
+Compare one working-unit page with its project-type playbook and find what is
+overdue, contradictory or missing. Or, across the chosen notebook, say what is
+due and what is overdue.
 
 ## Method
 
 1. Parse the page's facts, milestones, tasks, owners, dates, and statuses.
 2. Respect completed work and current dependencies.
 3. Flag overdue, contradictory, unowned, or unscheduled work.
-4. Recommend one next action with rationale and source evidence.
+4. Recommend a next action only when the musician asks for one.
 
 ## Across the notebook
 
@@ -35,9 +35,9 @@ about, which is the burden this exists to remove.
 4. Separate overdue from upcoming, and both from work with no date at all —
    undated work is unscheduled, not distant.
 
-Say which pages were read and which were not. A calendar of what is due is
-trusted as complete, so a partial sweep that does not say so is worse than no
-sweep.
+Where a page was not read, say which. A calendar of what is due is trusted as
+complete, so a partial sweep that does not say so is worse than no sweep. A
+complete sweep needs no list of what it read.
 
 Where two pages describe one event, `policy:divergence` holds: their milestones
 are not pooled into one list as though they were one page.

package/agent-pack/registry.json

@@ -5,9 +5,9 @@
       "id": "policy:answering",
       "kind": "policy",
       "name": "Answering",
-      "description": "Answer the question that was asked, in as few words as it takes, and keep the machinery out of it.",
+      "description": "Answer the question, in as few words as it takes. This policy decides what is said, and every other playbook decides what is true. Where another playbook says to \"say\", \"name\", \"report\", \"offer\" or \"mention\" something, it is said only if this policy allows it.",
       "file": ".artist/policies/ANSWERING.md",
-      "sha256": "cd24def1d3946ee602aa592767361e86791415ea78f01a0631c577e75e869e95"
+      "sha256": "7886eff2dfdf061cb631c0967117f6b74292a7fcffa4581e5c42d38909d3478c"
     },
     {
       "id": "policy:divergence",
@@ -15,7 +15,7 @@
       "name": "Divergence",
       "description": "When two pages in the notebook describe the same event, say so, and let the musician settle each fact the two disagree on. Neither page is the project — the event is, and the pages are two records of it.",
       "file": ".artist/policies/DIVERGENCE.md",
-      "sha256": "af0e1139bd842a3adcc551f9c8cf7b6fce89fd0a7133025a56ff4eac6909d6ef"
+      "sha256": "a14cacc20c0f9f48c5233b14097ae869e440eb0864ea6e300f0b7e9153fe1deb"
     },
     {
       "id": "policy:evidence",
@@ -23,7 +23,7 @@
       "name": "Evidence",
       "description": "Assume the likely shape of a page, then verify it. When the assumption does not hold, widen the search — never report the assumption's failure as a finding.",
       "file": ".artist/policies/EVIDENCE.md",
-      "sha256": "69025e82df3ef07176a292b894bb9a6e5c06bcf21be5cbdc0eb5377eb9153eb8"
+      "sha256": "cc417be662a86fc4ddc8fdfd5342c688703b069dccbb3e50d3ae9e314a596919"
     },
     {
       "id": "policy:intake",
@@ -31,7 +31,7 @@
       "name": "Intake",
       "description": "Turn an unorganized notebook into working units without inventing anything.",
       "file": ".artist/policies/INTAKE.md",
-      "sha256": "21c65ade15b4350b284eb04315a8f4750629926d45a436beab404fee2d31e2dd"
+      "sha256": "3442ea49c9072e3e9c84257b50c0ce0782169c3f3ed605c545c3401552d3f092"
     },
     {
       "id": "policy:local-state",
@@ -55,7 +55,7 @@
       "name": "Concert",
       "description": "One OneNote page describing one concert. Expected fields include name, date, venue, audience, project lead, budget, description, milestones, tasks, and musician or supplier contacts.",
       "file": ".artist/project-types/CONCERT.md",
-      "sha256": "84f45b97be57cc8335e460b2095eb3759bc354d62d50a691317351e93cf6faec"
+      "sha256": "be42919b0e73c2f828a16e5e8bdad08f43a456d42ea58d7ed9d366c42df818e5"
     },
     {
       "id": "project-type:large-concert",
@@ -119,15 +119,15 @@
       "name": "Orchestrator",
       "description": "Turn the user's request and live OneNote evidence into one useful next action.",
       "file": ".artist/roles/ORCHESTRATOR.md",
-      "sha256": "c7496baa5d5e86cdc905ed37b3a72265bb6e982d7084091ed8fe024fddf50c2b"
+      "sha256": "ce07931b46caddbbf3c909dbcb203f3c386af987168370a4385f1390ba644b4e"
     },
     {
       "id": "role:project-manager",
       "kind": "role",
       "name": "Project Manager",
-      "description": "Compare one working-unit page with its project-type playbook and identify the single most useful next project-management action. Or, across the chosen notebook, say what is due and what is overdue.",
+      "description": "Compare one working-unit page with its project-type playbook and find what is overdue, contradictory or missing. Or, across the chosen notebook, say what is due and what is overdue.",
       "file": ".artist/roles/PROJECT_MANAGER.md",
-      "sha256": "f2c3d4a767b97d8f33f778257d23adcb61ac737ffdf58265cb84d16dbcdc01c9"
+      "sha256": "f670aedf05d120c6518db692e668ede235d6ab5cc4b84e773d969f20fe5e7782"
     },
     {
       "id": "role:registrar",

package/dist/api.d.ts

@@ -122,6 +122,15 @@ export declare const calendarInsertEvent: (calendarId: string, body: unknown, to
  * only an event this tool created can be removed.
  */
 export declare const calendarDeleteEvent: (calendarId: string, eventId: string, token: string) => Promise<void>;
+/**
+ * Change one event in place. The only PATCH to Google, added by 0013.
+ *
+ * `If-Match` carries the etag the confirmation was made against, so an event
+ * that changed after the preview is refused by Google (412) rather than
+ * overwritten. Not retried, like every write here. sendUpdates=none: nobody is
+ * emailed. See docs/decisions/0013-editing-any-calendar-event.md.
+ */
+export declare const calendarPatchEvent: (calendarId: string, eventId: string, body: Record<string, unknown>, etag: string, token: string) => Promise<Response>;
 export declare const CALENDAR_LIST_NEED: ScopeNeed;
 /**
  * Create one page in one OneNote section.
@@ -135,7 +144,17 @@ export declare const CALENDAR_LIST_NEED: ScopeNeed;
  *
  * See docs/decisions/0003-onenote-writes.md.
  */
-export declare const onenoteCreatePage: (sectionId: string, xhtml: string, token: string) => Promise<Response>;
+export declare const onenoteCreatePage: (sectionId: string, xhtml: string, token: string, 
+/**
+ * Images the page refers to as `name:<name>`. With any, the page goes as
+ * multipart: the document is the part named `Presentation`, and each image
+ * is a part of its own. See docs/decisions/0012-images-on-a-new-page.md.
+ */
+parts?: {
+    name: string;
+    media_type: string;
+    bytes: Uint8Array;
+}[]) => Promise<Response>;
 /**
  * Read a page back with the ids a patch can aim at.
  *
@@ -153,6 +172,14 @@ export declare const onenotePageContent: (pageId: string, token: string) => Prom
     html: string;
     etag: string | null;
 }>;
+/**
+ * Create one section in a notebook.
+ *
+ * Narrow like `onenoteCreatePage`: one notebook id, one name, one POST, and no
+ * retry, because a 5xx does not say whether the section landed and a second
+ * attempt would make a second section. See docs/decisions/0011-creating-sections.md.
+ */
+export declare const onenoteCreateSection: (notebookId: string, displayName: string, token: string) => Promise<Response>;
 /**
  * Apply patch commands to one page.
  *

package/dist/api.js

@@ -415,8 +415,9 @@ export const calendarInsertEvent = async (calendarId, body, token) => {
  * only an event this tool created can be removed.
  */
 export const calendarDeleteEvent = async (calendarId, eventId, token) => {
+    // sendUpdates=none: nobody is emailed. Sending messages stays out (0013).
     const url = `${CALENDAR}/calendars/${encodeURIComponent(calendarId)}` +
-        `/events/${encodeURIComponent(eventId)}`;
+        `/events/${encodeURIComponent(eventId)}?sendUpdates=none`;
     const res = await fetch(url, {
         method: 'DELETE',
         headers: { authorization: `Bearer ${token}` },
@@ -436,6 +437,39 @@ export const calendarDeleteEvent = async (calendarId, eventId, token) => {
     }
     throw new GraphError(`Google Calendar refused to delete the event (${res.status}). ${detail}`, false);
 };
+/**
+ * Change one event in place. The only PATCH to Google, added by 0013.
+ *
+ * `If-Match` carries the etag the confirmation was made against, so an event
+ * that changed after the preview is refused by Google (412) rather than
+ * overwritten. Not retried, like every write here. sendUpdates=none: nobody is
+ * emailed. See docs/decisions/0013-editing-any-calendar-event.md.
+ */
+export const calendarPatchEvent = async (calendarId, eventId, body, etag, token) => {
+    const url = `${CALENDAR}/calendars/${encodeURIComponent(calendarId)}` +
+        `/events/${encodeURIComponent(eventId)}?sendUpdates=none`;
+    const res = await fetch(url, {
+        method: 'PATCH',
+        headers: {
+            authorization: `Bearer ${token}`,
+            'content-type': 'application/json',
+            'if-match': etag,
+        },
+        body: JSON.stringify(body),
+    });
+    if (res.ok)
+        return res;
+    const detail = (await res.text().catch(() => '')).slice(0, 300);
+    if (res.status === 403 && /insufficient|ACCESS_TOKEN_SCOPE/i.test(detail)) {
+        throw new ScopeError('This Google connection cannot change calendar events. Reconnect with ' +
+            '`artist-mcp connect google` to grant it.', 'change calendar events', false);
+    }
+    if (res.status === 412) {
+        throw new GraphError('The event changed after it was shown to you, so nothing was written. Ask ' +
+            'for the change again to see it as it is now.', false);
+    }
+    throw new GraphError(`Google Calendar refused to change the event (${res.status}). ${detail}`, false);
+};
 export const CALENDAR_LIST_NEED = {
     capability: 'see which calendars you have',
     optional: true,
@@ -452,18 +486,32 @@ export const CALENDAR_LIST_NEED = {
  *
  * See docs/decisions/0003-onenote-writes.md.
  */
-export const onenoteCreatePage = async (sectionId, xhtml, token) => {
+export const onenoteCreatePage = async (sectionId, xhtml, token, 
+/**
+ * Images the page refers to as `name:<name>`. With any, the page goes as
+ * multipart: the document is the part named `Presentation`, and each image
+ * is a part of its own. See docs/decisions/0012-images-on-a-new-page.md.
+ */
+parts = []) => {
     const url = `${GRAPH}/me/onenote/sections/${encodeURIComponent(sectionId)}/pages`;
-    const res = await fetch(url, {
-        method: 'POST',
-        headers: {
-            authorization: `Bearer ${token}`,
-            // Not application/json. OneNote takes the page as an XHTML document, and
-            // sending JSON is answered with a 400 that names neither problem.
-            'content-type': 'application/xhtml+xml',
-        },
-        body: xhtml,
-    });
+    let body = xhtml;
+    // Not application/json. OneNote takes the page as an XHTML document, and
+    // sending JSON is answered with a 400 that names neither problem.
+    const headers = {
+        authorization: `Bearer ${token}`,
+        'content-type': 'application/xhtml+xml',
+    };
+    if (parts.length > 0) {
+        const form = new FormData();
+        form.append('Presentation', new Blob([xhtml], { type: 'text/html' }));
+        for (const part of parts) {
+            form.append(part.name, new Blob([new Uint8Array(part.bytes)], { type: part.media_type }));
+        }
+        body = form;
+        // fetch writes the multipart content-type itself, with the boundary in it.
+        delete headers['content-type'];
+    }
+    const res = await fetch(url, { method: 'POST', headers, body });
     // Not retried, exactly as the calendar insert is not: a repeated create makes
     // a second page, and a 5xx does not say whether the first one landed. OneNote
     // accepts no client-set id, so there is no collision to rely on either — which
@@ -501,6 +549,29 @@ export const onenotePageContent = async (pageId, token) => {
     const res = await graphGet(`/me/onenote/pages/${encodeURIComponent(pageId)}/content?includeIDs=true`, token);
     return { html: await res.text(), etag: res.headers.get('etag') };
 };
+/**
+ * Create one section in a notebook.
+ *
+ * Narrow like `onenoteCreatePage`: one notebook id, one name, one POST, and no
+ * retry, because a 5xx does not say whether the section landed and a second
+ * attempt would make a second section. See docs/decisions/0011-creating-sections.md.
+ */
+export const onenoteCreateSection = async (notebookId, displayName, token) => {
+    const url = `${GRAPH}/me/onenote/notebooks/${encodeURIComponent(notebookId)}/sections`;
+    const res = await fetch(url, {
+        method: 'POST',
+        headers: { authorization: `Bearer ${token}`, 'content-type': 'application/json' },
+        body: JSON.stringify({ displayName }),
+    });
+    if (res.ok)
+        return res;
+    const detail = (await res.text().catch(() => '')).slice(0, 300);
+    if ((res.status === 401 || res.status === 403) && /40004|scope/i.test(detail)) {
+        throw new ScopeError('This Microsoft connection cannot create OneNote sections. Reconnect with ' +
+            '`artist-mcp connect microsoft`.', 'create OneNote sections', false);
+    }
+    throw new GraphError(`OneNote refused to create the section (${res.status}). ${detail}`, false);
+};
 /**
  * Apply patch commands to one page.
  *