Motir

Found by Yue, on the card itself: "I don't see the design result in 2413." The run had reported MOTIR-2413 In Review with a PR link, and the card showed nothing.

What happened

A design child's deliverable is the design result on the work item — the note, the mock and the screenshot, rendered in the Design result panel. It is a PUBLISHED ARTIFACT, and it publishes from CI: a step in ci.yml's Design asset guards job (scripts/upload-design-assets.mjs, docs/decisions/design-result.md §6), keyed off the design/MOTIR-<n>-<slug> branch.

That job failed on the first push of PR #2118, and the publish step runs after the guard step in the SAME job, so it never executed. Two dead paths in tests/design-asset-addresses.test.ts, both authored by the run: a token block extracted verbatim from theme.css carried a comment citing lib/projects/avatar.ts, and the notes cited an ADR that ships on the story's parent branch.

The run reported the card In Review on the strength of the PR link and stopped. Nothing was on the card for ~20 minutes until Yue asked.

Two rules existed and neither fired

1. The artifact-obtainable pre-done check (run.md, Build/serve rules) is exactly this situation — "when the card's deliverable is a PUBLISHED ARTIFACT ... the card is not finishable until YOU have OBTAINED that artifact from where its CONSUMER will obtain it", and it names green CI as one of the three signals that look like evidence and are not. It enumerates its artifact classes: a container image, an npm / GHCR package, a release binary, a tagged release. A design result is none of those, so the rule reads as being about someone else's card. The enumeration is doing the work of a definition, and a reader matching their card against the list correctly concludes it does not apply.

2. The parent-run DESIGN STOPPER step (run.md step 5a) says: produce the three-file asset, open its own PR, do not auto-merge, STOP that chain and report the design PR. It ends at the PR. Nothing in it says the result must reach the card, which is the only place the design is actually consumed — by the reviewer, and by the next motir run reading it as a design reference.

There is also a local memory (run-the-guard-lane) saying a design/* branch must run vitest --config vitest.design.config.ts before pushing, because that is the one CI lane the branch prefix does not skip. It is not in the runbook, and it was not run.

Why this is worth a card rather than only a lesson

The failure mode is not "I forgot". It is that a card whose artifact is published by CI has no local moment at which the deliverable is visibly missing. Everything the run touches succeeds: the files are written, the commit lands, the push succeeds, the PR opens, the link is real. The absence lives on a surface the run never opens. That is the same structure the artifact-obtainable rule was written for after three occurrences in one epic — and the rule missed this instance because its examples are a closed list.

The fix, already applied

• run.md's artifact-obtainable check: the artifact-class list gains a design result, and the class test is stated as a QUESTION (does a consumer obtain this from somewhere other than the branch?) rather than as an enumeration to match against.
• run.md's parent-run step 5a and the single-item design flow: the design stopper does not end at the PR. It ends when the publish line is in the CI log and the evidence id is on the card — and it names the guard lane to run BEFORE pushing, since a failing guard silently skips the publish that shares its job.
• notes.html carries the entry.

Acceptance criteria

• No product change is owed by this card; the run.md amendment and the notes.html entry are its whole deliverable, and both land with it.
• If a second artifact class turns out to be missing from the same list, the enumeration is replaced by the question outright rather than extended again.

Context refs

• docs/decisions/design-result.md §6 — the CI trigger, its auth, and the continue-on-error prohibition that makes a failed publish visible as a red check.
• .github/workflows/ci.yml — the Design asset guards job: guard step, then publish step, one job.
• scripts/upload-design-assets.mjs — resolveTargetKey, branch first, then title.
• prompts/run.md — the artifact-obtainable pre-done check; parent-run step 5a.
• The card: MOTIR-2413. The run: MOTIR-2725. The control that proved the pipeline works: MOTIR-2890's design PR, Published 3 design artifact(s) to MOTIR-2890.