61 ready now6 blocked2 superseded89 done2 with no row

1. 159CCno row

   logo-minimum fails intermittently, and one of those failures refused a push

   Done when a failing run's output is captured and says which of the two it is; the fix matches; and the check is run enough times under load to show the fix took — an intermittent failure cannot be closed by one green run, which is the trap this card exists to avoid falling into.

   Detail

   Files: lib/logo-minimum.test.ts § "is very nearly square, which is what a favicon slot needs" · bin/hooks/pre-push · data-products/tokens/constants.json § geometry.symbol_aspect

   New 2026-09-20. Three failures observed in one day's work on this repo, none reproducible on demand.

   What was seen.

   When	What happened	What it cost
   Session open	A full run reported 5 files and 8 tests failing; an immediate re-run reported 1, which was a real failure in token-values-are-canonical	Four minutes deciding which failures were real
   Mid-session	The pre-push gate refused a push — "the gate failed at: npm test" — and npm test run by hand seconds later passed 492/492	A false refusal. The push went through unchanged on a retry
   After the change-note sweep	logo-minimum § "is very nearly square" failed in a full run and passed in isolation, with no logo file modified	Five minutes ruling out a real cause
   Committing this card	The gate refused the push seconds after a green 495/495 by hand; the retry passed 495/495 and pushed	A second false refusal

   It does not reproduce on demand, and it keeps happening anyway. Eight deliberate attempts after the third instance — five isolated runs of the file, three full-suite runs — all green. Then the fourth instance arrived unprompted, while committing this card. Four in one day, two of them false push refusals. That rules out a stale working copy and points at contention: the gate runs the suite in a hook, and this repo is known to have more than one session open at a time.

   The fourth instance was not captured either, and that is now a process problem rather than bad luck. The push output was piped to tail -2, so the failure detail scrolled past before anyone could read it. When the gate next refuses, run npm test 2>&1 | tee /tmp/gate.log before retrying — the retry destroys the only evidence, and two chances have now been lost that way.

   What the assertion does, and why it is a plausible place for this to land. The test rasterises aleris-logo.svg with @resvg/resvg-js — native code — measures the symbol's bounding box, and asserts the aspect with toBeCloseTo(symbol_aspect, 2). Two decimal places is ±0.005 on a measured value of 0.966, so a single pixel of difference at the render size is enough to break it. A measurement asserted that tightly against a rasteriser is the shape of thing that wobbles under contention, and this repo is known to run more than one session at a time.

   What is not known, and it is the thing that would settle it. Nobody captured whether the failure was a wrong number or a timeout. Those have opposite fixes — a wrong number means the tolerance is too tight for the renderer, a timeout means the test needs longer under load — and the failure output was not kept. Until one is captured, any fix is a guess.

   Why this is worth a card rather than a shrug. An intermittent check is a check that can go dark: the next person to see it red has been taught by this history to re-run rather than investigate. Worse, one of the three instances was a false refusal by the pre-push gate, and a gate that refuses for no reason is how --no-verify becomes a habit. That is the cost, and it is not paid by whoever sees the failure.

   Done when: a failing run's output is captured and says which of the two it is; the fix matches; and the check is run enough times under load to show the fix took — an intermittent failure cannot be closed by one green run, which is the trap this card exists to avoid falling into.

2. 117CCno row

   The session-end backup hook snapshotted the main checkout, not the worktree the session was in — DONE 2026-09-02

   Detail

   This answers half of card 116's closing question. That card measured five snapshots in a row holding nothing that was not already landed, and put the hook's value to Torfinn as an open question. One reason is now known rather than guessed: .claude/hooks/backup-push.sh hard-coded REPO="/Users/torfinn/Dev/aleris-brand-os" and changed directory to it before doing anything, so a session running in .claude/worktrees/<id>/ had the main checkout captured and its own work captured not at all. Sessions in worktrees are the normal case here, so a large share of those five snapshots were backups of a tree that was never at risk.

   Reproduced before it was fixed. Driving the original script from a linked worktree in a throwaway repo produced a snapshot containing the main checkout's uncommitted file and not the worktree's. It recorded .claude/worktrees/<id> as a gitlink and none of the contents beneath it. The whole of the 2026-09-02 site session — the Astro build, the token-bridge fix, the v0.11 package cut — had never been inside a single snapshot.

   Two defects older than this one, found while writing the test. Retention took the date as everything after auto-, so any suffixed branch failed the eight-digit test and would never have been pruned once per-worktree names existed. And the "tree unchanged today" check did exit 0 above the retention block, so pruning was skipped on precisely the ordinary days.

   What it does now. Reads cwd from the JSON the hook is handed on stdin, snapshots that working tree, and writes to backup/auto-YYYYMMDD-<slug> per worktree so two sessions ending the same day cannot overwrite each other. A scope guard built on --git-common-dir keeps it acting only on this repo and its worktrees, and is asserted.

   Asserted, and the assertion is itself checked. .claude/hooks/backup-push.test.sh — four behaviours, a throwaway repo and worktree under $TMPDIR, nothing touched outside it. Each of the three defects was reintroduced by mutation and the test confirmed to fail on all three, because a test that passes on the broken version proves nothing. The pre-fix script is kept beside it as a .bak.

   The hook and its test were untracked until the same day. .gitignore excluded .claude/ wholesale, so the one piece of machinery whose purpose is preventing lost work lived in no repository and no backup. Narrowed to .claude/* plus !.claude/hooks/, which keeps settings.local.json and worktrees/ out.

   Still Torfinn's, and unchanged by this card: whether the hook earns its cost at all. What has changed is that the question can now be asked of a hook that backs up the right directory — the five-for-five measurement was taken against a broken one and should not be read as evidence either way.

   ---

3. 169CCReady now

   Get the icon picker serving

   Done when ikon serves on Forge with assignments visible to a signed-in user, the tokens match the current package, and it is on main.

   Waits on Torfinn: pull FORGE.md again in the console for ikon and brand, then Deploy

   Detail

   Files: the ikon repo — app/qlik/page.tsx, brand-provenance.json, FORGE.md, branch extract-icon-picker · Brand OS _state.md (the milestone)

   New 2026-09-28. ikon has been dark since the extraction on 2026-09-10, blocked on ASK-IKON-001. Forge answered it on 2026-09-28 (ikon/forge/ANSWER-IKON-001.md, and ANSWER-BRAND-001 here, which closes both): schema apply runs at every deploy since 2026-09-11, so db/001_icon_assignments.sql is applied by pressing Deploy. Both repos' FORGE.md copies predate that and still say "at onboarding".

   Found while landing card 167's picker half, and in front of a deploy:

   • /qlik is prerendered at build, and getSession returns null when SESSION_SECRET is absent at build time, so the deployed page would never show assignments. It needs to render per request. This was true on main before card 167 touched it.
   • The tokens are pinned at agent-baseline v0.12 while the package is at v0.22; the fix is a re-vendor that sits unmerged on extract-icon-picker (three commits, eleven days). The provenance check carries an acknowledged_behind entry, review date 2026-10-10, so it is not red meanwhile.
   • Fixed on the way: three paths still pointed at /tools/icon-picker/… from before the extraction, so / redirected to a 404 and saving and both downloads returned 404.

   Torfinn's: pull FORGE.md again from the console for ikon and brand (Forge's own recommendation), and press Deploy on ikon once the two code items are on its main. Claude Code's: the per-request render, the re-vendor, and removing the acknowledged_behind entry.

   Done when: ikon serves on Forge with assignments visible to a signed-in user, the tokens match the current package, and it is on main.

4. 168TReady now

   An expressive typeface for internal material

   Done when Torfinn has decided whether an expressive face is wanted; if it is, it is chosen and written into constitutional/typography-is-museo-sans.md with its scope; if it is not, the floor decision says so; and it is on main.

   Detail

   Files: constitutional/typography-is-museo-sans.md § 2 · workspace/plans/internal-ai-material-discovery-2026-09-18.md · workspace/decisions/internal-material-floor-2026-09-18.md

   New 2026-09-26, from ruling 2 of sitting 2. The discovery found that five of five colleagues making internal material with AI bought a typeface, because Museo Sans at 500 and 700 cannot carry a celebration ("thank you for a wonderful year"). The floor decision of 2026-09-18 left script faces free internally; the binding rule allows only Museo Sans or Arial. Torfinn ruled that the binding rule stands: the passed answer says Museo Sans at a large size, bold 700, or light 300 from 40px. Whether Aleris wants an expressive face at all, and for what, is a design question in its own right, and the floor decision's wording now disagrees with the binding rule until it is answered.

   Done when: Torfinn has decided whether an expressive face is wanted; if it is, it is chosen and written into constitutional/typography-is-museo-sans.md with its scope; if it is not, the floor decision says so; and it is on main.

5. 166TReady now

   The website switch-over, and what stands between the build and it

   Done when Torfinn has flipped NEW_SITE, the route-manifest diff is accepted, the link audit and review checks pass on the switched site, and the old pages are gone.

   Waits on Torfinn: Deploy on the brand Forge app

   Detail

   Files: workspace/plans/website-content-and-switch-over-2026-09-25.md (the plan: sitting 0's eight rulings, eight sittings, the build items) · site/release-state.mjs (NEW_SITE) · workspace/briefs/prd-brand-os-website-2026-09-24.md · lib/route-manifest.json

   New 2026-09-25. Phases 1–4 of the iteration-1 build are on main behind NEW_SITE: the layout and components, the content checks, the nine concept pages, the photo hero, the Create routes, answers, Export and the machine index (changelog, twenty-eighth entry). Phase 5, feedback, is card 165. The switch-over — / becomes the new front page, the old rendered pages retire, the route manifest changes as a reviewed diff — is Torfinn's call, and these stand in front of it:

   Sittings 0 and 1 held 2026-09-25. The plan's rulings are in the PRD as § 10: the switch happens at a threshold (Story, Colour, Typography, Voice, Imagery, Digital products, Logo; routes presentations, patient information, web pages, digital products, working with AI), not when everything is passed. Colour, its five answers, the hero translation and the alt text are passed; the front-page photo is the 2500px original. Dark mode and the About pages no longer stand in front of the switch.

   Concepts done 2026-09-28. Sittings 1b to 5 passed every concept page — the seven the switch needs and Icons and Reader state — with 26 answers published; card 131 is closed.

   Torfinn's:

   • Routes done 2026-09-28: sittings 6 and 7 passed six route guides, all five the switch needs; print and signage stays none.
   • Content done 2026-09-28: sitting 8 passed the front page, the Create page and the gap register. What remains before the flip is Claude Code's B5 and B6; then the flip, the manifest diff and Deploy are Torfinn's. Export descriptions and gap-notice guidance lines are utility text and do not come to him.
   • B5 built 2026-09-28 and B6 rehearsed 2026-09-29. The machinery is on branch claude/new-site-walkthrough-51083b; the flip itself is the tip of worktree-agent-a47991a96093332d0 (229d1e5), both pushed. The flipped image, built on Linux in Docker, matched the local build on all 48 routes and passed the post-deploy check 57/0 once that check stopped reading a retired page; suite 817 passed in switched state, link audit clean at 4,076 paths (first recorded as 4,199, from a build folder holding an earlier build's leftovers; the clean rebuild gives 4,076), both redirects and every survivor answer, noindex on every page. The route guides rendered their sections unstyled (headings at body size, lists as plain lines), and are styled 2026-09-29: each route file is parsed into the concept pages' numbered rules, do-and-don't cards and checklist (lib/route-page.ts), guarded by lib/route-page.test.ts, which three deliberate breaks of the parser each turn red. That closes the "first route file rendered end to end" item below. Suite 856 unswitched, 855 switched.
   • Flip accepted 2026-09-29 (Torfinn), and on main. NEW_SITE is true and the route-manifest diff is accepted. What remains for Done: Deploy on the brand Forge app (Torfinn's), then the link audit and the post-deploy check against the live host.

   Claude Code's, before or at the switch:

   • The plan's build items B1–B7: route and answer checks before the first route is drafted, the front and Export copy files wired in, the review report per sitting, the switch as one flip with the one redirect, and the rehearsal.
   • Add the new pages to the sitemap (left out while the site is pre-release).
   • Token the two motion distances BASELINE states without tokens (the card's 2px rise, the arrow's 4px shift).
   • Visuals for the do-and-don't cards; medium tabs on "How to apply it"; a first route file rendered end to end.
   • Check the scroll spy and the copy buttons in a foreground browser tab — the preview pane runs as a background tab and delivers neither scroll events nor clipboard access.

   Done when: Torfinn has flipped NEW_SITE, the route-manifest diff is accepted, the link audit and review checks pass on the switched site, and the old pages are gone.

6. 164CCReady now

   Six pattern files are written in Swedish, and the corpus source language is English

   Done when all seven pattern files have an English source, the known-mismatch list holds no pattern, and Torfinn has passed the translations.

   Detail

   Files: patterns/button-label.md · chat-bubble.md · chat-response-simple.md · confirmation.md · empty-state.md · error-message.md · lib/route-manifest.test.ts § KNOWN_BASELINE_LANG_MISMATCH

   New 2026-09-24. constitutional/language-policy.md § 1 makes English the source language, with local languages only for local examples. Torfinn noticed on 2026-09-24 that the hero pattern had been amended in Swedish ("All corpus source material should be in English, so the translation runs the other way"); patterns/hero.md was translated to an English source the same day, keeping its Swedish examples. The other six are Swedish throughout, and the suite already lists all of them as known language mismatches.

   The work: translate each to an English source, keeping Swedish example copy as local examples with an English gloss, the way hero.md now does; remove each from the known-mismatch list as it lands; cut the package, since all six ship in agent-baseline. The translations are Claude's and need Torfinn's pass.

   Done when: all seven pattern files have an English source, the known-mismatch list holds no pattern, and Torfinn has passed the translations.

7. 163TReady now

   A method for keeping URLs once the site has users

   Done when there is a written method, and a check, for what happens to a URL that leaves the manifest once the site is released: a redirect table the server reads, with a test that every removed route either redirects or is declared gone.

   Detail

   Files: site/serve.mjs · lib/route-manifest.json · workspace/briefs/prd-brand-os-website-2026-09-24.md § 2.4

   New 2026-09-24, prep work. Torfinn ruled that the website redesign may change today's content URLs without redirects, because the site is pre-release ("the urls that we change right now doesn't need to survive unless the software/site itself depends on them internally"), and that keeping URLs should be solved as a method for when the site is live with users.

   What exists. The site is static files served by site/serve.mjs, which answers GET and HEAD only and has no redirect table. lib/route-manifest.json already records every published route, and a change to it is a reviewed diff, so it is the natural input: a route that leaves the manifest could be required to name where it went. An earlier ruling let the /sv/ URLs die with no redirect map (lib/sitemap-and-robots.test.ts).

   Done when: there is a written method, and a check, for what happens to a URL that leaves the manifest once the site is released: a redirect table the server reads, with a test that every removed route either redirects or is declared gone.

8. 162TReady now

   Search for the Brand OS website

   Done when Torfinn has decided the scope (titles and headings, or full text) and it is built into the site with a keyboard-reachable control, working without a client framework.

   Waits on Torfinn: scope

   Detail

   Files: workspace/briefs/prd-brand-os-website-2026-09-24.md § 2.5

   New 2026-09-24. The PRD's first draft put a search button in the header, searching page titles, section headings and answer questions. Torfinn moved it to the backlog the same day ("Let's put that on the backlog for now"), so iteration 1 ships without it and the header carries no search control. The site has no search today — no index, no library.

   Done when: Torfinn has decided the scope (titles and headings, or full text) and it is built into the site with a keyboard-reachable control, working without a client framework.

9. 161CCReady now

   Generate the Aleris Design System from Brand OS, so it stops being a second author

   Done when the artifact's README and tokens are generated from Brand OS, the drift check runs in the cut, and the four items above read as Brand OS states them.

   Waits on Torfinn's pass of the README's hand-written part

   Detail

   Files: workspace/briefs/brief-design-system-artifact-generated-2026-09-24.md · the organisation's default Design System artifact (https://claude.ai/code/artifact/e7069248-84f6-4dcf-ba2b-e60cbc3032d4)

   New 2026-09-24. The rule changes from the website design (changelog, twenty-fifth entry) landed in Brand OS, and the design system that Claude sessions build with still states the old versions. Everything outside the repo that the rule-changes brief listed as "correct there after this lands" is this card:

   • the old ground rule ("never white"), the sticky limit and the side-accent rule, now ruled differently or more fully in BASELINE.md;
   • the button bevel, which now lives in the tokens (--button-*-shadow, --button-press-shadow);
   • tokens.json setting all four motion durations to 0ms against the canonical 100, 200, 350 and 500ms — its reduced-motion values carried over as the defaults;
   • its README's motion note, "Only transform and opacity animate", which hard rule 7 no longer says.

   The brief fixes these by generating the design system's README and tokens from Brand OS, with a drift check wired into the package cut, rather than hand-correcting them once.

   Blocked on Torfinn for one part only: the README's hand-written part (brief § 3.1, step 4.2) needs his pass before the first publish. Until then the brief publishes the generated parts only, so the rest can run in its own session now. Publishing to the artifact is a Cowork step (brief § 4).

   Done when: the artifact's README and tokens are generated from Brand OS, the drift check runs in the cut, and the four items above read as Brand OS states them.

10. 160TReady now

    Tables need their own design guidelines

    Done when tables have their own guidelines, including how rows are separated, placed where § Tables points, and Torfinn has passed them.

    Detail

    Files: baseline/BASELINE.md § Tables · principles/grids-tables-dataviz.md

    New 2026-09-24, from Torfinn's ruling on the website design, iteration 1 (workspace/decisions/website-design-iteration-1-2026-09-24.md § 4b item 4): "Tables need to have their own design guidelines. The no-dividers rule applies to lists across Aleris design."

    What exists. § Tables in BASELINE.md holds six bullets on density, headers, alignment and actions. It says nothing on row separation, which is now the open question: the no-dividers rule landed for lists (§ Lists) and states that tables are out of its scope, so a table's rows are neither required nor forbidden to carry rules.

    Not written in the change that opened this card, on the brief's instruction (workspace/briefs/brief-website-iteration-1-rule-changes-2026-09-24.md § D.3).

    Done when: tables have their own guidelines, including how rows are separated, placed where § Tables points, and Torfinn has passed them.

11. 158TReady now

    Colleagues are making Aleris material with AI, and five artefacts say what is actually wrong

    Done when the instruction is replaced in ChatGPT and the floor survives its own falsification test — that the four read as permission rather than prohibition — and strand 3 has reported against the new text. Blocked on Torfinn for: his pass on the Swedish, the intranet location for the header files, and names for strands 1 and 2. (Two items dropped from this line on 2026-09-22 because the card's own body records them as closed: the footer became a header, and all three logo-identity.md collisions closed on 2026-09-18.)

    Detail

    Files: workspace/plans/internal-ai-material-discovery-2026-09-18.md (the discovery) · workspace/briefs/den-nara-experten-instruktion-2026-09-22.md (the replacement instruction) · workspace/sources/den-nara-experten-core-instruction-2026-09-22.md (what it replaces) · workspace/tools/palette-distance.py (the harness) · principles/imagery.md · principles/logo-identity.md · card 157 (the page that started this)

    New 2026-09-18. Card 157 produced a page of instructions; Torfinn brought five real artefacts made by colleagues and asked to explore the problem before building more. The five changed the diagnosis.

    The frame he set, because it rules out whole branches. Enablement rather than compliance. Group communications owns the brand and "ownership in the Aleris context cannot really be enforced since it's like herding cats" — so the success measure is adoption, not conformance, and anything slower than a blank prompt will not be used. Creative room internally is worth something on purpose; the expressive face is his own separate design challenge and is out of this scope.

    What the five measurably show. Five of five use a script face the corpus has no position on whatsoever — the most consistent signal in the sample is not a breach of anything written. Three of five carry a self-assembled unit lockup ("Aleris ASIH Haninge", "Aleris | Uppsala Närakut") against a settled ratified rule and its named misuse list; the 2025 merger lockups were removed as a resolved edge case, so there is nothing sanctioned to point people at, which is likely why units are building their own. Three of five carry generated imagery implying a real Aleris place, patient or outcome, against an accepted rule. Two of five invent colours that are close to the twelve --color-chart-* tokens already in the system, scoped to charts where no poster-maker would look.

    Three failures wearing one coat, and only the first is fixable with words. Rules that exist and never reached anyone; needs the system has no answer for (the typeface, print layout); and tool limits no instruction can cross — an image model does not honour a hex value, which if true makes a paste block of values theatre for anyone generating the artefact as an image. That last one is assumed and is what strand 3 exists to settle.

    CORRECTED, and the correction matters. A first reading of the marks claimed none had been hallucinated. Wrong: the crop of artefact 3 had missed its logo. There are two production routes in the sample and they fail differently — four artefacts composed in a layout tool, where the logo is right because a person pasted it and what drifts is judgement, and one generated end to end, where the mark, the letterforms and the diacritics are all painted approximations ("hālsa", a macron for the umlaut). Words reach the first route and cannot reach the second. The diacritic is the cheap detector for telling them apart.

    THE ROOT CAUSE IS A ROUTING BUG IN AN ASSISTANT THAT ALREADY EXISTS. Colleagues use Den nära experten, the custom GPT Torfinn built on Brand Core 2025. Its activation logic reads "Visuellt material (PDF, PPT, bild) → aktiverar Modul 1 + 2" — the visual branch fires on uploaded material. Someone typing "gör en affisch" is text input, gets modules 1 and 3, and Modul 2 never loads. The design module is unreachable at the moment something is being designed. That explains the artefacts exactly: the Swedish is good because the text modules fired and are well written; the visuals drift because the module governing them was never in the room. The system works as designed and the gap is a missing branch.

    It also explains the colour measurement. Modul 2 gives colour as adjectives — sand = bas, petrol = huvudfärg, orange = accent — with no values anywhere in the file. A model asked to produce from adjectives invents the hexes, which is the 5-to-12 ΔE near-miss band across all five. Now a hypothesis with a cheap test rather than a curiosity.

    Two structural problems behind it. core_instruction.md was not in the exported folder — the file that always loads first lives in the GPT's instructions box, so the most load-bearing file is the only one nobody can review or version. And the assistant is built on Brand Core 2025 rather than Brand OS: two sources of truth, one a year-old snapshot in Word and PDF, with nothing that notices when the other moves. That is the stale-copy problem card 157 amended the constitution for on the same day.

    RULED 2026-09-18, Torfinn — the floor is four, recorded in workspace/decisions/internal-material-floor-2026-09-18.md with the test that selects it and what would falsify it: the logo and fixed text are placed never drawn; no generated image claiming a real place, patient or outcome; the sender is Aleris; sentence case. Everything else explicitly free, stated first. Also ruled: the twelve --color-chart-* tokens are released as an internal warm palette — they are almost exactly the range people were inventing.

    The intervention moved, and the first version of the plan was wrong about it. Not a page on the site: three edits to the assistant — a production branch in the routing, a production half for Modul 2 carrying values instead of adjectives, and a rule about what a model may not draw. Already adopted, sits at the moment of failure, updatable by Torfinn alone, which is the only thing in view that meets the adoption test.

    A finding left alone rather than fixed. site/src/lib/site-nav.ts says the four About pages are "drafted and held at proposed". They are drafted nowhere — not in the corpus, not in workspace/drafts/. The nav renders them as planned links on that basis.

    RULED the same day — the supply rule 3 owed: a header. A sand band across the head of the page, logo top left, unit name top right, on A4 and 16:9, upright or sideways. It answers the need the homemade lockups were meeting — the unit gets to say who is speaking — while the mark stands alone and unattached, so "the sender is always Aleris" holds in full. The band height is not a design choice: the safe zone is 50% of the logo's height on all sides, so a band that is the safe zone is exactly twice the logo height. The unit name shares the wordmark's baseline, at 0.7445 of the logo's height from its top — measured from the logo file, cross-checked against the ratified 0.4933 cap ratio to 0.4%, and then verified by canvas measurement rather than by eye (1px of difference in 157). Its size is stated against the wordmark's cap height so it holds at any scale. Set in Arial, ruled 2026-09-18 — "most users won't have Museo Sans installed and none of them using Figma" — which applies the 2025 rule that Arial is the face for PowerPoint and for material made outside the communication department, rather than making an exception.

    And a finding that decides how the header ships. An SVG with live text loses the unit name silently in macOS Quick Look: band and logo draw, the <text> element is dropped, no error. Browsers render it correctly, so it looks right wherever it is checked and wrong wherever it is used. With nobody in Figma and most without Museo Sans, the asset cannot assume a design tool or a font — the candidates are a PowerPoint template with an editable text box, PNG strips per unit, or SVGs with the name outlined. Generator and check live in workspace/tools/header/, so whatever ships is regenerated rather than redrawn.

    Three collisions with principles/logo-identity.md were raised and all three closed the same day, each by leaning on the existing rule rather than writing a new one. It was first ruled as a footer, which put the mark bottom right against his ratified "placement is always in the top left corner" — moved to a header, and the exception disappears instead of being recorded. A first draft said the symbol is never used as "ornament", which read as narrowing his standing permission for the symbol as a brand element — Torfinn: keep the rules, drop the term, "better to just be clear about what is and is not allowed in plain text". And safe zone keeps its existing meaning and stays attached to the logo; the band is a header. The design never breached the misuse list, only the word did. No change to logo-identity.md is needed by any of this, which is the outcome worth noticing.

    The colour figure from this card's first version is withdrawn. v1 of the harness measured photographs. Rebuilt, checked against synthetic artefacts at exact and at invented values, it says something narrower and more useful: grounds are close in all five (1.8–5.8 ΔE), petrol is a consistent near-miss where it appears (5.9, 6.3), and the accent is absent from all five — no flat orange anywhere, at any distance. Told "orange som accent" with no value, people did not pick a wrong orange; they went to script faces and hearts instead.

    RULED 2026-09-18 on delivery: the intranet, with the assistant as signpost, and one template with an editable unit name rather than one per unit — "managing this file whenever units come or go is futile." That put the baseline back into a PowerPoint text box, which is positioned by its box and not its baseline, so it is calibrated rather than derived: workspace/tools/header/calibrate.py renders the file, measures the name's baseline against the wordmark's, and the constant in the generator is that measurement. It reports zero difference; the first guess at Arial's ascent was 0.4mm out. The calibration is against this machine's renderer, and Windows is an assumption until someone opens it there.

    And the showcase and the experiment are the same job (Torfinn): the accepted versions of the observed artefacts double as strand 3's condition B, with the five artefacts already serving as condition A at no cost. One condition decides whether it is a test at all — the accepted version must be made through the assistant the way a colleague would, not by hand in a design tool, or it only proves a good poster is possible. And a named unit's work should not be shown as the "wrong" half without asking them first; strand 2 is contacting them anyway, and an invitation to co-author the pair turns a slight into a credit.

    Strand 3 is written and ready to run — workspace/plans/strand-3-protocol-2026-09-18.md. Twelve generations, about an hour, both prompt conditions written, scoring sheet included, instrument proved. It settles which project this is: if values move the output the fix is three edits to an assistant Torfinn owns; if they do not move it on the image route, written guidance cannot reach those artefacts at all and the effort belongs in templates.

    THE THREE EDITS BECAME ONE REPLACEMENT, because the module layer was never a mechanism. 2026-09-22, drafted in workspace/briefs/den-nara-experten-instruktion-2026-09-22.md. A custom GPT retrieves its knowledge files by semantic similarity rather than loading them on command, and .md is among the least reliable formats — frequently routed to Code Interpreter instead of the retrieval pipeline. So "Modul 2 aktiveras" never guaranteed anything, and the routing bug this card found had a second cause underneath it: edit 1 fixed when the module is called for and could not fix whether it arrives. Only the Instructions box loads every time. The floor, the nine values, the image rules and both output contracts now live there, measured at 7,892 characters against the box's 8,000 limit after four compression passes — the first draft came in at 8,837 and could not have been pasted at all.

    The file nobody could review is now in the repo. Torfinn pasted the Instructions box on 2026-09-22 and it is captured verbatim at workspace/sources/den-nara-experten-core-instruction-2026-09-22.md, closing this card's second structural problem and open item 4 of the discovery. It is 1,518 characters, and it confirms the diagnosis in its own words: "Beroende på vad användaren laddar upp eller frågar om: … Visuellt material (PDF, PPT, bild) → aktiverar Modul 1 + 2". The replacement is 5.2 times longer than what it supersedes, which is the risk strand-3-protocol-2026-09-18.md already names — a long instruction crowding out the brief — and the reason to run strand 3 as an acceptance test rather than assume a more complete text is a better one.

    A third gap, found while writing and absent from the discovery: nothing governed the image prompt. Image generation is on. When the assistant generates a picture it writes a prompt for a second model, and no brand rule travels to that model — only the words typed into the prompt. That is the exact moment the mark gets hallucinated, and it was ungoverned in the current instruction, in all four modules and in the 2026-09-19 edits. The replacement rules it directly: no text at all in generated images, which collapses hard rule 1 from a fourth prohibition into a consequence of one design decision and is the only reliable defence against the diacritic failure; the top fifth reserved as a positive property rather than by negation, because a prompt that names the logo can summon one; prompts written in English; and a look-at-the-output check, which is the only closed loop in the design. Note for the falsification test: the durable argument against drawing the logo is not capability. Image models render text well in 2026, so "it cannot do text" expires and takes the rule with it. What survives is that the logo is a file rather than a description, and that a mark which looks right is harder to catch than one that looks wrong.

    The review half was rewritten too, not only the production half. Modul 2's criteria pass the artefacts this card exists to prevent — a hallucinated mark with generous clear space passes "logotyp och friyta", and a well-lit generated patient satisfies "visa äkta människor och naturligt ljus". That phrase is gone; as worded it reads as an instruction to produce the failure. The floor is now checked before the expression, and the friyta criterion carries an explicit note that it cannot vouch for the mark.

    AN EXTERNAL DEADLINE ARRIVED, and it is not ours to move. OpenAI announced on 2026-09-11 that custom GPTs retire. For Enterprise workspaces, new GPT creation ends in late October and custom GPTs stop running on 2026-12-11. Migration turns a GPT's instructions into a skill inside a plugin; knowledge files carry over, custom actions and the selected model do not. Three consequences, all of which the draft already takes: what is in the Instructions box is what survives, so the guardrails belong there on migration grounds as well as on retrieval grounds; nothing may be built on actions or URL fetching, which closes the discovery's option of pointing the assistant at the raw token endpoint and settles the values as a dated copy with provenance; and the draft opens with a trigger paragraph that is harmless preamble today and becomes the plugin skill's description field in December. Eleven weeks. One rewrite now, then a copy.

    Strand 3 is updated to v0.2 and its kit is built, 2026-09-22. Three conditions rather than two — today's Modul 2 text, the short values block, and the new instruction as it will run — because a bad result under 7,892 characters could be the values or the length, and only the middle term separates them. Eighteen generations, about ninety minutes. workspace/plans/strand-3-run-kit-2026-09-22.md has the paste blocks, the naming, the sheet and the commands. Claude cannot run it: it needs image generation in ChatGPT and a layout tool. Under condition C, route 1 should produce no finished poster at all, and one appearing anyway is the run's most important single result, because it would mean the instruction never reached the image step.

    Re-proving the harness found it cannot see a white page. It responds correctly to distance — 0.0 ΔE at exact token values, 1.8 weighted at plausible invented ones, 6.5 with two roles banded off. But a poster with a pure white ground and otherwise perfect brand colours scores 1.8 weighted and is banded on, because sand-50 is #faf8f6 and sits 2.6 ΔE from white, and the page-ground role scores against whichever sand is closest. The most-cited AI tell in the corpus reads as correct. Moved to the by-eye sheet, which had not carried it. Also found: the five original artefacts are stored nowhere — they were images in a conversation, so §2's baseline figures cannot be reproduced and the showcase has no "before". Same defect class as the core instruction. Worth saving into workspace/sources/ before strand 2 contacts anyone.

    Done when: the instruction is replaced in ChatGPT and the floor survives its own falsification test — that the four read as permission rather than prohibition — and strand 3 has reported against the new text. Blocked on Torfinn for: his pass on the Swedish, the intranet location for the header files, and names for strands 1 and 2. (Two items dropped from this line on 2026-09-22 because the card's own body records them as closed: the footer became a header, and all three logo-identity.md collisions closed on 2026-09-18.)

    ---

12. 157TReady now

    The page for colleagues making things with AI, and the folder it cannot publish from

    Done when that wording has Torfinn's pass. The page itself is done — verified rendered at 1,243 words with its paste block intact, and it needs a deploy to reach the live host.

    Waits on —

    Detail

    Files: how-to/using-aleris-in-ai-tools.md (new, draft, label awaiting-pass) · lib/content.ts § CONTENT_DIRS · site/src/lib/site-nav.ts § SECTIONS · workspace/plans/website-v3-plan.md

    New 2026-09-18, Torfinn: "it's very important that we get something out into the hands of colleagues who produce stuff with AI that is in the uncanny valley territory of branding". Offered the choice between releasing the site as it stands and a narrow page for that audience, he chose the narrow page.

    What the page is. One page for a colleague who is not building software and does not want to read this site: a paste block for an AI tool, the nine colours with their values and their prohibitions, the type rules, a checklist of what gives an AI away, and an honest list of what the page does not give them. Every value is quoted from data-products/tokens/aleris-tokens.css and all nine of the URLs it cites were fetched and returned 200 on 2026-09-18.

    It carries one thing the corpus had nowhere obvious to put. Three characters an AI tool reaches for constantly — →, ←, ✓, plus ≤ and ≥ — are absent from both licensed Museo Sans weights, so they fall back silently to another face mid-sentence. That was measured 2026-09-05 and lives in BASELINE.md § Typography, which this audience will never open.

    Why it does not publish, and what the ruling is. how-to/ is not in CONTENT_DIRS, and the comment above that constant says so deliberately: "widening the publishing rule is Torfinn's decision, not a move's side effect". So the page sits in the tier the map assigns it and has no route. Its one sibling reaches a route only because MOVED_PATHS remembers where it used to live; a new file has no such history, and inventing one would be a fake legacy path. The three real options are: add how-to to CONTENT_DIRS (a second widening of the 2026-08-31 rule, with a lib/route-manifest.json diff as the designed gate), put the file in baseline/ (publishes today, wrong tier, and files it under a section label meaning "for builders"), or leave it unpublished and circulate it as text.

    The wiring change is inert until the words are passed. Every file in how-to/ is draft or carries no status, and the gate needs status: accepted plus a served lang. Adding the folder to CONTENT_DIRS today would therefore publish nothing at all — which makes the two decisions separable, and the publishing one safe to take first.

    Nav placement is the second half and it is also his. A route under how-to/ matches no section prefix, so sectionForRoute would fall through to Foundation. The page is for everyone rather than for builders or for readers of the brand, which is a shelf the six current sections do not have.

    The page broke a constitutional rule, and the suite said so. constitutional/tokens-are-canonical.md § 1 — no document outside the token file restates a token's value — is accepted and in force, and lib/token-values-are-canonical.test.ts failed on this file. That was the check working: the page holds nine values because its reader is pasting into a tool that cannot fetch a stylesheet, which is the one case the rule was not written against. It could not be quieted by adding the file to that check's KNOWN register, whose own words are "no new file may join".

    RULED 2026-09-18, Torfinn: "it's a checked view of the source". § 1 now carries one exemption — a page written for a reader who cannot fetch the token file may carry values provided every value on it is asserted against the token file by a check that fails when a token moves. The exemption is the check, not the intent, and a page claiming it without one is an ordinary restatement. The rule page is at v0.2; the amendment is Claude-drafted from his ruling and the wording still awaits his pass.

    The exemption is machine-conditioned rather than declared. lib/pasted-pages.ts is the single list both checks read: lib/pasted-values-are-live.test.ts asserts every hex on each listed page is a value the token file declares today, and lib/token-values-are-canonical.test.ts refuses the exemption to any file not on it — and fails if the live-values check is ever deleted, which is the way an exemption quietly becomes a hole.

    Why the exempt page is now better covered than a KNOWN one. The original check counts only hexes that still match a declared value, so on the day a token moves, every document printing the old value has its count go down and the suite reads greener. The rule's own failure mode looks like an improvement to the check written for it. The new check is the inverse and fails on that same commit; it was proved against a deliberately dead value before being trusted. Suite green at 492 tests.

    The page's role changed on 2026-09-18, same day, by card 158's diagnosis. It is no longer the thing colleagues are sent to — that is the assistant they already use. It is the human-readable source the assistant's production half is written from, which is a better fit for a page that has no URL yet anyway.

    One line rewritten on Torfinn's criticism. "Weights 500 and 700 only. Never 400. Never 300 below 40px." — three statements accreted around three separate incidents, reading as enforcement history rather than as instruction, and "strangely saying only 500 and 700 and then going on to say never 400 or 300". Now one: two weights, 500 for body and 700 for headings, with the 400 and 300 cases explained in the prose instead of stacked in the block. The general defect is worth keeping: rules written to catch a known breach do not convert into instruction without being rewritten, and this page lifted several of them unrewritten.

    RULED 2026-09-20 — both open questions, and neither is open any more. "Yes, how-to should publish", and "let's create a new nav option for how-tos so that we have a place to put new how-tos as we keep expanding the material." how-to joined CONTENT_DIRS — the second widening of the 2026-08-31 rule, and the decision the comment above that constant had been reserving for him in those words — and a How-to section sits in the header between the design system and the rules, carried pending. It published nothing on the day it landed, verified by reading lib/route-manifest.json rather than by trusting the test's silence: every file in the folder is draft or carries no status, so the wiring and the words stayed separable. Recorded in workspace/decisions/how-to-publishes-2026-09-20.md.

    And CLAUDE.md's publishing sentence was wrong about a different folder. It omitted principles/, which joined CONTENT_DIRS on 2026-09-07, while the folder list forty lines below said it publishes. The two disagreed for thirteen days and were only wrong together to someone holding both. Corrected with the how-to line.

    PASSED 2026-09-20 and the page is accepted. status: accepted, label: shareable, publishing at /how-to/using-aleris-in-ai-tools. The route set went 27 → 28 and the manifest is regenerated. The gate earned its keep on the way through: the auto-route strips aleris- from file names, so this would have published at /how-to/using-in-ai-tools — "using in AI tools" — which is the second instance of the trap that caught colour-is-the-aleris-palette on 2026-09-07. ROUTE_OVERRIDES now carries both and says that two makes it a pattern.

    Rewritten before it was accepted, on two of Torfinn's corrections. It still aimed at interfaces — radii, a 14px floor, 44px touch targets, buttons throughout — and those moved to the software section where they are true. Its typography led with a licence note about websites when the fact that matters is that almost nobody has Museo Sans, so Arial is what reaches the page; the 2025 guidelines already make Arial the face for PowerPoint and for anything made outside the communication department, so this applies a rule rather than conceding one. Six places came out in the language pass, including a line claiming the page's own plainness and, with it, a factual error: "three characters" followed by five.

    Still open on this card: the amendment's wording in constitutional/tokens-are-canonical.md, which publishes and is Claude-drafted.

    Done when: that wording has Torfinn's pass. The page itself is done — verified rendered at 1,243 words with its paste block intact, and it needs a deploy to reach the live host.

    ---

13. 156TReady now

    Which token vocabulary is canon, and the borders disagree

    Done when the border question is ruled and both tokens carry the ruled values, the naming scheme is chosen and a reconciliation is written that sundviktlakemedel can port against, and this card's answer is recorded somewhere that repo can point at rather than in a state file only it reads.

    Waits on Torfinn: the re-vendor, each consumer being on the no-go list

    Detail

    Files: data-products/tokens/aleris-tokens.css (364 tokens) · ~/Downloads/Aleris Design System (fixed)/tokens/*.css (135 tokens, 9 files) · sundviktlakemedel/_state.md § Blocked by · cards 64, 121

    New 2026-09-13. This card exists because the decision blocking another product's UI rebuild was not on this board at all.

    The situation. sundviktlakemedel has frozen v1 and is rebuilding its UI as v2. Its _state.md names the gate three times — "the token vocabulary gating v2", "Which token vocabulary is canon is the gate on Phase 2, and it is Torfinn's" — and gives the reason a port cannot start without it: an undefined custom property fails silently, so a half-reconciled vocabulary produces a UI that looks broken in ways nothing reports. Nothing in this repo carried that question. The board is the list of record for what is open and who holds it; this was open, held by Torfinn, and visible only in the blocked party's own notes. It could not have surfaced in a decision sitting.

    The premise it has been waiting on is understated in three ways, measured here 2026-09-13. That state file records "73 design-system tokens against Brand OS's 365, 21 shared names, values agreeing — so it is a naming reconciliation, not an absorption of new concepts". Recomputed from both files:

    	Recorded	Measured
    Export tokens	73	135
    Brand OS tokens	365	364
    Shared names	21	40
    Shared values agreeing	all	36 of 40

    The 73 was an undercount and this session reproduced it before catching it — the export is minified, several declarations to a line, and a line-anchored scan sees only the first on each. It returned exactly 73, matching the recorded figure, which is the most persuasive possible way to be wrong. Worth recording as its own small lesson: an independent recomputation that agrees with the number it is checking has not necessarily checked it.

    The four that disagree, and two are real. --ease-out and --ease-in-out differ only in whitespace and leading zeros — the same curves. The other two are not:

    Token	Export	Brand OS
    --border-default	#abc7c9 (petrol-200)	#d7d2cb (gray-100)
    --border-strong	#004851 (petrol-500)	#9e9281 (warm grey)

    This is one decision, not two: are Aleris borders brand-coloured or neutral? The export's whole border family is petrol-tinted and shifted one step — --border-subtle is gray-100, --border-default is petrol-200, --border-decor petrol-300, --border-strong petrol-500. Brand OS's borders are warm neutrals. A port that assumed the values agree would silently restyle every border in the application, which is precisely the failure the state file warns about, arriving through the half nobody was watching.

    And it sets a trap for card 64. That card asks for --border-subtle as a lighter row separator than gray-100, for a 250-row worklist whose separators and panel edges are forced to one value. The export already has a token by that name and it is gray-100 itself — the same name for a different thing. Adopting the export wholesale would fill card 64's name while leaving its requirement unmet, and nothing would report that, because a token that exists resolves.

    Most of the rest genuinely is naming, as the state file believed. 95 export names are absent here; 22 of them are this repo's own primitives under a shorter prefix — --petrol-500 against --color-petrol-500. Of the concept families in the remainder, Brand OS already carries spacing (25 tokens), focus (9), leading (12), weight (21), radius (19), row heights (3), touch targets (2) and the max-width/grid family (5) under its own names.

    Two families are genuine gaps, and both are already open as card 121. The export has --gradient-petrol and --gradient-orange; Brand OS has no gradient token at all. It has an --action-* family with hover rings; Brand OS has none. Card 121 is "Controls on a branded ground — five of six variants undefined, and no check can see a gradient", opened from a consumer measuring a live action that shipped invisible on five of seven seeded home screens. So the export is not only a rival naming — it carries the vocabulary card 121 says is missing. Whether it is the right vocabulary is a separate question from whether it fills the hole.

    RULED 2026-09-13, all three, and the reconciliation is built and self-checking.

    1 · Borders are neutral (warm grey). Canonical stands: --border-default is gray-100 #d7d2cb, --border-strong is #9e9281. The export's petrol-tinted family does not enter at any name — which also clears the trap above, because --border-subtle stays free for what card 64 actually asked for, a separator lighter than gray-100.

    2 · Canonical is this repo's scheme, on Torfinn's criterion — coherent and well structured, following good defaults rather than a bespoke invention. The good default is already written down here and did not need inventing: schemas/design-token.md § Layer 2 documents primitives → semantic → component and says "reference semantic tokens in code… never reference primitives directly — typing a hex code is the signal something is wrong." The export publishes bare primitives — --petrol-500, --sand-100, --gray-300 — as its public vocabulary, which invites exactly the direct-primitive reference that document forbids, and drops the category prefix that tells a primitive from a semantic token apart.

    3 · The export's vocabulary enters unless it collides — and measured, almost all of it collides. Five tokens enter. --gradient-petrol and --gradient-orange (Brand OS has no gradient token at all, which is card 121's gap), --status-info (canonical has error, warning, confirm, background — no informational state), --measure-text (a 68ch line-length measure, nothing canonical expresses one), and --surface-row-hover.

    The collision worth reading first, because it would have failed silently. --text-* carries two different types. Canonically it is a colour family — --text-primary, --text-secondary, --text-inverse. In the export, --text-xs … --text-2xl are font sizes, and canonical font sizes are --font-size-xs … --font-size-2xl, which map one-to-one across all seven. Adopting the export's --text-* alongside ours would make color: var(--text-base) resolve to 1.125rem; a declaration with an invalid value is dropped at computed-value time with no error, so the symptom is text silently inheriting its parent's colour.

    A fifth disagreement the shared-name comparison could not see. --duration-shimmer is 1400ms in the export; canonical --skeleton-duration resolves through --duration-moderate to 350ms. The names differ, so a name-keyed comparison was blind to it — a four-fold difference in how fast a loading skeleton pulses. Canonical holds under ruling 3; recorded rather than decided, because 350ms is fast for a shimmer and it belongs with whoever next touches motion.

    One thing the two vocabularies agree on completely: the spacing scale. The export's --space-1…9 and canonical's --spacing-3xs…3xl are the same nine values — 4/8/12/16/24/36/48/72/96px — under numeric versus t-shirt names. Nothing is reinterpreted.

    The deliverable is data-products/tokens/export-reconciliation.json, every one of the 135 export names mapped or listed as entering, with lib/export-reconciliation.test.ts asserting three properties so it cannot rot into a stale table: every target is a token canonical actually declares, every export name is accounted for exactly once, and nothing listed as entering is already taken. All three proved able to fail — a dangling target, a dropped name and a false enters claim each fire. The coverage half skips and says so when the export is not on the machine, since it lives in ~/Downloads.

    NAMED AND LANDED 2026-09-13. Torfinn took the proposals for the gradients and the informational status, and deferred the measure. Three tokens added, one deferred, and one candidate withdrawn on a measurement.

    Export	Canonical
    --gradient-petrol	--surface-gradient-cold	added
    --gradient-orange	--surface-gradient-warm	added
    --status-info	--status-info + new --color-info-500	added
    --measure-text	—	deferred
    --surface-row-hover	--table-row-hover-bg	already existed

    The gradients are named for the axis, not the pigment. This token file already carries a cold/warm/neutral surface axis — --surface-strong-cold is petrol-500, --surface-strong-warm is orange-500 — and each gradient starts on its own strong value and lightens one step. So they join a family a reader can predict rather than opening a --gradient-* one. --gradient-petrol names the pigment, which is primitive-layer thinking; the semantic layer names a role, and the role is a branded ground. This does not answer card 121 — which controls may sit on one, and how a check measures text over a gradient, are still that card's. It supplies the ground the card was missing.

    --status-info needed a primitive, and not the export's. The export's value was #004851, which is petrol-500, which is --text-primary — an informational state rendered in body-text colour does not read as a state. It takes #007bc7, the blue already in this system as --color-goal-no-data, as a separate declaration rather than an alias: that set is constrained "Dashboard only… never patient-facing", and tying a general status to it would give one value two unrelated roles with nothing comparing them. Same hex, two declarations, on the precedent warning-500/sand-500 already set. Measured before adding, not after: 4.51:1 on white, 4.26:1 on sand-50, 3.84:1 on sand-100 — so it clears AA for text on white and on neither sand ground, the same shape as confirm-500, and it is constrained the same way under card 118's rule.

    --measure-text is deferred, and that is recorded as a decision rather than a silence. Torfinn: "I cannot say what is right for this without more data about how it impacts our layouts and accessibility, so let's keep what we have until data shows us that we need to change it." The reconciliation file carries it in a deferred block with the condition that reopens it — a product measuring a readability or layout problem it can attribute to line length. Its test counts deferred toward coverage, so a token that is neither mapped, entering nor deferred is one nobody has considered.

    --surface-row-hover was withdrawn before it landed. The concept exists at --table-row-hover-bg, in the component layer, because a row hover is table-scoped; the first pass checked --surface-* and not --table-*. The two also disagree on value — canonical is --surface-subtle-warm, an orange tint, against the export's sand-50. The check did not catch this, and the reason is worth keeping: it asserts nothing entering shares a name with canonical, and this collided by concept under a different name. Concept collision is a judgement, not mechanically checkable. The name check is the floor, not the rule.

    Also landed: the shimmer. --skeleton-duration was var(--duration-moderate), 350ms, against the export's 1400ms. Torfinn took 1400ms. The alias was the defect rather than the number — the four --duration-* steps are transition levels, annotated as such, and a shimmer is an ambient loop that happens to be measured in the same unit. At 350ms it swept four times inside the same section's own "< 2s: shimmer only" window, which reads as flicker rather than as waiting. It now carries its own literal and a constraint against re-aliasing that scale.

    CUT AS v0.13, 2026-09-13. Three mirrored files changed — the token file, its generated JSON, and BASELINE.md — and the cut closed all three lag declarations, which is what a declaration promises. --check reports 30/30 byte-identical to canonical afterwards.

    A whole version, and not close: five new token declarations. Rule 6 sends new content to a whole version and a correction to a point release. (Claude-drafted call, one edit in two files to revise.)

    RE-VENDOR rather than repin, and gentler than v0.12 in the way that matters: nothing was retired. A retirement turns a consumer's var() into a dangling reference, which is invalid at computed-value time and therefore inherits rather than erroring — no build warning, a colour silently replaced by the parent's. v0.13 adds five declarations and changes one value, so a consumer adopting none of the new tokens sees exactly one difference, the shimmer. v0.12's mandatory pre-grep does not apply to this cut — though it still applies to sundviktlakemedel, which is pinned at v0.11 and takes v0.12's retirement on the way past.

    _packages/adapters/vendored-app/REVENDOR-v0.13.md is the hand-off, per consumer, prepared to the gate and left there because all three are on the no-go list. It names the check that matters: a re-vendor is verified not by a green suite but by the provenance record's hashes moving in the same commit as the bytes — a copy without a record update fails, and a record update without the copy fails.

    What is left is the re-vendor itself, and it is Torfinn's. sundviktlakemedel is the consumer this cut exists for: its _state.md has named "the token vocabulary gating v2" as a blocker three times, and this is the first cut carrying the vocabulary that answers it.

    Superseded — the questions as originally asked:

    1. Are borders petrol-tinted or neutral? One visual ruling, two token values, every surface in every product. Nothing else here can be settled while it is open, because it decides what --border-subtle is allowed to mean.
    2. Which naming scheme is canon — --petrol-500 or --color-petrol-500? Mechanical either way, and it decides the direction of a rename that has to happen once, in one place, before v2 starts porting.
    3. Does the export's gradient and --action-* vocabulary enter Baseline, adapted, or is card 121 answered from scratch? A cut and a version judgement, whichever way.

    Not recommended from here. Question 1 is a brand decision about what Aleris looks like, and the corpus has no position to read it off — foundation/colour.md does not rule on borders. Questions 2 and 3 are Claude's to execute the moment 1 is settled.

    Done when: the border question is ruled and both tokens carry the ruled values, the naming scheme is chosen and a reconciliation is written that sundviktlakemedel can port against, and this card's answer is recorded somewhere that repo can point at rather than in a state file only it reads.

    ---

14. 155TReady now

    The site is noindex until release, behind one flag

    Done when Torfinn says the site is ready, INDEXABLE flips to true, and a deploy is verified showing no noindex meta, no X-Robots-Tag, and robots.txt naming the sitemap again.

    Waits on Torfinn saying it is ready

    Detail

    Files: site/release-state.mjs (the switch) · site/src/layouts/Base.astro · site/src/pages/robots.txt.ts · site/src/pages/build-state.json.ts · site/serve.mjs · lib/noindex.test.ts

    New 2026-09-11, Torfinn: "noindex the site until we are ready for release". Done the same session; this card exists to be closed at release, not to be worked.

    The switch is INDEXABLE in site/release-state.mjs. Setting it true is the whole change: the meta tag disappears, robots.txt starts advertising the sitemap, the header stops being sent. Verified by doing it — flipped, rebuilt, checked all four surfaces, flipped back. The suite is green in both states and asserts the state the flag implies rather than hard-coding noindex, so it will not go quiet after release.

    It is not Disallow: /, and that is the one thing worth reading here. The obvious way to hide a site is a robots.txt Disallow, and it is the most common way a site stays in an index while its owner believes it is hidden: Disallow asks a crawler not to fetch the page, and a crawler that never fetches the page never reads the noindex on it. A URL discovered anywhere else — a link, someone else's sitemap, a mail scanner — stays listed as a bare URL with no description, and cannot be cleared until crawling is allowed again. So the site now invites crawling and answers every request with noindex. Allowing the crawl is what makes the refusal readable.

    Four surfaces, because a meta tag only exists in HTML. This site deliberately serves raw Markdown at /baseline/raw/* and /foundation/raw/* and a machine index at /llms.txt — machine readers are a first-class audience here — and none of those has a <head>. X-Robots-Tag from site/serve.mjs covers them, measured on /, /llms.txt and /baseline/raw/BASELINE.md.

    One design point found by a check rather than by thinking. The server first read the flag with import { INDEXABLE } from './release-state.mjs', and lib/static-server.test.ts failed instantly: serve.mjs imports nothing but node builtins, because the runtime image holds only site/dist and that file, so a non-builtin import breaks the container at startup, in production. The decision now travels as data — the build stamps build-state.json and the server reads it. Better than the import for a second reason nobody had in mind: the server reports what was built rather than what the source currently says, and those differ the moment someone edits the flag without rebuilding.

    It fails closed. A missing, unreadable or malformed stamp means not indexable, proved by deleting the file and watching the header persist. The asymmetry is the argument: hiding a released site is visible the day someone searches for it; leaking an unreleased one into an index is not visible at all, and is the expensive half to undo.

    One thing that went wrong and left a comment behind. The stamp was first written as _index-state.json, and Astro excludes _-prefixed files in src/pages from routing — so it emitted nothing, the server fell back to its default, and the output was correct for the wrong reason with no symptom. Caught by looking for the file. Renamed, and the trap is recorded in that endpoint's header.

    VERIFIED LIVE 2026-09-13. Deployed and measured on brand.dev.aleris.ai: robots.txt carries the pre-release body with Allow: / and no Sitemap: line, /build-state.json reads {"indexable": false}, the meta tag is in the page head, and X-Robots-Tag: noindex, nofollow comes back on /, /llms.txt, /baseline/raw/BASELINE.md, /favicon.ico and /sitemap.xml — HTML and non-HTML alike, which is the half a meta tag cannot do.

    Done when: Torfinn says the site is ready, INDEXABLE flips to true, and a deploy is verified showing no noindex meta, no X-Robots-Tag, and robots.txt naming the sitemap again.

    ---

15. 154TReady now

    Two Baseline gaps, found because the products that papered over them are being taken apart

    Done when either the tokens exist and both products use them, or the ramps are ruled sufficient and the five improvised values are gone. Either way KNOWN_OUT_OF_SET empties, which the check enforces.

    Detail

    Files: data-products/tokens/aleris-tokens.css · data-products/tokens/tokens.test.ts § KNOWN_OUT_OF_SET · site/src/styles/site.css

    New 2026-09-11. Both halves are the same shape: a product met a situation Baseline does not cover, invented a value, and the invention was recorded as a known exception rather than as a gap in the system. Deleting the Next app is what made that visible, because the exceptions expired with the file while the gaps did not.

    1 · No status tint scale. app/globals.css declared --color-status-success-20, --color-status-warning-20 and --color-status-suggested-20 — #dceee5, #f5ede0, #e5eff0. The exception entry said it plainly and has since 2026-08: "Baseline has no status tint scale; the app invented one. Gap in Baseline, not app error." The app is now gone and the gap is unchanged; what has gone is the only evidence anyone was looking at it. A tinted background behind a status message is not an exotic requirement, and the next product to need one will invent its own three values.

    2 · No dark-mode surface scale. Found the same day by repointing the token scan from app/ to site/src — a reach that would otherwise have gone quiet. site/src/styles/site.css declares --surface-page: #002b31 and --border-default: #14606a in dark mode: a page ground darker than petrol-700, and a border between petrol-400 and petrol-700. This one has more weight than a missing tint, because board card 1293 established that respecting a user's dark-mode setting is a legal requirement, the same class of obligation as the WCAG floors rather than a brand preference. The system requires the mode and supplies no tokens for it, so the site publishing the design system is the first product to have improvised around it.

    Neither is rewritten to an existing token, deliberately. Substituting petrol-700 for #002b31 changes what the page looks like, and that is a design decision rather than a lint fix. Both are recorded in KNOWN_OUT_OF_SET, whose anti-rot half asserts each value is still present — so the moment someone fixes one without removing its entry, the suite says so.

    The ruling is whether these become scales. A status tint ramp and a dark-mode surface set are both additions to aleris-tokens.css, which makes them Torfinn's and a package version. The cheaper alternative worth naming: rule that neither is a gap, and that a product needing a tint or a dark ground picks from the existing ramps — in which case these five values get replaced and the entries removed.

    Done when: either the tokens exist and both products use them, or the ramps are ruled sufficient and the five improvised values are gone. Either way KNOWN_OUT_OF_SET empties, which the check enforces.

    ---

16. 153TReady now

    The plain picker went dark too, and the site still ships the icons it no longer uses

    Done when the plain picker's fate is ruled, the build either serves the icon set for a reason or stops serving it, and the font floor has a checker or a ruled exemption.

    Detail

    Files: astro.config.mjs (publicDir) · public/icon-picker/ (3,776 files, 16 MB) · in aleris/ikon: app/picker/ and app/qlik/

    New 2026-09-11, found by verifying the cutover deploy rather than by reading anything. Two halves, and only the first needs a ruling.

    1 · /tools/icon-picker is a 404, not just /tools/icon-picker/qlik. Measured on brand.dev.aleris.ai right after the deploy. Card 145's scoping said "/tools/icon-picker itself (the plain picker) reads no database and its assets already ship in the Astro build" — a true sentence that reads as it survives the cutover, and it does not. Card 149 moved app/tools/icon-picker/**, all 22 files, which is both surfaces. The "nobody is actively using it" confirmation was about the Qlik tool, which is the one card 148 had measured answering 200; nobody asked about the plain picker, and it is now equally dark. It may genuinely not matter — that is Torfinn's to say, and the cutover plan already carries the open question "whether the picker is one app or eventually two surfaces", which this turns from speculative into live.

    2 · The site serves 3,776 icon files that no page on it references. Measured: /icon-picker/svgs/regular/house.svg returns 200 and 700 bytes, /icon-picker/metadata/categories-sv.json returns 200, and grep for src=/href="/icon-picker/…" across every built HTML page returns zero. The five files that mention icon-picker mention it in prose — the board, the changelog, BASELINE.md and one constitutional page. So 16 MB ships in every image and deploy for nothing, and it is a second live public copy of the icon set now that ikon holds the vendored one. Card 149 explicitly rejected "fetching the allowlist at build or run time" because it trades a checkable copy for a silent runtime dependency; leaving these URLs live is an open invitation to exactly that.

    The repo must keep the files — public/icon-picker/ is the canonical source ikon vendors from, brand-provenance.json hashes the tree against it, and lib/build-has-no-private-registry.test.ts asserts the set is committed rather than a stub (checked: it asserts the repo, not the build output, so excluding them from the build breaks no test). The question is only whether the deployed site should serve them, which is one line in astro.config.mjs.

    Depends on half 1: if the plain picker comes back on brand.aleris.ai, the assets stay. If it lives only at ikon, they go.

    A third thing, found 2026-09-11 when the Next app was deleted: a check lost its subject and nothing picked it up. data-products/tokens/tokens.test.ts carried app/tools/icon-picker/qlik/qlik.module.css as a known sub-14px-floor file — 23 literal declarations at 11px, 12px and 13px. That file is now in aleris/ikon, and nothing checks the font floor there: the contributed out-of-set-hex.mjs that travelled with the picker reads colours only. So an accessibility finding that had a standing check in this repo has neither a check nor a home. Recorded here rather than dropped; closing it is either a font-floor scan added to the contributed set, or a decision that a dense instrumental tool is exempt — which is the call card 30 asked for and never got.

    Done when: the plain picker's fate is ruled, the build either serves the icon set for a reason or stops serving it, and the font floor has a checker or a ruled exemption.

    ---

17. 152TReady now

    A live app uses the petrol step the scale decided against

    Done when the ramp has the step and ikon uses it, or ikon uses a neighbour — and either way the known_out_of_set entry is gone, which the check enforces.

    Detail

    Files: data-products/tokens/aleris-tokens.css (the petrol ramp, --color-petrol-500 / -700) · in aleris/ikon: app/qlik/qlik.module.css:10, and its known_out_of_set entry in brand-provenance.json

    New 2026-09-10, found by the out-of-set hex scan's first run in ikon (card 151).

    It was already evaluated once and ruled out, which the first version of this card did not know. data-products/tokens/tokens.test.ts carried this value as a documented exception with the note: "this is the same dark petrol board card 16 evaluated and ruled out as a secondary hover". So the question is not new — the value was considered for the ramp, rejected for that use, and then used anyway in a product. That changes what is being asked: not should we add a step, but does a rejected-for-hover value earn a place as a surface. Found 2026-09-11 while clearing the entry, which was pointing into a file the cutover deleted.

    The measurement. --header-dark: #003942 in the Qlik picker's stylesheet. It sits between --color-petrol-500 (#004851) and --color-petrol-700 (#003238) — which is where a petrol-600 would be. The scale deliberately does not have one: petrol-700's own token comment records that card 19 added only the press step, "hover no longer needs a colour step (card 16, the hover/focus merge), so only the press step was needed, not the petrol-600 the design return also proposed".

    It was known in the app and had never reached the corpus. The declaration already carried the comment "promote candidate → Brand OS petrol scale" before any check looked at it, which makes this a reporting gap rather than a discovery: someone saw it, wrote it down where only that repo could read it, and there was no route from there to here. The scan is now that route.

    Not fixed, and the reason is not caution. Substituting either neighbour changes what the header looks like, which is a design decision. It is recorded in hex_scan.known_out_of_set with this card named, so the check is green while the finding is visible, and the anti-rot half fires if someone swaps the value without removing the entry.

    The ruling, and it is a token decision: does --color-petrol-600: #003942 enter the ramp, or does the app move to petrol-500 or petrol-700 and accept the change? A third option worth naming: the value is close enough to petrol-500 that the difference may not survive a look at the two side by side, in which case this is a one-line fix in ikon and no token at all.

    Done when: the ramp has the step and ikon uses it, or ikon uses a neighbour — and either way the known_out_of_set entry is gone, which the check enforces.

    ---

18. 150CCReady now

    An unreproduced intermittent in the suite — recorded rather than declared fixed

    Done when a failing run is captured with its file name, or the suite has gone a month without one and this card is closed as unreproduced with that stated.

    Detail

    Files: lib/branch-hygiene.test.ts (the leading suspect, and only a suspect) · lib/static-server.test.ts (ruled out — its fixed ports were a real flake and are fixed)

    New 2026-09-10. Two observations, no reproduction, and this card exists because "it passes now" is not a diagnosis.

    What was seen. Test Files 1 failed | 22 passed twice, roughly an hour apart. Both times the run came immediately after heavy work on the machine — the first right after a merge with a large diff, the second right after a large file write plus a site build, with Docker builds and npm install runs happening through the same period. Neither run's failing file name was captured, which is the gap that makes this a card rather than a fix: the failure was seen through a grep that showed the summary line and not the name.

    One real flake was found and fixed in the hunt, and it is probably not this one. lib/static-server.test.ts bound ports 4187 and 4188; two runs in quick succession could collide on a socket not yet released. Fixed by binding PORT=0 and reading the assigned port from the server's own startup line — which in turn surfaced a genuine defect in site/serve.mjs, logging the requested port rather than the bound one, so it printed 0. Both fixed. But that flake needed two overlapping runs, and neither observed failure had one.

    The leading suspect, stated as a suspicion. lib/branch-hygiene.test.ts is the slowest file at 4,147 ms against a 30-second ceiling on an idle machine, and its cost is a git object walk that scales with refs and repository size. Card 109 already records it timing out once at 6.0 s against vitest's 5 s default "while its own verdict was correct and printed — a red light saying the wrong thing", and today's session created and destroyed six worktrees and many branches. A 7× margin makes this unlikely rather than impossible, and unlikely is where it has to be left: it is a hypothesis, not a finding.

    Sixteen consecutive clean runs since (six, then ten in a loop capturing failures by name). The trunk is green.

    CAPTURED 2026-09-13, with its name, and the leading suspect was right about the file and wrong about the cause.

    It is lib/branch-hygiene.test.ts, and it is a timeout rather than a failing assertion. Observed at 33,943 ms against its 30-second ceiling, reported as "has no undeclared branch ahead of main" failing — the name of whichever test the clock ran out on, not a test with anything wrong with it. Card 109 already described this shape once: "a red light saying the wrong thing". Anyone reading that failure would go and look at branch declarations, which are fine.

    It is load-dependent, which is why it never reproduced. Three consecutive measurements of the same file, same tree, minutes apart: 25.1 s alone, 54.1 s, then green in a full run. Nothing changed between them but what else the machine was doing. That variance is the whole phenomenon, and it is why sixteen clean runs proved nothing.

    The cost is fixture construction, not the object walk. This card and card 109 both guessed a git walk scaling with refs and repository size. Measured: 31 refs, which is trivial. What the file actually does is build roughly twenty temporary git repositories, each about 1.1–1.4 s of subprocess work, and run them while vitest has 25 other files in flight.

    One hypothesis tested and disproved, recorded because it looked convincing. git count-objects -v showed 9,112 loose objects against 172 in-pack — an unpacked repository, which genuinely does slow every git call, and exactly the kind of finding that ends an investigation. git gc packed all 8,544 and the very next run took 54 seconds, worse than before. So the loose objects were real and were not this. Repacking was worth doing on its own account; it was not the fix.

    What this means for the fix, and it is not the ceiling. The ceiling has been raised once already, 5 s → 30 s under card 109, and it is being outgrown again while the file's work grows. Raising it a third time chases the cost rather than meeting it. The two real options are reducing the fixture count — most of those twenty repositories differ in one commit and could share a base — or taking this file out of the parallel pool so it is not competing for the machine while being timed on wall-clock. Not done here: it is its own change, the trunk is green, and this card existed to get the diagnosis rather than the repair.

    What would settle it, and is the actual work of this card: capture the failing file name when it next happens. A run that reports only a summary line cannot be diagnosed afterwards, and both of today's were lost that way. Either the suite's invocation should always preserve full output, or the harness should keep the last failing run — the cheap version is not piping vitest through grep when the result matters.

    A process defect found alongside it, and worth more than the flake. Both failures were pushed anyway, because the commands were chained — npx vitest run | grep … && git push and later … ; git push. The filter's exit status gated the push, not the test's. The trunk was briefly red twice as a result. Chaining anything after a test run hides the thing the run was for; the push has to read the test's own status or be a separate step after reading the output.

    Done when: a failing run is captured with its file name, or the suite has gone a month without one and this card is closed as unreproduced with that stated.

    ---

19. 149T→CCReady now

    Extract the icon-picker to its own Forge app, and Brand OS becomes Supabase-free

    Done when the picker serves from its own Forge app on its own domain, renders an icon through @resvg/resvg-js, carries a provenance record for the allowlist and the icon set, grep -rl supabase lib app components in this repo returns nothing, and it is on main.

    Waits on Torfinn: the schema through the broker, then the OIDC credentials and the domain

    Detail

    Files: app/tools/icon-picker/** (22 files, 2,105 lines) · lib/supabase-server.ts · public/icon-picker/svgs/ (3,772 files, 16 MB) · data-products/iconography/allowlist.json (78 entries) · supabase/migrations/ (3 files) · db/seeds/icon_assignments.json · _packages/adapters/vendored-app/

    New 2026-09-10, from Torfinn's ruling: "Let's make icon-picker its own forge app — i can set up the domain and we'll move it there." Step 3 of workspace/plans/forge-cutover-sequence-2026-09-10.md, and it gates step 4 — the picker answers 200 on brand.dev.aleris.ai today, so the domain cut kills it unless this lands first.

    It extracts cleanly, measured rather than hoped. External dependencies only — react, next, jszip, @supabase/ssr, @resvg/resvg-js, node builtins. Nothing imports the corpus: no lib/content, no lib/baseline-*, no lib/foundation-*. lib/supabase-server.ts is one file with no internal imports and comes along whole.

    Two disk reads are the entire coupling, and they are different problems.

    • public/icon-picker/svgs/regular/*.svg, read at render time so @resvg/resvg-js can rasterise. Needed on disk — a URL will not do, which rules out the obvious "just point at the brand site".
    • data-products/iconography/allowlist.json — a corpus data-product, and the file card 58's review will change. This is the one that matters.

    So the picker becomes the fourth consumer of Brand OS and vendors both, through _packages/adapters/vendored-app/, which exists for exactly this: a provenance record with a sha256, a freshness check against the source's current version, and an expiry check that fails when a workaround's own condition stops being true. Two repos holding one allowlist with nothing comparing them is a failure this project has now found in several shapes; the adapter is the answer it already built. Rejected: fetching the allowlist at build or run time — it trades a checkable copy for a runtime dependency between two apps that fails silently when one is mid-deploy.

    The consequence worth having. With the picker gone, lib/supabase-server.ts and both @supabase/* packages leave this repo. Brand OS becomes entirely Supabase-free — seven files on 2026-09-09, four after the annotation retirement, zero after this. The boundary the corpus describes in prose becomes the boundary in the dependency list.

    Split of work. Torfinn: create the repo on code.aleris.ai (the name is a decision, not a default) and set up its domain. Claude: the move, the adapter wiring, the three migrations and the seed, a Dockerfile on the two-stage pattern from card 145, and a verification that the render endpoint still rasterises a real icon.

    Trap: the three migrations target the brand schema, and workspace/archive/rescued-from-backup-branches-2026-08-03/supabase/migrations/ holds two belonging to other products. A glob wide enough to catch the archive moves another product's schema into the new app.

    Related: cards 148 (the cutover this gates), 58 (whose review changes the vendored allowlist, and which is itself blocked on the dead Font Awesome token), 145, 105/144.

    Update 2026-09-10 — extracted, ported and pushed. code.aleris.ai/aleris/ikon at 56169d6.

    The move was the easy half and the measurement held: 22 files, ~2,105 lines, nothing importing the corpus. The port off Supabase was the real work. The whole data layer was one table and four operations — list, upsert on the convergence key, delete by id — now lib/db.ts over raw pg with forge's claim bridge, followed from FORGE.md rather than adapted. Auth reuses forge's own lib/oidc.mjs; only the wrapper is rewritten, because the scaffold wrapped it for a plain node:http server and this app is Next.

    RLS is now real, and that is the substantive change. The Supabase original carried four policies, every one using (true), under a comment admitting it: "internal tool behind a known URL with one writer. Anon read+write+update+delete acceptable for v1." RLS switched on and then opted out of — exactly what forced RLS exists to stop. db/001_icon_assignments.sql gates on the request claim, ENABLE + FORCE, single-tenant on controller: these rows are org-wide configuration, so an owner-per-row model would hide colleagues' work from each other for no reason (FORGE.md § What is controller?).

    Three things vendored with a sha256 each in brand/provenance.json: the 78-entry allowlist, the canonical token file (the CSS module references 71 of its variables — that dependency was not in the card's measurement and turned up on the first build), and the 3,772 SVGs. Plus the two Museo Sans faces.

    Verified by building the image and running it with no database, which is the state that matters: /health returns 503 naming what is missing while reporting icons: 3772; /qlik renders the catalogue and degrades to no assignments exactly as it did before; /login returns 503 naming the five variables it needs rather than a 500. Runs as node, 456 MB, no node_modules in the runtime stage. The app's own render tests pass, 7 of them.

    One bug found by running rather than reading: the fonts were mode 0600, copied from a working copy where the licensed files are restricted, so the container's node user got a 500 on them while an SVG from the same tree served fine. Local-only — git records 100644 and a Forge clone gets 0644 — and fixed anyway so both paths agree.

    What is left, and none of it is Claude's: apply the schema through the broker, supply FORGE_OIDC_CLIENT_ID and FORGE_OIDC_CLIENT_SECRET plus SESSION_SECRET, set the domain, deploy. aleris/brand keeps the picker source until step 5 — the cutover plan deletes the Next app last, deliberately, so there is something to compare against, and the picker is still serving users on the old host until the domain moves.

    A naming note, recorded not argued. ikon is Swedish and CONSTITUTION.md rule 7 keeps internal names English. Forge ties a repository name to a domain 1:1, so this name is also the address people type, and a domain has an audience — which is the same rule pointing the other way. Torfinn's call, made when creating the repo; it is in that repo's README so the next person meets the reasoning rather than the apparent inconsistency.

    Done when: the picker serves from its own Forge app on its own domain, renders an icon through @resvg/resvg-js, carries a provenance record for the allowlist and the icon set, grep -rl supabase lib app components in this repo returns nothing, and it is on main.

    ---

20. 145CCReady now

    Conform Brand OS to Forge — scoped to Astro, and the generated scan is wrong in two places — DONE 2026-09-10 (bar the console Deploy)

    Done when the Dockerfile serves site/dist statically on $PORT with a real /health, a Forge deploy goes live and serves the current corpus, FORGE-MIGRATION.md is regenerated or its two errors corrected in place with a note, and it is on main.

    Waits on Card 148 — the first deploy attempt was refused with a 409 domain conflict, and the override on offer would take the domain off a live icon-picker and 404 every /sv/ URL

    Detail

    Files: FORGE.md, FORGE-MIGRATION.md (Forge-generated, repo root) · Dockerfile · site/ and astro.config.mjs (what ships) · supabase/migrations/ (4 files, only if the icon-picker survives)

    New 2026-09-10, rescoped the same day by Torfinn's ruling: Astro wins, drop the Next work. The card opened asking which app Forge should conform. That question is answered, and answering it removed most of the card.

    What the move was. Forge forked aleris/brand from GitHub at 2a1110d, Mohan added FORGE.md and FORGE-MIGRATION.md, and the day's ruling pass merged across at a91c7fd. Trunk is code.aleris.ai/aleris/brand; GitHub is the github remote and is history.

    What the Astro ruling deletes from the checklist

    Measured 2026-09-10 against site/dist, not assumed. The Astro build already emits all 26 content routes (54 HTML files), llms.txt, foundation/raw/* and baseline/raw/*, and the 3,776 icon assets — so the machine-readable surface the README advertises is covered. site/src references Supabase, Resend and notify-comment nowhere.

    A static site needs none of what FORGE-MIGRATION.md spends four of its five steps on. Struck: step 2 (apply a schema through the broker), step 3 (the pg + withClaims seam, Authentik OIDC, the RPC and table-read ports), step 4 (re-key authz on forge). No database, no claim bridge, no forced RLS, no login — because nothing static reads a row.

    What is left, and it is step 1 plus a container

    • Bind 0.0.0.0 on $PORT, serve a real /health. The current Dockerfile runs a full Next.js Node server and its own header says why — dynamic routes, the cookie-based Supabase server client, filesystem reads, the native @resvg/resvg-js endpoint. Three of those four reasons go with the Next app. The Dockerfile is rewritten, not adjusted: a static file server over site/dist, which is also what makes the deploy cheap enough that card 113's freeze cannot repeat quietly.
    • Build-time env, and there is almost none left. The Font Awesome token and every NEXT_PUBLIC_* were build args on Coolify. The Astro build reads exactly one variable, SITE_URL, defaulting to brand.dev.aleris.ai in astro.config.mjs; set it in the Forge console when prod cuts over. The token is optional since card 147.
    • Deploy moves to the Forge console. Push, then press Deploy.

    The two errors in the generated scan, measured rather than suspected

    Both survive the rescope, because a regenerated scan will repeat them.

    • It reports Supabase: YES — 0 call site(s) across 0 file(s) and prints (none detected) under all four Replace-Supabase sub-steps. There are seven files, four importing directly, both packages in package.json. Under the Astro ruling this is no longer work to do — but the scan being wrong is still worth fixing, because the next app Forge onboards inherits the same blind spot.
    • It reports an own schema at db/ · migrations/ · schema.sql. db/ holds one JSON seed, migrations/ does not exist, and the four real migrations are in supabase/migrations/. Both errors point at supabase/, which the scan does not appear to read.

    A trap if the icon-picker does keep a database. workspace/archive/rescued-from-backup-branches-2026-08-03/supabase/migrations/ holds two migrations belonging to other products — crossborder and vårdförsäkring. Brand OS owns the brand schema only. A glob wide enough to catch the archive applies another product's schema to brand_dev.

    What does not come with the static site

    Two things, and neither is a consequence anyone chose — they fall out of the substrate. Card 146 carries the first; the second is scoped here.

    • The annotation and comments feature — card 146. Torfinn's, because it is a feature disappearing.
    • The Qlik icon-picker (/tools/icon-picker/qlik + three API routes). This is the backend island the corpus has named since the Phase C framing, and it genuinely needs Postgres and the native renderer. It is the one thing that would use a forge schema, a scoped role and withClaims. Not in this card's scope: conform the static site first, then decide whether the island is a second Forge app, a serverless function, or retired. /tools/icon-picker itself (the plain picker) reads no database and its assets already ship in the Astro build.

    Two loose ends from the move. GitHub holds six branches Forge does not — one fully merged and deletable, five backup/auto-*, two of which differ from trunk. Nothing lost, but stranded. And the pre-push harness did not travel: a fresh clone of the Forge repo has no hooks, so the gate that refused a push on 2026-09-09 does not exist there. Dev/_tools/guards/wiring.json is where it is version-controlled, and that is portfolio-level rather than this repo's.

    Related: cards 146 (comments), 113 (the deploy that had frozen; the Forge console is now the path), 99 (its phase 4 said sequence hosting after Phase C — Phase C is now decided).

    Done when: the Dockerfile serves site/dist statically on $PORT with a real /health, a Forge deploy goes live and serves the current corpus, FORGE-MIGRATION.md is regenerated or its two errors corrected in place with a note, and it is on main.

    ---

21. 143CCReady now

    Card 124's three Claude halves — the Tailwind sentence, the comment-density rule, and the cookbook entry

    Done when all three are written, the cookbook entry names its three instances and its detection, and it is on main.

    Detail

    Files: how-to/install-the-tokens.md · baseline/BASELINE.md § Serving this file · workspace/status/cookbook.md · reads workspace/evaluations/card-124-sundvikt-answers-reviewed-2026-09-10.md

    New 2026-09-10, from reviewing Sund vikt's answers. Card 124 assigned three of its five sections to Claude and they have no card of their own. None depends on Torfinn's §1 or §4 ruling.

    §2 · one sentence in how-to/install-the-tokens.md. The Tailwind v4 bridge is approved, documented in a BASELINE.md reference row, and does not exist as a package member. That silence produced two dead dependencies in a real consumer: tailwindcss and @tailwindcss/vite at ^4.3.3 are installed in sundviktlakemedel and the plugin runs on every build, with no @import "tailwindcss", no @theme block and not one utility class in the markup — verified 2026-09-10. The install page should say a consumer should not install Tailwind until the bridge ships. An installed-but-unused build plugin on a patient-facing product is a supply-chain surface, so the sentence is worth more than tidiness.

    §3 · the positive rule beside the serving rule. BASELINE.md § Serving this file argues weight and build safety, both defensive. The missing claim is positive: comment density in a design-system stylesheet is an asset, because the build removes it and the reasoning is what makes a rule survive its author. The worked proof is in the corpus already — the Museo Sans tabular-figures finding reached every consumer's instruction file because a comment recorded a measurement beside the code it governed. The risk is specific: a consumer hunting bytes, opening a file that is 67% prose, has an obvious first move that is also the worst one, and it nearly happened in sundviktlakemedel.

    §5 · one cookbook entry, covering three instances rather than one. A sweep built to catch "the list of eight" drift reported clean for a week while the drift was present, because its patterns needed an article the surviving phrase did not have. That is the same defect as _state.md's three same-day instances of a claim true of a narrower thing than it appeared to describe, and as board card 83's A/B/C absence claim, which searched three descriptive names while Baseline referred to the model by label. General form: a clean result is a fact about the query, never about the world. The detection is the cheap one and it is what makes this more than a slogan — when a check reports clean, plant the thing it is supposed to catch and confirm it fails. That is already the standing rule for new checks; what this adds is that it applies to existing checks reporting clean, which nobody does.

    Two more instances landed 2026-09-10, so the entry covers five rather than three, and both are worth naming because neither is a check — which widens the class. The branch-hygiene test went from failing to passing between two runs of the same commit, not because the stranded branch was dealt with but because the second run was in a clone whose remote had changed under it: the check reads its own origin, and origin moved from GitHub to Forge. And a grep across app lib components site/src reported the tree clean of a deleted import while hooks/useAuth.ts held one, because hooks/ is in none of the four paths — the build found it, the grep could not. So the general form should not say check: a clean result from any query — a grep, a test, a scan — is a fact about that query's reach. Forge's own FORGE-MIGRATION.md scan is a sixth instance from outside this repo, reporting zero Supabase call sites because it does not read supabase/.

    Trap: §2 and §3 are both one sentence in a publishing file, which is the size at which a card gets skipped and the sentence never written. They are on one card so the three land together.

    Related: cards 124 (the two halves that are Torfinn's), 119 (whether the bridge becomes a package member), 99 (the bridge is phase 0c of the starter-kit plan).

    Done when: all three are written, the cookbook entry names its three instances and its detection, and it is on main.

    ---

22. 142CCReady now

    The depends_on sweep card 136 authorised — 67 files, and DEPENDENCY_ALIASES retires with them

    Done when the 17 live corpus files declare real paths, the 50 deliberately-left files are declared with the reason, DEPENDENCY_ALIASES is empty or gone, a planted stale identifier fails a check, and it is on main.

    Detail

    Files: lib/content.ts (DEPENDENCY_ALIASES, 7 entries) · lib/baseline-content.ts (FOUNDATION_LINKS) · 67 files declaring a stale foundation/… identifier · documentation/site-map.md § Dependency model (the ruling)

    New 2026-09-10, from card 136's ruling: a depends_on identifier is a path. The Foundation essays moved to principles/ on 2026-09-07 and the identifiers other files declare for them did not; lib/content.ts has aliased the old names ever since so the links kept resolving. Under the ruling the aliases are a migration device, not a layer, so they come out.

    The scope, measured 2026-09-10 rather than estimated. 67 files carry at least one stale identifier: 17 live corpus, 16 _packages/ mirror, 3 _markets/sv/ archive, 31 workspace/, 0 in foundation/en-draft/. By identifier: constant-contextual 45, emotional-modes 29, colour 20, typography 12, imagery 11, iconography 3, logo-identity 0.

    Three traps, and the scope is not uniform. The _packages/ mirror is a generated view (ruled 2026-09-06) — sweeping it by hand puts the corpus and the generator out of step, so those 16 change by regenerating, at the next cut, not in this pass. The 3 _markets/sv/ files are archives now carrying status: superseded (card 95); an archive that has been edited is not an archive, so they stay stale on purpose and get declared rather than swept. And of the 31 in workspace/, dated records — decision records, briefs, changelog entries — state what was true when written and are not citations to keep live.

    So the real sweep is the 17 live corpus files, and the other 50 are a declaration of why they were left. Getting that split wrong in either direction is the failure this card is most likely to produce.

    The check that has to come with it, or the ruling is a preference: a stale depends_on should fail rather than silently alias. lib/in-repo-references.test.ts is the nearest existing shape and the natural home.

    Related: cards 136 (the ruling), 137 (the package rename, which must not collide with this), 132 (94 pointers to nowhere — same defect class, different field).

    Done when: the 17 live corpus files declare real paths, the 50 deliberately-left files are declared with the reason, DEPENDENCY_ALIASES is empty or gone, a planted stale identifier fails a check, and it is on main.

    ---

23. 141CCReady now

    An accepted constitutional page states a count that is wrong by fourteen

    Done when the count is current or the sentence is reworded to state a condition rather than a census, and it is on main.

    Detail

    Files: constitutional/language-policy.md § Detection of violation · foundation/en-draft/

    New 2026-09-09, found by the board PO pass while checking card 34.

    The page says "Sixteen en-draft/ pages currently carry the English source correctly; the three Baseline voice guides are the one known gap." foundation/en-draft/ holds two markdown files today (measured 2026-09-09) — the two voice files card 135 is about. The fourteen others moved into their tiers or were deleted as the English flip completed and Phase 0 ran.

    Why it is not just a stale number. The sentence is the page's own detection of violation, on a page that is accepted and therefore in force, and it publishes. A rule whose detection describes a directory that no longer exists in that shape cannot be run by someone who did not write it — which is the admission test the constitution sets for a rule existing at all. So this is a defect in an in-force rule, not a typo in prose.

    It is also the second instance of one shape, and the first is on this same board: card 34 was filed as work in progress while the work had been finished the day it opened. Both are a record describing a world that moved, on a surface nobody re-reads. The check that would catch this class does not exist — lib/in-repo-references.test.ts asserts that a cited path resolves, not that a stated count is current.

    Not corrected here. accepted pages are treated as immutable except corrections (CLAUDE.md § Status badges), and this one is a correction — but the sentence also carries the claim that the three voice guides are "the one known gap", which is a scope statement about the rule rather than an arithmetic slip. Claude can recount; whether the surrounding claim still holds is his.

    Done when: the count is current or the sentence is reworded to state a condition rather than a census, and it is on main.

    ---

24. 140TReady now

    Hard rule 3 is ruled per section and stated three different ways across nine places — ratify the wording, and define what a section is

    Done when section has a definition, the nine surfaces state one scope word, principles/colour.md's version question is answered, and the skill and the package copies are current.

    Waits on Card 23 — the adjacency invariant is the candidate definition, and per-section is unenforceable without one

    Detail

    Files: workspace/incoming/brief-hard-rule-3-per-section-2026-09-08.md (the inventory and the drafted wording) · principles/colour.md § the button rule (Foundation, accepted v1) · baseline/BASELINE.md hard rule 3 · schemas/design-token.md § Buttons · how-to/install-the-tokens.md · patterns/chat-bubble.md · patterns/hero.md · documentation/site-spec-v2.md · workspace/skills/aleris-design-system/SKILL.md · _markets/sv/foundation/colour.md

    New 2026-09-09, opened because the ruling had no card. Torfinn ruled per section on 2026-09-08 and the brief recording it sat in the drop zone with nothing on the board pointing at it — which is the one place a decision cannot be tracked from.

    What the corpus says now. Not one statement in nine places: three different scope words across the two tiers that have a declared precedence order. Foundation says per surface; Baseline says per screen in four places; the site spec says per page; and the Swedish Foundation page has said per sektion all along. BASELINE.md opens by saying Foundation takes precedence when the two conflict, so the corpus currently resolves to the word the ruling replaced.

    The wording is drafted and needs no writing — changed words only, the rest carried verbatim per the consolidation rule, for seven of the nine surfaces. Under CLAUDE.md § The content boundary a drafted rule sentence becomes his by ratification rather than by being written, so these are drafts until he says the words are his, on the pattern used for the two sentences ratified 2026-09-07.

    What actually blocks it, and why this is not clerical. Section has no boundary anywhere in the corpus, so per section is undecidable at a glance and unenforceable by a check. Card 23's adjacency invariant — never a filled orange beside a filled petrol — is the candidate definition, and the brief says so itself. Ratifying the wording first would put a decided-but-uncheckable rule into a Foundation page that is accepted v1, and then discover the term is still undefined. Card 23 is the root and the order is load-bearing.

    Why it is worth doing before the other sittings. One of the nine copies is workspace/skills/aleris-design-system/SKILL.md, which loads in every session and states the retired rule, so every build gets the old wording until this lands. Four consumers hold vendored copies, two of them in Swedish. And principles/colour.md is accepted v1, so changing it is a Foundation version question (documentation/versioning-rules.md), not an edit.

    Also worth knowing before he rules: the Swedish Foundation page is stale in the other direction — it still states "Ingen dark mode", retired on 2026-08-11 with a written reason. So principles/ and _markets/sv/ disagree in both directions at once and nothing compares them. That is the larger finding in the brief and it is card 57's neighbour, not this card's.

    Related: cards 23 (the definition, and the root), 119 (the cut that carries the six package copies), 121 and 123 (the two rulings that ride along), 57 (the Swedish page's opposite staleness).

    Done when: section has a definition, the nine surfaces state one scope word, principles/colour.md's version question is answered, and the skill and the package copies are current.

    ---

25. 135TReady now

    The voice essay — two documents, 256 lines and 145, that were never merged

    Done when one voice essay exists, the constitutional variant question is settled, and foundation/en-draft/ is empty and gone.

    Detail

    Files: foundation/en-draft/principles/voice.md (256 lines) · foundation/voice.md (145 lines, accepted) · foundation/en-draft/constitutional/voice-is-the-present-expert.md (96 lines) vs the live constitutional/ one (115) · workspace/authoring/voice-examples.md

    New 2026-09-06. This one is not the same as 133 and 134 — the essay exists. It is the last thing in foundation/en-draft/, and it is a merge rather than a move.

    What differs, measured 2026-09-06. The en-draft page frames each of the five principles as a question — "Is the patient the one acting, or the one things happen to?", "What does the reader need in the first three sentences?", "Whose purpose does this sentence serve?" — with the principle as the answer. The live page states them flat. Five sections exist only in en-draft: From patient information to patient guide, Across audiences, Across markets (culture and language), Anti-pattern (global), and Origin/Open/Related. Three exist only live: What the Present Expert is not, Quick reference, For AI systems. And principle 5 differs in substance — en-draft has "legal and contractual content earns its place only when it serves the patient", live has "the organisation's need for protection and the patient's need for information are not mixed."

    Why the question-form matters beyond style. documentation/site-map.md § "The core as a reasoning system" is the corpus's own argument for it: "questions generalise where answers don't." The en-draft page is that argument applied, and it is the only page in the corpus written that way. Whether the merged page keeps it is the substantive call here, not which sections survive.

    Also to settle: the en-draft constitutional voice page is a 96-line variant of the 115-line live one and nothing records which is newer. Compare before either is edited.

    Blocks: deleting foundation/en-draft/. It holds these two files and nothing else.

    Related: cards 133, 134, 55 (the "For AI systems" idiom rule, which exists only in the live page), 131.

    Done when: one voice essay exists, the constitutional variant question is settled, and foundation/en-draft/ is empty and gone.

    Found 2026-09-26 while drafting the website's Voice page, for the merge to settle. (1) Direct or inviting: foundation/voice.md gives "You need to fast" as the good, direct example, while baseline/voice/3-den-nara-experten-digital-rost-v2.md says interfaces invite and rejects "Du måste…". (2) Who the voice is for: the foundation page names patients, employees and partners; the constitutional rule adds next of kin, public servants and investors; the Swedish guides address the patient only. (3) Staff tools: no published source covers the voice of staff tools; the website's answer on it was dropped as a gap. The test wording and the fasting example in § For AI systems went to Torfinn in the same sitting.

26. 134TReady now

    The typography essay — same shape, and the smallest of the three

    Done when the layer question from card 133 is answered, and never-italics and rem-not-px are either placed or dropped on the record.

    Detail

    Files: constitutional/typography-is-museo-sans.md (promoted 2026-09-06, cites it five times) · foundation/typography.md (136 lines, accepted) · _markets/sv/foundation/typography.md

    New 2026-09-06. Same defect as card 133 and the least material: foundation/typography.md is 136 lines and already carries the scale, the two working weights, line spacing, and the hierarchy reasoning — everything the constitutional page sends a reader for. References redirected there 2026-09-06.

    The one thing specific to this element. The constitutional page's Open item 1 lists what the 2026-05-31 sort demoted to principles/typography.md: never-italics-for-emphasis, rem-not-px, keep-it-simple, the 8pt step, and the two-weight mapping. Those five rules were routed to a file that was never written. Three of them are in foundation/typography.md today (the 8pt step, the weight mapping, the scale as relative sizes) and two are not — never-italics and rem-not-px. So this card carries a real remainder rather than only an architecture question: two demoted rules have no home at all.

    Related: cards 133, 135, 93 (the en-dash convention, same class of craft rule with no home).

    Done when: the layer question from card 133 is answered, and never-italics and rem-not-px are either placed or dropped on the record.

    Update 2026-09-07 — the layer question is answered as in card 133; foundation/typography.md is principles/typography.md. The real remainder stays: never-italics-for-emphasis and rem-not-px still have no home. Also worth knowing before placing them: the constitutional page's Supersedes: line and every citation now read principles/typography.md.

27. 132T→CCReady now

    94 pointers to nowhere in what publishes and ships, and no check reads an in-repo path

    Done when the dual-context rule is stated, the check exists with its pinned counts, every remaining reference has taken one of the four routes, and it is on main.

    Detail

    Files: lib/external-references.test.ts (covers the other half) · constitutional/a-rule-is-applicable-where-it-is-read.md · baseline/BASELINE.md (7) · documentation/how-decisions-are-recorded.md (8) · constitutional/voice-is-the-present-expert.md (8) · documentation/aleris-meta-alignment.md (6) · foundation/en-draft/** (33) · _packages/agent-baseline/** (10)

    New 2026-09-06, measured rather than suspected. Opened after a session hit three dead pointers by accident in one afternoon.

    The measurement. 430 multi-segment in-repo paths are cited in rule surfaces — constitutional/, foundation/, baseline/, principles/, patterns/, schemas/, filters/, documentation/, qualities/ and the package. 94 do not resolve: 73 point at a file that exists somewhere else, 21 at nothing at all. Bare filenames used conversationally were excluded, and so was workspace/, which is working memory rather than a rule surface.

    One dissolved directory causes most of it. planning/ no longer exists. Its contents went to workspace/, documentation/ and workspace/archive/, and the pointers did not move: planning/aleris-design-system-open-questions.md, documentation/constitutional-core-test.md, planning/versioning-rules.md, planning/aleris-meta-alignment.md, planning/changelog.md, planning/f4-voice-briefing.md, planning/voice-filters-plan.md. A second cluster is principles/voice.md, principles/colour.md and principles/typography.md, cited from constitutional/ pages and now living at _markets/sv/foundation/ — so three constitutional pages point at Swedish archives.

    Ten of the 94 ship. _packages/agent-baseline/ carries dead pointers in BASELINE.md (4), MANIFEST.md (2), governance/aleris-design-governance.md (2), patterns/chat-response-simple.md (1) and foundation/imagery.md (1). A consumer or an agent following one gets nothing.

    A finding that fell out: foundation/en-draft/ is not empty. 33 of the 94 sit in en-draft/principles/, en-draft/constitutional/ and en-draft/viewports/. The 2026-08-27 record says "foundation/en-draft/ now holds no markdown at its root" — true, and the subdirectories were never mentioned. Third instance this month of a claim true of something narrower than it appeared to describe. Whether that tree is swept or deleted is a decision, not a fix.

    § references are NOT a problem and should not get a check. Of 16 file § Section references where the file resolves, 2 miss — and both are prose-shaped rather than real section names. Measured before proposing anything, so the sweep does not grow a second instrument it does not need.

    The check, and the constraint that shapes it

    lib/external-references.test.ts already asserts that a path pointing outside the repo is declared with a kind and a reason. Nothing asserts that a path pointing inside it resolves. That is the whole gap, and it is one function.

    Build it the way the hex check was built (lib/token-values-are-canonical.test.ts): pin the count per file, may go down, may never go up, no new file may join. 94 is a debt, not a permission, and a sweep lowers the numbers.

    The design constraint, and it is the interesting part. baseline/BASELINE.md and _packages/agent-baseline/BASELINE.md are the same content in two locations. tokens/aleris-tokens.css in it is correct read from the package root and wrong read from baseline/. So a naive resolver reports a real pointer as dead, and a resolver that tries every root reports a dead one as fine. This is constitutional/a-rule-is-applicable-where-it-is-read.md arriving as a mechanical problem: a file that ships in two contexts needs paths valid in both, or a line saying which context it is written for. Settle that before writing the resolver, or the check will be built around a workaround.

    Yours, three things. Whether en-draft/'s subdirectories are swept or deleted. What a constitutional/ page should point at when its target is now a Swedish archive in _markets/sv/ — the archive, the English replacement, or nothing. And the dual-context rule above, which decides the resolver.

    Related: cards 119 (the package copies are fixed by a cut, not by hand), 131, 88. constitutional/a-rule-is-applicable-where-it-is-read.md is the rule this serves from the inside.

    The remedy, sorted 2026-09-06 — and repointing is the wrong fix for most of them

    The decision rule already exists. constitutional/a-rule-is-applicable-where-it-is-read.md § Detection: delete the reference and re-read the sentence. Still applicable → attribution, keep it. The reader now has to go somewhere → dependency, absorb the content and then attribute. Written for paths pointing outside the repo; it decides all 94 unchanged. The question was never what path a reference becomes — it is whether the sentence is still true without it.

    Why a script cannot do this. Of the 16 references with exactly one candidate target, eleven resolve into workspace/, which does not publish. Repointing them makes the path valid and leaves the reader of a published page unable to follow it — card 86's shape, arrived at by fixing something.

    Done 2026-09-06: 12 repointed, only where the target publishes, ships, or is on the named-file allowlist. planning/aleris-meta-alignment.md and planning/versioning-rules.md → documentation/; foundation/en-draft/{voice,colour,typography}.md → the flipped foundation/ pages; governance/4-den-nara-… → its full path from root (×2); reference/aleris-baseline-images.md → baseline/reference/; planning/changelog.md → workspace/status/changelog.md (×2, allowlisted); /icon-picker/… → public/.

    Around 8 of the 94 are not defects, and the check must not report them.

    • baseline/setup.md's src/styles/aleris-tokens.css (×2) is an instruction to create a file, not a reference to one — "write it into the project as…". A resolver that reads it as a citation is wrong about the sentence.
    • baseline/BASELINE.md's tokens/… and logo/README.md are dual-context: correct read from the package root, wrong read from baseline/. Settle the context rule before the resolver, per above.

    The rest sort into four routes. Full list with each sentence quoted was produced 2026-09-06 and is reproducible by re-running the scan.

    • Attribution — delete the path, keep the sentence (~11). Historical provenance: supersede records naming where a file used to live (aleris-design-tokens.md, baseline-token-architecture.md, the en-draft accessibility draft), workstream credits (planning/f4-voice-briefing.md, planning/voice-filters-plan.md), and a citation of _state.md by its old repo name. The sentence carries its meaning without the path.
    • Declare as external (~4). patientguide/frame/lib/css.js, sundviktlakemedel/BRAND-OS-FINDINGS.md, and 2-areas/collaboration/swedish-language-rules.md — the last being a TAKS path written without its prefix, so external-references.test.ts's regex cannot see it and the in-repo resolver cannot either. A reference falling between two checks. Widen that regex as part of this.
    • Dependency — absorb or move (~5). constitutional/voice-is-the-present-expert.md and principles/_index.md both send the reader to principles/voice.md, which does not exist; and constitutional/voice-is-the-present-expert.md rests its non-negotiables on a sort in documentation/constitutional-core-test.md, now in workspace/research/ and unreachable from a published page. These are the consequential ones — two accepted constitutional pages leaning on material a reader cannot get to.
    • Never written (~4). documentation/aleris-meta-alignment.md cites constitutional/brand-os-is-canonical.md, patterns/canonical-component-as-peer.md, patterns/diataxis-documentation.md and components/aleris-svar.md. Either aleris-meta is a separate repo and these are external, or they were planned and never written. Settle which before touching them.

    Yours, six calls. Is foundation/voice.md what principles/voice.md should have said (×2)? Does the constitutional-core-test move somewhere reachable, or does the sort get absorbed into the page? Are the aleris-meta pages external or vapour? Does en-draft/ go? And the dual-context rule.

    Done when: the dual-context rule is stated, the check exists with its pinned counts, every remaining reference has taken one of the four routes, and it is on main.

    Update 2026-09-07 — the check exists; the sweep does not. lib/in-repo-references.test.ts and scripts/in-repo-references.mjs --list, landed with Phase 0 revised step 2. The dual-context constraint is settled in the check's header: a reference resolves in any context the file is actually read in — the repo root, its own folder, and the package root for a file inside _packages/agent-baseline/ or for the canonical copy of a file the package ships (looked up through _packages/agent-baseline.map.mjs). Not "try every root". Pinned at landing: 555 references, 81 unresolved in 21 files — this card counted 94 in 28 with a narrower scan, and five citations left behind by the 2026-09-06 move were repointed before pinning. Counts may fall and never rise; three path-shaped strings are declared as not citations (src/styles/aleris-tokens.css, React/Next.js, decided/considered/suggested). Of the 81: 28 in foundation/en-draft/ (yours — sweep or delete), 13 in the package (card 119), 8 in aleris-meta-alignment.md (vapour or external, yours), the rest sort into the four routes above. Done when clauses one and two are met; three and four remain.

28. 130CCReady now

    review/ has never been pointed at an Aleris consumer

    Done when both targets are declared, node review/run.mjs --self-test passes, both report with landing routes recorded, and it is on main.

    Waits on Two decisions, named 2026-09-09 while doing the seam cluster. (1) Where a review runs — a deployed URL, a local dev server, or a container as gcc used. The card's own trap says settle this before writing the config, and it is unsettled; both products are patient-facing, so it is not Claude's to pick. (2) The target-size floor per viewport, with its reason — with no declaration the strict 44 stands, and a patient-facing product should be arguing for 44 rather than inheriting 24 by silence. Claude's half is the target files and the run, and it is one sitting once (1) is answered

    Detail

    Files: review/targets/gcc.json, review/targets/claude-design-kits.json (the two that exist) · review/README.md § "Targets are declared here, not in the reviewed repo" and § "Contextual floors are declared, not guessed"

    New 2026-09-06, from the shipping-checks decision. The enforcement tier the decision leans on, unused on the two products that vendor the package.

    The gap. review/ has reviewed gcc — a repo Torfinn does not own — "without a byte changing in it", and the Claude Design kits. It has never been run against sundviktlakemedel or patientguide, which are the two consumers whose findings drive the package. The rendered tier is where the failures actually live: 37.8×37.8px targets where the static read predicted ~45, a 12px span with no size class of its own, and the 404 page nobody greps for.

    The build. A target file each: base URL, route sample, viewports, and the target-size floor declared with its reason per viewport — with no declaration the strict 44 stands, and a patient-facing product should be arguing for 44 rather than inheriting 24 by silence.

    Trap: each needs a running instance, and where it runs is not settled — a deployed URL, a local dev server, or a container as gcc used. Settle that before writing the config. And an empty page is a failure, never a pass: a route that redirected to login has not been reviewed and the report must say so on that row.

    Related: cards 121 (the gradient probe belongs with these), 104, 105.

    Done when: both targets are declared, node review/run.mjs --self-test passes, both report with landing routes recorded, and it is on main.

29. 126TReady now

    Voice findings — wanted or not, by what route, at what evidence bar

    Done when the assistant's findings file names one route rather than two, and the bar is written where findings are filed, and it is on main.

    Detail

    Files: workspace/incoming/brief-aleris-assistant-copy-consumers-and-voice-2026-09-04.md § 2 · ~/Dev/aleris-assistant/BRAND-OS-FINDINGS.md (both candidate routes written in, 2026-08-25, card 81) · foundation/voice.md

    New 2026-09-05, from the incoming triage § 2. Card 81 closed with this question left open on purpose; nothing has moved since.

    The gap. Tokens, components and hard rules have had two vendored consumers reporting against them for months. Voice — register, how the brand behaves across a turn — has had none, and the one repo whose brand surface is almost entirely voice has been silent by construction. Its own file names the cases the others cannot meet: the same question asked three ways, a disclosure the assistant must not act on, a register right at turn one and wrong by turn six.

    Yours, three things: whether Brand OS wants voice findings at all; the route — direct into workspace/incoming/ like the others, or through TAKS first, given the risk the consumer names itself (voice material arriving where the voice's author also writes it, with no strategic pass); and the evidence bar — one awkward reply is an anecdote, the same awkwardness across an eval run is a finding, and the route should say which it accepts.

    Related: cards 81, 82, 78 (moments — a register shifting across a conversation is one).

    Done when: the assistant's findings file names one route rather than two, and the bar is written where findings are filed, and it is on main.

30. 124TReady now

    The serving rule forbids subsetting by its letter, and the flip condition has no card

    Done when the serving rule says which way on subsetting, the flip condition is written somewhere the consumer can point at, and both are on main.

    Detail

    Files: workspace/incoming/brief-sundvikt-css-weight-and-the-flip-2026-09-02.md (the brief) · baseline/BASELINE.md § Serving this file ("remove the comments and the blank runs they leave behind, and nothing else") · baseline/setup.md step 1c · workspace/evaluations/sundvikt-component-library-candidacy-2026-08-28.md

    New 2026-09-05, from the incoming triage § 5.

    §1, corrected. The brief says declaration dropping is "not mentioned either way". The serving rule's "and nothing else" forbids it. A consumer measured what it costs: 199 of 363 vendored tokens unreferenced, 1,080 brotli bytes on each stylesheet, and a console budget headroom of 120 bytes that subsetting would make 1,200. Yours: widen the rule to sanction build-time subsetting with the sha256 governing the vendored source rather than the served artefact, with the warning that a second consumer of the same file (Storybook) can legitimately reference what the app does not — or keep the rule and say the byte cost is accepted.

    §2 folds into card 119. The bridge exists and is fetchable by URL per setup.md step 1c; the open half is only whether it becomes a package member at the next cut.

    §3 is Claude's: one sentence beside the serving rule for whoever is hunting bytes — the build removes the comments, do not.

    §4 is the card the brief asked for. Torfinn, 2026-09-02: the consumer is "both until we decide to flip". The conditions under which it stops being a source and becomes a consumer are unwritten; the brief's starting list is the component set holding its sort twice, Swedish out of the core, both halves of the testing story in one repo, and §1 answered. Yours to word.

    §5 is a cookbook line, Claude's: a clean report from a guard written for one drift shape is not evidence the drift did not happen; _state.md records the same shape three times as a query defect.

    Done when: the serving rule says which way on subsetting, the flip condition is written somewhere the consumer can point at, and both are on main.

    ---

31. 123T→CCReady now

    Seven findings from the Sund vikt component library still open — three pattern pages, a selected state, a compact button

    Done when the three pattern pages exist at proposed or better, findings 6 and 4 have a ruling, the four mechanical items are landed (done 2026-09-08), and it is on main.

    Detail

    Files: workspace/incoming/brief-sundvikt-design-system-findings-2026-08-27.md (twelve findings; 5 and 9 shipped in v0.11, verified) · patterns/ (seven files, no row, no chooser, no action cluster) · data-products/tokens/aleris-tokens.css § Buttons, § Tab Navigation · _packages/agent-baseline/logo/README.md · schemas/icon-allowlist-entry.md · baseline/setup.md

    New 2026-09-05, from the incoming triage § 6.

    Yours (findings 1, 2, 3, 4, 6, 12): pattern pages for the row, the chooser (segmented / tabs / toggle — Baseline has --tab-* tokens and no page) and the floating action cluster, including what may hide behind one and the finding that a menu hiding decline routes makes every decline one step dearer; a checkable gradient rule to replace "sparingly" (the Claude Design card's "Background surfaces only. Max two steps, low contrast, never in charts" is a candidate); and whether buttons get a selected state as a tint plus marker. The consumer's Row.tsx and its grounds stories are the specimens. The fixed Claude Design system ships Switch, Radio, Checkbox and SideNav, no tabs, segmented or row — it did not fill this.

    Claude's (7, 8, 10, 11): the --button-min-height-pointer note saying it is a floor with no pointer padding beside it — done 2026-09-05; a setup.md sentence that local additions load in a project layer after the vendored file, never appended to it; an icon rendering contract as utility text beside the allowlist schema, measured from the extracted 512-grid set; and logo/constants.json read by lib/logo-minimum.test.ts so the ratio, minimum and clear-space multiple stop being numbers copied into consumer tests. A compact padding value is yours if 7 is answered that way.

    Progress 2026-09-08 — findings 8, 10 and 11 closed; all four of Claude's mechanical items are now landed. Finding 8: the two sentences are on how-to/install-the-tokens.md (the file setup.md became), and the rule is a second file loaded after rather than an append, because appending destroys the byte comparison that is the only way a consumer learns the tokens moved. Finding 11: _packages/agent-baseline/logo/constants.json ships the geometry, the sizing rules and the derivation inputs, each with usage, constraint and provenance; lib/logo-minimum.test.ts reads the type floor and cap-height assumption from it and adds four assertions pinning the file to the rendered SVG and to the README prose, so the JSON, the prose and the drawing are one knot and none can move alone. Five mutations, five failures. The favicon's expiry is deliberately still absent — that is card 111 Q2 and stating one here would answer it by accident. Finding 10: schemas/icon-render-contract.md, draft/prep, with lib/icon-render-contract.test.ts asserting every stated number. One correction to this card's own wording, and it is the substance of finding 10. This card and the triage both described the extracted set as 512-grid. Measured: the viewBox is 512 units tall and its width takes ten distinct values from 64 to 640. A component that hard-codes viewBox="0 0 512 512" therefore distorts 2,406 of the 3,772 icons, and the icons that render correctly are the plurality — which is exactly why two independent handoff authors could each build a contract and neither notice. The contract's operative sentence is read the viewBox, never write one, and it would not have been written from the description this card carried.

    Related: cards 98 (eight missing patterns is one missing component layer), 99, 121.

    Done when: the three pattern pages exist at proposed or better, findings 6 and 4 have a ruling, the four mechanical items are landed (done 2026-09-08), and it is on main.

    ---

32. 122TReady now

    Third parties on an Aleris surface, and onboarding is not a mode

    Done when BASELINE.md no longer lists onboarding as a mode, governance carries a third-party section, and both are on main.

    Detail

    Files: workspace/incoming/brief-sundvikt-rails-and-allowlist-2026-09-01.md (the brief) · baseline/BASELINE.md § Surface temperature (line listing "onboarding" under communicative) · baseline/governance/aleris-design-governance.md § 3 · workspace/authoring/aleris-patient-product-design-guidelines.md § 4.2 (the "we/you" rule, unpublished)

    New 2026-09-05, from the incoming triage § 8.

    Corrected framing. The brief read the onboarding conflict as BASELINE.md against the governance file. Both say onboarding is communicative; the governance file says so in as many words. The conflict is inside the governance file, between "an onboarding flow is communicative throughout" and "a patient managing their treatment plan is in instrumental mode", for the case of a treatment onboarding — which is what the consumer has. Since a flow owns its mode, the wrong call propagates to every step.

    Three rules confirmed absent — no text in foundation/, baseline/, constitutional/, patterns/ or principles/ mentions BankID, Swish or a mark Aleris does not own; the motion rules cover loading and stop before a hand-off wait the patient controls and may not return from; and the pronoun rule the brief cites is in an unpublished authoring file, so the third-actor gap is inside a document that has not entered the corpus. All three appear the moment a patient touches something that is not Aleris, and the axis paper's principle — a system should state where it does not extend — is the frame.

    Yours: strike "onboarding" from the communicative list and say what separates marketing onboarding from treatment onboarding; one governance section for the mandated third-party mark, the hand-off waiting state, and how a sentence places a third actor. Prose throughout.

    Related: card 58 (the payment icon the same flow needs), workspace/research/axis-thinking-in-design-systems.md.

    Done when: BASELINE.md no longer lists onboarding as a mode, governance carries a third-party section, and both are on main.

    ---

33. 121T→CCReady now

    Controls on a branded ground — five of six variants undefined, and no check can see a gradient

    Done when BASELINE.md states which controls may sit on a branded ground, the tokens match the statement, a check can measure text over a gradient, and it is on main.

    Waits on Claude's measurement first: white ghost text against the petrol gradient's light stop, so the ruling carries a number rather than a preference

    Detail

    Files: workspace/incoming/brief-sundvikt-grounds-matrix-2026-09-03.md (the brief) · data-products/tokens/aleris-tokens.css § Buttons (--button-primary-inverse-* is the only inverse family) · review/checks/ (three checks, none reads background-image) · ~/Downloads/Aleris Design System (fixed)/components/core/Button.jsx (FILLS_ON_DARK)

    New 2026-09-05, from the incoming triage (workspace/evaluations/incoming-triage-2026-09-05.md § 7).

    THE GROUND NOW EXISTS, AND MEASURING IT AGAINST THE REAL DESIGN FOUND A LIVE AA FAILURE — 2026-09-13, card 156. --surface-gradient-cold and --surface-gradient-warm landed, the first gradients this token set has ever carried. Then the design system's own painting was served and driven in a browser rather than read, and it settles two things this card was guessing at.

    It is not a hypothetical ground: the painting uses the cold gradient eleven times, and its computed value is byte-identical to the token — linear-gradient(135deg, rgb(0,72,81) 0%, rgb(79,134,142) 100%).

    And it puts body text directly on it. Measured from the rendered page, not inferred:

    Text the painting places on it	on petrol-500	on petrol-400	floor
    white 16px w500 body	10.27:1	4.09:1	4.5:1	fails at the far stop
    petrol-100 14px w500	7.73:1	3.08:1	4.5:1	fails at the far stop
    white 18px w700 heading	10.27:1	4.09:1	3:1	passes throughout

    So a white heading that starts legible ends illegible along its own background, and the 14px secondary line is worse. This is the same defect this card was opened on — a live action shipped invisible on five of seven seeded home screens — reappearing as text rather than as a control, and it is now measured rather than suspected. sundviktlakemedel/docs/PLAN-DESIGN-SYSTEM-ADOPTION.md § 9 predicted precisely this before the token existed: "that is a floor, not a preference, and it is the one disagreement where adopting the design system's value is not available."

    RULED AND FIXED the same day: retune the far stop so white holds. --surface-gradient-cold now runs petrol-500 → --color-petrol-450, a new primitive at #437d85, where white is 4.66:1 — clearing the floor with headroom on both stops rather than landing on it. The exact 4.5:1 crossing is #467f87 and was deliberately not taken: a value sitting on a floor fails the next time anything nudges it. The new stop is 0.85 of the way along the old interpolation and 12/9/9 in RGB from petrol-400, so the gradient keeps its appearance — the fix is invisible, which is the point. The 450 step is where the existing 100/200/300/400/500/700 numbering puts it.

    Still not safe, and stated rather than smoothed over: petrol-100 is 3.51:1 on the new far stop, so the painting's 14px secondary line in that colour still fails on this ground and needs white or a card. Retuning white's floor did not fix a second text colour, and saying it had would be the kind of claim this card exists to catch.

    The warm ground stays dark-text-only — white is 2.38:1 at its near stop and 1.60:1 at its far one, nowhere near any floor at either end.

    And this card's standing complaint is answered in one narrow place: lib/gradient-contrast.test.ts is a check that can see a gradient. It parses the gradient tokens, resolves each stop through the primitives, and measures the permitted text against every stop rather than the one a reader would think of — because a gradient fails where it is lightest, which is the end nobody checks. Proved against the defect it was written for: putting the far stop back to petrol-400 fires it with #4f868e 4.09:1 (floor 4.5). The warm ground is asserted as a negative, so if anyone ever retunes it far enough for white to pass, the check fails and asks them to grant that permission deliberately instead of inheriting it. What it still cannot do is know which text colours a product actually places on a ground — that is markup, and it remains this card's.

    One thing measuring the painting settled for free, and it validates the border ruling. The painting borders with #d7d2cb — gray-100, the warm neutral — while the export's own tokens/colors.css declares --border-default: var(--petrol-200). The export's tokens and the export's paintings disagree with each other, and Torfinn's "neutral (warm grey)" ruling on card 156 matches what he actually designed rather than what the token file claims.

    The gap. The button vocabulary is indexed by emphasis and the system has more than one ground. The consumer measured all 24 variant × ground cells: on a petrol ground, outline and ghost sit at 1.00:1 (not there), secondary and complete fill at 1.00:1 against the ground (found, unreadable as a control), and only inverse has tokens. A live action shipped invisible on five of seven seeded home screens.

    A position already exists outside Baseline. The Claude Design system's Button defines onDark for all four of its variants: secondary becomes a white outline, outline and ghost go white, all three press to a translucent white. That is three controls on a branded ground, which argues against the brief's one-line rule (inverse only). Torfinn built one and has not ruled on the other.

    Yours: ratify or reject the on-dark answer — inverse only, or the transparent variants inverted. Claude's, first: measure white ghost text against the petrol gradient's light stop (petrol-400 #4F868E) before the ruling, so it is a verdict with a number. Claude's, after: the tokens if the answer is "inverted", and a gradient-aware contrast probe in review/ — sample the stops or rasterise and take the worst pixel behind each glyph — because any check walking computed backgroundColor reports the page behind a gradient and passes it. axe-core returns incomplete on the same case.

    Related: cards 118 (error text's grounds, same shape one token over), 120 (the other two-axis defect), 123.

    Done when: BASELINE.md states which controls may sit on a branded ground, the tokens match the statement, a check can measure text over a gradient, and it is on main.

    ---

34. 120TReady now

    Baseline has layout numbers and no layout behaviour — the column ladder for both surfaces is undecided

    Done when the ladder is decided (done); the layout section is rewritten with a first line in plain words and an F6-shaped parent; width classes and rem breakpoints exist with reasons; svl's three phone rules are in patterns/; the reflow check runs (done); the specimens exist (done); the svl measure finding has been sent back (done); and it is on main.

    Detail

    Files: workspace/research/layout-and-responsiveness-2026-09-04.md (the brief) · baseline/reference/aleris-grids-tables-dataviz.md § Part 1 · data-products/tokens/aleris-tokens.css § Layout Grid, § Breakpoints · sundviktlakemedel/src/brand/brand.css and src/styles/responsive.test.ts (the only solved instance)

    New 2026-09-04, from the Claude Design audit's reflow finding and the research that followed it.

    The gap, in one sentence. Baseline states a 12-column grid, two max-widths, four breakpoints and "use container queries" — and nowhere says what any of it does when the screen narrows. Nothing states that columns stack, when, or in what order. The breakpoints are Tailwind's defaults exactly, in px, admitted in the token comment as "not derived from the modular scale", and consumed by nothing in this repo. "Component swap at breakpoints" is a heading whose body is the z-index ladder. F6 does not cover space, so the surface-temperature layout rules have no reasoning parent.

    Five builds, five answers, none from Baseline. sundviktlakemedel is the one real responsive story in the portfolio — a one-column measure that grows via clamp() anchored to --breakpoint-sm/md, rem breakpoints for text-zoom, three phone stacking rules, spacing that steps with width, all tested — and Torfinn decided its key call (one growing column, not two) on 2026-09-02. It lives in one product's CSS. Same shape as the row primitive: solved downstream, absent upstream.

    What seven other systems agree on (GOV.UK, NHS, USWDS, Carbon, Atlassian, Polaris, Material 3 — sources in the brief): the column count is not constant across widths; mobile is one column and columns are opted into; reading width is a stated measure in characters, not a column span; two container widths for two content kinds is the norm (the part Baseline has right); classify by window not device, with media queries for the page and container queries for components.

    The decision that is yours: the column ladder for both surfaces. Communicative: is "grow the one column" at ≥1024 a Baseline rule, or was it a product choice for a one-job screen? Instrumental: what does a 12-column work surface become on a phone — the console had to invent "three things must work" alone. Same session shape as the radius decision (cards 44/45): candidates rendered side by side from the real token file, picked by looking. The Storybook seed (card 99) and this exploration are one piece of work from two ends.

    Two prerequisites are [CC] and cost no decision: measure Museo Sans ch at each type size so a measure token can be honest (svl found 10px at 18px; the Claude Design system ships 68ch unmeasured); and a reflow check in review/ at 320 CSS px across every target, which is Baseline's own button rule generalised and would have caught every Claude Design kit.

    Prerequisites done 2026-09-04, same day. review/checks/reflow.mjs exists, discriminates in self-test, and ran against the Claude Design kits: 6 of 15 route-viewport pairs fail, every offender a nowrap flex row or a fixed-column grid — the two shapes the 2026-08-12 button entry already names. Museo Sans ch measured from the licensed woff2: exactly 0.5em at both weights (9px at 18px), and real Swedish body averages 0.81 of a ch, so a ch measure overstates by a quarter — 68ch holds 84 characters, not 68. tokens.test.ts now asserts every width media query under site/ and app/ equals a declared breakpoint (generalised from svl's test; mutation-verified). Numbers and tables in the brief § 6a.

    A finding against a consumer's record, named and left. sundviktlakemedel/src/brand/brand.css states 1ch = 10px and 64 / 77 characters per line at 640 / 768px; measured, it is 9px and 87 / 105. Its "a cap would bite nothing" conclusion rests on the wrong figures — at 105 characters the column is thirty past the 45–75 guideline. Read-only to Brand OS (constitution rule 5); routes back through the findings path, and it bears directly on the communicative half of this card: 75 characters of 18px Museo Sans is ~548px, so Baseline's "6–8 of 12 columns" (600–800px) is 82–109 characters and was never a readable-measure proxy.

    Specimens built 2026-09-04: baseline/conformance/layout/index.html. The decision surface, same shape as ../radius/: three candidate ladders per surface, each rendered as specimen.html in an iframe at exactly 320 / 390 / 640 / 768 / 1024 / 1280 / 1440, from the real token file and the licensed Museo Sans. Every frame reports its own column width, characters per line at 18px body (measured average 7.31px, not ch), columns in use and whether it scrolls sideways. Content is not written for the page — the accepted hero pattern, copy Torfinn authored in the Claude Design kit, and svl's console rows. Not wired into the route manifest. Two defects in the page itself were found on its first look and fixed: the iframe's 1px borders sat inside the declared width, so every frame ran 2px narrow and the 640 frame fell on the wrong side of --breakpoint-sm; and the hidden surface was display:none, so its frames laid out at no width and the table showed a column of zeros that looked like a result.

    What the frames report (column px · characters per line at 18px), none of the 42 frames scrolling sideways:

    Surface	Model	320	390	640	768	1024	1280	1440
    Communicative	A grow the one column	288 · 39	358 · 49	608 · 83	640 · 88	704 · 96	768 · 105	768 · 105
    Communicative	B capped at a measure	288 · 39	358 · 49	548 · 75	548 · 75	548 · 75	548 · 75	548 · 75
    Communicative	C two columns from wide	288 · 39	358 · 49	548 · 75	548 · 75	527 · 72 · 2 sp	548 · 75 · 2 sp	548 · 75 · 2 sp
    Instrumental	A 12 → 6 → 1	1-up	1-up	2-up	2-up	4-up	4-up	4-up
    Instrumental	B 12 → 1	1-up, nav stacked	1-up, nav stacked	1-up, nav stacked	4-up	4-up	4-up	4-up
    Instrumental	C fluid auto-fit	1-up	1-up	2-up	3-up	4-up	5-up	5-up

    Three things the numbers say before anyone looks. Model A's column is past the 45–75 guideline from 640px up and reaches 105 at 1280 — the svl ladder, measured against the real face, is a wide measure at every desktop width. Model B holds 75 at every width from 640 and the ground takes the rest; whether that reads as calm or as wasted space is the thing to look at. Instrumental C, with four tiles, lands on five columns at 1280 and 1440 — a row with an empty fifth slot — which is what "the count falls out of arithmetic" looks like in practice, and the argument against it.

    DECIDED 2026-09-05 (Torfinn, from the specimens): communicative A, instrumental C. Communicative: one column that grows — svl's clamp, promoted — with no measure cap, chosen knowing it holds 88 characters at 768 and 105 at 1280; recorded on the token as a deliberate departure from the 45–75 guideline so the next reader does not take the width for an oversight. Instrumental: fluid auto-fit on 14rem tiles, no breakpoints, chosen knowing four tiles land on five columns from 1280 up. Landed: --grid-column-communicative and --grid-tile-min-instrumental in aleris-tokens.css with the numbers in their annotations; BASELINE.md § Surface temperature supersedes "6–8 of 12 columns"; the grids reference gains the decision section; the decision surface is marked decided; tokens.test.ts holds the clamp's anchors to --breakpoint-sm/md, renders the ladder at the seven widths and asserts the counts (five at 1280 included), and requires the departure to be stated on the token — mutation-verified. Sent back: the svl measure finding, dropped in sundviktlakemedel/_incoming/.

    Handed to TAKS 2026-09-05: ~/TAKS/1-projects/brandguide/_filedrop/brief-card-120-layout-prose-and-patterns-2026-09-05.md carries the three open pieces below with the settled decisions marked do-not-reopen, the evidence pointers, and the return path (a brief back into workspace/incoming/). Logged in that initiative's _state.md.

    Still open on this card, all Torfinn's prose or wording: the Part 1 rewrite with a plain first line and an F6-shaped reasoning parent; svl's three phone rules as patterns/ pages (CC can draft, T words); rem breakpoints and width-class names with reasons (recommendation 1 and 4 — the decision above did not settle them).

    Done when: the ladder is decided (done); the layout section is rewritten with a first line in plain words and an F6-shaped parent; width classes and rem breakpoints exist with reasons; svl's three phone rules are in patterns/; the reflow check runs (done); the specimens exist (done); the svl measure finding has been sent back (done); and it is on main.

    ---

35. 119CCReady now

    The token file moved and the package mirror did not — first value drift since v0.6.3

    Done when the cut is made with a version call recorded in MANIFEST.md, patientguide's print rule is fixed before its copy moves, the three consumer records re-vendored and each repo's own brand-provenance.mjs run clean, an undeclared-lag check exists or its absence is recorded with a reason, and it is on main.

    Waits on Cut made 2026-09-09. Sixteen of thirty mirrored files changed, fourteen byte-identical to v0.11, verified by the cut script re-reading every destination. The version call is drafted with its reasoning in MANIFEST.md — a whole version, and not close: two tokens added, one retired, one value changed, plus substantial new Baseline content. Revendor, not repin — the first since v0.6.3. The lag gap the card opened is closed by lib/package-lag.test.ts (mutation-verified three ways); run before the cut it reported sixteen undeclared files, both token files among them. Manifest source column rebuilt from the generator map, its pointer debt recomposed 5 → 3 → 5 and the composition recorded. What remains, and why it stopped here: all three consumers are on the no-go list, so re-vendoring is prepared to the gate and left there — _packages/adapters/vendored-app/REVENDOR-v0.12.md carries the per-consumer instructions, the grep that has to run before any copy, and the failure mode (a dangling var() inherits rather than erroring, so there is no build warning). One correction to this card, measured rather than assumed: its blocking prerequisite is mis-diagnosed. It said re-vendoring would make patientguide's print rule a dangling var() on patient-facing printed documents. It will not — that file declares the token itself and is verbatim: false in the provenance record, a hand-maintained mirror rather than a byte copy, so it stays internally consistent. The real consequence is divergence: the byte copy beside it takes petrol-400 while the mirror keeps orange-500, so one patient-facing repo would hold two answers about the same token, and nothing compares them. Two further uses the card does not mention were found; the local --color-text-muted alias is declared once and used nowhere. Also honest about a gap in the hand-off: sundviktlakemedel has not been surveyed for the retired token. Stated in the note rather than glossed. And aleris-vibe-coding is still at v0.6.5 on an unmerged branch, so the count is three consumers behind on v0.12 plus one that never took v0.7. Yours: whether the drafted version call stands (revising it to a point release is one edit in two files), and the three re-vendors — each one a change to a repo on the no-go list. 426 tests green in 21 files.

    Detail

    Files: _packages/agent-baseline/tokens/aleris-tokens.css and baseline-tokens.json · _packages/cut-agent-baseline.mjs · _packages/README.md § version table · consumer brand-provenance.json records

    New 2026-09-04. --text-accent changed value in canonical (card 115's amendment above). The package mirror was byte-identical to canonical before that and is now behind it.

    This is the fan-out kind that costs the most, and it has not happened since v0.6.3. Every cut from v0.7 to v0.11 was recorded as "No token file touched, so a consumer's vendored-value hash does not move and no revendoring is required — only the pinned version". That sentence is now false for the next cut: a token value moved, so patientguide, sundviktlakemedel and aleris-assistant re-vendor rather than repin.

    Not synced in the change that caused it, and that is the rule rather than an oversight. _packages/README.md rule 1: "Packages are generated, never edited. A hand-edited package is drift by definition." And MANIFEST.md on the cut script: "It does not choose a version, write this section, or update the version table — those carry the reasoning and the rule-6 judgement, and neither is mechanical." A repin is [CC]; the version call is not.

    A gap this exposes, worth deciding inside the card. Nothing in the repo reports that the mirror is behind canonical. Grepped: no test, no script, no check reads _packages/agent-baseline/tokens/ and compares it. The mirror is a pinned snapshot, so asserting identity would be wrong — it is allowed to lag. What is missing is an assertion that the lag is declared: that when the two differ, _packages/README.md's version table says so. Same shape as branch-hygiene.test.ts failing on a branch ahead of main and undeclared, which is the pattern to copy rather than invent.

    A blocking prerequisite, added 2026-09-04 with card 115. --text-tertiary was retired from canonical. patientguide holds a vendored copy that still declares it and uses it once — web/src/app/globals.css:674, inside @media print, on the (url) suffix after an external link. Nothing is broken today, and that is the danger: re-vendoring makes it a dangling var(), which is invalid at computed-value time and therefore inherits rather than erroring. The printed URL suffix would silently go from gray-300 to petrol-500, on patient-facing printed documents, with no build warning. Fix patientguide's line to --text-secondary before re-vendoring, not after. Not done from Brand OS: patientguide is on the no-go list and wants a code-reading human at its own gate.

    Done when: the cut is made with a version call recorded in MANIFEST.md, patientguide's print rule is fixed before its copy moves, the three consumer records re-vendored and each repo's own brand-provenance.mjs run clean, an undeclared-lag check exists or its absence is recorded with a reason, and it is on main.

    ---

    Update 2026-09-07 (Phase 0 revised). Four more items land with this cut and nowhere else, because package files are never edited by hand: (1) eleven shipped files now carry type:/layer: frontmatter for their new tier, so the copies already differ from canonical by those lines; (2) MANIFEST.md's source column names foundation/… for seven moved essays and baseline/setup.md, and its logo/README.md row says "rules from foundation/logo-identity.md" — all now under principles/ or how-to/; (3) the governance copy cites baseline/reference/aleris-grids-tables-dataviz.md, repointed in canonical to principles/grids-tables-dataviz.md; (4) lib/in-repo-references.test.ts pins MANIFEST.md at 5 and the governance copy at 3 unresolved until the cut, which is when both drop back to 2. The map the cut copies through is now _packages/agent-baseline.map.mjs; cut-agent-baseline.mjs --check lists 16 files that would change, nine of them drift since v0.11.

36. 114CCReady now

    Nothing fails when the deployed build and main disagree

    Done when a check exists that fails when the live host serves content the current main does not, it is proven to fail against the frozen build and pass after the redeploy, where it runs is recorded, and it is on main.

    Detail

    Files: a new check, probably lib/deploy-freshness.test.ts or a review/ check · review/README.md if it lands there

    New 2026-08-28, opened with card 113 rather than inside it, because the deploy is the incident and this is the missing apparatus.

    This repo asserts almost everything else about itself and not this. lib/route-manifest.test.ts fails when what publishes changes; data-products/tokens/tokens.test.ts fails when a ratio moves; lib/consumer-contract.test.ts fails when a promised path stops existing; lib/branch-hygiene.test.ts fails when work sits on an unmerged branch. Every one of those was written after the thing it checks had already gone wrong once. The published surface is the one claim nothing checks, and it was wrong for 73 days without anything reporting it.

    Two shapes, and they answer different questions. A build-time check compares the corpus against itself and would not have caught this, because the repo was correct throughout. What is needed is a check that fetches the live host and compares what it serves against the working copy — the same method that found the problem. review/ already drives a real browser against a declared target and already holds the rule that an empty page is a failure, never a pass; a freshness check is the same class of instrument one tier simpler, and it may belong there rather than in lib/.

    Three traps to design around.

    • It cannot run in an ordinary npm test without making the suite depend on a network and a live host. branch-hygiene is the precedent for a check that reads outside the file tree, and it is worth reading before choosing where this lives.
    • Not every difference is a failure. A page that is draft locally is correctly absent live; the check must compare the published set, which lib/route-manifest.json already computes, rather than every file.
    • The check must fail somewhere a human will see it. A test that only fails inside a suite nobody runs after a deploy reproduces the same defect one step further back. Where it reports is part of the design.

    Sequence: it can be written before card 113 lands and will fail until the redeploy happens. That is the behaviour we want, and it demonstrates the check works in a way a passing run cannot.

    2026-09-02 — the check is written and it fails, which is the half that can be finished without the redeploy. site/deploy-freshness.mjs, run with npm run site:freshness. It sits beside site/link-audit.mjs rather than in review/: that tool's stated job is what a browser paints, and its checks are functions evaluated in a page. This compares bytes over HTTP. The pair reads as one question each — does the build link only where it serves, and does the host serve what the build made.

    Written as a failure model rather than as one check, per cookbook entry 21. Eight modes covered, two named as gaps:

    Mode	State
    stale-content served bytes differ from the build's	checked, byte-exact
    raw-contract a raw endpoint 404s or changed	checked, byte-exact
    index-stale llms.txt differs from the generated one	checked, byte-exact
    missing-route a built route 404s on the host	checked
    empty-route 200 with no text-bearing content	checked
    fonts-gone a woff2 or the stylesheet 404s	checked
    fonts-cors /fonts/* stops filtering by Origin	checked, allowed and denied
    host-down unreachable or erroring	checked
    extra-route something published the build did not make	not checked — needs a crawl; nothing enumerates what is served. This is how foundation/en-draft/ became sixteen live URLs
    content-wrong whether the served prose is correct	not checked — byte-identity is the only mechanical proxy, and it is a proxy

    Byte-exact for some things and not others, deliberately. Raw endpoints, the font files and llms.txt are verbatim copies or generated text, so equality is the right assertion. HTML pages are checked for existing and having content but not for equal bytes — the emitted HTML carries content-hashed asset filenames, so two correct builds of the same source differ, and asserting equality there produces a check somebody deletes.

    First run against brand.dev.aleris.ai, 2026-09-02: 42 findings across four modes. 18 stale-content, 21 missing-route, 2 raw-contract, 1 index-stale. Four modes came back clean and that is worth as much: fonts-cors filters correctly in both directions, the font files are all present, no route serves an empty shell, and the host is up. So the one thing every consumer package depends on is not broken.

    The self-test runs before every real check and is not optional, following review/. Nine assertions. The first version had two that could never fail — Boolean('*') and a comparison against a literal — so the CORS judgement was extracted into a pure function and the self-test now drives it with real inputs, including a wildcard reaching a denied origin. A tautology in a self-test is worse than no self-test, because it reads as coverage.

    WHERE IT RUNS IS STILL NOT DONE, and it is the half that would have caught this. Two wirings are needed and neither exists: a post-deploy step, so a bad deploy is loud when it happens; and a schedule, because nothing failed on 2026-06-16 — the failure was 76 days of nothing happening, and no post-deploy hook can see that. Only a clock can. The script existing is not the same as the script running, which is the trap this card named from the start.

    Done when: a check exists that fails when the live host serves content the current main does not, it is proven to fail against the frozen build and pass after the redeploy, where it runs is recorded, and it is on main.

    ---

37. 112T→CCReady now

    Three token values restated where the token should have been named — and one is a ratified exception the constitutional page does not carve out

    Done when Torfinn has ruled on item 3, items 1 and 2 are corrected in canonical and in the agent-baseline mirrors, the narrow check exists with its blind spot named in its own header, and it is on main.

    Detail

    Owner: T for the ruling, CC for the rest · Opened: 2026-08-31 · Found by: measuring, after app/manifest.ts needed a literal hex and could not have one

    constitutional/tokens-are-canonical.md says a document "names the token; they do not repeat its hex", and records that no mechanical check exists: "extending the same pattern to catch a raw value restated in prose is not yet built." Every past breach — cards 8, 21, 22, 24 — was found by review, one instance at a time.

    A corpus-wide check is not buildable, and the measurement says so. 222 hex restatements across 17 files, of which the large majority are legitimate: foundation/colour.md (52) is the page whose job is to state the palette, baseline-tokens.json (41) is the generated twin, schemas/design-token.md (33) documents the record's shape. A check that flags all of them is roughly 90% false positives and would be switched off in a week. Same class as the unassertable-invariants finding — the rule is about restating a value where the token should have been named, and that requires knowing what a document is for.

    A narrow signature is buildable: a token named and its own hex on the same line. Five instances, three unique once the agent-baseline mirrors are folded in. All three are in files whose job is emphatically not to state values.

    1. principles/design-tokens.md:45 — the cleanest breach, and fixable now

    Restates #4f866e and #2e8540 beside their token names. It is a direct breach of a specific instruction rather than only of the general rule: baseline/BASELINE.md:45 ends with "This is the rule of record for confirm; other documents reference it rather than restating it." This is the other document, and it restates it.

    2. baseline/BASELINE.md:45 — the rule of record breaches itself, and is fixable now

    The same sentence that tells other documents not to restate the value restates it: --color-confirm-500 (#4f866e) … --color-goal-achieved (#2e8540). Neither hex carries any argument. The argument is the contrast figure — white on it is 4.23:1, below the floor at rest — and that stays. Dropping the two hexes costs the page nothing.

    3. baseline/BASELINE.md:27 — not a breach, a collision between two accepted pages. Torfinn's.

    This one is already a ratified exception, added 2026-08-12: "The one documented exception: a page rendered before the token stylesheet can load." A pre-auth surface sits behind the gate it is rendering, cannot reach the hashed stylesheet, and has to inline its colours. The page therefore lists the four values a pre-auth page needs — sand-100, petrol-500, orange-600, gray-100 — "cited from canonical rather than invented for this case", which is exactly the reasoning that makes it defensible. It was added after a real build shipped #d9663d and #e6e1da, two colours that are not Aleris colours at all, "because there was nothing here to check against."

    So a document that must state values, and a constitutional rule that says no document may, are both accepted and in force. The constitutional page has no carve-out and does not mention this exception.

    And the shapes are not symmetrical, which is the part worth deciding on. app/manifest.ts had the same problem — a surface that cannot use custom properties — and it was solved by reading the token file at build time. A markdown document cannot do that. So the options are genuinely different in kind: write the carve-out into tokens-are-canonical.md naming this exception, or move the four values into something generated that BASELINE.md points at rather than lists.

    A fourth thing, found in passing

    BASELINE.md:27 specifies a check that does not exist: "Pin the values with a test that extracts every hex a pre-auth page uses and asserts each one is one of these four — a build cannot see this rule fail otherwise." Written 2026-08-12, never built. It is a different check from the one this card proposes and both are small.

    What the narrow check would and would not catch

    It matches an exact token name and that token's own hex on one line. It misses the semantic-alias shape, and there is a live instance: BASELINE.md:41 writes --surface-page (sand-100, #f2ece4), where the alias resolves through --color-sand-100, so no name-to-hex match fires. Stating the blind spot rather than discovering it later — a check whose coverage is unstated is the failure mechanism 2 in workspace/status/cookbook.md §22 describes.

    Done when: Torfinn has ruled on item 3, items 1 and 2 are corrected in canonical and in the agent-baseline mirrors, the narrow check exists with its blind spot named in its own header, and it is on main.

    ---

    (Cards 113–115 were opened on 2026-08-31 as 106–108, on a branch that did not yet have origin/main's own 106–112. Renumbered on merge: main holds the numbers, a branch does not get to keep them. The board is the list of record and two cards with one number is a defect in it, so this is recorded rather than silently fixed — and it is an argument for taking the next number from origin/main rather than from the working copy.)

38. 111TReady now

    Q1 — the corpus has no rule for digital identity, and that is what blocks shipping an icon set

    Done when foundation/logo-identity.md either carries a digital-identity rule that a package and a check can cite, or records why digital identity belongs to Baseline instead — and it is on main.

    Detail

    Owner: T · Opened: 2026-08-31 · Blocks: Q2 (does the package ship the set) and Q3 (whose files)

    This is Q1 of workspace/evaluations/digital-identity-verification-2026-08-28.md, restated with the reason it comes first. It had been reading as a sequencing preference. It is structural.

    The corpus does not govern favicons at all. review/SPEC-production-icon-surface.md says it plainly — "This check has no rule to cite" — and gives the reason: every rule in logo/ is written for a mark that includes the wordmark, and the 24px minimum height exists precisely because below it the letters fall under the 14px type floor in foundation/typography.md. A tab icon is 16px. It is the one brand surface with no room for the wordmark at all, and the corpus has never said what the brand looks like there.

    Why that blocks Q2 rather than merely preceding it. _packages/README.md rule 1 is that packages are generated from the corpus, never edited. Shipping an icon set to consumers before Foundation has a rule about digital identity would make the package assert something the corpus has not said — the same defect as a package mirror restating a token value, one level up. Five consumer repos would carry an identity decision with no ratified source. So Q1 is not a tidiness step before Q2; Q2 cannot be answered correctly without it.

    What is already decided, so this card is narrower than it looks.

    • The symbol may stand alone as decoration or brand symbol at any size, and may not substitute for the logotype at any size — Torfinn, 2026-08-27.
    • The 16px entry is a deliberately different drawing — Torfinn, 2026-08-28, recorded in scripts/generate-logo-icons.mjs's own header: the ring's inner boundary stroked at 24 viewBox units, giving two fully-opaque pixels per stroke at 16px while keeping the counter open. Four candidates were rendered and measured before choosing.
    • The threshold is measured and it is narrow. All three rings resolve at 32px and up (12 alpha-edge crossings across the centre row) and collapse to 8 at 16px, because ring thickness is ~17.5 of 192 units — 1.46px at 16px, 2.9px at 32px. Asserted in both directions in lib/logo-minimum.test.ts, so if 16px ever resolves the redraw exception stops being justified and fails loudly.

    So the open part is not what the icon looks like. It is where the rule lives and what it says: does the ruling on the symbol standing alone go into foundation/logo-identity.md, and does that page acquire a digital-identity section that a package and a check can cite.

    A second thing that page is already waiting on. foundation/logo-identity.md is Swedish, status: draft, and the only Foundation page carrying no lang key at all. It is also the ninth file under foundation/ that three records call the eighth — the correction still owed since 2026-08-28. Writing the digital-identity rule may be the occasion to flip the page, which would settle both.

    Already done and deliberately not waiting on this card: the Brand OS site now serves the full set (card closed inside the same session — see the changelog entry for 2026-08-31, third entry). That commits nothing about Q2, because the site is not the package. It does mean the mechanism and the 16px drawing are now exercised in a real browser before any consumer carries them.

    Done when: foundation/logo-identity.md either carries a digital-identity rule that a package and a check can cite, or records why digital identity belongs to Baseline instead — and it is on main.

    ---

39. 108TReady now

    The two coined heading patterns — wording passed, acceptance open

    Done when Torfinn has read both definitions and either accepts them or replaces the wording, and it is on main.

    Detail

    Owner: T · Opened: 2026-08-31 · Wording pass done 2026-08-31 at Torfinn's instruction

    formrubrik (form instead of content, hard) and etikettrubrik (label heading, soft) sit in filters/ai-tells-and-filters.md and in the rules file at 0.2.1. The card opened as awaiting Torfinn's wording pass; he delegated the pass, so what is left is acceptance, not drafting.

    Three things the pass changed, beyond the prose.

    1. The page's naming claim was false for two of fourteen patterns. "Named in Swedish because these are the established working terms" — these two are not established, they were coined here, because the writing-style-profile has no vocabulary for headings. The claim is now qualified in place and each pattern's provenance says coined, not inherited. etikettrubrik has an anchor at least: etikett is the word Digg's guideline 61 uses for a label.
    2. The two patterns were overlapping. "The constituent parts" was listed as a formrubrik tell and is a noun phrase with no verb, which makes it etikettrubrik. formrubrik is now strictly the heading reports the text's form; etikettrubrik is the heading names a topic and says nothing about it.
    3. The page and the rules file disagreed and now say so. "What is there, and what is not" was given as a formrubrik tell while the matchable vocabulary does not and cannot contain it. Both files now state that matchable is the subset a check can match, not the pattern — so the gap is declared rather than latent.

    Raised as out of scope, then fixed on Torfinn's instruction the same day. dygdesignalering carried "honest by being clear, not by saying it is honest" and anglicismdrift carried "Kodväxling är inte djup, det är drift" — both antithesis siblings, on the pages that rule kiaster hard, transcribed verbatim in June 2026. Both second sentences cut, not rewritten, per Kiaster's own repair: the substance was already in each first sentence. Four live copies corrected together — both filter pages, the rules file counter_example, and both source entries in TAKS/2-areas/collaboration/writing-style-profile.md, which is a cross-boundary edit made deliberately, because fixing the corpus and leaving the source is mechanism 3 in workspace/status/cookbook.md §22. The plain-english skill packaged from that profile could not be located on disk and may be a fifth copy. The quotations above are kept on purpose.

    Done when: Torfinn has read both definitions and either accepts them or replaces the wording, and it is on main.

40. 107TReady now

    Does WCAG 2.4.6 enter the accessibility constitutional node as a fourth non-negotiable

    Done when the node either carries 2.4.6 or records why it does not, and it is on main.

    Detail

    Owner: T · Opened: 2026-08-31

    baseline/BASELINE.md commits to WCAG 2.1 AA minimum and constitutional/accessibility-is-foundational.md names WCAG 2.1 AA as its external lineage. 2.4.6 Headings and Labels — headings and labels describe topic or purpose — appears nowhere in the corpus; grep returns zero mentions, while 1.4.1, 1.4.11 and 2.5.8 are all cited by number. The node's three non-negotiables are colour-alone, 14px, and contrast — all visual.

    This is what makes "What it is, in one paragraph" a conformance question rather than a taste question: it is a heading that does not describe its section's topic or purpose.

    Against: the node describes its non-negotiables as "clean bright-lines and clean fitness functions", and 2.4.6 is only half-checkable — the vocabulary and structure rules are mechanical, but whether a heading describes its topic is judgment. Adding a half-checkable rule to a list whose defining property is checkability is the objection to answer, not to wave through.

    Done when: the node either carries 2.4.6 or records why it does not, and it is on main.

41. 106TReady now

    106 title-case headings ship to consumers against a decided sentence-case rule

    Done when either the seven files are corrected and their rows deleted from the baseline, or the board records a decision that imported reference material keeps its title case and the baseline says so in its note — and it is on main.

    Detail

    Owner: T · Opened: 2026-08-31 · Found by: lib/heading-tells.test.ts on its first run

    Sentence case is decided and unambiguous — "no exceptions, not even table headers or nav labels". First mechanical count: 106 title-case headings across 16 files, of which 58 are unique and the rest are the _packages/agent-baseline/ mirror. They concentrate in seven files imported from ALERIS-DESIGN-WORKING: aleris-anti-patterns (12), aleris-baseline-animation (10), aleris-grids-tables-dataviz (9), aleris-privacy-jtbd-analysis (7), aleris-baseline-images (5), aleris-progressive-enhancement (5), aleris-design-governance (3). Everything else is in ones and twos.

    The rule was applied to new work and never to the imported material, and nothing counted, so it has been shipping to consumers inside the package the whole time.

    Not failing the suite. The hits are frozen in lib/heading-tells.baseline.json and the test fails on a new hit or a stale row, so the debt cannot grow and cannot rot. The cleanup is a decision, not an emergency: the seven files are Baseline reference material, and rewriting their headings is a voice pass, not a find-and-replace. PROPER_NOUNS in lib/heading-tells.ts already exempts real names, including "Present Expert".

    Done when: either the seven files are corrected and their rows deleted from the baseline, or the board records a decision that imported reference material keeps its title case and the baseline says so in its note — and it is on main.

42. 104TReady now

    Gröna korset's five-state safety scale — ratified clinical exception, or standing breach

    Done when the corpus either records the safety scale as a ratified exception with its accessibility requirement stated, or rules that it is not one and says what the scale maps to — and it is on main.

    Detail

    Files: none yet · reads _packages/adapters/vendored-app/PROFILE-gcc.md §7 and review/reports/gcc-ux-review.html

    New 2026-08-28, from profiling gcc as a consumer candidate. This is the question that gates whether an adapter for that consumer can be generated at all, because it decides whether the checks would exempt those colours or flag them — and an adapter may not answer it (rule 2 of _packages/adapters/README.md: an adapter carries no brand content).

    Gröna korset is a national patient-safety method with established colour semantics. Its scale is five ordered states — empty → green → yellow → orange → red — and gcc's own collaboration map states the problem in one line: a straight one-to-one mapping onto Baseline's status set does not exist, so the scale has to be designed against Aleris tokens without losing readable gradation. Baseline's status colours mark error, warning, confirm and goal; they do not express ordered severity.

    Two facts make this urgent rather than theoretical. The rendered review measured three of the five colours failing AA, including green — which is what a well-run ward sees on most days. And four of the five states are separated by hue alone, which is the classic red-green confusion set: for roughly one in twelve men, risk of harm and harm occurred read as the same band. Screen-reader users are already served, because every cell carries a full aria-label — so an audit that inspects only the accessibility tree passes this, and the group with no path is sighted users with colour-vision deficiency.

    The decision, stated as the fork. If the colours are fixed by the method, the scale belongs in the corpus as a documented clinical exception with its own accessibility requirement — most plausibly a glyph per state, which gcc can implement cheaply because label, description and colour already sit in one structure. If they are not fixed, the scale is a design problem to solve against the tokens, and gcc is carrying a breach until it is.

    Related, not the same: cards 64 and 65 are the same class — a real state the palette has no answer for — and 65 in particular is about a non-colour treatment for a third status state. Whoever takes this should read 65 first; if the two are answered separately they will disagree.

    Done when: the corpus either records the safety scale as a ratified exception with its accessibility requirement stated, or rules that it is not one and says what the scale maps to — and it is on main.

    ---

43. 103TReady now

    OQ-12 — framework-agnostic component specs — open since 2026-03-21

    Done when OQ-12 either closes against card 99's outcome or is restated to say what is still open, its last_verified moves, and it is on main.

    Detail

    Files: workspace/research/aleris-design-system-open-questions.md § OQ-12 · baseline/governance/aleris-design-governance.md (open_questions: frontmatter)

    New 2026-08-28. The tracker entry card 99 answers, still last_verified: 2026-03-21.

    OQ-12 reads: "Blocking: Framework-agnostic component specs… The slot pattern (data-slot) is CSS-native and the strongest candidate for a cross-framework standard." The same gap was flagged Priority 1 in workspace/archive/aleris-product-design-skill-workplan.md § "Gaps" — "Existing docs describe everything in Tailwind utility classes (rounded-xl, bg-sand). Action: describe in framework-agnostic terms with Tailwind as one mapping example."

    Neither has moved in five months, and the asymmetry is the point. The token layer has been medium-independent since March, ratified three times and re-ratified into principles/design-tokens.md on 2026-08-10. The component layer never was: BASELINE.md's component rules are prose, every consumer implements them independently, and the one place they exist as code is product-local.

    Nothing asserts framework independence anywhere. Every test in lib/ and every check in review/ was read; none of them touches it. The only mechanical proxy in the portfolio is _tools/frontend-suite/checks/r4-js-ceiling.mjs, whose docblock quotes the COOKBOOK rule "default to no JavaScript, and make the framework an opt-in with a reason" — and it measures a byte ceiling by audience tier, not a medium. Nothing fails when a component spec is written in Tailwind classes.

    Done when: OQ-12 either closes against card 99's outcome or is restated to say what is still open, its last_verified moves, and it is on main.

44. 102TReady now

    The 2026-05-07 no-framework component decision was reversed in practice with no record

    Done when either the synthesis document records that the component-framework decision was superseded and by what, or aleris-assistant records why it diverges, and it is on main.

    Detail

    Files: documentation/architecture-v2-synthesis.md § Resolved 2026-05-07 · workspace/status/changelog.md § 2026-05-07

    New 2026-08-28, found while sourcing the framework-agnostic reasoning for card 99.

    documentation/architecture-v2-synthesis.md § "Resolved 2026-05-07" records: "Component framework: TypeScript + vanilla custom elements + Shadow DOM. No framework (no Lit, no React, no Vue)… Lit's main value is developer experience for humans writing many components by hand; with AI as the primary coder, that value largely disappears, while the dependency cost stays." Mirrored in the changelog the same day.

    aleris-assistant ships React 19 + react-dom + Vite + Tailwind 4 + @storybook/react-vite + @testing-library/react. No .md in that repo mentions shadow DOM, custom elements, web components, or why React was chosen. The decision was reversed in practice and neither side recorded it.

    Two things make this worth a card rather than a note. The synthesis document still reads as current — it says "no remaining architecture-level questions" — so a session reading it is told a decision holds that does not. And the architecture-v2-decisions.md it promises was never written, so there is no other place the reversal could have been recorded.

    Why [T]. The question is whether the 2026-05-07 reasoning still holds. Card 99 leans on it — the AI-as-primary-coder argument is the reason an HTML substrate is proposed over a React one — so if it has quietly stopped being the position, card 99 should know before it is decided, not after.

    Done when: either the synthesis document records that the component-framework decision was superseded and by what, or aleris-assistant records why it diverges, and it is on main.

    ---

45. 101CCReady now

    Two token consumers are provably stale or wrong

    Done when both consumers either carry a provenance record or are recorded as deliberately unmanaged with a reason, the dangling path in aleris-svar-main is corrected, and it is on main.

    Detail

    Files: none in this repo — this card is the finding and the routing · _packages/adapters/vendored-app/ if either consumer turns out to warrant the adapter

    New 2026-08-28, found while surveying the portfolio for card 99. Independent of every other card here.

    aleris-units-explorer carries src/tokens/aleris-tokens.css at 33,409 bytes against canonical's 50,487 — an older, smaller version with a different hash, imported from src/index.css. It has no provenance record, so nothing in that repo can tell it is behind.

    aleris-svar-main vendors a 149-line subset whose provenance comment points at ~/Dev/aleris-brand-os/baseline/tokens/ — a path that no longer exists, since Phase B step 3 moved the token file to data-products/tokens/ on 2026-08-10. Its sibling aleris-assistant, which it is a fork of, points at the current path. So the two forks disagree about where the source is and neither is checked.

    Why this is a Brand OS card rather than each consumer's. _packages/adapters/vendored-app/ exists precisely because vendoring without provenance drifts silently, and it found four expired workarounds when it was first run against the two consumers that have it. These two have the same failure and no adapter. Whether they warrant one, or a lighter note, is the decision — but a consumer that cannot tell it is stale is the condition that adapter was built for.

    Done when: both consumers either carry a provenance record or are recorded as deliberately unmanaged with a reason, the dangling path in aleris-svar-main is corrected, and it is on main.

    ---

46. 99TReady now

    The starter-kit Storybook — scope, substrate and the four mechanisms

    Done when Torfinn has decided scope, substrate and hosting, design-system-layering-analysis-260824.md §7 records that decision 2 was revised on 2026-08-28 and why, documentation/site-map.md names the fourth delivery surface, and it is on main.

    Detail

    Files: none yet · reads workspace/evaluations/sundvikt-component-library-candidacy-2026-08-28.md · touches documentation/site-map.md § Delivery surfaces once decided

    New 2026-08-28. The main proposal. It is a knowing revision of decision 2 in TAKS/1-projects/brandguide/design-system-layering-analysis-260824.md — "leave src/brand/ product-local" — taken by Torfinn on the reasoning that Brand OS should do as much of the groundwork as possible for people building in the Aleris style, that visual documentation is a powerful tool, and that a starter kit is less brittle than a lawbook.

    What it is. A visual expression of the packages that are already cut: a Storybook that renders from the real token file rather than restating it, the property baseline/buttons/index.html already has. A fourth delivery surface, alongside the three documentation/site-map.md § "Delivery surfaces" lists. Not a package member — _packages/ is untouched, so rule 6 and adapter rule 2 do not bite.

    Why the 24 August objections do not survive the reframe. Three were given. Framework choice — none, the artefact is CSS and markup per principles/design-tokens.md §12. Everyone else's upgrade path — none, nobody imports it; what is load-bearing is the token file they vendor, which already carries version identity, sha256 and expiry checks through brand-provenance.mjs. Release cadence — remains, and is the honest residual. The fourth objection, that a copied reference implementation has no version identity, was answered by the same document two sections earlier when it called the token layer "the discipline paying off": that machinery works because the artefact is a CSS file, and a CSS component layer inherits it unchanged.

    The seed, measured 2026-08-28. sundviktlakemedel/src/brand/brand.css — 1674 lines, 137 BEM classes, zero hex literals, three data- hooks. The React barrel above it is 534 lines with not a single React hook; its own header calls it "the thin component layer." It is the only implementation of BASELINE.md's component rules anywhere.

    Substrate: HTML and CSS, not React. It is the only choice that reaches every Aleris app — aleris-apt, aleris-event and bryning-app are vanilla HTML, aleris-presentation is Vue 3 — and it matches the decision taken at this exact layer on 2026-05-07 and never executed (documentation/architecture-v2-synthesis.md: "No framework (no Lit, no React, no Vue)… with AI as the primary coder, [the DX] value largely disappears, while the dependency cost stays"). The cost, stated: no props table, less ergonomic authoring, and a React developer hand-converts markup — which is the cost AI has actually made cheap. A React binding is a later addition, explicitly not canonical.

    The four mechanisms that keep a non-authoritative kit honest, all of which have a working precedent in this portfolio: a review/ target (card 100); a test asserting the stylesheet and the stories agree — 137 classes declared, 92 literal in TSX, 17 constructed dynamically, so no grep can settle it; a declared-divergence list generalising Sund vikt's closed nine; and the no-raw-elements gate widened so it can see inline formatting inside the shared layer.

    One hard exclusion, carried from the 24 August analysis and not negotiable: the kit ships no clinical rendering — dose and unit, lab value with reference range and flag, weight trend, provenance. The mitigation is a type, not a convention: shared components accept pre-formatted opaque strings and never numbers-with-units. sundviktlakemedel/src/brand/DataTable.stories.tsx:35 is the proof convention alone fails — the boundary leaked inside the candidate before a shared artefact existed.

    Its nav slot is occupied as of 2026-09-18. The header entry reserved for this card — "Kit", rendered as text with "Not built yet" beside it — now links the published reference screens at /design-system/, labelled Reference screens rather than Kit, because the 2026-09-17 ruling declined an API surface. Nothing about this card changed: if it is built, the question is whether it shares that section or replaces it, and that is one line from Torfinn.

    Hosting: brand.aleris.ai, built on deploy so it cannot become the "aspirational documentation" risk #5 of architecture-v2-synthesis.md names. Any Aleris git account may hold the source. Sequence against Phase C — a Storybook build is static and composes with the re-platform, so building it before that decision risks building it twice.

    Maintenance: Torfinn now, Mohan later, forge-style. Which has to mean generated wiring, a gate that fails rather than a document that asks, and a self-service path for adding a component — or the handover does not survive.

    Done when: Torfinn has decided scope, substrate and hosting, design-system-layering-analysis-260824.md §7 records that decision 2 was revised on 2026-08-28 and why, documentation/site-map.md names the fourth delivery surface, and it is on main.

    ---

47. 98TReady now

    Card 62 re-read — eight missing patterns is one missing component layer

    Done when Torfinn either accepts that card 62's six-to-eight are better served by rendered components than by pattern files — in which case card 62 narrows to the two with decisions behind them — or says why the pattern prose is the thing that was actually needed and card 62 stands as written — and whichever it is, the board records it and it is on main.

    Detail

    Files: none yet — this card is the re-reading, not the work. Depends on card 99.

    New 2026-08-28, from workspace/evaluations/sundvikt-component-library-candidacy-2026-08-28.md §11. Does not replace card 62. It proposes a different answer to the question card 62 is stuck on.

    Card 62 has been blocked since 2026-08-12 on the content-creation boundary: eight tool-surface pattern entries are missing, and writing pattern-library entries is prose Claude may not produce. It offers three routes, all of which put the writing on Torfinn.

    The re-reading. A pattern file argues; a rendered component shows. The rendering half — the component, its states, the tokens it uses, the measurement — is the same category as baseline/buttons/index.html and baseline/conformance/index.html, both of which Claude built and which the board fenced (card 18) as "an evaluation surface, not a component library." So seven of the eight could exist as rendered, checkable components without anyone crossing the boundary, and the prose can follow later or not at all.

    Two stay Torfinn's, because a real decision sits behind each. The third status state is card 65. The environment badge needs a colour role, placement, and a ruling on whether PROD should be badged at all — the questions _packages/adapters/vibe-coding-seed/GAPS.md §1 lists.

    What this does not claim. It does not argue the boundary is wrong, and it does not ask for a recalibration. It observes that the boundary is about prose that argues in Aleris's voice, and that a rendered specimen measuring itself against the tokens is a different object — the same distinction the 2026-07-29 calibration drew, applied to a different artefact rather than widened.

    Done when: Torfinn either accepts that card 62's six-to-eight are better served by rendered components than by pattern files — in which case card 62 narrows to the two with decisions behind them — or says why the pattern prose is the thing that was actually needed and card 62 stands as written — and whichever it is, the board records it and it is on main.

    ---

48. 92CCReady now

    "Chrome" is a retired word with 54 uses in what publishes and ships

    Done when each of the 54 uses is classified as the rule sense or the browser sense, the rule-sense ones are corrected, the retirement has a record in this repo, and a RETIRED row asserts it — with wholeWord: true, since "chrome" appears inside "Chromebook" and CSS identifiers.

    Detail

    Files: measured in baseline/iconography/size-test.html (23), curation.html (13), curation-session-b.html (6), data-products/tokens/aleris-tokens.css (3), _packages/agent-baseline/tokens/aleris-tokens.css (3), data-products/iconography/allowlist.json (2), schemas/design-token.md (1), data-products/tokens/baseline-tokens.json (1), _packages/agent-baseline/tokens/baseline-tokens.json (1)

    New 2026-08-27, found while cutting v0.8: _packages/agent-baseline/README.md's language section opened "Chrome is English; brand content is in its authored language." Corrected in that one sentence because it was being rewritten anyway. The other 54 were left, and this card is why.

    The word was retired on 2026-08-04 and the reason is exactly what makes the sweep non-mechanical: "the word named both this rule and app furniture in roughly sixty files, and app furniture is the half the rule does not govern." The canonical replacement for the rule half is "Internal names are English." But a large share of the 54 are almost certainly Chrome the browser — size-test.html and the iconography curation files are about rendering — and a blind replacement would corrupt them. The word does two jobs; that is why it was retired, and it is also why a sed cannot close this.

    A second thing this card has to settle before it can be asserted. lib/retired-terms.test.ts's third assertion requires every RETIRED row to name a record path that exists in this repo. The chrome retirement is recorded in ~/TAKS/2-areas/collaboration/ and in Dev/CLAUDE.md, neither of which is in this repo — and under the seventh constitutional rule (a rule must be applicable by a reader who has only this repo) citing them is not allowed. So a row cannot be added until the retirement has an in-repo record. That is the card's first step, not an afterthought.

    Done when: each of the 54 uses is classified as the rule sense or the browser sense, the rule-sense ones are corrected, the retirement has a record in this repo, and a RETIRED row asserts it — with wholeWord: true, since "chrome" appears inside "Chromebook" and CSS identifiers.

    ---

49. 90TReady now

    Print has no home in Brand OS — scope what may be lifted from patientguide's document surface

    Done when the brief has a decision — a scope for a print layer, or a recorded decision not to have one — and the brief is filed to workspace/archive/.

    Detail

    Files: workspace/incoming/brief-print-surface-scope-2026-08-14.md (the brief) · principles/design-tokens.md · would land in principles/ + data-products/tokens/

    New 2026-08-27, and the card is the point: the brief had sat unexecuted for thirteen days with nothing on the board, and deliberately parked and forgotten look identical without a card. Torfinn's call was to card it rather than archive it or execute it.

    The gap is total, and the brief measured it rather than asserting it. Across foundation/, baseline/, principles/, constitutional/, patterns/, schemas/ and data-products/, in .md, .css and .html: zero occurrences of @page. Zero page dimensions in mm. One @media print — four lines in baseline/index.html hiding the sidebar when someone prints the Brand OS site, which is not a document standard. No header or footer standard, no page-number convention, no margin values, no normative measure. Meanwhile principles/design-tokens.md names print as a context where exact values matter, pointing at a token file that holds no print value of any kind.

    Why it is a [T] card and not a lift. patientguide/docs/specs/document-surface.md (2026-08-13) is the first real print specification anywhere in the portfolio — page frame, margins derived from ISO 838 punch clearance, measure, header slot ratios, footer slots, a type floor in points, all measured off rendered output. The temptation is to copy it. The brief's own framing is the reason not to: a value lifted into Brand OS binds every project, not just this one. So the decision is not "what are the numbers" but which of one product's measured numbers are properties of the Aleris brand and which are properties of an A4 patient guide. That is a brand call.

    Deliberately not proposed here: page geometry. The brief declines to propose any, and this card should not invent one either.

    Done when: the brief has a decision — a scope for a print layer, or a recorded decision not to have one — and the brief is filed to workspace/archive/.

    ---

50. 86TReady now

    Prose blocks D and E — the colour-alone rule, deferred by route 3

    Done when blocks D and E are written into the Swedish colour page, or the rule is repointed and the blocks written against the new target, and it is on main.

    Detail

    Files: _markets/sv/foundation/colour.md (the Swedish page the blocks belong to) · foundation/colour.md (the English source they translate from) · constitutional/accessibility-is-foundational.md (the page the rule points at) · lib/route-manifest.json / CONTENT_DIRS (why it cannot point there yet)

    New 2026-08-25, from card 85. This card was promised on 2026-08-11 and never opened — the promise lived in a changelog entry on colour-swedish-port, which was never merged, so the deferral had no tracker for two weeks. That is the same failure as the branch itself: a record whose only copy was on a branch.

    What is deferred. Two prose blocks from the Swedish colour port:

    • Block D — the colour-alone hard rule's expanded reasoning.
    • Block E — "Why colour cannot carry meaning on its own", which is where the CVD evidence goes.

    Why they were deferred rather than written. Route 3 (card 42): the English page points the colour-alone rule at [[constitutional/accessibility-is-foundational]], which is accepted but does not publish, because constitutional/ is not in CONTENT_DIRS. Porting the rule would put a dead link on an accepted, published page. So the rule stays as it stands until constitutional/ publishes.

    This card is therefore gated on a publishing decision, not on writing time. It unblocks when constitutional/ publishes — which is Phase B work and touches card 39's CONTENT_DIRS question — or when someone decides the rule can point somewhere else.

    The evidence for block E is now ready and checked, which was not true when this was deferred. Error red #C14444 and success green #4F866E sit 76.87 apart in normal vision and 14.55 apart under protanopia — computed twice independently, and the check lives at scripts/delta-e-check.py with sanity pairs and mutation verification. The structural finding behind block E is the stronger half and it also holds: every Aleris colour is warm, and warm colours collapse onto a single yellow-khaki band under red-green CVD, so hue distinguishes nothing there. Whoever writes block E does not need to recompute anything.

    Why [T]. Both blocks are Foundation prose that argues — exactly what the content boundary reserves. The numbers, the method and the gate are all settled; the writing is not Claude's.

    Related: cards 42 (route 3, the parent decision), 85 (which opened this), 39 (CONTENT_DIRS), 76.

    Done when: blocks D and E are written into the Swedish colour page, or the rule is repointed and the blocks written against the new target, and it is on main.

    ---

51. 79TReady now

    Decision 1 withdrawn — what F6 gains instead, and it is not a list

    Done when F6's position is stated as decided rather than repeatedly re-proposed, and dependency-reciprocity.md has a decided status and home, and it is on main.

    Detail

    Files: documentation/dependency-reciprocity.md (the 2026-08-24 section, now on main) · foundation/constant-contextual.md (F6, unchanged and to stay unchanged) · workspace/decisions/decision-record-context-factors-and-emotional-modes-2026-08-25.md § 1

    New 2026-08-25. Records a withdrawal and the work that replaces it.

    What happened. The 2026-08-25 session decided (decision 1) that F6 gains a named set of five factors, each identity element declaring which bind it. Torfinn withdrew it on review the same day. It collided with documentation/dependency-reciprocity.md, amended 2026-08-24 — the one modified file in the working tree, and the only file in that tree the session's checks did not read.

    Why it lost. That record had already put a version of the same proposal to Torfinn and had it declined: F6's job, per documentation/site-map.md, is to let someone reason about a decision no branch or leaf covers yet, and a list cannot do that job — it answers covered cases and goes quiet on new ones. Hence "F6 stays a stance" and "Where enforcement goes instead — not on F6", but on the nodes where a constant is already stated as a value. Then the part that decides it: "adjacency is per-decision, not global. There is no single adjacency graph over contexts, and a pre-declared taxonomy of context relations will be wrong — each decision defines its own reach."

    Its evidence, which the session had no answer to. The children's markers case (TAKS brandguide/_state.md, 2026-07-30): the constraint that reorganised the whole design was that the summons letter names a lettered waiting area. Not medium, not audience, not emotional mode, not surface temperature — nothing a pre-declared scheme would have contained, and found by asking Sanna. A closed list of five factors misses it exactly as the four axes would.

    What replaces it. Not a list. The field a decision records is the property of the situation the answer turned on, in the words of whoever made it, so reach is computed per decision. Torfinn, 2026-08-25: that addition is the correct one, and it is the learning model. The concrete work is cards 80, 81 and 82 — carded rather than executed, on his scope call.

    What this card is for, since the withdrawal is already recorded. Two things are still open. (1) F6 is confirmed to need no change — worth stating positively somewhere, because three separate proposals have now tried to give it structure and the answer has been the same each time. (2) documentation/dependency-reciprocity.md is status: proposed and sits in documentation/, which does not publish. If it is the learning model, its status and placement are a decision nobody has taken.

    The method lesson, which generalises past this card. git status is part of reading the working tree. The record listed twelve files it had read and carried the caveat that it read the working tree rather than main — it named the right risk and missed the actual one. The ground is newest exactly where a session is most confident.

    ---

    Pulled 2026-08-25. Both halves are now one decision each rather than open questions, and the first half's premise was wrong.

    (1) F6's position — measured, and the framing inverted

    This card said three proposals had tried to give F6 structure and been turned down each time. Checking the corpus corrected that. Five attempts exist, and they split by scope rather than failing uniformly:

    Attempt	Date	Scope	Outcome
    Four contextual axes (channel/format, reader state, audience, market/culture)	2026-05-31	global	Never confirmed — still PROPOSED in F6's en-draft, still card 54
    Enumerate the constants, contextual as residual	2026-08-24	global	Declined, Torfinn's objection. "F6 stays a stance"
    Five context factors	2026-08-25	global	Withdrawn same day (decision 1)
    Physical domain's four factors — kliniktyp, patientgrupp, byggnadens förutsättningar, land och lokala krav	2026-08-06	one domain	Accepted, and named "the physical domain's instance of foundation/constant-contextual.md"
    Baseline's two surface modes — communicative, instrumental	before 2026-06	one branch	Accepted and shipping. BASELINE.md § Surface temperature opens "Baseline applies F6…"

    So the position is not "F6 resists structure". It is: F6 stays a stance, and structure lives in instances that declare their own reach. Three attempts to put a list on F6 failed; two attempts to put one a layer down succeeded and nobody has argued with either. The corpus settled this in practice and never said so, which is why the same proposal keeps arriving — this is the third time.

    The physical instance proves a global list would have been wrong, not just unnecessary. Its four factors overlap card 54's four axes on two (patientgrupp is audience-shaped, land is market-shaped) and diverge on two no global list would ever carry: kliniktyp and byggnadens förutsättningar. A building's constraints decide an interior and mean nothing for a screen. A list big enough to hold them is useless; one small enough to be useful excludes the factor that actually reorganised that domain's guide.

    The decision left, and it is one sentence's worth: Closed 2026-08-25 — it was already written. TAKS/1-projects/brandguide/context-architecture.md, updated 2026-08-24, states it in §9 ("F6 is unchanged and stays a stance"), argues it in §3 with the same children's-markers evidence this session re-derived, and says in its own § "Relationship to other documents" why it exists: "F6 teaches the reader to tell constant from contextual, and says nothing about how the system learns what the contexts are." So the position has a home, it is not F6, and it predates the question. Nothing to write.

    This session's measurement is still worth keeping — five attempts split three-global-refused against two-local-accepted — because that document argues the position from first principles and does not count the corpus's own history of trying the alternative. Recorded in workspace/decisions/decision-record-context-factors-and-emotional-modes-2026-08-25.md § "What F6's position actually is".

    What this card still holds is only the second half: the status of documentation/dependency-reciprocity.md. Note that context-architecture.md §5 asks the sibling question — "does this document live in TAKS or move to Brand OS? Two documents on one subject is the shape that has drifted four times before" — so the two placement questions are one decision, not two.

    (2) dependency-reciprocity.md — one status field over two different states

    The card asked for a status and a home. Reading the file gives the reason it has neither: it is two documents with one status: field, and they are not at the same level of ratification.

    • The original 2026-07-28 half proposes a dependency graph. Genuinely still proposed — its own Next step asks for a scoping session that has not happened.
    • The 2026-08-24 half is the learning model, and Torfinn ratified it on 2026-08-25. That half is accepted.

    One field cannot say both, so the file currently understates the ratified half and overstates the proposed one. type: planning is also now wrong for the second half — a ratified model is not planning.

    Same shape as card 74's finding on foundation/logo-identity.md: ratified rules inside a draft page, where the page's badge described the weakest thing in it. The fix there was to separate ratification from reasoning rather than to relabel the whole file.

    Three options, and the third is what card 74 did:

    • (a) Mark the whole file accepted and leave it in documentation/. Cheapest, and it promotes an unscoped graph proposal to accepted along with the model.
    • (b) Leave it proposed. Honest about the graph, and leaves the ratified model looking provisional — which is what let decision 1 be taken against it in the first place.
    • (c) Split. The learning model becomes its own accepted record (decision record, or a constitutional statement if "reach is recorded per decision" is a rule rather than a position); the graph stays here as proposed planning with a pointer. Most work, and the only option where both halves are described correctly.

    Not done here, deliberately: both remaining decisions are yours, and neither is a formality — (1) decides whether Foundation gains a sentence, and (2) decides whether the corpus gains a constitutional rule. This card stays open until one of each is taken.

    Also produced by pulling this: card 76 amended. Its reading of Baseline defining communicative/instrumental as the defect does not survive the pattern above — declaring a local instance is what a branch is for. The real defect there is narrower and worse.

    Related: cards 54, 72, 74, 76, 78, 80–82 · decision 1 (withdrawn), decision 2 (orphaned).

    Done when: F6's position is stated as decided rather than repeatedly re-proposed, and dependency-reciprocity.md has a decided status and home, and it is on main.

    ---

    Closed 2026-08-25 on both halves, and the second one dissolved rather than being decided.

    (2) The status question had no answer because the file held two subjects. The coherence pass found that context-architecture.md and dependency-reciprocity.md were not model and mechanism — they stated one argument twice, five days apart, with the same target-size example and the same three evidence cases in the same order. git log gives the direction: written 2026-08-24 in dependency-reciprocity.md, restated 2026-08-25 in context-architecture.md under a header claiming neither restated the other. The drift shape, on consecutive days.

    The two are merged into documentation/how-decisions-are-recorded.md — when we decide something, how do we record it so the next person can find it and knows what it covers? Both old paths are pointer stubs with a section map. The merged file is accepted and carries an in-force map at the top: §1–4, §8–10 in force; §7 (the language question), §11 (the graph), §13, §14 carried open. That is card 74's move — separate ratification from reasoning inside the file rather than relabel the file to its weakest part — applied to the file that ended up holding the ratified half. No split was needed, because once the model moved, everything left in the graph proposal was uniformly unratified.

    (1) F6's position now has a rule, not just a record. constitutional/a-thinking-tool-stays-a-thinking-tool.md, status: proposed. Its Detection of violation is the five-attempt table from this card; its Origin says outright that it exists so the fourth proposal meets something. The rule sentence and Implication are Claude-drafted and marked as such — both argue, so both are Torfinn's to rewrite before it moves to accepted. That is the one thing left on this card.

    Also produced. workspace/status/observations.md — a doab.md-shaped ledger for situations the brand has met, which gives F6's quick-test question 3 ("flagga den") somewhere to point for the first time. It starts near-empty on purpose, with one Claude-proposed candidate awaiting Torfinn's wording (instructional imagery, card 84). Entries are earned, not generated; the discipline is TAKS/doab.md 2026-05-14 and is pointed at rather than restated.

    And a detection statement for the obligation that had none. Every constitutional rule carries one; "every decision records the property its answer turned on" did not. The failure it needs to catch is not an empty field but a filled one — a label in a property-shaped box, "applies to the console", which looks complete. The test is doab.md's own: could someone who was not in the situation have written this? Recorded in the merged file § "What holding a situation commits you to", obligation 1.

    Not made constitutional, deliberately: a decision records the property its answer turned on. It is in force on consumer findings and nowhere else — not on board cards, not on decision records. A rule nobody follows on the day it is written becomes decoration. Graduation trigger recorded in workspace/decisions/decision-record-context-documents-coherence-2026-08-25.md § 5.

    Reasoning, alternatives, and what would make it wrong: workspace/decisions/decision-record-context-documents-coherence-2026-08-25.md. Still open on this card: Torfinn's wording of the rule sentence. ✔ otherwise.

    ---

52. 78TReady now

    Moments have no home in the layer taxonomy

    Done when there is a decided home for moment-level material, or a recorded decision that patterns absorb it, and it is on main.

    Detail

    Files: patterns/ (7 files, all component-level) · principles/ (one real file) · qualities/ (empty) · documentation/site-map.md (the layer model)

    New 2026-08-25, from decision 5, which implies a unit of accumulation the corpus has nowhere to put.

    The gap. Decision 5 retires A/B/C on the grounds that learnings accumulate by flow and state across products, not per product type. That names a unit the taxonomy does not have. patterns/ is component-level — hero, empty state, error message, confirmation — and a moment such as receiving a result spans components and constrains their order, so it is not a pattern. principles/ holds one real file. qualities/ is empty.

    What is lost meanwhile, concretely. The best material in A/B/C is results sequencing — lead with the next step, context before clinical detail, human contact always visible. Filed under Mode C it reaches only products classified as C. Filed as a moment it reaches the health check, the screening, and a lab value inside the weight product. § 3.2's trust sequences have the same shape: they describe an entry moment and are filed by product type.

    A partial answer already exists and should be read first. documentation/dependency-reciprocity.md (2026-08-24) proposes a fourth finding kind, new context — on the grounds that the existing three (missing token, missing pattern, contradiction) force situations into the wrong box, and "the box determines what survives". That is the same problem arriving from the consumer side. Whether a moment is a context, or a second thing beside it, is part of this card. Card 80 carries the finding-kind half.

    Related: cards 50 and 62 (both about what the layers are for), 77, 79, 80 · decision 5.

    Done when: there is a decided home for moment-level material, or a recorded decision that patterns absorb it, and it is on main.

    ---

53. 77TReady now

    Record the one service property that survives A/B/C's retirement

    Done when the property is recorded somewhere a page can depend on, or explicitly discarded with a reason, and it is on main.

    Detail

    Files: baseline/governance/4-den-nara-experten-digital-behavior-v1.md (line 122, where it already sits in other words) · workspace/authoring/ALERIS-DESIGN-WORKING.md § 3.1 (where A/B/C is) · destination undecided

    New 2026-08-25, from decision 5.

    The property. Can this service deliver news the person did not ask for? Screening can. An ablation pathway will. A weight subscription mostly will not, until a lab value or a side effect arrives. It decides whether a results experience must be designed for the full emotional range at all.

    Why it is the only part worth keeping. A/B/C is retired as redundant — too high level to decide anything, identifying a patient's emotional state from the service she bought, and broken by its own examples ("Patientguide spans A and C", "a bariatric patient may move between Mode C and Mode A within the same flow"). Everything else in it reduces to a flow state, which accumulates across products rather than per product type. This one does not: it is a property of the service, not of a moment, and no flow-level record would hold it.

    It is already written down, in Baseline, in different words — found on the 2026-08-25 check and not known when decision 5 was taken. baseline/governance/4-den-nara-experten-digital-behavior-v1.md (status: accepted) lists as priority area 3: "AI behavior on unexpected results (Mode C in the design working document) — how the product acts when a patient shifts from calm to anxious." So this card starts from an existing sentence rather than a blank page. Note that the same line is one of the two dangling references in card 83 — resolving them together is cheaper than twice.

    The trap. This is not a mode, and it must not be recorded as one. It answers a yes/no question about a service before design starts; it does not describe anyone's state.

    Related: cards 73, 78, 83 · decision 5.

    Done when: the property is recorded somewhere a page can depend on, or explicitly discarded with a reason, and it is on main.

    ---

54. 70TReady now

    The categorical chart order puts near-identical hues next to each other

    Done when the dataviz guidance either states a categorical order that keeps adjacent slots distinguishable, or confirms sequential order with its reasoning — and patientguide's deviation is resolved against whichever it is.

    Detail

    Files: data-products/tokens/aleris-tokens.css (--chart-1…--chart-12) · whichever reference file carries dataviz guidance

    New 2026-08-19, from reconciling patientguide's token transcription. Every value matched after correction except two — and the two that didn't are the interesting ones.

    The chart primitives in sequence read: teal, mint, blue, blue-light, purple, purple-light, terracotta, terracotta-light, marine, olive, warm-grey, dark-sand. A five-series chart drawing --chart-1..5 in package order therefore gets blue immediately followed by blue-light; at six series it also gets purple followed by purple-light. Two near-identical pairs out of five, before considering colour-vision deficiency.

    patientguide maps its five semantic slots to positions 1, 2, 3, 5, 7 instead, and that skip is almost certainly the better choice. It was left in place rather than aligned to the package, because aligning would have made adjacent series harder to distinguish — a regression wearing conformance's clothes.

    Why this is [T]. Whether the twelve-step list is an order to draw in or just an inventory of available hues is a visual-language decision, the same character as cards 64 and 65. The light/dark pairs look designed for paired comparison — before/after, two-series — which --chart-pair-N-a/-b already serve; if that is what they are for, then --chart-1..12 is listing primitives rather than recommending a sequence, and saying so is the whole fix.

    Done when: the dataviz guidance either states a categorical order that keeps adjacent slots distinguishable, or confirms sequential order with its reasoning — and patientguide's deviation is resolved against whichever it is.

    ---

55. 65TReady now

    A non-colour status treatment for a genuine third state

    Done when a system-wide non-colour treatment for a third, genuinely-uncertain status state is decided, documented in BASELINE.md § Status messages, and it is on main.

    Detail

    Files: data-products/tokens/aleris-tokens.css (possibly a new token, depending on the decision) · baseline/BASELINE.md § Status messages · foundation/colour.md (the colour-alone rule this depends on)

    New 2026-08-12, from workspace/briefs/findings-from-sundviktlakemedel-build-part2-2026-08-12.md §5. A real status state — "could not assess", not a degraded version of either "clear" or "flagged" — had no token to build from: every existing status value (--status-confirm, --status-error, --status-warning) is a colour, and colour-alone is exactly what the constitutional rule forbids relying on. The consumer built it from border-style: dashed plus a distinct glyph — it works and survives greyscale, but "the shape that means uncertain" is now a decision made once, by one consumer, rather than something Brand OS owns.

    Why this is [T]. What visual convention reads as "uncertain" system-wide (dashed border, a specific glyph, a hatch pattern, something else) is a visual-language decision, the same character as the button state model (cards 16/17) — not a token to wire mechanically.

    Depends on this, once decided: the StatusChip three-state pattern named in the same brief's predicted patterns (distinct from card 62's six/seven, since it can't be written as a pattern until this decision exists — right now it would just document one consumer's improvisation).

    Done when: a system-wide non-colour treatment for a third, genuinely-uncertain status state is decided, documented in BASELINE.md § Status messages, and it is on main.

    ---

56. 64TReady now

    --border-subtle — a lighter row separator than gray-100

    Done when a --border-subtle value is chosen and lands in aleris-tokens.css, BASELINE.md § Tables documents when to use it over --border-default, and it is on main.

    Detail

    Files: data-products/tokens/aleris-tokens.css (a new colour + border token pair) · baseline/BASELINE.md § Tables

    New 2026-08-12, from workspace/briefs/findings-from-sundviktlakemedel-build-part2-2026-08-12.md §3. --border-default (gray-100, #d7d2cb) is the only container border colour, so a dense worklist's row separator and its panel edge are forced to the same value — flattening the table's structure at scale (the consumer measured this at 250 rows). The build used --border-default for both, deliberately, rather than invent a value.

    Checked whether an existing token already covers this — it doesn't. sand-50 (the instrumental page background) is close in lightness, but using a page-background colour as a row-separator border would make the rule nearly invisible against that same page, which isn't what a "lighter but still present" rule needs. A genuinely new value between gray-100 and the sand surfaces is required.

    Why this is [T]. Same shape as the corner-radius default (card 45): a new value on the palette needs a design call, not a mechanical wiring — there is no "lighter gray" already decided elsewhere to point to.

    Done when: a --border-subtle value is chosen and lands in aleris-tokens.css, BASELINE.md § Tables documents when to use it over --border-default, and it is on main.

    ---

57. 62TReady now

    Six tool-surface pattern files — content-boundary conflict, not yet resolved

    Done when Torfinn picks an option above, or restates the boundary doesn't apply here and why — not before then.

    Waits on Card 99's three rulings — the seven only exist as components if the kit does

    Detail

    Files: none yet — this card is the flag, not the work

    New 2026-08-12, from workspace/briefs/findings-from-sundviktlakemedel-build-2026-08-12.md §5 and Torfinn's OQ5 answer ("write them now"). The brief identifies six missing tool-surface pattern-library entries (the gaps a real build hit with nothing in the pattern library to point to). Torfinn's instruction is to write them now rather than wait.

    A seventh candidate arrived in the second deliverable (workspace/briefs/findings-from-sundviktlakemedel-build-part2-2026-08-12.md, predicted pattern #2): a confirm-with-attestation control, built by that consumer as Button variant="complete" — petrol plus a required check glyph, direct application of hard rule 5's confirm retirement. Unlike the third-state status indicator (that same brief's predicted pattern #1, which needs board card 65 decided first), this one has no open decision behind it — same shape as the other six. Folded into this card's scope rather than opened separately.

    An eighth candidate arrived 2026-08-19, from a different direction — a consumer's written standard rather than a build's findings. aleris-vibe-coding's docs/environments.md:131 makes an environment badge mandatory in every app it seeds: the interface must show whether it is running DEV, STAGE or PROD, driven by an environment variable, never hardcoded to PROD. Brand OS has no pattern for it, so a component every app in that consumer must ship is improvised in every app — colour role, placement, whether it survives greyscale, and whether PROD should be badged at all or only the non-PROD environments. Folded in here rather than opened separately, the same way the seventh was. It is arguably the strongest of the eight: the requirement is mandatory, universal in that consumer, and predates every build that produced the other seven. A second consumer confirmed it 2026-08-28, and differently. gcc builds an environment marker of its own, inventing three colours Brand OS has never seen. So the eighth candidate now has two independent instances — one a written standard requiring the component, one a build that needed it and improvised — and the two do not agree on what it looks like. That is the shape the other seven candidates do not have. See _packages/adapters/vendored-app/PROFILE-gcc.md §7. Found while writing _packages/adapters/vibe-coding-seed/, and recorded in that adapter's GAPS.md — an adapter may not answer it, because inventing brand content in wiring is a hand-edited package one layer out.

    The conflict. CLAUDE.md's content-creation boundary is explicit and was restated after an earlier miscalibration this same project: Claude does not "produce pattern examples for the pattern library" — that's listed as still-gated even after the 2026-07-29 calibration narrowed the boundary to exclude pure utility text. Six new pattern-library entries read as exactly what that sentence names, not utility text like a table cell or column header.

    Not resolved by proceeding anyway. Raising this here rather than either silently writing the six files or silently sitting on the instruction. Options: (a) Claude drafts structure/scaffolding — headings, the problem statement, the token references, the "done when" — and Torfinn writes the pattern-defining prose and examples into that scaffold; (b) Torfinn writes the six files directly, using the brief's §5 gap list as the brief; (c) Torfinn decides these six specifically read as mechanical enough (they document existing token/rule combinations already decided elsewhere in Baseline, not new brand argument) to fall on the utility side of the boundary, the same recalibration that freed table cells and footnotes on 2026-07-29.

    Done when: Torfinn picks an option above, or restates the boundary doesn't apply here and why — not before then.

    ---

58. 57TReady now

    Design the positive rule replacing "No dark mode"

    Done when a positive rule exists in foundation/colour.md (or wherever the constitutional split lands it) stating what Aleris does in dark mode, high contrast, and at larger text sizes — and it is on main.

    Detail

    Files: foundation/colour.md (the retirement note lives at the old rule's position) · foundation/en-draft/constitutional/colour-is-the-aleris-palette.md (same retirement, plus a resolved Open item) · documentation/site-spec-v2.md (corrected, no longer cites the retired rule as evidence of on-brand discipline)

    New 2026-08-11. Torfinn: respecting a user's local/personal display settings — dark mode, high contrast, dynamic text size — is a legal requirement, the same class of obligation as the WCAG floors already on this page, not a brand preference Aleris can override. "No dark mode" retired the same day across both places it was stated as a non-negotiable (canonical and the still-draft constitutional page), plus the site-spec line that cited it as evidence the Brand OS site follows its own rules.

    What's retired, and what isn't. The prohibition is gone. Nothing has replaced it — there is no dark-mode token set, no dark-surface contrast verification, no rule about what "on-brand in dark mode" even means. The Brand OS site itself is still light-only in practice; that's now an implementation gap, not a demonstration of discipline (site-spec corrected to say so).

    Why this is [T] and can't be executed mechanically. A positive rule here is real design work — a dark palette (or a rule for how the existing palette inverts), contrast re-verification against dark surfaces, and a decision about whether high-contrast and dynamic-text-size get their own rules or ride on existing accessibility floors. None of that exists yet to port or verify; it has to be designed.

    Done when: a positive rule exists in foundation/colour.md (or wherever the constitutional split lands it) stating what Aleris does in dark mode, high contrast, and at larger text sizes — and it is on main.

    Scope question raised 2026-08-12 (consumer feedback, workspace/briefs/findings-from-sundviktlakemedel-build-2026-08-12.md §6/OQ3): does the eventual dark-mode rule cover instrumental surfaces (tools, admin, dashboards) the same way it covers communicative ones, or does instrumental get its own, separately-reasoned treatment? Torfinn: explicitly TBD — this needs a real design pass, not a quick mathematical or logical extrapolation from the light-mode rule. Don't let a builder (or Claude) infer an instrumental dark-mode answer from the eventual communicative one; it hasn't been designed.

    ---

59. 55TReady now

    Rewrite the "For AI systems" idiom rule in voice.md for an English source

    Done when the bullet states a real English-language failure mode Torfinn has written, and it is on main.

    Detail

    Files: foundation/voice.md (after promotion) · viewports/voice-for-ai-systems.md (the generated adapter this section feeds, per principles/voice.md's own Open item 4)

    New 2026-08-11, from the English-flip language sweep. voice.md's "For AI systems" section bans literal-translation artefacts — "Vi är här för dig", "tveka inte att höra av dig" — explicitly as a rule about Swedish source text. Now that this page is the canonical English source rather than a translation of it, the rule is self-referential and doesn't name any real failure mode in English.

    Torfinn's decision (2026-08-11): rewrite it, not cut it. The gap: rewrite is voice content — deciding what the English-language equivalent failure looks like (stiff corporate-translation phrasing? AI-hedging boilerplate? something else) is a brand-voice call, not translation.

    Not blocking: the rest of voice.md is reviewed and approved; this one bullet ships with a flag rather than holding up the page. See the bullet's own inline note for where it sits.

    Done when: the bullet states a real English-language failure mode Torfinn has written, and it is on main.

    ---

60. 36TReady now

    Physical domain ownership, and the three specifics to confirm with Sanna

    Done when the decision record carries a role in owner:, the three specifics each have a yes or no, and documentation/site-map.md's open decision 3 records physical as settled.

    Detail

    Files: workspace/decisions/decision-record-physical-interior-2026-08-06.md ← Open 1 and 2 · documentation/site-map.md ← open decision 3 · workspace/archive/interior-fysisk-miljo-v1-inbox.md ← open question B3

    New 2026-08-06 out of card 35. Two things, one conversation.

    One: record the owner as a role. documentation/site-map.md's open decision 3 is "Per-domain ownership — who owns communication, physical, and each per-market core." Sanna owning physical answers a third of it for free. But _TEMPLATE.md's rule is that owner is a role, not a personal name — "People change; the repo's load-bearing facts must survive" — and Claude does not know her title. One field, and it unblocks promoting the decision record past proposed.

    Two: confirm three specifics before they enter the corpus. Each appears only in the 2026-08-06 guide — not in any of the three archived drafts, not in either June research source. The guide is LLM-assisted, which makes the distinction between decided and plausibly generated worth one explicit pass:

    • sage — is this a colour she chose, or a word that arrived with the drafting? Determines whether card 37 is a palette-extension decision or a rewording.
    • 70/20/10 — recorded as hers by right (composition is the domain's), so this is confirmation rather than approval. But if the ratio came from the model rather than from her, it should not be recorded as a decision at all.
    • The suppliers — Input Interiör, RP Möbler, IKEA. v1's open B3 was "Finns det befintliga leverantörsavtal som påverkar möbel- och materialval?", unanswered. If these are real agreements, that is a decision record and a changelog entry of its own. If they are illustrative, they should not sit in a document that reads as policy. Worth putting the tension to her directly: IKEA against the guide's own undvik trendmaterial, its hög kvalitet, and its sustainability line möbler som håller länge. That is not a gotcha — it is the kind of thing that is cheap to reconcile now and expensive to reconcile after a unit has been fitted out.

    Also worth raising in the same conversation, though it is not a decision: she has seen interior-arrival-phygital-draft.md, so the six [!utkast] slots are either declined or deferred. Either answer is fine; the corpus just needs to know which, so it stops carrying them as live work.

    Done when: the decision record carries a role in owner:, the three specifics each have a yes or no, and documentation/site-map.md's open decision 3 records physical as settled.

    ---

61. 34TReady now

    Author English Group-level originals for the three Baseline voice guides

    Done when all three have an English draft in workspace/authoring/ for Torfinn's review, and a decision is recorded on whether they graduate to real Baseline originals — with the Swedish repointed as depending on them — or stay flagged as drafts.

    Detail

    Files: baseline/voice/1-den-nara-experten-karnguid.md · baseline/voice/2-den-nara-experten-dokumenttyper.md · baseline/voice/3-den-nara-experten-digital-rost-v2.md ← the three Swedish sources, active and accurate · workspace/authoring/ ← English drafts land here

    New 2026-08-06, surfaced while drafting constitutional/language-policy.md (card 33). The route-manifest gate (card 27) already flagged these three as a language mismatch — Swedish content under Baseline's hardcoded lang="en" — and the language-exit brief left "whether Baseline's three Swedish voice guides get translated or relabelled" explicitly open (§5).

    Not a translation problem, a provenance problem. The three guides were authored directly in Swedish and are accurate as they stand — nothing about them is wrong. They simply have no English original to point to, and language-policy.md (card 33) requires one. Torfinn's framing: authoring the missing English "originals" that the Swedish is retroactively "based on" is reverse engineering, not translation. The Swedish stays exactly as it is; English is constructed to stand behind it as the Group-level source.

    What Claude can do: produce a high-quality English draft of each guide as a starting point — not a rough machine pass, the best version achievable short of Torfinn's own voice pass. Same shape as the existing _translation-notes.md precedent: flagged, unverified, his to correct on sight. What Claude cannot do: finalize it as the canonical original. These three become the source every future reference points to, so the voice pass is not optional the way it might be for a lower-stakes page.

    Done when: all three have an English draft in workspace/authoring/ for Torfinn's review, and a decision is recorded on whether they graduate to real Baseline originals — with the Swedish repointed as depending on them — or stay flagged as drafts.

    ---

62. 28CCReady now

    The language and voice-pass inventory – what B2 needs

    Done when every Foundation page has language, status, and voice-pass state on one table, the fallback options are costed, and B2 is a decision rather than an estimate.

    Detail

    Files: foundation/*.md · foundation/en-draft/** · workspace/authoring/_translation-notes.md ← the machine-assisted-translation caveat (moved from foundation/en-draft/ 2026-08-05, card 30) · documentation/site-map.md ← the no-fallback stance

    Pullable now. B2 – whether the published local site is English or Swedish – is currently a guess about which corpus is real, and the guess may be inverted. The Swedish pages are the finished ones: six genuinely-Swedish accepted Foundation pages, voice-passed and frozen. The English set is five accepted plus one proposed, and _translation-notes.md describes the whole of it as "unverified, machine-assisted translations – starting points for Torfinn to revise", with five voice-sensitive passages flagged for his pass. So the two languages are at rough parity in count, and the real unknown is how many English pages carry prose Torfinn has actually passed versus prose marked accepted by inheritance.

    Note the trap: foundation/imagery.md is English sitting in the Swedish tree at identity/imagery, so a count of Swedish accepted pages that trusts directory position returns seven when the answer is six.

    Second half of the card. B2 turns on the fallback policy – what an English reader sees when a page exists only in Swedish. site-map.md records a no-fallback stance, meaning gaps rather than silent Swedish. That is what makes a second locale cheap or expensive and it should be decided with B2, not after it.

    Done when: every Foundation page has language, status, and voice-pass state on one table, the fallback options are costed, and B2 is a decision rather than an estimate.

    ---

63. 23TReady now

    The pairing rule – adopt the flow ladder, or not

    Done when adopted or declined in the changelog. If adopted, the rule gets its own section in BASELINE.md § Buttons, hard rule 3 is reworded, and the four costs above each get an answer or a card.

    Detail

    Files: workspace/archive/button-state-return-2026-08-01/reference/Button States Brief.dc.html ← turn 2, open it in a browser (moved from workspace/incoming/ since) · workspace/evaluations/button-state-return-evaluation-2026-08-01.md · baseline/BASELINE.md ← hard rule 3 at :35, § Buttons

    New 2026-08-01, from the design return's turn 2. Nobody asked for it and it is the largest idea in the bundle.

    The rule. Button form follows flow position, not visual rank. Filled orange instigates – pressed from outside, it puts the user into a flow. Petrol outline continues inside a flow, or is a sibling choice outside one. Filled petrol closes – the flow ends here, confirmation or not. A link is a sibling that is navigation. One invariant: never filled orange beside filled petrol, because they are opposite ends of a sequence, so co-occurrence means one is mislabelled.

    The measurement under it is new and holds. Against sand-100 the primary's boundary is 3.85:1 and the secondary's is 8.75:1 – the subordinate control is 2.3× crisper than the one it is subordinate to. And the two fills measure 2.27:1 against each other, below the 3:1 that would let a low-vision user separate two adjacent components. The pair fails twice and neither failure was on any list. The rule makes it structurally impossible rather than discouraged, which is a better answer than tuning either button. The invariant is also enforceable in CI, which is unusual for a composition rule.

    What adopting it costs, and none of this is free:

    • It amends hard rule 3. BASELINE.md:35 reads "One primary CTA per screen… Do not place two orange buttons in the same view." The return records Torfinn as saying per section, not per screen. Stacked sections mean the pair repeats down a page, so a bad pairing compounds rather than appearing once.
    • It unwinds the confirm alias. Card 3 folded confirm into secondary; the ladder separates them again – confirm would need its own cluster pointing at the same petrol values rather than aliasing. A token change, not a reversal of card 3.
    • It reopens the check glyph. Filled petrol now means "closes a flow", so Avsluta and Radera utkast take the form while confirming nothing, and a required check reads wrong on them. Either the glyph belongs to the sign-off subset rather than to the form, or it goes. (check is already in the F11 allowlist, so nothing turns on icon availability.)
    • It leaves one slot empty. Inside a flow, outline is taken by Fortsätt, so Tillbaka and Avbryt have no form. Two candidates: a link, which is honest for Tillbaka and wrong for Avbryt in a modal, since Avbryt is an action; or reviving ghost, whose first real job this would be – at which point ghost's press state stops being theoretical and card 17's gap (a) reopens on a variant with no instances.
    • Two edge cases decide whether it survives contact. "Bekräfta och boka ny tid" ends one flow and opens another. A one-step action instigates and closes in the same press, and the invariant forbids drawing both – the return proposes choosing the form from the user's position before the press, which makes it filled orange, and says explicitly that this needs adopting or rejecting rather than inferring.

    Why it is its own card and not part of 17. Card 17 decides the state set – what a button does when you focus, press or are blocked. This decides which button you are looking at in the first place, and it amends a hard rule. Nothing in 16 or 17 depends on it; it depends on neither.

    Done when: adopted or declined in the changelog. If adopted, the rule gets its own section in BASELINE.md § Buttons, hard rule 3 is reworded, and the four costs above each get an answer or a card.

64. 165CCBlocked

    Feedback on the website: "Did this answer your question?"

    Done when a reader can answer yes or no on a concept or answer page, the row lands in the Forge database under forced row-level security, and the brand team can export it as CSV.

    Waits on Forge: forge/ASK-BRAND-001.md and forge/ASK-BRAND-002.md

    Detail

    Files: workspace/briefs/prd-brand-os-website-2026-09-24.md § 4.15 and § 6.3 · site/serve.mjs · db/

    New 2026-09-25. Every concept and answer page is meant to ask whether it answered the reader's question (decision record § 2). Torfinn ruled that answers go to a table in a Forge database (2026-09-24), and on 2026-09-25 that the feature waits until the database question is resolved ("the yes/no feedback feature can be added in later when the DB issue is resolved"). Nothing of it is built; the pages carry no feedback box.

    Half answered 2026-09-28. forge/ANSWER-BRAND-001.md: a migration after onboarding is a db/0002_*.sql file, pushed, then Deploy pressed in the console — forge applies it as the app's own migrator, and has since 2026-09-11 (SEC-20); our FORGE.md is stale on this. ASK-BRAND-002 is still open (how a public endpoint writes a row when nobody is signed in, and which controller a group-wide site uses): forge calls it a real design decision. So the table can be written now and the endpoint cannot be finished until 002 is answered.

    Blocked on Forge, not on this repo (as first written). Forge's scoped role cannot create tables, and FORGE.md documents a schema reaching the database only "at onboarding". A feedback table arrives after onboarding. That is the question ikon/forge/ASK-IKON-001.md has asked since 2026-09-10, including "how a second migration reaches the schema later", and it is still open. The one answer unblocks both apps. Asked of Mohan on 2026-09-25, on Torfinn's instruction: forge/ASK-BRAND-001.md (how a migration reaches the database after onboarding) and forge/ASK-BRAND-002.md (how a public endpoint writes a row when nobody is signed in, and which controller a group-wide site uses). Answers arrive as forge/ANSWER-BRAND-00N.md.

    Ready to build once answered: a db/ migration for one table in the brand schema (timestamp, page path, yes or no, optional comment; no names, email or IP), with row-level security forced; a small feedback module beside site/serve.mjs, which stays free of packages, carrying the one dependency (pg) and the claims pattern from FORGE.md; the Dockerfile carrying only that dependency; lib/static-server.test.ts changed on purpose so only the feedback route accepts a POST; rate limiting and a 2 000-character cap; a test against a throwaway Postgres. The box itself (PRD § 4.15) goes on concept and answer pages, and stays hidden with JavaScript off.

    Done when: a reader can answer yes or no on a concept or answer page, the row lands in the Forge database under forced row-level security, and the brand team can export it as CSV.

65. 144CCBlocked

    Generate a vendored-app adapter for gcc, now that pursuing it is ruled

    Done when card 104 is ruled, the adapter is generated and installed, its first run's findings are recorded, and it is on main.

    Waits on Card 104 — Gröna korset's five-state safety scale is either a ratified clinical exception or a standing breach, and that decides whether the adapter's checks exempt those colours or flag them. An adapter may not answer it (adapter rule 2: an adapter carries no brand content)

    Detail

    Files: _packages/adapters/vendored-app/PROFILE-gcc.md (filled 2026-08-28, with citations) · _packages/adapters/vendored-app/ · nothing in ~/Dev/gcc until the gate clears

    New 2026-09-10, from card 105's ruling: pursue. The profile exists and nothing in that repo has been touched.

    Blocked on card 104, and not by choice of sequencing. Gröna korset's five-state safety scale is either a ratified clinical exception or a standing breach. The adapter's checks cannot be generated without knowing which, because the answer decides whether they exempt those colours or flag them — and an adapter may not decide it: adapter rule 2 says an adapter carries no brand content, so this is the one question the mechanism is forbidden from answering for itself.

    Done when: card 104 is ruled, the adapter is generated and installed, its first run's findings are recorded, and it is on main.

    ---

66. 137T→CCBlocked

    Rename the package folders to the tiers — a breaking cut, taken once, at Foundation v1

    Done when the map's left-hand side names the tiers, all four consumers are re-pinned to the version that carries it and their provenance checks pass, the migration note is in the manifest, and it is on main.

    Waits on Foundation v1 shipping (documentation/versioning-rules.md: packages pin to a version from then, not a date). Card 136 cleared 2026-09-10 — an identifier is a path — so this now waits on Foundation v1 alone, and on card 142 having swept the identifiers so the rename and the sweep do not collide

    Detail

    Files: _packages/agent-baseline.map.mjs (the left-hand side of every entry) · _packages/agent-baseline/{foundation,reference,governance,voice,patterns}/ · _packages/agent-baseline/MANIFEST.md and README.md · _packages/adapters/vendored-app/instances/patientguide.brand-provenance.json and sundviktlakemedel.brand-provenance.json · _packages/adapters/vibe-coding-seed/ · lib/consumer-contract.test.ts · lib/in-repo-references.ts (the package root in the dual-context rule) · baseline/BASELINE.md § the file table

    New 2026-09-07, opened on Torfinn's instruction after the Phase 0 revised moves. Since that day nine of the package's thirty files come from principles/ and only seven from baseline/, while the package still says foundation/colour.md, reference/aleris-baseline-animation.md and governance/aleris-anti-patterns.md. That gap is the generated-view ruling (2026-09-06) working as intended: the left side of the map is the consumer contract and did not move. This card is the one deliberate moment it does.

    Why it is a breaking cut and not a side effect. Four consumers record package paths and compare bytes against them — patientguide and sundviktlakemedel through brand-provenance.json, aleris-assistant by direct reference (it broke for fifteen days the last time a path moved, 2026-08-10), and aleris-vibe-coding through Richard's mirror on Bitbucket, still pinned at v0.6.5. Renaming a folder breaks all four at once, so it happens once, announced, with every consumer re-pinned in the same pass — not as a consequence of whatever cut happens to come next. The v0.12 catch-up cut (card 119) keeps the old names on purpose.

    Why Foundation v1. _packages/README.md rule 3: until Foundation v1 ships, packages are stamped by date; after it, they pin to a version. A consumer re-pinning to a version-stamped package for the first time is already taking a deliberate step, so that is the cheapest moment to hand them new paths as well. Two breaking changes for the price of one migration.

    What the cut carries, so nothing is renamed twice. The package folders become the tiers: principles/ for the essays and the reference pages, patterns/ for the library and anti-patterns, and whatever the governance split (⚑ item 5) and the BASELINE.md retirement (card 50) have produced by then. The aleris- file prefixes the corpus dropped go at the same time. Card 136's outcome — identifiers as paths or names — decides whether the depends_on values inside the shipped files change in the same cut, which is why it is a wait-on rather than a follow-up.

    What must exist before the cut. A written migration note per consumer (old path → new path, generated from the two versions of the map rather than typed); brand-provenance.mjs in the vendored-app adapter able to read both shapes for one version, or a stated cut-over date; and lib/consumer-contract.test.ts fed the new left-hand side. lib/in-repo-references.ts's dual-context rule needs no change — it reads the package root, not the folder names.

    Yours (T). Whether the rename happens at Foundation v1 or waits for a later version; whether it coincides with retiring BASELINE.md (card 50), which would change the package's entry point in the same breaking cut; and the folder names themselves, which should be the tier names unless the package wants a consumer-facing vocabulary of its own.

    Related: cards 119 (the catch-up cut that keeps the old names), 136, 50, 125 (consumers who copy rather than install), 14 and 34 (Richard's mirror).

    Done when: the map's left-hand side names the tiers, all four consumers are re-pinned to the version that carries it and their provenance checks pass, the migration note is in the manifest, and it is on main.

    ---

67. 100CCBlocked

    review/ gains a rendered-component target

    Done when a target exists, --self-test passes, the run is clean or its findings are declared with reasons, review/README.md records the in-repo-target exception, and it is on main.

    Waits on Card 99 — the target has to be the component set itself, and card 99 is what decides whether a component set exists and in what substrate. Moved here 2026-09-09: it had been filed as pullable since 2026-08-28 while its own body says it "depends on card 99 producing something to point at". Card 99 is Torfinn's, in sitting B

    Detail

    Files: review/targets/ (a new target) · review/README.md · possibly review/checks/

    New 2026-08-28. Depends on card 99 producing something to point at.

    review/README.md opens by saying what it is for: "data-products/tokens/tokens.test.ts asserts what the token file declares. This asserts what a browser actually paints." What it has never had is a target that is the component set itself rather than a product built from it. A rendered component gallery is the ideal target — every component in every state at one URL, no login, no seeded database, no Docker.

    Why this matters more than convenience. It is the mechanism that lets the kit be non-authoritative without being unchecked, which is the whole architecture of card 99. And it closes a gap the conformance tiers currently leave open: a product can be checked against Baseline, and the token file can be checked against itself, but nothing renders the component set against the rules it claims to implement.

    Two properties of review/ to preserve, both stated in its own README. Targets are declared in review/targets/, never in the reviewed repo — but this target is in this repo, so the distinction that motivated the rule (reviewing work you do not own) does not apply and should be noted rather than silently inverted. And --self-test runs before every real review; a component gallery does not change that.

    Contextual floors need declaring. target-size has two, 44px and 24px, and which applies is a fact about the situation. A component gallery renders both densities on purpose, so the target must declare per-viewport with a reason rather than inherit the strict default and report a false failure on every console specimen.

    Done when: a target exists, --self-test passes, the run is clean or its findings are declared with reasons, review/README.md records the in-repo-target exception, and it is on main.

    ---

68. 40CCBlocked

    Build the physical source layer, and split wayfinding out of it

    Done when physical/ holds an interior page and a separate wayfinding page, both declaring depends_on against the decision record and the constitutional accessibility node, both non-publishing until a deliberate transit; the archived drafts are marked superseded with pointers rather than left as parallel copies; and every open question from v1 that is still open is carried forward rather than dropped.

    Waits on Cards 36, 37 – colour/ownership decisions the layer would have to state (38 closed 2026-08-06)

    Detail

    Files: physical/ ← does not exist yet · workspace/archive/rescued-from-backup-branches-2026-08-03/physical/{interior.md, interior-arrival-phygital-draft.md, README.md} · workspace/archive/interior-fysisk-miljo-v1-inbox.md · workspace/decisions/decision-record-physical-interior-2026-08-06.md · workspace/sources/physical-accessibility-floors-2026-08-06.md

    New 2026-08-06 out of card 35. Waits on cards 36, 37 and 38 — all three are decisions the layer would have to state on its first page, and writing it first means writing around them.

    What this is not. The first pass of card 35's evaluation recommended reconciling the four interior drafts into a single physical/interior.md. That recommendation followed from reading the 2026-08-06 guide as a candidate page, and it went away with the reframe. The source layer gets built from the archived drafts plus the recorded decisions — not by merging a human-facing guide into a corpus page.

    The material to build from, and what each contributes. interior-arrival-phygital-draft.md (27 KB) is the base: most developed, and already structured along the patient journey — ankomst, incheckning, väntan, mötet och avskedet — with emotional mode as an explicit lens and a digifysiskt lager section. interior.md and the v1 inbox file carry the operational detail the guide dropped: reception acoustics and sightlines, waiting-room zoning, the logo placement table, the wall-communication rules with a function, an owner and an update cycle per element, staff areas, sound design. The decision record carries the five owner positions. The consolidation rule applies: source text carries over verbatim, nothing paraphrased, and anything the guide changes is marked as changing it rather than silently rewritten.

    Two things to preserve that are easy to lose. v1's open A4 — reformulate self-check-in from a solution into a principle (patienten ska kunna ankomma utan att behöva verbalisera sitt ärende offentligt) so terminals and apps become implementation examples and the principle survives technology change. And the guide's undvik list, which is the closest thing in any of the four documents to the negative form the corpus requires of its own pages; it should become that section rather than staying inside a form-language subsection.

    Wayfinding splits out in the same pass. The guide itself says of it "Ett eget kapitel." It has its own standards research (workspace/sources/wayfinding-signage-standards-research-2026-06-15.md), its own governance logic — follow established standard rather than choose from our list, which is the inverse of every other iconography arena — and its own open decision: one signage line across three countries or local adaptation, which Norway's reversing universal-design stance makes a design question and not only a compliance one. foundation/iconography.md already declares the skyltning & vägfinning arena OPEN and pointing here. Keeping it as a section inside interior is what has kept it unwritten.

    Also fold in: physical/README.md's five collected inbound dependencies — it was written as a requirements inventory for exactly this moment and says so ("When Physical is planned for real, this table is the requirements inventory — start there"). And F1's Ingen dark mode, which states it covers fysiska rum and has never been carried through.

    The trap: card 39. Do not create any physical/*.md with status: accepted until CONTENT_DIRS is fixed, or it publishes silently. Card 39 is [CC] and pullable now, so it should simply go first.

    Done when: physical/ holds an interior page and a separate wayfinding page, both declaring depends_on against the decision record and the constitutional accessibility node, both non-publishing until a deliberate transit; the archived drafts are marked superseded with pointers rather than left as parallel copies; and every open question from v1 that is still open is carried forward rather than dropped.

    ---

69. 37TBlocked

    The palette boundary – sage, varmvit/ljusgrå, and who owns composition

    Done when sage has a route and, if it enters, a full F1 row plus the token ripple; varmvit/ljusgrå are either reworded or documented; and the decision record's §3 open half is closed.

    Waits on Card 36 – whether sage is Sanna's real choice or a drafting artefact; varmvit/ljusgrå and 70/20/10 already closed

    Detail

    Files: foundation/colour.md ← accepted, and the freeze/twin-sync history applies · workspace/decisions/decision-record-physical-interior-2026-08-06.md ← §3 · foundation/constant-contextual.md ← the rule that settles it

    New 2026-08-06 out of card 35. Most of this card is already answered; what remains is one decision and one rewording.

    The framing, so this doesn't get re-litigated. foundation/constant-contextual.md says "Paletten är konstant. Kompositionen är kontextuell." That draws the line between what a domain owner may decide and what belongs to Foundation, without needing a judgement call each time:

    • 70 % bas / 20 % naturmaterial / 10 % accent is composition. The physical domain's, by right. Recorded as decided in the decision record §3. Nothing to approve — only to confirm it is really hers rather than the model's (card 36).
    • sage is membership. Not hers. F1's hard rule: "Använd aldrig godtyckliga HEX-värden. Varje färg i paletten har ett syfte och ett namn." sage appears nowhere in the corpus — not in F1, not in the tokens, not in the three archived interior drafts. This is the decision. Two routes: it enters F1 properly, documented the way every other member is — Pantone, CMYK, sRGB, HEX, a stated role, and a contrast row — or the intent is expressed through existing palette names. Route one is a real palette extension with a real ripple (tokens, the fitness check's out-of-set hex assertion, agent-baseline, the Swedish twin). Route two costs a sentence.
    • varmvit and ljusgrå are probably neither — they read as material descriptions rather than palette claims, and F1 already has vit (#FFFFFF), sand (#F2ECE4), sand 50 (#FAF8F6) and named warm greys with roles. Likely a rewording, not a decision. Confirm and close.

    The trap. foundation/colour.md is status: accepted and carries the freeze and twin-sync history from cards 5, 7 and 9 — the two Swedish rows that were deferred to the twin sync are still deferred. If sage goes in, it goes in through the same discipline: not a direct edit to an accepted page as a one-liner.

    Why this is worth deciding rather than deferring: the guide is currently the only statement of Aleris interior policy, it is in circulation, and it names a colour the brand does not have. Every week that stands is a week someone can specify sage on a wall and be right to think they were following the guide.

    Done when: sage has a route and, if it enters, a full F1 row plus the token ripple; varmvit/ljusgrå are either reworded or documented; and the decision record's §3 open half is closed.

    Two of three closed 2026-08-06. 70/20/10 needed no ratification, per the framing above — only card 36's confirmation that it's really hers. varmvit/ljusgrå resolved as wording, not decision: they map to Sand 50 (#FAF8F6) and Slate (#D7D2CB), both already named and roled in F1's Neutrala toner table. A pointer note added there rather than restating the mapping — same discipline tokens-are-canonical.md just formalised. Decision record §3 updated to match. sage alone remains, and it's blocked on card 36 — moved to Blocked on the board rather than left in Ready now with nothing actually pullable.

    English twin synced 2026-08-06, and it surfaced a bigger finding. foundation/en-draft/colour.md is not a translation of the Swedish page — its own frontmatter says translation_status: source, and its content is materially ahead: the post-supersede semantic naming (sand-50, gray-100, the seven-step orange ramp with interactive/brand split) that the Swedish page never received. Its own banner calls the Swedish page "outgoing... frozen until this one publishes," which per card 25's route B (Swedish stays the served site) may never happen as originally framed. The pointer note added there uses the English file's current names (sand-50, gray-100), not the Swedish page's Sand 50/Slate — so the two pointer notes are equivalent in meaning but not byte-identical, on purpose. Not resolved, flagged for Torfinn: whether the colour supersede's English-only content is stalled, abandoned, or still pending a publish path is a live question this session didn't raise or answer.

    ---

70. 58TSuperseded

    Review the icon allowlist — too conservative

    Done when the allowlist reflects a deliberately reviewed scope, not last review's default, and it is on main.

    Waits on 2026-09-26 · replaced by Torfinn's ruling that there is no allowlist at all: any Font Awesome Pro icon may be used except the floor's motifs. Retiring the machinery is card 167

    Detail

    Files: data-products/iconography/allowlist.json (the patient-facing list itself) · foundation/iconography.md (the four-context model and the governance rules each context follows) · baseline/iconography/index.html (the visualisation)

    New 2026-08-11. Torfinn: the allowlist is too conservative right now.

    What's already on record about it. foundation/iconography.md (accepted the same day, card 51/56 sequence) states the model this list is supposed to implement: patient-facing gets the strictest selection because the cost of a wrong icon is highest there — "editors choose icons from a reviewed allowlist rather than freely... the friction is the point." That's the right shape; the question this card raises is whether the current contents of the list match how strict that actually needs to be, or whether it's stricter than the cost-of-mistake principle it's supposed to implement actually calls for.

    Why this is [T]. Which icons clear the bar is a judgment call about what reads as trustworthy to a patient — not something to loosen mechanically without a reason for each addition.

    Done when: the allowlist reflects a deliberately reviewed scope, not last review's default, and it is on main.

    Progress 2026-09-05 — the data defects are fixed; the content half is still this card. sundviktlakemedel found (brief 2026-09-01) that all 78 entries carry __FILL_IN__ in both label fields, that the note claimed 79 icons and 55 ui-primitive entries while the array held 78 and 54, and that no test read the file. The note is corrected, and data-products/iconography/allowlist.test.ts now derives both counts from the entries, checks categories and families, and holds the placeholder total as a KNOWN figure of 78 — so filling labels moves a number the suite sees, and a new placeholder cannot hide under it. Eight mutations, eight fire. Still yours: the 156 label strings, and the scope review this card was opened for — the same brief found a payment icon is now a live need (Swish) and the list has none in any category.

    Reframed 2026-09-08 (Torfinn). The list is not too conservative by accident: it was curated once, on 2026-04-30, for one purpose — the patient-facing context, second-pass clinical trim, 78 icons — and has been read as the whole system's allowlist since. Widening it is the job. What must survive the widening is the floor, which is documented and sound: principles/iconography.md § the floor — weapons, logos and trademarks, religious symbols, anything aggressive or alarmist, never in any context — plus the curation decisions the allowlist's own note records (no person-iconography, people stay in photography per imagery; anatomy reduced to heart-pulse; specialty iconography deferred to custom extensions). So the review has two halves: state the floor as the allowlist's exclusion rule in schemas/icon-allowlist-entry.md where it can be checked, then widen the list per context (the four-context model gives internal tools "a generous selection list" already, on paper). .font-awesome.md (2026-09-08) tells /add-icon to refuse anything off the list until then, so the narrowness now costs every icon insertion. The file references above predate Phase 0: foundation/iconography.md is principles/iconography.md.

    ---

71. 12CCSuperseded

    AA pass two – add the steps, turn the test green

    Done when npm test passes with no allowlisted failures and the reference doc agrees with the token file.

    Waits on 2026-07-31 · replaced by card 19. Card 12 was going to add a confirm fill and a petrol step; the brief retires the confirm variant instead, so the two cards were doing one job in different directions. One list, not two – cookbook §12.

    Detail

    Files: baseline/tokens/aleris-tokens.css · baseline/tokens/tokens.test.ts · baseline/reference/aleris-design-tokens.md

    Deliberately a second pass, not folded into the supersede (decided 2026-07-29): the contrast test lands first with secondary and confirm failing, then this card fixes them, which makes the fix provable rather than asserted.

    Add the petrol step and the confirm interactive fill at the values from card 3. Repoint --button-secondary-hover-bg off petrol-300 to the new darker step. Add the confirm interactive fill below confirm-500 and repoint --button-confirm-bg and --button-confirm-hover-bg to it, leaving --status-confirm on confirm-500 so non-button uses are untouched. Remove the "Derived value – validate when a confirm scale is added to F1" comment at aleris-tokens.css:473 along with its Anchor justification.

    Then remove the known-failure markers from tokens.test.ts – the suite goes green. Update baseline/reference/aleris-design-tokens.md to match; that table has drifted from the token file before. Confirm the new confirm fill stays visually distinct from --color-goal-achieved #2E8540, which the token constraint requires.

    Done when: npm test passes with no allowlisted failures and the reference doc agrees with the token file.