slotlock 0.9.0 → 0.10.0

package/CHANGELOG.md

@@ -3,6 +3,311 @@
 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

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