project: widen prettier scope to cover all files

The format:check and format scripts only covered src/ and demo source
directories, so a bunch of files e.g. tests were never checked by CI.
But, even more annoyingly, I found Claude would sometimes explicitly run
`prettier --write` on excluded files that it edited, thus introducing
diff noise.

Instead, match ably-js's approach of formatting everything (relying on
Prettier's automatic ignoral of gitignored stuff [1]).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

[1] https://prettier.io/docs/ignore

Author: lawrence-forooghian

.claude/rules/ABSTRACTIONS.md

@@ -39,13 +39,12 @@ ably-common/                          # Git submodule — shared protocol resour
 
 The SDK ships four entry points from a single package:
 
-| Export path | Contains | Purpose | External deps |
-|---|---|---|---|
-| `@ably/ai-transport` | Generic codec interfaces, `createClientTransport`, `createServerTransport`, shared utilities | Core primitives — codec-agnostic transport and encoding | `ably` (peer) |
-| `@ably/ai-transport/react` | `useClientTransport`, `useView`, `useTree`, `useSend`, `useRegenerate`, `useEdit`, `useActiveTurns`, `useAblyMessages` | Generic React hooks for any codec | `ably`, `react` (peers) |
-| `@ably/ai-transport/vercel` | `UIMessageCodec`, `createServerTransport`, `createClientTransport`, `createChatTransport`, Vercel-specific types | Drop-in Vercel AI SDK integration | `ably`, `ai` (peers) |
-| `@ably/ai-transport/vercel/react` | `useChatTransport`, `useMessageSync` | React hooks for Vercel's `useChat` | `ably`, `ai`, `react` (peers) |
-
+| Export path                       | Contains                                                                                                               | Purpose                                                 | External deps                 |
+| --------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | ----------------------------- |
+| `@ably/ai-transport`              | Generic codec interfaces, `createClientTransport`, `createServerTransport`, shared utilities                           | Core primitives — codec-agnostic transport and encoding | `ably` (peer)                 |
+| `@ably/ai-transport/react`        | `useClientTransport`, `useView`, `useTree`, `useSend`, `useRegenerate`, `useEdit`, `useActiveTurns`, `useAblyMessages` | Generic React hooks for any codec                       | `ably`, `react` (peers)       |
+| `@ably/ai-transport/vercel`       | `UIMessageCodec`, `createServerTransport`, `createClientTransport`, `createChatTransport`, Vercel-specific types       | Drop-in Vercel AI SDK integration                       | `ably`, `ai` (peers)          |
+| `@ably/ai-transport/vercel/react` | `useChatTransport`, `useMessageSync`                                                                                   | React hooks for Vercel's `useChat`                      | `ably`, `ai`, `react` (peers) |
 
 ## Two-Layer Architecture
 
@@ -67,11 +66,11 @@ Header/event/message-name constants and Ably message utilities used by both laye
 
 The client-side architecture separates three concerns:
 
-| Component | Owns | Events |
-|---|---|---|
-| **Tree** | Complete conversation state — every node from live messages and history. Turn tracking (active turn → clientId). | `update` (any structural change), `ably-message` (every raw message), `turn` (start/end) — unfiltered, fires for all changes |
-| **View** | Pagination window — which history-loaded nodes are visible vs withheld. | Same event names, but **scoped to the visible window** — only fires when the visible output changes |
-| **Transport** | Write path (send/regenerate/edit/cancel), channel subscription, stream routing, decode loop. | `error` only — all data events moved to Tree/View |
+| Component     | Owns                                                                                                             | Events                                                                                                                       |
+| ------------- | ---------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
+| **Tree**      | Complete conversation state — every node from live messages and history. Turn tracking (active turn → clientId). | `update` (any structural change), `ably-message` (every raw message), `turn` (start/end) — unfiltered, fires for all changes |
+| **View**      | Pagination window — which history-loaded nodes are visible vs withheld.                                          | Same event names, but **scoped to the visible window** — only fires when the visible output changes                          |
+| **Transport** | Write path (send/regenerate/edit/cancel), channel subscription, stream routing, decode loop.                     | `error` only — all data events moved to Tree/View                                                                            |
 
 The Tree is the source of truth. The View subscribes to Tree events and re-emits them filtered to what's visible. The Transport wires the channel to the Tree and exposes both as `transport.tree` and `transport.view`.
 
@@ -146,8 +145,8 @@ Public-facing entry points (e.g. `createClientTransport()`) are factory function
 
 1. **Two-layer split**: Generic transport/codec knows nothing about Vercel. Vercel layer implements the codec and provides convenience wrappers.
 2. **Codec-parameterized**: All generic components are parameterized by `<TEvent, TMessage>` via the `Codec` interface.
-4. **Constructor/option injection**: All dependencies passed explicitly — no singletons, no globals.
-3. **Composition, not inheritance**: Transports compose features; no class hierarchies.
+3. **Constructor/option injection**: All dependencies passed explicitly — no singletons, no globals.
+4. **Composition, not inheritance**: Transports compose features; no class hierarchies.
 5. **Interface-first**: Public contracts are TypeScript interfaces. Implementations are internal `Default*` classes, exposed to consumers via factory functions.
 6. **Header discipline**: Generic layer uses only `x-ably-*` headers. Domain-specific headers (e.g. `x-domain-*`) belong in the Vercel layer.
 7. **Explicit exports**: Only types and functions listed in `index.ts` files are public API.

.claude/rules/ERRORS.md

@@ -11,7 +11,7 @@ Every error should either be handled internally with a clear recovery strategy,
 - **Isolate handler callbacks**: When the SDK invokes developer-provided callbacks (event listeners, hooks), wrap each in try/catch. One bad handler shouldn't kill internal machinery or prevent other handlers from firing.
 - **Define recovery semantics explicitly**: For every internal operation that can fail, decide upfront: retry, degrade, or propagate. Document the choice.
 - **Preserve the original error**: When wrapping errors, always attach the original as `cause`. Developers debugging production issues need the full chain.
-- **Best-effort operations should be labeled**: If something is fire-and-forget (e.g. cleanup publish on close), comment it as such. Swallowing an error is only acceptable when failure is unrecoverable *and* non-impactful.
+- **Best-effort operations should be labeled**: If something is fire-and-forget (e.g. cleanup publish on close), comment it as such. Swallowing an error is only acceptable when failure is unrecoverable _and_ non-impactful.
 
 ### Surfacing errors to developers
 
@@ -86,9 +86,9 @@ throw new Ably.ErrorInfo('unable to send message; room is not attached', ErrorCo
 throw new Ably.ErrorInfo('unable to detach room; room is in failed state', ErrorCode.RoomInInvalidState, 400);
 
 // Wrong — do not use these prefixes
-"cannot send message"
-"failed to send message"
-"Could not send message"
+// "cannot send message"
+// "failed to send message"
+// "Could not send message"
 ```
 
 Dynamic context is allowed in the message:
@@ -145,12 +145,12 @@ reject(
 
 Use the custom Vitest matchers in a test helper (`test/helper/expectations.ts`):
 
-| Matcher | Usage |
-|---|---|
-| `toBeErrorInfo({ code?, statusCode?, message?, cause? })` | Assert a value is an `Ably.ErrorInfo` matching the given fields |
-| `toThrowErrorInfo({ code?, statusCode?, message? })` | Assert a sync function throws a matching `Ably.ErrorInfo` |
-| `toBeErrorInfoWithCode(code)` | Shorthand — assert value is `Ably.ErrorInfo` with a specific code |
-| `toThrowErrorInfoWithCode(code)` | Shorthand — assert sync function throws with a specific code |
-| `toBeErrorInfoWithCauseCode(code)` | Assert value is `Ably.ErrorInfo` whose `.cause.code` matches |
+| Matcher                                                   | Usage                                                             |
+| --------------------------------------------------------- | ----------------------------------------------------------------- |
+| `toBeErrorInfo({ code?, statusCode?, message?, cause? })` | Assert a value is an `Ably.ErrorInfo` matching the given fields   |
+| `toThrowErrorInfo({ code?, statusCode?, message? })`      | Assert a sync function throws a matching `Ably.ErrorInfo`         |
+| `toBeErrorInfoWithCode(code)`                             | Shorthand — assert value is `Ably.ErrorInfo` with a specific code |
+| `toThrowErrorInfoWithCode(code)`                          | Shorthand — assert sync function throws with a specific code      |
+| `toBeErrorInfoWithCauseCode(code)`                        | Assert value is `Ably.ErrorInfo` whose `.cause.code` matches      |
 
 The matchers only check the fields you provide — omitted fields are not compared. The `cause` field is checked recursively.

.claude/rules/LOGGING.md

@@ -19,14 +19,14 @@ type LogContext = Record<string, any>;
 
 ## Log Levels
 
-| Level | When to use |
-|---|---|
-| `Trace` | Routine operations — entry point of every key method. The most verbose level. |
-| `Debug` | Useful for debugging but superfluous in normal operation — successful completions, state transitions, decision points. |
-| `Info` | Operationally significant but expected — transport open/close, lifecycle events. |
-| `Warn` | Not an error yet, but could cause problems — unexpected but recoverable states. |
-| `Error` | An operation has failed and cannot be automatically recovered. |
-| `Silent` | No logging. |
+| Level    | When to use                                                                                                            |
+| -------- | ---------------------------------------------------------------------------------------------------------------------- |
+| `Trace`  | Routine operations — entry point of every key method. The most verbose level.                                          |
+| `Debug`  | Useful for debugging but superfluous in normal operation — successful completions, state transitions, decision points. |
+| `Info`   | Operationally significant but expected — transport open/close, lifecycle events.                                       |
+| `Warn`   | Not an error yet, but could cause problems — unexpected but recoverable states.                                        |
+| `Error`  | An operation has failed and cannot be automatically recovered.                                                         |
+| `Silent` | No logging.                                                                                                            |
 
 Levels are hierarchical. Setting the level to `Debug` suppresses `Trace` but shows everything else.
 
@@ -85,7 +85,8 @@ this._logger.debug('Tree.upsert(); inserting new node', { msgId, parentId, forkO
 
 // Warning
 this._logger.warn('DefaultDecoderCore.decode(); unexpected message action', {
-  action, serial: message.serial,
+  action,
+  serial: message.serial,
 });
 
 // Error
@@ -130,7 +131,8 @@ Not yet an error, but something that could cascade:
 
 ```ts
 this._logger.warn('DefaultDecoderCore.decode(); unrecognized message name', {
-  name: message.name, serial: message.serial,
+  name: message.name,
+  serial: message.serial,
 });
 ```
 

.claude/rules/TESTS.md

@@ -2,10 +2,10 @@
 
 ## Two tiers
 
-| Tier | Command | Runs against | What it proves |
-|---|---|---|---|
-| **Unit** | `npm test` | Mocks only | Every code path works correctly in isolation |
-| **Integration** | `npm run test:integration` | Real Ably channels | Happy path works end-to-end over real Ably |
+| Tier            | Command                    | Runs against       | What it proves                               |
+| --------------- | -------------------------- | ------------------ | -------------------------------------------- |
+| **Unit**        | `npm test`                 | Mocks only         | Every code path works correctly in isolation |
+| **Integration** | `npm run test:integration` | Real Ably channels | Happy path works end-to-end over real Ably   |
 
 Config: `vitest.config.ts` (unit, excludes `*.integration.test.ts`) and `vitest.config.integration.ts` (integration only).
 
@@ -49,11 +49,11 @@ By default, integration tests run against the **Ably sandbox**. The globalSetup
 
 To run against a different environment, set `VITE_ABLY_ENV`:
 
-| `VITE_ABLY_ENV` | Behaviour | API key required? |
-|---|---|---|
-| *(unset)* / `sandbox` | Provisions a sandbox app automatically | No |
-| `local` | Connects to `local-rest.ably.io:8081` (no TLS) | Yes — set `VITE_ABLY_API_KEY` |
-| `production` | Connects to production Ably | Yes — set `VITE_ABLY_API_KEY` |
+| `VITE_ABLY_ENV`       | Behaviour                                      | API key required?             |
+| --------------------- | ---------------------------------------------- | ----------------------------- |
+| _(unset)_ / `sandbox` | Provisions a sandbox app automatically         | No                            |
+| `local`               | Connects to `local-rest.ably.io:8081` (no TLS) | Yes — set `VITE_ABLY_API_KEY` |
+| `production`          | Connects to production Ably                    | Yes — set `VITE_ABLY_API_KEY` |
 
 ### Conventions
 

.claude/skills/commit/SKILL.md

@@ -57,6 +57,7 @@ project-specific guidance takes precedence.
 ### Project-specific component prefixes
 
 The component prefix is derived from the file paths in the diff. Examples:
+
 - `codec:` `codec/vercel:` `transport:` `transport/vercel:`
 - `react:` `react/vercel:`
 - `claude/skills:` `claude/rules:`

.claude/skills/docs/SKILL.md

@@ -83,19 +83,23 @@ direct, declarative statement. No preamble, no "In this guide, we'll..."
 
 ```markdown
 <!-- Good -->
+
 Cancellation in `@ably/ai` is a channel-level operation - the client publishes
 a cancel signal on the Ably channel, the server receives it and aborts the
 matching turns.
 
 <!-- Good -->
+
 Interruption is when a user sends a new message while the AI is still streaming
 a response.
 
 <!-- Bad -->
+
 In this guide, we'll explore how to cancel streaming responses in your
 AI application.
 
 <!-- Bad -->
+
 This page covers the cancellation feature of the AI Transport SDK.
 ```
 
@@ -109,7 +113,7 @@ This page covers the cancellation feature of the AI Transport SDK.
   "robust." The technical explanation IS the value proposition.
 - **No hedging.** Don't say "you may want to" or "consider using." Say
   "use X when Y."
-- **Use hyphens, not em-dashes.** Use ` - ` (space-hyphen-space) for
+- **Use hyphens, not em-dashes.** Use <code> - </code> (space-hyphen-space) for
   parenthetical asides, not `—`. This applies to prose, code comments,
   and table cells.
 
@@ -195,8 +199,8 @@ Internals pages follow this flow:
    glossary, and the corresponding feature/concept pages
 
 Internals pages differ from concept pages: concept pages explain what
-developers need to know to *use* the SDK. Internals pages explain how the
-SDK works *internally* for contributors and curious engineers. Internals
+developers need to know to _use_ the SDK. Internals pages explain how the
+SDK works _internally_ for contributors and curious engineers. Internals
 pages can reference source file paths and internal class names.
 
 ### Tables
@@ -206,10 +210,10 @@ codes, phase behaviors. Tables are scannable and dense. Prefer a table over
 a bullet list when comparing properties across items.
 
 ```markdown
-| Filter | Effect | Use case |
-|---|---|---|
-| `{ own: true }` (default) | Cancel all turns started by this client | Stop button |
-| `{ turnId: "abc" }` | Cancel one specific turn | Cancel a specific generation |
+| Filter                    | Effect                                  | Use case                     |
+| ------------------------- | --------------------------------------- | ---------------------------- |
+| `{ own: true }` (default) | Cancel all turns started by this client | Stop button                  |
+| `{ turnId: "abc" }`       | Cancel one specific turn                | Cancel a specific generation |
 ```
 
 ### Diagrams
@@ -218,7 +222,7 @@ Use **Mermaid diagrams** (` ```mermaid `) for sequence diagrams, flowcharts,
 and any multi-column or multi-participant interactions. Mermaid is rendered
 by GitHub and most doc tooling, so alignment is never an issue.
 
-```markdown
+````markdown
 ```mermaid
 sequenceDiagram
     participant C as Client
@@ -228,8 +232,8 @@ sequenceDiagram
     C->>Ch: publish(x-ably-cancel)
     Note left of C: close local stream(s)
     Ch->>S: deliver to cancel listener
-```                                        (close the code fence)
 ```
+````
 
 **When to use Mermaid vs plain text:**
 
@@ -254,8 +258,8 @@ eliminates this class of bugs entirely.
 - **Real types, real methods.** Use the actual API - `transport.send()`,
   `turn.cancel()`, not pseudocode.
 - **Comments explain the non-obvious.** Don't comment `// cancel the turn`
-  above `turn.cancel()`. Do comment `// fire-and-forget - POST doesn't block
-  the stream return`.
+  above `turn.cancel()`. Do comment
+  `// fire-and-forget - POST doesn't block the stream return`.
 - **TypeScript only** for now (the SDK is TypeScript).
 - **Both sides.** Feature pages show client and server code. Use section
   headers to separate them.
@@ -273,11 +277,13 @@ readers skim, and the link needs to be where the concept appears.
 
 ```markdown
 <!-- Good: inline link where the concept is mentioned -->
+
 The [decoder](decoder.md) accumulates deltas via string concatenation and
 uses [prefix-matching](decoder.md#known-serial-prefix-match) to detect
 whether an update is incremental or a replacement.
 
 <!-- Bad: concept mentioned without link, with "See also" at the bottom -->
+
 The decoder accumulates deltas via string concatenation and uses
 prefix-matching to detect whether an update is incremental or a replacement.
 ...
@@ -351,14 +357,14 @@ docs/
 
 **Page type by directory:**
 
-| Directory | Page type | Pattern |
-|---|---|---|
-| `concepts/` | Concept page | Definition → architecture → data flow → key details |
-| `get-started/` | Quickstart | Prerequisites → step-by-step → "what's happening" → next steps |
-| `frameworks/` | Framework guide | What the framework provides → what's missing → how AIT fills gaps → integration paths |
-| `features/` | Feature page | Definition → problem framing → mechanism → client code → server code → edge cases |
-| `reference/` | Reference page | One section per API item: signature, params table, return type, example |
-| `internals/` | Internals page | Definition → concepts → operations → algorithms → edge cases → cross-refs |
+| Directory      | Page type       | Pattern                                                                               |
+| -------------- | --------------- | ------------------------------------------------------------------------------------- |
+| `concepts/`    | Concept page    | Definition → architecture → data flow → key details                                   |
+| `get-started/` | Quickstart      | Prerequisites → step-by-step → "what's happening" → next steps                        |
+| `frameworks/`  | Framework guide | What the framework provides → what's missing → how AIT fills gaps → integration paths |
+| `features/`    | Feature page    | Definition → problem framing → mechanism → client code → server code → edge cases     |
+| `reference/`   | Reference page  | One section per API item: signature, params table, return type, example               |
+| `internals/`   | Internals page  | Definition → concepts → operations → algorithms → edge cases → cross-refs             |
 
 If a page doesn't fit these categories, discuss placement before writing.