feat(unic-archon-dlc): an annotation must reach a criterion or be refused

The worked example

The card's variant=default, state=default cell (189:5267) carries a fade animation annotation. docs/agents/figma.md records it. Both runs' contracts record it. Neither run implemented it. No .tsx or .css in either build carries a transition, an animation or a keyframe.

Nothing in the chain turns a recorded annotation into a criterion, a ticket, or code. It is written down and then dropped.

And nothing says what fade means, which is why neither run could act on it even in principle. That half is now a design question in the Consumer's tracker.

The general shape

A fact reaching a contract is not a fact reaching anything.

The same applies to arrangement: both contracts record the card's layout with y-coordinates — slot at 16, text frame at 104 — and the badge and icon position was wrong in both runs, with no check comparing the two.

The open question

When /specs reads something it cannot turn into a code shape, what should happen? Candidates, none decided:

• Refuse it — a run stops and asks what the annotation specifies, the way it stops for a missing focus value.
• Carry it forward as an open item — the contract records it as owed, and /tickets must give it a criterion or explicitly waive it.
• Route it to the design tracker — the same path the unbacked-literal finding takes.

The refuse option has precedent in the command already. The carry-forward option needs a reader, and this repository has just learned what happens to records with no reader.

Full evidence: docs/research/2026-08-31-dlc-run-2-findings.md.

Start with docs/research/2026-08-31-dlc-run-2-findings.md and docs/agents/figma.md, then inspect the /specs and /tickets paths and both run contracts. Trace how the fade annotation and recorded coordinates are handled, and define the missing behavior and acceptance criteria before implementation. Done means unsupported annotations and arrangement facts no longer disappear without an explicit outcome.