# WRNexusJS 0.3 — One-by-One Test Checklist

Use this checklist on a clean branch before publishing. Run the global gates first, then test the numbered capabilities in order. Keep one of the three existing applications on its current release so you can compare output and behavior during the upgrade.

## Global release gates

```bash
bun install
bun run verify:0.3
bun run typecheck
bun run lint
bun run test
bun run format:check
bun run build
```

Expected: every command exits with code 0. The build must create `dist/build-report.json`.

For the VS Code extension:

```bash
cd editors/vscode
bun run check
bun run package
```

Expected: editor tests and validation pass, `src/compiler.cjs` is rebuilt from the 0.3 compiler, and a 0.3.0 VSIX is produced.

## Existing application upgrade safety

Run this separately in each existing application:

```bash
wrnexus update . --version=0.3.0 --dry-run
wrnexus update . --version=0.3.0
bun run format
bun run check
bun run build
wrnexus doctor .
wrnexus config . --explain
wrnexus analyze .
```

Verify before committing:

1. `.wrnexus/update-backups/` contains the original `app/` directory and project configuration.
2. `.wrnexus/migrations/0.3.0.json` lists only files that were actually normalized.
3. Dynamic attributes use quoted expressions, for example `items='{items}'`.
4. Existing `data-for`, `{#each}`, component mounts, pages, layouts, APIs, middleware, gateway routes, and authentication flows still work.
5. The package marker is updated only after installation, checks, and build succeed.

## 40 capability tests

|   # | Capability                 | Test                                                                                                                        | Expected result                                                                                       |
| --: | -------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
|   1 | Language specification     | Open `docs/WRN-LANGUAGE-SPEC-1.0.md`; compile each root member shown there.                                                 | Compiler and editor accept the same syntax.                                                           |
|   2 | Shared parser/AST          | Import `parse` from both `@wrnexus/syntax` and `@wrnexus/compiler`.                                                         | Equivalent ASTs; old compiler imports continue working.                                               |
|   3 | Compile/runtime separation | Build a static page with no state/events.                                                                                   | Page sends no reactive runtime unless another feature requires it.                                    |
|   4 | Fine-grained reactivity    | Change one signal used by one binding while another signal remains unchanged.                                               | Only dependent renderers run; `batch`, `computed`, and `effect` behave predictably.                   |
|   5 | Deterministic hydration    | SSR a stateful component, then hydrate it. Test keyed reorder with `data-for="item in items key item.id"`.                  | No mismatch; keyed DOM nodes retain identity and focus on reorder.                                    |
|   6 | Partial hydration          | Test `hydrate = "load"`, `idle`, `visible`, `interaction`, `media:...`, and `none`.                                         | Each component hydrates only under its selected condition.                                            |
|   7 | Server-only execution      | Set `runtime = "server"` on a static component, then add a browser event deliberately.                                      | Static version ships no client scope; interactive server-only version reports a compile diagnostic.   |
|   8 | Data loading               | Define a loader, action, request-local `dedupe`, cache metadata, and invalidation tags.                                     | Loader/action types are inferred and duplicate request work runs once.                                |
|   9 | Streaming SSR              | Return an async iterable body with delayed chunks.                                                                          | Shell/head arrive first and later chunks complete valid HTML.                                         |
|  10 | Routing                    | Create route groups, `[id?]`, `[[id]]`, `[...slug]`, and `[[...slug]]`.                                                     | Groups do not affect URLs; optional/catch-all params match and conflicts are reported.                |
|  11 | Middleware                 | Add global middleware plus tracing and tenancy middleware.                                                                  | Execution order is deterministic and context values reach the route.                                  |
|  12 | Typed API/RPC              | Define an endpoint with input/output schemas and call it through `createRpcClient`.                                         | Invalid input returns a structured error; valid output is typed.                                      |
|  13 | Security defaults          | Test CSP, CSRF, secure cookies, CORS, body/upload limits, and a raw HTML boundary.                                          | Unsafe requests/content are rejected and security headers are present.                                |
|  14 | DevToolbar                 | Open a page containing missing alt text, low contrast, oversized image, bad SEO, and runtime diagnostic.                    | Toolbar groups issues by panel and shows source/actionable detail.                                    |
|  15 | Optimization reports       | Build and run `wrnexus analyze .`.                                                                                          | Report shows assets, route sizes, measurements, diagnostics, and budget status.                       |
|  16 | Error messages             | Add a malformed prop, invalid runtime, and duplicate symbol.                                                                | Error contains stable code, file, line/column, code frame, and hint.                                  |
|  17 | Editor/LSP behavior        | Test completion, hover/diagnostics, go-to-definition, formatting, snippets, and multiline props.                            | Editor behavior matches compiler syntax with no false unknown-member errors.                          |
|  18 | Schemas/validation         | Submit invalid and valid data through existing form/API validation and a typed endpoint schema.                             | Client/server errors agree and valid types are inferred.                                              |
|  19 | Authentication             | Test session login/logout, protected middleware, OAuth/passkey integrations used by your apps, and route security metadata. | Existing SSO flows remain unchanged and protected routes reject anonymous users.                      |
|  20 | Multi-tenancy              | Configure subdomain, domain, and path tenancy separately.                                                                   | `ctx.tenant` resolves correctly and tenant-scoped operations reject missing tenancy.                  |
|  21 | Jobs/cron/workflows        | Queue priority jobs, duplicate idempotency keys, retries, cancellation, concurrency, workflow steps, and cron aliases.      | Priority/order/retries are deterministic; duplicates do not create extra queued work.                 |
|  22 | Realtime                   | Connect an authenticated room, publish through the existing bus/Redis bridge, disconnect, and reconnect.                    | Authorization, delivery, cleanup, and horizontal bridge behavior remain correct.                      |
|  23 | Plugins                    | Register pre/normal/post plugins with `before`/`after`, AST/code transforms, diagnostics, server and build hooks.           | Order is deterministic; duplicates/cycles fail with stable errors.                                    |
|  24 | Infrastructure adapters    | Run the same built app through the existing Bun and Node/fetch adapter paths; test configured deployment adapter metadata.  | Request/response semantics and build report remain consistent.                                        |
|  25 | Build caching/HMR          | Change CSS, a leaf component, a shared component, server code, and route structure separately.                              | Only affected work is rebuilt; structural changes trigger the correct reload level.                   |
|  26 | Compatibility/migrations   | Upgrade a copied legacy app twice.                                                                                          | First run changes only required files; second run is source-idempotent; backup/report exist.          |
|  27 | Testing                    | Run the full package suite and the three upgraded app suites.                                                               | All old regressions plus new 0.3 tests pass.                                                          |
|  28 | Performance budgets        | Set deliberately small HTML/JS/CSS/image budgets, then realistic budgets.                                                   | Build warns/fails according to policy, then passes with realistic limits.                             |
|  29 | Observability              | Enable tracing and `serverTiming`; make a request containing nested spans.                                                  | Trace records include duration/status/attributes and response has `Server-Timing`.                    |
|  30 | Component architecture     | Render primitives, behavior components, layouts, and product components in light/dark/responsive states.                    | Props/events/slots/accessibility remain consistent and app overrides still win.                       |
|  31 | Design tokens              | Audit `--wire-*` usage and switch themes.                                                                                   | Components use semantic tokens and no required token is undefined.                                    |
|  32 | Accessibility              | Compile missing-alt markup and run toolbar keyboard/focus/ARIA checks.                                                      | Compile-time and runtime accessibility findings appear without duplicates or false positives.         |
|  33 | Motion/transitions         | Exercise existing lifecycle/animation behavior with reduced-motion enabled and disabled.                                    | Motion respects user preference and teardown does not leak listeners/timers.                          |
|  34 | Documentation              | Follow the language, architecture, upgrade, and this checklist from a clean clone.                                          | Commands/examples match actual APIs and produce the documented result.                                |
|  35 | AI-friendly metadata       | Inspect language spec exports, structured diagnostics, component metadata, route manifest, and build report.                | Tools can consume JSON/typed metadata without parsing human logs.                                     |
|  36 | Feature flags              | Resolve boolean/function flags for two users/tenants and across async work.                                                 | Context does not leak and experimental features stay disabled by default.                             |
|  37 | Public APIs                | Search applications/plugins for imports containing `/src/` or undocumented internals.                                       | Consumers use only exported package entry points.                                                     |
|  38 | Configuration              | Layer defaults, profile, environment, project config, and route overrides; run `config --explain`.                          | Final value and its source are clear; invalid settings report paths.                                  |
|  39 | Gateway                    | Test host/path routing, forward auth with app + path, WebSockets, timeouts, headers, and development/production origins.    | Existing domains work; internal service resolution avoids hardcoded production URLs.                  |
|  40 | Release gates              | Run `verify:0.3`, full checks, app upgrades, builds, editor package, and release prepare.                                   | Version topology, migration uniqueness, lockfile, docs, tests, and artifacts all pass before publish. |

## Recommended rollout

1. Upgrade a disposable copy of the least complex application.
2. Compare generated HTML, browser JavaScript, routes, gateway behavior, and screenshots against its current production version.
3. Upgrade the second and third applications only after the first passes this checklist.
4. Publish 0.3.0 as a prerelease first if the three applications exercise materially different subsystems.
