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.