Design-system amendments
Everything this work has accumulated that the design system does not yet carry. None applied — the doc comes first.
Twelve on the register — 9 to write, one declined, one deferred. Each is something the build settled and the design system does not say: a token that does not exist, a component with no entry, a rule that lives in the work and not in the document. A declined amendment stays here with its reason, because a register that records only what was accepted teaches nobody why the rest was not.
Every entry is checked against the shipped code before it goes near the design system — not against a comment, and not against this register. Three of the first four checked that way were recording a design that had been superseded on 2026-08-21 and never re-read. A comment is a claim.
Doc first, then regenerate boro-tokens.css, boro-typography.css and the Tailwind preset together. Never one alone. A serialization regenerated by itself is how a token file and a preset start disagreeing about the same value.
Check the DS changelog before proposing an amendment. --content-tertiary sat on this list until someone looked: the design system had already fixed it at v2.21 with the stone-550 half-step, and the list was simply a version behind. An amendment against a document you have not re-read is a guess.
Hairline on every chip and badge
Recorded as: §07 Badge Soft specifies a fill and a text colour and no border, and every chip and badge in this work carries a visible 1px hairline — status tones taking their own hue at 55%, neutral taking border-strong.
Wrong as recorded — checked against the shipped CSS on 2026-08-24. The artifact ships .chip { border: 1px solid transparent; } for every tone. There is no hue at 55% and no border-strong on neutral, and nothing in the harness asserts a hairline at all. The visible hairline was part of the solid-fill design that the 2026-08-21 tint replaced — the same supersession that took A-2 — and the comment describing it survived. What is true and small: the chip carries a 1px *transparent* border so its geometry matches bordered siblings, and the DS should say that rather than describe a border nobody can see. Recorded as A-13.
The chip's 1px transparent border holds geometry, nothing else
Every chip and badge ships border: 1px solid transparent. It is not decoration and it is not a hairline — it exists so a chip occupies the same box as a bordered sibling and does not shift by 2px when one is placed beside the other. §07 should say so, because the next person to read a transparent border will assume it is a leftover and delete it.
Checked against the shipped code Verified against the shipped CSS. .chip { border: 1px solid transparent; }, every tone, with no hue border and no border-strong anywhere in the family.
The solid / wash status tier
Recorded as reopening what §07 retired at v2.6 and re-affirmed at v2.10 — a solid status tier with a fixed ink label, theme-invariant, one value per tone.
Declined 2026-08-24 — the build had already declined it, and the register was reading a stale comment. The artifact carried a block headed *“solid fills with a fixed ink label, ratified 2026-08-21”* describing a theme-invariant design. The tokens directly beneath it said something else: *“Chip fills + labels — BOTH THEMES ARE NOW A TINT (Lab 14, ratified 2026-08-21). Solid on light is retired.”* The replacement landed the same day and the old comment survived above tokens that had stopped matching it. So the build converged on exactly what §07 specifies — a tint — independently, and §07 stands untouched. What was real in this entry was never the tier: it was the construction rule, which moves to A-3. *(The stale comment is gone from the artifact. It cost a session — this amendment was drafted from it, and recommended, before anyone read the values underneath.)*
--chip-*, --chip-*-ink, --hue-*, --warn-num
None of these exist in the token file. And the values alone are not the amendment — the construction rule is, because it is the part that cannot be re-derived: chips are the hue at 34% over the ground on both themes — except warning at 36% and neutral at 35% on dark, with the label pushed 55% toward black on light and lifted 35% toward white on dark. The two percentages differ because they must — luminance is not symmetric about the middle of the range, so the literal mirror of the dark construction measures 3.30–4.29:1 and fails AA on every tone; at 55% the identical wash clears everywhere, worst 5.65:1. The ratio is measured against the composite — fill over ground — never the fill alone. --chip-on survives only as the ink for the opaque hue fills, not as a chip label. Rails, discs and bars take the opaque --hue-* set rather than the chip fill, because a 3px rail in a 34% wash disappears on dark. --warn-num is light-only — #C2410C at 5.18:1, because --status-warning's brown reads muddy at display size and orange-700 as a single value fails dark at 3.38:1.
Checked against the shipped code Verified 2026-08-24, and it turned out to be one rule rather than ten values. tools/lifecycle/chip-construction.py proves every one of the ten inks reproduces from its hue: light is the hue × 0.45, dark is the hue lifted 35% toward white. Ten transcribed values drift one at a time and nothing notices; a rule with a check behind it fails the moment a value stops obeying it — so the DS should carry the rule and the five hues, not the ten inks. Exceptions confirmed and kept rather than smoothed: dark warning builds from #F0A93B at 36%, dark neutral at 35%.
StageChip tone bound to rental status, disputed → error
The tone should derive from the status rather than be set per usage. The live component is worse than undocumented: RentalStageChip.tsx fails WCAG AA on five of twelve states, worst 2.00:1 — which is app work, not simulator work.
Checked against the shipped code Verified against the shipped code. TONE_BY_STATUS maps all twelve statuses, and disputed: "error" is there. The amendment is real: the mapping exists in the artifact and nowhere in the DS.
Which pill geometry a card-header badge uses
Two pill geometries are in use and the DS does not say which belongs in a card header. Deciding it is the amendment.
Checked against the shipped code Verified against the shipped CSS. .badge ships height: 22px; padding: 3px 9px; font-size: 11px; font-weight: 600 — the chip family's geometry, not standalone Badge's 28.
Specs for ChatBubble, ThreadRow and MilestoneCard
All three are “pending spec” in the component register, and this work has effectively written them. The largest item on this list, and the one most likely to be skipped because it is not a single value.
Deferred to v2.23, and started the same day v2.22 lands. It blocks no token work, and it is the only entry on this register that gets authored rather than recorded — what the build settled is measured and transcribable, but interaction states, behaviour below the breakpoints and the token binding for each part were never things the simulator had to decide. A component spec written from a rendering is the trap this project has paid for twice, so it gets its own pass with CJ looking, rather than riding inside a token bump.
The timer pair, and the magnitude format rule
A display timer and a line timer, in two weights, plus the rule for how a magnitude is formatted. Nothing in §07 covers a countdown at all.
Checked against the shipped code Verified against the shipped code. The pair is a weight property with two values — 7 display, 5 line — and the magnitude rule is fmtRemaining(): expired below zero, the date beyond a week, whole days above a day, h mm above an hour, m:ss below one. The numeral is the same string with left removed.
The map plate
preserveAspectRatio="xMidYMid slice" so the geofence stays circular at any width, with the pin's bounding box — not its point — as the measured anchor.
Checked against the shipped code Verified against the shipped SVG. preserveAspectRatio="xMidYMid slice" is on the plate.
The date separator
Emitted only where the day changes. Never repeats, never leads the thread, never trails it, and never walks backwards in time.
Checked against the shipped code Verified, and asserted — the strongest of the thirteen. The harness enforces the label shape, that a separator is never first, never two in a row, never a repeat, and that time only moves forward. This one cannot rot.
The segment counter
Five pips with exactly one current, on the rental-active card. Never appears on Lane A, which has no segments to count.
Checked against the shipped code Verified against the shipped CSS. The pips take --hue-success and --hue-warning with --warn-edge on the current one — the opaque set, not the chip wash.
.badge.info — the missing fifth badge tone
Recorded as: the badge set carried four tones where the chip set carries five, so .badge.info did not exist at all. Found on 2026-08-22 when the sidebar filter needed it.
No DS change needed. This was an implementation defect that had already been closed, recorded on the amendment list as though the specification were missing something. It is the mirror image of --content-tertiary — that one was on the list because the doc had moved ahead of the register; this one because the build had. Both are the same lesson: read the document before proposing to change it. What the artifact's badges genuinely do differently is take the --chip-* construction rather than §07's Soft tint, and that is A-3.
Checked against the shipped code Checked against the design system, and the design system was already right. §07 Badge states the status set as success · warning · error · info · neutral — five, with info among them. The four-tone set was the artifact's CSS, not the DS's specification, and it was fixed on 2026-08-22.
bubble-own / bubble-own-on — the own-message bubble
bubble-own #2BA7FF, one value on both themes; bubble-own-on #1C1917, a fixed mark that does not flip — the arrangement danger/danger-on and brand-on already use, because a mark on a saturated fill must not flip when the surface beneath it does. Ink label 6.72:1, better than the white-on-red CTA at 6.15:1; a white label was tested and rejected at 2.60:1. The fill against a white card is 2.60:1, below the 3:1 non-text threshold, accepted and recorded on the reading that a bubble is neither a control nor information-bearing geometry.
Checked against the shipped code Verified by measurement rather than by shipping — the token does not exist yet. Ink label 6.72:1 on #2BA7FF; white label 2.60:1 and rejected; fill against a white card 2.60:1, below the 3:1 non-text threshold and accepted with the reason recorded.