@chidchanun/bcp 0.1.29 → 0.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,10 +1,38 @@
1
1
  # BCP Framework
2
2
 
3
- BCP Framework is a React full-stack framework focused on file-based routing, SSR, server data loading, guarded application flows, API routes, authentication, database access, validation, logging, uploads, storage and standalone production deployment.
3
+ BCP Framework is a React full-stack framework for file-based routing, SSR, SPA navigation, server data loading, guarded application flows, API routes, authentication, database access, validation, uploads, storage and standalone Node.js production deployment.
4
4
 
5
- > **Development target:** `0.1.29`
5
+ > **Development target:** `0.2.0 — Framework Platform`
6
6
  >
7
- > BCP is pre-1.0. The `0.1.29` source adds the Developer Experience milestone and remains an unreleased development target until local validation, RC checks, tagging and npm publication complete.
7
+ > `0.2.0` establishes the first explicit platform baseline for BCP. It remains an unreleased development target until local validation, RC checks, tagging and npm publication complete.
8
+
9
+ ## Platform baseline — 0.2.0
10
+
11
+ BCP `0.2.0` consolidates the capabilities built across the `0.1.x` series into a documented and testable platform contract.
12
+
13
+ New platform sources:
14
+
15
+ ```text
16
+ docs/platform-manifest.json
17
+ -> version, runtime target, public entrypoints and capability metadata
18
+
19
+ docs/docs-web-manifest.json
20
+ -> docs-web sections, routes, Markdown sources and releases
21
+
22
+ docs/platform-contract.md
23
+ -> public platform/compatibility contract
24
+
25
+ docs/migration-0.2.md
26
+ -> application upgrade guide
27
+ ```
28
+
29
+ The package release pipeline now verifies the platform contract against the prepared npm artifact so accidental public-export/version drift fails package validation.
30
+
31
+ Read more:
32
+
33
+ - [Framework Platform Contract](docs/platform-contract.md)
34
+ - [Migrating to 0.2.0](docs/migration-0.2.md)
35
+ - [Platform Manifest](docs/platform-manifest.json)
8
36
 
9
37
  ## Current capabilities
10
38
 
@@ -12,29 +40,29 @@ BCP Framework is a React full-stack framework focused on file-based routing, SSR
12
40
  | --- | --- |
13
41
  | Application | React SSR, hydration, layouts, metadata and SPA navigation |
14
42
  | Routing | Static, dynamic, catch-all, optional catch-all and route groups |
15
- | Server data | `loader.ts`, request-scoped server APIs |
43
+ | Server data | Route `loader.ts`, request-scoped server APIs |
16
44
  | Mutations | Route-owned `actions.ts` and `<Form>` |
17
45
  | Authorization | `guard.ts`, `requireAuth()`, `requireRole()` |
18
46
  | Authentication | JWT cookie sessions and auth helpers |
19
47
  | Middleware | Middleware System v2 with onion execution |
20
48
  | Validation | Typed validation helpers and structured validation errors |
21
49
  | Error handling | HTTP error helpers and consistent error responses |
22
- | Database | MySQL pool/query helpers, transactions and migrations |
50
+ | Database | MySQL helpers, transactions and migrations |
23
51
  | Logging | Structured logger, request logger and request IDs |
24
52
  | Uploads | Buffered multipart helpers and production multipart streaming |
25
- | Storage | Local + S3-compatible adapters, streaming, listing, copy/move, metadata, bulk delete and signed S3 URLs |
53
+ | Storage | Local + S3-compatible storage, streaming, list/copy/move, metadata, bulk delete and signed URLs |
26
54
  | Caching | Response cache and revalidation primitives |
27
- | Developer tools | Project generators, `doctor` / `inspect` v2, updater, route inspection and project metadata |
28
- | Production | Standalone build, hardening gateway, graceful shutdown, trusted-proxy controls and HTTP timeouts |
29
- | Documentation | Markdown source map plus `docs/docs-web-manifest.json` for `bcp-docs-web` |
55
+ | Developer tools | Generators, Doctor/Inspect v2, updater, route inspection and project metadata |
56
+ | Production | Standalone Node.js build, hardening gateway, graceful shutdown, trusted proxy controls and HTTP timeouts |
57
+ | Documentation | Markdown source + machine-readable docs-web/platform manifests |
30
58
 
31
59
  ## Requirements
32
60
 
33
- - Node.js `24.11` or newer
61
+ - Node.js `24.11.0` or newer
34
62
  - React `19`
35
63
  - npm
36
64
 
37
- Database features currently target MySQL.
65
+ Database framework primitives currently target MySQL. `create-bcp-app` can also scaffold PostgreSQL, SQLite and MongoDB application helpers.
38
66
 
39
67
  ## Quick start
40
68
 
@@ -44,32 +72,24 @@ cd my-app
44
72
  npm run dev
45
73
  ```
46
74
 
47
- Generated projects normally use the application dependency key `bcp`:
75
+ Generated projects normally keep one framework dependency key:
48
76
 
49
77
  ```json
50
78
  {
51
79
  "dependencies": {
52
80
  "bcp": "npm:@chidchanun/bcp@latest"
53
- },
54
- "scripts": {
55
- "dev": "bcp dev",
56
- "build": "bcp build",
57
- "start": "bcp start",
58
- "routes": "bcp routes",
59
- "update": "bcp update",
60
- "typecheck": "tsc --noEmit"
61
81
  }
62
82
  }
63
83
  ```
64
84
 
65
- Keep only one framework dependency named `bcp`. Installing both `bcp` and `@chidchanun/bcp` directly can load duplicate framework/React contexts.
85
+ Do not install both `bcp` and a second direct `@chidchanun/bcp` dependency in the same application; duplicate framework copies can create separate React/framework contexts.
66
86
 
67
87
  ## Application model
68
88
 
69
89
  ```text
70
90
  Browser
71
91
 
72
- BCP security / middleware / cache
92
+ Security / middleware / cache
73
93
 
74
94
  Route guard
75
95
 
@@ -80,7 +100,7 @@ React SSR
80
100
  Hydration / SPA navigation
81
101
  ```
82
102
 
83
- A route can keep page, loader, guard and actions together:
103
+ Typical route structure:
84
104
 
85
105
  ```text
86
106
  app/
@@ -98,73 +118,101 @@ app/
98
118
  └─ route.ts
99
119
  ```
100
120
 
101
- ## Routing
121
+ ## Public entrypoints
102
122
 
103
- Page routes are discovered from `app/**/page.tsx` and API routes from `app/**/route.ts`.
123
+ The `0.2.0` platform contract recognizes these application entrypoints:
104
124
 
105
125
  ```text
106
- app/page.tsx /
107
- app/about/page.tsx /about
108
- app/users/[id]/page.tsx /users/:id
109
- app/docs/[...slug]/page.tsx /docs/*
110
- app/catalog/[[...slug]]/page.tsx /catalog and /catalog/*
111
- app/(admin)/settings/page.tsx /settings
126
+ bcp
127
+ bcp/island
128
+ bcp/cache
129
+ bcp/config
130
+ bcp/validation
131
+ bcp/error
132
+ bcp/database
133
+ bcp/auth
134
+ bcp/server
135
+ bcp/server-only
136
+ bcp/middleware
137
+ ```
112
138
 
113
- app/api/users/route.ts /api/users
114
- app/api/users/[id]/route.ts /api/users/:id
139
+ Application code should use public entrypoints rather than importing internal framework files under `packages/`.
140
+
141
+ The authoritative machine-readable list is in [docs/platform-manifest.json](docs/platform-manifest.json).
142
+
143
+ ## CLI
144
+
145
+ Core commands:
146
+
147
+ ```bash
148
+ bcp dev
149
+ bcp build
150
+ bcp start
151
+ bcp routes
152
+ bcp update
153
+ bcp doctor
154
+ bcp inspect
155
+ bcp version
115
156
  ```
116
157
 
117
- Read more: [Routing](docs/routing.md)
158
+ Database migrations:
118
159
 
119
- ## Project generators — 0.1.29
160
+ ```bash
161
+ bcp db create create_users
162
+ bcp db migrate
163
+ bcp db status
164
+ bcp db rollback
165
+ ```
120
166
 
121
- BCP `0.1.29` adds generators for common framework files:
167
+ Project generators:
122
168
 
123
169
  ```bash
124
170
  bcp generate page dashboard/users
125
- bcp generate page users/[id]
126
171
  bcp generate api users
127
172
  bcp generate middleware
128
173
  bcp generate migration create_users
129
174
  ```
130
175
 
131
- Generated targets:
132
-
133
- ```text
134
- page -> app/<route>/page.tsx
135
- api -> app/api/<route>/route.ts
136
- middleware -> middleware.ts
137
- migration -> migrations/<timestamp>_<name>.ts
138
- ```
176
+ Page/API/middleware generators require `--force` before replacing an existing scaffold target.
139
177
 
140
- Page/API/middleware generators do not overwrite existing files unless `--force` is explicitly supplied:
178
+ On Windows, Microsoft SQL Server may provide another `bcp.exe`. For direct PowerShell usage prefer the collision-free project-local alias:
141
179
 
142
- ```bash
143
- bcp generate page dashboard/users --force
180
+ ```powershell
181
+ npm exec -- bcp-framework doctor
182
+ npm exec -- bcp-framework inspect
183
+ npm exec -- bcp-framework routes
184
+ npm exec -- bcp-framework generate page dashboard/users
144
185
  ```
145
186
 
146
- Migration generation reuses the existing database migration implementation so migration naming and format remain centralized.
187
+ Inside npm scripts, `bcp` remains safe because npm prepends the project `node_modules/.bin` directory to `PATH`.
147
188
 
148
- Read more: [Project Generators](docs/generators.md)
189
+ ## Routing, loaders, guards and actions
149
190
 
150
- ## Server data, guards and actions
191
+ BCP discovers pages from `app/**/page.tsx` and API handlers from `app/**/route.ts`.
151
192
 
152
- Server loaders live next to their route in `loader.ts`. Route authorization can be defined in `guard.ts`, while route-owned mutations live in `actions.ts`.
193
+ ```text
194
+ app/page.tsx /
195
+ app/users/[id]/page.tsx /users/:id
196
+ app/docs/[...slug]/page.tsx /docs/*
197
+ app/catalog/[[...slug]]/page.tsx /catalog and /catalog/*
198
+ app/(admin)/settings/page.tsx /settings
199
+ app/api/users/route.ts /api/users
200
+ ```
153
201
 
154
- ```ts
155
- import {
156
- requireRole,
157
- } from "bcp/auth";
202
+ Route-owned server features stay colocated:
158
203
 
159
- export const guard =
160
- requireRole("admin");
204
+ ```text
205
+ page.tsx
206
+ loader.ts
207
+ guard.ts
208
+ actions.ts
161
209
  ```
162
210
 
163
- Read more:
211
+ Guides:
164
212
 
213
+ - [Routing](docs/routing.md)
165
214
  - [Server Data Loaders](docs/server-data-loaders.md)
166
215
  - [Route Guards](docs/route-guards.md)
167
- - [Auth Route Guards](docs/auth-route-guards.md)
168
216
  - [Form Actions](docs/form-actions.md)
169
217
 
170
218
  ## Authentication and server APIs
@@ -185,9 +233,7 @@ import {
185
233
  } from "bcp/server";
186
234
  ```
187
235
 
188
- BCP also exposes lower-level JWT cookie session primitives through `bcp/server`.
189
-
190
- Read more:
236
+ Guides:
191
237
 
192
238
  - [Authentication](docs/authentication.md)
193
239
  - [JWT Sessions](docs/session-auth.md)
@@ -201,180 +247,76 @@ import {
201
247
  } from "bcp/database";
202
248
  ```
203
249
 
204
- The database layer provides lazy MySQL pool creation, prepared execution, query helpers, transactions and migrations.
250
+ BCP's database layer includes lazy MySQL pool creation, query/execute helpers, transactions and migrations.
205
251
 
206
- ```bash
207
- bcp db create create_users
208
- bcp db migrate
209
- bcp db status
210
- bcp db rollback
211
- ```
212
-
213
- Read more:
252
+ Guides:
214
253
 
215
254
  - [Database](docs/database.md)
216
255
  - [Database Migrations](docs/database-migrations.md)
217
256
 
218
- ## Uploads and streaming
219
-
220
- BCP supports the original buffered multipart helpers as well as production multipart-to-storage streaming:
221
-
222
- ```ts
223
- import {
224
- storeMultipartFile,
225
- } from "bcp/server";
226
-
227
- const stored =
228
- await storeMultipartFile(
229
- request,
230
- {
231
- storage,
232
- fieldName: "file",
233
- key: "documents/report.pdf",
234
- maxBytes: 100 * 1024 * 1024,
235
- constraints: {
236
- maxBytes: 80 * 1024 * 1024,
237
- allowedTypes: [
238
- "application/pdf",
239
- ],
240
- },
241
- }
242
- );
243
- ```
244
-
245
- `storeMultipartFile()` consumes `Request.body` incrementally and streams the selected file directly into storage. Request/body infrastructure limits still apply.
257
+ ## Storage and uploads
246
258
 
247
- Read more: [File Upload](docs/file-upload.md)
259
+ `create-bcp-app` can scaffold:
248
260
 
249
- ## Storage
250
-
251
- ### Local filesystem
252
-
253
- ```ts
254
- import {
255
- createLocalStorage,
256
- } from "bcp/server";
257
-
258
- const storage =
259
- createLocalStorage({
260
- directory: "./uploads",
261
- });
261
+ ```text
262
+ None
263
+ Local Server
264
+ Amazon S3
265
+ Cloudflare R2
262
266
  ```
263
267
 
264
- `create-bcp-app --storage local` creates `lib/storage.ts` plus a visible `storage/README.md` / `.gitkeep` scaffold. Runtime objects remain ignored by Git.
268
+ BCP's storage API supports local and S3-compatible storage, streaming reads/writes, ranges, object listing, copy/move, portable metadata, bulk deletion and S3 signed URLs.
265
269
 
266
- ### S3 / R2 / MinIO
270
+ Local Server projects keep a visible scaffold:
267
271
 
268
- ```ts
269
- import {
270
- createS3Storage,
271
- } from "bcp/server";
272
-
273
- const storage =
274
- createS3Storage({
275
- bucket: process.env.S3_BUCKET!,
276
- region: process.env.S3_REGION!,
277
- endpoint: process.env.S3_ENDPOINT,
278
- accessKeyId: process.env.S3_ACCESS_KEY_ID,
279
- secretAccessKey: process.env.S3_SECRET_ACCESS_KEY,
280
- });
272
+ ```text
273
+ storage/
274
+ ├─ .gitkeep
275
+ └─ README.md
281
276
  ```
282
277
 
283
- Custom endpoints and `forcePathStyle` support common S3-compatible deployments such as MinIO. Keep credentials server-only.
284
-
285
- Read more: [S3-Compatible Storage](docs/s3-storage.md)
278
+ Runtime objects remain ignored by Git.
286
279
 
287
- ### Streaming storage
280
+ Guides:
288
281
 
289
- The stable minimum `StorageAdapter` retains its buffered API while adapters can expose optional `putStream()` and `readStream()` implementations.
290
-
291
- ```ts
292
- import {
293
- getStorageCapabilities,
294
- putStorageStream,
295
- readStorageStream,
296
- } from "bcp/server";
297
- ```
298
-
299
- Both built-in local and S3 adapters support streaming reads/writes and byte ranges.
300
-
301
- Read more: [Storage and File Delivery](docs/storage.md)
282
+ - [File Upload](docs/file-upload.md)
283
+ - [Storage & File Delivery](docs/storage.md)
284
+ - [Storage Ecosystem](docs/storage-ecosystem.md)
285
+ - [S3-Compatible Storage](docs/s3-storage.md)
302
286
 
303
- ### Storage Ecosystem — 0.1.27
287
+ ## Production build
304
288
 
305
- BCP `0.1.27` added a richer, additive object-storage API without invalidating older `StorageAdapter` implementations:
289
+ Build:
306
290
 
307
- ```ts
308
- import {
309
- copyStorageObject,
310
- createStorageSignedReadUrl,
311
- createStorageSignedWriteUrl,
312
- deleteStorageObjects,
313
- getStorageEcosystemCapabilities,
314
- getStorageMetadata,
315
- listStorageObjects,
316
- moveStorageObject,
317
- setStorageMetadata,
318
- } from "bcp/server";
291
+ ```bash
292
+ npm run build
319
293
  ```
320
294
 
321
- Listing supports prefix filtering, limits and opaque cursors. Copy and move use native adapter operations when available, with portable fallback behavior where practical. Portable user metadata is string-to-string metadata and is distinct from authorization/business state.
322
-
323
- S3-compatible storage also supports short-lived presigned direct-transfer URLs. Local storage intentionally does not emulate signed URLs.
324
-
325
- Read more: [Storage Ecosystem](docs/storage-ecosystem.md)
326
-
327
- ## File delivery
295
+ Output:
328
296
 
329
- `createStorageResponse()` serves local or cloud-backed objects through the same API with `GET`, `HEAD`, ETag/Last-Modified validators and single byte ranges.
330
-
331
- ```ts
332
- import {
333
- createStorageResponse,
334
- } from "bcp/server";
335
-
336
- return createStorageResponse(
337
- request,
338
- storage,
339
- "documents/report.pdf"
340
- );
297
+ ```text
298
+ .bcp-framework/build/
299
+ ├─ client/
300
+ ├─ public/
301
+ └─ server/
302
+ └─ server.mjs
341
303
  ```
342
304
 
343
- Read more: [Storage and File Delivery](docs/storage.md)
344
-
345
- ## Middleware, validation, errors and caching
346
-
347
- BCP includes Middleware System v2, typed validation helpers, structured HTTP errors, structured logging and response caching/revalidation.
348
-
349
- Read more:
350
-
351
- - [Middleware](docs/middleware.md)
352
- - [Validation](docs/validation.md)
353
- - [Error Handling](docs/error-handling.md)
354
- - [Logging and Observability](docs/development-logging.md)
355
- - [Caching](docs/caching.md)
356
- - [Security](docs/security.md)
357
-
358
- ## Production build
305
+ Run:
359
306
 
360
307
  ```bash
361
- npm run build
362
308
  npm run start
363
309
  ```
364
310
 
365
- Standalone output is written under:
311
+ The `0.2.0` platform build target is explicitly:
366
312
 
367
313
  ```text
368
- .bcp-framework/build/
369
- ├─ client/
370
- ├─ public/
371
- └─ server/
372
- └─ server.mjs
314
+ standalone-node
373
315
  ```
374
316
 
375
- ### Production Hardening 0.1.28
317
+ Native `.exe`, desktop and mobile compilation are not part of the `0.2.0` platform contract.
376
318
 
377
- The standalone runtime is wrapped by a public hardening gateway with configurable HTTP and shutdown behavior:
319
+ Production hardening supports:
378
320
 
379
321
  ```dotenv
380
322
  BCP_REQUEST_TIMEOUT_MS=120000
@@ -384,170 +326,93 @@ BCP_SHUTDOWN_TIMEOUT_MS=10000
384
326
  BCP_TRUST_PROXY=false
385
327
  ```
386
328
 
387
- Standalone production handles `SIGTERM` and `SIGINT`, drains the public listener, runs application cleanup hooks and then stops internal runtime layers.
329
+ Enable trusted proxy mode only when untrusted clients cannot bypass the trusted reverse proxy/load balancer.
388
330
 
389
- ```ts
390
- import {
391
- registerShutdownHook,
392
- } from "bcp/server";
331
+ Read more: [Production Hardening](docs/production-hardening.md)
393
332
 
394
- registerShutdownHook(
395
- () => {
396
- storage.destroy();
397
- },
398
- {
399
- name: "storage",
400
- }
401
- );
402
- ```
333
+ ## Doctor / Inspect / project metadata
403
334
 
404
- Trusted proxy mode is disabled by default. Enable `BCP_TRUST_PROXY=true` only when direct untrusted traffic cannot bypass the trusted reverse proxy/load balancer.
335
+ Project diagnostics:
405
336
 
406
- Read more: [Production Hardening](docs/production-hardening.md)
337
+ ```powershell
338
+ npm exec -- bcp-framework doctor
339
+ npm exec -- bcp-framework inspect --json
340
+ ```
407
341
 
408
- ## Doctor and Inspect v2 0.1.29
342
+ Doctor/Inspect v2 can report lockfile/package-manager state, duplicate framework declarations, standalone build presence, Docker/project diagnostics, storage provider and production-hardening configuration.
409
343
 
410
- `bcp doctor` now includes additional project/runtime diagnostics for:
344
+ Projects created by recent `create-bcp-app` versions include non-secret scaffold metadata:
411
345
 
412
346
  ```text
413
- lockfile / package manager
414
- multiple framework dependency declarations
415
- standalone production artifact
416
- Docker + reproducible install guidance
417
- storage provider
418
- production-hardening environment validity
347
+ bcp.project.json
419
348
  ```
420
349
 
421
- `bcp inspect` keeps its existing fields and adds a machine-readable `project` object with project metadata, selected presets and runtime/deployment information.
350
+ Credentials, database passwords, access keys, JWT/session secrets and tokens must never be stored in that file.
422
351
 
423
- ```powershell
424
- npm exec -- bcp-framework doctor --json
425
- npm exec -- bcp-framework inspect --json
426
- ```
352
+ Guides:
427
353
 
428
- Read more: [Developer Tools](docs/developer-tools.md)
354
+ - [Developer Tools](docs/developer-tools.md)
355
+ - [Project Metadata](docs/project-metadata.md)
429
356
 
430
- ## Project metadata 0.1.29
357
+ ## Updating from 0.1.x
431
358
 
432
- New `create-bcp-app` projects include `bcp.project.json`:
359
+ `0.2.0` does not intentionally remove public entrypoints from the `0.1.29` baseline.
433
360
 
434
- ```json
435
- {
436
- "schemaVersion": 1,
437
- "framework": "bcp",
438
- "projectName": "my-app",
439
- "packageManager": "npm",
440
- "presets": {
441
- "tailwind": true,
442
- "database": "mysql",
443
- "auth": "jwt-cookie",
444
- "storage": "local"
445
- }
446
- }
447
- ```
361
+ Recommended upgrade flow after publication:
448
362
 
449
- This file stores only non-secret scaffold metadata. Credentials, database passwords, access keys, JWT/session secrets and tokens stay in environment/server-only configuration.
363
+ ```powershell
364
+ npm exec -- bcp-framework doctor
365
+ npm exec -- bcp-framework update --check
366
+ npm exec -- bcp-framework update 0.2.0
367
+ npm run typecheck
368
+ npm run build
369
+ ```
450
370
 
451
- Existing projects without the file continue to work; diagnostic tooling falls back to project files where practical.
371
+ Do not reuse a standalone `.bcp-framework/build` produced by an older framework version; rebuild after upgrading.
452
372
 
453
- Read more: [Project Metadata](docs/project-metadata.md)
373
+ Read more: [Migrating to 0.2.0](docs/migration-0.2.md)
454
374
 
455
- ## Windows CLI
375
+ ## Documentation source and bcp-docs-web
456
376
 
457
- Microsoft SQL Server can install another executable named `bcp.exe`. BCP publishes the collision-free alias `bcp-framework`.
377
+ The framework repository is the documentation source of truth.
458
378
 
459
- Inside project npm scripts, `bcp` is safe because npm prepends `node_modules/.bin` to `PATH`.
379
+ `bcp-docs-web` should consume:
460
380
 
461
- For direct PowerShell usage:
381
+ ```text
382
+ docs/docs-web-manifest.json
383
+ -> navigation, routes, Markdown sources and release routes
462
384
 
463
- ```powershell
464
- npm exec -- bcp-framework --version
465
- npm exec -- bcp-framework doctor
466
- npm exec -- bcp-framework inspect
467
- npm exec -- bcp-framework routes
468
- npm exec -- bcp-framework generate page dashboard/users
469
- npm exec -- bcp-framework dev
470
- npm exec -- bcp-framework build
385
+ docs/platform-manifest.json
386
+ -> version, runtime target, public entrypoints and capabilities
471
387
  ```
472
388
 
473
- Read more: [Developer Tools](docs/developer-tools.md)
389
+ Markdown under `docs/` remains the authored content source.
474
390
 
475
- ## Updating BCP
391
+ Start here:
476
392
 
477
- ```bash
478
- bcp update
479
- bcp update --check
480
- bcp update --dry-run
481
- bcp update 0.1.29
482
- bcp update next
483
- ```
393
+ - [Documentation Source Map](docs/README.md)
394
+ - [Docs-Web Manifest](docs/docs-web-manifest.json)
395
+ - [Platform Manifest](docs/platform-manifest.json)
396
+ - [Framework Platform Contract](docs/platform-contract.md)
397
+ - [Migration Guide](docs/migration-0.2.md)
484
398
 
485
- Read more: [Updating](docs/updating.md)
399
+ ## Release validation
486
400
 
487
- ## Framework development and release validation
401
+ Framework releases must pass:
488
402
 
489
403
  ```bash
490
404
  npm install
491
405
  npm run typecheck
492
406
  npm run test:unit
493
407
  npm run test:integration
494
- npm run test:e2e
495
408
  npm run test:package
409
+ npm run test:e2e
496
410
  npm run rc:check
497
411
  ```
498
412
 
499
- A version must not be tagged or published until its RC and packed-package verification pass.
500
-
501
- Read more: [Releasing](docs/releasing.md)
502
-
503
- ## Documentation source and `bcp-docs-web`
504
-
505
- The `docs/` directory is the authored source for **`bcp-docs-web`**.
506
-
507
- Starting with `0.1.29`, docs-web should consume:
508
-
509
- ```text
510
- docs/docs-web-manifest.json
511
- ```
512
-
513
- for sidebar/navigation and route mapping. Markdown files remain the documentation content source of truth.
413
+ `0.2.0` adds a platform-contract package smoke check that verifies the prepared npm artifact's public exports, executable aliases, Node baseline, docs metadata and framework/create-app version parity.
514
414
 
515
- The manifest contains:
516
-
517
- ```text
518
- section id/title
519
- website route
520
- Markdown source file
521
- page title
522
- version target
523
- release state
524
- release routes
525
- ```
526
-
527
- Recommended starting points:
528
-
529
- - [Docs-Web Manifest](docs/docs-web-manifest.json)
530
- - [Documentation Source Map](docs/README.md)
531
- - [Getting Started](docs/getting-started.md)
532
- - [Configuration](docs/configuration.md)
533
- - [Project Metadata](docs/project-metadata.md)
534
- - [Routing](docs/routing.md)
535
- - [Project Generators](docs/generators.md)
536
- - [Server Data Loaders](docs/server-data-loaders.md)
537
- - [Route Guards](docs/route-guards.md)
538
- - [Form Actions](docs/form-actions.md)
539
- - [Server Request APIs](docs/server-request-apis.md)
540
- - [File Upload](docs/file-upload.md)
541
- - [Storage and File Delivery](docs/storage.md)
542
- - [Storage Ecosystem](docs/storage-ecosystem.md)
543
- - [S3-Compatible Storage](docs/s3-storage.md)
544
- - [Production Hardening](docs/production-hardening.md)
545
- - [Authentication](docs/authentication.md)
546
- - [Database](docs/database.md)
547
- - [Middleware](docs/middleware.md)
548
- - [Developer Tools](docs/developer-tools.md)
549
- - [Deployment](docs/deployment.md)
550
- - [Releasing](docs/releasing.md)
415
+ Do not tag or publish a release until the final release commit passes the complete RC sequence.
551
416
 
552
417
  ## Release history
553
418
 
@@ -563,20 +428,13 @@ Recommended starting points:
563
428
  | `0.1.27` | Storage Ecosystem |
564
429
  | `0.1.28` | Production Hardening |
565
430
  | `0.1.29` | Developer Experience |
431
+ | `0.2.0` | Framework Platform baseline |
566
432
 
567
433
  ## Next direction
568
434
 
569
- After `0.1.29`, the planned major milestone is **`0.2.0 Framework Platform`**.
570
-
571
- The focus should be consolidation rather than unrelated feature growth:
572
-
573
- 1. public API consistency and compatibility expectations,
574
- 2. production-runtime stabilization across supported deployment paths,
575
- 3. documentation completeness and docs-web integration,
576
- 4. migration guidance for pre-`0.2.0` applications,
577
- 5. a documented platform baseline for routing, data, auth, database, storage and runtime APIs.
435
+ After the `0.2.0` platform baseline is validated and released, later `0.2.x` work can add broader build/deployment targets and higher-level platform features without changing the existing standalone Node.js contract by accident.
578
436
 
579
- These are roadmap goals, not `0.1.29` guarantees.
437
+ Native executable/desktop/mobile packaging remains future roadmap work, not a `0.2.0` guarantee.
580
438
 
581
439
  ## License
582
440