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.
77 lines
4.8 KiB
YAML
77 lines
4.8 KiB
YAML
version: 1
|
|
authored: 2026-10-26
|
|
total_lines: 212
|
|
provenance: "private archive, copied 2026-10-26, path withheld"
|
|
exhibits:
|
|
- id: history-as3-class
|
|
order: 1
|
|
era: "Flash / ActionScript"
|
|
language: "ActionScript 3"
|
|
file: 01-actionscript-class.as
|
|
lines: 36
|
|
shows: "class, imports, encapsulation"
|
|
area: history
|
|
title: "A small class that hides its own state"
|
|
rationale: "Every field is private and explicitly typed, and the whole public surface is two methods, so a caller cannot push the object into a state it does not understand. The constructor takes what it needs as parameters instead of reaching for it, which is why the same class can drive every siren on the screen without knowing where any of them are."
|
|
honest_note: "Verbatim, including a latent typo on one private field (this.high rather than this.height). Left as found: the excerpt is evidence, not a portfolio piece."
|
|
|
|
- id: history-js-easing-engine
|
|
order: 2
|
|
era: "jQuery + PHP"
|
|
language: JavaScript
|
|
file: 02-js-easing-core.js
|
|
lines: 42
|
|
shows: "easing + timeline core"
|
|
area: history
|
|
title: "One curve, used twice"
|
|
rationale: "A named easing function is evaluated to give each letter its delay, so the spacing of an animation follows the same curve as its motion instead of a guessed linear stagger. Both directions build from one transform object, which is what stops the two halves of the same effect drifting apart over years of edits."
|
|
honest_note: "Excerpt from a 2,195-line file in which easing curves are used as a spacing distribution rather than only a timing function."
|
|
|
|
- id: history-php-media-pipeline
|
|
order: 3
|
|
era: "jQuery + PHP"
|
|
language: PHP
|
|
file: 03-php-encode-op.php
|
|
lines: 27
|
|
shows: "one encode op + the FFmpeg piping"
|
|
area: history
|
|
title: "Check the input, then encode in two passes"
|
|
rationale: "The real MIME type of the input is checked before any command is built, so a wrong file type returns a message instead of a half-written artefact. The encode takes two passes, generating a palette from the clip and then mapping frames onto it, which is the difference between a GIF that holds its colour and one that does not."
|
|
honest_note: "Row 20 is an elision marker: 34 lines of ImageMagick frame-optimisation options are omitted because they are disabled in the live code. This is 3,400 lines of procedural PHP with global state and interpolated shell commands; what is worth reading is the operational judgement, not the structure."
|
|
|
|
- id: history-typescript-service-layer
|
|
order: 4
|
|
era: "React + TypeScript"
|
|
language: TypeScript
|
|
file: 04-typescript-service-layer.ts
|
|
lines: 37
|
|
shows: "types, interfaces, service layer"
|
|
area: history
|
|
title: "Validate at the edge, then do one thing"
|
|
rationale: "Input is checked by a schema at the boundary of each procedure, so the data layer receives a shape it can trust rather than one it hopes for. Each procedure is a thin call on the database context, which keeps the router a description of the API rather than a second copy of the queries."
|
|
honest_note: "The types come from a Prisma schema in the same project (Device, Telemetry and Command models). The router is shown because it is where the two meet."
|
|
|
|
- id: edge-embedded-cpp-interface
|
|
order: 5
|
|
era: "Embedded C++"
|
|
language: C++
|
|
file: 05-embedded-cpp-interface.hpp
|
|
lines: 28
|
|
shows: "interface vs implementation"
|
|
area: edge
|
|
title: "The hardware stops at the header"
|
|
rationale: "The header declares one function and one constant and includes nothing but Arduino.h, so a caller compiles without pulling the ESP32 WiFi stack into its translation unit. Only the implementation file knows about station mode, polling and millisecond timeouts, and it returns a boolean so the caller decides what a failed join means."
|
|
honest_note: "Header and implementation are shown together, with a comment marking the boundary, because the point of the exhibit is the split rather than either file alone."
|
|
|
|
- id: platform-nix-derivation
|
|
order: 6
|
|
era: "Declarative infrastructure"
|
|
language: Nix
|
|
file: 06-nix-derivation.nix
|
|
lines: 33
|
|
shows: "fetchurl + hash, override rationale, removal condition"
|
|
area: platform
|
|
title: "A patch that says when to delete itself"
|
|
rationale: "The file records its own removal condition, delete it once nixpkgs ships 0.10, which is the part of an override that usually goes missing and leaves the next reader guessing. Pinning by fetchurl with a verified hash keeps the build reproducible while the reason for the pin lives in the file rather than in a commit message nobody will read."
|
|
honest_note: "The whole file, unedited. It is the newest exhibit and one of the shortest, and it is the one that best predicts how this engineer works now."
|