slotlock 0.8.0 → 0.10.0

package/CHANGELOG.md

@@ -3,6 +3,548 @@
 All notable changes follow [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) and semantic
 versioning.
 
+## 0.10.0 - 2026-11-11
+
+This release gives a workspace its people and an audit trail. It brings six roles read from the
+database on every request, team workspaces with invitations, verified domains that let colleagues
+find and ask to join their team, single sign-on and SCIM provisioning through each team's own
+identity provider, sign-out everywhere and a hash-chained audit log, and lets a
+member be limited to locations or groups (RFC 0004 D1). The change history
+becomes append-only and is kept by plan (D2). A person's data can be exported or erased, and a whole
+tenant exported (D3), from the API, the command line and the dashboard's new Privacy page. It closes
+the four questions the security review left open, and fixes what a review of RFC 0004's T2 changes
+found; that review was not the independent human review GOVERNANCE.md requires. Read the upgrade
+notes first.
+
+### Upgrade notes
+
+- **Run `slotlock migrate` before serving this release, on every server at once.**
+  - The schema becomes version 5, which a 0.9 server refuses (`schema_newer`), so a server still on
+    0.9 stops serving once the database is migrated.
+  - It adds eight tables (`audit_events`, `dashboard_people`, `dashboard_sessions`, `workspaces`,
+    `workspace_memberships`, `workspace_invitations`, `tenant_exports`, `tenant_export_parts`), new
+    columns (among them `cutoff_anchor` on bookings and events, and the audit log's chain) and 39
+    functions.
+  - Verified domains add three more tables (`workspace_domains`, `workspace_join_requests`,
+    `workspace_join_blocks`) and single sign-on five (`sso_connections`, `sso_identities`,
+    `sso_role_mappings`, `dashboard_session_sso`, `sso_bypasses`) and SCIM four (`scim_tokens`,
+    `scim_users`, `scim_groups`, `scim_group_members`), with their functions, unused until turned on.
+  - It grants the serving role what this release needs; a library user runs
+    `grantApplicationRole` again.
+- **The change history can no longer be edited by the serving role.** It may only add to
+  `slotlock.outbox` and read it. Maintenance prunes it through `slotlock.prune_changes`, so code of
+  your own that deleted or changed change rows directly must stop.
+- **Everyone signs in again once.** Sessions from before this release carry no session epoch and no
+  session record, so the dashboard asks for a new sign-in.
+- **An organization's members become Developers.** They keep read-only and read-write keys of
+  their own, but no longer create Full-access keys, add webhooks or revoke others' keys. Keys they
+  made before keep working: review the Full-access keys your organization's members created.
+- **Set each resource's hold price before upgrading if its agent holds take payment.** An agent's
+  hold now takes its price from the resource's `holdPrice` booking rule (`hold_price`).
+  - An agent that names a `payment` the rule does not have is refused `payment_price_mismatch`.
+    That includes any payment on a resource without a price.
+  - An agent books a priced resource only from a paid hold (`payment_required`).
+- **A key's caps count its pending approvals.** An agent close to its `max_holds` or
+  `max_held_hours` may be refused sooner (`hold_limit_reached`, `held_time_limit_reached`).
+- **`@slotlock/sync`:** connect calendars connected before this release again (their seals are
+  now bound to their tenant). A library user who reads iCalendar URLs must pass the guarded fetch.
+- **`@slotlock/payments-stripe` with ISK or UGX:** create PaymentIntents for
+  `stripeAmount(amountMinor, currency)`. A payment read back is converted with `isoMinorUnits`, and
+  one that is not a whole ISO amount is refused.
+- **New and off until set:**
+  - team workspaces (`SLOTLOCK_DASHBOARD_TEAM_WORKSPACES=on`);
+  - invitations by email (`SLOTLOCK_INVITATION_EMAIL`, `SLOTLOCK_INVITATION_EMAIL_KEY`,
+    `SLOTLOCK_INVITATION_EMAIL_FROM`);
+  - verified domains, with team workspaces (`SLOTLOCK_VERIFIED_DOMAINS=on`; the server's maintenance
+    checks each domain daily, so set it on the server too);
+  - single sign-on through each team's provider, with verified domains (`SLOTLOCK_TEAM_SSO=on` and
+    `SLOTLOCK_SSO_SECRET`, on whichever serves the dashboard: a server that does not never reads
+    them);
+  - SCIM provisioning from each team's provider, with verified domains (`SLOTLOCK_TEAM_SCIM=on`, on
+    whichever serves the dashboard: its `/scim/v2` is where providers call). On Workers, add the
+    `SLOTLOCK_SCIM_RATE_LIMIT` rate limiting binding, which counts providers' calls apart from each
+    client's dashboard budget; without it they share that budget, and the Worker logs a warning.
+
+### Added
+
+- **slotlock.pylota.io, for search engines** ([RFC 0005](docs/rfc/0005-search.md)). A page per
+  search intent: `/pricing/`, `/mcp-server/`, `/booking-api/`, `/open-source/`, `/about/`,
+  `/use-cases/` with eight industries, `/compare/` (a bookings table of your own, Cal.com, Cronofy,
+  Nylas and the Google Calendar API, each claim sourced and dated) and `/blog/` with four articles
+  and an RSS feed, each with a Markdown twin listed in `llms.txt`. Every page carries a search
+  title and description, an Open Graph image and JSON-LD (Organization, SoftwareApplication with
+  the plans' prices, BreadcrumbList, TechArticle, BlogPosting); the sitemap dates each page from
+  git; Markdown twins name their HTML page as canonical and agent files are `noindex`; the 404 page
+  is `noindex`. `npm run check:seo` fails the site build on a missing canonical, image or sitemap
+  entry, and `scripts/check-live-seo.sh` checks the live hosts after each deploy. The site allows
+  Cloudflare Web Analytics, which sets no cookie (PRIVACY.md).
+- **Roles in the dashboard.** What each person may do in a workspace is one of six roles (Owner,
+  Admin, Developer, Member, Viewer, Billing), read from the database on every request
+  (`slotlock.workspace_memberships`, `createSlotlockDashboardWorkspaces`), so a role changed or a
+  membership ended applies at the next request. Every dashboard route needs a capability
+  (`workspace-roles.ts`); one with none is refused. A person is the Owner of their own workspace;
+  in an organization's, GitHub's owners are its Owners and its members Developers.
+- **Confirm it's you.** Full-access keys, webhooks, billing and the assistant's model need a
+  sign-in in the last 15 minutes; past it, the dashboard asks the person to sign in again and
+  returns to the page.
+- **Sign out everywhere** (Settings, Account) ends every session of the person, on every device
+  (a per-person session epoch, `slotlock.dashboard_people`).
+- **An audit log** (`slotlock.audit_events`, 180 days): key, webhook, billing, assistant-model,
+  contact and session changes, and every refusal, with where they came from. The serving role may
+  only add to it and read it (`SLOTLOCK_APPEND_ONLY_TABLES`); maintenance prunes it.
+- **Team workspaces** (`SLOTLOCK_DASHBOARD_TEAM_WORKSPACES=on`): anyone signed in creates a
+  workspace of its own (`team:<id>`) on the Teams page, invites people to it by email with a role,
+  and changes their roles, removes them (revoking the keys they made, or keeping them) or leaves on
+  Settings, Members. An invitation's link works once, for seven days, only for the address it was
+  sent to (verified by Google, or by GitHub when the person confirms it), and opening it consumes
+  nothing. A team always keeps an Owner; nobody gives a role above their own. `serve` takes a
+  team's keys only with the setting on and while the team exists. Where plans apply, each person
+  creates one team on Free, which holds up to 3 people. `SlotlockInvitationSender` sends the
+  links by email where a deployment has one; otherwise the person inviting copies it.
+- Google's `email_verified` is accepted as the string `"true"` as well as `true`.
+- **The audit log in the dashboard** (Settings, Audit log): Owners and Admins read who did what,
+  refused or done, from where, 50 events a page, filtered by action, and export it as CSV or JSON on
+  the Team plan. Each tenant's events form a hash chain (`chain_index`, `prev_hash`, `hash`), with
+  the time stamped by the database: an event changed, removed or taken off the chain in the middle
+  shows where (`slotlock.verify_audit_chain`, `verifyAuditChain`); exports carry each hash, to keep
+  as proof elsewhere. Retention removes only the start of the chain.
+- **Where you're signed in** (Settings, Account): each session's browser, address, start and last
+  use, and signing another device out at its next request (`slotlock.dashboard_sessions`, a digest
+  of each session's id; `SlotlockDashboardSessions`). A session passes only while its record does,
+  so sessions from before this release sign in once more, and a person's 50 most recent are kept.
+- **Team for team workspaces**: a team's Owners and Billing managers buy the Team plan on Usage, as
+  an organization's do.
+- **Deleting a team** (Settings, Team): an Owner types its handle; its keys stop (on every server
+  within 30 seconds), every member sees the date, and maintenance erases it seven days later unless
+  an Owner keeps it (`slotlock.schedule_team_deletion`, `cancel_team_deletion`,
+  `erase_deleted_teams`). Refused while the team has a subscription, and never erased while it has
+  one.
+- **Invitations by email**: `SLOTLOCK_INVITATION_EMAIL` (`resend` or `postmark`), with
+  `SLOTLOCK_INVITATION_EMAIL_KEY` and `SLOTLOCK_INVITATION_EMAIL_FROM`
+  (`createSlotlockInvitationEmailSender`). Each person is held to 50 invitations a day across their
+  teams, as each team is; sending one again counts as a send. One address is sent at most 5 a day
+  from every team together (`recipient_limit`), so open sign-up cannot fill an inbox. Requests to
+  the provider carry a User-Agent (Resend refuses one without), and a refusal is logged with the
+  provider's status (`SlotlockInvitationEmailError`), never the address.
+- **Requests about one person** (RFC 0004 D3). `POST /v1/subjects/export` (`exportSubject`,
+  `slotlock subject export`) lists what the tenant keeps about one person, found by exactly one of
+  `email`, `holder`, `contact` or `reference`: the rows that name them, by table
+  (`SLOTLOCK_SUBJECT_TABLES`). `POST /v1/subjects/erase` (`eraseSubject`,
+  `slotlock subject erase`) takes them out in one transaction: their contacts, attendee entries and
+  waitlist entries are deleted, their email leaves events' attendee and organizer lists and
+  approvals' requests, and their holder and booking references become one `erased-<32 hex>` name
+  in holds, bookings, cancelled bookings, events, approvals and the change history. Bookings stay
+  as time taken; nothing goes on the feed; the audit log records `subject.erased` without the
+  person.
+- **Privacy in the dashboard** (Settings, Privacy; Owners and Admins, with a sign-in in the last 15
+  minutes: the new capability `privacy.manage`). Export the workspace and download it as JSON
+  lines; find one person by email, holder, contact or booking reference, see how many rows of each
+  table name them, download them as JSON, or erase them once confirmed. Every form posts, so the
+  person is never in an address; the audit log records `export.created`, `export.downloaded`,
+  `subject.exported` and `subject.erased` without them.
+- **People limited to locations or groups** (RFC 0004 D1). On a team's Members page an Owner, or an
+  Admin not limited themselves, limits anyone but an Owner to up to 20 locations and 20 groups
+  (new column `workspace_memberships.resource_scope`; definers `slotlock.member_scope`,
+  `slotlock.member_scopes` and `slotlock.set_member_scope`). From their next request every
+  transaction the dashboard runs for them carries that resource scope (`dashboard-scope.ts`), so
+  RFC 0003 G6's policies keep it to those resources; Approvals shows and decides only what asks
+  for theirs alone, and their assistant is limited the same way. They keep only reading, the desk
+  and the assistant (`SLOTLOCK_SCOPED_CAPABILITIES`, `SLOTLOCK_SCOPED_DASHBOARD_PAGES`,
+  `SLOTLOCK_SCOPED_DASHBOARD_POSTS`); the keys they created are revoked unless kept. Audited as
+  `member.scope_changed`. Made an Owner by any path, a person's limit is cleared (a trigger on
+  `workspace_memberships`), so it does not return if they stop being one. Custom resource adapters
+  declare `keepsToScope`; without it a limited person reaches only their own account. Rerun
+  `slotlock migrate` and the role grants.
+- **Exporting a whole tenant** (RFC 0004 D3). `POST /v1/tenant/exports` asks for a copy of
+  everything the tenant keeps, read through one cursor so at one moment; the server builds it after
+  answering into parts of one table's rows (new tables `tenant_exports` and `tenant_export_parts`),
+  read with `GET /v1/tenant/exports/{export_id}/parts/{part}` and kept 24 hours. Secrets stay out;
+  derived, internal and per-member tables are left out (`SLOTLOCK_TENANT_EXPORT_TABLES`,
+  `SLOTLOCK_TENANT_EXPORT_LEFT_OUT`). One at a time, five kept, 512 MB at most; maintenance deletes
+  expired exports and builds any left pending. `slotlock tenant export [--out <dir>]` reads the same
+  snapshot straight to NDJSON, storing nothing. Recorded in the audit log (`export.created`).
+- **The audit log over the API and the command line** (RFC 0004 D2): `GET /v1/audit` (on the Team
+  plan where plans apply, as the dashboard's export) and `GET /v1/audit/verify`;
+  `slotlock audit export` and `slotlock audit verify` (exit 1 when the chain breaks).
+- **Verified domains** (`SLOTLOCK_VERIFIED_DOMAINS=on`, with team workspaces): a team's Owners add
+  their organization's domain on Settings, Identity and publish a TXT record
+  (`_slotlock-challenge.<domain>`, a 128-bit token per claim). The server's maintenance looks it up
+  daily over DNS-over-HTTPS, Cloudflare's cross-checked by Google's (`SLOTLOCK_DNS_RESOLVER=system`
+  uses the server's own resolver); a record gone on two checks a day apart makes the domain lapse
+  in 14 days, with a new token, so a domain that changes hands cannot be revived from DNS history.
+  One team holds a domain at a time; public suffixes, special-use names and consumer mail domains
+  are refused (the Public Suffix List through `tldts`, pinned). People whose verified address is at
+  a team's domain find it on the Teams page and ask to join, approved by an Owner or Admin as
+  Viewer, Member or Developer; an Owner may let Google Workspace accounts of the domain join at once
+  as a Viewer (an address verified once by Google or GitHub, or one the team removed or declined,
+  only asks), or turn joining off. A record behind a CNAME does not count, and 14 days of resolver
+  errors lapse a domain too.
+- **Single sign-on through each team's own identity provider** (`SLOTLOCK_TEAM_SSO=on`, with
+  verified domains, and `SLOTLOCK_SSO_SECRET`): Okta, Microsoft Entra ID (one tenant), Google
+  Workspace or any OpenID Connect provider, set up, tested and turned on by the team's Owners on
+  Settings, Identity. ID tokens are checked with WebCrypto on both runtimes (`verifySlotlockIdToken`:
+  RS256, PS256 or ES256, never none or HMAC; RSA of 2048 bits or more; exact issuer; audience and
+  azp; time with 60 seconds' skew; nonce), keys cached per JWKS URL, an Owner's URLs fetched as
+  hostile (https on public names, no redirects, 5 seconds, 256 KB), client secrets sealed with
+  AES-256-GCM. Identities are the provider's subject, never an email; a sign-in through a provider
+  alone makes a person with no workspace of their own, scoped to the team (no other team, nor the
+  person's other sessions); members link their GitHub or Google person by signing in through it,
+  with a work account at the verified domain, while signed in. Members at the verified domains
+  join at their first sign-in (on by default, as Viewer), groups map to roles (never Owner, and
+  nobody who signs in only through a provider is made one), and the team may require single
+  sign-on, with an Owner's audited one-hour bypass. Turning a connection off or changing it ends the
+  sessions and proofs it gave; deleting it, or erasing the team, erases the people who signed in
+  only through it. Google sign-in now goes through the same verifier, which allows 60 seconds of
+  clock skew.
+- **SCIM 2.0 provisioning for each team** (`SLOTLOCK_TEAM_SCIM=on`, with verified domains): the
+  team's identity provider adds, deactivates and groups its people at the dashboard's
+  `/scim/v2/<team id>` (RFC 7643/7644: Users and Groups with GET, POST, PUT, PATCH and DELETE,
+  `eq` filters, paging, discovery), with bearer tokens an Owner makes on Settings, Identity (two at
+  a time, kept as SHA-256), and Okta's and Entra's requests read as they send them. Users at the
+  verified domains only; one becomes a member on signing in with a Google Workspace account of the
+  domain or through the team's single sign-on. Deactivation ends that membership at the next
+  request and, as the Owner chose when turning SCIM on, revokes the person's keys; reactivation
+  needs a new sign-in. Groups give roles (`slotlock-role-<role>`, or as an Owner maps them; never
+  Owner), and the directory never changes an Owner. On Workers, the `SLOTLOCK_SCIM_RATE_LIMIT`
+  binding counts providers' calls per address apart from the dashboard's per-client budget: a
+  provider calls from addresses its other customers share. The dashboard's `scim` option;
+  `workspaces.scim`.
+  An Owner may also hold invitations to the team's verified domains. New capability
+  `identity.manage` (Owners, fresh sign-in); `createSlotlockWorkspaceDomains`,
+  `runSlotlockDomainChecks`, `normalizeSlotlockDomain`, `createSlotlockDohResolver`.
+
+### Changed
+
+- **The change history cannot be edited** (RFC 0004 D2). The serving role may only add changes
+  and read them (`SLOTLOCK_APPEND_ONLY_TABLES` includes `outbox`): pruning goes through the
+  definer `slotlock.prune_changes`, and the one edit is taking a person out
+  (`slotlock.erase_subject_changes`, which writes nothing but an `erased-` name). Both act only for
+  the tenant the caller acts in. Rerun `slotlock migrate` and the role grants.
+- **History is kept by plan**: 30 days on Free, 90 on Developer and 400 on Team
+  (`SLOTLOCK_CHANGE_RETENTION_BY_PLAN`), or `retentionDays` if longer; a tenant with no plan keeps
+  `retentionDays`. The workspace audit log keeps 180 days, or 400 on Team. The privacy notice says
+  so, and how an account holder answers a person's request themselves.
+- **The privacy notice lists contacts, busy time from other calendars, and payments for holds**,
+  with how long each is kept: a contact until it is deleted; busy time 30 days after it ends; a
+  payment record until its resource or account goes. It says hosted Slotlock sends nothing to
+  contacts, holds no calendar or payment provider's token, and that the integrations that do run
+  under the tenant's own agreements. Erasure lists all three.
+- **An organization's members no longer have every power.** Before, any member could create a
+  Full-access key (which reaches contacts, webhooks, history and erasure), revoke anyone's key and
+  add webhooks. Members are now Developers: read-only and read-write keys of their own, resources,
+  rules and hours. Review the Full-access keys your organization's members created.
+
+### Security
+
+The four questions the review left open, now closed:
+
+- **Moving a booking no longer avoids a late cancellation.** Where the reschedule cutoff was
+  shorter than the cancel cutoff, a booking could be moved far ahead and then cancelled free. A
+  booking or event moved when cancelling it would already be late now keeps the start it had
+  (`cutoff_anchor`), and a later cancellation is judged, and its fee recorded, from it.
+- **An agent no longer sets its own hold price.** The new booking rule `holdPrice` (`hold_price`)
+  is the tenant's price: an agent's hold of the resource waits for it whatever the agent asks, a
+  `payment` it names that is not the price is refused (`payment_price_mismatch`), and an agent
+  books the resource only from a paid hold. Without a price, an agent names none.
+- **A key's caps count its pending approvals.** The time an agent's approvals hold while a person
+  decides counts against its key's `max_holds` and `max_held_hours`, so asking for approval never
+  holds more than the agent could hold itself (`hold_limit_reached`, `held_time_limit_reached`).
+- **ISK and UGX in `@slotlock/payments-stripe`.** Stripe counts them in hundredths ISO 4217 has
+  not, so 1 krona paid read as 100 against a hold's price. The adapter converts
+  (`isoMinorUnits`), refuses an amount that is not whole, and `stripeAmount` gives the
+  PaymentIntent's.
+
+From a review of RFC 0004's T2 changes, in five areas, each finding reproduced against a real
+database first. This was not a human review, so it does not count as the independent review
+GOVERNANCE.md requires.
+
+- **Approvals could be got round by an update.** An agent's update that kept its event's time and
+  resource skipped every policy. A transparent event made opaque, or a granted booking given a
+  recurrence rule, booked that time unasked. A granted approval's idempotency key also booked any
+  other bundle. Updates are now judged by the time they would add, and a key answers only the
+  request a person approved.
+- **A 129-byte holiday calendar could hang the server.** A daily rule on a day that never comes held
+  it for every tenant, again after each restart once subscribed. A 1 MB calendar held it for a
+  minute. Such rules are refused, a calendar's work is bounded, and a subscription due for import
+  is put off as it is taken. A subscription named after its URL shows the host only.
+- **Payments a hold never used could be kept.** These were not refunded: a late payment for a
+  hold already cleared away, a refund Stripe did not make, and a paid hold that expired or was let go
+  before its booking. Slotlock now records whether a paid hold was booked. It answers the payment for
+  one that ended unbooked with `hold_ended`, and says so on the feed (`payment_unapplied`).
+  `@slotlock/payments-stripe` names the tenant on each PaymentIntent and refunds each such payment,
+  retrying a refund that failed. It logs at level error each payment it keeps.
+- **An agent could let a booking go past its cutoffs another way:** by making it transparent, or a
+  series. Both are now refused as the cancel or move they are.
+- **Busy time from calendars missed a composite's parts, and two booking paths.** A hall's busy time
+  is now counted on its rooms and a room's on the hall. A hold's confirmation and a series' roll
+  refuse it too. Busy time that ended a month ago goes.
+- **A `@slotlock/sync` connect link could be reused** by anyone who had it for 30 minutes. A link is
+  now followed once, and its flow is finished only in the browser that followed it.
+- **Reminders already sent were sent again when a reminder list changed.** Each sent reminder was
+  kept by its place in the list, so adding, removing or reordering one sent the earlier ones twice
+  (an SMS or email through `@slotlock/notify`). They are now kept by when they were due: a changed
+  list sends only what is new, and a moved booking is reminded again as before.
+- **`@slotlock/sync`, hardened further:**
+  - One calendar that refuses for good (read only, access revoked) no longer stops write-back for
+    the whole tenant: it is that mapping's failure (`failedMappings`), and read-only calendars are
+    not offered for write-back.
+  - A connection disconnected during a pass no longer comes back with its tokens, nor records busy
+    time.
+  - Seals are bound to their tenant, and a mapping uses only its own tenant's connection.
+    Connections made before this must be connected again.
+  - iCalendar feeds are read on core's worker threads, with a deadline.
+  - Google connections hold only the scopes they asked for, and one missing a scope is refused.
+  - A library user who reads iCalendar URLs must pass the guarded fetch.
+
+## 0.9.1 - 2026-11-11
+
+### Fixed
+
+- **The dashboard asks an owner to upgrade where a plan stops them.** A workspace at a limit of its
+  plan (10 of 10 resources on Free, say) saw only a red bar: Usage and the Overview now say
+  "On Free, you have 10 of 10 resources: adding another is refused", with **Upgrade**, and the
+  Overview's plan card offers it too. The same holds for the plan a workspace is about to move to.
+  An add refused at a limit (a resource, a key, a webhook) links to the upgrade, or to Usage for a
+  workspace that pays. A quota at 80% offers the upgrade as well as at 100%. A member is told an
+  owner can upgrade, and where the deployment neither sells nor arranges plans, no upgrade is named.
+
+## 0.9.0 - 2026-11-11
+
+### Added
+
+- Each hold's payment is kept apart from the hold (new table `hold_payments`, under RLS, erased with
+  the tenant), so `slotlock_mark_hold_paid` with the same payment answers `replayed: true` however
+  the hold ended: confirmed in place or booked as an event. Before, a confirmed hold answered
+  `404 hold_not_found`, which `@slotlock/payments-stripe` with `refundRefused` refunded: a customer
+  reloading the return page, or Stripe redelivering a webhook, got a booked time refunded (found by
+  the security audit). The adapter now refunds only `hold_expired`, `payment_conflict` and
+  `payment_amount_mismatch`.
+- Three integration packages in `packages/` (RFC 0004 P3), each its own process with its own
+  schema and secrets, talking to Slotlock over its API:
+  - `@slotlock/sync` (C1, C4, T2): busy time from Google freeBusy, Microsoft getSchedule and
+    iCalendar URLs, recorded as each source's busy time; confirmed bookings written back to Google
+    and Microsoft calendars, times only. OAuth with PKCE, then a signed page where the tenant's person
+    chooses which calendar blocks which resource; tokens, URLs and keys sealed with AES-256-GCM. A
+    booking changed in the calendar is reported on the feed (`coverage.conflict`), never applied. A
+    provider's 429 or 503 is retried when it says, else with backoff; a feed cursor that expired
+    while the sync was down is recovered by reconciling each calendar with the bookings as they are.
+  - `@slotlock/notify` (C2): confirmations, moves, cancellations and reminders by Postmark,
+    Resend or SES, and Twilio SMS and WhatsApp, each send recorded under its key (change id,
+    channel, recipient) before it is made. Consent per channel; test tenants go to a capture inbox.
+    Recipients are kept only as digests, except an event's attendees, kept sealed until a day after
+    it ends so a cancellation reaches them.
+  - `@slotlock/payments-stripe` (C3, T2): a PaymentIntent read back from the tenant's own Stripe
+    account marks its hold paid, with the amount received; a payment for an expired hold is refused
+    and, if asked, refunded.
+  - Each runs as its own process (`slotlock-sync`, `slotlock-notify`, `slotlock-payments-stripe`,
+    each with `migrate` and `serve`), and `packages/integrations.Dockerfile` builds one image with
+    all three.
+- What integrations build on (RFC 0004 P3, D1's recommendation: core keeps primitives, packages
+  outside it send and sync). Feed type `reminder.due`: maintenance puts each event reminder on the
+  feed once, when it comes due (within the last day, before the event starts), and again if the
+  occurrence moves; `reminders_due` in its answer. A change's `id` is the key a sender sends it
+  once by. Events take `notify` (`slotlock_create_event`'s `notify: false`): no reminders, and a
+  sender tells no one. Reservations take `reminder_minutes` (up to five, minutes before the start),
+  each said once as `reminder.due` for the contact the reservation names, and again if it moves.
+- Contacts (P3, T2): new table `contacts`, the people a booking may name to be told about it, by
+  the tenant's own reference, with email, phone and WhatsApp numbers (E.164), locale and consent
+  per channel. `slotlock_put_contact`, `slotlock_get_contact`, `slotlock_delete_contact`
+  (`/v1/contacts/{contact_ref}`); deleting one also takes its reference off every booking. At most
+  100,000 a tenant. `slotlock_list_contacts` (`GET /v1/contacts`) lists them a page at a time, and
+  each answers `consent_at`: when each channel's answer was given, kept while it stands. The
+  dashboard's Contacts page lists them and forgets one, for an erasure request. Reservations take
+  `contact_ref` and `notify`, both on the feed with each change; neither is ever the person.
+- Holds that wait for payment (RFC 0004 C3, T2): `payment_required` on `slotlock_acquire_hold`
+  (time to live at most 30 minutes). Confirming one answers `409 payment_required` until
+  `slotlock_mark_hold_paid` (`POST /v1/holds/{hold_id}/paid`) records the payment's reference at
+  the integrator's processor: the same reference again answers the same hold, another
+  `payment_conflict`, an expired hold `hold_expired`. New feed type `hold.paid`. Slotlock records
+  payment state and never moves money. A hold may name what the payment must be (`payment`:
+  `amount_minor` and `currency`); `slotlock_mark_hold_paid` then takes what was `received`, and
+  less, or another currency, is `409 payment_amount_mismatch`. Holds answer `payment_amount` and
+  `paid_amount`. Agents' `slotlock_hold_slots` takes `payment_required` and `payment` too.
+- Busy time from calendars that give no events (RFC 0004 C1, T2): `slotlock_put_source_busy`
+  (`PUT /v1/resources/{resource_id}/coverage/{source}/busy`) records a source's coverage of a
+  window and the busy time in it (at most 5,000 intervals, merged), replacing what it said of that
+  window. New table `source_busy`. Every read counts it (free/busy, a resource's busy time,
+  searches and waitlist offers), and every booking Slotlock makes is refused
+  over it (`overlap`). A confirmed booking the source newly reports busy time over is left alone
+  and reported once as `coverage.conflict` (named by `source_id`, never the source). Retiring the
+  source forgets its busy time. `slotlock_report_coverage_conflict`
+  (`POST /v1/resources/{resource_id}/coverage/{source}/conflicts`) lets a calendar sync report a
+  booking it wrote that was moved (`changed_in_calendar`) or removed (`removed_from_calendar`) in
+  the calendar, as `coverage.conflict` with the booking left as it is.
+- Hours that inherit (RFC 0004 B2). The tenant and each location store weekly hours
+  (`setTenantAvailability`, the new `setLocationAvailability`; `PUT /v1/availability`,
+  `PUT /v1/locations/{location}/availability`, `GET /v1/availability`). A resource without its own
+  uses its location's (the nearest up the chain), then the tenant's, then the server's, and a
+  resource added later inherits too. Resources carry `inherited_availability`. The dashboard has
+  "Your hours" and an Hours page for each location; the CLI has `hours set --location`.
+- Closures and special days (RFC 0004 B1, T2): new table `availability_exceptions`, for the tenant,
+  a location (and everything inside it) or one resource. Each replaces whole local days, read in
+  each resource's time zone: `closed` empties them, `open` gives them 1-4 windows of their own.
+  The nearest scope wins on a day. One evaluator (`openWindows`) serves search, pool availability,
+  approval policies' `outside_hours`, and writes under `enforceHours`. At most 5,000 a tenant
+  (`availability_exceptions_limit_reached`). API: list, create and delete under
+  `/v1/availability/exceptions`. Dashboard: a Closures page. CLI: `slotlock closures
+  list|add|delete|import`.
+- Holiday calendars (B1): `slotlock_import_holidays` (`POST /v1/availability/holidays`) and
+  `closures import` close the days an iCalendar file's all-day events cover, recurring ones
+  expanded over a bounded span. `serve` fetches an `https` URL through the guarded fetch (no
+  private addresses, 1 MB, 10 seconds); the store-backed application backend fetches none unless
+  given `holidayFetch`. Each import is a calendar (new table `holiday_calendars`, under RLS, erased
+  with the tenant), kept by name where it applies: its `name`, else its own `X-WR-CALNAME`, else
+  the URL. Importing it again updates its closures and removes those it no longer names in the
+  span (`removed`), so a holiday a calendar dropped goes too; a closure imported before calendars
+  were kept becomes the calendar's that names it. With `subscribe`, the URL is kept and maintenance
+  imports it again every 30 days (`holidayFetch` on `maintainSlotlockTenant` and the scheduler;
+  `serve` and `slotlock maintain` pass the guarded fetch), a failed import keeping its closures,
+  noting why (`last_error`) and trying again a day later. `slotlock_list_holiday_calendars`
+  (`GET /v1/availability/holiday-calendars`) and `slotlock_delete_holiday_calendar`
+  (`DELETE …/{calendar_id}`, its closures with it); closures answer `calendar_id`; at most 50
+  calendars a tenant. The dashboard's Closures page takes a file upload (the form was limited to
+  8 KB, too small for most calendars, and now takes 1 MB), a paste or, where the server fetches
+  them (`serve`, Cloud), an address with "Import it again every 30 days", and lists the calendars
+  with their next import, a failed one's error, and Delete. `closures import` names the calendar
+  with `--label`.
+- Durations and hires (RFC 0004 B3). Booking rules gain `minDurationMinutes`, `maxDurationMinutes`,
+  `allowedDurations` and `defaultDurationMinutes`, and for a booking from one local day to another
+  `pickupTimes` and `returnTimes` (it starts and ends in them, and under `enforceHours` needs only
+  its start and end inside the hours). `turnaroundMinutes` goes up to a week. Refusals:
+  `booking_rule_min_duration`, `booking_rule_max_duration`, `booking_rule_duration_not_allowed`,
+  `booking_rule_pickup_time`, `booking_rule_return_time`. Searches offer only allowed lengths, and
+  take `defaultDurationMinutes` when they name none (`400 duration_required` otherwise).
+  `hoursApply` (`hours_apply`) says how the hours hold a hire: `whole` (all of it) or `ends` (its
+  start and end only), by default `ends` with pick-up or return times, else `whole`. Writes follow
+  it under `enforceHours`; `slotlock_find_available_slots` and `slotlock_find_next_available`
+  follow it always, so with `ends` they offer slots from one day to another, judged as the write
+  would be, and `slotlock_find_available_ranges` judges ranges as the write would where hours are
+  enforced. A pick-up or return refusal comes with alternatives, as other refusals of a time do.
+- Zone rule changes reach everything (RFC 0004 B9): `followZoneRules` also re-checks a recurring
+  series' occurrences to come (each kept with its wall time, reported once as
+  `event.timezone_shifted` with its `recurrence_id`; with `move`, the whole series moves at its
+  next revision in one transaction, each occurrence and its booking keeping its `recurrence_id`,
+  but only where the server's zone rules agree with the database's, else each is reported with
+  `reason: "rules_disagree"`; something in the way keeps its times, said once as
+  `event.timezone_conflict`), and reservations written with the new
+  optional `local_start` (`localStart`), reported as `reservation.timezone_shifted` or, with
+  `move`, moved at the next revision (`reservation.timezone_conflict` when something is in the
+  way). A `local_start` that does not name the reservation's start is `400 invalid_local_start`.
+- Holds across resources (RFC 0004 B7, T2): `slotlock_hold_together` (`POST /v1/slot-holds/together`),
+  the 19th agent tool, holds one time on 2-20 resources all or nothing, as one group whose holds
+  expire together. `slotlock_book_together` takes its `hold_group_id` and books the set from those
+  holds in one transaction. The application API gains `slotlock_tenant_book_together`
+  (`POST /v1/tenant/bundles`) and `slotlock_tenant_book_pool` (`POST /v1/tenant/pool-bookings`), the
+  agents' bundle and pool bookings for the tenant's own systems. Their events are the tenant's
+  (owner `internal`), not the key's: no agent's event quota counts them, and revoking the key
+  leaves them. Approval policies hold them only when they say `include_application: true` (new,
+  false by default), and a grant books them as the tenant's again; a key that `requires_approval`
+  still waits for a person whatever it books.
+- Waitlists that match (RFC 0004 B6): an entry may wait for any slot of a length within its
+  window (`duration_minutes`, `durationMs`), on a resource or a pool, and is offered the earliest
+  free one. Offers end `accepted`, `declined` (new `slotlock_decline_waitlist_offer`,
+  `POST /v1/waitlist/{entry_id}/decline`) or `lapsed`, decided by what becomes of their hold, by a
+  database trigger whatever path takes it. New feed types `waitlist.joined`, `.accepted`,
+  `.declined`, `.lapsed` and `.left`. Entries answer `duration_minutes` and `decided_at`.
+- A written booking lifecycle (RFC 0004 B4, T2): `src/lifecycle.ts` names each status, the move
+  each action makes and the refusal every other gets, and a test holds the store to it. A
+  tombstone keeps why the booking ended (`end_reason`: `cancelled` or `no_show`). New feed types:
+  `reservation.rescheduled` (a move, as well as `reservation.updated`) and `reservation.completed`,
+  which maintenance writes once for each booking whose end passed in the last week
+  (`bookings_completed` in its answer).
+- Cancellation and reschedule policies (RFC 0004 B5, T2): rules `cancelCutoffMinutes` and
+  `rescheduleCutoffMinutes` (`booking_rule_cancel_cutoff`, `booking_rule_reschedule_cutoff`), which
+  an admin may go past with `override_reason`, kept on the tombstone and the feed; and
+  `cancellationFee`, recorded on a late cancellation for the integrator to charge.
+- `slotlock_find_available_ranges` (`GET /v1/available-ranges`), the 18th agent tool: hires across
+  days for named resources or a pool's members, the earliest range on each from a pick-up window,
+  lasting N days or ending in a return window.
+- VAVAILABILITY carries RDATE and EXDATE (B1): the export adds the next year's closures as EXDATEs
+  and special hours as AVAILABLEs with RDATEs. The import reads them, and single AVAILABLEs, as
+  the resource's own exceptions, replacing those an earlier import made.
+
+- **Chats in the dashboard assistant.** Each conversation is a chat a member keeps:
+  - it is titled by its first message, at its own address (`<root>/assistant?c=<id>`);
+  - chats are listed beside the one shown, most recent first, grouped by day (Today, Yesterday,
+    Previous 7 days, Previous 30 days, Older), with a search box, and **Rename** and **Delete**
+    behind each one's menu;
+  - **New chat** starts another, and on a narrow screen the list is a page of its own
+    (`<root>/assistant/chats`);
+  - the page opens on the chat used in the past two hours, else on a new one;
+  - a streamed reply tells the page which chat it went to, so a new one gets its address and its
+    place in the list without a reload.
+
+  Chats are kept until the member deletes one, at most 100 per member (`SLOTLOCK_ASSISTANT_MAX_CHATS`;
+  past it, the least recently used goes, even with many started at once). A chat deleted while its
+  reply is being written stays deleted. They live in the new table `slotlock.assistant_chats`,
+  under forced RLS, erased with the tenant. `slotlock migrate` makes each member's 0.8 conversation
+  their first chat, once. Run `slotlock migrate`.
+- **Finding a resource by name.** `slotlock_list_resources` takes `query` and ranks the resources
+  that match what a person calls one, best first:
+  - each word is looked for in the name, reference, labels, kind, location and description;
+  - case and accents are ignored, and a typo, a word cut short or words run together are forgiven
+    (`mercedez`, `merc 2025` and `mercedesbenz` all find "Mercedes-Benz 2025");
+  - numbers match exactly;
+  - a search does bounded work, whatever the resources hold: past a budget of typo checks, it
+    matches exactly, by prefix and by words run together only.
+
+  `resource_not_found` for a name or reference given where an id belongs names the likeliest
+  resources in `details.candidate_1` to `candidate_3`.
+
+### Changed
+
+- The tenant's hours are stored, not copied onto every resource (RFC 0004 B2), and resources
+  without their own inherit them, those added later too. `storeTenantAvailability` stores them and
+  answers `{ inheriting, ownHours }`. `setTenantAvailability` keeps its 0.8.0 contract, deprecated:
+  every resource uses the hours afterwards, and it answers how many. `PUT /v1/availability` keeps
+  the hours resources have of their own by default; its `override_resources` is `none`, `all`
+  (clear them) or `matching` (clear those the same as the tenant's were or as the new ones: the
+  copies earlier versions made, while hours set apart on purpose stay), as are
+  `hours set --all --override` and `--matching`. It answers `resources_updated` (resources the
+  hours now apply to) and `resources_with_own_hours`. The dashboard's "Your hours" names the
+  resources that keep their own, with the same three choices, and `/resources?hours=own` lists
+  them.
+- `slotlock_run_maintenance` answers `bookings_completed`; the five clients' checks of its keys
+  include it. `slotlock_cancel_reservation` and `slotlock_cancel_tenant_event` answer
+  `cancellation_fee` (null when none).
+- `parseVAvailability` answers `days` as well as `rules`, and no longer refuses RDATE, EXDATE or an
+  AVAILABLE without RRULE.
+
+- **The dashboard assistant's store** (`SlotlockAssistantStore`) keeps chats. `listChats`,
+  `getChat`, `putChat`, `renameChat` and `deleteChat` replace `getConversation`,
+  `putConversation` and `deleteConversation`, and `settleAction` takes the chat's id. The tenant
+  store has `listAssistantChats`, `getAssistantChat`, `putAssistantChat`, `renameAssistantChat`
+  and `deleteAssistantChat`, and `settleAssistantAction` takes `chatId`.
+- **Conversation lifetime.** `conversationTtlMs` no longer defaults to 2 hours: without it, chats
+  are kept until deleted. Given, it may be up to 3,650 days.
+- **New conversation is New chat.** It starts another chat and deletes nothing. A form of 0.8 that
+  posts `<root>/assistant/reset` does the same.
+- **The assistant's system prompt** lists the workspace's resources (up to 50, with the ids tools
+  take) and says how to find others. The tool descriptions and the MCP instructions say that
+  `resource_id` takes an id and how to find one, and that a filter leaves out resources that state
+  nothing.
+
+### Fixed
+
+- Enforced hours (`enforceHours`) judged a write inside `withTenant` against no hours when its
+  resource used the server's default (`defaultAvailabilityRules`, `SLOTLOCK_AVAILABILITY` under
+  `serve`): every such booking was refused `booking_rule_outside_hours`. The tenant's store now
+  carries the server's hours.
+
+- **The assistant's chips stream.** "What's on today" and "Find free time" were forms that waited
+  for the whole turn and then reloaded the page; they now send through the box, so their reply
+  streams.
+
+- The dashboard assistant's Stop stops the turn on any runtime. Cancelling the streamed reply now
+  aborts the turn itself, which keeps what it had. Before, only `request.signal` stopped it, and a
+  runtime that does not abort it when the client goes kept the turn running. On Workers, the
+  request's database connection now closes only once the stopped turn is kept.
+- The Overview never shows a change by its type. A change it has no words for, from a newer server,
+  reads "Something changed", on its resource when it names one. A type such as `constructor` no
+  longer finds an inherited entry.
+- The assistant page's script keeps live steps in a map with no prototype, so a provider's tool-call
+  id of `__proto__` names nothing.
+
 ## 0.8.0 - 2026-11-10
 
 ### Added

package/NOTICE

@@ -10,6 +10,8 @@ each retains its own license. This release was built with these versions:
 - ical.js 2.2.1, Mozilla Public License 2.0, https://github.com/kewisch/ical.js
 - rrule 2.8.1, BSD 3-Clause License, https://github.com/jakubroztocil/rrule
   - tslib (via rrule), BSD Zero Clause License (0BSD), https://github.com/Microsoft/tslib
+- tldts 7.4.19, MIT License, https://github.com/remusao/tldts
+  - tldts-core (via tldts), MIT License, https://github.com/remusao/tldts
 - zod 4.6.7, MIT License, https://github.com/colinhacks/zod
 
 Peer dependency, installed and versioned by the application that embeds Slotlock:

package/README.md

@@ -16,8 +16,10 @@ TypeScript library.
 
 ## Get started
 
-The documentation is at [slotlock.pylota.io/docs](https://slotlock.pylota.io/docs/). There are
-three ways to run Slotlock:
+The documentation is at [slotlock.pylota.io/docs](https://slotlock.pylota.io/docs/), with a page
+each for the [booking MCP server](https://slotlock.pylota.io/mcp-server/), the
+[booking API](https://slotlock.pylota.io/booking-api/), [use cases](https://slotlock.pylota.io/use-cases/)
+and [pricing](https://slotlock.pylota.io/pricing/). There are three ways to run Slotlock:
 
 - **[Slotlock Cloud](docs/hosted/README.md)**: nothing to run. Sign in with GitHub at
   `https://app.slotlock.pylota.io/dashboard`, create a key, and connect an agent to