Motir

Found while running MOTIR-3931. That card fixed every failing pair in the two mocks' product layer; this is what its element scan found in the layer it did not rule on. It is filed rather than swept because it turns on a DECISION that already has an answer in the other repository, and the two answers disagree.

The population, measured on this branch

Every element carrying its own text node was loaded in headless chromium and read for its resolved color against its effective background — the nearest ancestor with a non-transparent fill — then ruled against 1.4.3 at that element's own size and weight. The command is MOTIR-3931's, recorded in design-notes.md § The MUTED inks.

All light-theme; the dark arm is 0. #f4f3f1 is the mocks' doc-annotation SHEET — a raw scaffold colour, not an --el-* surface — so nothing in the token layer can be adjusted to fix this. It is the board a reviewer reads the asset ON: the panel captions, the viewport 1440 × 900 … rules, the measurement lines, and the green/struck spans a re-measurement uses to mark a number as replaced.

The 2.65 entry is the one to look at first and it is not the muted ink: b at 11px in #1aae39 is a green used to mark a REPLACED figure. Whatever is decided about captions, a colour-only mark at 2.65 also rests state on hue alone.

Why this is a decision and not a sweep

design-showcase.mock.html's own token block asserts the exemption in prose:

"The only raw values are the doc-annotation scaffold (sheet, captions, ref chips, viewport rulers), which is not product UI."

motir-core asked exactly this question and answered the other way. MOTIR-3054 — "decide whether a mock's board CHROME owes AA, then sweep or codify" — decided yes, and shipped it: motir-core PR #2133, "a design board's chrome owes AA — enforce the ink guard over both layers", with tests/theme/inkContrastMockScan.ts ruling on the stylesheet layer as well as the utility-class one, run by vitest.design.config.ts. Its reasoning was that the board is read by a person — Yue accepts Stories from these PNGs (Principle #18) — so "not product UI" is not the same as "not read".

motir-marketing has neither the decision nor a lane to enforce one. .github/workflows/ci.yml runs lint · typecheck · build · test; there is no vitest.design.config.ts and nothing in tests/ reads design/** for contrast. So this repository's assets can hold the opposite position indefinitely without anything noticing, and the next design card here inherits the exemption by reading it in a header comment.

What is owed

1. Adopt motir-core's answer or record a reason this repository differs. Adopt is the expected outcome — one project holding two answers to one accessibility question is the defect — but the alternative is a legitimate finding if these boards genuinely differ in kind, and it must then be written down rather than left as a header comment.
2. On adopt: sweep the 54 sites, which is a scaffold-colour change rather than a token swap — #f4f3f1 and the annotation inks are raw values these mocks own outright.
3. Give the repository a lane, or say why it has none. A decision with no enforcement in a repository that has never had one regresses on the next asset. motir-core's vitest.design.config.ts + inkContrastMockScan.ts is the shape to port; whether it is worth porting for two assets is part of (1).

Acceptance criteria

• The chrome question is DECIDED for motir-marketing and recorded in design/marketing/design-notes.md with the reason — adopting MOTIR-3054's answer, or differing from it explicitly. A commit message is not the record.
• If chrome owes AA: all 54 sites clear 1.4.3 at their own size and weight, re-measured by the element scan rather than by the edit, and both .png exports are re-taken at their own existing viewports (design-showcase 1440, landing 1320 — deviceScaleFactor: 2, dimensions otherwise unchanged).
• The b/s marks are dispositioned by name: at 2.65 and 4.07 they are the two entries a caption-only sweep leaves behind.
• The mocks' token-block header no longer asserts an exemption the repository has not decided — whichever way it goes, the header states the decision and cites it.
• If a guard lane lands, it joins ci.yml in the same change (that file's own header: "do not declare a gate before its job exists", and its converse).
• pnpm lint, format:check, typecheck, build, test.

Advisory dispositions

validate_work_item returned two, both plain advisory severity — the tier a narrow reading of the dispatch guard skips. Both APPLY and both are wired.

• reference · advisory — names MOTIR-3931 at in_progress — APPLIES. The 54-site count above was measured on MOTIR-3931's branch, and this card edits both mocks and design-notes.md — the same three files that card is rewriting. blocked_by wired.
• reference · advisory — names MOTIR-3984 at todo — APPLIES, for a different reason: a BINARY collision. Both cards re-export landing.png, which is 2.3 MB of unmergeable bytes, and both edit landing.mock.html. run.md's stacked-pull-request rule names this exact case and prefers the alternative it offers — sequence the two cards and cut the second branch off main after the first lands — so this is a blocked_by and a wait, not a stack. blocked_by wired.

Both edges are intra-container: this card was moved into MOTIR-656 alongside the two cards it depends on, which is log-bug.md's EDGE TEST answering YES rather than a placement chosen for tidiness (gate 7).

Boundary

Not the product layer — MOTIR-3931 closed that in design-showcase.*, and MOTIR-3984 owns the footer pair in landing.* and in the shipped component. Not motir-core — MOTIR-3054 is done there and nothing here re-opens it; it is cited as the decision to adopt or to differ from. No token change, since the annotation layer uses no --el-* surface at all.