ts-procedures 7.2.0 → 8.0.0

package/docs/core.md

@@ -10,6 +10,7 @@ The `Procedures()` function creates a factory for defining procedures. It accept
 
 ```typescript
 Procedures<TContext, TExtendedConfig>(builder?: {
+    config?: { noRuntimeValidation?: true }
     onCreate?: (procedure: TProcedureRegistration<TContext, TExtendedConfig>) => void
 })
 ```
@@ -18,6 +19,7 @@ Procedures<TContext, TExtendedConfig>(builder?: {
 |-----------|----------------------------------------------------------------------------|
 | `TContext` | The base context type passed to all handlers as the first parameter        |
 | `TExtendedConfig` | Additional configuration properties for all procedures `config` properties |
+| `builder.config.noRuntimeValidation` | When `true`, every procedure created by this factory skips AJV validation of `schema.params` and `schema.input` at call time. Applies to both `Create` and `CreateStream`. Default: validation runs.   |
 | `builder.onCreate` | Optional callback invoked when each procedure is registered (runtime)      |
 
 ## Create Function
@@ -91,7 +93,7 @@ async function* (ctx, params) => AsyncGenerator<TYield, TReturn | void>
 - `ctx.error(message, meta?)` - Create a ProcedureError
 - `ctx.signal?` - AbortSignal for cancellation support (optional for `Create`, always present for `CreateStream`)
 
-When using the built-in HTTP implementations (Hono, Express), `ctx.signal` is automatically injected from the HTTP request, so handlers can detect client disconnection. For direct usage without a server, `signal` is `undefined` unless you pass one in context.
+When using the built-in HTTP implementation (Hono), `ctx.signal` is automatically injected from the HTTP request, so handlers can detect client disconnection. For direct usage without a server, `signal` is `undefined` unless you pass one in context.
 
 **Returns:**
 - `{ [name]: handler }` - Named generator export
@@ -221,6 +223,22 @@ AJV is configured with:
 
 **Note:** `schema.params` is validated at runtime. `schema.returnType` is for documentation/introspection only.
 
+### Disabling Runtime Validation
+
+For trusted internal callers — for example, a back-of-house factory whose inputs are already type-checked at build time and whose handlers are never invoked from public HTTP — pass `config.noRuntimeValidation: true` when constructing the factory:
+
+```typescript
+const { Create, CreateStream } = Procedures({
+  config: { noRuntimeValidation: true },
+})
+```
+
+When set, every procedure registered by this factory skips AJV validation of `schema.params` and `schema.input` on every call. JSON Schema is still computed at registration time (so `info.schema` and codegen are unaffected) — only the per-call validator runs are bypassed.
+
+**Use sparingly.** Do not enable this for procedures that accept input from public clients, untyped JSON bodies, or anything you do not control end-to-end. The flag is shaped as `noRuntimeValidation?: true` (only `true` is accepted) to make the opt-out explicit at the call site.
+
+This is independent of the per-call `ctx.isPrevalidated` escape hatch used by HTTP builders that have already validated upstream — both paths short-circuit the same validators.
+
 ## Error Handling
 
 ### Using ctx.error()
@@ -274,7 +292,7 @@ The taxonomy also drives typed `catch` blocks on generated clients and per-route
 
 ## Abort Signal
 
-For regular procedures, `ctx.signal` is available when the server implementation provides it. The built-in HTTP integrations (Hono RPC, Express RPC) inject the request's abort signal automatically:
+For regular procedures, `ctx.signal` is available when the server implementation provides it. The built-in HTTP integration (`HonoAppBuilder`) injects the request's abort signal automatically:
 
 ```typescript
 const { Create } = Procedures<{ signal: AbortSignal }>()
@@ -292,7 +310,7 @@ const { LongQuery } = Create(
 )
 ```
 
-When using the Hono or Express implementations, `ctx.signal` aborts when the client disconnects, automatically cancelling in-flight `fetch()` calls, database queries, or any other signal-aware operation.
+When using the Hono implementation, `ctx.signal` aborts when the client disconnects, automatically cancelling in-flight `fetch()` calls, database queries, or any other signal-aware operation.
 
 For streaming abort signal behavior (including `signal.reason` and consumer break detection), see [Streaming Procedures](./streaming.md#abort-signal-integration).
 
@@ -300,27 +318,25 @@ For streaming abort signal behavior (including `signal.reason` and consumer brea
 
 ### onCreate Callback
 
-Register procedures with your framework (Express, Fastify, etc.):
+Register procedures with a custom framework via the `onCreate` callback. Each registration receives `{ name, handler, config }` so you can wire it into whatever router or framework you want:
 
 ```typescript
-import express from 'express'
+import { Hono } from 'hono'
+import { ProcedureError } from 'ts-procedures'
 
-const app = express()
-const routes: Map<string, Function> = new Map()
+const app = new Hono()
 
-const { Create } = Procedures<{ req: Request; res: Response }>({
-  onCreate: ({ name, handler, config }) => {
-    // Register as Express route
-    app.post(`/rpc/${name}`, async (req, res) => {
+const { Create } = Procedures<{ raw: unknown }>({
+  onCreate: ({ name, handler }) => {
+    app.post(`/rpc/${name}`, async (c) => {
       try {
-        const result = await handler({ req, res }, req.body)
-        res.json(result)
+        const result = await handler({ raw: c }, await c.req.json())
+        return c.json(result)
       } catch (e) {
         if (e instanceof ProcedureError) {
-          res.status(500).json({ error: e.message })
-        } else {
-          res.status(500).json({ error: 'Internal error' })
+          return c.json({ error: e.message }, 500)
         }
+        return c.json({ error: 'Internal error' }, 500)
       }
     })
   },
@@ -329,7 +345,7 @@ const { Create } = Procedures<{ req: Request; res: Response }>({
 // Procedures are automatically registered as /rpc/GetUser, /rpc/CreateUser, etc.
 ```
 
-For built-in HTTP framework integrations (Express RPC, Hono RPC, Hono API, Hono Stream), see [HTTP Integrations](./http-integrations.md).
+For the built-in HTTP integration (RPC, RPC streams, REST, REST streams via `HonoAppBuilder`), see [HTTP Integrations](./http-integrations.md).
 
 ### Introspection with getProcedures()
 
@@ -419,6 +435,7 @@ describe('GetUser', () => {
 Creates a procedure factory.
 
 **Parameters:**
+- `builder.config.noRuntimeValidation` - When `true`, every procedure registered through this factory skips AJV validation of `schema.params` and `schema.input` at call time. Default: validation runs. See [Disabling Runtime Validation](#disabling-runtime-validation).
 - `builder.onCreate` - Callback invoked when each procedure is registered
 
 **Returns:**

package/docs/http-integrations.md

@@ -2,89 +2,38 @@
 
 # HTTP Framework Integrations
 
-ts-procedures includes built-in HTTP builders for Express and Hono that handle routing, context resolution, lifecycle hooks, abort signals, and automatic route documentation. Each builder uses the `onCreate` callback internally to register procedures as HTTP endpoints.
+ts-procedures includes a built-in HTTP builder for Hono that handles routing, context resolution, lifecycle hooks, abort signals, and automatic route documentation. The builder reads procedures off the factory at registration time and mounts the matching routes when you call `build()`.
 
-For a full cross-framework comparison (config interfaces, path generation, context resolution, abort signal, lifecycle hooks, route documentation), see the [HTTP implementations overview](../src/implementations/http/README.md).
+For a full reference (config interfaces, path generation, context resolution, abort signal, lifecycle hooks, route documentation), see the [HTTP implementations overview](../src/implementations/http/README.md).
 
 ## Integrations at a Glance
 
-| Integration | Export | Style | Guide |
-|-------------|--------|-------|-------|
-| Express RPC | `ts-procedures/express-rpc` | RPC (POST routes) | [README](../src/implementations/http/express-rpc/README.md) |
-| Hono RPC | `ts-procedures/hono-rpc` | RPC (POST routes) | [README](../src/implementations/http/hono-rpc/README.md) |
-| Hono Stream | `ts-procedures/hono-stream` | SSE/text streaming | [README](../src/implementations/http/hono-stream/README.md) |
-| Hono API | `ts-procedures/hono-api` | REST (method-based) | [README](../src/implementations/http/hono-api/README.md) |
+| Integration | Export | Procedure kinds | Guide |
+|-------------|--------|-----------------|-------|
+| HonoAppBuilder | `ts-procedures/hono` | `rpc`, `rpc-stream`, `http`, `http-stream` | [HTTP implementations overview](../src/implementations/http/README.md) |
 
-## Express RPC
+## Hono
 
-RPC-style HTTP integration for Express that creates POST routes at `/rpc/{name}/{version}` paths with automatic JSON schema documentation.
+`HonoAppBuilder` is the single Hono integration. One builder dispatches all four procedure kinds — `rpc`, `rpc-stream`, `http`, `http-stream` — from one `register()` call. Works with Bun, Deno, Cloudflare Workers, and Node.js.
 
 ```typescript
-import { ExpressRPCAppBuilder, RPCConfig } from 'ts-procedures/express-rpc'
-
-const RPC = Procedures<AppContext, RPCConfig>()
-
-RPC.Create(
-  'GetUser',
-  {
-    scope: ['users', 'get'],
-    version: 1,
-    schema: {
-      params: Type.Object({ id: Type.String() }),
-      returnType: Type.Object({ id: Type.String(), name: Type.String() }),
-    },
-  },
-  async (ctx, params) => {
-    return { id: params.id, name: 'John Doe' }
-  }
-)
-
-const app = new ExpressRPCAppBuilder()
-  .register(RPC, (req) => ({ userId: req.headers['x-user-id'] as string }))
-  .build()
-
-app.listen(3000)
-// Route created: POST /users/get/get-user/1
-```
-
-See the [Express RPC Integration Guide](../src/implementations/http/express-rpc/README.md) for complete setup including lifecycle hooks, error handling, and route documentation.
-
-## Hono RPC
-
-RPC-style HTTP integration for Hono with the same routing pattern as Express RPC. Works with Bun, Deno, Cloudflare Workers, and Node.js.
-
-```typescript
-import { HonoRPCAppBuilder, RPCConfig } from 'ts-procedures/hono-rpc'
+import { Procedures } from 'ts-procedures'
+import { HonoAppBuilder } from 'ts-procedures/hono'
+import type { RPCConfig } from 'ts-procedures/http'
+import { Type } from 'typebox'
 
-const RPC = Procedures<AppContext, RPCConfig>()
+type AppContext = { userId: string }
+const procs = Procedures<AppContext, RPCConfig>()
 
-RPC.Create('GetUser', {
+// 1. RPC procedure (Create) — POST /rpc/users/profile/get-user/1
+procs.Create('GetUser', {
   scope: ['users', 'profile'],
   version: 1,
   schema: { params: Type.Object({ id: Type.String() }) },
-}, async (ctx, params) => {
-  return { id: params.id, name: 'John Doe' }
-})
-
-const app = new HonoRPCAppBuilder({ pathPrefix: '/rpc' })
-  .register(RPC, (c) => ({ userId: c.req.header('x-user-id') || 'anonymous' }))
-  .build()
-
-// POST /rpc/users/profile/get-user/1
-```
-
-See the [Hono RPC Integration Guide](../src/implementations/http/hono-rpc/README.md) for complete setup including context resolution, doc extension, abort signal, error handling, and runtime compatibility.
-
-## Hono Stream
+}, async (ctx, params) => ({ id: params.id, name: 'John Doe' }))
 
-Streaming/SSE integration for Hono that supports both SSE and text streaming modes with yield validation, lifecycle hooks, and client disconnect detection.
-
-```typescript
-import { HonoStreamAppBuilder } from 'ts-procedures/hono-stream'
-
-const StreamRPC = Procedures<AppContext, RPCConfig>()
-
-StreamRPC.CreateStream('WatchNotifications', {
+// 2. RPC stream (CreateStream) — GET/POST /rpc/user/notifications/watch-notifications/1
+procs.CreateStream('WatchNotifications', {
   scope: ['user', 'notifications'],
   version: 1,
   schema: { yieldType: Type.Object({ id: Type.Number(), message: Type.String() }) },
@@ -95,60 +44,43 @@ StreamRPC.CreateStream('WatchNotifications', {
   }
 })
 
-const app = new HonoStreamAppBuilder()
-  .register(StreamRPC, (c) => ({ userId: c.req.header('x-user-id') || 'anonymous' }))
-  .build()
-```
-
-See the [Hono Stream Integration Guide](../src/implementations/http/hono-stream/README.md) for complete setup including SSE/text modes, the `sse()` helper, validation, error handling, and migration notes.
-
-## Hono API Integration
-
-REST-style HTTP integration for Hono that routes by HTTP method with per-channel input validation via `schema.input`.
-
-```typescript
-import { Procedures } from 'ts-procedures'
-import { HonoAPIAppBuilder } from 'ts-procedures/hono-api'
-import type { APIConfig } from 'ts-procedures/http'
-import { Type } from 'typebox'
-
-const API = Procedures<{ userId: string }, APIConfig>()
-
-API.Create('GetUser', {
+// 3. REST procedure (CreateHttp) — GET /rpc/users/:id
+procs.CreateHttp('GetUserRest', {
   path: '/users/:id',
   method: 'get',
+  scope: 'users',
   schema: {
-    input: {
-      pathParams: Type.Object({ id: Type.String() }),
-    },
-    returnType: Type.Object({ id: Type.String(), name: Type.String() }),
+    req: { pathParams: Type.Object({ id: Type.String() }) },
+    res: { body: Type.Object({ id: Type.String(), name: Type.String() }) },
   },
-}, async (ctx, { pathParams }) => {
-  return await fetchUser(pathParams.id)
-})
+}, async (ctx, { pathParams }) => fetchUser(pathParams.id))
 
-API.Create('CreateUser', {
-  path: '/users',
-  method: 'post',
+// 4. REST stream (CreateHttpStream) — GET /rpc/streams/logs
+procs.CreateHttpStream('TailLogs', {
+  path: '/streams/logs',
+  method: 'get',
+  scope: 'streams',
   schema: {
-    input: {
-      body: Type.Object({ name: Type.String(), email: Type.String() }),
-    },
+    req: { query: Type.Object({ source: Type.String() }) },
+    yield: Type.Object({ line: Type.String() }),
   },
-}, async (ctx, { body }) => {
-  return await createUser(body)
+}, async function* (ctx, { query }) {
+  for await (const line of tail(query.source)) yield { line }
 })
 
-const app = new HonoAPIAppBuilder({ pathPrefix: '/api' })
-  .register(API, (c) => ({ userId: c.req.header('x-user-id') || 'anonymous' }))
+const app = new HonoAppBuilder({
+  pathPrefix: '/rpc',
+  rpc:    { onSuccess: (proc, c) => log.info(`[rpc] ${proc.name}`) },
+  api:    { onSuccess: (proc, c) => log.info(`[api] ${proc.name}`) },
+  stream: { defaultStreamMode: 'sse' },
+})
+  .register(procs, (c) => ({ userId: c.req.header('x-user-id') || 'anonymous' }))
   .build()
-
-// Routes:
-// GET  /api/users/:id  -> 200
-// POST /api/users      -> 201
 ```
 
-See the [Hono API Integration Guide](../src/implementations/http/hono-api/README.md) for the full surface: `schema.input` channels, query parsing, success-status defaults, and error handling.
+`HonoAppBuilder`'s config is **stratified** — kind-specific knobs (`onSuccess`, `queryParser`, `defaultStreamMode`, `onStreamStart`, `onStreamEnd`, `onMidStreamError`) live inside the matching `rpc:` / `api:` / `stream:` block. Cross-cutting hooks (`onRequestStart`, `onRequestEnd`, `onRequestError`, `errors`, `unknownError`, `onError`) stay at the top level.
+
+For the full surface — config interfaces, path generation, context resolution, abort signal, lifecycle hooks, route doc shapes — see the [HTTP implementations overview](../src/implementations/http/README.md).
 
 ## Error Handling
 
@@ -165,7 +97,7 @@ Both modes also expose `onRequestError` — a cross-cutting observer for logging
 
 ```typescript
 import { defineErrorTaxonomy } from 'ts-procedures/http-errors'
-import { HonoAPIAppBuilder } from 'ts-procedures/hono-api'
+import { HonoAppBuilder } from 'ts-procedures/hono'
 
 class UseCaseError extends Error {
   constructor(readonly externalMsg: string, readonly internalMsg: string) {
@@ -190,40 +122,34 @@ const appErrors = defineErrorTaxonomy({
   },
 })
 
-new HonoAPIAppBuilder({
+new HonoAppBuilder({
   errors: appErrors,
   unknownError: {
     statusCode: 500,
     toResponse: () => ({ name: 'InternalServerError', message: 'Unexpected error' }),
     onCatch: (err, { procedure }) => logger.error({ procedure: procedure.name, err }),
   },
-}).register(API, /* ... */).build()
+}).register(procs, /* ... */).build()
 ```
 
-The identical `errors` + `unknownError` shape plugs into `HonoRPCAppBuilder`, `ExpressRPCAppBuilder`, and `HonoStreamAppBuilder` (pre-stream only — mid-stream uses `onMidStreamError`).
+For streaming procedures the taxonomy covers the pre-stream path only; mid-stream errors are handled via `stream.onMidStreamError`.
 
 ### Imperative — the `onError` callback
 
 For apps that don't need typed client dispatch or declarative docs, configure `onError` directly and handle every error in one place:
 
 ```typescript
-new HonoAPIAppBuilder({
+new HonoAppBuilder({
   onError: (procedure, c, error) => {
     logger.error(`[${procedure.name}]`, error)
     return c.json({ error: error.message ?? 'unknown error' }, 500)
   },
-}).register(API, /* ... */).build()
+}).register(procs, /* ... */).build()
 ```
 
 (Need to route different error classes to different status codes? Use the taxonomy — that's exactly what it's designed for. Hand-writing `instanceof` ladders inside `onError` is [anti-pattern #20](../agent_config/claude-code/skills/ts-procedures/anti-patterns.md).)
 
-Signatures (differ by framework):
-
-| Builder | `onError` signature |
-|---|---|
-| `HonoAPIAppBuilder`, `HonoRPCAppBuilder` | `(procedure, c: Context, error) => Response \| Promise<Response>` |
-| `ExpressRPCAppBuilder` | `(procedure, req, res, error) => void` (write to `res`) |
-| `HonoStreamAppBuilder` | `(procedure, c: Context, error) => Response \| Promise<Response>` — pre-stream only |
+`HonoAppBuilder`'s `onError` signature: `(procedure, c: Context, error) => Response | Promise<Response>` — for streaming procedures, pre-stream only.
 
 Picking between modes isn't irreversible: you can start with `onError`, migrate chunks to the taxonomy as your error model stabilizes, and leave the rest in `onError`. Both modes coexist in the dispatch order below.
 
@@ -232,27 +158,27 @@ Picking between modes isn't irreversible: you can start with `onError`, migrate
 `APIConfig` and `RPCConfig` are generic over a `TErrorKey extends string` parameter so you can declare which errors a specific route may emit:
 
 ```typescript
-import type { APIConfig } from 'ts-procedures/http'
+const procs = Procedures<Ctx>()
+type ErrorKey = keyof typeof appErrors & string
 
-type MyAPIConfig = APIConfig<keyof typeof appErrors & string>
-const API = Procedures<Ctx, MyAPIConfig>()
-
-API.Create('GetUser', {
+procs.CreateHttp('GetUser', {
   path: '/users/:id',
   method: 'get',
-  errors: ['UseCaseError'],   // typo-checked against the taxonomy keys
+  errors: ['UseCaseError'] satisfies ErrorKey[],   // typo-checked against the taxonomy keys
   schema: { /* ... */ },
 }, /* handler */)
 ```
 
 These per-route declarations flow into the DocEnvelope and drive typed `catch` blocks on generated clients — see [Client & Codegen → Typed Error Handling](./client-and-codegen.md#typed-error-handling).
 
+**Tip:** if a factory exclusively contains HTTP procedures, prefer the factory-level generic form `Procedures<Ctx, APIConfig<keyof typeof appErrors & string>>()` — it bakes the typo-checked error keys into every route on that factory so individual `errors: [...] satisfies ErrorKey[]` annotations are no longer needed. The per-route `satisfies` form above is the right pick when a single factory mixes HTTP procedures with other config shapes.
+
 ### Cross-cutting observability — `onRequestError`
 
 `onRequestError` fires for every caught error, **before** dispatch. It's an observer — it can't mutate the response. Use it for APM, distributed tracing, custom logging, or metrics where you want one hook that sees every error regardless of which mode dispatched it.
 
 ```typescript
-new HonoAPIAppBuilder({
+new HonoAppBuilder({
   errors: appErrors,
   onRequestError: async ({ err, procedure, raw }) => {
     sentry.captureException(err, { procedure: procedure.name })
@@ -271,41 +197,19 @@ The observer is awaited before the response is sent, and any error it throws is
 
 Configuring only the taxonomy, only `onError`, both, or neither are all valid. When neither is configured the builder goes straight from step 1 to step 4.
 
-## One Hono Server, Multiple Builders
+## DocRegistry — Composing Docs
 
-You don't need a separate Hono instance per builder. `HonoRPCAppBuilder`, `HonoAPIAppBuilder`, and `HonoStreamAppBuilder` each accept an optional `app?: Hono` in their config — pass the same instance and they all mount their routes onto the same server:
+For a single-builder app, the simplest path is `builder.toDocEnvelope({ basePath, errors })` — it wraps `DocRegistry` for you and produces the same envelope shape:
 
 ```typescript
-import { Hono } from 'hono'
-import { HonoRPCAppBuilder } from 'ts-procedures/hono-rpc'
-import { HonoAPIAppBuilder } from 'ts-procedures/hono-api'
-import { HonoStreamAppBuilder } from 'ts-procedures/hono-stream'
-import { DocRegistry } from 'ts-procedures/http-docs'
-
-const app = new Hono()
-
-const rpcBuilder = new HonoRPCAppBuilder({ app, pathPrefix: '/rpc' })
-  .register(RPC, ctxResolver)
-const apiBuilder = new HonoAPIAppBuilder({ app, pathPrefix: '/api' })
-  .register(API, ctxResolver)
-const streamBuilder = new HonoStreamAppBuilder({ app })
-  .register(Stream, ctxResolver)
+const builder = new HonoAppBuilder({ pathPrefix: '/api', errors: appErrors })
+  .register(procs, ctxResolver)
+const app = builder.build()
 
-rpcBuilder.build()
-apiBuilder.build()
-streamBuilder.build()
-
-const docs = new DocRegistry().from(rpcBuilder).from(apiBuilder).from(streamBuilder)
-app.get('/docs', (c) => c.json(docs.toJSON()))
+app.get('/docs', (c) => c.json(builder.toDocEnvelope()))
 ```
 
-One server, one Hono instance, one `/docs` endpoint. The three builders are **registration scopes**, not separate servers — each owns the routes it mounts (RPC vs API vs Stream) but all of them coexist on the same listener. Mix in custom middleware (`app.use(...)`), health checks, or static routes on the shared `app` before or after `.build()`.
-
-If you omit `app`, each builder constructs its own internal `Hono` instance — useful when you really do want isolated apps (multi-tenant routing, separate ports, etc.).
-
-## DocRegistry — Composing Docs from Multiple Builders
-
-Use `DocRegistry` to compose route documentation from any combination of HTTP builders into a typed envelope:
+For multi-app aggregation — e.g., two `HonoAppBuilder` instances mounted under different prefixes — use `DocRegistry` directly:
 
 ```typescript
 import { DocRegistry } from 'ts-procedures/http-docs'
@@ -315,9 +219,8 @@ const docs = new DocRegistry({
   headers: [{ name: 'Authorization', description: 'Bearer token', required: false }],
   errors: appErrors,  // your ErrorTaxonomy — auto-converted to ErrorDocs, framework defaults merged
 })
-  .from(rpcBuilder)
-  .from(apiBuilder)
-  .from(streamBuilder)
+  .from(publicBuilder)
+  .from(adminBuilder)
 
 app.get('/docs', (c) => c.json(docs.toJSON()))
 ```
@@ -328,7 +231,7 @@ For errors that aren't in your taxonomy (middleware-level, infrastructure, doc-o
 
 ```typescript
 const docs = new DocRegistry({ errors: appErrors, basePath: '/api' })
-  .from(rpcBuilder)
+  .from(honoBuilder)
   .documentError({ name: 'RateLimitExceeded', statusCode: 429, description: 'too many requests' })
 ```
 
@@ -339,10 +242,20 @@ The `DocRegistry` output is the input for [Client Code Generation](./client-and-
 ## Type Exports
 
 ```typescript
-// HTTP types
-import type { RPCConfig, RPCHttpRouteDoc, StreamHttpRouteDoc, StreamMode, APIConfig, APIHttpRouteDoc, APIInput, HttpMethod } from 'ts-procedures/http'
-
-// Hono API (REST-style)
-import { HonoAPIAppBuilder } from 'ts-procedures/hono-api'
-import type { APIConfig, APIHttpRouteDoc, APIInput, HttpMethod, QueryParser } from 'ts-procedures/hono-api'
+// Shared HTTP types
+import type {
+  RPCConfig,
+  RPCHttpRouteDoc,
+  StreamHttpRouteDoc,
+  HttpStreamRouteDoc,
+  StreamMode,
+  APIConfig,
+  APIHttpRouteDoc,
+  APIInput,
+  HttpMethod,
+} from 'ts-procedures/http'
+
+// Hono builder + Hono-specific types
+import { HonoAppBuilder } from 'ts-procedures/hono'
+import type { HonoAppBuilderConfig, QueryParser, OnRequestErrorContext, ExtendProcedureDoc } from 'ts-procedures/hono'
 ```

package/docs/streaming.md

@@ -105,72 +105,15 @@ for await (const item of CancellableStream({}, {})) {
 }
 ```
 
-## SSE Integration Example
+## SSE Integration
 
-```typescript
-import express from 'express'
-import { Procedures } from 'ts-procedures'
-
-const app = express()
-
-const { CreateStream, getProcedures } = Procedures<{ req: express.Request }>({
-  onCreate: (proc) => {
-    if (proc.isStream) {
-      // Register streaming procedures as SSE endpoints
-      app.get(`/stream/${proc.name}`, async (req, res) => {
-        res.writeHead(200, {
-          'Content-Type': 'text/event-stream',
-          'Cache-Control': 'no-cache',
-          'Connection': 'keep-alive',
-        })
-
-        const generator = proc.handler({ req }, req.query)
-
-        req.on('close', async () => {
-          // Client disconnected - stop the generator
-          await generator.return(undefined)
-        })
-
-        try {
-          for await (const data of generator) {
-            res.write(`data: ${JSON.stringify(data)}\n\n`)
-          }
-        } finally {
-          res.end()
-        }
-      })
-    }
-  },
-})
-
-// Define a streaming procedure
-CreateStream(
-  'LiveFeed',
-  {
-    schema: {
-      params: Type.Object({ channel: Type.String() }),
-      yieldType: Type.Object({ event: Type.String(), data: Type.Any() }),
-    },
-  },
-  async function* (ctx, params) {
-    while (!ctx.signal.aborted) {
-      const event = await pollForEvent(params.channel)
-      yield event
-    }
-  },
-)
-
-app.listen(3000)
-// SSE endpoint: GET /stream/LiveFeed?channel=updates
-```
-
-For the built-in Hono streaming integration, see the [Hono Stream README](../src/implementations/http/hono-stream/README.md).
+For the built-in Hono streaming integration, see [HTTP Integrations](./http-integrations.md). `HonoAppBuilder` dispatches `CreateStream` and `CreateHttpStream` procedures as SSE or text streams from the same `register()` call as your RPC and REST routes.
 
 ## Stream Errors
 
 Streaming procedures support the same error handling as regular procedures (see [Error Handling](./core.md#error-handling)).
 
-For HTTP stream endpoints, pre-stream errors (validation, context resolution, anything thrown before the first yield) go through the same two peer error-handling modes as every other HTTP builder — either the declarative `errors` / `unknownError` taxonomy (from `defineErrorTaxonomy`) or the imperative `onError` callback on `HonoStreamAppBuilder`. Cross-cutting `onRequestError` observer fires for every pre-stream error. See [HTTP Integrations → Error Handling](./http-integrations.md#error-handling) for the full contract. Mid-stream errors (thrown after the first yield) still flow through `onMidStreamError` and are surfaced to the client as SSE error events — the HTTP status is already committed once streaming begins, so mid-stream is outside the peer error modes.
+For HTTP stream endpoints, pre-stream errors (validation, context resolution, anything thrown before the first yield) go through the same two peer error-handling modes as every other HTTP builder — either the declarative `errors` / `unknownError` taxonomy (from `defineErrorTaxonomy`) or the imperative `onError` callback on `HonoAppBuilder`. Cross-cutting `onRequestError` observer fires for every pre-stream error. See [HTTP Integrations → Error Handling](./http-integrations.md#error-handling) for the full contract. Mid-stream errors (thrown after the first yield) still flow through `onMidStreamError` and are surfaced to the client as SSE error events — the HTTP status is already committed once streaming begins, so mid-stream is outside the peer error modes.
 
 ```typescript
 const { StreamWithErrors } = CreateStream(

package/docs/superpowers/plans/2026-05-07-astro-adapter.md

@@ -60,7 +60,6 @@ Open `package.json` and confirm both:
 "optionalDependencies": {
   "ajsc": "7.2.0",
   "astro": "^5.0.0",
-  "express": "^5.2.1",
   "hono": "^4.7.4"
 },
 "devDependencies": {
@@ -990,7 +989,6 @@ Dispatch rules:
 
 ## What's NOT included
 
-- Express RPC support (Express uses Node `req`/`res`, not Web Fetch).
 - DocRegistry coupling — wire `DocRegistry` against the same builders separately for client codegen.
 ````
 
@@ -1253,7 +1251,7 @@ Multi-app: pass an array; first non-404 response wins. All-404 falls back to the
 
 Constraints:
 - Astro 5+ in SSR (or `prerender = false`).
-- Express builders are NOT supported by this adapter — Hono builders only.
+- Hono builders only — the adapter accepts `Request`/`Response` apps.
 ````
 
 - [ ] **Step 3: Update patterns.md**
@@ -1270,8 +1268,6 @@ When a downstream developer is building inside an Astro app, recommend the catch
 3. Mount the built app(s) in a single catch-all file: `src/pages/api/[...rest].ts`. Use `pathPrefix: '/api'` so your Hono routes don't need to repeat the prefix.
 
 Anti-pattern: don't create one Astro file per procedure — that loses the centralized factory wiring and forces the developer to repeat the context closure.
-
-Anti-pattern: don't try to use `express-rpc` with the Astro adapter. The adapter only accepts Web-Fetch apps (Hono).
 ````
 
 - [ ] **Step 4: Mirror the same content into Copilot and Cursor rules**
@@ -1283,7 +1279,7 @@ In each file, locate the existing builders section and append (verbatim — same
 ```markdown
 ## Astro adapter
 
-Catch-all endpoint pattern. Build Hono apps once with HonoAPI/RPC/Stream builders, mount via `createAstroHandler` in `src/pages/api/[...rest].ts` with `pathPrefix: '/api'`. Read Astro context inside factory closures with `getAstroContext(c)`. Multi-app dispatch is first-non-404-wins. Express builders are not supported.
+Catch-all endpoint pattern. Build Hono apps once with HonoAPI/RPC/Stream builders, mount via `createAstroHandler` in `src/pages/api/[...rest].ts` with `pathPrefix: '/api'`. Read Astro context inside factory closures with `getAstroContext(c)`. Multi-app dispatch is first-non-404-wins.
 ```
 
 - [ ] **Step 5: Run the docs-consistency check**
@@ -1388,7 +1384,6 @@ If nothing changed, skip this step.
 - `stripPrefix(request, prefix)` — defined Task 2, called Task 4. Same signature.
 
 **Out-of-scope items confirmed not in plan:**
-- Express adapter — explicitly excluded
 - Native Astro builders — explicitly excluded
 - DocRegistry coupling — wired separately in walkthrough (Task 10), not in adapter
 - `dispatch: 'merge'` knob — not introduced