frontpage-host 0.3.16 → 0.3.17

package/AGENTS.md

@@ -282,7 +282,7 @@ AI Support Agent team guidance: administrators may set `guidanceEmail` through t
 
 ## Emails workspace workflows
 
-Campaign timing uses the existing `mail save --file` and `mail campaign preview|send|get` commands. Read [MAIL.md, Campaign scheduling](./MAIL.md#campaign-scheduling) before using it. Save document.scheduledAt as a future ISO timestamp with an explicit timezone, null for Send now, or omit to retain it. Saving never confirms sending; overdue drafts remain drafts. Read settings for the business timezone. Review the post-save content timestamp, exact audience, eligible count and saved schedule before campaign send with a stable requestKey. Confirmed groups/filters resolve once, and normal delivery restrictions remain. The owner agent uses save_mail_editor then manage_people area:campaign; MCP uses save_mail_editor and campaign.preview/send/get. Direct saved-email sends cannot bypass a dated campaign. Reuse exact requests after uncertain responses.
+Campaign timing uses the existing `mail save --file` and `mail campaign preview|send|get|unschedule|reschedule` commands. Read [MAIL.md, Campaign scheduling](./MAIL.md#campaign-scheduling) before using it. Save document.scheduledAt as a future ISO timestamp with an explicit timezone, null for Send now, or omit to retain it. Saving never confirms sending; overdue drafts remain drafts. Use document.scheduleLocal:{dateTime,timeZone} for local YYYY-MM-DDTHH:mm plus IANA timezone; the server converts it. ISO scheduledAt remains supported. Do not supply both. Review the post-save content timestamp, exact audience, eligible count and saved schedule before campaign send with a stable requestKey. Confirmed groups/filters resolve once, and normal delivery restrictions remain. The owner agent uses save_mail_editor then manage_people area:campaign; MCP uses save_mail_editor and campaign.preview/send/get. Direct saved-email sends cannot bypass a dated campaign. Reuse exact requests after uncertain responses. Before queueing, unschedule cancels a scheduled email to Draft, keeping its email/audience; reschedule changes only time and retains confirmed recipients/content. Both require documentUpdatedAt from a fresh get and a stable requestKey. Reschedule accepts scheduleLocal or scheduledAt. Read MAIL.md for examples.
 
 See [MAIL.md](./MAIL.md) for the complete save contract, reusable people picker directory, saved campaign recipients, Off-series enrollment and resume timing, all sender settings/null resets, suppression rules, Sent queries and details, and retry-safe examples. `frontpage mail save --file save.json` saves template and pending series together; it never sends. New series default On; existing series retain their saved state. Save email steps before enrolling anyone. Check the returned series status before attaching it to a rule; an Off series holds enrollment until turned On. `frontpage mail people` reads the same site-scoped directory as the workspace. Use `frontpage help mail --json` for current commands and flags. No new CLI binary, API namespace or migration command is required. Hosted guides and article help must be updated through the Frontpage CLI.
 

package/MAIL.md

@@ -111,13 +111,15 @@ The workspace, CLI, owner agent and MCP use the same saved campaign and confirma
 | Save draft, audience and timing | `mail save --file draft.json` | `save_mail_editor` | `frontpage_mail_write`, operation `save_mail_editor` |
 | Review audience | `mail campaign preview --file audience.json` | `manage_people`, area `campaign`, operation `preview` | `frontpage_mail_read`, operation `campaign.preview` |
 | Confirm sending or scheduling | `mail campaign send --id ID --file review.json --request-key KEY` | `manage_people`, area `campaign`, operation `send` | `frontpage_mail_write`, operation `campaign.send` |
+| Cancel a scheduled email | `mail campaign unschedule --id ID --file cancel.json --request-key KEY` | `manage_people`, area `campaign`, operation `unschedule` | `frontpage_mail_write`, operation `campaign.unschedule` |
+| Change a confirmed time | `mail campaign reschedule --id ID --file time.json --request-key KEY` | `manage_people`, area `campaign`, operation `reschedule` | `frontpage_mail_write`, operation `campaign.reschedule` |
 | Read saved audience, timing and status | `mail campaign get --id ID --json` | `manage_people`, area `campaign`, operation `get` | `frontpage_mail_read`, operation `campaign.get` |
 
 Use `--site YOUR_SITE --json` with each CLI command. Agent calls bind the current site; never supply a siteId. MCP calls take `slug`, `operation` and `payload`, with the same fields inside payload. Existing role, plan, consent and delivery checks apply.
 
 ### Save a schedule without sending
 
-Read the current campaign and `mail settings get` first. Convert the owner's chosen local date and time using the saved IANA timezone. `document.scheduledAt` accepts a future ISO timestamp with `Z` or an explicit offset. Do not guess an offset or silently shift a time that does not exist during daylight-saving changes. Ask for clarification if a repeated local time is ambiguous.
+Read the current campaign first. The workspace uses the viewer's local timezone. Tools can save `document.scheduleLocal:{dateTime:"2030-11-15T09:00",timeZone:"America/Chicago"}`; the server converts local time to UTC. Use an IANA timezone, not a guessed offset. Missing clock-change times are rejected; repeated clock-change times use the earlier occurrence. Ask for the owner's timezone if unknown. Existing `document.scheduledAt` ISO timestamps with `Z` or an explicit offset still work. Supply only one timing input. Omit both to retain timing; scheduledAt:null selects Send now.
 
 - A timestamp selects Schedule for later.
 - `null` selects Send now and clears the saved date. It still does not send.
@@ -175,10 +177,33 @@ frontpage mail campaign get --id CAMPAIGN_DOCUMENT_ID --site YOUR_SITE --json
 
 Copy the canonical UTC scheduledAt from the saved response into review, or null for Send now. Use the exact post-save document timestamp and preview's eligible count; never use a timestamp from before an audience save. The service rejects a changed reviewed audience, count, content timestamp or scheduled time. A past date needs a new future date or Send now before confirmation. Existing older callers without review fields remain supported; agents should always supply the complete review.
 
-Confirmation freezes the eligible recipients and content. Groups and filters resolve at confirmation, not at the future send time. Permission, opt-out and delivery checks still apply before sending. A confirmed future campaign has stored status `pending` and scheduledAt; the UI labels that combination Scheduled. Drafts remain `draft` regardless of date. Queued, sent and delivered are different states; read campaign counts and the send ledger. Confirmed campaigns cannot be edited through this flow; cancellation and rescheduling are not added here.
+Confirmation freezes the eligible recipients and content. Groups and filters resolve at confirmation, not at the future send time. Permission, opt-out and delivery checks still apply before sending. A confirmed future campaign has stored status `pending` and scheduledAt; the UI labels that combination Scheduled. Drafts remain `draft` regardless of date. Queued, sent and delivered are different states; read campaign counts and the send ledger. Before queueing begins, a confirmed schedule can be cancelled or moved as described below. Its content and recipients stay fixed unless cancelled and confirmed again.
 
 Keep the same requestKey and exact payload after an uncertain save or confirmation. Read back campaign state and retry the original request; never create a new send key to recover an uncertain result. A changed request needs a fresh review. The older `mail send email` / `send_mail_email` path sends immediately and cannot confirm a scheduled campaign; it returns a conflict for dated campaigns. Use campaign send instead. Test sends and dry runs do not confirm or start the campaign; existing test restrictions still apply.
 
+### Manage a confirmed schedule
+
+Read `campaign get` immediately before reviewing a change. It returns `documentUpdatedAt` and `canManageSchedule`. **Cancel scheduled email** uses `unschedule`: it changes status to `draft`, clears scheduledAt and the old confirmed snapshot/recipients, and keeps the email and saved audience. Normal editing resumes. Saving that draft never sends it; sending or scheduling again needs a fresh review and explicit confirmation with a new send request key. There is no cancelled campaign state.
+
+`reschedule` changes only time. Show the saved email, recipient count, current time and proposed time, then get the owner's approval. It retains the confirmed recipients/content even if groups have changed. Closing the review makes no change.
+
+Both actions work only while the campaign is confirmed and dated, before its first queue batch. They may still work after the due time if queueing has not begun. Once queueing begins, the service rejects them with 409. Refresh and show the saved state; do not substitute a new timestamp without a fresh review.
+
+`cancel.json`:
+```json
+{"documentUpdatedAt":"POST_READ_TIMESTAMP"}
+```
+`time.json`:
+```json
+{"documentUpdatedAt":"POST_READ_TIMESTAMP","scheduleLocal":{"dateTime":"2030-11-16T09:00","timeZone":"America/Chicago"}}
+```
+```sh
+frontpage mail campaign unschedule --id CAMPAIGN_DOCUMENT_ID --file cancel.json --request-key CANCEL_KEY --site YOUR_SITE --json
+frontpage mail campaign reschedule --id CAMPAIGN_DOCUMENT_ID --file time.json --request-key CHANGE_KEY --site YOUR_SITE --json
+```
+
+For reschedule, scheduledAt is also accepted instead of scheduleLocal. Keep the original key and exact payload after a lost response, then read back state. Accepted action keys cannot reapply an older change over a newer one. An old send confirmation retry cannot restart a cancelled draft. A different action needs a new request key. These operations share the worker's campaign lock and add no table, campaign state or worker.
+
 ### Email capability release check
 
 For each changed Email capability, check its shared service, UI, public API, CLI help and examples, owner-agent schema/instructions, and MCP operation/docs. Add focused contract checks and test the real adapters. Run `node scripts/people/sync-agent-docs.mjs` after editing the packaged manuals and `node scripts/people/sync-agent-docs.mjs --check` before release. Publish hosted guides through the Frontpage CLI only, then verify the public page. Do not maintain a separate scheduling implementation or a second internal manual.

package/PEOPLE.md

@@ -579,7 +579,7 @@ Preview reports matched, eligible, no-email, suppressed, and permission-missing
 
 Campaigns can also schedule a future send through `mail save` with `document.scheduledAt`. A date on a draft never sends it. After reviewing content, audience and time, `mail campaign send` confirms the saved schedule; the existing worker waits until due. Send now uses scheduledAt:null. `campaign get` returns stored status and scheduledAt; pending plus a future time displays Scheduled in the UI. Groups and filters resolve when confirmed. Read [MAIL.md, Campaign scheduling](./MAIL.md#campaign-scheduling) for complete save, review, retry, agent and MCP examples. Direct `mail send email` is for immediate unscheduled sends and cannot bypass a saved schedule.
 
-For the owner agent, call `set_mail_settings({})` to read the business timezone, then `save_mail_editor` with a one_off document and future ISO scheduledAt including Z or an explicit offset. Omission preserves timing; null clears it. Read `get_mail_email` after saving and `manage_people` with area:campaign, operation:get for saved timing/audience, then operation:preview for the exact audience and eligible count. Show the owner the content, recipients and local send time. On explicit confirmation, call `manage_people` with area:campaign, operation:send, payload:{documentId,requestKey,review:{audience,eligible,documentUpdatedAt,scheduledAt}}. Use the post-save document timestamp, preview count and canonical saved UTC time. These values must still match; a changed review needs a fresh read and approval. Keep the original requestKey and payload after an uncertain result and read back state before retrying. Never use direct send_mail_email to bypass timing. MCP uses `frontpage_mail_write` operation:save_mail_editor and campaign.send, with campaign.get/preview through `frontpage_mail_read`. A confirmed campaign cannot be edited or rescheduled in this flow.
+For the owner agent, use `save_mail_editor` with a one_off document and `scheduleLocal:{dateTime:"2030-11-15T09:00",timeZone:"America/Chicago"}`. The server converts local time to UTC. Use the owner's timezone; ask if unknown. Future ISO scheduledAt including Z or an explicit offset remains supported; do not supply both. Omission preserves timing; null clears it. Read `get_mail_email` after saving and `manage_people` with area:campaign, operation:get for saved timing/audience, then operation:preview for the exact audience and eligible count. Show the owner the content, recipients and local send time. On explicit confirmation, call `manage_people` with area:campaign, operation:send, payload:{documentId,requestKey,review:{audience,eligible,documentUpdatedAt,scheduledAt}}. Use the post-save document timestamp, preview count and canonical saved UTC time. These values must still match; a changed review needs a fresh read and approval. Keep the original requestKey and payload after an uncertain result and read back state before retrying. Never use direct send_mail_email to bypass timing. MCP uses `frontpage_mail_write` operation:save_mail_editor and campaign.send, with campaign.get/preview through `frontpage_mail_read`. Before queueing, campaign.unschedule cancels the scheduled email to Draft; campaign.reschedule changes only time. Both use documentUpdatedAt from a fresh campaign.get and a stable requestKey. Reschedule takes scheduleLocal or scheduledAt. Get approval for the new time and retain confirmed recipients/content. Cancellation keeps the email/audience for editing; scheduling again needs fresh confirmation and a new send key. Old accepted retries cannot undo later actions. UI, CLI, agent and MCP share this service. See the Mail guide for examples.
 
 ## CLI, API, and agent reference
 

package/dist/commands/people-workspace.js

@@ -124,7 +124,7 @@ export async function runCampaign(slug, args) {
         ...payload,
         operation,
         ...(documentId ? { documentId } : {}),
-        ...(operation === "send"
+        ...(["send", "unschedule", "reschedule"].includes(operation)
             ? { requestKey: requestKey ?? payload.requestKey }
             : {}),
     });

package/dist/registry.js

@@ -601,8 +601,8 @@ export const COMMANDS = [
             "settings set --file settings.json supports all eight fields and null resets; --header-align, --window-start, --window-end, --hourly-cap null|1..1000.",
             "sends list --q --status --type campaign|series|confirmation|template|test|inline --page 1 --limit 20.",
             "Series status active means On; paused/draft mean Off. Enrollment while Off waits at step 1, without sending. Existing people resume their next unsent step.",
-            "campaign preview|audience|send|get. --id DRAFT_ID, --file audience.json ({audience:{groupIds|stageIds|personIds|filters}}). send requires --request-key; reuse it after a network error. Templates/series are for automation; campaigns have separate drafts. See PEOPLE.md.",
-            "Schedule campaigns through save document.scheduledAt (future ISO time with timezone); null means Send now, omission preserves timing. A dated draft never sends until campaign send confirms it. Supply review:{audience,eligible,documentUpdatedAt,scheduledAt} from fresh saved reads/preview. campaign get returns status and scheduledAt; pending plus a future date means Scheduled. Direct send email cannot bypass saved timing. See MAIL.md, Campaign scheduling.",
+            "campaign preview|audience|send|get|unschedule|reschedule. --id DRAFT_ID, --file audience.json ({audience:{groupIds|stageIds|personIds|filters}}). send, unschedule and reschedule require --request-key; reuse it after a network error. Templates/series are for automation; campaigns have separate drafts. See PEOPLE.md.",
+            "Schedule campaigns through save document.scheduleLocal:{dateTime,timeZone} (local YYYY-MM-DDTHH:mm and IANA zone, converted by the server) or document.scheduledAt (future ISO time with timezone); null means Send now, omission preserves timing. A dated draft never sends until campaign send confirms it. Supply review:{audience,eligible,documentUpdatedAt,scheduledAt} from fresh saved reads/preview. campaign get returns status and scheduledAt; pending plus a future date means Scheduled. Direct send email cannot bypass saved timing. Before queueing, unschedule cancels to draft; reschedule changes only time. Both require documentUpdatedAt from fresh campaign get and a stable --request-key. reschedule accepts scheduleLocal or scheduledAt. See MAIL.md, Campaign scheduling.",
             "template history <id> pages saved copies with --limit (20 by default, max 100) and --cursor. history-get <id> --history-id reads full content. Both reads follow the plan Rewind window, plus Latest at any age; older copies stay stored. Lists report windowDays, unlimited, canUpgrade and moreBeyondWindow. Use template set with the stable template ID to save edited content as latest; past copies stay unchanged. Read template get before editing. History begins with content retained when history shipped, not lost earlier edits.",
             "email list is unsent drafts only. Sent one-offs are mail sends list",
             "send --file is an inline one-off (no saved document)",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "frontpage-host",
-  "version": "0.3.16",
+  "version": "0.3.17",
   "description": "Frontpage CLI — manage your site from the terminal",
   "type": "module",
   "bin": {