Manager and settings

Manager and settings

Five studio pages share one full-viewport overlay. Runtime is the active calculation context; Workers and Plugins are catalogs, not tabs inside it.

Abstract

Active plugins live in store.activePlugins; per-plugin fields in store.pluginsConfig keyed by `${'{'}kind{'}'}:${'{'}id{'}'}`.

Conceptual model

Rendering…

Plugin Manager

Catalog

Lists sources, streams, engines, storages from the unified registry.

Status bar shows active engine id and storage backend after changes.

Install (URL)

Paste a module URL exporting a default plugin object (kind, id, name, contract methods). AXIS:

1. Fetches and validates export
2. Registers into the TypeScript registry
3. Persists install record so restoreInstalledPlugins() reloads next visit

Security notes (operator-level): only https/http schemes suitable for module load; treat third-party URLs as code execution in your browser origin. See security tests under tests/security/.

Supported URL kinds: source, stream, engine, dataset, component. Example plugins ship in public/plugins/:

• example-coingecko-source.js
• example-tiny-pyne-engine.js
• example-cf-do-stream.js

PYNE Agent (sister project — natural language → PYNE scripts) installs as a component from your deployed worker URL (or via Workers Manager → Install):

https://<pyne-agent-worker>/plugin/axis-pine-agent.js

See PYNE Agent and plugin reference. Works without the HOOX mesh.

Script Library tab

See Script library. The Plugins page hosts the panel so library and plugins share one studio surface.

Runtime vs Workers vs Plugins

One overlay (AppPage in src/ui/studio/) with a left rail. Switching rail pages does not close the overlay.

• Runtime — src/ui/runtime/RuntimePage.tsx — active engine, endpoint, exec mode.
• Workers — src/ui/workers/WorkersPage.tsx — backend inventory and probes.
• Plugins — src/ui/plugins/PluginsPage.tsx — catalog / install / library.

Workers

Opens from the studio rail, ⌘K Open Workers, or a Runtime related card.

Catalog items (usage)

Probes

• Run once when the modal opens; Refresh re-runs.
• Each worker has a hard wall-clock timeout (~5s) so a hung host cannot leave “Probing…” forever.
• Pyodide probe uses HEAD (not a full pyodide.js download).
• HTTP probes hit GET /health (JSON markers). Implementation: src/workers/*, src/ui/workers/WorkersPage.tsx. Operator CLI twin: AXIS CLI.

Hardened VPS note: production UFW typically allows only 22 + 443. Pro API binds 127.0.0.1:5002 — public :5002 probes correctly time out. On https://axis.hoox.sh, Workers Manager probes pyne Pro via same-origin https://axis.hoox.sh/health (nginx reverse-proxy), not loopback. See VPS demo.

Runtime (engine)

Engine, execution mode, Backend URL, Test, and Prefer WebSocket live on Runtime, not Settings. Storage is a Wire slot.

Settings

Product chrome only. Engine/endpoint/mode are on Runtime.

Deep multi-page history and gap repair live in the Data Source Manager, not Settings.

Execution mode maps to PYNE Runtime.run(..., mode=…):

The Connection HUD engine chip shows the selected mode. Save persists via Solid store persist() into pynescript.axis.v1. Escape closes; Ctrl/Cmd+Enter saves.

Pyodide engines hide endpoint—calculation is same-origin assets, not Flask.

Interface surface (UI map)

Internals

Invariants

1. Settings never write script bodies—only layout/config.
2. Catalog Use does not auto-Run; Load/Run remain explicit.
3. Source change may re-default stream (defaultStreamForSource).
4. API keys for cloud/git belong in pluginsConfig, not in git-committed defaults.

Worked examples

Point AXIS at local Worker

1. Settings → Engine Server-Side → Endpoint http://127.0.0.1:8787
2. Probe → OK
3. Save → Run

Install example source

1. Manager → Install → URL to .../plugins/example-coingecko-source.js (served origin)
2. Catalog → Source appears → Use → Load

Failure modes

See also

• Script library
• Compose recipes
• Plugins