Planning bug: `run.md` never says the at-scale lane is LABEL-gated, so a run labels the PR AFTER creating it — a second trigger at the same sha whose cancelled run poisons the card's CI verdict

Type · planning bug (the runbook's account of the PR-opening step, one trigger change out of date) Filed about · MOTIR-3206 / motir-core PR #2192, 2026-08-20 Fix lands in · motir-meta/prompts/run.md (branch + PR, never a direct commit to main)

What the runbook says today

prompts/run.md step 9 — "Open the feature PR, then IMMEDIATELY transition_status in_progress → implemented" — says nothing about labels, and e2e-at-scale does not appear anywhere under prompts/. MOTIR-3148 took the at-scale E2E legs (board-at-scale, collab-at-scale, reporting-at-scale, billing-cloud) off the PR trigger on 2026-08-19: they now run on push-to-main, or on a PR labelled e2e-at-scale. A run that needs those legs to gate its own PR has to discover the label from the workflow file or from nothing at all, and — having opened the PR first, as step 9 instructs — applies it afterwards.

Why applying it afterwards is not merely untidy

A labeled event triggers ci.yml again at the unchanged head sha, and the workflow's concurrency group (cancel-in-progress, deliberate — MOTIR-3106) cancels the run already in flight. Two runs at one commit is precisely the state MOTIR-3209 shows Motir's own check-row ingestion cannot represent: the cancelled run's rows merge by check NAME with the survivor's, its un-expanded ${{ matrix.* }} legs and its cancelled Deploy to Fly never get overwritten, and the card's verdict reads failing forever on an all-green PR. On #2192 that stranded the card at implemented for six hours with a comment naming four checks that had passed.

So the cost of the missing sentence is not one wasted run — it is a card that never reaches In Review, on the very lane a run reaches for when it wants MORE verification than the default PR gate gives.

The rule to write

In run.md step 9, at the PR-opening instruction:

Every label the PR needs goes in the gh pr create call (--label e2e-at-scale), never a gh pr edit --add-label afterwards. A label added after the PR exists re-triggers ci.yml at the same head sha and cancels the run in flight; two runs at one commit corrupt the card's CI verdict (MOTIR-3209) and CI then never promotes it out of Implemented.

And, in the same step, the trigger fact that is missing outright:

The at-scale E2E legs (board-at-scale, collab-at-scale, reporting-at-scale, billing-cloud) run on push-to-main or on a PR labelled e2e-at-scale (MOTIR-3148). If the card's change can affect them — the planning canvas, the board at scale, billing/cloud surfaces — pass that label at creation, because otherwise the lane first runs AFTER the merge, where its failure blocks the deploy instead of the PR. That is how MOTIR-3154 held main red.

Co-located write — coordinate, do not block

MOTIR-3150 (todo) amends step 8 of the same file: the design/* / docs/* branch-prefix account of what CI skips, which MOTIR-3148 also falsified. Different clause, adjacent step, one file — a rebase, not a dependency, so no blocked_by edge. Recommended order: land MOTIR-3150 first (it rewrites more of the surrounding prose), then this one on top; whichever runs second re-reads the merged step before editing.

Nor is MOTIR-3209 a blocker. This card writes prose that CITES that bug as the reason for a "never"; it consumes no code, symbol or schema from it, and the rule is correct — and worth writing — whether MOTIR-3209 is fixed today or never. The likely-missing-edge advisory on it is a false positive of the kind the detector is designed to produce; it is disposed of here in words, deliberately, rather than by wiring an edge that would hold a 25-minute prose fix behind a migration.

Acceptance criteria

1. git grep -c 'e2e-at-scale' prompts/ on the merged branch returns non-zero — the label's existence and its trigger are stated in the runbook, not only in ci.yml.
2. git grep -n 'add-label' prompts/run.md finds only the prohibition (the rule naming it as the thing NOT to do), never an instruction to use it.
3. The rule is stated at the step where the PR is opened, not in a separate appendix — a run following step 9 top-to-bottom cannot open the PR before reading it.
4. The stated reason is the cancelled-run corruption, and the prose cites the bug's id so a future reader can check whether the mechanism still holds. (The "never" survives that bug's fix either way — a cancelled run wastes a full at-scale matrix — and this criterion is satisfied by the citation alone, not by anything landing in motir-core.)
5. Landed as a branch + PR against motir-meta that the user merges; no direct commit to main, git add of the specific file only (shared checkout).

Out of scope

The motir-core ingestion defect itself (MOTIR-3209) and anything in ci.yml. This card changes prose only.