Files
soleprint/docs/data/en/artery-plexuses.md
2026-09-24 00:43:18 -03:00

4.0 KiB

Plexuses

A plexus is a full app — the vocabulary has always said so ("full app with backend, frontend and DB"). What was missing is that a plexus is exported, not served. It is compiled to a distributable file the way vite builds for production, and that compile is the whole point of the format.

make dist                         # every plexus
make dist bundle                  # one, by name
make dist path/to/ui.toml         # the [[plexus]] tables of a run file

Output is one index.html per plexus under gen/plexuses/<name>/ (or --dest), carrying its theme, its data and its diagrams inline. No server, no node, no network. Zip it, mail it, double-click it.

A plexus is built on its own: nothing else has to be built first, and no other configuration has to name it.

The constraint that shapes it

It has to open from a double-clicked file on a machine with no egress. That is the state a regulated Windows box is usually in, and it rules out three things a normal web app does:

Ruled out Because
fetch("bundle.json") file:// treats every sibling file as cross-origin
<link href="/theme.css"> an absolute path assumes a server at the root
a webfont @import a blocked stylesheet is a stall, not a fallback

So the data is a JS object, the theme is inlined at compile time, and the fonts are stacks. The test that matters is opening the output with the network off and seeing zero failed requests — everything else is cosmetic.

Choosing what gets built

make dist builds every directory under soleprint/artery/plexuses/ that holds a plexus.json. To build with other settings — another theme, a plexus kept outside spr, a different destination — list it in a run file:

[[plexus]]
name     = "bundle"
theme    = "mcrn"
dest     = "out/bundle.html"

delivery = "vendored" renames the output through the mapping profile, refuses to write if any spr word survives, and needs a notice — the same rules as a vendored slice. See Export / Compile.

Writing one

soleprint/artery/plexuses/<name>/
  plexus.json      identity, theme, the data the page renders
  app/index.html   the template

make dist fills these placeholders and writes one file:

Placeholder Becomes
%%THEME_CSS%% only what the page can use: the custom properties it reads (and what they reach) per theme in inline_themes, and the rules that can match something on it
%%BUNDLE%% plexus.json as a JS object
%%GRAPH%% a rendered SVG from docs/graphs/, inlined
%%TITLE%% %%DESCRIPTION%% %%DEFAULT_THEME%% %%BUILT%% from the manifest

Anything else in app/ is copied alongside, for a plexus that outgrows one file.

A plexus whose app/ holds a package.json is built as a Vue app instead: its @ui imports are sliced from common/ui (the same closure a consumer would get), vite build runs in a temporary directory, and the emitted script and stylesheet are inlined into one file. live/ is the example.

The bundle plexus

The one that ships. It answers "what does a rig installation have at its disposal" — tools, cabinets, veins, themes — and embeds the system diagram.

Because the SVG is inlined rather than <img>-linked, the theme switch recolours the diagram too: graphviz writes class="node accent" into the SVG, and CSS outranks the presentation attributes it bakes in. Switching to lucid turns both the page and the diagram into something printable, which is the demonstration the format exists for.

Not the same as rig's bundle

Two artifacts, both called bundle, generated by different repos:

soleprint rig
Command make dist make manifest in sample-rig
Artifact plexuses/<name>/index.html generated/<slug>.yaml
Needs nothing kind + MetalLB
Answers what shipped, on any machine whether this cluster install is sound

Complementary. One proves the environment, the other travels.