frontpage-host 0.3.19 → 0.3.20

package/BOOKING.md

@@ -54,7 +54,7 @@ A recurring block update/removal adds `--scope this|following|all` and the exact
 
 Calendar consent stays with the person connecting the account. Never put OAuth credentials or private iCal URLs into CLI files, prompts or agent tools. Follow the returned workspace link and connect there. Each member controls their own calendars; admins can connect shared calendars to spaces. Hard refresh permits two distinct attempts per calendar in a rolling 15 minutes, including failures. The same retry identity does not spend another attempt. The dispatcher runs every five minutes; healthy reconciliation targets 15 minutes, plus scheduling delay and provider backoff.
 
-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 unavailable dates for approval-based stays; it does not send bookings back or provide a real-time double-booking guarantee.
+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. Do not use the old `data-fp-form="booking"` collector for new forms. 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.
 
@@ -66,10 +66,14 @@ All commands above call the same Booking actions as the workspace and internal a
 
 `hours set --file hours.json` takes `{"hours":[{"day":1,"start":"09:00","end":"17:00"}]}` with the current revision/key. The server infers the current user; no target-user flag exists. `activation set --file state.json` takes `{"state":"active"}` (also `disabled` or `archived`). `types save --member-users USER_ID,USER_ID --file type.json` resolves joined members in the shared operation; the complete type value must use `memberResourceIds:[]`. Omit the flag to keep the resource-ID contract. An empty `--member-users ''` clears assigned members.
 
-`connections connect --file setup.json --request-key KEY` takes `{"provider":"google","ownership":"personal"}`. Providers are `google`, `outlook`, `ical`; iCal requires `ownership:"shared"`. Optional `action:"reconnect"` requires the existing `connectionId`. An admin may name `responsibleUserId` to request their joined member's consent; the admin does not receive that member's authorization. Follow the returned workspace URL. The same request appears in the editor status bar and workspace overview. An account-only OAuth return is not complete until calendar selection/binding saves. Failures retain a truthful next step; repeating the same request does not create duplicate notices. `setup dismiss --id REQUEST_ID --revision GENERATION --request-key KEY` hides the request; it does not disconnect or mark connected.
+`connections connect --file setup.json --request-key KEY` takes `{"provider":"google","ownership":"personal"}`. Providers are `google`, `outlook`, `ical`; iCal accepts `ownership:"personal"` for your own member or `ownership:"shared"` for admin-managed spaces. Optional `action:"reconnect"` requires the existing `connectionId`. An admin may name `responsibleUserId` to request their joined member's consent; the admin does not receive that member's authorization. Follow the returned workspace URL. The same request appears in the editor status bar and workspace overview. An account-only OAuth return is not complete until calendar selection/binding saves. Failures retain a truthful next step; repeating the same request does not create duplicate notices. `setup dismiss --id REQUEST_ID --revision GENERATION --request-key KEY` hides the request; it does not disconnect or mark connected.
 
 `accounts calendars --id ACCOUNT_ID` returns owned provider calendar choices. `calendars save --record-kind account --id ACCOUNT_ID --file selection.json --request-key KEY` selects one, using `calendarId`, `label`, `resourceIds`, `receivesBookings` and `ownership`. Editing uses `--record-kind calendar --id CONNECTION_ID --account ACCOUNT_ID --revision N`. Use `--setup REQUEST_ID` when completing a returned connection request. Provider identity and consent remain protected by the server.
 
-`connections save` updates an iCal connection's label/resourceIds with the current revision. `connections refresh --record-kind feed|calendar --id CONNECTION_ID --revision N --request-key KEY` executes the server-limited refresh, not a link-only request. Disconnect uses the same record kind/ID/revision plus `--file disconnect.json` containing `{"confirmed":true,"removeBinding":false}`. `accounts disconnect` uses the account ID/revision and the same explicit value. `removeBinding:false` keeps dependent availability unavailable until reconnected; `true` removes that dependency. Existing bookings remain. Never infer that requesting refresh means sync succeeded.
+`connections save` updates an iCal connection's label/resourceIds with the current revision. `connections refresh --record-kind feed|calendar --id CONNECTION_ID --revision N --request-key KEY` executes the server-limited refresh, not a link-only request. Disconnect uses the same record kind/ID/revision plus `--file disconnect.json` containing `{"confirmed":true,"removeBinding":true}`. `accounts disconnect` uses the account ID/revision and the same explicit value. Normal disconnect uses `true` to stop checking that source. Explicit `removeBinding:false` keeps dependent availability unavailable until reconnected. Existing bookings remain. Never infer that requesting refresh means sync succeeded.
 
 Only consent/private-link entry uses the secure human handoff. Never pass OAuth codes/tokens or private export URLs through files, CLI arguments or chat. `event-open` takes `{"detailId":"OPAQUE_ID_FROM_OWNER_CALENDAR"}`; opening its URL still requires the connecting human. All ordinary reads preserve role redaction; all mutations preserve stable keys, revisions and the existing two-refreshes-per-15-minutes server allowance.
+
+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.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "frontpage-host",
-  "version": "0.3.19",
-  "description": "Frontpage CLI \u2014 manage your site from the terminal",
+  "version": "0.3.20",
+  "description": "Frontpage CLI — manage your site from the terminal",
   "type": "module",
   "bin": {
     "frontpage": "dist/bin.js"