frontpage-host 0.2.3 → 0.2.5

package/AGENTS.md

@@ -260,10 +260,12 @@ Use `frontpage people overview`, `groups`, `stages`, `membership`, `rules`, `att
 
 ## Customer Inbox
 
-Internal, allowlisted sites only. Use `frontpage customer-inbox get|put|post RESOURCE`, stable write keys and current versions. Full guide: [CUSTOMER-INBOX.md](./CUSTOMER-INBOX.md). `export CONVERSATION_ID --out FILE` writes authorized paginated history and file metadata; `download FILE_ID --out FILE` downloads through a file grant. Outputs never overwrite existing files. `frontpage usage` reports shared site credits, mail and storage. The owner toolbar uses `manage_customer_inbox` for all site-wide Inbox settings, unlocked knowledge, files, customer conversations, private guidance, replies, takeover/return and recovery. The support agent has a separate server-bound customer scope and requires verification for People data. Both agents cannot edit or unlock locked knowledge; human UI/CLI can unlock it. Never lend a website agent a human CLI key.
+Scale and internal sites, after owner activation. No pilot allowlist. Use `frontpage customer-inbox get|put|post RESOURCE`, stable write keys and current versions. Full guide: [CUSTOMER-INBOX.md](./CUSTOMER-INBOX.md). `export CONVERSATION_ID --out FILE` writes authorized paginated history and file metadata; `download FILE_ID --out FILE` downloads through a file grant. Outputs never overwrite existing files. `frontpage usage` reports shared site credits, mail and storage. The owner toolbar uses `manage_customer_inbox` for all site-wide Inbox settings, unlocked knowledge, files, customer conversations, private guidance, replies, takeover/return and recovery. The support agent has a separate server-bound customer scope and requires verification for People data. Both agents cannot edit or unlock locked knowledge; human UI/CLI can unlock it. Never lend a website agent a human CLI key.
 
 
 Payments, invoices and recurring billing: see packaged [PAYMENTS.md](./PAYMENTS.md), `frontpage help payments`, and https://frontpage.host/developers/payments. Version 0.2.0 removes writable currency, Store checkout mode and Store-owned money commands; Store stays cart-only. Preview/review before sends; keep stable operation keys on retries. Autopay requires the customer’s own verified authorization.
 
 
 Offerings own every standalone Pay now payment. Use `frontpage payments buttons list|get|create|update|archive|restore`; create the saved offering before adding its returned `data-fp-pay` markup. Supports `--receipt-template-id UUID`, `--default-receipt`, `--active true|false`, combined price/details updates and JSON payloads. Archive deletes from active checkout but preserves history. The website agent uses the same service automatically for ordinary payment-button requests. Store stays cart-only; invoices stay saved customer-addressed records. Full instructions: PAYMENTS.md and https://frontpage.host/developers/payments.
+
+Currency is owned by Payments and read by Store, Offerings and invoices. Offering create/get/update responses include exact receiptVariables. For custom confirmations, declare those names with existing mail template commands, attach receiptTemplateId, and verify both records. Only include expressly selected answers; keep private answers excluded. Forms still use input-name tokens and confirmTemplateId.

package/CUSTOMER-INBOX.md

@@ -1,6 +1,6 @@
 # Customer Inbox
 
-Customer Inbox uses the site's existing AI credits and storage allowance. It is available on internal plans after site activation. The support agent uses fixed GPT-6 Luna and bills AI usage at 10× raw provider cost. During human handling, customer messages use ordinary routing. Each authenticated owner email uses a small metered Luna Decisions call to keep private guidance, ownership controls and customer-facing replies distinct; the full support agent stays paused. UI and CLI controls need no intent call.
+Customer Inbox uses the site's existing AI credits and storage allowance. It is available on Scale and internal plans after owner activation. Other public plans do not include Inbox. No pilot allowlist is required. The support agent uses fixed GPT-6 Luna and bills AI usage at 10× raw provider cost. During human handling, customer messages use ordinary routing. Each authenticated owner email uses a small metered Luna Decisions call to keep private guidance, ownership controls and customer-facing replies distinct; the full support agent stays paused. UI and CLI controls need no intent call.
 
 Run `frontpage help customer-inbox`. Use the site's normal CLI key:
 
@@ -94,6 +94,26 @@ Set `enabled:false` in settings to use manual handling for new conversations. Th
 
 Set `guidanceToMe:true` in a versioned settings update to bind the signed current owner's verified address. Arbitrary recipient addresses and user IDs remain forbidden. The service saves only the resolved owner identity, not this setup flag.
 
+## Verify a direct email sender
+
+Fresh mail to the business address receives one generic confirmation email before support inference or People access. With passing receiving-service DMARC checks, a normal reply to its secret Reply-To confirms that mailbox. The customer can use **Confirm email** instead. No special reply words or AI decision are needed. Confirmation itself uses no AI credits; the email send and saved files use existing site allowances.
+
+DMARC alone proves a sending domain, not a particular mailbox. Inbox requires the delivered secret destination, matching sender and site, active route, and live proof. It ignores sender-written authentication headers. Missing or gray checks offer the button only. A hard failure is held without an automatic reply. Temporary checks retry through the existing transport outbox and fall back to link confirmation after the third attempt.
+
+The challenge lasts one hour. A successful email-only proof lasts 30 days. Repeated replies do not extend it. A used challenge address continues while its route and proof remain valid. Unused expired challenges and expired/revoked proofs grant no access. Send a new message to the business or ask its owner for a fresh link. An expired-route reply remains held with its original captured email; it does not silently become verified input. Owners can inspect held receipts and request a fresh confirmation rather than weakening identity checks.
+
+Email confirmation never signs an existing browser into a customer account. A visitor who typed the same email still needs their own browser/app proof before history, orders, People notes or customer updates are available. Existing chat confirmation and recovery keep their browser-specific behavior. Once proven, email support joins the customer's continuous site thread and resumes the original question plus any new reply. Empty human replies can prove ownership without adding a blank customer message. Private guidance, manual handling, site eligibility and knowledge locks keep their existing rules.
+
+Read `conversations/<id>/routing` for `identity.verified` and the email-only `verification` status. Status is `unrequested`, `pending`, `verified`, `expired`, `revoked`, `held`, `retrying` or `failed`; reasons and timestamps help separate proof from delivery. CLI 0.2.5 or later supports the new resend resource. A current human admin or owner-toolbar manager can send a fresh generic link to the already bound customer address:
+
+```sh
+printf '{}\n' > confirmation.json
+frontpage customer-inbox post conversations/CONVERSATION_UUID/verification \
+  --file confirmation.json --request-key confirm_customer_20261016 --site my-site --json
+```
+
+The JSON CLI result contains `{"ok":true,"command":"customer-inbox","data":{"verification":"pending"}}`. Reuse the same key after a lost response. Inbox keeps one live pending challenge and enforces a one-minute resend cooldown. A reminder of a still-valid challenge keeps its original link and deadline; it does not create another grant or extend expiry. A pacing response uses HTTP `429` with `verification_cooldown`; retry after one minute. The request accepts no recipient or identity fields. A resend never grants authority by itself. The workspace provides the same **Send fresh confirmation** action. Owner-toolbar operation: `conversation_verify_email` with `{"id":"CONVERSATION_UUID"}`.
+
 ## Security review and recovery
 
 | Resource | Method | JSON body |
@@ -105,7 +125,7 @@ Set `guidanceToMe:true` in a versioned settings update to bind the signed curren
 | `receipts` | GET | Held inbound mail; admin only |
 | `receipts/<id>` | POST | `{}` queues a held capture retry; admin only |
 
-Only a validated clear attack can create an automatic site-scoped block. Authenticated customer mail binds a verified email identity; unverified mail stays thread-scoped. Blocks never ban a People contact across sites or a shared IP. Unblock preserves evidence and does not replay the attack. Uncertain, malformed, refused or unavailable screening pauses the agent and leaves human handling available. Known blocks and rate/size checks stop work before another paid call.
+Only a validated clear attack can create an automatic site-scoped block. DMARC-passing customer mail provides a site-scoped sender identity for abuse blocking only; it does not grant customer-data access. Unauthenticated mail stays thread-scoped. Blocks never ban a People contact across sites or a shared IP. Unblock preserves evidence and does not replay the attack. Uncertain, malformed, refused or unavailable screening pauses the agent and leaves human handling available. Known blocks and rate/size checks stop work before another paid call.
 
 The fixed policy requires allow probability at least 0.90 and confidence at least 0.80, with no attack category. Automatic blocking requires malicious probability and confidence at least 0.98 and an attack category. Other results pause for human review; a review does not label the customer malicious. These are platform controls, not customer settings. Review email notices deduplicate per conversation and reason group per hour. Saved receipt retries wait at least 30 seconds so one failed receipt cannot monopolize recovery.
 
@@ -121,7 +141,7 @@ The developer guide lives at `https://frontpage.host/developers/customer-inbox`.
 
 ## Owner workspace and widget
 
-Open `/workspace/sites/<siteId>/customer-inbox` on an approved internal site. The workspace uses the same versioned service operations as the CLI. Conversation rows show the latest public message. Customer messages, agent replies, owner replies, private guidance, notes and handling changes have distinct labels. Private guidance stays in the thread and does not transfer ownership.
+Open `/workspace/sites/<siteId>/customer-inbox` on a Scale or internal site. The workspace uses the same versioned service operations as the CLI. Conversation rows show the latest public message. Customer messages, agent replies, owner replies, private guidance, notes and handling changes have distinct labels. Private guidance stays in the thread and does not transfer ownership.
 
 Use `frontpage customer-inbox get widget --site my-site` as a human admin to get the script URL, site ID and server-side app identity key. Install the returned script through the normal Frontpage CLI file workflow or your app's template:
 
@@ -184,6 +204,8 @@ const identity = encoded + "." + createHmac("sha256", process.env.INBOX_IDENTITY
 
 The service verifies the signature, site, origin and expiry. Assertions can last at most five minutes. They grant customer identity only, never owner or manager authority. Every app-session request must include the current signed identity matching that session's subject and email. Put a server-rendered assertion in `data-identity`, or preferably provide `data-identity-url="/api/support-identity"`. That same-origin HTTPS endpoint authenticates the current app user and returns `{"identity":"<signed assertion>"}`. The widget refreshes it; after logout or account changes, old app sessions cannot be read without the matching identity. Anonymous widgets need no assertion. Each approved origin has its own visitor session; email continues the bound conversation.
 
+A new direct email to the public agent address can receive general business answers, but it does not prove mailbox ownership. DMARC validates the sending domain, not authority to read a customer record. The agent requests confirmation before reading or updating People, customer notes, orders or previous customer history. Fresh alias mail stays provisional until proof. Replies to a valid recipient-bound route can continue without a fresh click while the customer proof remains valid.
+
 Unverified visitors can ask general business questions in their provisional chat. They cannot read or update an existing People contact, notes, orders or customer history. The same gate protects automatic People capture and every customer-data tool. After proof, People receives the customer and subsequent factual updates; the existing customer notes receipt remains idempotent. Public support and identity-protected support are distinct permissions.
 
 Browser access lasts 30 days from creation or successful email verification/recovery. Verification links last one hour and work once; confirming rotates the credential. The widget retains access in that browser's storage and keeps it through temporary network failures. Returning browsers with valid access reopen their history automatically. When access is missing, ordinary **Continue** and email confirmation select the verified customer's continuous public-support conversation for that site. Both empty and nonempty provisional chats join only after proof; approved public origins can share the customer history through their own verified sessions. Typed email never restores history. Revoked credentials remain revoked; fresh proof does not reactivate an old token. Signed app identities remain separate by site, origin and subject. The recovery endpoint remains available, but customers need no separate Recover workflow. An empty unverified saved session with an email requests confirmation automatically; a receipt prevents duplicate requests during the link's one-hour lifetime, then rotates so an expired link cannot block a fresh confirmation.

package/PAYMENTS.md

@@ -409,3 +409,61 @@ not automatically join its submission to a payment.
 Offerings work without Store markup. The platform supplies a Payments drawer for buyer-chosen amounts and saved questions; fixed payments without questions proceed to Stripe Checkout. Never add a Cart button or Store drawer for an Offering.
 
 For custom appearance, include one shared `<template data-fp-payment-drawer>` using the required panel, title, close, amount, fields, error and confirm hooks documented by the Payments agent module. Style it with normal site CSS and payment-specific variables. Keep dynamic questions in the saved Offering, not in page HTML. UI, CLI and agent question edits appear on the next opening without republishing. Template/style edits use normal website publishing. Payments never changes the Store cart or its saved delivery choices.
+
+
+## Currency and confirmation answer variables
+
+Payments owns the site's currency from the existing Stripe connection process.
+Store, Offerings, invoices, checkout and public price display read the same saved
+Payments currency. It is read-only; do not set a Store currency or guess USD when
+setup is pending. Recorded transactions retain the currency actually charged.
+
+Offering create/get/update responses include `receiptVariables`, an array of
+`{name,label}`. The standard receipt variables are `buyer_name`, `buyer_email`,
+`total`, `currency`, and `items`. An included question also exposes
+`answer_<customizationId>`. For example, the saved field ID `appointment-date`
+provides `{{answer_appointment-date}}` when `includeInReceipt:true`.
+Read returned names rather than constructing names from editable labels.
+
+Use the existing template commands:
+
+```bash
+frontpage payments buttons get consultation --site YOUR_SITE --json
+frontpage mail template create --file confirmation.json --site YOUR_SITE --json
+frontpage payments buttons update consultation --receipt-template-id TEMPLATE_UUID --site YOUR_SITE --json
+frontpage mail template get TEMPLATE_UUID --site YOUR_SITE --json
+```
+
+A template document declares the tokens it uses:
+
+```json
+{
+  "name": "Consultation confirmation",
+  "subject": "Thank you, {{buyer_name}}",
+  "preheader": "Your consultation payment confirmation",
+  "variables": ["buyer_name", "answer_appointment-date", "total"],
+  "blocks": [
+    {"type":"paragraph","text":"Requested date: {{answer_appointment-date}}"},
+    {"type":"paragraph","text":"Total paid: {{total}}"}
+  ]
+}
+```
+
+Only answers explicitly included in the receipt are available. Private answers
+stay in authorized payment details. Existing `{{items}}` summaries still work.
+Stable IDs keep tokens working after a label edit. Historical receipts use the
+captured answers, not today's question definitions. An optional unanswered field
+can be blank; zero and false are values. Unavailable variables or a wrong-site
+template receive a validation error. Correct a shared template before removing
+its required field, or detach/replace it in the same Offering update.
+
+Forms keep their existing convention: `{{company_name}}` reads the submitted
+input named `company_name`, and the form uses `confirmTemplateId`. Offerings use
+`receiptTemplateId`. Store buyer receipts keep their five standard variables.
+There is no separate mapping interface or variable picker.
+
+Activity includes `metrics` for the last 30 days: gross received money, successful
+payment count, and average payment, grouped by currency. Gross is before fees and
+refunds. Schedules are not received money. Metrics cover the full recorded period,
+not only the capped Activity rows. Dates use verified successful-payment times;
+older records without proof show that the date is unavailable.

package/README.md

@@ -66,3 +66,5 @@ Payments, invoices and recurring billing: see packaged [PAYMENTS.md](./PAYMENTS.
 
 
 Offerings own every standalone Pay now payment. Use `frontpage payments buttons list|get|create|update|archive|restore`; create the saved offering before adding its returned `data-fp-pay` markup. Supports `--receipt-template-id UUID`, `--default-receipt`, `--active true|false`, combined price/details updates and JSON payloads. Archive deletes from active checkout but preserves history. The website agent uses the same service automatically for ordinary payment-button requests. Store stays cart-only; invoices stay saved customer-addressed records. Full instructions: PAYMENTS.md and https://frontpage.host/developers/payments.
+
+Payments owns the shared currency from Stripe setup; Store reads it. Offering create/get/update JSON returns `receiptVariables` for custom confirmation templates, including eligible `answer_<customizationId>` tokens. Use existing mail template commands and attach with `--receipt-template-id`; see PAYMENTS.md.

package/dist/commands/customer-inbox.js

@@ -5,7 +5,7 @@ import { takeFlag, assertNoUnknownFlags } from "../argv.js";
 import { getApiKey } from "../auth/keychain.js";
 import { apiBase, v1Get, httpErrorFromV1, CliHttpError, EXIT_AUTH, EXIT_USAGE, EXIT_OK, exitCodeForError, } from "../http/client.js";
 import { emitOk, emitErr, isJson } from "../runtime.js";
-const RESOURCE = /^(?:status|activation|address|widget|settings|knowledge(?:\/[0-9a-f-]+(?:\/history)?)?|sources|blocks(?:\/[0-9a-f-]+\/unblock)?|jobs(?:\/[0-9a-f-]+(?:\/resume)?)?|files(?:\/[0-9a-f-]+)?|receipts(?:\/[0-9a-f-]+)?|conversations(?:\/[0-9a-f-]+(?:\/(?:messages|routing|guidance|reply|control|state|revoke-sessions))?)?)(?:\?[^#]*)?$/;
+const RESOURCE = /^(?:status|activation|address|widget|settings|knowledge(?:\/[0-9a-f-]+(?:\/history)?)?|sources|blocks(?:\/[0-9a-f-]+\/unblock)?|jobs(?:\/[0-9a-f-]+(?:\/resume)?)?|files(?:\/[0-9a-f-]+)?|receipts(?:\/[0-9a-f-]+)?|conversations(?:\/[0-9a-f-]+(?:\/(?:messages|routing|guidance|reply|control|state|revoke-sessions|verification))?)?)(?:\?[^#]*)?$/;
 export function inboxCommand(args) {
     const work = [...args], verb = work.shift(), resource = work.shift(), file = takeFlag(work, "--file"), key = takeFlag(work, "--request-key"), out = takeFlag(work, "--out");
     assertNoUnknownFlags(work, "customer-inbox");

package/dist/registry.js

@@ -518,7 +518,7 @@ export const COMMANDS = [
         flags: [
             "items list|get|create|update|archive|restore|activate|images|stock; use --file for nested variants, options, customizations and images. Existing fixed/open pricing is retained. Store always uses Add to cart.",
             "Descriptions use a small markdown subset. Bind data-fp-store-bind=description for the full product story; do not bake titles, prices or images into the page. Store is cart-only; use Payments for explicit Pay now.",
-            "items stock uses --add/--remove as a signed delta, or --set/--unlimited. Never combine these verbs. Product pages use data-fp-store-product and the platform cart templates. Store prices use the account currency.",
+            "items stock uses --add/--remove as a signed delta, or --set/--unlimited. Never combine these verbs. Product pages use data-fp-store-product and the platform cart templates. Store prices read the shared currency owned by Payments.",
             "variants add|update|archive|restore; categories list|create|rename|archive. Create categories before assigning their slugs.",
             "settings get|set-fulfillment|set-checkout-fee|set-receipt|availability get|on|off. Fee mode flat uses --cents; percent uses --bps (250 is 2.5%). Receipt takes --template <id> or --stock. Availability requires admin and --yes in scripts.",
             "orders list|get; import explicitly reads the existing site product files. No fleet import or data conversion occurs.",
@@ -548,6 +548,7 @@ export const COMMANDS = [
             "availability preview|on|off. off reads affected counts before confirmed pause/void; a partial response stays off and requires another off request. on never resumes stopped billing or restores void invoices.",
             "activity list|get <id> --source order|payment. invoices and recurring have separate get commands. Source IDs never collide.",
             "buttons list [--limit 1..100 --offset N --archived true]; get|create|update|archive|restore. These manage Offerings. Create uses --id, --title, --price-cents, optional --amount open --min-cents. Create/update support --description, --active true|false, --receipt-template-id UUID or --default-receipt, and --file. Price, details and template save together. Archive deletes from new payments while retaining history; archive/restore require --yes. Only registered Offerings authorize Pay now; page markup and Store flags never do.",
+            "Offering create/get/update JSON includes receiptVariables. Use exact names in existing mail templates, then attach --receipt-template-id. Included answers expose answer_<customizationId>; private answers are excluded. Currency is owned by Payments, not Store.",
             "tax get; tax settings --file <file> --yes; tax registrations list|add --country US --state CA --yes|end <id> --yes. Supply the business's actual tax registrations. No automatic tax advice or raw Account Session secrets.",
             "invoices preview|send --file <file>; list [--limit 1..100 --offset N --arrangement <id>]; get|refresh|resend|void <id>. send/resend need --operation-key; send needs --preview-hash; financial writes require --yes in scripts.",
             "recurring preview|create --file <file>; list|get|refresh|cancel|resume|resend-invitation. Supported cadence: weekly, fortnightly, monthly, quarterly, yearly; firstDate YYYY-MM-DD, explicit IANA timeZone, 09:00 start. create/resume/invitation need stable operation keys. Resume requires first-date, preview-hash and --yes; no missed-period backfill.",

package/llms.txt

@@ -36,10 +36,12 @@
 
 Use `frontpage people overview`, `groups`, `stages`, `membership`, `rules`, `attachments`, `import`, and `company`. Use `frontpage mail campaign` for one-off group/stage/list audiences in Emails. Every editor action is available through these commands or `frontpage people workspace OPERATION --file payload.json`. Full operations and examples: [PEOPLE.md](./PEOPLE.md); public guide: https://frontpage.host/developers/people. Automated emails select a saved template or series. Campaigns use their own drafts.
 
-Customer Inbox (internal sites): CUSTOMER-INBOX.md. Settings, widget, knowledge, human guidance/relay, lifecycle, export/download and recovery. The owner toolbar manages all site-wide Inbox operations through manage_customer_inbox, including conversations, files and recovery, but cannot edit/unlock locked knowledge. The support agent is restricted to its verified customer and cannot change shared knowledge from customer input. No borrowed human credentials.
+Customer Inbox (Scale and internal sites): CUSTOMER-INBOX.md. Settings, widget, knowledge, human guidance/relay, lifecycle, export/download and recovery. The owner toolbar manages all site-wide Inbox operations through manage_customer_inbox, including conversations, files and recovery, but cannot edit/unlock locked knowledge. The support agent is restricted to its verified customer and cannot change shared knowledge from customer input. No borrowed human credentials.
 
 
 Payments, invoices and recurring billing: see packaged [PAYMENTS.md](./PAYMENTS.md), `frontpage help payments`, and https://frontpage.host/developers/payments. Version 0.2.0 removes writable currency, Store checkout mode and Store-owned money commands; Store stays cart-only. Preview/review before sends; keep stable operation keys on retries. Autopay requires the customer’s own verified authorization.
 
 
 Offerings own every standalone Pay now payment. Use `frontpage payments buttons list|get|create|update|archive|restore`; create the saved offering before adding its returned `data-fp-pay` markup. Supports `--receipt-template-id UUID`, `--default-receipt`, `--active true|false`, combined price/details updates and JSON payloads. Archive deletes from active checkout but preserves history. The website agent uses the same service automatically for ordinary payment-button requests. Store stays cart-only; invoices stay saved customer-addressed records. Full instructions: PAYMENTS.md and https://frontpage.host/developers/payments.
+
+Payments owns Stripe currency. Read Offering receiptVariables before creating a confirmation template; attach it through Payments. Forms use submitted input names. Full receipt contract: PAYMENTS.md.

package/package.json

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