@agent-native/core 0.141.7 → 0.144.0

package/corpus/templates/calendar/.agents/skills/turn-into-app/SKILL.md

@@ -0,0 +1,296 @@
+---
+name: turn-into-app
+description: >-
+  Turn a proven thread, skill, or workflow into a runnable Agent-Native app
+  with simple buttons, visible agent steps, preview, and deployment handoff.
+  Use when a user invokes `/turn-into-app` or asks to make a workflow into an
+  app.
+user-invocable: true
+scope: both
+metadata:
+  internal: true
+---
+
+# Turn Into App
+
+## Default behavior
+
+This is an end-to-end build skill, not a request for an app proposal.
+
+- With no argument, use the current thread as the source. This is the normal
+  invocation at the end of a successful workflow.
+- With a named skill or local workflow, read that source and package it
+  immediately, even at the beginning of a thread. For example,
+  `/turn-into-app /some-skill` means “turn `/some-skill` into an app.”
+- With an attachment or path, read the supplied artifact as the source.
+- Do not ask the user to restate context that is already in the thread.
+- When invoked from an Agent-Native app, keep the current thread as the source
+  and use the available workspace/coding-agent handoff when the current runtime
+  cannot edit files. Do not claim the app exists without an actual path and
+  verification result.
+
+## Source support
+
+Supported source paths today are the current Codex thread, a named skill, or a
+local workflow/transcript supplied as a path or attachment. An exported
+ChatGPT or Claude transcript can use the same local-file path today.
+
+ChatGPT shared-conversation import and Claude web conversation/project import
+are **coming soon**. Do not claim private web access, invent an importer, add
+fake OAuth, or scrape a logged-in page without an explicit supported adapter.
+If a user gives one of those URLs before an adapter exists, ask for an export or
+transcript instead and treat it as imported source material.
+
+Deliver a fresh app in a new directory, implement the repeatable workflow with
+buttons and agent handoffs, start its dev server, verify the main path, and
+continue through build/deployment handoff. Do not stop at a plan.
+
+## Source selection guard
+
+The generated app must implement the concrete workflow found in the source. It
+must not become a generic “what app do you want to make?” intake form.
+
+- In a delegated or forked task, read the actual referenced source thread and
+  the latest explicit workflow direction in the current task. If they disagree,
+  the latest concrete workflow direction wins.
+- Do not treat a thread that merely discusses building this skill as the product
+  source unless the user explicitly asks to appify that meta-workflow.
+- If the source contains several workflows, choose the latest successful,
+  repeatable job that motivated the request and name it in the handoff. If no
+  concrete job can be identified, stop and report what is missing instead of
+  inventing an app-builder UI.
+
+## UI contract for generated apps
+
+Generated apps must follow the shared Agent-Native surface model:
+
+- Keep the domain workflow on a named route (`/workflow`, `/automations`,
+  `/block`, or the source's equivalent). Preserve the scaffold's full-page
+  chat route instead of replacing it with a domain form while leaving the
+  layout configured as a chat page.
+- Use the right `AgentSidebar` for contextual AI. Every button-triggered
+  `sendToAgentChat` handoff should open or focus that sidebar and keep the user
+  on the current domain page.
+- Use a sans-first SaaS hierarchy for the app shell. Choose a named visual
+  direction in `DESIGN.md` before styling: product mode, audience, palette
+  family, type treatment, composition, shape language, and anti-references.
+  One restrained editorial cue is welcome, but warm beige plus terracotta is
+  not the default and serif type belongs in content previews or a deliberate
+  brand moment rather than the whole tool.
+- Preserve existing brand tokens. For a new unbranded app, choose a
+  product-fitting palette family and compare sibling apps before reusing their
+  accent. Keep shared semantic tokens and Agent-Native behavior consistent
+  while varying the visual world, density, composition, and shape language.
+- Give the AgentSidebar a subtle surface or divider boundary so it is visually
+  distinct from the domain page without becoming a heavy panel wall.
+- Every AI-labeled button must actually call `sendToAgentChat` with bounded
+  context and `openSidebar: true`. Keep `submit: true` for direct execution and
+  `submit: false` only when the user should edit the staged prompt first. Label
+  deterministic local actions as local, preview, or analyze instead of AI.
+- Standalone apps that render `AgentSidebar` must keep one assistant-ui runtime
+  context. Pin the versions compatible with the installed core/toolkit peer
+  graph, and add Vite dedupe/aliases when linked or transitive packages resolve
+  duplicate assistant-ui modules. Verify a fresh AI handoff has no
+  `AssistantUiStaleIndexErrorBoundary` or stale-index console error.
+- Make the left navigation describe domain destinations. Chat is a separate
+  destination, not the label for every app page.
+- Start with one primary action and one compact state. Put setup choices,
+  advanced inputs, diagnostics, and long explanations behind progressive
+  disclosure or later workflow steps.
+- Never use sparkle, wand, magic, robot, or similar decorative AI icons. Use a
+  message or neutral action icon, or no icon when the button label is enough.
+- Before handoff, inspect the first viewport for text density, repeated cards,
+  unrelated forms, and generic helper copy. Remove what the user does not need
+  until the next decision.
+- Run a `distill`, `typeset`, `colorize`, `layout`, `polish`, and `audit` pass
+  as useful named reviews. Make one intervention at a time and commit the
+  chosen direction rather than averaging several options into generic SaaS.
+- For before/after or original/generated review, stack the source first and the
+  result second by default. Reserve side-by-side layouts for short content that
+  remains comfortable to scan at the target width.
+
+## 1. Extract the workflow
+
+Read the full available source before coding. Reduce it to a short working
+brief:
+
+- the user and repeatable job;
+- inputs and outputs;
+- the 1-3 judgment-heavy agent moments;
+- the buttons, review points, and retry states a user needs;
+- data, permissions, integrations, and failure boundaries.
+
+Preserve useful judgment from the source, but do not turn a one-off answer,
+private data, or an unverified result into a product contract. If the source is
+not available or does not contain a repeatable job, say what is missing rather
+than claiming the app is complete.
+
+## 2. Create a fresh app
+
+Choose a short slug from the workflow and create a new directory. Never
+overwrite an existing app. If the user supplied a directory, use it; otherwise
+use `apps/<slug>` inside an existing Agent-Native workspace, or a new sibling
+directory when working outside one.
+
+For a new UI-bearing standalone app, use the current Agent-Native scaffold and
+then read the generated `AGENTS.md`:
+
+```bash
+npx @agent-native/core@latest create <app-directory> --template chat
+cd <app-directory>
+pnpm install
+```
+
+When working inside an existing Agent-Native workspace, create the app from
+the workspace root instead:
+
+```bash
+pnpm exec agent-native add-app <slug> --template=chat
+```
+
+Do not use `create` for an existing workspace; it scaffolds a new standalone
+workspace rather than adding an app to the current one.
+
+Use a first-party template only when it materially fits the workflow. Keep the
+new app independent from the source thread's working tree unless the user
+explicitly asks to extend an existing app.
+
+Read the generated `DESIGN.md` before building the first screen and fill in the
+visual direction as part of the app brief. Do not copy the previous app's
+palette just because its tokens are nearby.
+
+## 3. Turn the workflow into buttons and agent work
+
+Implement the smallest useful surface around the extracted brief. The app
+should make the repeated path obvious without hiding the agent's judgment:
+
+- Give each important repeated moment a clear button, such as “Analyze,”
+  “Suggest options,” “Draft,” “Review,” or “Publish.” Use the source's actual
+  vocabulary when it is clear.
+- Put deterministic reads, writes, approvals, and publishing in `actions/`
+  with `defineAction`. The UI and agent must call the same action surface.
+- Use application state for the current screen, selected item, and focused
+  object so the agent can see where the user is.
+- Use `sendToAgentChat({ message, context, submit: true })` for intentional
+  button-triggered agent work. Use `submit: false` when the user should review
+  or edit the proposed prompt first.
+- Pass IDs, URLs, and bounded summaries in context. Do not paste large provider
+  dumps into prompts, call an LLM directly from the browser, or invent fake
+  progress.
+- Make agent results visible, editable, retryable, and attributable. Keep
+  irreversible actions behind an explicit review or confirmation point.
+
+Use the existing shadcn/ui primitives, Tabler icons, shared composer, and
+optimistic action patterns. Do not add a parallel CRUD API route for an action.
+
+## 4. Keep onboarding shared
+
+Use the framework's existing setup experience. The app should offer the normal
+“Connect Builder” and “Add your own keys” paths for AI setup. Do not create a
+second credential form or hardcode a provider key.
+
+In local-development instructions, add a brief note that a developer can set
+an environment variable such as `ANTHROPIC_API_KEY` or `OPENAI_API_KEY` before
+starting the app; after restart, the setup prompt is no longer shown when the
+key is available. Keep real secrets out of source, examples, and generated
+content.
+
+Turn-into-app apps should commit an `agent-native.json` app configuration so a
+plain `pnpm dev` has the right first-run behavior without extra flags:
+
+```json
+{
+  "version": 1,
+  "onboarding": {
+    "firstRun": {
+      "development": "connect",
+      "production": "connect-and-integrations"
+    }
+  }
+}
+```
+
+`connect` keeps the Connect Builder / Add your own keys choice visible and
+skips only the generic “This app is an agent.” integrations catalog. The
+production value includes that catalog for a hosted app. Do not replace this
+with a local credential form or remove the shared onboarding. In development,
+the shared Connect Builder card also explains the deployment-level
+`ANTHROPIC_API_KEY` / `OPENAI_API_KEY` fallback and links to the full
+environment-variable guide.
+
+When the onboarding default needs code rather than a static mode map, add an
+optional `agent-native.config.ts` with the same returned shape:
+
+```ts
+import { defineAgentNativeConfig } from "@agent-native/core/config";
+
+export default defineAgentNativeConfig(({ isDev }) => ({
+  version: 1,
+  onboarding: {
+    firstRun: isDev ? "connect" : "connect-and-integrations",
+  },
+}));
+```
+
+The Vite preset loads this file automatically on supported Node versions. The
+JSON file remains the portable, inspectable fallback. See the [Agent-Native
+app configuration guide](/docs/agent-native-config) for precedence, supported
+modes, and the boundary between committed config and deployment secrets.
+
+For an account-free local preview, create the ignored local `.env` file with
+`AUTH_DISABLED=1` before starting the dev server. This is only for loopback
+development; never commit or deploy this setting. AI/provider connections still
+use the normal onboarding flow or the documented environment-variable keys.
+
+## 5. Run it immediately
+
+From the new app directory:
+
+```bash
+pnpm dev
+```
+
+For a fresh local test app, use the ignored `.env` with `AUTH_DISABLED=1` so the
+domain UI opens without an account; the committed app config makes shared
+onboarding visible. Keep the process running so the user can try the app. Read
+the actual server output and report the real local URL. If the app needs installation or a setup step,
+complete it when possible and distinguish “not configured” from an unavailable
+credential store.
+
+## 6. Verify, build, and deploy
+
+Exercise the actual happy path, not only the source files:
+
+1. Load the reported URL and confirm the main route renders.
+2. Confirm the shared onboarding state or a configured local key.
+3. Click the primary workflow button and confirm the intended agent handoff.
+   Also click every other AI-labeled button and confirm it opens the same
+   contextual sidebar with the expected prompt or staged context.
+4. Confirm the result, action persistence, application state, and sync path.
+5. Check the dev output for browser/runtime errors, and capture input, result,
+   and agent-sidebar states so the complete flow is reviewable.
+
+Then run the supported build. For a standalone app, use the generated app's
+documented build and hosting path. For an app inside a workspace, use the
+workspace deploy command, for example:
+
+```bash
+npx @agent-native/core@latest build
+npx @agent-native/core@latest deploy --preset netlify
+```
+
+Use `vercel` or another supported preset when that is the configured target.
+Attempt deployment when the user requested it or the project already has the
+required provider configuration. If external authentication, a production
+secret, or a hosting decision is missing, finish local verification and report
+the exact remaining handoff without claiming a live deployment.
+
+Label evidence separately: locally running, locally verified, build-ready,
+deployed, and live-verified are different states.
+
+## Handoff
+
+End with the new app directory, local URL, visual direction, what the buttons do,
+account-free local-preview status, verification performed, deployment URL if it is real,
+and one precise pending step when something could not be completed. Keep the
+handoff short enough to use in a demo or recording.

package/corpus/templates/calendar/.agents/skills/turn-into-app/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Turn Into App"
+  short_description: "Turn a thread or skill into a runnable app"
+  default_prompt: "Scan the current thread, turn the workflow into a new Agent-Native app with clear buttons, run it locally, verify it, and complete the deployment handoff."

package/corpus/templates/calendar/.agents/skills/turn-into-skill/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: turn-into-skill
+description: >-
+  Capture a proven thread or workflow as a reusable Agent-Native skill and save
+  it as a personal or organization resource. Use when a user invokes
+  `/turn-into-skill` or asks to save a workflow for reuse.
+user-invocable: true
+scope: both
+metadata:
+  internal: true
+---
+
+# Turn Into Skill
+
+This is a packaging-and-save workflow, not a request for a proposal. A skill
+is the lightweight path for a repeatable job that mostly needs guidance and
+existing app actions. Use `turn-into-app` when the job needs a dedicated UI,
+new persistent domain state, or a distinct app route.
+
+## Default behavior
+
+- With no argument, use the current thread as the source.
+- With a named skill, local workflow, transcript path, or attachment, read that
+  source and package it immediately.
+- Do not ask the user to restate context already present in the source.
+- Default to a personal skill unless the user explicitly asks for a team,
+  organization, or all-app skill, or passes `shared` as the scope.
+- If the current thread only discusses creating a skill, do not package that
+  meta-workflow unless the user explicitly asks for it.
+- Treat an explicit `/turn-into-skill` invocation as authorization to save the
+  resulting skill, but never overwrite an existing skill at the target path
+  unless the user clearly asks to update it.
+
+## 1. Extract the repeatable workflow
+
+Read the full source before writing. Reduce it to a concise working brief:
+
+- the repeatable job and the user outcome;
+- when the skill should trigger;
+- required inputs, context, permissions, and integrations;
+- the ordered steps and the one to three judgment-heavy decisions;
+- expected outputs, verification, retry, and failure boundaries.
+
+Preserve the useful judgment from the source, not its transcript. Do not turn
+one-off answers, private data, customer data, secrets, or unverified claims into
+the skill's contract. If no repeatable job can be identified, stop and report
+what is missing instead of inventing generic guidance.
+
+## 2. Author the skill
+
+Create a single `SKILL.md` with:
+
+- a short hyphen-case name and a description under 40 words that says what the
+  skill does and when to use it;
+- `user-invocable: true` so it can be selected from the app's `/` picker;
+- `scope: both` so the saved skill can guide the app runtime and connected
+  coding agents;
+- concise sections for purpose, trigger, inputs, workflow, verification, and
+  failure or retry behavior.
+
+Write imperative, reusable instructions. Keep exact action names, field rules,
+and decision criteria when they matter. Use placeholders for credentials and
+provider data. Do not paste the source transcript, large dumps, or ephemeral
+thread details into the saved skill.
+
+Choose a new slug when the target path already exists. Read an existing skill
+before changing it, and update it only when the user explicitly requested an
+update.
+
+## 3. Save at the requested scope
+
+Skills are resources at `skills/<slug>/SKILL.md`.
+
+| User intent | Save path |
+| --- | --- |
+| Just me or personal reuse | Use the `resources` tool with `action: "write"`, `scope: "personal"`, `visibility: "workspace"`, and the generated skill content. |
+| Shared organization or app reuse | Use the `resources` tool with `action: "write"`, `scope: "shared"`, `visibility: "workspace"`, and the generated skill content. |
+| Every workspace app | Use `create-workspace-resource` with `kind: "skill"`, `scope: "all"`, the generated path, name, description, and content. |
+| Only selected apps | Use the workspace resource flow with `scope: "selected"` only when the user names the app set. |
+
+For an all-app workspace skill, use the workspace resource action when it is
+available. If the current app does not expose it, discover or delegate to the
+configured Dispatch workspace agent. Do not silently save a personal skill and
+report it as shared. If organization approval is queued, report that the skill
+is pending approval rather than claiming it is active.
+
+Set `visibility: "workspace"` for an explicitly requested saved skill. Use
+`agent_scratch` only for temporary drafting, then promote or rewrite it before
+reporting the skill as saved.
+
+## 4. Verify and hand off
+
+After saving, read the exact `skills/<slug>/SKILL.md` resource back at the
+target scope. Confirm that the frontmatter name, trigger description, and full
+workflow body are present. If the read-back fails or the save returned an
+approval request, say so plainly and include the actual pending state.
+
+Report:
+
+- the skill name and path;
+- whether it is personal, organization-wide, or selected-app;
+- the trigger users can invoke from `/`;
+- the verification result and any approval or setup still required.
+
+## Related skills
+
+- `turn-into-app` — package the same source as a UI-bearing app with buttons,
+  agent handoffs, and a domain workflow.
+- `create-skill` — general skill format and authoring rules.
+- `capture-learnings` — lightweight memory for preferences and corrections,
+  rather than reusable workflows.
+- `self-modifying-code` — safety boundaries when the agent edits app source.

package/corpus/templates/calendar/.agents/skills/turn-into-skill/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Turn Into Skill"
+  short_description: "Save a proven workflow as a reusable skill"
+  default_prompt: "Read the current thread, distill the repeatable workflow into a concise user-invocable skill, save it at personal or organization scope, verify the saved resource, and report its path."

package/corpus/templates/calendar/AGENTS.md

@@ -44,10 +44,8 @@ ladder.
   version matters, use `provider-api-catalog`, `provider-api-docs`, and
   `provider-api-request` against the real provider API instead of weakening the
   answer around a narrow action.
-- For relationship-history searches, prefer raw Google Calendar API calls via
-  `provider-api-request` so the agent controls `calendarId`, `timeMin`,
-  `timeMax`, `q`, `maxResults`, and pagination. For large scans, stage results
-  with `stageAs` and analyze them with `query-staged-dataset`.
+- For relationship-history searches, use `provider-api-request`; stage large
+  scans with `stageAs` and analyze them with `query-staged-dataset`.
 - For Google Calendar, distinguish an empty calendar from missing auth,
   reauth-needed, or fetch failures.
 - `list-events` returns the UI-compatible list by default and the compact
@@ -55,35 +53,14 @@ ladder.
   `sourceCoverage`, and `coverageComplete` fields — a partial source failure is
   not an empty calendar. See `event-management` for the formats and the
   `accountEmails` rules.
-- Treat Google Calendar working locations as native status events, never as
-  generic all-day events. See `event-management` for
-  `workingLocationProperties`, single-occurrence scope, and the working-hours
-  limitation.
-- Full-day out-of-office creation uses inclusive human dates plus an IANA
-  timezone. `create-event` translates them to local-midnight timed bounds and
-  sends provider `allDay: false`; do not expose Google's timed-only constraint
-  as a required pair of time inputs in the UI. See `event-management` for the
-  action contract and decline behavior.
-- Use framework sharing actions for calendars/events/booking resources when
-  applicable.
-- Booking-link sharing controls who can manage the link. Public booking access
-  is still controlled by the `/book/{username}/{slug}` URL and `isActive`.
-- `create-booking-link` and `update-booking-link` accept `hosts` for required
-  co-hosts besides the owner, e.g. `hosts: ["brent@example.com"]`. Group links
-  only offer times when the owner and all co-hosts are free, then invite
-  co-hosts to the created Google Calendar event.
+- Treat Google Calendar working locations and full-day out-of-office events as
+  native status events; see `event-management` for their action contracts.
+- Use framework sharing actions for calendar, event, and booking resources;
+  see `availability-booking` for booking-link controls and co-hosts.
 - Keep scheduling answers concrete: exact dates, time zones, conflicts, and
   assumptions.
-- Event detail (panel and popover) exposes `calendar.event-detail.bottom` as an
-  `ExtensionSlot`. Extensions render as widgets there with `slotContext`
-  (eventId, title, start/end, timezones, location, attendees, accountEmail).
-  For inline adornments next to each guest email (e.g. local times), prefer the
-  first-party attendee timezone UI / `set-attendee-timezone` settings, or a
-  source edit — do not claim the slot can inject per-row UI.
-- Use `rsvp-event` for invitation responses, and `update-event` with
-  `addAttendees` (not a replacement `attendees` list) when inviting more people.
-  See `event-management` for RSVP notes, optional guests, recurring guest scope,
-  and `get-attendee-timezones` / `set-attendee-timezone` overrides.
+- Event detail extensions, attendee adornments, RSVP scope, and multi-account
+  updates are documented in `event-management`; follow that skill before edits.
 
 ## Application State
 
@@ -95,4 +72,6 @@ ladder.
 - Preserve `accountEmail` on every Google event write. When more than one
   Google account is connected, pass the chosen account to `create-event`, and
   pass the event's returned `accountEmail` to `update-event`, `delete-event`,
-  and `rsvp-event`. These actions target that account's primary calendar.
+  and `rsvp-event`. These actions target that account's primary calendar. For a
+  move, pass the original account as `accountEmail` and the destination as
+  `targetAccountEmail` to `update-event`.

package/corpus/templates/calendar/actions/update-event.ts

@@ -79,7 +79,7 @@ function workingLocationTitle(
 
 export default defineAction({
   description:
-    "Update a Google Calendar event. Supports title, description, location, time, event color, attachments, reminders, and recurrence rules such as RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR.",
+    "Update a Google Calendar event. Supports moving an existing event between connected Google account calendars, as well as title, description, location, time, event color, attachments, reminders, and recurrence rules such as RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR.",
   schema: z.object({
     id: z
       .string()
@@ -90,6 +90,12 @@ export default defineAction({
       .describe(
         "Connected Google account email from list-events/search-events",
       ),
+    targetAccountEmail: z
+      .string()
+      .optional()
+      .describe(
+        "Move this event to another connected Google account's primary calendar. Pass accountEmail as the current event account. Moving creates the event on the destination and removes it from the source.",
+      ),
     title: z.string().optional().describe("New event title"),
     description: z.string().optional().describe("New event description"),
     location: z.string().optional().describe("New event location"),
@@ -205,6 +211,11 @@ export default defineAction({
       args.accountEmail,
       ownerEmail,
     );
+    const targetAccountEmail =
+      args.targetAccountEmail !== undefined
+        ? await resolveOwnedAccountEmail(args.targetAccountEmail, ownerEmail)
+        : undefined;
+    const hasAccountMove = targetAccountEmail !== undefined;
     const recurrence = normalizeRecurrence(args.recurrence);
     const guestNotificationMessage = normalizeGuestNotificationMessage(
       args.notificationMessage,
@@ -227,6 +238,7 @@ export default defineAction({
     let attendees = normalizeAttendees(args.attendees);
 
     const hasPatch =
+      hasAccountMove ||
       args.title !== undefined ||
       args.description !== undefined ||
       args.location !== undefined ||
@@ -283,6 +295,100 @@ export default defineAction({
       return existingEvent;
     };
 
+    if (hasAccountMove) {
+      if (
+        targetAccountEmail!.trim().toLowerCase() ===
+        accountEmail.trim().toLowerCase()
+      ) {
+        throw new Error(
+          "The destination calendar must be different from the current calendar.",
+        );
+      }
+      if (args.scope === "all") {
+        throw new Error(
+          "Move a recurring event occurrence with scope single; moving an entire recurring series is not supported.",
+        );
+      }
+
+      const existingEvent = await loadExistingEvent();
+      const hasOtherEventPatch =
+        args.title !== undefined ||
+        args.description !== undefined ||
+        args.location !== undefined ||
+        args.start !== undefined ||
+        args.end !== undefined ||
+        args.startTimeZone !== undefined ||
+        args.endTimeZone !== undefined ||
+        args.allDay !== undefined ||
+        args.transparency !== undefined ||
+        args.visibility !== undefined ||
+        args.status !== undefined ||
+        args.remindersUseDefault !== undefined ||
+        args.reminders !== undefined ||
+        args.attachments !== undefined ||
+        args.colorId !== undefined ||
+        args.reminderMinutes !== undefined ||
+        args.reminderMethod !== undefined ||
+        args.addGoogleMeet !== undefined ||
+        args.addZoom !== undefined ||
+        args.recurrence !== undefined ||
+        args.attendees !== undefined ||
+        args.addAttendees !== undefined ||
+        args.workingLocationType !== undefined ||
+        args.workingLocationLabel !== undefined;
+      if (hasOtherEventPatch) {
+        throw new Error(
+          "Move the event separately from other event field changes.",
+        );
+      }
+
+      const sendUpdates =
+        args.sendUpdates ??
+        (existingEvent.attendees?.some((attendee) => !attendee.self)
+          ? "all"
+          : "none");
+      const result = await googleCalendar.moveEvent(googleEventId, {
+        sourceAccount: { ownerEmail, accountEmail },
+        destinationAccount: {
+          ownerEmail,
+          accountEmail: targetAccountEmail!,
+        },
+        sendUpdates,
+      });
+      if (!result.id) {
+        throw new Error("Google did not return an id for the moved event.");
+      }
+
+      const guestNotification = guestNotificationMessage
+        ? await sendEventGuestNotificationNote({
+            event: {
+              ...existingEvent,
+              id: `google-${result.id}`,
+              googleEventId: result.id,
+              accountEmail: targetAccountEmail,
+              htmlLink: result.htmlLink,
+              hangoutLink: result.meetLink,
+              conferenceData: result.conferenceData,
+            },
+            organizerEmail: ownerEmail,
+            message: guestNotificationMessage,
+            kind: "update",
+          })
+        : undefined;
+
+      return {
+        success: true,
+        id: `google-${result.id}`,
+        replacedId: `google-${googleEventId}`,
+        accountEmail: targetAccountEmail,
+        updated: ["accountEmail"],
+        htmlLink: result.htmlLink,
+        hangoutLink: result.meetLink,
+        conferenceData: result.conferenceData,
+        ...(guestNotification ? { guestNotification } : {}),
+      };
+    }
+
     if (args.location !== undefined && !hasWorkingLocationPatch) {
       const existingEvent = await loadExistingEvent();
       if (existingEvent.eventType === "workingLocation") {