frontpage-host 0.3.15 → 0.3.17

package/AGENTS.md

@@ -282,6 +282,8 @@ 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|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.
 
 Rule placement: read a rule revision, then use `people workspace rules.place` with `id`, `owner` and `expectedRevision`. This only organizes the rule; it does not change its trigger or execution. New UI rules/attachments save paused. Generic attachment calls still need explicit `enabled:false` for paused creation. Saved optional conditions and exact duration minutes remain supported through CLI and agent calls.

package/MAIL.md

@@ -100,6 +100,114 @@ Include `audience` with a one_off document in the same `mail save` request. Supp
 
 For an audience-only change, the existing `mail campaign audience --id DOCUMENT_ID --file audience.json` remains supported. Its JSON is `{"audience":{"personIds":["PERSON_ID"]}}`, or `{"audience":null}` to clear. Saved selection is intent; final send review resolves groups and filters again, checks permission and delivery restrictions, and freezes the actual recipients and content. Started campaigns cannot be edited or sent twice with a new key. Read `PEOPLE.md` for preview/send review and stable send keys.
 
+## Campaign scheduling
+
+The workspace, CLI, owner agent and MCP use the same saved campaign and confirmation service. Send now is the default. Saving a date never confirms sending: a draft stays a draft even after that date passes. Only an explicit campaign confirmation makes it eligible for the worker. The worker selects confirmed (`pending`) campaigns whose scheduled time has arrived, or whose scheduled time is null. Its existing minute pass and delivery checks can delay sending; the selected time is the earliest send time, not a delivery guarantee.
+
+| Action | CLI | Owner agent | MCP |
+| --- | --- | --- | --- |
+| Read content | `mail email get ID --json` | `get_mail_email` | `frontpage_mail_read`, operation `get_mail_email` |
+| Read timezone | `mail settings get --json` | `set_mail_settings({})` (read only) | `frontpage_mail_read`, operation `get_mail_settings` |
+| 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 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.
+- Omitting the field preserves existing timing.
+- Templates and series do not accept this field.
+
+Example `draft.json` for an existing campaign; replace IDs, timestamps, content and audience with the current reviewed values. Omit id and expectedUpdatedAt when creating a new campaign. Choose a future date for the actual request.
+
+```json
+{
+  "requestKey": "UNIQUE_SAVE_KEY",
+  "document": {
+    "id": "CAMPAIGN_DOCUMENT_ID",
+    "expectedUpdatedAt": "EXACT_CURRENT_DOCUMENT_TIMESTAMP",
+    "kind": "one_off",
+    "name": "November update",
+    "subject": "Your November update",
+    "preheader": "News from our team.",
+    "blocks": [{"type":"paragraph","text":"Here is our latest news."}],
+    "scheduledAt": "2030-11-15T09:00:00-06:00"
+  },
+  "audience": {"personIds":["PERSON_ID"]}
+}
+```
+
+```sh
+frontpage mail save --file draft.json --site YOUR_SITE --json
+frontpage mail email get CAMPAIGN_DOCUMENT_ID --site YOUR_SITE --json
+frontpage mail campaign get --id CAMPAIGN_DOCUMENT_ID --site YOUR_SITE --json
+frontpage mail campaign preview --file audience.json --site YOUR_SITE --json
+```
+
+`audience.json` contains `{"audience":{"personIds":["PERSON_ID"]}}`. Supported choices also include `groupIds`, `stageIds`, `filters`, and `addresses`. The UI's Choose people option uses personIds; List individual email addresses uses addresses. Read `campaign get` to reuse a saved selection. When changing audience sources, send only the new source rather than merging the old selection. Use `audience:null` in `mail save` to clear it. Clearing or replacing an audience does not clear the saved schedule. Explicit addresses do not create People records or grant email permission.
+
+### Review and confirm
+
+Show the owner the content, eligible recipient count, and send date/time in the business timezone before confirmation. Fetch current content and campaign state after saving, and preview the exact audience. The confirmation file `review.json` carries those reviewed values:
+
+```json
+{
+  "review": {
+    "audience": {"personIds":["PERSON_ID"]},
+    "eligible": 1,
+    "documentUpdatedAt": "EXACT_POST_SAVE_DOCUMENT_TIMESTAMP",
+    "scheduledAt": "2030-11-15T15:00:00.000Z"
+  }
+}
+```
+
+```sh
+# This is the confirmation: it authorizes sending when due.
+frontpage mail campaign send --id CAMPAIGN_DOCUMENT_ID --file review.json --request-key UNIQUE_SEND_KEY --site YOUR_SITE --json
+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. 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.
+
 ## People directory and enrollment
 
 ```bash

package/PEOPLE.md

@@ -577,6 +577,10 @@ frontpage mail campaign get --id DRAFT_ID --site YOUR_SITE --json
 
 Preview reports matched, eligible, no-email, suppressed, and permission-missing counts and sends nothing. Sending freezes content and eligible recipients, deduplicates email addresses, and uses the existing paced email queue. Reuse the send request key after a lost response. Check `campaign get` for queued, sent, pending, failed, and skipped work; queued does not mean delivered.
 
+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, 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
 
 The editor, public API, CLI, and site agent call the same application service. Every operation below is available without opening the UI.

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

@@ -591,6 +591,8 @@ export const COMMANDS = [
             "frontpage mail series steps set <id> --file steps.json",
             "frontpage mail template history <id> --limit 20 --json",
             "frontpage mail template history-get <id> --history-id <saved-copy-id> --json",
+            "frontpage mail save --file scheduled-draft.json --site YOUR_SITE --json",
+            "frontpage mail campaign send --id DRAFT_ID --file review.json --request-key SEND_KEY --site YOUR_SITE --json",
             "frontpage mail suppress add --email bounce@example.com",
         ],
         flags: [
@@ -599,7 +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.",
+            "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.15",
+  "version": "0.3.17",
   "description": "Frontpage CLI — manage your site from the terminal",
   "type": "module",
   "bin": {