Context
Every project on the site needs a demonstration a reviewer can use, not just a description. The projects range from a live trading platform whose code is the company's, through private products and prototypes, to design documents. Running their backends here would mean hosting trading engines, Kafka, Temporal or GPU inference on a 4-CPU, 8 GB host that also serves this site, plus their credentials and data. A demonstration that looks live but is not would also undermine the rest of the site.
Options
- Host sandboxed copies of each project's backend. Real interactivity, but heavy, costly, a large attack surface, and impossible for the private and employment code without publishing it.
- Embed the products in iframes. Breaks
frame-ancestors/CSP assumptions and depends on third-party uptime; employment systems cannot be embedded anyway. - Ship demonstrations as static data plus small client components, generated from the real code or records, with the one live demo limited to this site's own read-only API.
Decision
The third option. Each case study embeds a ::demo{name} directive; the audit rejects unknown names, and
a unit test keeps the registry and the audit list identical. Every demo renders inside a frame that
states its kind (live, playable preview, recorded results, visualization from source, screenshots,
design only) and its provenance: which code, commit and data produced it.
- The ChartX preview replays output of the real generator, run offline once; nothing calls ChartX.
- The API console is the only live demo. It calls
/api/v1on this origin (connect-src 'self'), only with a fixed list of GET requests, behind the existing proxy rate limit. Pages still never depend on the API (ADR-0003): the console says so and degrades to a message if the API is down. - Demo components use SVG attributes and classes only, never inline styles, so the strict CSP holds.
- Screenshots of private software are taken from local runs against mock data, never from production.
Consequences
- No new services, credentials or infrastructure; demos cost nothing to run and cannot affect uptime.
- "Playable" means replayed, not live, and the page says so. A reviewer who wants the real thing is pointed to the live product (Fluxa) or the public repository (BoundedCode).
- Demo data is checked by unit tests for internal consistency (for example, each ChartX answer is the limit the hidden candles actually touch first).