[Architecture]
AXIS system architecture: AXIS vs engine, plugin registry, topologies, ADRs, and state namespaces.
Architecture
AXIS architecture is the discipline of separable axes—price history, live time, calculation, and library storage—coordinated by a Solid AXIS UI that never owns a closed interpreter.
Abstract
| Layer | Responsibility |
|---|---|
| AXIS | UI, store, plugin orchestration, chart apply |
| Plugin contracts | source | stream | engine | storage (+ reserved component) |
| Engines | PYNE evaluation (browser Pyodide or remote /run) |
| Optional edge | Cloudflare Pages + Worker + DO/KV/D1/R2 |
| Optional desk API | Flask Pro API |
Invariant: AXIS ≠ engine. Evaluation always crosses an engine plugin boundary.
Track map
| Page | Contents |
|---|---|
| Overview | End-to-end data/control flow |
| ADRs | ADR-001 … ADR-013 |
| Topologies | Dev, static, edge deploy shapes |
| State namespaces | Keys, migration, hash, IDB |
Conceptual model
Formal namespaces
Contract namespace: pynescript.axis.plugins.v1
App state key: pynescript.axis.v1
Legacy prefixes: pynescript.superchart.*
CF project id: pynescript-superchart (frozen)
Health service id: pynescript-axis-worker
Related tracks
- End User — operator workflows
- UI — UI subsystem design
- Plugins — contracts & catalogs
- Worker — edge data plane
- DevOps — build & CORS
- PYNE runtime — language evaluation
See also
frontend/README.md— package-level mapfrontend/LEGACY.md— pre-Solid shell boundary