The favicon and nav logo went from a two-mark system — one mark for the site, a second held in reserve for Knolling — to a single four-circle mark used everywhere, after a finished design showed up mid-session and made the distinction between the two look unnecessary. The old Knolling-only mark got deleted outright rather than left dormant in the repo, and the accent moved from workshop gold to the running pillar’s red, which wasn’t a rule change — just what the new design actually uses.
A second, unrelated handoff landed the same week: nine patterns promoted into real Astro components — buttons, chips, cards, section labels, pillar dots, a text input, stat boxes, a progress bar, list rows — meant to replace CSS duplicated across three or more files. They got migrated one page at a time, one commit per page, and only where the component reproduced the original value exactly. Call it two-thirds of the intended call sites actually fit; the rest needed a value — usually a gap, once a font size — that the component simply doesn’t expose.
Main takeaways
- A two-mark system built with real intent (docs/05-favicon-marks.md, two build-log entries) still got replaced within days, once someone looked at it with fresh eyes. Worth remembering before treating any spec doc as a permanent decision.
- A component handoff’s own migration spec is a hypothesis, not a fact — several of its documented prop mappings didn’t survive a check against the real CSS.
- Naming a page-level override the same as a component’s own inherent base class is a real, repeatable bug, not a one-off typo — it happened twice on two different pages this chapter.
What I got wrong
- Knolling’s Buttondown avatar and header image still show the retired mark — that only gets fixed by a manual re-upload outside this repo, still not done.
- Card and ListRow’s low fit rate reads like a component bug (a missing
gapprop) more than a per-page coincidence, but that’s a hypothesis for whoever owns the handoff, not something confirmed by editing the component myself.