Build notes: “The Terminal”

Why this build exists

It is not a portfolio piece. Under the parameterize-after-two rule, the shared journal layout may only be factored out once a second build exists, and only the things both builds agree on may be hard-coded. So build #2's job was to disagree with build #1 on all sixteen pre-declared axes on purpose — otherwise the eventual template would encode one page's taste and call it a family.

It is also the real future home of zero2webmaster.com/blog after WordPress. That is why the demo reproduces a live post verbatim rather than showing invented copy: anything this template cannot express is content that cannot migrate.

The 16 axes

Twelve inverted cleanly. Four could not invert at full strength, and in every one of those four cases the reason is the same rule: an axis may not be inverted by breaking a family invariant. Where that happened it is recorded here rather than quietly resolved one way or the other.

Axis 7 — heroMode: partial, because overlay is anti-pattern #1

The pre-declared table offered “overlay or split”. Overlay — a headline in white type over a busy full-bleed photo — is the family's first anti-pattern, so it was never available. Split is a genuine inversion of title-first and breaks nothing: the headline still never sits on the photograph, and the largest contentful paint is still text.

Axis 12 — motion: partial, because prose never animates

“Expressive” is bounded to the furniture: the hero entrance, the H2 accent blocks drawing down, the figures and code block rising once, the dividers, and the archive table's FLIP reorder on sort. A body paragraph still never animates, and that is not a convention — scripts/verify-journal.mjs fails the build if any CSS rule pairs an .abody paragraph selector with opacity or transform.

Axis 15 — toc: partial, because the criteria are an invariant

The gate itself could not change. What inverted is placement and default state: build #1 put a collapsed <details> in its left rail; build #2 has no rail, so the TOC is expanded and inline, directly after the deck. The gate still ran as a build-time decision and logged the numbers it used:

15 H2 plus 18 H3 is 33 candidate entries — a flat expanded list that long is a wall, not a table of contents. So this build ships the thing build #1 never needed: H2 entries only at rest, with the active section revealing its own sub-sections as the reader passes through it. Tracking is IntersectionObserver, never a scroll handler, and the active entry carries aria-current="location".

The negative case is asserted too. The archive is not a reading surface, so it ships zero TOC markup and zero TOC JavaScript, and the verifier fails if any leaks onto it — that is how “no TOC” stays distinguishable from “TOC broken”.

Axis 4 — measure: the axis reads backwards, because ch is the wrong unit

The pre-declared axis is 66ch → 72ch, which reads as “build #2 is wider”. Measured on the rendered pages, it is not:

Build #2's nominally wider measure is narrower in both pixels and characters, because ch is the width of the digit zero in that element's own font — and Nunito Sans, a UI sans with a large x-height, has a much wider zero than a text serif. So the axis compares two different rulers.

This also produced a real bug. A custom property holding ch resolves at its use site, so width: min(72ch, 100%) computed 800px on a 21px serif paragraph and about 1,642px — collapsing to 100% — on a 38px Space Grotesk H2. The prose sat in the measure while every heading ran full-bleed and the H2 accent block hung off a different left edge than the text it labels. The measure is now resolved once, to 50rem, so every block shares it.

Consequence for the parameterization: the measure axis must be an absolute length (or a target characters-per-line), never ch. Two builds expressed in ch cannot be compared, and the shared engine would inherit a knob whose numbers point the wrong way. The verifier now fails if --measure is declared in ch.

Axis 16 — defaultTheme: partial, and this one is a judgement call worth stating plainly

Kerry ruled on 2026-08-06 that both blogs ship light and dark, so what used to be a theme count axis became a default axis, and dual-theme-with-a-persisted-toggle became a hard-coded family invariant instead — which is the parameterize-after-two rule working exactly as designed: agreement collapses into the engine.

Where this build narrows its own brief. The brief said dark is “the one every first-time visitor lands in”. It also said prefers-color-scheme is honoured. Those two cannot both be absolutely true, and this build chose to honour the reader's operating-system preference: defaultTheme governs the case where the reader has expressed no preference at all, and a light-OS visitor lands in light. Two reasons. Overriding a declared accessibility-adjacent preference on a 11-minute reading surface is a worse outcome than losing a brand impression; and this is the definition that stays parameterizable, which is the whole point of build #2. The dark identity is still what the page is designed on and still what most visitors and every no-preference visitor see.

Type

Three faces, all free, all self-hosted as latin-subset variable WOFF2 in /z2w-blog/fonts/. Zero font-CDN requests — same hard rule as build #1, asserted by the verifier.

Body sets at 21px / 1.72 over a 72ch measure — wider than build #1's 66ch because a serif sets narrower per character and the code block wants the room. Nothing on any of these pages renders below 16px, captions and UI included; the verifier judges a clamp() by its minimum and rejects any em-based size below 1em, with no allowlist.

Licence. All three faces are licensed under the SIL Open Font License 1.1, and serving a .woff2 from a public page is redistribution — so the licence and the copyright notices ship alongside the fonts, at /z2w-blog/fonts/OFL.txt. The notices there were read out of the name table of the exact files this page loads, not from an upstream README.

Colour — two hand-built themes, and the trap this build was warned about

Neither theme is an inversion of the other; the light palette has its own ink values. Every ratio below is recomputed at build time from the shipped tokens, so this table cannot drift from the pages.

The per-surface trap caught a third victim. Zero2Webmaster's existing green text tier #4a7a10 — the value /portfolio/ and /web-craft/ use — measures 4.82:1 on this light paper but only 4.37:1 on the light panel. It passes a palette audit and fails a surface audit. The light theme therefore ships #436E0E, which clears AA on both. This is the same failure as the broadsheet's #ab5200 and build #1's #964800: contrast is a property of a pairing, not of a palette.

And the trap axis 10 creates. Making the accent role fill + block puts far more text on filled surfaces than build #1 had, and a fill is a ground the token audit does not automatically cover:

Every accent or gold fill on both themes takes near-black ink. White on #82C92B measures 2.03:1 and is now a permanent regression pin: the verifier feeds that exact pair through the gate on every build and fails if it is ever accepted. Gold #FFD700 is rationed to a single role and appears nowhere as text.

No rail — where the nine relocated things went

Removing the rail (axis 5) was the most consequential inversion in the set, because build #1 put nine things in it and “delete it” is not an answer for any of them.

The demo post, and what the harvest got wrong

The post is a verbatim reproduction of https://zero2webmaster.com/cursor/ — “Gain Coding Superpowers: How Non-Coders Build Real Software”, published 2025-12-15, by Dr. Kerry Kriger. Its canonical points at the original, because a reproduction must not compete with the real post in search. It was chosen on evidence: of the twelve longest posts on the blog it is the only one with a real code block, and it has by far the deepest heading nesting.

The harvest is committed and re-runnable (node scripts/harvest-z2w-blog.mjs --images), deliberately fixing a build-#1 limitation — build #1's harvest tooling lived in a session scratchpad and was thrown away, so nobody could re-check what the source said.

A fourth harvest finding, found during this build

The brief carried three findings to handle. A fourth turned up while converting: WordPress's content.rendered ends with a Kadence Post Grid — a “More Articles You May Enjoy” related-posts widget — inside the content field. It contributes six <h2> and six <img> that belong to other posts, and its titles land in the word count.

This is build #1's word-count lesson in a second costume — there, Kadence inline CSS text was being counted and the first measure read 3,098 words instead of 2,030. The harvest now reports both numbers on every run and names the difference, and the guide publishes both, because a single number is exactly how a related-posts widget gets mistaken for six extra sections of an article. Log the numbers the gate actually used, always.

The three findings the brief carried

• Two images had no alt. One of them is the YouTube poster and is resolved by the facade decision below (an empty alt inside a facade button is correct — the button's aria-label carries the accessible name). The other needed real alt text written, and it is DRAFT-flagged below.
• One image had no intrinsic width/height. The YouTube poster. Measured from the downloaded file: 1280×720. Missing dimensions are invisible on a fast local machine and cause reflow everywhere else, which is why they fail the build.
• maxresdefault.jpg — figure or facade? Facade. Reading the source markup settled it: the element is a real wp-block-embed is-provider-youtube block, and zero2webmaster.com merely renders it through its own poster facade — which is precisely why the harvest counted zero <iframe>. Reproducing it as a plain figure would have turned a video into a picture. It ships as the family's facade block: no iframe until click, the real video title on the button, and a <noscript> link out.

Block coverage, corrected

The brief predicted this post would rehearse code and deep nesting but no quotes. It has two real quotations — one from Chris Davis of Automation Bridge, one from Claude — marked up in WordPress as Kadence “advanced heading” paragraphs rather than <blockquote>. The inventory counted tags; the content has quotes. So the union of the family's two demo posts covers the whole 16-block library on real content except table and footnote, and the table specimen comes from the real one on zero2webmaster.com/self-hosting/ rather than being invented.

Every per-element conversion decision

The body is verbatim, but “verbatim” still requires decisions about markup that has no equivalent in this template. Each one is listed so it can be argued with.

Two things this converter deliberately does not do. It does not turn the manually numbered roadmap paragraphs (“1. … 2. … 3. … 5.”) into an <ol>, because that would renumber them and quietly hide that 4 is missing in the source. And it does not strip the source's <strong> runs: “no bold scattered through body paragraphs” is a rule about copy we write, and this copy is the author's.

One honest note on imagery: the post's own art was created in Midjourney by Dr. Kerry Kriger and is credited as such in the source caption, which is reproduced. The family's no-AI-imagery rule is a SAVE THE FROGS! standing rule about images we generate for a page; it does not license us to alter an author's credited illustrations.

The archive — why a table

Axis 13 inverted to a dense sortable table, and the content argued for it rather than the axis dictating it. Of 22 posts, 20 are in Learn. Build #1's archive leaned on a six-category filter row; build #2 has no real taxonomy to filter on and must not fabricate one. 22 posts also fit on one page, so there is no paging.

• A real semantic <table> with <caption>, <thead> and <th scope="col">. Hairline row rules only — no zebra, no vertical rules, tabular numerals.
• Sortable by date and by reading time with real <button>s in the header cells and aria-sort maintained. Progressive enhancement over a server-order default: with JavaScript off it is still a complete, ordered index.
• Year bands only exist while the table is sorted by date. Leaving “2026” sitting above a row from 2023 because the reader sorted by reading time would be a lie, so the bands are rebuilt with the order.
• Sorting animates the reorder with a FLIP transition, and that is skipped entirely under prefers-reduced-motion.
• No cursor-following image. That was build #1's signature and axis 13 gives it up: build #2's archive is scannable where build #1's was memorable. That is the trade, stated rather than hidden.

Reading times are measured, not estimated. The harvest fetches every post's full content and counts real prose words; the table divides by 230 words per minute. An invented minute-count on a page reproducing someone's real work would be an invented statistic.

⚑ Awaiting Kerry's review

Verification

The verifier was extended, not forked. scripts/verify-journal.mjs now covers public/journal/ and public/z2w-blog/ from one definition of the family — a family with two verifiers has two definitions of itself. All existing groups apply unchanged: imagery (alt + explicit dimensions + the local file exists), the 16px floor, per-surface contrast in every theme, the TOC gate in both directions, prose-never-animates, facade-only embeds, self-hosted fonts, and the SEO shell on every page.

Three assertions are new for build #2, and each was canary-tested — broken on purpose, the build confirmed failing, then restored. An un-canaried assertion is an assertion nobody has shown to work.

1. Fill contrast, in both themes, with white-on-#82C92B (2.03:1) fed through the gate on every run as the regression pin.
2. The default theme — build #2's :root must carry the dark ground and build #1's the light one. The default is now the axis, and it is the part a later edit can silently flip.
3. No client-side syntax highlighter — highlighting is done at build time; the pages must load zero highlighting JavaScript.

Four more were added on Kerry's first review (group 1c), all canary-tested the same way: every --nat must equal the width attribute of the image it governs; no CSS rule may leave an image unbounded; each page must declare the number of caps it is known to need — without which the group would pass on a page carrying no caps at all; and the page that declares --nat must also ship the rule that consumes it, which is the one that caught a bug introduced by this very fix. The verifier now stands at 542 assertions over both builds.

What the harness found — thirteen bugs that existed only in rendered pixels

Three Chrome DevTools passes over two themes and four breakpoints, screenshotting rather than reading code. Every item below passed code review, passed the verifier, and was wrong on screen. They are listed because the pattern matters more than the individual fixes: five of the thirteen are one CSS declaration silently cancelling another, and no amount of reading either declaration in isolation reveals it.

And two that were measured rather than seen. The largest contentful paint was 1,201ms, and the cause was the page's own choreography: the H1 is the LCP element and the hero entrance faded it in, so first contentful paint landed at 588ms and the headline was not fully visible until 1,204ms. A split hero exists partly to keep LCP as text; fading the headline gives that away. Second, the hero image was the 1,232px original rendering into a ~500px box — 256KB for nothing. With the headline no longer withheld and the hero served at 768px, LCP is 386ms and CLS is 0.00. Lighthouse: 100 / 100 / 100 (accessibility, best practices, SEO) on all three pages, desktop and mobile, zero failed audits.

The verifier grew four guards out of this pass, each canary-tested: a page may not use ch for a length; every class in a page's markup must have a rule on that page; the H1 must be typed on every page that has one; and — after a generator crash let the verifier report "all assertions passed" against the previous build's HTML — every generated page must be newer than its generator and its input data. That last one is the most important thing in this file: a green check that cannot tell you whether it examined current output is not a green check.

What Kerry's review changed — four fixes, and why three of them are the same mistake

Kerry read the shipped pages on 2026-08-07 and sent four notes. They are worth recording together because three of the four are one failure repeated: a value that satisfied its rule while failing its job. Each is now a build assertion, so the rule and the job cannot drift apart again.

The image work found its own bug, in the fix. The cap is a two-part mechanism — a --nat declaration in the markup and a rule that consumes it — and this family splits its stylesheet per page. The consuming rule was first written next to .fig, which is post-only, so the archive shipped --nat in its markup with nothing on that page to honour it: max-width computed to none and the lead image went on upscaling, while the new assertion passed because it was reading the markup half of a two-part mechanism. It is the same shape as the stylesheet-split bug in the table above, and the same shape as the Rank Math retitle that preceded this build — one true surface taken as proof of all surfaces. The verifier now asserts that the page declaring --nat also ships the rule consuming it.

Also this pass: a build was failing while its output was being read as current. A stray backtick in a CSS comment broke the stylesheet (the trap this file's own header warns about), the generator exited non-zero, and the previously-emitted HTML was still sitting on disk looking perfectly plausible. The freshness gate added in v1.16.0 is what makes that recoverable — and it is the reason it exists.

Round two of Kerry's review — and the axis that was wrong about its own content

A second pass on 2026-08-11. The headline item is not a bug at all: axis 9 gave this build a duotone, and it was working exactly as specified. The problem is that the axis was assigned to the FAMILY before anyone looked at what this build's images actually are.

Twenty-one of this post's twenty-three images are screenshots — a chat window, an Airtable grid, a terminal, a file tree. A duotone is an editorial treatment for photography, which is why build #1 (frog and event photography) wears it happily. Applied to a screenshot it paints every white UI panel a slab of #82C92B, which destroys the one thing a screenshot exists to convey. Kerry: “why does it have a green background? I think all the images got green backgrounds.” He was right, and no contrast gate or alt-text check could ever have caught it, because nothing was broken — the treatment was simply wrong about its subject. Same failure as the brief predicting a “code-heavy” blog that turned out to be prose: an axis value is a claim about the content, and it has to be measured against the content.

So the rule is now a tonal treatment may be applied to photography and must never be applied to a screenshot, and since a generator cannot reliably tell the two apart, the default is off. The treatment is kept as an opt-in for art, and the verifier asserts both halves: that nothing is toned by default, and that the opt-in still blends on the wrapper — because deleting the feature would have deleted the v1.14.0 lesson with it (an element blends against its backdrop, not its own background).

And one assertion that could not fail. The YouTube parity checks were first written as page.includes('playsinline=1'). The canary that deleted playsinline from the parameter string still passed — because the long comment above the facade explains the parity list and ships inline in the page, so the check was matching its own documentation. It now parses the parameter string out of the page and tests that. An assertion that cannot distinguish its two outcomes is decoration, and the only way to find out is to break the thing on purpose.

Verifier: 542 → 585 assertions. Six of the new ones were canary-tested; the seventh is the one described above, which was canary-tested, failed to fail, and was rewritten.

What this unblocks

With two builds shipped, the journal family passes the parameterize-after-two gate. Everything the two builds agree on gets hard-coded into the shared layout — the 16-block library, the vertical-rhythm system, the contrast gate (now including fills, over both themes), the alt/dimension gate, the SEO shape, the TOC criteria, the 16px floor, prose-never-animates, facade-only embeds, self-hosted-fonts-only, and dual light/dark with a persisted toggle, which stopped being an axis the moment both builds needed it. The sixteen axes become the config surface, with these two builds' values as the proven extremes.

That work is deliberately not started here. A build already thinking about the shared abstraction converges toward it, and then the parameterization is derived from one taste after all.

Built 2026 · the archive · the demonstration post · build #1's notes ↑ Back to top