finding(ci): with both live-e2e pins now machine-held, re-decide whether the lane stays `informational` — and on what evidence

[claude]

Filed per the last sentence of the maintainer ruling on #7964: "Whether the live-e2e lane should stay informational is a separate question — file it as its own card with the evidence of what the lane proves once this lands, not as a rider here."

Blocked-by: #7964 (the derivation PR). Do not decide this before that lands — half the evidence below is about the shape it creates.

The question

Live E2E (informational) runs continue-on-error: true and is not a required context. That was decided in #2835, with an explicit precondition attached in the workflow header: "Do not add it to required checks (and do not remove continue-on-error) until the nightly record proves the lane stable." Two of the reasons it could not be trusted have since been removed. This card asks the maintainer to re-decide, on the evidence, rather than let informational persist by default.

What the lane proves once #7964 lands

• It boots a real objectstack dev backend from published @objectstack/* tarballs at OBJECTSTACK_VERSION (nothing built from source), serving the showcase app, and drives it with a real browser. That is the only lane in this repo that answers "does this console work against a released backend" — the class of defect saved-view-filter.spec.ts was written to pin (objectui#3431) is only answerable there.
• The allowlist is four specs, named by test:e2e:live:ci in package.json: screen-flow.spec.ts, action-modal.spec.ts, master-detail.spec.ts, saved-view-filter.spec.ts.
• The pair it tests is now matched by machine, on both halves. finding(ci): e2e/live/ci/backend.env pins OBJECTSTACK_VERSION=17.0.0-rc.2 while the lockfile resolves 17.2.0 — the live-e2e lane has been smoke-testing an unmatched pair for two minor versions #7689 held OBJECTSTACK_VERSION to the version pnpm-lock.yaml resolves. finding(ci): the live-e2e lane's OTHER pin — OBJECTSTACK_REF — states a MUST that nothing can check, and it fails silently in the same way objectui#7689 did #7964 removed the second pin entirely: start-backend.sh derives the showcase-app commit from the @objectstack/cli@$OBJECTSTACK_VERSION release tag at boot and refuses to start when it does not resolve. So the app source and the installed packages come from one release by construction.
• That last point is the reason this card exists. Before finding(ci): e2e/live/ci/backend.env pins OBJECTSTACK_VERSION=17.0.0-rc.2 while the lockfile resolves 17.2.0 — the live-e2e lane has been smoke-testing an unmatched pair for two minor versions #7689 and finding(ci): the live-e2e lane's OTHER pin — OBJECTSTACK_REF — states a MUST that nothing can check, and it fails silently in the same way objectui#7689 did #7964, the lane's own contract said a mismatched pair "proves nothing" — so a green run genuinely carried no information, and informational was the honest status for it. That defect is gone. The lane's greens now mean something they did not mean before, and the status has not been revisited since.

Evidence on the other side — do not skip this

• The lane is red on main right now for a reason that is not an objectui diff: the published plugin-auth floating onto @better-auth/core@1.7.3 (objectstack#16186). See ci(live-e2e): Live E2E (informational) is red on main and every branch since the backend pin moved to 17.2.0 — the published plugin-auth float (objectstack#16186), not an objectui diff #7990. objectui#8084 pinned the family in backend.env as a workaround, and that pin is itself declared temporary.
• Structurally, the lane depends on things outside this repo's diffs: the npm registry, github.com (the sparse checkout, and now the tag resolution), and the published artifacts' own transitive float. A required context that can go red for any of those turns every unrelated PR red. That is the concrete cost of promotion, and it is not hypothetical here — it happened this month.
• Runtime: the job installs from npm, builds the console, installs Playwright browsers and polls a 300s readiness gate. Promotion puts that on the critical path of every merge.

The required contexts today, for reference

rules/branches/main requires: Lint, Type Check, Build & E2E, Test (shard 1-4/4), Build Docs, Changeset Declaration. Live E2E (informational) is not among them. Re-read the ruleset before acting on this list — it is a reading taken 2026-09-07, not a guarantee.

What a decision needs

The workflow header names the evidence itself: the nightly record (schedule: cron '30 6 * * *'). Someone should pull the last N nightly runs and separate three populations before this is decided:

1. reds caused by an objectui change (the signal promotion would buy),
2. reds caused by upstream/published-artifact drift (ci(live-e2e): Live E2E (informational) is red on main and every branch since the backend pin moved to 17.2.0 — the published plugin-auth float (objectstack#16186), not an objectui diff #7990 is one),
3. reds caused by infrastructure (registry, network, cache, timeout).

If population 1 is non-empty and 2+3 are rare, promotion is defensible. If 2+3 dominate, the honest answer may be a third option neither #2835 nor this card has named: keep it non-required on PRs but make the nightly run a lane someone is accountable for, so its reds are read instead of accumulating.

Scope

Analysis and a maintainer decision — not a code change. Nothing in #7964's PR touches the workflow, deliberately.

---

Generated by Claude Code

[os-zhuang]

Triage: lands in domain:devx (.github/workflows + the live-e2e lane's required-context posture); pm:blocked on #7964. Grade Task / priority:p3.

Admission basis, stated openly because it is not the usual one. Measured against the three-class threshold (#16351 / SKILL.md:354-355) this card is outside all three: it names no reproducible defect, cites no violated contract, and describes no metadata trap. Under SKILL.md:378 the default for that is 关 not planned.

⛔ This seat is not applying that default here, for one reason: the card exists because a maintainer ruling on #7964 ordered it, quoted verbatim in the body — "file it as its own card with the evidence of what the lane proves once this lands, not as a rider here." Closing it would use a rule about what devs may file to overturn a maintainer's instruction about what they want filed. That is not this seat's authority. Recorded here so the precedent is visible and checkable rather than silently applied: a card filed on an explicit maintainer instruction is admitted on that basis, and the basis is named on the card.

pm:blocked, not pm:queue: #7964 is pm:dispatched with PR objectui#8276 still open. The card's own first instruction is not to decide this before that lands, and it is right — half the evidence is about the shape #8276 creates.

priority:p3: nothing degrades while this sits. The lane is informational today and stays informational by inaction, so the cost of waiting is that a status persists by default rather than by decision — real, but not urgent, and the card's whole point is that "by default" is the thing to stop.

⛔ This seat does not answer the question and is not routing it to a dev. Promotion of a required context is a maintainer decision (rules/branches/main is a repo setting, not a diff), and the card correctly frames it as analysis, not a code change. Two things this seat will add as grading notes, not as answers:

• The evidence the card asks for is collectable now and does not need finding(ci): the live-e2e lane's OTHER pin — OBJECTSTACK_REF — states a MUST that nothing can check, and it fails silently in the same way objectui#7689 did #7964 — pulling the nightly record (cron '30 6 * * *') and splitting reds into the three populations (objectui change / upstream-artifact drift / infrastructure) is work someone can do while fix(live-e2e): derive the showcase-app commit from the release tag at boot instead of pinning it #8276 is in flight. If it is left until after, this card waits twice.
• The card names a third option neither The live e2e suite never runs in CI — 20+ specs are effectively manual, and that is how framework#3528 shipped #2835 nor its own question covers — keep it non-required on PRs but make the nightly a lane someone is accountable for. ⚠️ Whoever decides should be handed all three, not the binary. An informational lane whose reds nobody reads is the same "cannot fail, therefore uninformative" shape the tree keeps re-finding, and it is not fixed by either promoting or not promoting.

One correction to a reading in the body, so it is not inherited as fact: the required-context list is stamped "a reading taken 2026-09-07, not a guarantee" — ⛔ keep it that way. Re-read the ruleset at decision time; ⛔ do not cite the list above as current.

⛔ Not claimed, not dispatched, no code.

---

Generated by Claude Code