Phase 7 is mostly authored assets. This commit is the asset half; the
template half is a Builder child issue because this phase must not write
application code.
DoD items satisfied or advanced:
- [x] Eight diagrams present, both themes, readable at 1x and on mobile
8 SVGs, one byte-identical <style> block across all 8 (one visual
language by construction). Light and dark resolve from a single file
via prefers-color-scheme, verified per file in Chrome: 8/8 return two
distinct palettes. Geometry verified with getBBox(), not estimated:
0 findings after fixing 74 (text overflow, partial overlap, empty
text, out-of-viewBox). Mobile type at the 900px minimum is 14.1/12.2px.
- [x] Six code exhibits with a two-sentence rationale each
212 verbatim lines across five eras, copied with cp/sed from the
read-only archive. Every rationale is exactly two sentences about why
the code is good; every exhibit also carries an honest_note, and where
the code is not good the note says so (the 3,400-line procedural PHP
script is presented for its operational judgement, not its structure).
- [~] Every image optimised; total page weight budgeted and recorded
BUDGET.md records measured raw and gzip weights for all 15 served
files: 63,802 B raw / 13,220 B gzipped. Zero rasters by design. Page
weight of a real page is not measurable until Phase 2 templates and
Phase 3 serving exist, and is recorded as open rather than asserted.
- [x] Archive never linked or exposed
No mount paths or volume names under content/. Provenance recorded as
"private archive, path withheld".
- [ ] Client wall reads as deliberate -> needs markup/CSS (Builder)
- [ ] Lighthouse held at >= 95/95 -> needs a served page (Phase 3)
Also: the client wall is authored as data (45 entries, 44 distinct names) with
the 45-vs-46 discrepancy and the Diajio -> Diageo correction recorded
rather than papered over. No commercial marks are enabled: that is a
permission decision for Sam, so availability is recorded and permission is not
implied.
Phase 7.2 — diagrams
Eight diagrams, one visual language, light and dark in one file each.
Authored 2026-10-26. Source of truth is the SVG files themselves: each one is self-contained, with no external font, image or script reference.
The language
| Part | Rule |
|---|---|
| Canvas | viewBox="0 0 960 540", width/height set so a bare file view is 1× |
| Type | 19 px section title · 15 px heading · 13 px label · 12 px caption, all ui-sans-serif system stack |
| Boxes | rx=7, 1.4 px stroke, four semantic tones: neutral, accent (the thing being described), teal (store / gateway), amber (guard, failure, limit) |
| Arrows | solid = data or control flow, dashed = trust boundary or approximate relationship |
| Colour | greys carry structure; one blue accent, one teal, one amber, nothing else |
| Text | every <text> is real text in the SVG, so it scales, selects and reads to a screen reader |
Every file carries a byte-identical <style> block. That is the whole of the
consistency guarantee: there is one palette, defined once, repeated verbatim.
A check that compares the eight style blocks and finds one distinct value is the
evidence that the eight diagrams share a language.
Both themes in one file
The <style> block defines the light palette, then repeats the same selectors
inside @media (prefers-color-scheme: dark). No duplicated files, no theme
toggle needed in the page, no chance of a light and a dark copy drifting apart.
If the site later grows a manual theme toggle, the SVG must be inlined into the
page (not <img>) so page CSS can override the custom properties. Until then
<img> is correct: the file follows the reader's operating system.
| Role | Light | Dark |
|---|---|---|
| ink (text) | #1b222b |
#e7edf4 |
| panel (box fill) | #f4f6f8 |
#182028 |
| muted (labels) | #5b6673 |
#98a4b3 |
| accent | #1a6bc4 |
#5aa2f0 |
| teal | #0f766e |
#38b3a6 |
| amber | #b45309 |
#d98b3f |
| box stroke | #c3ccd6 |
#35424f |
Mobile
A 960 px schematic cannot be read at 360 px. The presentation contract is:
- wrap the figure in a horizontally scrollable container
svg { display:block; width:100%; min-width:900px; height:auto }
At 1× (container ≥ 960 px) the type renders at 15 px / 13 px. At the 900 px minimum inside a 390 px container it renders at 14.1 px / 12.2 px — the same order as body text, and the figure scrolls rather than shrinking into illegibility. A figure that is scaled to 360 px instead reaches 5 px type and is not readable; that is why the contract is a requirement and not a suggestion.
Accessibility
Each file carries role="img" and both <title> and <desc>. The <desc> is
the alternative text — 190–285 characters, describing what the diagram asserts
rather than naming its parts. If a template sets alt="" on the <img>, the
<title>/<desc> are not read out; the template must supply alt from the
manifest's alt: field.
Files
| # | File | Area | Answers |
|---|---|---|---|
| 1 | 01-homelab-topology.svg |
platform | where it runs, and where the trust boundaries are |
| 2 | 02-agent-architecture.svg |
ai | how agents are organised and why one gateway |
| 3 | 03-rag-pipeline.svg |
ai | which side of the pipeline is AI and which side is not |
| 4 | 04-edge-architecture.svg |
edge | why devices never talk to each other |
| 5 | 05-distributed-audio.svg |
edge | how eight speakers stay in sync, and how voice gets in |
| 6 | 06-media-pipeline.svg |
products | where the human gate sits in a media pipeline |
| 7 | 07-cost-resource-engineering.svg |
platform | the memory ceiling, drawn to scale |
| 8 | 08-era-timeline.svg |
history | five platform shifts and what survived them |
Facts behind them come from reference/stack.md, reference/content-map.md and
docs/phase-3-deploy.md. Diagram 7 is numbers from a measurement, not an
illustration: if the caps change, the bars change.