Motir

Drive one real release end to end through the machinery the story builds, and prove it produced artifacts a stranger can fetch. Only a real merge can show this, which is why it is a card and not an acceptance criterion inside the story.

Why it hangs at the ROOT with no blocked_by edge — stated, not left silent

It cannot be a child of the story: completing a container cascades done onto its children, and the container is completed by its own merge — so a child asserting "the release worked" would be closed by the very event it is supposed to verify, before anyone looked.

It also carries no blocked_by edge, and that is a limitation rather than a judgement. Dependency edges run between same-kind siblings under one parent; this is a root-level task and its real prerequisite is a story under an epic, so the graph has no legal way to express "after that story." The ordering is therefore recorded here, in words: do not start this until the story's four cards have merged. Nothing mechanical will hold it back.

Its relationship to the OVERDUE release — not a duplicate

MOTIR-3850 owns cutting the release that is overdue now, by hand, and it should not wait for any of this. This card is a different release: the FIRST one cut through the new lane, whenever that falls. Two things make it distinct rather than a second copy — it exercises the automation rather than a person's shell, and it covers all three published packages, where MOTIR-3850's criteria are about @motir/cli and its sandbox image. If the automation happens to land before MOTIR-3850 is discharged, say so on both cards and let one release satisfy both.

The walk

1. Open a small pull request touching one of the three packages; add a changeset to it (pnpm changeset); merge it.
2. Watch the Version Packages pull request appear or update. Confirm its author is the App, not a person — that is what proves the token wiring.
3. Merge the Version Packages pull request.
4. Watch the tag push, then watch the downstream lanes fire on their own. This is the step GITHUB_TOKEN cannot do, and seeing the runs appear is the only proof that the App token was used.
5. Fetch each published artifact as a consumer, not as the publisher.

Acceptance criteria

• A Version Packages pull request was opened by the App and merged, and its number is quoted here.
• The tags pushed by the lane fired the downstream lanes — the triggered run ids are quoted, and each shows push on the tag as its event. A green run list is not enough: quote the run whose trigger was the tag.
• npm pack @motir/cli@<version>, @motir/brand@<version> and @motir/design-system@<version> each succeed with NO credential, and the three resulting shasums are quoted. Not "npm shows the version" — the pack, anonymously, because that is what a consumer actually does. Do the same for every package whose version moved; a package that did not move is named as not-moved rather than skipped silently.
• docker pull ghcr.io/moooon-b-v/motir-sandbox:claude-<version> succeeds anonymously if the CLI was among the packages released, and its digest is quoted.
• The next scheduled sandbox-staleness run is green, quoted by run id — the only signal that the condition actually cleared.
• If any step failed, the failure and its cause are recorded HERE before anything is re-run. A first release that needed three attempts is the most useful thing this card can produce.

Context refs

• The story and its lane — the machinery under test.
• MOTIR-3850 — the overdue hand-cut release, deliberately independent of this.
• .github/workflows/sandbox-staleness.yml — the scheduled tripwire whose green run is this card's terminal signal.