frontpage-host 0.3.24 → 0.3.26

package/AGENTS.md

@@ -126,7 +126,7 @@ Sites are Astro 6 + Tailwind v4. More detail: `frontpage help site-building` or
 - Extensions: `frontpage extensions`; if LOCKED on plan, do not fake charts/etc.
 - Media: `frontpage media upload <file>` — images/PDF ≤25 MB, video (MP4/WebM/MOV) ≤50 MB, SVG/text ≤4 MB (sanitizing proxy). Human output prints `sitePath:` first (use that in markup — never raw blob hosts), then optional `url:`. Optional `?w=` on rasters only. **Text/CSV** uploads are inline only — **not** added to the media library and **cannot** be linked via `/__media` (`media upload --json` omits full `content`; use `inbox … --csv` for submission exports).
 - Generated images: `frontpage images generate --prompt "…"` `[--count N]` — one prompt, 1–4 variations of that same picture. Prints `sitePath:` first. Counts against AI $ and storage. Flag-off environments return 404 (`Image generation is not enabled.`). Do not call xAI / Imagine yourself.
-- Analytics: bare `frontpage analytics` = dashboard; also `summary|query|funnel|timeseries|compare|sql` for reads. Use type=pageview when counting views; count alone includes every matching event. Custom SQL is parsed/allowlisted and site-scoped by RLS; it rejects unrelated tables, unsafe functions/types, recursive CTEs and unsupported syntax. Keep SQL dates inside SQL (there is no SQL --days flag). Limits: 4000 input characters, five seconds, 500 returned rows. Metric definitions and supported examples: https://frontpage.host/developers/analytics. MCP uses separate structured tools and excludes raw SQL.
+- Analytics: bare `frontpage analytics` = dashboard; also `summary|query|funnel|timeseries|compare|sql` for reads. Use type=pageview when counting views; count alone includes every matching event. Custom SQL is parsed/allowlisted and site-scoped by RLS; it rejects unrelated tables, unsafe functions/types, recursive CTEs and unsupported syntax. Keep SQL dates inside SQL (there is no SQL --days flag). Limits: 4000 input characters, five seconds, 500 returned rows. Metric definitions and supported examples: https://frontpage.host/developers/analytics. MCP offers the same guarded SQL service through frontpage_analytics_sql, plus structured report tools; its Business read consent still applies.
 - People CRM: `frontpage people list|get|add|set|note|rm-note|follow-up|hide|unhide|export`. Site-scoped person graph (email or phone). Inbox stays the raw ledger. Hide is not forget. List export is CSV (not a one-person legal dump). Full guide: https://frontpage.host/developers/people
 - Routines: `frontpage routines list|get|add|set|pause|resume|rm|run|runs`. One routine can hold several hours and several days. `8am,12pm,4pm` on `tue,thu,fri` stores hours `[8, 12, 16]` and weekdays `[2, 4, 5]`. Ask for an IANA timezone. Do not guess UTC. Full guide: https://frontpage.host/developers/routines
 - Store catalog: `frontpage store items|variants|categories|settings|orders|import`. Integer cents only (`$49.99` is `4999`). `--price-cents` is the usual cost. Optional `--discount-cents` is the sale the buyer pays (must be lower). End a sale with `frontpage store variants update <itemId> --id <variantId> --clear-discount`. This sends discountPriceCents: null and keeps the regular price. Omit both sale flags on update to preserve the current sale. Do not combine --clear-discount with --discount-cents; 0 means free, not removal. Read the item back to verify. Stock: use --stock unlimited on variants update or items stock --set unlimited; zero is sold out. Omit stock on update to preserve it. Rename option types or return to one SKU with items update --file, preserving the surviving variant’s regular price, sale and stock. Create a category before assigning it. Photos are a site path `/__media/uploads/<this-slug>/…` or an HTTPS URL already saved on this site. `frontpage payments connect [--no-open]` opens Frontpage then Stripe. Store always uses Add to cart. Use Payments for standalone Pay now and invoices. Service fee is `settings set-checkout-fee`. The cart starts hidden. Product pages are the default: unless they said they do not want product pages, write one `src/pages/products/item.astro` (or shop) with `data-fp-store-product`. If they said no, skip that file and do not bind `href` or `url`. Description is a small markdown subset; product-page bind is `<div data-fp-store-bind="description">`. Every store control carries `data-fp-requires="store"`. Do not bake titles or prices. Full guide: https://frontpage.host/developers/store
@@ -320,7 +320,9 @@ remain errors; they do not become original-file fallback successes.
 
 ## Native Booking
 
-Read [BOOKING.md](./BOOKING.md) before using `frontpage modules booking`. Use native settings, types/forms, members/spaces, availability, reservations and recurring blocks. Do not send new bookings through the old generic module collector. Every write requires a stable request key; updates require the current revision. Consent and private calendar-link entry stay with the human in Workspace → Connections. Ordinary owned connection management and self-hours share the workspace actions; setup requests appear in the editor status bar and overview.
+Appointment types support `startIntervalMinutes:null` (match current appointment length) or 5/10/15/20/30/45/60 through the existing JSON type save. Read BOOKING.md for clock alignment and current-rule rescheduling. Use exact returned availability; do not invent starts.
+
+Read [BOOKING.md](./BOOKING.md) and current `frontpage modules docs booking --site SITE` before using `frontpage modules booking`. Use native settings, types/forms, members/spaces, availability, reservations and recurring blocks. Do not send new bookings through the old generic module collector. Every write requires a stable request key; updates require the current revision. Consent and private calendar-link entry stay with the human in Workspace → Bookings → Connections. Ordinary owned connection management and self-hours share the workspace actions; setup requests appear in the editor status bar and overview. Style and inspect the whole website flow, including review, verification, result and management. The picker, field and panel templates are editable starting points; retain shared availability and verification bindings.
 
 ## Page screenshots
 

package/BOOKING.md

@@ -9,6 +9,7 @@ Start with `frontpage modules booking status --site SITE --json`. Its `providerS
 | Command after `frontpage modules booking` | Purpose |
 | --- | --- |
 | `status`, `get`, `set` | Read setup/status, read settings, save complete settings. |
+| `presentation-get`, `presentation-set` | Read or save the same-site customer management-page path. |
 | `resources list`, `resources save`, `resources catalog` | Read or save internal joined-member availability records and spaces. Creating an existing member resolves its shared record without overwriting hours. |
 | `types list`, `types save`, `types catalog` | Read or save booking types and their customer questions. |
 | `calendar` | Read a bounded calendar range, with optional member/space filters. |
@@ -56,14 +57,40 @@ Calendar consent stays with the person connecting the account. Never put OAuth c
 
 Google and Outlook import busy periods and can receive Frontpage-owned confirmed events when the owner grants write access. Private event details never reach visitors. iCal imports busy times for appointments or stays under either confirmation policy; it does not send bookings back or provide a real-time double-booking guarantee.
 
-Website authors use the platform Booking runtime and `data-fp-booking` containers. The agent controls surrounding HTML and CSS; the service controls forms, availability, validation, email verification and reservation state. Read the Booking module docs and use their exact starter markup. The old `data-fp-form="booking"` collector is retired and rejects submissions. Its old confirmation links cannot confirm appointments or send invites. Historical requests remain in the Forms inbox and `frontpage inbox leads --site SITE`; this cleanup does not convert them into native reservations. Customers review the booking, verify their email and submit; verification creates no inventory hold. A customer management link opens a dedicated page. Viewing a link never accepts, declines or cancels a booking.
+Website authors use the platform Booking runtime and `data-fp-booking` containers. The agent controls markup, layout, colors, fonts and the picker design. The shared runtime binds real availability, per-type questions, validation, required email verification and reservation state. Read `frontpage modules docs booking --site SITE` for the current contract and starter markup. The old `data-fp-form="booking"` collector is retired and rejects submissions. Its old confirmation links cannot confirm appointments or send invites. Historical requests remain in the Forms inbox and `frontpage inbox leads --site SITE`; this cleanup does not convert them into native reservations. Customers review the booking, verify their email and submit; verification creates no inventory hold. A customer management link opens a dedicated page. Viewing a link never accepts, declines or cancels a booking.
 
-Booking presentation uses Store's soft `fp-defaults` layer. Ordinary site CSS and component/utility layers override its appearance. Match the site's tokens, forms and typography. For runtime-generated nodes, use an authored root class with Astro `<style is:global>` or `:global(...)`; generated controls do not inherit the page's scope attribute. Type, time, member, space and choice menus use the shared custom listbox. Do not show their hidden backing selects or build a second selection system. Labels, selected time ranges and time-zone help render separately.
+Booking presentation uses Store's soft `fp-defaults` layer. Ordinary site CSS and component/utility layers override its appearance. Match the site's tokens, forms and typography. For runtime-generated nodes, use an authored root class with Astro `<style is:global>` or `:global(...)`; generated controls do not inherit the page's scope attribute. Appointments use a visual date calendar and available-time buttons by default. Stays use check-in and checkout directly, without a second Stay dropdown. Type, member, space and question menus use the shared custom listbox; do not show their hidden native selects. The default picker is a starting point, not a restriction to two fixed layouts.
 
 Style `.fp-booking-field`, `.fp-booking-label`, `.fp-booking-control-slot`, `.fp-booking-control`, `.fp-booking-help`, `.fp-booking-error`, `.fp-booking-address`, `.fp-booking-field--checkbox` and `.fp-booking-week`. Dropdown parts use `.fp-booking-select`, `-field`, `-trigger`, `-value`, `-caret`, `-menu`, `-list`, `-option`, `.is-active` and `.is-selected`. Optional tokens include `--fp-booking-control-bg/--fp-booking-control-fg`, `--fp-booking-selected-bg/--fp-booking-selected-fg`, `--fp-booking-border`, `--fp-booking-radius`, `--fp-booking-focus` and `--fp-booking-control-height`. All visual defaults remain overridable; hidden/disabled states remain behavior.
 
 An optional `<template data-fp-booking-field-template>` inside the root, outside filled containers, changes field wrapper markup. Its single outer element must contain a `<label data-fp-booking-label>` and `[data-fp-booking-control-slot]`. Optional `[data-fp-booking-label-text]`, `[data-fp-booking-help]` and `[data-fp-booking-error]` preserve authored label content and help/error placement. The runtime fills text, controls, accessible IDs and validation. Preserve those bindings. Inspect every question type, menus, focus/selected/disabled states, loading, empty, errors, review, verification and success on desktop/mobile and with two forms on a page. Build success alone does not verify appearance.
 
+### Visual picker and a fully custom picker
+
+Available-date dots, the selected-time checkmark, selected dates and full stay-range highlights explain what can be booked and what the visitor chose. `.fp-bp-day-face` and `.fp-bp-time-face` keep that state styling separate from broad button rules. Restyle or replace these elements freely; provide clear selection feedback when replacing them. Optional colors are `--fp-booking-available-color`, `--fp-booking-selected-bg/--fp-booking-selected-fg`, `--fp-booking-date-selected-bg/--fp-booking-date-selected-fg` and `--fp-booking-range-bg`. Use real site tokens with valid fallbacks and pair foreground/background colors.
+
+Keep focus, selection, loading, unavailable and error states distinct. `.is-pending` is not `.is-unavailable`; an initial read is not an empty calendar. Keep the selection area visible while loading, and show a real read error with a retry action. The controller starts at the first available day and validates a whole stay against one eligible member/space. Never infer that every interior day of a selected range is available from separate endpoint dates.
+
+For different markup, put `data-fp-booking-picker="custom"` on the root and author its date/availability containers. The runtime preserves those children and mounts no second picker. After `frontpage:booking-ready`, use `FrontpageBooking.getPicker(root)` and `subscribe(render)`; retain the returned unsubscribe function when removing your view. Use `showMonth`, `nextAvailable`, `choose`, `selectArrival`, `selectDeparture`, `selectTime`, `selectResource`, `selectType` and `refresh` for selection and reads. Read the live module docs for their full signatures and safe state fields. Use only returned days/choices; do not calculate slots or recreate scheduling rules. The state excludes customer details, codes, signed receipts and external-event content. Verification and exact submission retries stay with the runtime.
+
+### Review, verification, results and management
+
+Style the complete flow: review, email-code entry, pending/confirmed result, management, date changes and recovery. Shared cards use `.fp-booking-panel`, `.fp-booking-panel-header`, `.fp-booking-panel-icon`, `.fp-booking-panel-content`, `.fp-booking-details`, `.fp-booking-detail`, `.fp-booking-actions`, `.fp-booking-action`, `.fp-booking-notice`, `.fp-booking-verification` and `.fp-booking-code`. Action variants are `--primary`, `--secondary` and `--danger`. `data-fp-booking-panel-state` identifies the screen; `data-fp-booking-step` identifies the form step. These are visual hooks, not ways to change a reservation.
+
+An optional `<template data-fp-booking-panel-template>` inside the root, outside filled containers, owns the panel markup. Its outer element contains `data-fp-booking-panel-title`, `data-fp-booking-panel-content` and `data-fp-booking-panel-actions`; `data-fp-booking-panel-description` is optional. An optional detail template uses `data-fp-booking-detail-template` with label/value hooks `data-fp-booking-detail-label` and `data-fp-booking-detail-value`. Existing field templates also apply to code/recovery fields. Dynamic values bind as text, and incomplete templates fall back to the usable default. Panel colors/radius and actions also accept `--fp-booking-panel-bg`, `--fp-booking-panel-radius` and paired `--fp-booking-action-bg/--fp-booking-action-fg` variables. All are soft defaults.
+
+For a branded management page, author `data-fp-booking-manage`, `data-fp-booking-manage-body`, `data-fp-booking-status` and the same runtime script. Keep its outer page concise and style it with the shared body. Add `noindex` and `no-referrer` metadata. A `data-fp-booking-manage-picker-template` can replace its date-change picker with the same safe controller. Publish the page before changing future email links:
+
+```bash
+frontpage modules booking presentation-get --site SITE --json
+# management.json contains {"managementPath":"/manage-booking"}
+frontpage modules booking presentation-set --site SITE --file management.json --revision REVISION --request-key management-page-20261031 --json
+```
+
+Use the returned presentation revision, not a booking revision. Only an admin can change this path. An empty `managementPath` restores the built-in page. The private link proof stays in the URL fragment and current browser history entry for reload; never put it into a query, custom picker state or public markup.
+
+A customer receipt and a business notification serve different purposes. When their configured recipients share an inbox, it receives both; business subjects say `Business notification`. Customer links manage a reservation; business links require workspace access. Do not suppress one audience, relax required verification or change recipients to reduce test mail.
+
 Private external event details are available only to the connecting human in the workspace Calendar. CLI/agent calendar output remains busy times only; there is no CLI command for private event content.
 
 ## Shared setup and connection operations
@@ -83,3 +110,15 @@ Only consent/private-link entry uses the secure human handoff. Never pass OAuth
 Only the booking type chooses instant confirmation or manual acceptance of customer requests; connecting a calendar never changes that choice. Successful imports revalidate every 15 minutes even when the source advertises a longer cache lifetime. Connection summaries include safe `health` with `status`, `label`, `message` and `usable`. Fresh last-good busy times still apply during refresh or a temporary failure; missing, revoked, disconnected, stale (30 minutes) or uncovered imports keep dependent availability unavailable. Retries keep existing backoff and Retry-After. Imported event titles and private feed URLs never appear in these summaries.
 
 Repeated Connect for your existing Google/Microsoft account returns its current calendar choices without replacing its grant or selections. Use Reconnect on the existing account to renew permissions.
+
+## Appointment start times
+
+Set `startIntervalMinutes` in the existing `types save --file type.json` value. Use `null` for Automatic, which follows the current `durationMinutes`, or `5`, `10`, `15`, `20`, `30`, `45`, `60` for a fixed interval. Omit the field when updating to keep the saved choice; new types default to Automatic.
+
+For a 60-minute appointment that can start on the hour or half hour, keep `durationMinutes:60` and set `startIntervalMinutes:30`. To return to hourly Automatic, send `startIntervalMinutes:null`. Send the complete booking-type value with the current revision and a stable request key:
+
+```bash
+frontpage modules booking types save --id TYPE_ID --revision REVISION --file type.json --request-key UNIQUE_KEY --site SITE --json
+```
+
+Starts align to midnight in the business time zone. Thirty-minute intervals offer :00/:30, even if working hours begin at 9:10. Buffers and calendar conflicts remove starts without moving the grid. New bookings and rescheduling follow the type's current interval; there is no historical 15-minute fallback. Stays keep their existing arrival/departure rules. Read `availability` and use an exact returned slot; direct off-grid requests fail with `slot_unavailable`. The website's design remains fully controlled by its author.

package/dist/modules/booking-contract.generated.json

@@ -58,6 +58,8 @@
     },
     "direct": {
         "status": "status",
+        "presentation-get": "presentation_get",
+        "presentation-set": "presentation_save",
         "get": "settings_get",
         "set": "settings_save",
         "calendar": "calendar",
@@ -65,6 +67,7 @@
         "event-open": "event_open"
     },
     "writes": [
+        "presentation_save",
         "settings_save",
         "resource_save",
         "type_save",
@@ -88,6 +91,8 @@
     ],
     "actions": [
         "status",
+        "presentation_get",
+        "presentation_save",
         "settings_get",
         "settings_save",
         "resources_list",

package/dist/modules/commands.js

@@ -99,6 +99,8 @@ export const MODULE_COMMANDS = [
             "status",
             "get",
             "set --file settings.json --revision N --request-key KEY",
+            "presentation-get",
+            "presentation-set --file presentation.json --revision N --request-key KEY",
             "resources list|save|catalog", "members list", "hours get|set", "activation set", "accounts list|calendars|disconnect", "calendars get|save", "setup list|dismiss", "event-open --file event.json",
             "types list|save|catalog",
             "bookings list|get|create|accept|decline|cancel|reschedule|withdraw",
@@ -121,7 +123,7 @@ export const MODULE_COMMANDS = [
             "Use --file for a complete settings/resource/type/booking/block value. Updates need --id and --revision. First settings save uses --revision 0.",
             "Every write requires --request-key. Reuse its exact body/key after timeout; changed input needs a new key. List responses return nextCursor; pass it as --before with the same list/site and filters. Limit is at most 100. Booking lists accept --search and --status.",
             "Calendar ranges are at most 31 days. --member/--space filter both together. Blocks support --scope this|following|all and the exact --occurrence returned by the calendar.",
-            "Connections connect/refresh return a human workspace link. Calendar consent and private calendar settings stay with the connecting human. No secrets go through the CLI.",
+            "Connections connect returns a human workspace link. Refresh runs the shared rate-limited sync operation; read its result and connection health. Calendar consent, private feed entry and private event details stay with the connecting human. No secrets go through the CLI.",
         ],
     },
     {

package/llms.txt

@@ -9,7 +9,7 @@
 - Fonts: frontpage fonts [--slot] [--query] → exact value → tokens set fonts.<role> → APPLY font-sans|serif|mono|display. Build bundles catalog faces from tokens.ts and/or CSS font-family contexts (not prose). Inline-only without tokens works for catalog faces after rebuild; prefer tokens+utilities for brand roles.
 - Module/extension docs: frontpage modules docs <key> | frontpage extensions docs <key>
 - Search flags: --regex --case-sensitive --whole-word --files-only --context-lines --max-results
-- Modules setup: Store Stripe connect is frontpage payments connect. Payments availability owns pause/restore and retains the shared Stripe account. request-setup remains valid for the editor amber bar. frontpage modules <key> prints that key's CLI usage. Index: https://frontpage.host/developers/modules. Typed config: frontpage modules callbar|forms|booking|signups get|set (forms set needs --instance; confirm emails paid-plan only). Form destinations: frontpage modules forms destinations|connect-destination|attach-destination|detach-destination|remove-destination --yes|request-destination-setup (token = admin; request-destination-setup lights the editor bar; request-setup forms is a no-op; connect does not attach every form). Privyr: paste Incoming Webhook URL (https://www.privyr.com/api/v1/incoming-leads/…), not a token. HubSpot: Development → Keys → Service keys or Legacy apps → Auth → Show token. Pipedrive: profile → Company settings → Personal preferences → API. Docs: https://frontpage.host/developers/modules#forms-destinations. google_reviews: frontpage modules google_reviews connect --place-id | --maps-url (server resolve + seed; no Autocomplete; do not write placeId via config). Also status, list-reviews, hide/show, set-stars, set-sort, set-weight, reset-weights, refresh, disconnect. Docs: https://frontpage.host/developers/modules/google-reviews. Markup: data-fp-google-reviews / data-fp-google-ask + required data-fp-requires="google_reviews". Ask scores: frontpage inbox google_reviews.
+- Modules setup: Store Stripe connect is frontpage payments connect. Payments availability owns pause/restore and retains the shared Stripe account. request-setup remains valid for the editor amber bar. frontpage modules <key> prints that key's CLI usage. Index: https://frontpage.host/developers/modules. Typed config: frontpage modules callbar|forms|signups get|set (forms set needs --instance; confirm emails paid-plan only). Booking uses its native commands and BOOKING.md below. Form destinations: frontpage modules forms destinations|connect-destination|attach-destination|detach-destination|remove-destination --yes|request-destination-setup (token = admin; request-destination-setup lights the editor bar; request-setup forms is a no-op; connect does not attach every form). Privyr: paste Incoming Webhook URL (https://www.privyr.com/api/v1/incoming-leads/…), not a token. HubSpot: Development → Keys → Service keys or Legacy apps → Auth → Show token. Pipedrive: profile → Company settings → Personal preferences → API. Docs: https://frontpage.host/developers/modules#forms-destinations. google_reviews: frontpage modules google_reviews connect --place-id | --maps-url (server resolve + seed; no Autocomplete; do not write placeId via config). Also status, list-reviews, hide/show, set-stars, set-sort, set-weight, reset-weights, refresh, disconnect. Docs: https://frontpage.host/developers/modules/google-reviews. Markup: data-fp-google-reviews / data-fp-google-ask + required data-fp-requires="google_reviews". Ask scores: frontpage inbox google_reviews.
 - Analytics ops: frontpage analytics summary|query|funnel|timeseries|compare|sql (bare analytics = dashboard)
 - Media: frontpage media upload <file> (images/PDF ≤25 MB, video ≤50 MB, SVG/text ≤4 MB); human prints sitePath first — use /__media/uploads/<slug>/… in markup. Text/CSV is inline only (not media library; --json omits full content).
 - Prompt attachments: frontpage prompt "…" --attach <file|/__media/…|https://…> [--asset-url https://…] (same media caps as media upload)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "frontpage-host",
-  "version": "0.3.24",
+  "version": "0.3.26",
   "description": "Frontpage CLI \u2014 manage your site from the terminal",
   "type": "module",
   "bin": {