Skip to content

moooon

Motir

Vibe your whole project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.

  • Vibe Project
  • Open Source
  • AI Agent
  • AI Loop
1
requests
0
upvotes
145
planned
1,361
shipped

Motir · Roadmap

MOTIR-4040To Do

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-core origin/main 4f3121228playwright.config.ts (no MOTIR_CLOUD; the testIgnore comment quoted above), playwright.cloud.config.ts:111, playwright.acceptance.config.ts:99
  • .github/workflows/ci.yml — the billing-cloud leg sits in e2e-at-scale, whose if: is github.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.

Add a comment