This page is the public compass for Axonyx: what already works, what is being sharpened now, what is next, and what belongs to later framework layers such as Blockbit CMS and deeper standard library modules.
The first public loop is now real enough to publish and deploy. The next priority is making that loop dependable under real state, actions, production transport, and security pressure.
Core authoring, build, deploy, data contracts, action metadata, and package publishing exist; state, server hardening, auth, and storage still need deeper passes.
Function-shaped pages, `return ASX`, local components, props, state, render blocks, and route-scoped component JS are now a complete V1 slice.
Foundry now has a broad native component catalog, but each page still needs richer previews and API detail.
Aegis is usable today through `cargo ax test` for Cargo-first fast checks, status/text assertions, link assertions, and same-origin broken-link detection.
State manifests, action patches, invalidation events, typed local bindings, component-local signal IDs, compiler-owned local events, and reactive If boundaries exist; cross-file state graph work remains the next deeper state milestone.
WASM State V1 executes typed String, Number, and Bool local operations in Rust. The narrow browser host still owns events, UTF-8 transfer, and targeted DOM writes, with the existing JS executor retained as a fallback.
The next milestone is the first complete public loop: a developer can create an Axonyx app, write pages in .asx, use Foundry components, inspect routes/API/actions/schema contracts, build, deploy, and understand errors without dropping into framework internals.
Clear .asx pages, layouts, components, params, optional values, and friendly parser errors.
Reliable `cargo ax run dev`, route inspection, generated backend, static output, and deploy defaults.
Docs, UI previews, package versions, Render flow, and clear upgrade notes for beta users.
Now
The first complete authoring slice is stable enough for real pages and reusable components.
Interactive State V1 now supports real local interactions without inline JavaScript or a virtual DOM.
Harden the Tokio/Axum-backed path that powers `cargo ax run start` and hosted deploys.
0.2.2 adds compiler-owned local events and reactive If boundaries to the Contract V1 and Pages/ASX foundation, while preserving typed server actions for trusted mutations.
0.2.16 keeps create-axonyx and cargo-axonyx aligned with the published 0.2.1 runtime contract.
A 1,592-byte Rust/WASM executor now sits behind `ax-state/1` for typed local operations without becoming a dependency for static pages.
Grow `axonyx-ui` into a practical MUI-like foundation for Axonyx-native apps.
Bring `axonyx.dev` pages to the same confidence level as the React adapter site.
Make failed builds explain the fix instead of only exposing parser/runtime internals.
Build the Rust-first QA layer behind `cargo ax test`, while keeping it useful for React/Next sites today.
Next
Deepen action invalidations and typed query function calls so mutation flows keep page data fresh without hand-wired client state.
Let The Melt own a cross-file state graph, initial snapshots, and safe patch targets for actions and UI bindings.
Move from local SQLite proof toward Postgres, schema pull/check, migrations, typed table resources, and clearer query diagnostics.
Extend the shipped WASM executor with validated event payloads and a narrower browser host API while keeping the compatibility fallback.
Move more deploy/runtime settings into `Axonyx.toml` so hosted, Docker, and local production starts share one model.
Define secure-by-default rules for escaping, guarded routes, signed sessions, CSRF, capability-based file APIs, and `cargo ax doctor security`.
Add focused guides for state, actions, query invalidation, API routes, deploy, and package updates.
Keep improving `cargo ax doctor`, `routes`, `api`, `actions`, `schema`, and deploy-friendly build behavior.
Document and harden form lifecycle, validation errors, redirects, and server-side mutation flow.
Every component page should have the same structure: intro, live preview, usage example, API reference link.
Later
Move deeper into Tokio/Hyper-style production transport, streaming, static assets, request limits, and deploy adapters.
Harden signed sessions, auth guards, crypto helpers, route protection, and error handling.
Design database adapters, file uploads, content collections, stream APIs, and schema/DTO discovery commands.
Build the CMS as a higher layer on top of Axonyx primitives, not inside the core framework too early.
Grow the shipped local executor into the broader optional client runtime for typed patches and component behavior where WASM is worth loading.
Allow external design systems to ship as packages while the app keeps the same route/data/component structure.
Add background jobs and child process orchestration for image processing, content indexing, and heavier CMS tasks.
Done
Function-shaped pages, `return ASX`, local components, typed params, component-local state, render blocks, and route-scoped inline client JS.
Imports, fragments, paired tags, slots, page params/defaults, Head, If, Each, and native component packages.
`create-axonyx`, `cargo ax check`, `doctor`, `build`, `run dev`, `test`, `routes`, `api`, `actions`, and `schema pull`.
Static route rendering, nested layouts, loaders, content collections, action forms, and local state binding metadata.
`invalidate` literal keys, `revalidate` expression targets, automatic mutation invalidation, patch response invalidations, refresh metadata, page fragment refreshes, redirect fallback safety, and integration guard tests shipped through the current 0.1.x line.
`query loadPosts(status: String)` can now bind page data calls such as `loadPosts(status)`, and `cargo ax check` reports missing or extra query arguments before runtime.
`create-axonyx 0.2.16`, `cargo-axonyx 0.2.16`, `axonyx-runtime 0.2.1`, and `axonyx-core 0.2.1` are published.
`axonyx-ui` ships as Cargo and npm package with CSS, JS helpers, and native `.asx` Foundry components.
The public site is authored in Axonyx and deployed from the native framework loop.
Axonyx is still beta. Items may move as the framework gets tested on real pages, real deploys, and future CMS flows. The rule is simple: stabilize the smallest useful full-stack loop first, then widen the standard library and CMS story without breaking the core authoring model.
