Planning bug: a card asserted the default E2E lane is cloud-on — it is off-cloud, and the whole two-arm plan was built on it
Opened by Zhu Yue ·
What the card said
MOTIR-4038, authored 2026-08-31: "Cloud arm (the default E2E build, MOTIR_CLOUD=true)".
What is true
motir-core playwright.config.ts sets no MOTIR_CLOUD, and says so in its own words, at the testIgnore it uses to keep the cloud specs out:
"The cloud-on billing journeys (Subtask 8.1.10) run in their own MOTIR_CLOUD lane (playwright.cloud.config.ts) — excluded here so this off-cloud suite never boots them (they 404 without MOTIR_CLOUD, and turning it on globally would break unrelated at-scale/menu specs)."
playwright.cloud.config.ts:111 and playwright.acceptance.config.ts:99 are the only two lanes that set it. Measured on origin/main at 4f3121228.
Why it matters — the error is not the sentence, it is what was planned on it
The card is the story's E2E subtask, and the sentence decides which arm each lane can drive. Backwards, it plans the self-host arm as the hard one needing a special run and the cloud arm as free — the exact inverse. Built to the card, the run would have written a self-host arm that cannot execute in the lane it was placed in.
It also hid the story's largest consequence, which no card names at all: four existing E2E specs assert the public-projects capability while running off-cloud (epic-privacy-flow, follow-the-build-flow, public-project-flow, build-in-public-flow). They passed because the capability was unconditionally on. Gating it makes them assert a product that is switched off, so they had to move to the cloud-on lane — which is the billing-cloud leg of e2e-at-scale, push-to-main or a labelled PR, not every PR. A coverage reduction nobody had costed, discovered at build time.
The rule it is about
The global lesson "A test lane's ability to drive a path is a property of the LANE'S CONFIG, never of a sibling test's subject" (c6085ctcyup76rg7gqre06jkr) states this exactly, and was reinforced against this occurrence — its second. The lesson's howToApply asks the author to "check it there", in the lane's own config. Nothing in the authoring path makes anybody do that.
Fix
The planning-side ask: a card that names a TEST LANE's capability cites the lane's config file, not a sibling spec. Whether that becomes a plan-rules/type-test.md bar or is left to the lesson tier is the decision this card carries.
Evidence
motir-coreorigin/main4f3121228—playwright.config.ts(noMOTIR_CLOUD; thetestIgnorecomment quoted above),playwright.cloud.config.ts:111,playwright.acceptance.config.ts:99.github/workflows/ci.yml— thebilling-cloudleg sits ine2e-at-scale, whoseif:isgithub.event_name == 'push' || contains(github.event.pull_request.labels.*.name, 'e2e-at-scale')- The correction, in full, is a comment on MOTIR-4038 and the header of each moved spec.
Discussion
No comments yet.
Adding to this discussion signs you in on app.motir.co and brings you back to this request.