stitchkit 0.108.5 → 0.109.1

package/llms/{upgrading-0.59.0-0.71.0.txt → upgrading-0.61.0-0.73.0.txt}

@@ -1,14 +1,133 @@
-# Upgrading 0.59.0 → 0.71.0 — stitchkit docs slice
+# Upgrading 0.61.0 → 0.73.0 — stitchkit docs slice
 
 > Generated from the `docs/` tree by `bun run gen:llms`. The index of all slices is
 > `llms.txt` in this package.
 
-Contains: Guide: Upgrading, 0.59.0 → 0.71.0  (docs/guide/upgrading.md)
+Contains: Guide: Upgrading, 0.61.0 → 0.73.0  (docs/guide/upgrading.md)
 
 ==============================================================================
-# Guide: Upgrading, 0.59.0 → 0.71.0  (docs/guide/upgrading.md)
+# Guide: Upgrading, 0.61.0 → 0.73.0  (docs/guide/upgrading.md)
 ==============================================================================
 
+## Released migration: 0.73.0
+
+Two breaking changes. Nothing you send to a server changed, and only one of these
+can reach a call site the compiler already checks.
+
+### If you call `withOptions` from a call site that lost its types
+
+`withOptions` takes one argument on an endpoint with no contract input, two when
+there is one. Passing two to a no-input endpoint used to succeed and silently
+drop the options: the request went out **uncancelled**, the caller still received
+`REQUEST_ABORTED` — cancellation is decided from the signal it was handed, not
+from what the transport did — and the server ran the operation to its own
+deadline. Every symptom then points at the transport, and the investigation goes
+there. It now throws a `TypeError` naming the endpoint and the correct shape.
+
+```ts
+// before — the options were dropped and the request was never cancelled
+api.ping.withOptions({}, { signal })
+
+// after
+api.ping.withOptions({ signal })
+```
+
+A typed call site already refused the wrong arity, so this reaches only code that
+does not have the types: a `Record<string, …>` view of the client, a hand-written
+double, a dynamic dispatch. The guard counts arguments and never reads them, so a
+method handed to a callback API behaves exactly as before.
+
+### If you match on `ApiError.message`
+
+An `ApiError` that nothing explained used to carry `API Error: ${code}` — a
+string that reads like an explanation while only restating the code, so a caller
+could not tell an origin that explained a failure from one that said nothing. It
+now says which it is.
+
+```ts
+// before
+err.message === 'API Error: INVALID_INPUT'
+
+// after
+err.message === 'INVALID_INPUT (no message supplied)'   // better: match err.code
+```
+
+Match `err.code` instead: it is the contract, and it did not change. An error
+carrying a real message is untouched. An empty message now counts as no message,
+for the same reason — an empty string is not an explanation either.
+
+### If a diagnostic journal lock file is already on disk
+
+One operator step, and only on a host that has been **renamed** since its lock was written.
+
+A lock written before this version carries no machine identity, so there is nothing to compare and
+the host name is all that is left. If the name still matches, the lock reclaims exactly as it always
+did and there is nothing to do. If the name has changed, the lock is `unattributable` and is refused
+— the same refusal this release exists to end, except that this particular file predates the fix and
+cannot be repaired from the inside. Delete it once:
+
+```sh
+rm <journal path>.lock   # only when the host was renamed since the file was written
+```
+
+Locks written from this version on carry the machine identity, so the situation cannot recur. To see
+which case you are in without guessing, read the refusal instead of the file:
+`readDiagnosticJournalLockDiagnosis(err)` returns `attribution: 'unattributable'` for exactly this
+one, and `'another-machine'` for a lock that genuinely belongs elsewhere and must **not** be deleted.
+
+Two related fixes need no migration, but change what you will see. An error the
+transport raised through `createHttpClient` now carries the transport's own text
+in `message` and the original error as `cause`, where before it carried neither
+and filed the text under `details.message` alone; if you followed the retry rule
+in [the client guide](./client.md) — inspect the adapter's `cause`, retry only
+when it proves dispatch did not happen — that rule was not executable on this
+transport and now is. And the client guide now states which direction validation
+runs: responses are checked against `output`, arguments are **not** checked
+before being sent.
+
+## Released migration: 0.72.0
+
+Nothing you *pass* changed. Both items are about types you read or build, and
+both stop the compiler rather than surprising you at runtime.
+
+### If you read `perKey` off `BoundedAdmissionPolicy`
+
+`perKey` is now a union: the flat ceiling it always was, or `{ maxKeys, limits }`
+where the ceiling is resolved from the key. Declaring one is unchanged; reading
+one needs a narrowing.
+
+```ts
+// before
+const ceiling = policy.perKey?.maxConcurrent
+
+// after
+const ceiling =
+  policy.perKey && !('limits' in policy.perKey) ? policy.perKey.maxConcurrent : undefined
+```
+
+A shape carrying members of both branches — `{ maxKeys, maxConcurrent, limits }` —
+is refused. **In 0.72.0 and 0.72.1 that refusal came only from
+`createBoundedAdmission`**, not from `tsc`: an excess-property check against a
+union admits any property some member declares, so the mixed shape typechecked
+and threw when the admission was built. From **0.72.2** each branch declares the
+other's members as `never`, so it is a compile error. Nothing about the runtime
+changed — both branches always refused it — but on a path your tests do not
+construct, the earlier versions would have told you in production.
+
+### If you build a snapshot or a status by hand
+
+`CreditWindowSnapshot` gained `waiting` (producers parked in the new waiting
+`acquire`) and `DiagnosticJournalStatus` gained `lock`. Both are produced by the
+framework, so reading them is unaffected — but a test double stops compiling:
+
+```ts
+// before
+const snapshot: CreditWindowSnapshot = { state: 'open', capacityBytes: 100, /* … */ }
+
+// after
+const snapshot: CreditWindowSnapshot = { state: 'open', capacityBytes: 100, /* … */ waiting: 0 }
+```
+
 ## Released migration: 0.71.0
 
 The Agent coding tools. Two of the three changes are visible to the compiler;
@@ -914,229 +1033,3 @@ The refusals now say which of the two happened: a resource that was never
 healthy is told it "is not healthy" and pointed at `required: false`; one that
 was healthy and stopped is told it "lost readiness" and pointed at
 `onResourceFailure`.
-
-## Released migration: 0.60.0
-
-### close() says what it achieved
-
-`AgentRuntime.close()` returned `Promise<void>` and its contract promised three
-things that cannot hold together. It now returns
-`{ settled, timedOut, remaining }`.
-
-Nothing breaks if you ignore the value:
-
-```ts
-await runtime.close({ gracePeriodMs: 30_000, forceTimeoutMs: 5_000 })
-```
-
-What DOES change is any code that relied on the old sentence "`close()` never
-returns while a run is still in flight" while naming a `forceTimeoutMs`. That
-was never true — the force budget exists precisely to stop waiting — so if your
-process exits straight after `close()`, read the result:
-
-```ts
-const closed = await runtime.close({ gracePeriodMs: 30_000, forceTimeoutMs: 5_000 })
-if (!closed.settled) {
-  // `closed.remaining` runs were still in flight. They stay recoverable
-  // through `scanRecoverable`; close never marks them terminal on its own.
-  logger.warn({ remaining: closed.remaining }, 'exiting with runs in flight')
-}
-```
-
-If you want the old guarantee, omit `forceTimeoutMs`: that is the one
-combination in which `close()` cannot return with a run in flight — and its wait
-is unbounded, which is the trade.
-
-A TypeScript consumer that wrote `const done: void = await runtime.close()` is
-the only shape that stops compiling.
-
-### one name per concept
-
-`AgentModelDeclaration` was a bare alias of `AgentModelDescriptor`, so the same
-type reached consumers under two exported names:
-
-```ts
-// before
-defineModelRegistry<Record<string, AgentModelDeclaration>>({ … })
-// after
-defineModelRegistry<Record<string, AgentModelDescriptor>>({ … })
-```
-
-A find-and-replace covers it; there is no behavioural change. Kept name is
-`AgentModelDescriptor`, the one paired with `AgentModelDescriptorSchema` and
-returned by `registry.descriptor()`.
-
-Two names that look like the same case and are **not** being merged:
-`SocketEventMap` aliases Socket.IO's `EventsMap` so a vendor's name stays out of
-our signatures, and `AgentRun.ownerId` holds the same value a runtime publishes
-as `runtimeEpoch` on its events. The latter is one identity in two roles — "who
-owns this run" and "which runtime emitted this event" — and both declarations
-now say so. Renaming either would make the fencing comparison read worse.
-
-### a reachable public surface
-
-Three exports that the public API required and did not provide, plus one option
-it accepted and ignored.
-
-```ts
-// before — identified by string, because the class was exported nowhere
-if (error instanceof Error && error.name === 'AgentRuntimeConflictError') …
-// after
-import { AgentRuntimeConflictError } from 'stitchkit/agent-runtime'
-if (error instanceof AgentRuntimeConflictError) …
-```
-
-`ActivityTokenBrand` is exported, so `ActivityProjection` can be implemented by
-a test double. `STITCH_ERROR_STATUS` gained `APPLICATION_NOT_ACCEPTING` (503) —
-only an exhaustive `satisfies Record<StitchErrorCode, …>` map stops compiling,
-and the fix is one line. (`GRAMMY_WEBHOOK_NOT_ACCEPTING` joined it in 0.60.1,
-under the same rule — see ADR 0105. This section briefly said the opposite: that
-an adapter's code stays out of the registry. It does not, and leaving it out was
-the worse of the two, because `isStitchErrorCode` then answered `false` and the
-code reached the wire spelled stitchkit's way, past both `codeMap` and
-`unmappedCode`.)
-
-`application.shutdown()` no longer accepts `retryAfterSeconds`. Delete it from
-the call — the kernel never read it. If you meant the HTTP `Retry-After` a
-draining server sends, that lives on `managedServerResource({ retryAfterSeconds })`,
-where it always did the work.
-
-### one shutdown vocabulary
-
-```ts
-// before
-await runtime.close({ drainTimeoutMs: 30_000, forceTimeoutMs: 5_000 })
-// after
-await runtime.close({ gracePeriodMs: 30_000, forceTimeoutMs: 5_000 })
-```
-
-The rename is mechanical. The behaviour change under it is not, and it is the
-reason the rename waited: two combinations were traps.
-`close({ drainTimeoutMs })` with no force budget aborted the runs and returned
-**without waiting for them to settle** — so naming a budget gave a weaker
-guarantee than naming none — and `close({ forceTimeoutMs })` with no drain
-budget never read the force budget, leaving an unbounded wait. Both now behave
-as their names say.
-
-> **Superseded.** This section once ended "and `close()` never returns while a
-> run is in flight". That was never true with a force budget — the budget exists
-> to stop waiting — and `close()` now returns `{ settled, timedOut, remaining }`
-> instead of promising it. See *Released migration: 0.60.0 → close() says what
-> it achieved*, above.
-
-If your shutdown path measured how long `close()` took, expect it to take
-longer in exactly the case where it used to return early — that is the fix, not
-a regression. Defaults stay per-surface: `ShutdownOptions.gracePeriodMs`
-defaults to 30 seconds, and the runtime's omitted budget still means "abort
-immediately", the behaviour `close()` has always had.
-
-### unresolved attachments are omitted
-
-`history.unresolvedFile` defaulted to `text`, and the placeholder it produced
-carried the storage reference:
-
-```ts
-// before — the provider received your object key
-// "[attachment: s3://bucket/tenants/42/invoice.pdf]"
-history: {}
-// after — omitted entirely by default; ask for a placeholder explicitly
-history: { unresolvedFile: 'text' }   // "[attachment: invoice.pdf]"
-```
-
-Two things to check. If a prompt relied on the model seeing *something* where an
-unresolved file was, set `unresolvedFile: 'text'` — behaviour otherwise changes
-silently, since an omitted part produces no error. And if any stored transcript
-or provider log contains the old placeholder, it contains your storage layout;
-treat those as disclosed. The `error` policy still names the reference, because
-it is thrown into your process rather than sent upstream.
-
-### one bounded recoverable scan
-
-`AgentRuntimeStore` had two scans: a mandatory unbounded one and an optional
-paged one. The runtime only ever called the optional one, so implementing the
-interface as written produced a store that threw on its first `recover()`:
-
-```ts
-// before — the mandatory member was dead, the needed one was optional
-{
-  scanRecoverable: () => loadEveryRecoverableSnapshot(),
-  scanRecoverablePage: ({ cursor, limit }) => page(cursor, limit),
-}
-// after — one member, the bounded signature the driver already used
-{ scanRecoverable: ({ cursor, limit }) => page(cursor, limit) }
-```
-
-Delete the unbounded implementation rather than porting it: loading every
-recoverable conversation to start is the shape 0.59.0 and ADR 0101 moved away
-from, and nothing calls it now. If you built on `createAgentRuntimeStore()` you
-have nothing to do **if you only pass it to the runtime** — it implements the
-bounded page for you from the same driver member. If you CALL it yourself, the
-member changed shape: `scanRecoverable()` took no argument and returned
-snapshots; it now takes `{ cursor?, limit }` — `limit` is required — and returns
-one page of descriptors.
-```ts
-// before: const stale = await store.scanRecoverable()
-// after:  const { items, nextCursor } = await store.scanRecoverable({ limit: 100 })
-```
-
-### published application status
-
-`createApplicationHealthHandler` and `createApplicationOperationalHandlers` no
-longer serialise the whole `ApplicationSnapshot`. They publish
-`ApplicationStatusProjection` — the verdict plus resource counts:
-
-```ts
-// before — the response named every resource and its dependency edges
-const { resources } = await fetch('/status').then((r) => r.json())
-resources[0].dependsOn
-// after — the topology is read in-process, where it always belonged
-app.getSnapshot().resources[0].dependsOn
-```
-
-The consequence to check is not compilation — it is whatever already consumes
-these routes. A dashboard that drew the dependency graph from `/status`, or an
-alert keyed on `admission.pending`, goes blank rather than red: the fields are
-absent, not zero. Both are available from `getSnapshot()`, so the fix is to read
-them in the process that owns the application and publish them on a channel you
-control. If a route was reachable from outside your network, treat the previous
-payload as disclosed and rotate nothing but assume the topology is known.
-
-## Released migration: 0.59.0
-
-### Normalized agent runtime persistence
-
-`AgentRuntimeStoreDriver` no longer reads and rewrites a lifetime `AgentStoredState` JSON
-aggregate. Migrate that row and its recoverable/archive projections once:
-
-1. Copy `conversationId` and `version` into the bounded runtime head.
-2. Write every `AgentStoredState.runs[]` entry as one normalized run record.
-3. Write every `AgentStoredState.admissions[]` entry as one admission receipt and copy its
-   canonical input into that receipt.
-4. For terminal runs, retain the canonical assistant on the run record before deleting any old
-   history/archive rows.
-5. Replace the recoverable projection with an index over normalized run `state`.
-6. Cut the adapter over atomically; there is no compatibility driver or dual-write mode.
-
-```ts
-// before
-createAgentRuntimeStore({
-  state: { load, compareAndSwap },
-  history: { load, loadById, apply },
-  scanRecoverable,
-})
-
-// after
-createAgentRuntimeStore({
-  head: { load, compareAndSwap },
-  runs: { load, loadByAssistantMessageId, loadMany, listActive, save },
-  admissions: { load, loadByInputMessageId, create },
-  history: { load, apply },
-  scanRecoverable,
-})
-```
-
-`AgentRuntimeHeadSchema`, `AgentStoredRunSchema` and `AgentAdmissionReceiptSchema` replace
-`AgentStoredStateSchema` and `AgentAdmissionIdentitySchema`. Run
-`runAgentStoreConformance()` against the migrated adapter before switching production traffic.
-If an application implements `AgentRuntimeStore` directly, its duplicate result must also include
-the canonical `run` and the retained `assistant` for a terminal run.

package/llms/{upgrading-0.72.0-0.99.0.txt → upgrading-0.74.0-0.100.0.txt}

@@ -1,14 +1,83 @@
-# Upgrading 0.72.0 → 0.99.0 — stitchkit docs slice
+# Upgrading 0.74.0 → 0.100.0 — stitchkit docs slice
 
 > Generated from the `docs/` tree by `bun run gen:llms`. The index of all slices is
 > `llms.txt` in this package.
 
-Contains: Guide: Upgrading, 0.72.0 → 0.99.0  (docs/guide/upgrading.md)
+Contains: Guide: Upgrading, 0.74.0 → 0.100.0  (docs/guide/upgrading.md)
 
 ==============================================================================
-# Guide: Upgrading, 0.72.0 → 0.99.0  (docs/guide/upgrading.md)
+# Guide: Upgrading, 0.74.0 → 0.100.0  (docs/guide/upgrading.md)
 ==============================================================================
 
+## Released migration: 0.100.0
+
+### watch capacity and session/live/delivery adoption
+
+**Who must act:** watch consumers exceeding 1024 hub sources, 1024 hub subscribers,
+1024 client keys or 128 listeners per key. These previously unbounded collections
+now refuse excess admission. Choose explicit positive finite limits, for example:
+
+```ts
+// Before: no hub-wide capacity bounds.
+createWatchHub({ read, watchable });
+// After: explicitly budget a larger workload.
+createWatchHub({ read, watchable, maxSources: 4096, maxSubscribers: 4096 });
+// Client limits are configured independently.
+createWatchClient({ ...clientConfig, maxKeys: 2048, maxListenersPerKey: 256 });
+```
+
+The remaining steps apply only to applications opting into session lifetimes,
+scoped watched reads, managed subscriptions or multi-action notification delivery.
+Existing clients within the limits and single-send outboxes need no migration.
+
+Replace local session generation counters with one `createSessionScope`; share it
+with `createSessionCredentials`. Guard transport attempts, complete asynchronous
+operations and final synchronous delivery. Route credential persistence through
+one coordinator. Keep provider-specific error classification and bounded command
+retry in the application. Coordination is per client instance.
+
+Upgrade both watch endpoints before enabling session-scoped watches: strict older
+servers reject the new optional `WatchKey.instance`. Server-verified scope controls
+sharing; the client instance is only routing identity. Bind exact watched handles
+to session-qualified cache keys. Existing delta/reconnect behavior stays in place.
+For applications needing more than 1024 hub sources/subscribers or client keys, set
+explicit finite capacity options. Enable a reconciliation interval when lost hints
+must recover without a reconnect.
+
+For multi-action outboxes, enqueue new items with a versioned delivery plan and
+return small JSON receipts from `send`. Existing queued single-send items should
+be drained before enabling a delivery executor on that queue, or migrated under
+the store's atomic transition. When a new executor version ships, list the old
+version's projection in `delivery.retiredVersions` until its queued items drain;
+a plan version with no executor waits, reported to `onError` as
+`NotificationPlanVersionError` (from 0.100.1).
+Make projection idempotent. Provider idempotency/reconciliation remains necessary
+for a crash between remote success and checkpoint. These APIs are available starting with 0.100.0.
+
+### exclusive lock recovery
+
+New lock and reclaim-guard records include `owner.process`: kernel boot identity,
+process birth token and namespace. `readDiagnosticJournalLockDiagnosis(error)`
+adds `identity` to distinguish matched lifetime evidence, PID reuse, a different
+boot, an absent PID, a legacy record or unavailable identity. Legacy `alive` only
+means the PID is present; it does not prove that the recorded writer still exists.
+
+**Who must act:** deployments recovering a legacy lock with a reused live PID,
+or bundling file-lock consumers into a standalone Darwin executable. Legacy
+records cannot safely infer their missing boot/start identity from `acquiredAt`.
+Stop all writers to that resource, verify exclusive ownership, preserve the old
+lock for incident evidence outside the active lock path, and restart with the
+new package. Never delete a lock merely because it is old. New acquisitions
+write the modern record; no journal data migration is needed.
+
+Darwin distributions must retain the package's architecture-matched native
+`.node` asset for process birth measurement, as for contained filesystem access.
+If native/proc identity cannot be read, new locks explicitly record null and
+recovery refuses rather than treating unknown ownership as death. From 0.100.1 a
+Linux kernel without time namespaces (before 5.6) records the PID namespace alone
+instead of null, so its locks recover like any other. Existing
+`refuse` policy and the separately configured ownerless-file grace are unchanged.
+
 ## Released migration: 0.99.0
 
 ### structural alternatives in flattened tool schemas
@@ -1018,122 +1087,3 @@ Not a migration, but worth knowing: a missing multipart file used to be reported
 `UNKNOWN_ERROR`, the code that means *this client cannot tell you what happened*, on the one refusal
 where it is certain nothing was sent. → ADR 0148 carries the reasoning, including why argument
 validation stays on the server.
-
-## Released migration: 0.73.0
-
-Two breaking changes. Nothing you send to a server changed, and only one of these
-can reach a call site the compiler already checks.
-
-### If you call `withOptions` from a call site that lost its types
-
-`withOptions` takes one argument on an endpoint with no contract input, two when
-there is one. Passing two to a no-input endpoint used to succeed and silently
-drop the options: the request went out **uncancelled**, the caller still received
-`REQUEST_ABORTED` — cancellation is decided from the signal it was handed, not
-from what the transport did — and the server ran the operation to its own
-deadline. Every symptom then points at the transport, and the investigation goes
-there. It now throws a `TypeError` naming the endpoint and the correct shape.
-
-```ts
-// before — the options were dropped and the request was never cancelled
-api.ping.withOptions({}, { signal })
-
-// after
-api.ping.withOptions({ signal })
-```
-
-A typed call site already refused the wrong arity, so this reaches only code that
-does not have the types: a `Record<string, …>` view of the client, a hand-written
-double, a dynamic dispatch. The guard counts arguments and never reads them, so a
-method handed to a callback API behaves exactly as before.
-
-### If you match on `ApiError.message`
-
-An `ApiError` that nothing explained used to carry `API Error: ${code}` — a
-string that reads like an explanation while only restating the code, so a caller
-could not tell an origin that explained a failure from one that said nothing. It
-now says which it is.
-
-```ts
-// before
-err.message === 'API Error: INVALID_INPUT'
-
-// after
-err.message === 'INVALID_INPUT (no message supplied)'   // better: match err.code
-```
-
-Match `err.code` instead: it is the contract, and it did not change. An error
-carrying a real message is untouched. An empty message now counts as no message,
-for the same reason — an empty string is not an explanation either.
-
-### If a diagnostic journal lock file is already on disk
-
-One operator step, and only on a host that has been **renamed** since its lock was written.
-
-A lock written before this version carries no machine identity, so there is nothing to compare and
-the host name is all that is left. If the name still matches, the lock reclaims exactly as it always
-did and there is nothing to do. If the name has changed, the lock is `unattributable` and is refused
-— the same refusal this release exists to end, except that this particular file predates the fix and
-cannot be repaired from the inside. Delete it once:
-
-```sh
-rm <journal path>.lock   # only when the host was renamed since the file was written
-```
-
-Locks written from this version on carry the machine identity, so the situation cannot recur. To see
-which case you are in without guessing, read the refusal instead of the file:
-`readDiagnosticJournalLockDiagnosis(err)` returns `attribution: 'unattributable'` for exactly this
-one, and `'another-machine'` for a lock that genuinely belongs elsewhere and must **not** be deleted.
-
-Two related fixes need no migration, but change what you will see. An error the
-transport raised through `createHttpClient` now carries the transport's own text
-in `message` and the original error as `cause`, where before it carried neither
-and filed the text under `details.message` alone; if you followed the retry rule
-in [the client guide](./client.md) — inspect the adapter's `cause`, retry only
-when it proves dispatch did not happen — that rule was not executable on this
-transport and now is. And the client guide now states which direction validation
-runs: responses are checked against `output`, arguments are **not** checked
-before being sent.
-
-## Released migration: 0.72.0
-
-Nothing you *pass* changed. Both items are about types you read or build, and
-both stop the compiler rather than surprising you at runtime.
-
-### If you read `perKey` off `BoundedAdmissionPolicy`
-
-`perKey` is now a union: the flat ceiling it always was, or `{ maxKeys, limits }`
-where the ceiling is resolved from the key. Declaring one is unchanged; reading
-one needs a narrowing.
-
-```ts
-// before
-const ceiling = policy.perKey?.maxConcurrent
-
-// after
-const ceiling =
-  policy.perKey && !('limits' in policy.perKey) ? policy.perKey.maxConcurrent : undefined
-```
-
-A shape carrying members of both branches — `{ maxKeys, maxConcurrent, limits }` —
-is refused. **In 0.72.0 and 0.72.1 that refusal came only from
-`createBoundedAdmission`**, not from `tsc`: an excess-property check against a
-union admits any property some member declares, so the mixed shape typechecked
-and threw when the admission was built. From **0.72.2** each branch declares the
-other's members as `never`, so it is a compile error. Nothing about the runtime
-changed — both branches always refused it — but on a path your tests do not
-construct, the earlier versions would have told you in production.
-
-### If you build a snapshot or a status by hand
-
-`CreditWindowSnapshot` gained `waiting` (producers parked in the new waiting
-`acquire`) and `DiagnosticJournalStatus` gained `lock`. Both are produced by the
-framework, so reading them is unaffected — but a test double stops compiling:
-
-```ts
-// before
-const snapshot: CreditWindowSnapshot = { state: 'open', capacityBytes: 100, /* … */ }
-
-// after
-const snapshot: CreditWindowSnapshot = { state: 'open', capacityBytes: 100, /* … */ waiting: 0 }
-```

package/llms/upgrading.txt

@@ -11,10 +11,11 @@ Contains: Guide: Upgrading, general  (docs/guide/upgrading.md)
 
 Load this slice, then every range slice between your installed version and the target:
 
-- 0.100.0 → 0.108.0: `llms/upgrading-0.100.0-0.108.0.txt`
-- 0.72.0 → 0.99.0: `llms/upgrading-0.72.0-0.99.0.txt`
-- 0.59.0 → 0.71.0: `llms/upgrading-0.59.0-0.71.0.txt`
-- 0.37.0 → 0.58.0: `llms/upgrading-0.37.0-0.58.0.txt`
+- 0.101.0 → 0.109.0: `llms/upgrading-0.101.0-0.109.0.txt`
+- 0.74.0 → 0.100.0: `llms/upgrading-0.74.0-0.100.0.txt`
+- 0.61.0 → 0.73.0: `llms/upgrading-0.61.0-0.73.0.txt`
+- 0.44.0 → 0.60.0: `llms/upgrading-0.44.0-0.60.0.txt`
+- 0.37.0 → 0.37.0: `llms/upgrading-0.37.0.txt`
 
 # Upgrading stitchkit