experimental-a2 0.19.0 → 0.21.1

package/docs/server/06-guarantees.mdx

@@ -1,45 +1,49 @@
 ---
 title: Guarantees
-description: Appends are effectively-once, handlers are at-least-once, and retries keep event identity across crashes.
+description: Appends are effectively-once, consumers are at-least-once, and retries keep event identity across crashes.
 ---
 
 ## In short
 
 - **Appends are effectively-once.** Event ids deduplicate writes. A batch commits
-  before its handlers start; they may start before `append` resolves.
-- **Handlers are at-least-once.** They may run again after a crash, so
-  [side effects use idempotency keys](/server/handlers#handlers-can-run-twice).
+  before its consumers start; they may start before `append` resolves.
+- **Consumers are at-least-once.** They may run again after a crash, so
+  [side effects use idempotency keys](/server/consumers#consumers-can-run-twice).
 - **The log stays ordered.** Every session has one immutable append order.
-- **Handlers are concurrent by default.** Log order does not serialize them.
-  Only events in the same lane run one at a time in log order.
+- **Consumers are concurrent by default.** Log order does not serialize them.
+  Only events in the same lane of one consumer run one at a time in log order.
+- **Every consumer keeps its own place.** One consumer's failures, retries, and
+  dead letters never hold up another.
 
 ## One event, many attempts
 
-An event is pending until A2 marks it processed. Every wakeup (an append, a
-scheduler watchdog, or `server.drain()`) claims the session's eligible events,
-and the log decides what remains. Reads never dispatch handlers.
+A consumer keeps a durable cursor in every session: where it has gotten to,
+and the event it runs next, its head. An event is pending for a consumer until
+that consumer's cursor moves past it. Every wakeup (an append, a scheduler
+watchdog, or `server.drain()`) claims the session's eligible heads, and the
+cursors decide what remains. Reads never dispatch consumers.
 
 Each claim expires. If its holder dies, the claim lapses and the next wakeup
-claims the event again with a larger `ctx.attempt`. The retry gets the same
+claims the head again with a larger `ctx.attempt`. The retry gets the same
 event id, index, type, and payload. A kill after the claim can use up an
-attempt before your code runs, and that attempt counts toward the event's
-[failure budget](#when-a-handler-keeps-failing). An older attempt can never
+attempt before your code runs, and that attempt counts toward the head's
+[failure budget](#when-a-consumer-keeps-failing). An older attempt can never
 overwrite a newer one's completion or failure.
 
 :::note[Recovery is not an event]
 A2 does not append `recovered` or `continued`. Recovery retries the same event.
-Your log contains only application facts.
+Your log contains only application facts; cursors live beside it.
 :::
 
 ## Immediate and dependent events
 
-[`ctx.session.append(name, ...events)`](/server/handlers#append-what-should-happen-now)
+[`ctx.session.append(name, ...events)`](/server/consumers#append-what-should-happen-now)
 commits immediately: its events stay in the log if the parent later crashes,
 and run concurrently with it unless both share a lane.
-[Returned events](/server/handlers#return-what-happens-after-success) commit
-with the parent's completion, in one transaction.
+[Returned events](/server/consumers#return-what-happens-after-success) commit
+with the cursor's advance past the parent, in one transaction.
 
-If the handler throws or dies before that transaction, neither the completion
+If `run` throws or dies before that transaction, neither the completion
 nor the returned events exist, and the retry produces the same deterministic
 ids. If the transaction commits but its acknowledgement is lost, the retry gets
 the committed rows back. A partial or changed batch is rejected.
@@ -51,11 +55,11 @@ the external system.
 
 ## Lanes
 
-[Lanes](/server/handlers#lanes) are session-scoped serial groups. Only the
-lowest-index unfinished event in a lane is eligible, so a failure blocks later
-events in that lane, not the whole session. Unlaned events and different lanes
-run concurrently. A2 stores the lane at append, so a changed lane resolver
-affects only new events.
+[Lanes](/server/consumers#lanes) are serial groups of one consumer in one
+session. Only the lowest-index unfinished event in a lane is eligible, so a
+failure blocks later events in that lane, not the whole session and not other
+consumers. Unlaned events and different lanes run concurrently. A2 stores each
+consumer's lane at append, so a changed lane resolver affects only new events.
 
 A lane controls A2 dispatch, not the outside world. A2 claims every eligible
 event, with no global concurrency limit or priority queue. Put capacity limits
@@ -64,52 +68,57 @@ runtime.
 
 ## Append and scheduling
 
-A top-level append commits before any wakeup. A2 then starts the handlers
-inline and, with a scheduler, arms a watchdog in parallel. Handlers never wait
-for the queue, and a handler may start before `append` returns. `append` waits
-up to two seconds for the watchdog send, never for handlers. A failed arm
-records `a2.append.armed = false` on the trace. Handler appends and returned
-events join the running drain and add no arm.
+A top-level append commits before any wakeup. A2 then starts the consumers
+inline and, with a scheduler, arms a watchdog in parallel. Consumers never wait
+for the queue, and one may start before `append` returns. `append` waits up to
+two seconds for the watchdog send, never for consumers. A failed arm records
+`a2.append.armed = false` on the trace. Consumer appends and returned events
+join the running drain and add no arm.
 
-[`append.dispatch`](/server/production#dispatch-in-a-fresh-invocation) skips
+[`append.dispatch`](/schedulers/overview#dispatch-in-a-fresh-invocation) skips
 the inline drain and hands the work to the scheduler instead.
 
-An event type without a handler settles in the append transaction. It starts
-no drain or arm unless older handled work in the session is still pending.
+An event no consumer takes starts no work. It starts no drain or arm unless
+older work in the session is still pending. A dead letter is not pending: it
+waits for a redrive, which wakes the session itself.
 
 ## Causal trees are durable
 
-Every event a handler appends or returns stores a `cause`: the triggering
-event's index and dispatch attempt. Top-level appends store `null`. Children
-of one handler are siblings, nested handlers add levels, and a retried child
-keeps its original cause.
+Every event a consumer appends or returns stores a `cause`: the consumer, its
+lane, the triggering event's index, and the attempt. Top-level appends store
+`null`. Children of one run are siblings, nested runs add levels, and a
+retried child keeps its original cause.
 
 ## A chain that crosses the function timeout
 
-A function killed mid-handler restarts that handler from its entry point in a
-fresh invocation: same event, new attempt. Events already processed stay
-processed, so a chain of handlers can outlast one invocation, but each handler
+A function killed mid-run restarts that consumer's `run` from its entry point
+in a fresh invocation: same event, new attempt. Events a cursor already moved
+past stay done, so a chain of events can outlast one invocation, but each run
 must fit in a fresh one: an attempt that runs out of time is a failed attempt,
-and a handler that never fits dead-letters after ten. Split longer work into
+and a run that never fits dead-letters after ten. Split longer work into
 smaller events or increase the function duration. On Vercel, A2 caps the claim window
 at the function deadline when the platform exposes it, so a retry starts
 promptly after a timeout. Once the deadline passes, A2 claims nothing more in
 that invocation, so a timeout costs the event one attempt.
 
-## When a handler keeps failing
+## When a consumer keeps failing
 
-A caught failure counts against that event, releases its claim, and leaves
-other eligible events running. A2 holds it back for a delay that starts at
+A caught failure counts against that consumer's head, releases its claim, and
+leaves other eligible heads running. A2 holds it back for a delay that starts at
 one second and doubles with each failed attempt up to 30 seconds, then retries
 it on the session's next wake. With a scheduler, that's a few seconds at first,
 then the delay itself. An attempt that ends before it finishes, because its
 process timed out, crashed, or lost its claim, counts too, once the next
-attempt takes its claim over. Ten failed attempts dead-letter the event: later
-events in its lane stay blocked, while unlaned events and other lanes continue.
+attempt takes its claim over. Ten failed attempts dead-letter the event for
+that consumer: later events in its lane stay blocked, while unlaned events,
+other lanes, and other consumers continue.
 A crash costs every event it interrupts one attempt, so a session whose work
 keeps outrunning its function dead-letters: bound its fan-out, or put work that
-waits on the same resource in one lane. The event waits until you
-[retry or skip it](/server/production#3-when-an-event-dead-letters) with
+waits on the same resource in one lane. A `NonRetriableError`, or a returned
+batch the store refuses because it reuses an event id, dead-letters the event
+on that first attempt instead: a retry would fail the same way. The event
+waits until you
+[retry or skip it](/server/consumers#resolve-a-dead-letter) with
 `session.redrive()`.
 
 ## Limits
@@ -120,13 +129,14 @@ waits on the same resource in one lane. The event waits until you
 | No scheduler configured | A later top-level append or explicit `drain()` wakes the session. Reads never do. |
 | Scheduler invocation dies after claiming but before arming | Its unacknowledged queue delivery is the slower fallback. |
 | Store backend unavailable | Safe progress stops until it returns. |
-| External effect succeeds before A2 completion | The handler may repeat it. Use idempotency or external fencing. |
+| External effect succeeds before A2 completion | The consumer may repeat it. Use idempotency or external fencing. |
 
 ## What append never throws for
 
-A failing handler never makes `append` throw. Handler failures are retried and,
-if persistent, [dead-letter the event](#when-a-handler-keeps-failing).
+A failing consumer never makes `append` throw. Its failures are retried and,
+if persistent, [dead-letter the event](#when-a-consumer-keeps-failing) for
+that consumer.
 
-Append success means the event is durable, not that its handlers finished. An
+Append success means the event is durable, not that its consumers finished. An
 identical batch retry returns rows with the same ids. A mixed batch throws
 [`PARTIAL_DUPLICATE_BATCH`](/reference/errors).

package/docs/stores/01-overview.mdx

@@ -0,0 +1,37 @@
+---
+title: Overview
+description: Where A2 keeps your session histories.
+---
+
+```ts server/orders.ts
+import { createServer } from 'experimental-a2/server'
+import { redis } from 'experimental-a2/store-redis'
+import { orders } from '@/contracts'
+
+export const ordersServer = createServer({
+  contract: orders,
+  store: redis({ url: process.env.REDIS_URL }),
+  consumers: [
+    /* ... */
+  ],
+})
+```
+
+| Store | Use it for |
+| --- | --- |
+| [Redis](/stores/redis) | Production (recommended) |
+| [Redis over HTTP](/stores/redis-http) | Production, when your provider only offers a REST API |
+| [Postgres](/stores/postgres) | Production |
+| [SQLite](/stores/sqlite) | Development: the default |
+| [Memory](/stores/memory) | Tests: the default when `NODE_ENV=test` |
+
+When you omit `store`, development gets SQLite, so state survives `next dev`
+restarts, and tests get memory. Production has no default, on purpose: the
+server throws `STORE_NOT_CONFIGURED` at startup rather than write events to a
+filesystem that evaporates.
+
+A store holds A2's session histories. It doesn't connect A2 to your
+application tables; see
+[Sessions and your database](/contract/sessions#sessions-and-your-database).
+
+Servers with consumers or timers also need a [scheduler](/schedulers/overview).

package/docs/stores/02-redis.mdx

@@ -0,0 +1,57 @@
+---
+title: Redis
+description: The recommended production store. Live streams are pushed, not polled.
+---
+
+```ts server/orders.ts
+import { createServer } from 'experimental-a2/server'
+import { redis } from 'experimental-a2/store-redis'
+import { orders } from '@/contracts'
+
+export const ordersServer = createServer({
+  contract: orders,
+  store: redis({ url: process.env.REDIS_URL }),
+  consumers: [
+    /* ... */
+  ],
+})
+```
+
+```package-install
+npm i ioredis
+```
+
+Works on a single Redis instance and on non-cluster providers such as Upstash,
+which is durable by default (use its TCP `rediss://` URL). There's nothing to
+set up: A2 creates its keys as it writes.
+
+## Options
+
+| Option | |
+| --- | --- |
+| `url` | creates an `ioredis` client |
+| `client` | your own `ioredis` client instead |
+| `keyPrefix` | isolates several apps on one Redis. Default `'a2'` |
+| `clock`, `ids` | test seams for timestamps and generated event ids |
+
+## Upgrade
+
+The store records its key layout in `<keyPrefix>:schema`, and refuses a prefix
+marked with another one with `STORE_NOT_CONFIGURED`. A release that changes
+the layout says what to do on its [upgrade page](/upgrades/overview).
+[0.21](/upgrades/0-21) reads what earlier releases wrote under the same
+prefix.
+
+## How it works
+
+- Each session is a Redis Stream.
+- Every write publishes a wake-up, so live streams are push-driven, and
+  connections scale with your processes, not with your viewers.
+- A wake-up is disposable: a safety re-read recovers a lost one within ten
+  seconds.
+
+## Cost per command
+
+On providers that bill per command, such as Upstash, appending an event with a
+consumer and running it takes 19 commands, and an idle live stream takes 6 a
+minute.

package/docs/stores/03-redis-http.mdx

@@ -0,0 +1,56 @@
+---
+title: Redis over HTTP
+description: The same Redis store over fetch, for providers with only a REST API.
+---
+
+```ts server/orders.ts
+import { createServer } from 'experimental-a2/server'
+import { redisHttp } from 'experimental-a2/store-redis-http'
+import { orders } from '@/contracts'
+
+const url = process.env.UPSTASH_REDIS_REST_URL
+const token = process.env.UPSTASH_REDIS_REST_TOKEN
+if (!url || !token) throw new Error('set the Upstash REST URL and token')
+
+export const ordersServer = createServer({
+  contract: orders,
+  store: redisHttp({ url, token }),
+  consumers: [
+    /* ... */
+  ],
+})
+```
+
+Stores sessions exactly like [Redis](/stores/redis), with no client dependency
+and nothing to set up. Use it when your provider only offers a REST API.
+
+:::warning
+Live streams trust the messages on the store's `:notify` channels. Browsers
+never hold Redis credentials, so they can't reach those channels. The risk is a
+credential that can publish but not write, such as a token another service
+uses: it could add or hide events in live views. Grant publish access only to
+credentials that can also write the store.
+:::
+
+## Options
+
+| Option | |
+| --- | --- |
+| `url`, `token` | your provider's REST endpoint and token |
+| `keyPrefix` | isolates several apps on one Redis. Default `'a2'` |
+| `clock`, `ids` | test seams for timestamps and generated event ids |
+
+## Live updates
+
+- Live events and presence use Upstash's HTTP `SUBSCRIBE` endpoint, with the
+  same URL and token. Each active channel holds one outbound HTTP subscription
+  per store instance, shared by its viewers and closed when the last one
+  leaves.
+- Writes publish their wake-ups in the same Redis script as the append. A
+  rejected notification doesn't fail the write.
+- Idle streams re-read every ten seconds to recover a missed notification.
+  Subscriptions reconnect on their own and catch up from the event cursor.
+- After a reconnect, A2 re-reads presence and clears fields deleted during the
+  gap, so presence may repeat its latest values.
+- If `SUBSCRIBE` answers 404, 405, or 501, the store polls instead, every 25ms
+  while busy and up to every two seconds when idle. Other errors stay errors.

package/docs/stores/04-postgres.mdx

@@ -0,0 +1,172 @@
+---
+title: Postgres
+description: Any Postgres database. You create A2's tables; A2 never changes your schema.
+---
+
+```ts server/orders.ts
+import { createServer } from 'experimental-a2/server'
+import { postgres } from 'experimental-a2/store-postgres'
+import { orders } from '@/contracts'
+
+export const ordersServer = createServer({
+  contract: orders,
+  store: postgres({ connectionString: process.env.DATABASE_URL }),
+  consumers: [
+    /* ... */
+  ],
+})
+```
+
+```package-install
+npm i pg
+```
+
+Works with Neon, Supabase, RDS, or your own server, including transaction-mode
+poolers.
+
+## Create the tables
+
+A2 doesn't create or change tables in your database. This is the SQL it needs:
+[`schema.sql`](https://github.com/vercel-labs/a2/blob/main/packages/a2/sql/postgres/schema.sql),
+also in the package at `node_modules/experimental-a2/sql/postgres/schema.sql`.
+Apply it before your first deploy, however you run SQL against your database
+or as one of your migrations, as the role your app connects with. A breakpoint
+comment ends each statement, for tools that send one statement per query.
+`a2_batch` runs the statements it's handed, so only its owner may call it,
+whatever your default privileges grant new functions. An app that connects as
+another role needs `grant execute on function a2_batch(text[], jsonb)` beside
+its grants on the tables, and keeps it when you apply the file again.
+
+A2 checks nothing up front. It relies on the table and column names, the
+column types, the primary keys, the unique index on `a2_events.event_id`, and
+the `a2_batch` function; the other indexes keep its queries fast. A query that
+finds a table, column, or the function missing throws `STORE_NOT_CONFIGURED`,
+naming the file. Once it's applied, the next request works, with no redeploy.
+
+`a2_batch` runs several statements in one round trip. Each append, claim,
+completion, and `consume` poll is one call of it, so they hold a session's lock
+only while the database runs the call, not across round trips from your app.
+That's what keeps one busy session fast on a database a few milliseconds
+away. It needs `read committed`, Postgres's default isolation level, and
+throws `STORE_NOT_CONFIGURED` under a stricter default.
+
+## With Drizzle
+
+[`drizzle-schema.ts`](https://github.com/vercel-labs/a2/blob/main/packages/a2/sql/postgres/drizzle-schema.ts),
+next to `schema.sql`, shows the same tables as Drizzle definitions. It's an
+example, not an API: one way to fit A2's tables into a Drizzle project is a
+copy next to your own schema, so your migrations create them with yours.
+
+```ts drizzle.config.ts
+import { defineConfig } from 'drizzle-kit'
+
+export default defineConfig({
+  dialect: 'postgresql',
+  // your tables, and a copy of drizzle-schema.ts:
+  schema: ['./db/schema.ts', './db/a2.ts'],
+  out: './drizzle',
+  dbCredentials: { url: process.env.DATABASE_URL ?? '' },
+})
+```
+
+`drizzle-kit generate` then writes A2's tables into a migration you can read,
+and `drizzle-kit migrate` applies it. Adapt the copy to your Drizzle version
+and layout, as long as the names and types stay A2's.
+
+Drizzle can't declare a function, so add `a2_batch` as a custom migration:
+run `drizzle-kit generate --custom`, and paste the `do` block that creates
+`a2_batch` from `schema.sql` into the file it makes. It creates the function
+only if it's missing, so the migration is safe on any database.
+
+A generated migration only creates tables. On a database that already has
+A2's tables, from an earlier release or a `schema.sql` applied by hand, put
+`schema.sql` in place of the SQL drizzle-kit generated for them: it creates
+what's missing and upgrades the rest, keeping their events, and your schema
+still describes them for the next `generate`. To keep a table of your own
+from A2's logs, see [SQL projections](/server/sql-projections).
+
+## Upgrade
+
+A release that changes A2's tables says so in its changelog, and its
+[upgrade page](/upgrades/overview) says when to apply its `schema.sql`. With
+Drizzle, bring your copy of `drizzle-schema.ts` in line with the new one.
+
+## Live updates (polling)
+
+By default, live streams poll every 25ms while a session is busy, backing off
+to every two seconds when it's quiet, so an update from another client can take
+up to two seconds, plus query latency, to reach a quiet stream. A client's own
+`push()` refreshes its stream immediately, even when the write and the stream
+run in different invocations.
+
+## Live updates (notifications)
+
+For instant updates, pass `listenConnectionString`, a direct connection to the
+same database (not through a pooler), and apply
+[`notifications.sql`](https://github.com/vercel-labs/a2/blob/main/packages/a2/sql/postgres/notifications.sql)
+once, the same way as `schema.sql` (with Drizzle, as a custom migration:
+`drizzle-kit generate --custom`). A missing trigger fails no query, so this is
+the one thing A2 looks for: a listening store's first subscription throws
+`STORE_NOT_CONFIGURED` until the triggers exist.
+
+Its triggers notify listeners of every write, including writes from stores
+without the option. Notifications arrive after commit, a reconnect catches up
+from the cursor, and subscriptions also reconcile every ten seconds. Every
+serverless instance opens its own direct connection, so leave connection
+headroom.
+
+## Use postgres.js
+
+`connectionString` creates a `pg` pool. To use
+[postgres.js](https://github.com/porsager/postgres) instead, wrap it as
+`client`:
+
+```ts server/store.ts
+import postgresJs from 'postgres'
+import { postgres } from 'experimental-a2/store-postgres'
+
+const url = process.env.DATABASE_URL
+if (!url) throw new Error('set DATABASE_URL')
+
+const sql = postgresJs(url, {
+  // A2 sends JSON as text; this keeps postgres.js from encoding it again.
+  types: {
+    json: {
+      to: 114,
+      from: [114, 3802],
+      serialize: (x: unknown) => (typeof x === 'string' ? x : JSON.stringify(x)),
+      parse: (x: string) => JSON.parse(x),
+    },
+  },
+})
+
+export const store = postgres({
+  client: {
+    query: async (text, values = []) => ({
+      rows: [...(await sql.unsafe(text, values))],
+    }),
+    connect: async () => {
+      const connection = await sql.reserve()
+      return {
+        query: async (text, values = []) => ({
+          rows: [...(await connection.unsafe(text, values))],
+        }),
+        release: () => connection.release(),
+      }
+    },
+    end: () => sql.end(),
+  },
+})
+```
+
+`listenConnectionString` still opens its listener with `pg`, so live
+notifications need `pg` installed too.
+
+## Options
+
+| Option | |
+| --- | --- |
+| `connectionString` | creates a `pg` pool, shared by stores with the same settings |
+| `client` | your own pool instead: a `pg` `Pool`, PGlite, or a pooler wrapper. Its lifecycle is yours |
+| `listenConnectionString` | a direct connection for notifications |
+| `clock`, `ids` | test seams for timestamps and generated event ids |

package/docs/stores/05-sqlite.mdx

@@ -0,0 +1,36 @@
+---
+title: SQLite
+description: The development default, in a file at `.a2/dev.db`.
+---
+
+```ts server/orders.ts
+import { createServer } from 'experimental-a2/server'
+import { sqlite } from 'experimental-a2/store-sqlite'
+import { orders } from '@/contracts'
+
+export const ordersServer = createServer({
+  contract: orders,
+  store: sqlite({ path: '.a2/orders.db' }),
+  consumers: [
+    /* ... */
+  ],
+})
+```
+
+In development, a server without a `store` uses SQLite at `.a2/dev.db`, so
+your sessions survive `next dev` restarts. Pass it yourself to pick another
+file.
+
+It runs on `node:sqlite`, with no dependencies, and creates its tables when it
+opens the file. A file a release before [0.21](/upgrades/0-21) wrote throws
+`STORE_NOT_CONFIGURED` when it opens: delete it, or pass another `path`. It's
+for development: a serverless filesystem doesn't last or
+share one file across instances, so production needs another
+[store](/stores/overview).
+
+## Options
+
+| Option | |
+| --- | --- |
+| `path` | the database file. Default `.a2/dev.db`; `:memory:` works |
+| `clock`, `ids` | test seams for timestamps and generated event ids |

package/docs/stores/06-memory.mdx

@@ -0,0 +1,22 @@
+---
+title: Memory
+description: An in-process store for tests, the default when `NODE_ENV=test`.
+---
+
+```ts
+// in a test:
+import { createServer } from 'experimental-a2/server'
+import { memory } from 'experimental-a2/store-memory'
+import { orders } from '@/contracts'
+
+const ordersServer = createServer({ contract: orders, store: memory() })
+```
+
+Sessions live in the process and vanish when it exits. Under `NODE_ENV=test`, a
+server without a `store` already uses memory.
+
+## Options
+
+| Option | |
+| --- | --- |
+| `clock`, `ids` | test seams for timestamps and generated event ids |

package/docs/stores/meta.ts

@@ -0,0 +1 @@
+export default { order: 4 }

package/docs/upgrades/01-overview.mdx

@@ -0,0 +1,30 @@
+---
+title: Overview
+description: What to do when you move to a new release. One page per release that needs steps from you, newest first.
+---
+
+## The releases
+
+| Release | What you do |
+| --- | --- |
+| [0.21](/upgrades/0-21) | Rewrite handlers as consumers. Let earlier deployments finish; on Postgres, then apply the new `schema.sql`. SQLite starts fresh. |
+| [0.20](/upgrades/0-20) | Postgres: apply `schema.sql` yourself, before you deploy. |
+| [0.19](/upgrades/0-19) | Start new agent sessions: earlier ones don't fold. |
+| [0.18](/upgrades/0-18) | Move the AI SDK loop's options into `harness`. |
+| [0.17](/upgrades/0-17) | Redis: use a fresh `keyPrefix`. Serve agents with `agent()`. |
+
+## Across several releases
+
+Read every page between the release you run and the one you're moving to,
+oldest first. Code changes add up: make each page's changes. Store steps
+don't always: each release's `schema.sql` covers a database from any earlier
+release, so a Postgres database needs only the newest one, applied the way the
+newest page says, and one fresh Redis `keyPrefix` covers every release that
+asks for one.
+
+## Everything else
+
+Each release's changelog lists everything it changes, including what needs no
+steps: [`CHANGELOG.md`](https://github.com/vercel-labs/a2/blob/main/packages/a2/CHANGELOG.md),
+also in the package at `node_modules/experimental-a2/CHANGELOG.md`. Releases
+before 0.17 are only there.