@chidchanun/bcp 0.1.24 → 0.1.25

package/README.md

@@ -1,11 +1,80 @@
 # BCP Framework
 
-BCP Framework is a React full-stack framework with file-based routing, SSR, SPA navigation, API routes, middleware, loaders, guards, form actions, authentication, MySQL primitives, validation, structured errors, logging, file uploads and standalone production builds.
+BCP Framework is a React full-stack framework focused on file-based routing, server rendering, server-side data loading, guarded application flows, API routes, authentication, database access, validation, logging, file uploads, storage adapters and standalone production deployment.
 
-> Current release target: `0.1.24`. BCP is pre-1.0 and each release candidate is validated before the manual npm publish step.
+> **Development target:** `0.1.25`
+>
+> BCP is still pre-1.0. Features documented for the current development target should not be presented as published npm behavior until the release candidate has passed and the matching version has been published.
+
+## Overview
+
+BCP provides a single application model for React pages and server code:
+
+```text
+Browser
+  ↓
+BCP middleware / security
+  ↓
+Route guard
+  ↓
+Loader / action / API route
+  ↓
+React SSR
+  ↓
+Hydration / SPA navigation
+```
+
+The framework is designed so application code can stay close to the route that owns it:
+
+```text
+app/
+├─ layout.tsx
+├─ page.tsx
+├─ dashboard/
+│  ├─ guard.ts
+│  └─ users/
+│     └─ [id]/
+│        ├─ loader.ts
+│        ├─ actions.ts
+│        └─ page.tsx
+└─ api/
+   └─ upload/
+      └─ route.ts
+```
+
+## Current capabilities
+
+| Area | Capability |
+| --- | --- |
+| Application | React SSR, hydration, layouts, metadata, SPA navigation |
+| Routing | Static, dynamic, catch-all, optional catch-all and route groups |
+| Server data | `loader.ts`, request-scoped server APIs |
+| Mutations | Route-owned `actions.ts` and `<Form>` |
+| Authorization | `guard.ts`, `requireAuth()`, `requireRole()` |
+| Authentication | JWT cookie sessions and auth helpers |
+| Middleware | Middleware System v2 with onion execution |
+| Validation | Typed validation helpers and structured validation errors |
+| Error handling | HTTP error helpers and consistent error responses |
+| Database | MySQL pool/query helpers, transactions and migrations |
+| Logging | Structured logger, request logger and request IDs |
+| Uploads | Multipart parsing, file validation and safe local persistence |
+| Storage | `StorageAdapter`, local storage adapter and file delivery |
+| Caching | Response cache and revalidation primitives |
+| Developer tools | `doctor`, `inspect`, updater and route inspection |
+| Production | Standalone server build with production middleware pipeline |
+
+## Requirements
+
+- Node.js `24.11` or newer
+- React `19`
+- npm
+
+Database features currently target MySQL.
 
 ## Quick start
 
+Create a new application:
+
 ```bash
 npx create-bcp-app@latest my-app
 cd my-app
@@ -18,65 +87,93 @@ Default development URL:
 http://localhost:3000
 ```
 
-## CLI
+A generated project normally exposes scripts such as:
 
-```bash
-bcp dev
-bcp routes
-bcp build
-bcp start
-bcp doctor
-bcp doctor --json
-bcp inspect
-bcp inspect --json
-bcp update
-bcp version
+```json
+{
+  "scripts": {
+    "dev": "bcp dev",
+    "build": "bcp build",
+    "start": "bcp start",
+    "routes": "bcp routes",
+    "update": "bcp update"
+  }
+}
+```
 
-bcp db create create_users
-bcp db migrate
-bcp db status
-bcp db rollback
+## Packages
+
+The public framework package is published as:
+
+```text
+@chidchanun/bcp
 ```
 
-Microsoft SQL Server also installs a Windows executable named `bcp.exe`. BCP Framework therefore also publishes the collision-free alias:
+Applications normally consume it through the dependency key:
 
-```powershell
-bcp-framework doctor
-bcp-framework inspect
-bcp-framework dev
-bcp-framework build
+```text
+bcp
 ```
 
-Normal project npm scripts can continue using `bcp` because npm places `node_modules/.bin` first on the script PATH.
+This keeps imports concise:
+
+```ts
+import {
+    Form,
+    Link,
+    useLoaderData,
+} from "bcp";
+```
+
+Server-only APIs use dedicated entrypoints such as:
+
+```ts
+import {
+    cookies,
+    logger,
+    requestId,
+} from "bcp/server";
+```
 
 ## Project structure
 
+A typical application can grow into this layout:
+
 ```text
 app/
 ├─ layout.tsx
 ├─ page.tsx
+├─ login/
+│  └─ page.tsx
 ├─ dashboard/
 │  ├─ guard.ts
+│  ├─ page.tsx
 │  └─ users/
 │     └─ [id]/
 │        ├─ loader.ts
 │        ├─ actions.ts
 │        └─ page.tsx
 └─ api/
-   ├─ hello/
-   │  └─ route.ts
+   ├─ auth/
+   │  └─ login/
+   │     └─ route.ts
    └─ upload/
       └─ route.ts
 
 lib/
 public/
+migrations/
 bcp.config.ts
 package.json
 tsconfig.json
 ```
 
+BCP keeps page rendering, route authorization, server data and route mutations close together without requiring one large application router configuration file.
+
 ## Routing
 
+Page routes are discovered from `app/**/page.tsx`.
+
 ```text
 app/page.tsx                     /
 app/about/page.tsx               /about
@@ -88,9 +185,26 @@ app/(admin)/settings/page.tsx    /settings
 
 Static routes have priority over dynamic and catch-all routes.
 
-## Server data
+API routes use `route.ts`:
+
+```text
+app/api/users/route.ts       /api/users
+app/api/users/[id]/route.ts  /api/users/:id
+```
+
+Read more: [Routing](docs/routing.md)
 
-A route can load server-only data with `loader.ts`:
+## Layouts and metadata
+
+Routes can inherit layouts from parent directories. The framework resolves the layout chain while rendering both development and standalone production requests.
+
+Document metadata is route-aware and can be generated alongside the page tree.
+
+Read more: [Routing](docs/routing.md)
+
+## Server data loaders
+
+Place `loader.ts` next to a page when the route needs server-side data.
 
 ```ts
 // app/users/[id]/loader.ts
@@ -104,7 +218,7 @@ export async function loader({
 }
 ```
 
-The page consumes the serializable value with:
+Consume the serializable result in a client page:
 
 ```tsx
 "use client";
@@ -119,14 +233,50 @@ export default function UserPage() {
             id: string;
         }>();
 
-    return <main>{data.id}</main>;
+    return (
+        <main>
+            User {data.id}
+        </main>
+    );
 }
 ```
 
-Protected route trees can use `guard.ts`, and route-owned mutations can use `actions.ts` with the public `<Form>` client API.
+Read more: [Server Data Loaders](docs/server-data-loaders.md)
+
+## Route guards
+
+A route tree can define `guard.ts` to authorize access before the protected route is rendered.
+
+Authentication-aware guards are available through `bcp/auth`:
+
+```ts
+import {
+    requireRole,
+} from "bcp/auth";
+
+export const guard =
+    requireRole("admin");
+```
+
+The standalone production pipeline preserves the same active request context used by authentication and server request APIs.
+
+Read more:
+
+- [Route Guards](docs/route-guards.md)
+- [Auth Route Guards](docs/auth-route-guards.md)
+
+## Form actions
+
+Route-owned mutations live in `actions.ts` and can be invoked through the public `<Form>` API.
+
+This supports both progressive form submission and SPA action transport while keeping mutation logic server-only.
+
+Read more: [Form Actions](docs/form-actions.md)
 
 ## Server request APIs
 
+Request-scoped APIs are exposed through `bcp/server`:
+
 ```ts
 import {
     bearerToken,
@@ -139,11 +289,147 @@ import {
 } from "bcp/server";
 ```
 
-`requestId()` accepts a valid incoming `X-Request-Id` or generates a stable UUID for the request.
+`requestId()` uses a valid incoming `X-Request-Id` when available or generates a stable UUID for the active request.
+
+Read more: [Server Request APIs](docs/server-request-apis.md)
+
+## Authentication and sessions
+
+High-level authentication helpers are available through:
+
+```ts
+import {
+    auth,
+    requireAuth,
+    requireRole,
+} from "bcp/auth";
+```
+
+Lower-level JWT cookie session primitives are available through `bcp/server`:
+
+```ts
+import {
+    createSession,
+    createSessionToken,
+    destroySession,
+    getSession,
+    verifySessionToken,
+} from "bcp/server";
+```
+
+Authentication is intentionally separated from application-specific credential lookup so projects can connect their own user table or identity provider.
+
+Read more:
+
+- [Authentication](docs/authentication.md)
+- [JWT Cookie Sessions](docs/session-auth.md)
+
+## Middleware
+
+Middleware System v2 uses onion-style execution:
+
+```ts
+export async function middleware(
+    request,
+    context,
+    next
+) {
+    const response =
+        await next();
+
+    response.headers.set(
+        "x-app",
+        "example"
+    );
+
+    return response;
+}
+```
+
+This allows middleware to run logic both before and after downstream route execution.
+
+Existing middleware v1 behavior remains supported for compatibility.
+
+Read more: [Middleware](docs/middleware.md)
+
+## Validation
+
+BCP includes typed validation primitives:
+
+```ts
+import {
+    v,
+    validateFormData,
+} from "bcp/validation";
+```
+
+Validation can be shared by API routes and form actions without coupling application schemas to the rendering layer.
+
+Read more: [Validation](docs/validation.md)
+
+## Error handling
+
+Structured HTTP error helpers are exposed through `bcp/error`:
+
+```ts
+import {
+    badRequest,
+    forbidden,
+    notFoundResponse,
+    toErrorResponse,
+    unauthorized,
+} from "bcp/error";
+```
+
+The common error envelope is:
+
+```json
+{
+  "error": {
+    "status": 400,
+    "code": "BAD_REQUEST",
+    "message": "Invalid request"
+  }
+}
+```
+
+Read more: [Error Handling](docs/error-handling.md)
+
+## Database
+
+Database helpers are exposed through:
+
+```ts
+import {
+    db,
+} from "bcp/database";
+```
+
+The database layer provides:
+
+- lazy MySQL pool creation,
+- prepared execution,
+- query helpers,
+- transactions,
+- migration status and rollback support.
 
-## Logging & Observability
+Migration commands:
 
-BCP 0.1.23 introduced structured server logging:
+```bash
+bcp db create create_users
+bcp db migrate
+bcp db status
+bcp db rollback
+```
+
+Read more:
+
+- [Database](docs/database.md)
+- [Database Migrations](docs/database-migrations.md)
+
+## Logging and observability
+
+Structured server logging is available through `bcp/server`:
 
 ```ts
 import {
@@ -158,7 +444,11 @@ logger.info(
             "catalog",
     }
 );
+```
+
+Request-scoped logging can automatically include request identity:
 
+```ts
 export async function loader() {
     const log =
         await requestLogger({
@@ -176,18 +466,35 @@ export async function loader() {
 }
 ```
 
-Configure output with:
+Environment controls:
 
 ```env
 BCP_LOG_LEVEL=debug
 BCP_LOG_FORMAT=json
 ```
 
-Supported levels are `debug`, `info`, `warn`, `error` and `silent`. Formats are `pretty` and `json`.
+Supported levels:
+
+```text
+debug
+info
+warn
+error
+silent
+```
+
+Supported formats:
+
+```text
+pretty
+json
+```
+
+Read more: [Logging and Observability](docs/development-logging.md)
 
-## File Upload
+## File upload
 
-BCP 0.1.24 adds server-only multipart/file helpers through `bcp/server`:
+BCP `0.1.24` introduced multipart parsing and file validation:
 
 ```ts
 import {
@@ -229,39 +536,31 @@ export async function POST(
             }
         );
 
-    const saved =
+    return Response.json(
         await saveUploadedFile(
             file,
             {
                 directory:
                     "./uploads",
             }
-        );
-
-    return Response.json({
-        fileName:
-            saved.fileName,
-        size:
-            saved.size,
-        checksumSha256:
-            saved.checksumSha256,
-    });
+        )
+    );
 }
 ```
 
 Upload helpers provide:
 
 - multipart validation,
-- total and per-file size limits,
-- MIME/extension allowlists,
-- optional or required file fields,
+- total request and per-file size limits,
+- MIME and extension allowlists,
+- required/optional file fields,
 - safe UUID-based storage names,
 - filename sanitization,
 - path traversal protection,
-- no-overwrite-by-default storage,
+- no-overwrite-by-default persistence,
 - SHA-256 checksum metadata.
 
-The security gateway enforces `server.bodyLimit` / `BCP_BODY_LIMIT` before request data reaches application handlers. The default is 1 MiB, so applications accepting larger files must raise it explicitly.
+The security gateway applies `server.bodyLimit` / `BCP_BODY_LIMIT` before application upload parsing. Applications accepting larger files must raise that outer limit explicitly.
 
 ```ts
 import {
@@ -276,122 +575,234 @@ export default defineConfig({
 });
 ```
 
-MIME type and extension are metadata checks, not content-signature verification. Security-sensitive applications should additionally inspect file content and use malware scanning where appropriate.
+MIME type and extension validation are metadata checks, not content-signature verification. Security-sensitive applications should additionally verify content and use malware scanning where appropriate.
 
-See [File Upload](docs/file-upload.md).
+Read more: [File Upload](docs/file-upload.md)
 
-## Development route graph recovery
+## Storage adapters
 
-BCP 0.1.24 fixes a development route/client-bundle synchronization issue that could produce:
+BCP `0.1.25` adds the first application-facing storage abstraction.
 
-```text
-Client bundle was not found for route "/docs/[...slug]".
-```
+```ts
+import {
+    createLocalStorage,
+    storeUploadedFile,
+} from "bcp/server";
 
-The problem happened when the actual page topology changed but Windows/editor filesystem events were classified as `change` instead of `add`/`unlink`. The route scanner could see a new route while the incremental client bundle graph still represented the previous route tree.
+const storage =
+    createLocalStorage({
+        directory:
+            "./uploads",
+    });
 
-The dev gateway now compares the actual pathname/page/layout graph and automatically refreshes the internal development server/client bundler when topology changes. Manually deleting `.bcp-framework` should no longer be required to recover this state.
+const stored =
+    await storeUploadedFile(
+        file,
+        {
+            storage,
+            key:
+                "avatars/user-101.webp",
+        }
+    );
+```
 
-## Developer diagnostics
+The `StorageAdapter` contract contains:
 
-```bash
-bcp doctor
-bcp inspect
+```text
+put
+stat
+read
+exists
+delete
 ```
 
-`bcp doctor` checks project structure, BCP/React installations, React renderer parity, duplicate framework copies, environment/config loading, route conflicts and client/server boundaries. Blocking failures return a non-zero exit code.
+Application code can depend on this contract instead of depending directly on filesystem paths.
+
+The built-in adapter in `0.1.25` is local filesystem storage. Cloud/object-storage adapters are planned for a later milestone.
 
-`bcp inspect` prints resolved configuration, development env filenames, public variable names, dependency versions and discovered routes.
+Storage keys are logical relative paths. Absolute paths and traversal segments are rejected.
 
-For local release verification, install packed `.tgz` artifacts under the existing `bcp` dependency key. Do not install a second `@chidchanun/bcp` copy next to `node_modules/bcp`, because separate framework copies can split React contexts and produce misleading loader/hook errors.
+Read more: [Storage and File Delivery](docs/storage.md)
 
-## Validation and errors
+## Production file delivery
+
+Storage objects can be returned through a hardened HTTP response helper:
 
 ```ts
 import {
-    v,
-    validateFormData,
-} from "bcp/validation";
+    createStorageResponse,
+} from "bcp/server";
 
-import {
-    badRequest,
-    unauthorized,
-    toErrorResponse,
-} from "bcp/error";
+export async function GET(
+    request: Request
+) {
+    return createStorageResponse(
+        request,
+        storage,
+        "documents/report.pdf",
+        {
+            disposition:
+                "attachment",
+            downloadName:
+                "report.pdf",
+        }
+    );
+}
 ```
 
-Structured error responses use the common envelope:
+`createStorageResponse()` supports:
 
-```json
-{
-  "error": {
-    "status": 400,
-    "code": "BAD_REQUEST",
-    "message": "Invalid request"
-  }
-}
+- `GET`,
+- `HEAD`,
+- `ETag`,
+- `Last-Modified`,
+- `If-None-Match`,
+- `If-Modified-Since`,
+- `If-Range`,
+- single byte ranges with `206 Partial Content`,
+- `304 Not Modified`,
+- `416 Range Not Satisfiable`,
+- safe `Content-Disposition` filenames.
+
+The default cache policy is intentionally conservative:
+
+```text
+private, max-age=0, must-revalidate
 ```
 
-## Database
+Public immutable caching must be opted into explicitly.
 
-```ts
-import {
-    db,
-} from "bcp/database";
+Multiple byte ranges are intentionally not supported in `0.1.25`.
+
+Read more: [Storage and File Delivery](docs/storage.md)
+
+## Caching
+
+BCP includes server response caching and revalidation primitives used by development and standalone production runtimes.
+
+Read more: [Caching](docs/caching.md)
+
+## Security
+
+The framework security layer includes request body limits and production request handling defaults. Application authorization is still the responsibility of route guards and application logic.
+
+Storage keys, filenames and MIME metadata must not be treated as authorization decisions.
+
+Read more: [Security](docs/security.md)
+
+## Environment and configuration
+
+Application configuration lives in:
+
+```text
+bcp.config.ts
 ```
 
-The database layer provides a lazy MySQL pool, prepared execution, queries and transactions. Database migrations are managed through `bcp db` commands.
+Public environment variables use the prefix:
 
-## Authentication
+```text
+BCP_PUBLIC_
+```
 
-```ts
-import {
-    auth,
-    requireAuth,
-    requireRole,
-} from "bcp/auth";
+Server-only environment values remain server-side and are not emitted into browser bundles.
+
+Read more: [Configuration](docs/configuration.md)
+
+## Developer tools
+
+BCP includes project diagnostics:
+
+```bash
+bcp doctor
+bcp inspect
 ```
 
-BCP also exposes lower-level JWT cookie session helpers through `bcp/server`.
+`bcp doctor` checks areas such as:
 
-## Middleware
+- project structure,
+- BCP installation,
+- React / ReactDOM compatibility,
+- duplicate framework copies,
+- environment/config loading,
+- route conflicts,
+- client/server boundaries.
 
-Middleware v2 uses true onion execution:
+`bcp inspect` reports resolved configuration, environment sources, dependencies and discovered routes.
 
-```ts
-export async function middleware(
-    request,
-    context,
-    next
-) {
-    const response =
-        await next();
+Read more: [Developer Tools](docs/developer-tools.md)
 
-    response.headers.set(
-        "x-app",
-        "example"
-    );
+## Windows CLI
 
-    return response;
-}
+Microsoft SQL Server also installs an executable named `bcp.exe` on Windows.
+
+BCP therefore publishes the collision-free alias:
+
+```text
+bcp-framework
 ```
 
-Existing v1 middleware remains supported.
+Inside project npm scripts, `bcp` remains safe because npm puts `node_modules/.bin` at the front of `PATH`.
 
-## Hydration parity
+For direct PowerShell usage, prefer:
 
-BCP 0.1.20 normalized Windows CRLF/CR source line endings in development instrumentation. BCP 0.1.21 completed SSR/client JSX semantic parity by preserving JSX through the Babel React Refresh pass and allowing esbuild to perform the development JSX transform.
+```powershell
+npm exec -- bcp-framework doctor
+npm exec -- bcp-framework inspect
+npm exec -- bcp-framework dev
+npm exec -- bcp-framework build
+```
 
-Multiline quoted JSX attributes are supported without rewriting classes onto a single line or applying `suppressHydrationWarning` as a framework workaround.
+## CLI reference
 
-## Production
+```bash
+bcp dev
+bcp routes
+bcp build
+bcp start
+bcp doctor
+bcp doctor --json
+bcp inspect
+bcp inspect --json
+bcp update
+bcp version
+
+bcp db create create_users
+bcp db migrate
+bcp db status
+bcp db rollback
+```
+
+## Development behavior
+
+BCP includes Fast Refresh and deterministic development hydration behavior.
+
+Recent stabilization work also covers:
+
+- Windows line-ending parity,
+- multiline JSX hydration parity,
+- duplicate BCP installation detection,
+- automatic page-route/client-bundle graph resynchronization,
+- standalone authentication guard request-context parity.
+
+A development topology change should no longer require manually deleting `.bcp-framework` to recover a missing client route bundle.
+
+Read more: [Hydration](docs/hydration.md)
+
+## Production build
+
+Build an application:
 
 ```bash
 npm run build
-npm start
 ```
 
-Standalone output is generated under:
+Start the generated standalone runtime:
+
+```bash
+npm run start
+```
+
+Production output is written under:
 
 ```text
 .bcp-framework/build/
@@ -401,44 +812,71 @@ Standalone output is generated under:
    └─ server.mjs
 ```
 
-## Updating
+The standalone runtime composes production middleware, security, cache, actions, guards, loaders and page rendering into the final HTTP pipeline.
+
+Runtime hostname/port overrides can be supplied to `bcp start` without rebuilding the application.
+
+Read more: [Deployment](docs/deployment.md)
+
+## Updating BCP
 
 ```bash
 bcp update
 bcp update --check
 bcp update --dry-run
-bcp update 0.1.24
+bcp update 0.1.25
 bcp update next
 ```
 
-Projects published before the updater can bootstrap it once with:
+Projects created before the updater was introduced can bootstrap it once using the public package:
 
 ```bash
 npx @chidchanun/bcp@latest update
 ```
 
-## Release validation
+Read more: [Updating](docs/updating.md)
+
+## Framework development
+
+When working inside the BCP Framework repository itself:
 
 ```bash
+npm install
 npm run typecheck
 npm run test:unit
+npm run test:e2e
+npm run test:package
+```
+
+Full release-candidate validation:
+
+```bash
 npm run rc:check
 ```
 
-After RC passes, releases are tagged and published manually with the guarded release scripts.
+A version must not be tagged or published until its release candidate and packed-package verification pass.
+
+Read more: [Releasing](docs/releasing.md)
+
+## Documentation source
 
-## Documentation
+The `docs/` directory is the source content intended to feed the future **`bcp-docs-web`** documentation website.
 
+Start with:
+
+- [Documentation Source Map](docs/README.md)
 - [Getting Started](docs/getting-started.md)
+- [Configuration](docs/configuration.md)
 - [Application Modules](docs/application-modules.md)
 - [Routing](docs/routing.md)
-- [Server Request APIs](docs/server-request-apis.md)
 - [Server Data Loaders](docs/server-data-loaders.md)
-- [Protected Route Guards](docs/route-guards.md)
+- [Route Guards](docs/route-guards.md)
 - [Form Actions](docs/form-actions.md)
+- [Server Request APIs](docs/server-request-apis.md)
 - [Validation](docs/validation.md)
 - [Error Handling](docs/error-handling.md)
 - [File Upload](docs/file-upload.md)
+- [Storage and File Delivery](docs/storage.md)
 - [Authentication](docs/authentication.md)
 - [Auth Route Guards](docs/auth-route-guards.md)
 - [JWT Sessions](docs/session-auth.md)
@@ -447,17 +885,58 @@ After RC passes, releases are tagged and published manually with the guarded rel
 - [Middleware](docs/middleware.md)
 - [Hydration](docs/hydration.md)
 - [Developer Tools](docs/developer-tools.md)
-- [Development Logging](docs/development-logging.md)
+- [Logging and Observability](docs/development-logging.md)
 - [Caching](docs/caching.md)
 - [Security](docs/security.md)
 - [Deployment](docs/deployment.md)
 - [Updating](docs/updating.md)
 - [Releasing](docs/releasing.md)
 
-## Requirements
+## Documentation website model
+
+When `bcp-docs-web` is built, the recommended top-level information architecture is:
+
+```text
+Getting Started
+Routing & Data
+Authentication
+Database
+Runtime & Infrastructure
+API Reference
+Releases
+```
+
+`docs/README.md` contains the proposed route-to-source mapping for that website.
+
+## Release history
+
+Release notes are stored under:
+
+```text
+docs/releases/
+```
+
+Recent milestones:
+
+| Version | Milestone |
+| --- | --- |
+| `0.1.20` | Hydration line-ending stabilization |
+| `0.1.21` | Hydration semantic parity |
+| `0.1.22` | Developer tools and diagnostics |
+| `0.1.23` | Logging and observability |
+| `0.1.24` | File Upload Foundation |
+| `0.1.25` | Storage Adapters and File Delivery |
+
+## Roadmap
+
+Current planned direction after `0.1.25`:
+
+1. S3-compatible / cloud storage adapter integration.
+2. Production upload streaming.
+3. Broader storage adapter ecosystem.
+4. Additional production hardening as new workloads expose edge cases.
 
-- Node.js 24.11 or newer
-- React 19
+Roadmap items are plans, not published API guarantees.
 
 ## License