# Where WRNexusJS Should Go Next

## Repository status snapshot — 2026-08-02

This is a long-term design roadmap. Status below distinguishes tested implementation from
aspiration. `Delivered` requires repository evidence, `Partial` is usable but incomplete,
and `Future` is intentionally not represented as production-ready.

| #   | Initiative                                   | Status    | Implemented foundation / remaining scope                                                                                                                                                                                                                                    |
| --- | -------------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1   | End-to-end typed server actions              | Delivered | Schema-backed WRN actions provide typed clients, serialization, auth/authz, CSRF, lifecycle/optimistic events, invalidation and progressive forms.                                                                                                                          |
| 2   | Framework-wide type safety                   | Delivered | Generated contracts cover routes/query values, schema-derived API input/output, actions/components, middleware contexts, SQL query args/results, env/i18n/config, typed realtime messages, queue payloads and cache keys; compile-time examples reject invalid shapes.      |
| 3   | Rendering and hydration modes                | Delivered | Explicit `static/server/hybrid/client/partial-static` policies, zero-JS enforcement and load/idle/visible/interaction/media/never hydration ship; client mode mounts inert templates before hydration and partial-static uses build shells plus streamed regions.           |
| 4   | Data loading, streaming and async boundaries | Delivered | Named load DAGs run independent work in parallel, memoize dependencies and support deferred/client phases; streamed SSR, `<Async>` loading/success/error UI, bounded retry/dedup/cancellation, SWR caches and route prefetching ship.                                       |
| 5   | Predictable cache architecture               | Delivered | Separate request/data/component/page caches, declarative policies, safe identity variation, tags/keys, SWR, locks, stampede protection, distributed invalidation, development logs and DevToolbar inspection ship.                                                          |
| 6   | Plugin lifecycle                             | Delivered | Ordered async setup/config/transform/server/build/render/deploy/shutdown/HMR hooks and typed directive/CLI/config/adapter/virtual/docs/type contributions run through the same build and development pipeline. Generated application artifacts aggregate plugin docs/types. |
| 7   | Layers and presets                           | Delivered | Recursive local/package `extends` composition, deterministic precedence, profile merging, cycle diagnostics and source explanations ship; layers compose plugins and all app config.                                                                                        |
| 8   | Framework-level security                     | Partial   | CSP, CSRF, CORS, headers, limits, SSRF/open-redirect helpers, replay controls and abuse tests ship; full ASVS certification remains.                                                                                                                                        |
| 9   | Complete DevToolbar                          | Delivered | Runtime/store/cache/compiler inspectors plus live SQL/slow-query, queue definition, realtime route, translation-gap, unused-CSS, memory/Web-Vitals and upgrade providers ship with plugin panels and safe editor integration.                                               |
| 10  | Cross-editor language server                 | Delivered | The canonical stdio LSP and VS Code/Neovim/JetBrains clients provide mapped diagnostics, navigation/refactors and workspace-aware components/contracts/routes/i18n/CSS/database/schema completion.                                                                          |
| 11  | First-class testing platform                 | Delivered | Seven test levels, managed Playwright browser matrices/installations, HTML reports, screenshots/traces, database rollback/factories, deterministic CI sharding and full application harnesses ship.                                                                         |
| 12  | Jobs, cron and durable workflows             | Delivered | Durable queues/workflows include memory, Redis and PostgreSQL stores, batching/chaining, scheduler daemon, dashboard snapshots/HTML, retries, leases, approvals, progress and cancellation.                                                                                 |
| 13  | Realtime platform                            | Delivered | Typed rooms, presence/replay/reconnect/backpressure, SSE, Redis/NATS/Kafka scaling, filtered database feeds, bounded file streaming and payload-free DevToolbar monitoring ship.                                                                                            |
| 14  | Storage, files and media                     | Delivered | Safe local/S3/CDN storage, multipart acceleration, resumable uploads, durable quotas, temporary cleanup, malware/DLP hooks, image variants and injectable FFmpeg video transcoding ship.                                                                                    |
| 15  | Native multi-tenancy                         | Delivered | Tenant resolution/context, scoped repositories/cache/storage, durable memberships/quotas, workspace switching, audits and bounded per-tenant migration orchestration ship.                                                                                                  |
| 16  | API platform and SDK generation              | Delivered | REST/RPC, OpenAPI/docs/Postman/curl, five SDK languages, an engine-neutral hardened GraphQL plugin and OpenAPI 3.1 webhook prose/schema/signature extraction ship.                                                                                                          |
| 17  | Frontend reactive capabilities               | Delivered | Fine-grained reactivity, history/URL/context, declarative portals/transitions/dynamic components, cancellable hydration coordination and forward/reverse timeline animations ship.                                                                                          |
| 18  | Content and documentation system             | Delivered | Typed collections, safe Markdown/registered MDX components, lazy syntax bundles, preview/version/search/feed tooling and Contentful/Sanity/Strapi adapters ship.                                                                                                            |
| 19  | PWA and offline applications                 | Delivered | Generated manifests/workers, caching/sync/push/install/update, migrated IndexedDB queues, durable push subscriptions and escaped queue/conflict review UI ship.                                                                                                             |
| 20  | Deployment and infrastructure                | Delivered | Docker/Compose, Kubernetes, systemd/nginx, Railway, Render and Fly presets ship with probes, migrations, graceful shutdown, assets, env/secrets, logs and scaling guidance.                                                                                                 |
| 21  | Open-standard observability                  | Delivered | W3C/OTLP traces, metrics and logs, subsystem/custom spans, Prometheus/Grafana, Jaeger/Zipkin, Sentry-compatible errors, profiling, request IDs and health ship.                                                                                                             |
| 22  | Enterprise identity and governance           | Delivered | Auth/authz plus the official identity package cover OAuth/OIDC, SAML, LDAP/AD adapters, SCIM, passkeys/MFA/devices/sessions, machine identities, policy, approvals, audited impersonation and privacy governance.                                                           |
| 23  | AI-native development                        | Delivered | OpenAI/Anthropic/Google/local adapters, structured tools/streaming, embeddings/vector/RAG, persistence/templates/guardrails/usage/tracing/fallback/rate/evals and a framework-context MCP server ship.                                                                      |

### Language-server delivery

The server is editor-neutral and backed by the canonical syntax package. Run:

```bash
bunx wrnexus-language-server --stdio
```

VS Code enables the bundled server by default and retains local providers only as a
startup fallback. Neovim and JetBrains LSP clients use the same stdio command, preventing
parser and diagnostic drift between editors.

WRNexusJS already has much more than a normal early-stage framework: SSR-first `.wrn` rendering, automatic hydration, file-based routing, APIs, middleware, realtime rooms, database tooling, validation, authentication, authorization, OAuth, caching, queues, pub/sub, security, observability, testing, type-checking and more than 100 UI components.

The biggest mistake now would be creating many unrelated packages. The next goal should be:

> **One framework where a developer can build, test, secure, deploy, monitor and maintain a complete application without manually connecting ten different systems.**

## 1. End-to-End Typed Server Actions

This should be the highest priority.

Developers should be able to call server-side functions directly from `.wrn` pages without manually creating API routes, fetch calls, JSON parsing and loading states.

Proposed concept:

```wrn
page Users {
  action createUser using CreateUserSchema {
    const user = await db.users.create(input)
    invalidate("users")
    return user
  }

  view {
    <form @submit='createUser'>
      <Input name="name" />
      <Button type="submit">Create user</Button>
    </form>
  }
}
```

The compiler should automatically provide:

- Request and response serialization
- Schema validation
- Authentication and authorization checks
- CSRF protection
- Pending, success and error states
- Optimistic updates
- Cache invalidation
- Type-safe client calls
- Progressive enhancement when JavaScript is disabled

Modern frameworks increasingly connect forms and server mutations directly; Next.js provides Server Functions, while SvelteKit provides server-side form actions. ([Next.js][1])

## 2. Complete Type-Safety Across the Framework

WRNexusJS should generate types for the entire application:

- Route names and parameters
- Query parameters
- API request bodies
- API responses
- Server actions
- Component props, slots and events
- Middleware context
- Database queries
- Environment variables
- Translation keys
- Configuration
- Realtime messages
- Queue jobs
- Cache keys

For example:

```ts
navigate(route("users.details", { id: user.id }));
```

Invalid route names or missing parameters should fail during development and CI, not in production.

Add commands such as:

```bash
wrnexus typecheck
wrnexus generate types
wrnexus routes
wrnexus inspect component Button
```

Delivered in v0.8: all four commands above are implemented. Generated named routes enforce
required parameters and accept typed query values; `wrnexus typecheck` validates TypeScript and
every `.wrn` source. `app/types/wrnexus.generated.d.ts` now centralizes component, environment,
translation, cache and configuration types plus exact schema-derived endpoint input/output,
middleware context, generated SQL query arguments/results, typed realtime messages and queue
payloads. The basic application contains positive assignments and `@ts-expect-error` assertions
that make contract regressions fail compilation.

## 3. Explicit Rendering and Hydration Modes

Currently, automatic SSR and hydration make development simple. The next step is giving developers control when needed.

Every page or component should support:

```wrn
render = "static"
render = "server"
render = "hybrid"
render = "client"

hydrate = "load"
hydrate = "idle"
hydrate = "visible"
hydrate = "interaction"
hydrate = "media"
hydrate = "never"
```

This would provide:

- Zero-JavaScript static components
- Interactive islands
- Server-only components
- Lazy hydration below the fold
- Reduced browser bundle size
- Better performance on low-end devices
- Better control for dashboards versus marketing pages

Astro’s islands architecture renders most content as static HTML and adds JavaScript only where interaction is required. ([Astro Docs][2])

WRNexusJS does not need to copy Astro, but it should provide similarly clear control through native `.wrn` syntax.

Delivered foundation in v0.8: all listed `render` values parse and compile to explicit metadata;
`static` and `server` force hydration off, while `hydrate = "never"` is the readable alias for
the runtime's `none` strategy. Idle, visibility, interaction, and `media:<query>` scheduling are
implemented in the browser runtime. Client rendering now emits an inert template and browser mount
anchor rather than an SSR page body; partial-static routes embed a build-time shell and stream only
request-dependent regions.

## 4. Unified Data Loading, Streaming and Async Boundaries

Add a complete data-loading model:

```wrn
load users {
  return db.users.list()
}
```

Support:

- Parallel data loading
- Dependent data loading
- Streaming SSR
- Deferred data
- Suspense-like boundaries
- Loading placeholders
- Error boundaries
- Request cancellation
- Automatic deduplication
- Retry policies
- Stale-while-revalidate
- Route-level prefetching

Proposed UI:

```wrn
<Async source='users'>
  <Loading>
    <SkeletonTable />
  </Loading>

  <Success data='users'>
    <UserTable items='users' />
  </Success>

  <Error error='error'>
    <ErrorState message='error.message' />
  </Error>
</Async>
```

Delivered in v0.8: named loads are memoized dependency nodes. Independent nodes execute in
parallel, `after first, second` declares validated dependencies, cycles and invalid cross-phase
dependencies fail compilation, and `defer` moves server work behind the bounded client-load
endpoint. Results enter `ctx.data` and named page context. `<Async>` compiles loading, success and
error templates; server data renders success during SSR, while client/deferred data uses a
same-route authenticated request with shared-request deduplication, bounded retries, safe text
interpolation and navigation cancellation. Existing streaming, request dedupe, stale-while-
revalidate caches and link focus/hover prefetching complete the data path.

## 5. Predictable Cache Architecture

You already have `@wrnexus/cache`. Now make caching a first-class framework concept rather than only a package.

Support four clearly separated caches:

1. Request cache
2. Data cache
3. Component cache
4. Full-page cache

Example:

```wrn
cache {
  strategy = "stale-while-revalidate"
  ttl = "5m"
  tags = ["users", "dashboard"]
  vary = ["tenant", "language"]
}
```

Required capabilities:

- Key-based and tag-based invalidation
- User-specific and tenant-specific caches
- Distributed Redis-compatible cache
- Memory cache for development
- Cache stampede prevention
- Cache locking
- Background revalidation
- Cache inspection in DevToolbar
- Clear development logs explaining cache hits and misses

Next.js currently exposes both data-level and UI-level caching with inputs contributing to cache keys. ([Next.js][3])

The important part for WRNexusJS is to make its cache model easier to understand than competing frameworks.

Delivered in v0.8: `CacheCoordinator` separates request, data, component, and full-page
lifetimes. `.wrn` cache blocks compile to runtime policy metadata; loaders, components, and safe
documents consume it. Keys automatically include authenticated user and tenant identity, while
full pages additionally vary by language, theme, and accent. Tag/key invalidation, Redis-compatible
cross-instance invalidation, bounded memory storage, per-key locking, stampede suppression,
background SWR, development event logs, response diagnostics, and the DevToolbar Cache panel are
covered by focused tests. Full-page storage refuses CSRF-bearing documents and rotates cached CSP
nonces per response.

## 6. A Powerful Plugin Lifecycle

`@wrnexus/plugin` should become the foundation of the ecosystem.

Create stable hooks covering the complete application lifecycle:

```ts
definePlugin({
  name: "wrnexus-plugin-example",

  setup() {},
  config() {},
  routes() {},
  components() {},
  middleware() {},
  compiler() {},
  transform() {},
  devServer() {},
  devToolbar() {},
  build() {},
  render() {},
  deploy() {},
  shutdown() {},
});
```

Plugins should be able to:

- Add `.wrn` compiler transformations
- Register pages and API routes
- Register components and directives
- Add middleware
- Add CLI commands
- Add DevToolbar applications
- Add database migrations
- Add configuration schemas
- Add deployment adapters
- Add virtual modules
- Extend documentation
- Participate in HMR
- Add type definitions

Vite’s success is strongly connected to its well-defined transform, development server, build and HMR plugin hooks. Nuxt similarly allows modules to extend major framework areas. ([vitejs][4])

Plugin APIs must be versioned and treated as public contracts.

Delivered foundation in v0.8: plugins have deterministic setup, configuration, compiler,
diagnostic, route, server, build, final-render, deploy, shutdown, and HMR lifecycles. Typed
contributions cover directives, executable CLI commands, configuration validators, deployment
adapters, production virtual modules, documentation, declarations, components, routes, middleware,
assets, migrations, and DevToolbar panels. Permission inference, explicit grants, duplicate checks,
compatibility matrices, render integration, and HMR/shutdown dispatch are tested. Development now
awaits the same AST/directive/code transforms as production and materializes virtual modules before
route compilation. Type generation and production builds aggregate contributed declarations into
`app/types/wrnexus.plugins.generated.d.ts` and documentation into `.wrnexus/documentation/plugins.md`.

## 7. Layers, Presets and Reusable Application Foundations

Developers should be able to extend an existing WRNexusJS application foundation:

```ts
export default defineConfig({
  extends: ["@workroot/wrnexus-enterprise", "@workroot/wrnexus-saas", "./layers/company"],
});
```

A layer could provide:

- Layouts
- Components
- Authentication
- Themes
- API routes
- Middleware
- Database tables
- Permissions
- Translations
- Testing configuration
- Deployment configuration

This would let WorkRoot maintain reusable foundations such as:

- SaaS starter
- Admin portal starter
- Government portal starter
- E-commerce starter
- Police management starter
- Multi-tenant ERP starter

Nuxt layers support reusable configuration, components, utilities and organizational architecture across applications. ([Nuxt][5])

## 8. Framework-Level Security

Security should be enabled by default and difficult to accidentally disable.

`@wrnexus/security` should cover:

- CSRF protection
- Content Security Policy with nonces
- CORS
- Rate limiting
- Brute-force protection
- Secure headers
- Cookie policies
- Session rotation
- Request size limits
- SSRF protection
- Open redirect protection
- SQL injection prevention
- XSS-safe output
- File type validation
- Malware scanning hooks
- Secret masking
- API key rotation
- Tenant isolation
- Security audit logs
- Webhook signature validation
- Replay-attack protection

Add:

```bash
wrnexus security audit
wrnexus security headers
wrnexus security test
```

Use OWASP ASVS 5.0 as the framework’s security baseline and map framework controls to specific ASVS requirements. OWASP describes ASVS as a standard for designing and verifying security controls in modern web applications and web services. ([OWASP Foundation][6])

**Status:** Partial. The three security CLI commands, secure-default inspection, focused abuse-test discovery, and the governed ASVS 5.0.0 control map in `docs/SECURITY-ASVS-5.md` are delivered. The map deliberately does not claim application certification: tenant authorization, business rules, deployment infrastructure, API-key operations, and malware-engine integration require application-specific verification.

## 9. Complete DevToolbar

The DevToolbar can become one of WRNexusJS’s strongest differentiators.

It should include expandable applications for:

- Component tree
- Props and reactive state
- Route information
- SSR render timing
- Hydration timing
- Hydration mismatch detection
- API requests
- SQL queries
- Slow query detection
- Cache hits and misses
- Queue jobs
- Realtime connections
- Accessibility
- SEO
- Security headers
- Image optimization
- Broken links
- Missing translations
- Unused CSS
- JavaScript payload
- Memory usage
- Web Vitals
- Environment and configuration
- Framework upgrade warnings

Allow plugins to add custom toolbar applications. Astro’s development toolbar follows this extensible model and supports third-party toolbar applications. ([Astro Docs][7])

**Status:** Delivered. Runtime/store/cache inspection, browser and compiler diagnostics, hydration timing, accessibility, SEO, security, image, link, JavaScript and performance applications ship as visible filters. Plugin-contributed applications, badges, issue feeds and escaped structured data render automatically. First-party providers now expose a bounded live SQL/slow-query history, queue definitions, realtime route inventory, cross-locale missing keys, browser unused-selector sampling, server/browser memory and Web-Vitals endpoints, and framework upgrade guidance. Provider JSON is escaped, bounded and excludes environment values.

## 10. Full Language Server, Not Only a VS Code Extension

Create `@wrnexus/language-server` using the Language Server Protocol.

Then VS Code, JetBrains, Neovim and other editors can share the same implementation.

It should provide:

- Syntax errors
- Type errors
- Autocomplete
- Hover documentation
- Go to definition
- Find references
- Rename symbol
- Component prop suggestions
- Slot suggestions
- Event suggestions
- Route autocomplete
- Translation key autocomplete
- Tailwind autocomplete
- Database model autocomplete
- Schema autocomplete
- Quick fixes
- Safe refactoring
- Formatting
- Code actions
- Extract component
- Convert HTML to `.wrn`
- Detect inaccessible markup
- Detect SSR/client boundary mistakes

Also provide a TypeScript virtual-document representation of `.wrn` files so TypeScript tooling can understand expressions inside templates.

**Status:** Delivered. The editor-neutral stdio LSP ships syntax, accessibility and mapped TypeScript-expression diagnostics; completion, hover, symbols, definition, references, safe rename, formatting and quick fixes; plus a `wrnexus/virtualDocument` request backed by the canonical `@wrnexus/typecheck` virtual module. VS Code consumes the bundled server and the same command works with Neovim and JetBrains LSP clients. Its bounded workspace index adds component props/slots/events, file routes, translation keys, observed Tailwind/CSS classes and database/validation schemas. Code actions safely extract selected markup into a component and convert selected HTML into WRN syntax.

## 11. First-Class Testing Platform

`@wrnexus/test` should support all test levels through one interface:

```bash
wrnexus test unit
wrnexus test component
wrnexus test api
wrnexus test browser
wrnexus test visual
wrnexus test accessibility
wrnexus test performance
```

Important capabilities:

- `.wrn` component mounting
- Reactive state testing
- SSR output testing
- Hydration testing
- API route testing
- Middleware testing
- Realtime testing
- Queue testing
- Test database creation
- Transaction rollback between tests
- Fixtures and factories
- Authentication helpers
- Browser testing across Chromium, Firefox and WebKit
- Visual screenshot comparison
- Accessibility scanning
- Network mocking
- Test trace viewer
- CI sharding

Playwright now provides framework-agnostic component testing in real browsers, visual testing, browser matrices and accessibility integration. ([Playwright][8])

WRNexusJS should wrap this into a native developer experience rather than requiring users to configure everything themselves.

**Status:** Delivered. All seven CLI levels are parsed correctly. Unit, component, API, accessibility and performance suites use convention-based Bun test discovery; browser and `@visual` suites delegate to a detected Playwright project. `--install-browsers`, `--browsers=chromium,firefox,webkit`, HTML/line reports and native Playwright sharding provide managed browser matrices. `@wrnexus/test` supplies `.wrn` SSR rendering, reactive hydration, route calls, request/cookie/network helpers, a real in-process application harness, bounded deterministic factories, forced transaction rollback and safe screenshot/trace artifact capture. Non-browser files use stable modulo CI sharding.

## 12. Jobs, Cron and Durable Workflows

Expand queue support into a complete background execution platform.

Add:

```ts
defineJob({
  name: "send-campaign",
  input: CampaignSchema,
  retries: 5,
  timeout: "10m",
  concurrency: 10,
  idempotencyKey: (input) => input.campaignId,

  async run(input, ctx) {},
});
```

Support:

- Delayed jobs
- Recurring cron jobs
- Retry strategies
- Exponential backoff
- Idempotency
- Dead-letter queues
- Priorities
- Concurrency limits
- Progress reporting
- Job cancellation
- Chained jobs
- Batch jobs
- Durable workflows
- Human approval steps
- Scheduled workflows
- Job dashboard
- Redis, PostgreSQL and memory drivers

This is especially important for WRNexus, ERP systems, notifications, reports, uploads and government workflows.

**Status:** Delivered. Delays, interval/cron scheduling helpers, retries with exponential/custom backoff, idempotency, dead letters, priority, concurrency/capacity, cancellation and leases ship. Memory, dependency-neutral Redis and PostgreSQL stores support durable workers with atomic claims. The workflow engine adds validated dependency DAGs, persisted progress/results/failures, restart-safe pause/resume and audited human approvals. Batch insertion and workflow DAGs cover batching/chaining; the abort-aware standalone daemon runs schedules and workers; bounded dashboard snapshots and an escaped HTML renderer provide operational inspection and feed the DevToolbar queue application.

## 13. Better Realtime Platform

Expand realtime rooms beyond basic WebSockets:

- WebSockets
- Server-Sent Events
- Presence
- Typing indicators
- Channel permissions
- Private channels
- Reconnection
- Message acknowledgements
- Message replay
- Offline queue
- Backpressure
- Horizontal scaling
- Redis/NATS/Kafka pub-sub adapters
- Realtime database events
- Typed client/server messages
- File streaming
- Realtime monitoring panel

Example:

```ts
defineRoom<ChatEvents>({
  authorize: ({ user, params }) => user.can("chat.access", params.roomId),

  presence: true,
  history: 100,
});
```

**Status:** Delivered. WebSockets, authorization/private rooms, bounded typed envelopes, presence/typing helpers and UI, reconnecting clients, bounded offline sends and gateway backpressure ship. Redis, dependency-neutral NATS and Kafka adapters provide horizontal pub/sub. The bounded per-room event log adds monotonic sequences, acknowledgements, replay and SSE responses. Allowlisted database-change feeds and bounded, out-of-order file-stream reassembly use the same message contract. A payload-free live snapshot of rooms, message counts, acknowledgement counts and sequences feeds the dedicated DevToolbar realtime monitor.

## 14. Storage, Files and Media

Turn `@wrnexus/uploader` and `@wrnexus/image` into a unified storage platform:

- Local storage
- S3-compatible storage
- Cloudflare R2
- MinIO
- Signed upload URLs
- Multipart uploads
- Resumable uploads
- Chunked uploads
- Upload progress
- File validation
- Virus-scanning hooks
- Private/public buckets
- Image resizing
- Format conversion
- Responsive image generation
- Video transcoding hooks
- CDN URLs
- Storage quotas
- Temporary files
- Automatic cleanup

Developers should change storage providers through configuration without changing application code.

**Status:** Delivered. Config-selected local and S3-compatible storage covers AWS S3, R2 and MinIO; public/CDN and signed private URLs, multipart HTTP uploads, checksums, MIME/signature validation, resumable out-of-order chunks, progress UI and build-time responsive image resizing/format conversion ship. The upload pipeline has pre-storage malware/DLP scanning and post-storage hooks with automatic rollback. A bounded concurrent multipart object-client protocol provides S3 acceleration with abort cleanup. Memory and atomic PostgreSQL quota stores enforce byte/object limits. Temporary-object tracking exposes scheduled cleanup, and the injectable built-in FFmpeg transcoder safely produces bounded MP4/WebM variants without shell interpolation.

## 15. Multi-Tenancy as a Native Feature

Many enterprise and SaaS applications need tenants, organizations and workspaces.

Provide:

- Tenant resolution from domain, subdomain, header or session
- Tenant-scoped database queries
- Automatic tenant filters
- Tenant-specific themes
- Tenant-specific translations
- Tenant-specific domains
- Tenant-specific storage
- Tenant quotas
- Tenant-specific cache keys
- Cross-tenant access protection
- Organization membership
- Workspace switching
- Tenant audit logs
- Tenant migration helpers

The most important rule: it should be difficult for a developer to accidentally query another tenant’s data.

**Status:** Delivered. Native domain/subdomain/path/header/session resolvers, composable required middleware, request context, tenant keys for cache/storage, guarded resource access, membership/workspace switching, quota enforcement and audit callbacks ship. Database repositories inject an immutable scope into every CRUD/count query and overwrite caller-provided tenant IDs on create. Tenant theme/translation metadata travels on `ctx.tenant`. The packaged memory/PostgreSQL directory persists memberships, roles, workspace access and quota usage with parameterized queries. Bounded per-tenant migration orchestration isolates failures and supports controlled continue-on-error rollouts.

## 16. API Platform and SDK Generation

Support three API styles:

- REST
- Typed RPC
- GraphQL through an optional plugin

Automatically generate:

- OpenAPI specification
- Swagger-like documentation
- TypeScript SDK
- JavaScript SDK
- Java SDK
- Go SDK
- Python SDK
- Postman collection
- API examples
- Webhook documentation

Commands:

```bash
wrnexus api generate
wrnexus sdk generate typescript
wrnexus sdk generate java
wrnexus api docs
```

The route, action and validation schemas should remain the single source of truth.

**Status:** Delivered. Typed REST endpoints and RPC callers feed working `api generate`, `api docs`, and `sdk generate` commands. The route-derived pipeline emits OpenAPI 3.1, escaped static documentation, Postman, curl examples and dependency-light TypeScript, JavaScript, Java, Go and Python clients; generated output is demonstrated in `examples/basic-app/generated/api`. Statically declared webhook event, summary, description, payload-schema reference and signature-header metadata now populate OpenAPI 3.1 `webhooks` and rendered prose. Optional `@wrnexus/graphql` integrates any maintained execution engine through the plugin route lifecycle while enforcing body, depth, alias and introspection policies and hiding thrown production details.

## 17. Frontend Reactive Capabilities

The `.wrn` language should eventually provide:

- Computed values
- Watchers
- Effects
- Lifecycle callbacks
- Element references
- Two-way model binding
- Event modifiers
- Keyed loops
- Dynamic components
- Portals
- Transitions
- Animations
- Error boundaries
- Async boundaries
- Context providers
- Shared stores
- URL state
- Persisted state
- Undo/redo state
- Fine-grained updates

Possible syntax:

```wrn
state firstName = ""
state lastName = ""

computed fullName = `${firstName} ${lastName}`

watch fullName {
  console.log("Name changed", fullName)
}

effect {
  document.title = fullName || "Profile"
}
```

Keep the syntax understandable and avoid introducing React-style hook complexity.

**Status:** Delivered. The language/compiler ships fine-grained state bindings, computed values, watchers, effects, lifecycle callbacks, refs, model binding, event modifiers, keyed loops, async/error boundaries and shared/persisted stores. `@wrnexus/reactive` adds bounded undo/redo signals, URL-backed state adapters, scoped context providers and imperative portal/transition helpers. Declarative `<Portal to>`, `<Transition name>` and reactive `<Component is>` boundaries compile to hydration markers; the browser runtime moves portal content, coordinates entry classes and switches named component cases. The cancellable timeline API sequences bounded delayed/eased steps in forward or reverse order with injectable clocks/frames for deterministic tests.

## 18. Content and Documentation System

Add a typed content collection system for:

- Blogs
- Documentation
- Changelogs
- Products
- Help centres
- Knowledge bases
- Legal pages

Support Markdown, MDX-like extensions and remote content loaders.

Features:

- Schema validation
- Draft mode
- Content references
- Automatic table of contents
- Syntax highlighting
- Search indexes
- RSS
- Sitemap
- Pagination
- Content versioning
- Preview mode
- CMS adapters

Astro content collections provide schema-based, type-safe content organization and querying, which is a strong model for this area. ([Astro Docs][9])

**Status:** Delivered. Official `@wrnexus/content` provides schema-validated collections, safe Markdown rendering with code blocks, draft/token-gated previews, references, heading/TOC metadata, search indexes, RSS, sitemaps, pagination and versions. Local recursive, remote JSON and CMS loaders share one contract. MDX execution is deliberately restricted to an explicit component registry—no arbitrary JavaScript evaluation—with bounded nested expansion. Incremental highlighters load and cache only language bundles encountered by content. First-party Contentful, Sanity and Strapi adapters encode collection/query values, support bearer credentials and normalize vendor records through optional typed mappers.

## 19. PWA and Offline Applications

Create `@wrnexus/pwa` with:

- Service worker generation
- Offline pages
- Asset precaching
- Runtime caching
- Background synchronization
- Push notifications
- Install prompts
- Web app manifest
- Update notifications
- IndexedDB abstraction
- Offline forms
- Conflict resolution
- Offline queue synchronization

This would make WRNexusJS suitable for field officers, government employees, delivery applications and users in low-connectivity locations.

**Status:** Delivered. Official `@wrnexus/pwa` owns web-manifest and service-worker generation, offline navigation, asset precaching, network-first/cache-first/stale-while-revalidate rules, background-sync events, push notifications, install prompts and update events. Its bounded mutation queue supports stable idempotency IDs and client/server/last-write/custom conflict resolution. Contiguous versioned IndexedDB migrations and the native queue store provide browser durability. Validated HTTPS push subscriptions persist through bounded memory or parameterized PostgreSQL stores. The escaped queue/conflict review renderer and delegated browser runtime expose retry/remove/client/server decisions without embedding payloads into markup.

## 20. Deployment and Infrastructure

Create deployment presets:

```bash
wrnexus deploy docker
wrnexus deploy kubernetes
wrnexus deploy systemd
wrnexus deploy railway
wrnexus deploy render
wrnexus deploy fly
```

Generate:

- Optimized Dockerfile
- Docker Compose
- Kubernetes manifests
- Health and readiness endpoints
- Graceful shutdown
- Migration jobs
- Static asset configuration
- Reverse-proxy configuration
- Environment templates
- Secret requirements
- Logging configuration
- Scaling recommendations

Even if WRNexusJS remains Bun-native, deployment should not require developers to understand every Bun production detail.

**Status:** Delivered. `wrnexus deploy docker|kubernetes|systemd|railway|render|fly` now generates non-destructive deployment presets. The presets cover optimized multi-stage Bun containers, Compose, Kubernetes service/deployment/migration job resources, hardened systemd plus nginx, cloud-platform manifests, `/healthz` and `/readyz` probes, release migrations, graceful termination, immutable asset caching, environment and secret requirements, centralized logging guidance and initial horizontal-scaling resources. The basic application contains checked-in output for every target.

## 21. Observability Based on Open Standards

`@wrnexus/observability` should use OpenTelemetry-compatible concepts:

- Traces
- Metrics
- Logs
- Request IDs
- Distributed trace context
- Database spans
- Cache spans
- Queue spans
- Realtime spans
- Server-action spans
- Custom application spans
- Error reporting
- Performance profiling

OpenTelemetry defines interoperable observability signals including traces, metrics and logs. ([OpenTelemetry][10])

Provide exporters for:

- OpenTelemetry Collector
- Prometheus
- Grafana
- Jaeger
- Zipkin
- Sentry-compatible error systems

**Status:** Delivered. `@wrnexus/observability` provides W3C trace-context propagation and request IDs, structured correlated logs, metrics, Web Vitals and health probes. OTLP trace/metric/log exporters target an OpenTelemetry Collector; Prometheus text/push output supports Prometheus and Grafana; Zipkin v2 output supports Zipkin and Jaeger's compatibility endpoint; a Sentry-compatible reporter captures errors. The operation tracer standardizes database, cache, queue, realtime, server-action and custom application spans, and the lightweight profiler records application timings without coupling the framework to a vendor.

## 22. Enterprise Identity and Governance

Official enterprise packages should eventually support:

- OIDC
- OAuth
- SAML
- LDAP
- Active Directory
- SCIM provisioning
- Passkeys
- MFA
- Device management
- Session management
- API keys
- Service accounts
- RBAC
- ABAC
- Policy-based authorization
- Approval workflows
- Impersonation with auditing
- Data retention
- Export and deletion workflows
- Consent tracking

**Status:** Delivered. `@wrnexus/auth` supplies OAuth account linking, passkeys, email/SMS/TOTP/recovery-code MFA, trusted devices, revocable sessions and audited impersonation. `@wrnexus/authz` supplies RBAC, ABAC and composable policy decisions. The separate `@wrnexus/identity` package adds strict OIDC discovery and PKCE authorization, signed-SAML adapter validation with issuer/audience/recipient/expiry/replay enforcement, LDAP and Active Directory synchronization adapters, authenticated bounded SCIM provisioning, scoped API keys and service accounts, approval-gated subject exports/deletions, consent history, retention enforcement and governance audit events. SAML XML-signature and LDAP wrn parsing deliberately remain adapter responsibilities so deployments can choose a maintained protocol SDK without placing vendor code in core.

## 23. AI-Native Development

WRNexusJS already includes an AI package, but it should become provider-neutral rather than depending on one default model or vendor. The current documentation shows a direct AI creation and streaming API, making this a natural area to expand.

Add:

- OpenAI, Anthropic, Google and local model adapters
- Structured output
- Tool calling
- Streaming
- Embeddings
- Vector database adapters
- RAG pipelines
- Conversation persistence
- Prompt templates
- Guardrails
- Token and cost tracking
- AI tracing
- Model fallback
- Rate limits
- Evaluation tools

Also create a WRNexusJS MCP server capable of exposing:

- Current routes
- Components
- Props and events
- Database schema
- Compiler diagnostics
- Runtime errors
- Dev server status
- Framework documentation
- Installed packages

Next.js and Nuxt documentation now explicitly includes AI-agent, MCP and `llms.txt` workflows, showing that AI-aware framework tooling is becoming part of the modern developer experience. ([Next.js][11])

**Status:** Delivered. `@wrnexus/ai` is provider-neutral and includes OpenAI, Anthropic, Google, OpenAI-compatible local/Ollama/llama.cpp/vLLM and deterministic adapters; structured output, validated tools, streaming, embeddings, an in-memory vector adapter contract, RAG with bounded context and citations, bounded conversation storage, strict prompt templates, guardrails, token/cost attempt events, retries, circuit breaking, model fallback, rate limiting and evaluation reports. Attempt events integrate with the framework's standard tracing without recording prompts or credentials. `@wrnexus/mcp` provides stdio JSON-RPC through `wrnexus mcp`/`wrnexus-mcp` and bounded tools for routes, components/props/events, DB schemas, compiler reports, redacted runtime errors, dev health, docs and installed packages.

# Keep the Framework Divided Into Three Levels

Do not place everything inside the core.

### Core

Only include:

- Compiler
- `.wrn` runtime
- Reactive system
- Router
- SSR/CSR
- Server
- Configuration
- Plugin lifecycle
- Type system
- CLI
- Development server

### Official Packages

Maintain these under WorkRoot:

- Auth and authorization
- Database
- Validation
- Security
- Cache
- Queue and workflows
- Realtime
- Storage and images
- Email and notifications
- Observability
- Testing
- UI
- PWA
- Content
- Deployment

### Ecosystem Packages

Allow the community to build:

- Payment gateways
- CMS integrations
- Analytics integrations
- Cloud-provider integrations
- Search engines
- CRM integrations
- Maps
- Social platforms
- Industry-specific modules

This prevents core bloat while still allowing developers to build almost anything.

# Recommended Release Order

## WRNexusJS 0.8 — Developer Foundation

Build these first:

1. Complete Language Server
2. Typed routes
3. Typed components, props, slots and events
4. Typed server actions
5. Error and async boundaries
6. Stable plugin lifecycle
7. Security defaults
8. Enhanced DevToolbar
9. Framework doctor command
10. API and compatibility documentation

## WRNexusJS 0.9 — Production Platform

Then implement:

1. Explicit rendering and hydration modes
2. Streaming SSR
3. Unified cache model
4. Deployment presets
5. Jobs and cron scheduler
6. Storage and media system
7. OpenTelemetry-compatible observability
8. Browser, component and visual testing
9. OpenAPI and SDK generation
10. Multi-tenancy

## WRNexusJS 1.0 — Stable Ecosystem

Before calling it stable:

1. Public API stability guarantees
2. RFC process
3. Deprecation policy
4. Automatic migrations
5. Long-term support policy
6. Plugin compatibility testing
7. Layers and presets
8. Plugin registry
9. Production benchmarks
10. Complete security review
11. Complete example applications
12. Upgrade testing from every supported version

# The Five Most Important Features

If we choose only five things now, I recommend:

1. **Typed server actions and forms**
2. **Complete `.wrn` Language Server**
3. **Explicit rendering, streaming and hydration modes**
4. **Stable plugin and layers architecture**
5. **Production security, testing and observability**

These five will make WRNexusJS feel like a complete professional framework. Adding more UI components or small utility packages before completing these foundations will increase maintenance without improving developer confidence.

[1]: https://nextjs.org/docs/app/getting-started/mutating-data?utm_source=chatgpt.com "Getting Started: Mutating Data | Next.js"
[2]: https://docs.astro.build/en/concepts/islands/?utm_source=chatgpt.com "Islands architecture - Docs"
[3]: https://nextjs.org/docs/app/getting-started/caching?utm_source=chatgpt.com "Getting Started: Caching | Next.js"
[4]: https://vite.dev/guide/api-plugin "Plugin API | Vite"
[5]: https://nuxt.com/docs/4.x/getting-started/layers?utm_source=chatgpt.com "Layers · Get Started with Nuxt v4"
[6]: https://owasp.org/www-project-application-security-verification-standard/?utm_source=chatgpt.com "OWASP Application Security Verification Standard (ASVS)"
[7]: https://docs.astro.build/en/guides/dev-toolbar/?utm_source=chatgpt.com "Dev toolbar - Docs"
[8]: https://playwright.dev/docs/test-components?utm_source=chatgpt.com "Component testing | Playwright"
[9]: https://docs.astro.build/en/guides/content-collections/?utm_source=chatgpt.com "Content collections - Docs"
[10]: https://opentelemetry.io/docs/languages/js/ "JavaScript | OpenTelemetry"
[11]: https://nextjs.org/docs/app/guides?utm_source=chatgpt.com "App Router: Guides | Next.js"
