WRNexusJS/docs/ROADMAP.md

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:

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:

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)

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:

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:

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:

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)

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:

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:

<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:

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)

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:

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)

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:

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)

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:

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)

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)

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:

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)

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:

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:

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:

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:

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)

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:

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)

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)

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.