frontpage-host 0.3.11 → 0.3.13

package/AGENTS.md

@@ -298,4 +298,4 @@ For a manual group, `groups.people` accepts `availability: "all" | "available" |
 
 Complete Store edits: use existing items update --file with changed fields and variantUpdates. stock requires expectedStock from a fresh items get. One transaction saves all changes or none. On 409 review current stock; never silently substitute it. firstVariant plus optionNames enables versions. Keep explicit stock/variant commands for single operations. Routines add accepts --request-id UUID; reuse that ID and exact schedule after a lost response. Ordinary form edits live only in the active task; Cancel keeps input, Discard loses unfinished input. Submitted payments, imports, builds, and API-key status are separate operations.
 
-Template history (frontpage-host 0.3.11+): read `mail template get ID` before editing. `mail template history ID --limit 20 --cursor CURSOR` pages saved copies; `mail template history-get ID --history-id COPY_ID` fetches full content. Edit any copy, then `mail template set ID --file content.json` with the stable template ID and content fields only to make a new latest copy. Last template save wins; past copies remain. Campaign and series conflict checks remain. Retry uncertain saves through `mail save` with the same requestKey and exact payload. History begins with content retained at launch; earlier overwritten edits are unavailable. See MAIL.md.
+Template history (frontpage-host 0.3.11+): read `mail template get ID` before editing. `mail template history ID --limit 20 --cursor CURSOR` pages saved copies; `mail template history-get ID --history-id COPY_ID` fetches full content. Edit any copy, then `mail template set ID --file content.json` with the stable template ID and content fields only to make a new latest copy. Last template save wins; past copies remain. Campaign and series conflict checks remain. Retry uncertain saves through `mail save` with the same requestKey and exact payload. History begins with content retained at launch; earlier overwritten edits are unavailable. History reads use the plan’s Rewind window and always include Latest, even when older. Older copies stay stored; lists and direct reads apply the same limit. Window metadata explains the limit and whether older copies exist. See MAIL.md.

package/CUSTOMER-INBOX.md

@@ -32,7 +32,7 @@ Settings allow `enabled`, `instructions`, `tools`, `maxSteps` (1–12), `maxOutp
 
 `maxContextTokens` (12000–96000, default 32000) keeps its existing API name but is a conservative working-size allowance, not an exact provider-token count or AI credit balance. Admission measures UTF-8 request text and tools in the provider's wire representation once, with reply and image reserves. It never counts both canonical assistant content and provider replay. Exact provider receipts still determine billing. Optional older history, preloaded notes and expendable read results can leave the working window; current input, required owner guidance, safety instructions and completed action outcomes remain intact. Omitted reads are labeled and must be reread before use. Full history and sources remain saved. Screening uses complete required public input and removes only optional older context. Required input that cannot fit needs owner review.
 
-Retrieval calls share the remaining allowance within each tool batch. Website reads return smaller chunks when needed, with their existing cursors. Knowledge search previews return accurate `hasMore` flags. `knowledge_read({id,cursor?})` and `knowledge_read({sourceId,cursor?})` return bounded bodies with `offset`, `truncated` and `nextCursor`; continue the identical ID. Knowledge cursors bind the site, ID and content version. Changed or expired content requires restarting without a cursor. Management source/note reads keep their full-body contract.
+Retrieval calls share the remaining allowance within each tool batch. Website reads return smaller chunks when needed, with job-local short continuation references. Knowledge search previews return accurate `hasMore` flags. `knowledge_read({id,cursor?})` and `knowledge_read({sourceId,cursor?})` return bounded bodies with `offset`, `truncated` and `nextCursor`; continue the identical ID. Knowledge cursors bind the site, ID and content version. Changed or expired content requires restarting without a cursor. Management source/note reads keep their full-body contract.
 
 `retrieval_budget_exhausted` tells the support agent to use one focused read or answer from sufficient evidence still present, rather than repeat the same broad batch. Local preparation removes optional context before another paid call. An unresolved paid call or email send still requires reconciliation, never a blind inference retry.
 
@@ -206,6 +206,8 @@ frontpage customer-inbox put settings --site my-site --file website-settings.jso
 
 The support agent can call `website_search({query,cursor?})` and `website_read({path,cursor?})`. Both are bound to the active job's own public business website. They accept no other site ID, hostname, source path or credential. Searches match focused keywords and fetch at most four public pages per call. Results include matching URLs/excerpts, `scanned`, `discovered`, `unavailable`, `partial` and `nextCursor`.
 
+For Support tool results, `nextCursor` is a short job-local reference such as `next_1`. The runtime saves and supplies the exact signed server cursor, including across worker restarts. A reference cannot select another page, query or job. Direct internal website-tool clients keep their existing signed-cursor contract.
+
 Use a focused query such as `repair pricing`. Follow a search `nextCursor` with the **same query**; start a changed query without a cursor. Read a promising result with `website_read({path:"/services"})`, using the returned site-relative path. Reads return up to 8,000 characters with `truncated` and `nextCursor`; continue with the **same path** to read more text. A changed page or expired cursor requires restarting without the cursor. Search previews are not complete evidence. An empty partial batch does not prove that the answer is absent.
 
 Expected tool failures return `error`, `message`, `nextAction` and `retryable`. `website_cursor_invalid` explains how to restart the request. Page failures identify whether another result or a bounded retry is useful. `retryable` refers to a transient failure, not permission to repeat invalid input. The agent corrects recoverable inputs before escalating; revoked permissions and stale jobs still stop execution. No source files, private pages, credentials or external-site override become available.
@@ -225,7 +227,7 @@ Example search result for `{"query":"repairs"}`:
   "discovered":12,
   "unavailable":[],
   "partial":true,
-  "nextCursor":"OPAQUE_CONTINUATION_CURSOR",
+  "nextCursor":"next_1",
   "retrievedAt":"2026-10-17T12:00:00.000Z"
 }
 ```
@@ -480,3 +482,11 @@ invalid IDs change nothing. Retries are harmless. This endpoint neither exposes
 message content nor changes ownership, knowledge, model work or charges. Canceled
 follow-ups show **Seen in chat · email not needed** in the workspace. If the request
 fails, normal email delivery remains the fallback.
+
+## Chat links and page context
+
+Embedded chat and the owner Inbox render named Markdown links and ordinary HTTP/HTTPS URLs safely. Message storage stays plain text; arbitrary HTML and unsafe URL schemes do not execute. Email delivery formatting is unchanged. Support can use `[descriptive text](https://example.com/help)` in replies.
+
+New browser widgets send optional `pagePath` with each message when the API advertises `pageContext:true`. The path is tied to that message, excludes query strings and fragments, and appears in Support history and security screening. It is an untrusted same-site hint, never identity or authority. It is not live browsing history. Existing clients may omit it. The email-confirmation return path remains separate.
+
+Decisions cache-read and cache-write counts are subsets of total input. New Decisions receipts use the published cache rates with a new provider-price snapshot; old snapshots keep their original rules. Input limits, customer multipliers, credits, model selection and budget enforcement are unchanged. This release does not repair old requests or change recovery controls.

package/MAIL.md

@@ -44,9 +44,11 @@ frontpage mail template history TEMPLATE_ID --cursor NEXT_CURSOR --site YOUR_SIT
 frontpage mail template history-get TEMPLATE_ID --history-id SAVED_COPY_ID --site YOUR_SITE --json
 ```
 
-History returns `items` (ID, savedAt, name, subject), `currentId` and `nextCursor`. Fetch the next page until `nextCursor` is null. The default page size is 20, with a maximum of 100. `history-get` returns `copy` with full content and `templateId`, the stable ID. The workspace shows the same history under Sender; scrolling loads the next 20 copies.
+History returns `items` (ID, savedAt, name, subject), `currentId`, `nextCursor`, `windowDays`, `unlimited`, `canUpgrade` and `moreBeyondWindow`. The last field reports hidden older copies when the final page is reached. Fetch the next page until `nextCursor` is null. The default page size is 20, with a maximum of 100. `history-get` returns `copy` with full content and `templateId`, the stable ID. The workspace shows the same history under Sender; scrolling loads the next 20 copies.
 
-To use an old copy, fetch it, edit it if needed, then save normally. Put only `name`, `subject`, `preheader`, `blocks` and `variables` in a JSON file, then run `frontpage mail template set TEMPLATE_ID --file content.json --site YOUR_SITE --json`. Use the stable TEMPLATE_ID, never the saved-copy ID. This creates a new latest copy; it does not change the old one. There is no separate restore command. Read `template get` before each edit so you start with current work. For response-loss retries use `mail save` with one unchanged `requestKey` and payload; replaying that save creates no duplicate copy.
+Template history reads follow the site plan’s Rewind window: Starter 7 days, Growth 30 days, Scale 90 days; Enterprise and Internal use the existing uncapped history rule. Latest remains readable at any age. Older copies stay stored and become readable again within a larger window after an upgrade. Both history lists and history-get enforce the window; direct saved-copy IDs do not bypass it. Existing feature and CLI plan gates still apply.
+
+To use an available old copy, fetch it, edit it if needed, then save normally. Put only `name`, `subject`, `preheader`, `blocks` and `variables` in a JSON file, then run `frontpage mail template set TEMPLATE_ID --file content.json --site YOUR_SITE --json`. Use the stable TEMPLATE_ID, never the saved-copy ID. This creates a new latest copy; it does not change the old one. There is no separate restore command. Read `template get` before each edit so you start with current work. For response-loss retries use `mail save` with one unchanged `requestKey` and payload; replaying that save creates no duplicate copy.
 
 Public API reads: `GET /api/v1/sites/SLUG/mail/templates/TEMPLATE_ID/history?limit=20&cursor=…` and `GET /api/v1/sites/SLUG/mail/templates/TEMPLATE_ID/history/SAVED_COPY_ID`. Viewers may read; editors and owners may save. Site access and plan checks still apply.
 

package/PEOPLE.md

@@ -788,4 +788,4 @@ Writes are not universally idempotent. Preserve documented request keys, receipt
 
 For MCP CSV exports, continue `contacts.export` with `textOffset` set to `textPage.nextOffset` and `expectedTextVersion` set to `textPage.version`. The tool returns bounded `csv` text and a version hash; a changed export returns a conflict instead of combining different snapshots. `textLength` defaults to 4,000 UTF-16 units and accepts up to 8,000.
 
-Template history uses the existing Email tools. Read get_mail_template before editing. list_mail_template_history({id,cursor?,limit?}) pages copies; get_mail_template_history({id,historyId}) reads full content. Edit any copy and save through update_mail_template with the stable ID to make it latest. Both simultaneous saves remain; last template save wins. Group, rule and series checks remain. CLI equivalents and full instructions: MAIL.md, Template history.
+Template history uses the existing Email tools. Read get_mail_template before editing. list_mail_template_history({id,cursor?,limit?}) pages copies; get_mail_template_history({id,historyId}) reads full content. Edit any copy and save through update_mail_template with the stable ID to make it latest. Both simultaneous saves remain; last template save wins. Group, rule and series checks remain. History lists and direct reads follow the plan’s Rewind window, plus Latest at any age. Older copies stay stored. CLI equivalents and full instructions: MAIL.md, Template history.

package/dist/registry.js

@@ -593,7 +593,7 @@ export const COMMANDS = [
             "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.",
-            "template history <id> pages saved copies with --limit (20 by default, max 100) and --cursor. history-get <id> --history-id reads full content. 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.",
+            "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)",
             "Blocks and series steps are JSON (--file). Unknown leftover flags fail closed (exit 2)",

package/llms.txt

@@ -58,4 +58,4 @@ The workspace validates and saves unfinished group settings before opening email
 
 Complete Store edits: use existing items update --file with changed fields and variantUpdates. stock requires expectedStock from a fresh items get. One transaction saves all changes or none. On 409 review current stock; never silently substitute it. firstVariant plus optionNames enables versions. Keep explicit stock/variant commands for single operations. Routines add accepts --request-id UUID; reuse that ID and exact schedule after a lost response. Ordinary form edits live only in the active task; Cancel keeps input, Discard loses unfinished input. Submitted payments, imports, builds, and API-key status are separate operations.
 
-Template history (frontpage-host 0.3.11+): read `mail template get ID` before editing. `mail template history ID --limit 20 --cursor CURSOR` pages saved copies; `mail template history-get ID --history-id COPY_ID` fetches full content. Edit any copy, then `mail template set ID --file content.json` with the stable template ID and content fields only to make a new latest copy. Last template save wins; past copies remain. Campaign and series conflict checks remain. Retry uncertain saves through `mail save` with the same requestKey and exact payload. History begins with content retained at launch; earlier overwritten edits are unavailable. See MAIL.md.
+Template history (frontpage-host 0.3.11+): read `mail template get ID` before editing. `mail template history ID --limit 20 --cursor CURSOR` pages saved copies; `mail template history-get ID --history-id COPY_ID` fetches full content. Edit any copy, then `mail template set ID --file content.json` with the stable template ID and content fields only to make a new latest copy. Last template save wins; past copies remain. Campaign and series conflict checks remain. Retry uncertain saves through `mail save` with the same requestKey and exact payload. History begins with content retained at launch; earlier overwritten edits are unavailable. History reads use the plan’s Rewind window and always include Latest, even when older. Older copies stay stored; lists and direct reads apply the same limit. Window metadata explains the limit and whether older copies exist. See MAIL.md.

package/package.json

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