stitchkit 0.108.4 → 0.109.0

package/llms-full.txt

@@ -75,12 +75,12 @@ own, recorded as an ADR.
 | `stitchkit/geo` | server (Bun or Node) | evolving | managed GeoIP reader generations, last-known-good reload and the optional MaxMind adapter |
 | `stitchkit/oauth` | browser **and** server | evolving | provider-neutral Authorization Code + PKCE request and one-shot callback transaction mechanics |
 | `stitchkit/google` | server (Bun or Node) | evolving | optional Google code exchange and verified OIDC identity adapter |
-| `stitchkit/observability` | server | stable<br>_redefined in 2 of the 53 minors since 0.56.2, most recently 0.92.0_ | request/tool event projections — `createObservability`, trace context, sanitisation |
+| `stitchkit/observability` | server | stable<br>_redefined in 2 of the 54 minors since 0.56.2, most recently 0.92.0_ | request/tool event projections — `createObservability`, trace context, sanitisation |
 | `stitchkit/testing` | tests on Bun or Node | stable | in-process generated clients over a real Fetch handler, the managed-resource conformance kit and manual time for schedules and retries |
 | `stitchkit/declaration` | browser + build and deployment tooling (Bun or Node) | evolving | `ProjectDeclarationSchema` — the one machine-readable statement a repository makes about itself |
 | `stitchkit/react` | browser + server rendering | stable | `createCursorQuery`, `createCacheBridge`, QueryClient and `ApiError` retry policy |
 | `stitchkit/react/keyboard` | browser | evolving | which part of a screen gets a key — ordered layers, one Escape per level, list zones with real focus; see [keyboard guide](keyboard.md) |
-| `stitchkit/agent-runtime` | server | evolving<br>_redefined in 23 of the 53 minors since 0.56.2, most recently 0.105.0_ | optional durable conversation/run loop, history, models, prompts, fencing and events |
+| `stitchkit/agent-runtime` | server | evolving<br>_redefined in 23 of the 54 minors since 0.56.2, most recently 0.105.0_ | optional durable conversation/run loop, history, models, prompts, fencing and events |
 | `stitchkit/agent-runtime/sandbox` | server | evolving | optional Linux Bubblewrap sessions, durable workspaces and a host HTTP credential gateway; see [sandbox guide](sandbox.md) |
 | `stitchkit/agent-runtime/testing` | tests on Bun or Node | evolving | credential-free replay, scripted provider faults, deterministic race controls and the agent-store conformance kit |
 | `stitchkit/agent-runtime/harness` | server | evolving | resource-aware process-local facade over the canonical Agent runtime; supervision stays outside |
@@ -92,7 +92,7 @@ own, recorded as an ADR.
 | `stitchkit/agent-runtime/sqlite/bun` | server (Bun) | evolving | durable built-in SQLite store for the agent runtime |
 | `stitchkit/agent-runtime/sqlite/node` | server (Node ≥ 22.5) | evolving | durable built-in SQLite store for the agent runtime |
 | `stitchkit-tui` | terminal (Bun) | evolving | optional official OpenTUI host over a caller-composed headless runtime |
-| `stitchkit/application` | browser + server | evolving<br>_redefined in 13 of the 53 minors since 0.56.2, most recently 0.105.0_ | managed resource graph, readiness, admission, schedules, subtree restart and bounded shutdown |
+| `stitchkit/application` | browser + server | evolving<br>_redefined in 13 of the 54 minors since 0.56.2, most recently 0.105.0_ | managed resource graph, readiness, admission, schedules, subtree restart and bounded shutdown |
 | `stitchkit/application/grammy` | server | evolving | a grammY bot as application resources — configuration, then polling with updates admitted by batch — and the webhook adapter |
 | `stitchkit/application/opentelemetry` | server | evolving | maps application snapshots onto an injected OpenTelemetry `Meter` |
 | `stitchkit/application/schemas` | browser + server | evolving | the application's snapshot, health and shutdown schemas alone, without the kernel |
@@ -2785,6 +2785,13 @@ preserve facts the generic client cannot invent — for example a Unix transport
 an effect from `UNKNOWN_ERROR` alone; inspect the owned adapter's cause and retry
 only when it proves that dispatch did not happen.
 
+The same evidence survives when caller abort or the request deadline wins the
+race: the public code remains `REQUEST_ABORTED` or `REQUEST_TIMEOUT`, while
+the exact rejection produced by the transport remains in `ApiError.cause`.
+That cause is internal diagnostic data — it is not included by JSON/string
+rendering — so delivery state and trace metadata remain available without
+putting transport payloads or credentials in a client-facing error.
+
 For an endpoint without contract arguments, pass only the options object:
 
 ```ts
@@ -9648,12 +9655,24 @@ string, the schema says what it should be:
 | `z.enum([...])`      | `--size large`                                 |
 | `z.array(z.string())`| `--tag a --tag b` → `["a","b"]`                |
 | `z.object({...})`    | `--opts '{"k":"v"}'` (JSON) or `--opts.k v`    |
+| `z.record(z.string(), z.unknown())` | `--data '{"code":"007"}'` or `--data.code=007` → `"007"` |
 | `.optional()` / `.default()` | not required                           |
 
 Primitive literals use the same coercion through optional, nullable and default wrappers and as
 array elements. A literal set whose members have different primitive types stays lexical because
 argv has no type tag: for `z.literal([7, '007'])`, `--value 007` remains the string `"007"` rather
 than being guessed as the number `7`. The unchanged Zod schema makes the final admission decision.
+Object and record JSON keeps the same behavior when a CLI discovers a tool through MCP. Restored
+`propertyNames`, `minProperties` and `maxProperties` constraints still run before dispatch; CLI
+coercion does not execute application transforms.
+
+A dotted leaf follows the leaf schema, including through optional/nullable wrappers and restored
+MCP object guards. A declared number or boolean is coerced; a string stays byte-for-byte lexical.
+For a free `z.record(z.string(), z.unknown())`, argv provides no JSON type tag, so the dotted
+value also stays a string: `007`, `+007`, `1e3`, `true` and `false` keep those spellings.
+Use the whole-object JSON form when a free record value must be a JSON number or boolean. This
+avoids silently changing identifiers while keeping `z.record(..., z.number())` and
+`z.record(..., z.boolean())` explicitly typed.
 
 After a bare boolean flag, the next token is its value when it is exactly
 `true` or `false` — `--active false` turns it off, as it reads. Any other word
@@ -15260,9 +15279,10 @@ import { Database } from 'bun:sqlite'
 import type { Update } from 'grammy/types'
 
 const webhook = { token: env.BOT_TOKEN, url: env.WEBHOOK_URL, secret: env.WEBHOOK_SECRET }
+const updateStore = sqliteTelegramUpdateStore({ database: new Database(env.UPDATES_DB) })
 
 const intake = createTelegramUpdateIntake<Update>({
-  store: sqliteTelegramUpdateStore({ database: new Database(env.UPDATES_DB) }),
+  store: updateStore,
   handle: (update) => bot.handleUpdate(update),
   onFailure: (failure) => logger.warn('Update failed', { ...failure }),
 })
@@ -15306,13 +15326,55 @@ fix (a refused message, a blocked user) is abandoned; `maxAttempts` (5) ends
 the rest. Delivery is at least once: a handler that finished but could not be
 recorded as finished runs again.
 
+Use `handleAttempt` when the handler needs the immutable attempt fence and an
+ownership-loss signal. A signal asks slow work to stop; the fence is what
+authorizes a domain write. Check it through a transaction-bound reference store
+inside the same database transaction as that write:
+
+```ts
+handleAttempt: async (update, { fence, ownerLost }) => {
+  ownerLost.throwIfAborted()
+  await database.transaction(async (tx) => {
+    const transactionStore = postgresTelegramUpdateStore({
+      query: (text, parameters) => tx.query(text, parameters),
+      createTable: false,
+    })
+    if (!(await transactionStore.owns(fence, Date.now()))) return
+    await applyDomainTransition(tx, update)
+  })
+}
+```
+
+The fence contains the claim's own `{ updateId, attempt, claimId }`. The opaque
+`claimId` is persisted and never reused, so an old handler cannot adopt either
+a newer attempt or a pruned and recreated `updateId`. Existing `handle(update)`
+remains unchanged, including direct functions whose own optional second
+argument has a different meaning.
+
+For a final obligation, configure `handleExhaustion`. The reference store keeps
+the terminal record unacknowledged until this handler resolves, including
+across restart; a throw leaves it for the next sweep. Delivery is at least once,
+so use the complete `{ updateId, attempt, claimId }` as an idempotency key in
+the consumer database:
+
+```ts
+handleExhaustion: ({ updateId, attempt, claimId, update, error }) =>
+  recordFinalFailureOnce({ key: `telegram:${updateId}:${attempt}:${claimId}`, update, error })
+```
+
+This reuses the update row and table. Without `handleExhaustion`, terminal
+abandonment retains its previous behavior.
+
 With grammY the handler is `bot.handleUpdate`, which wraps a middleware's error
 in a `BotError`; the intake unwraps it, so `retry`, `onFailure` and the error
 stored with the update are what the middleware threw — a `retry` that returns
 `false` for the bot's own terminal error sees that error.
 
-The store is an interface of six atomic steps (`TelegramUpdateStore`), so the
-bot's own database holds it:
+The base store remains the six atomic steps of `TelegramUpdateStore`. A
+`TelegramUpdateFencedStore` adds `claimOwned`, `renewOwned`, `owns` and
+`settleOwned`; `TelegramUpdateDurableStore` adds the final-obligation methods.
+Reference stores implement both, so the bot's own database holds the fence and
+final obligation without a second queue:
 
 | Store | Takes |
 |---|---|
@@ -15339,7 +15401,12 @@ postgresTelegramUpdateStore({
 Each rule is one conditional statement, so a claim is atomic across every
 process sharing the table. By default the table is created on first use; where
 migrations own the schema, `postgresTelegramUpdateStoreSchema(table)` is the
-statement to put in one.
+statement to put in one. Apply it before using `handleAttempt` or
+`handleExhaustion`; it adds `claim_id` idempotently. Legacy `handle(update)`
+uses base PostgreSQL operations that do not reference that column. SQLite adds
+the column automatically and tolerates two rolling processes racing the
+migration. A direct base-store claim with `durableExhaustion: true` also opts
+into the column-backed durable capability.
 
 A store of your own — over an ORM, another database — is put through the same
 rules the shipped ones are, concurrent claims included:
@@ -15794,6 +15861,73 @@ analytics policy belong to the application.
 
 # Upgrading stitchkit
 
+## Released migration: 0.109.0
+
+### free CLI record leaves are lexical
+
+**Who must act:** scripts that pass dotted values into a free `record<string, unknown>` and rely on
+stitchkit guessing numbers or booleans from their spelling. Declared object leaves and whole-object
+JSON keep their typed behavior.
+
+Free record values have no schema type to justify coercion. They now preserve argv text, so values
+such as `007`, `1e3`, `true` and `false` arrive exactly as written.
+See [ADR 0257](../decisions/0257-cli-dotted-values-follow-their-declared-schema.md).
+
+1. Pass typed free-record values as one JSON object:
+
+   ```sh
+   # before: produced { count: 5 } by spelling-based inference
+   app command --data.count=5
+   # after: JSON says explicitly that 5 is a number
+   app command --data='{"count":5}'
+   ```
+
+2. If dotted flags are the intended interface, declare their object shape; a `z.number()` or
+   `z.boolean()` leaf still coerces and validates its own CLI value.
+
+### Opting into Telegram attempt fencing
+
+Existing `handle(update)` callbacks and the six-method `TelegramUpdateStore` need no change. The
+new capability is opt-in
+([ADR 0256](../decisions/0256-a-telegram-attempt-is-fenced-by-a-persisted-claim.md)).
+
+1. To fence a domain write, move only that handler to the explicit context-aware option:
+
+   ```ts
+   createTelegramUpdateIntake({
+     store,
+     handleAttempt: async (update, { fence, ownerLost }) => {
+       ownerLost.throwIfAborted()
+       await domainTransaction(async (tx) => {
+         if (await transactionStore(tx).owns(fence, Date.now())) await apply(tx, update)
+       })
+     },
+   })
+   ```
+
+2. A direct grammY handler remains `handle: bot.handleUpdate.bind(bot)`; stitchkit does not pass its
+   attempt context into grammY's optional webhook-envelope parameter.
+
+3. A custom store used by `handleAttempt` implements `claimOwned`, `renewOwned`, `owns` and
+   `settleOwned` over the full `{ updateId, attempt, claimId }` identity. If it also delivers
+   `handleExhaustion`, implement `exhaust`, `dueExhaustions` and `acknowledgeExhaustion`. Run
+   `checkTelegramUpdateStore` against a fresh database; it checks base, fenced and durable rules
+   according to the methods the store exposes.
+
+4. SQLite stores add `claim_id` automatically. PostgreSQL stores with the default
+   `createTable: true` do the same. When migrations own a PostgreSQL table, apply the returned
+   schema before enabling `handleAttempt` or `handleExhaustion`:
+
+   ```ts
+   await sql.unsafe(postgresTelegramUpdateStoreSchema('telegram_updates'))
+   // Equivalent addition for an existing table:
+   // ALTER TABLE telegram_updates ADD COLUMN IF NOT EXISTS claim_id TEXT;
+   ```
+
+   Legacy `handle(update)` continues to use base operations that do not reference `claim_id`, so
+   the migration is required only when the new capability or an explicit base
+   `claim(..., { durableExhaustion: true })` is enabled.
+
 ## Released migration: 0.108.0
 
 ### a request that never left is its own send outcome
@@ -22369,7 +22503,7 @@ Advanced building blocks — the shared machinery the mounts are built on.
 | `TransportCounts` | _type_ | per-transport counts (`{ HTTP, MCP, AGENT, CLI }`) |
 | `ToolSurfaceProjection` | _type_ | the one readonly `{ services?, runtimeTools? }` container shared by full, MCP-only and introspection surfaces (`buildToolManifest`, `listToolNames`, `summarizeTransports` take `ToolSurfaceProjection<RuntimeToolDefinition>`) |
 | `ToolManifestConfig` | _type_ | mixed surface plus required model-facing `transport` and presentation options |
-| `coerceJsonArgs` | function | coerce JSON-stringified array/object tool arguments; throws a `ZodError` naming the field when a union that keeps a string member receives a string that parses to an array its array member accepts |
+| `coerceJsonArgs` | function | coerce JSON-stringified array/object tool arguments, including object guards restored from JSON Schema; arbitrary transform pipes stay untouched; throws a `ZodError` naming the field when a union that keeps a string member receives a string that parses to an array its array member accepts |
 | `flattenToolJsonSchema` | function | project structurally identifiable discriminated unions into conservative object joins; scalar collisions retain provable types, object/array collisions retain structural alternatives, and field descriptions retain discriminator labels plus availability/requiredness hints; the projection never executes validation |
 | `ToolPresentationSchema` | _type_ | immutable model-facing JSON Schema document shared by tool transports |
 | `MountableTool` | _type_ | one operation with separate executable CLI argument schema and model-facing presentation schema |
@@ -22571,13 +22705,16 @@ injected grammY bot. → ADR 0143, ADR 0201 — [guide](../guide/telegram.md)
 | `telegramWebhookUrl` | function | the address with an `owner` tag derived from the secret: equal for one secret, different for another, the path untouched |
 | `checkTelegramWebhook` / `TelegramWebhookState` | function / _type_ | whether the webhook still points here: `owned`, `ownerHost`, `pendingUpdates`, Telegram's `lastError` |
 | `receiveTelegramWebhook` / `ReceiveTelegramWebhookOptions` / `TelegramUpdateAcceptance` | function / _type_ | one webhook `Request`: 403 without the secret (compared in constant time), 405 for another method, 400 for no update, 200 once `accept` recorded it |
-| `createTelegramUpdateIntake` | function | webhook updates recorded before Telegram is answered and handled after: chat order kept, other chats alongside up to `maxConcurrent`, a renewed lease per attempt, a sweep that takes over what a restart or a dead process left, retries, `maxAttempts`, finished updates remembered `retainMs` to refuse repeats; at least once |
-| `TelegramUpdateIntakeConfig` / `TelegramUpdateIntake` / `TelegramUpdateEnvelope` / `TelegramUpdateFailure` / `TelegramUpdateStoreStep` | _type_ | `store`, `handle` (a grammY `BotError` is unwrapped: `retry`, `onFailure` and the stored error see what the middleware threw), `retry`, `maxAttempts` (5), `leaseMs` (120 000), `pendingGraceMs` (60 000), `sweepEveryMs` (30 000), `retainMs` (24 h), `maxConcurrent` (32), `onFailure`, `onStoreError`, `now`; `accept(body)`, `start()`, `sweep()`, `idle()`, `close()` |
-| `TelegramUpdateStore` / `StoredTelegramUpdate` / `TelegramUpdateState` / `TelegramUpdateSettlement` / `TelegramUpdateClaimOptions` / `TelegramUpdateDueQuery` | _type_ | the store an intake runs on: `add`, `claim`, `renew`, `settle`, `due`, `prune`, each atomic on one record — a claim takes `pending`, a due `failed` or a lapsed `processing`; renew and settle only by the attempt holding it |
+| `createTelegramUpdateIntake` | function | webhook updates recorded before Telegram is answered and handled after: chat order kept, other chats alongside up to `maxConcurrent`, a renewed lease and immutable fence per attempt, a sweep that takes over what a restart or a dead process left, retries, `maxAttempts`, optional recoverable exhaustion delivery, finished updates remembered `retainMs` to refuse repeats; at least once |
+| `TelegramUpdateIntakeConfig` / `TelegramUpdateAttemptIntakeConfig` / `TelegramUpdateIntakeOptions` / `TelegramUpdateIntake` / `TelegramUpdateEnvelope` / `TelegramUpdateFailure` / `TelegramUpdateStoreStep` | _type_ | `store`, unchanged `handle(update)` or attempt-aware `handleAttempt(update, context)` (a grammY `BotError` is unwrapped), shared `retry`, `maxAttempts` (5), `leaseMs` (120 000), `pendingGraceMs` (60 000), `sweepEveryMs` (30 000), `retainMs` (24 h), `maxConcurrent` (32), `onFailure`, durable `handleExhaustion`, `onExhaustionFailure`, `onStoreError`, `now`; `accept(body)`, `start()`, `sweep()`, `idle()`, `close()` |
+| `TelegramUpdateAttemptContext` / `TelegramUpdateAttemptIdentity` / `TelegramUpdateOwnershipLostError` | _type_ / class | immutable `{ updateId, attempt, claimId }` fence plus `ownerLost`; the persisted opaque claim token prevents a stale capability from matching after prune/re-add, while a store check in the consumer's DB transaction fences a domain write |
+| `TelegramUpdateExhaustion` / `TelegramUpdateExhaustionFailure` / `StoredTelegramUpdateExhaustion` / `TelegramUpdateExhaustionQuery` | _type_ | a terminal update/attempt/error retained in the update store until `handleExhaustion` resolves; ordered `{ limit, afterUpdateId? }` pages prevent a failing first batch from starving later rows; delivery failures are observational and leave it due |
+| `TelegramUpdateStore` / `StoredTelegramUpdate` / `TelegramUpdateState` / `TelegramUpdateSettlement` / `TelegramUpdateClaimOptions` / `TelegramUpdateDueQuery` | _type_ | the base store an intake runs on: `add`, `claim`, `renew`, `settle`, `due`, `prune`, each atomic on one record — a claim takes `pending`, a due `failed` or a lapsed `processing`; renew and settle only by the attempt holding it |
+| `TelegramUpdateFencedStore` / `TelegramUpdateDurableStore` | _type_ | reference-store capabilities: `claimOwned` creates and returns the persisted identity, `renewOwned`, `owns(identity, at)` and `settleOwned(identity, settlement)` act only on that exact unexpired claim; `exhaust`, `dueExhaustions`, `acknowledgeExhaustion` keep a final consumer obligation in the same row until exact acknowledgement |
 | `memoryTelegramUpdateStore` | function | the store in this process's memory — tests, or a bot that accepts losing unhandled updates to a restart |
 | `sqliteTelegramUpdateStore` / `SqliteTelegramUpdateStoreConfig` / `TelegramSqliteDatabase` | function / _type_ | the store in SQLite over the handle the application opened — `bun:sqlite` `Database` or `node:sqlite` `DatabaseSync`; `table` (default `telegram_updates`) created when missing |
 | `postgresTelegramUpdateStore` / `PostgresTelegramUpdateStoreConfig` / `TelegramPostgresQuery` | function / _type_ | the store in Postgres over the client the application holds, as one `query(text, parameters)` returning rows — Bun `sql.unsafe`, Prisma `$queryRawUnsafe`, `pg` `pool.query`; each rule one conditional statement; `table`, `createTable` (default `true`) |
-| `postgresTelegramUpdateStoreSchema` | function | the table and its index as a statement for a migration, safe to run twice |
+| `postgresTelegramUpdateStoreSchema` | function | the table, idempotent `claim_id` upgrade and index as a statement for a migration, safe to run twice; required before fenced methods when `createTable: false`, while legacy base methods remain compatible with the prior table |
 | `checkTelegramUpdateStore` | function | put any store through every rule, each on a fresh store from `make`, concurrent claims included; resolves with the violations, empty when it keeps them |
 
 ---
@@ -22888,7 +23025,7 @@ SDK nor the `ai` peer.
 | `parseCliArgs` | function | argv → typed tool args against a schema (advanced) |
 | `routeCliArgv` | function | select the command out of argv without duplicating the global-option grammar (advanced) |
 | `extractCliGlobalOptions` | function | lift the application's own global options out of argv before routing (advanced) |
-| `coerceJsonArgs` | function | the second half of `parseCliArgs` — parse array/object values a consumer sends itself, without the `stitchkit/tools` barrel |
+| `coerceJsonArgs` | function | the second half of `parseCliArgs` — parse array/object values a consumer sends itself, including discovered MCP object guards restored from JSON Schema, without the `stitchkit/tools` barrel |
 | `CliArgumentError` | class | the refusal `parseCliArgs` and the view flags raise; a CLI reports it and exits `2` |
 | `renderCliView` | function | compute an aggregate over a result (`--count-by`, `--sum`, `--top`, `--table`) — [guide](../guide/cli.md#aggregate-views) |
 | `createCliProfileStore` | function | named `0600` credential profiles resolved by name, with the never-substitute rule built in — [guide](../guide/cli.md#named-profiles) |

package/llms.txt

@@ -9,7 +9,7 @@ Build with stitchkit: define a contract once, then `implement` it and serve it (
 Load the slice for each entrypoint your code imports — `import … from 'stitchkit/server'` → `llms/server.txt`; the root `stitchkit` import → `llms/stitchkit.txt`. A slice holds that entrypoint's API reference section and the guide pages whose home it is; every guide lives in exactly one slice, and a slice that needs another's guide names it under "Also read". Each file is at most 50.0 KB; a longer one continues in numbered parts, each naming the next at its top. Moving across versions: load `llms/upgrading.txt` and the range slices it lists between your version and the target. `llms-full.txt` inlines everything; it is far larger than a context window, so do not read it whole.
 
 ## Entrypoint slices
-- **stitchkit**: [llms/stitchkit.txt](llms/stitchkit.txt) 46.7 KB → [llms/stitchkit.2.txt](llms/stitchkit.2.txt) 36.5 KB
+- **stitchkit**: [llms/stitchkit.txt](llms/stitchkit.txt) 47.2 KB → [llms/stitchkit.2.txt](llms/stitchkit.2.txt) 36.5 KB
 - **stitchkit/live**: [llms/live.txt](llms/live.txt) 21.2 KB
 - **stitchkit/react**: [llms/react.txt](llms/react.txt) 8.6 KB
 - **stitchkit/react/keyboard**: [llms/react-keyboard.txt](llms/react-keyboard.txt) 9.2 KB
@@ -18,7 +18,7 @@ Load the slice for each entrypoint your code imports — `import … from 'stitc
 - **stitchkit/tools/contract**: [llms/tools-contract.txt](llms/tools-contract.txt) 0.2 KB
 - **stitchkit/tools/invoker**: [llms/tools-invoker.txt](llms/tools-invoker.txt) 0.2 KB
 - **stitchkit/tools/connections**: [llms/tools-connections.txt](llms/tools-connections.txt) 3.7 KB
-- **stitchkit/cli**: [llms/cli.txt](llms/cli.txt) 42.8 KB → [llms/cli.2.txt](llms/cli.2.txt) 20.1 KB
+- **stitchkit/cli**: [llms/cli.txt](llms/cli.txt) 43.8 KB → [llms/cli.2.txt](llms/cli.2.txt) 20.2 KB
 - **stitchkit/cli/publish**: [llms/cli-publish.txt](llms/cli-publish.txt) 1.5 KB
 - **stitchkit/remote**: [llms/remote.txt](llms/remote.txt) 1.0 KB
 - **stitchkit/contract**: [llms/contract.txt](llms/contract.txt) 31.9 KB
@@ -42,7 +42,7 @@ Load the slice for each entrypoint your code imports — `import … from 'stitc
 - **stitchkit/testing**: [llms/testing.txt](llms/testing.txt) 33.6 KB
 - **stitchkit/agent-runtime/sandbox**: [llms/agent-runtime-sandbox.txt](llms/agent-runtime-sandbox.txt) 8.3 KB
 - **stitchkit/files**: [llms/files.txt](llms/files.txt) 5.5 KB
-- **stitchkit/telegram**: [llms/telegram.txt](llms/telegram.txt) 32.9 KB
+- **stitchkit/telegram**: [llms/telegram.txt](llms/telegram.txt) 36.6 KB
 - **stitchkit/telegram/html**: [llms/telegram-html.txt](llms/telegram-html.txt) 2.7 KB
 - **stitchkit/telegram/screens**: [llms/telegram-screens.txt](llms/telegram-screens.txt) 21.2 KB
 - **stitchkit/tracking**: [llms/tracking.txt](llms/tracking.txt) 16.8 KB
@@ -61,11 +61,12 @@ Load the slice for each entrypoint your code imports — `import … from 'stitc
 - **stitchkit/files/packaging**: [llms/files-packaging.txt](llms/files-packaging.txt) 3.5 KB
 
 ## Upgrading slices
-- **Upgrading — how to move across versions**: [llms/upgrading.txt](llms/upgrading.txt) 12.1 KB
-- **Upgrading 0.100.0 → 0.108.0**: [llms/upgrading-0.100.0-0.108.0.txt](llms/upgrading-0.100.0-0.108.0.txt) 46.1 KB
-- **Upgrading 0.72.0 → 0.99.0**: [llms/upgrading-0.72.0-0.99.0.txt](llms/upgrading-0.72.0-0.99.0.txt) 46.4 KB
-- **Upgrading 0.59.0 → 0.71.0**: [llms/upgrading-0.59.0-0.71.0.txt](llms/upgrading-0.59.0-0.71.0.txt) 45.6 KB
-- **Upgrading 0.37.0 → 0.58.0**: [llms/upgrading-0.37.0-0.58.0.txt](llms/upgrading-0.37.0-0.58.0.txt) 40.0 KB
+- **Upgrading — how to move across versions**: [llms/upgrading.txt](llms/upgrading.txt) 12.2 KB
+- **Upgrading 0.101.0 → 0.109.0**: [llms/upgrading-0.101.0-0.109.0.txt](llms/upgrading-0.101.0-0.109.0.txt) 45.0 KB
+- **Upgrading 0.74.0 → 0.100.0**: [llms/upgrading-0.74.0-0.100.0.txt](llms/upgrading-0.74.0-0.100.0.txt) 45.1 KB
+- **Upgrading 0.61.0 → 0.73.0**: [llms/upgrading-0.61.0-0.73.0.txt](llms/upgrading-0.61.0-0.73.0.txt) 41.2 KB
+- **Upgrading 0.44.0 → 0.60.0**: [llms/upgrading-0.44.0-0.60.0.txt](llms/upgrading-0.44.0-0.60.0.txt) 43.9 KB
+- **Upgrading 0.37.0 → 0.37.0**: [llms/upgrading-0.37.0.txt](llms/upgrading-0.37.0.txt) 6.2 KB
 
 ## Guide (web)
 - [Getting started](https://github.com/max-listov/stitchkit/blob/master/docs/guide/getting-started.md): install, entrypoints, and a first contract → server → client app

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "stitchkit",
-  "version": "0.108.4",
+  "version": "0.109.0",
   "description": "Contract-first backend framework — one defineContract() into an HTTP API, MCP tools, AI-agent tools and a typed client. Bun and Node.",
   "keywords": [
     "bun",