QA wave R0: provision the shared QA tree and take the machine-lane baseline at e4e5c6e3

[os-zhuang]

Part of #9296. Round 0 of the full platform-checklist regression — everything the later rounds stand on. This card produces no PR and no qa-run issue; it produces one comment on itself carrying the readings, and a structured report to the PM.

What this round owns

1. One QA tree for the whole wave. git worktree add ../objectstack-qa-wave <sha> at e4e5c6e3c608b1b807c83a0d5b734f213eb1a1dd, then pnpm install there. Re-fetch first and record the sha you actually get — if main moved, the wave re-pins to yours and you say so.
   • ⛔ Do not create a second worktree or a second pnpm install anywhere. The container has a fixed disk allowance (~30 GB free at dispatch); rounds R1/R2/R3 all reuse this one tree. Isolation between runs is per-item port + file DB, not per-item tree.
2. Console build — start it first, it is the long pole. pnpm objectui:build builds @object-ui/console at the pinned .objectui-sha (665661ab…) into packages/console/dist. Cold monorepo: budget 10–30 min; run it in the background while the gates below run. ⛔ Never pnpm objectui:refresh — that re-bumps the pin to the local ../objectui HEAD (currently 195b9e4a, ≠ the pin) and every later browser verdict would describe a commit this repo does not pin.
   • packages/console/dist does not exist right now, so /_console/ 404s until this finishes. That is a prerequisite, not a defect.
   • Finish with pnpm check:console-sha and report its output.
3. Repo machine gates, with timings (the timings are a deliverable — they budget R1–R3):
   • pnpm check:platform-checklist (expected green: 15 areas / 182 items / 28 kinds mapped / 2 waived)
   • pnpm typecheck
   • pnpm test
   • objectstack verify against the showcase app, and the packages/qa/dogfood golden suite
4. Smoke the boot path the later rounds depend on: pnpm -C examples/app-showcase exec objectstack dev --ui --seed-admin -p <free non-default port> -d file:/tmp/qa-wave/r0.db, poll /api/v1/health → 200, confirm /_console/ serves after the build. Record the port/DB convention the next rounds should follow.

Reporting

Comment on this issue (English) with: the sha actually tested, .objectui-sha, per-gate command → exit status → wall-clock, the console-sha comparison, and the boot smoke result. Then return the PM report JSON.

A red gate on main is a finding, not your task. Do not fix it: reproduce it twice, check whether it also fails on the merge-base, and file it as its own issue with the failing command and output. Say so in the report.

Non-negotiable for this card

• No PR from this card. Nothing you produce lands in the repo tree.
• Report faithfully: a gate you did not get to is "not run", never "passed". If pnpm test cannot finish in a sane budget, report how far it got, which packages are covered, and stop — a partial run reported honestly is a good outcome; an implied full green is not.

[os-zhuang]

Claim: PM loop round 1 (QA wave #9296)
Session: session_01Ai9gUdihXjg7FumzsBNSSs
Branch: none — this card produces no commit and no PR
Worktree: objectstack-qa-wave (the shared QA tree this card provisions; every later round reuses it)
Domain: domain:devx
File surface: none in the repo tree. Writes go to /tmp/qa-wave/**, node_modules/, and packages/console/dist/ (git-ignored build output). Stop on breach and explain in the report.
Container & model: M, mode:subagent, model: opus — install/build failure diagnosis and the "is this red pre-existing on main?" call are judgment, not gate-mechanical.
Serial constraints cleared: no in-flight card touches the repo tree from this wave. Runs concurrently with #9299, which is disjoint by construction — #9299 edits docs/qa/platform-checklist/** in its own worktree and is barred from pnpm install, so the two never contend for the container's disk allowance.

Routing authority: maintainer direct-dispatch channel — 「按照你的建议执行」 (2026-08-17), authorizing the five-round orchestration proposed in-session and recorded on #9296.

---

Generated by Claude Code

[os-zhuang]

R0 machine-lane baseline — complete

Bottom line: the repo is green at the pinned sha. Every gate on this card ran to completion and passed. Two red gates were hit along the way; both are filed, neither was fixed here, and neither is a product defect at e4e5c6e3.

Sha actually tested

origin/main was re-fetched before provisioning and had not moved — no re-pin was needed.

framework sha under test	e4e5c6e3c608b1b807c83a0d5b734f213eb1a1dd
origin/main at provisioning time	e4e5c6e3c608b1b807c83a0d5b734f213eb1a1dd (identical)
.objectui-sha	665661ab093263f39f2e660a295ea615dbcee35a
QA tree	/home/user/objectstack-qa-wave, detached HEAD, one pnpm install
container	4 CPU / 15 GB RAM, node v22.22.2, pnpm 10.31.0, vitest 4.1.10
disk after everything	11 G used, 27 G free

Gates

command	exit	wall clock
git worktree add --detach /home/user/objectstack-qa-wave e4e5c6e3	0	~7 s
pnpm install (the only one)	0	35 s
pnpm check:platform-checklist	0	1 s
pnpm typecheck	0	704 s (11 m 44 s) ⚠️ contended
pnpm objectui:build — cold, attempt 1	1	18 s
pnpm objectui:build — cold, attempt 2 (clean repro)	1	9 s
pnpm exec turbo run build --filter=@objectstack/client... (workaround)	0	474 s (7 m 54 s)
pnpm objectui:build — attempt 3, after workaround	0	509 s (8 m 29 s)
pnpm check:console-sha	0	1 s
pnpm -C examples/app-showcase exec objectstack verify	0	16 s
pnpm --filter @objectstack/dogfood test — beside the console build	1	620 s
pnpm test — turbo default concurrency 10	1	35 s (aborted at 26/44 tasks)
pnpm exec turbo run test --concurrency=2	1	37 s (aborted at 17/21 tasks)
pnpm exec turbo run test --continue --concurrency=2	0	2257 s (37 m 36 s)

⚠️ The typecheck number is contended — it ran concurrently with the client dep build, and both were in @objectstack/spec's DTS phase at once (load average peaked at 12.3 on 4 CPUs). Treat 704 s as an upper bound; unloaded it will be meaningfully less.

pnpm test — the real reading

The default invocation is not usable as a gate on this box: @objectstack/types#test fails on a 5 s timeout and turbo aborts, leaving 18 of 44 tasks unrun. Cutting the fan-out alone does not fix it either (it still failed at --concurrency=2). The reading that actually covers the repo:

pnpm exec turbo run test --continue --concurrency=2
Tasks:    135 successful, 135 total
Cached:    71 cached, 135 total
  Time:    37m35.763s

72 test packages · 43 531 tests passed · 208 skipped · zero failed suites. This is a complete run, not a partial one — every task reached a terminal state and every one succeeded.

Console build

packages/console/dist was absent at t0, as expected — a prerequisite, not a defect. (Stated for completeness: /_console/ was never probed before the build, because the server was first booted after it; the absence itself is what was verified.)

✓ Console dist matches the objectui pin (objectui@665661ab0932).

dist stamp	665661ab093263f39f2e660a295ea615dbcee35a
repo pin	665661ab093263f39f2e660a295ea615dbcee35a
verdict	equal
dist size	52 MB (52 272 KB)
bundle canary import/jobs	present

scripts/build-console.sh did not touch ../objectui — confirmed, as the script documents. It fetched the pinned commit into ../objectui/.git (the commit was not present locally) and built from its own worktree at /home/user/objectstack-qa-wave/.cache/objectui-665661ab0932. ../objectui HEAD is still 195b9e4ab with a clean working tree. objectui:refresh was never run.

Cost to budget R3 against: the console build alone is ~8.5 min when spec/core/client dists already exist. From a genuinely cold tree the real number is ~16.5 min (474 s deps + 509 s console). The dists persist in the shared QA tree, so R1–R3 pay zero — the console is already built and stamped.

Boot smoke — green

pnpm -C examples/app-showcase exec objectstack dev --ui --seed-admin -p 3100 -d file:/tmp/qa-wave/r0.db

probe	result
/api/v1/health	200 in 10 s from launch — {"status":"ok","version":"1.0.0"}
/_console/	200, 6467 B text/html, hashed asset chunks (index-B1QKp1HQ.js, framework-DFLyxMlO.js, ui-components-CEpu_S1i.js)
/_console/index.html	200, identical
banner	Console: http://localhost:3100/_console/ · ConsoleUI plugin in the loaded set
seeded admin	admin@objectos.ai / admin123

objectstack verify against showcase: 15 verified, 0 gaps, 0 FAILED, 1 needs-fixture, 7 skipped (0 mismatches) — ✓ verify passed — no runtime failures. The 1 needs-fixture is showcase_account (the auto-record trips the app's own Tax-ID / email / support-config validators); the 7 skips are its dependent relations plus 2 external read-only federated objects. Not defects.

Port / DB convention for R1–R3

The QA tree is provisioned and must be reused as-is — do not create a second worktree and do not run pnpm install again.

• Tree: /home/user/objectstack-qa-wave (detached at e4e5c6e3, never commits). Console dist is built and stamped; pnpm check:console-sha is green. ⛔ Never pnpm objectui:refresh.
• Ports — one per concurrently-running item, isolation is per-item port + file DB, never a per-item tree. R0 used 3100 and has released it. Suggested non-overlapping bands: R1 3110–3129, R2a 3130–3149, R2b 3150–3159, R2c 3160–3169, R3 3200+, one band per area card. Confirm free before binding rather than assuming.
• DB: -d file:/tmp/qa-wave/<round>-<item>.db, and rm -f it before boot — a stale file silently inherits the previous item's rows. /tmp/qa-wave/ already exists.
• Seed: --seed-admin on an empty DB yields admin@objectos.ai / admin123.
• Boot budget: health 200 in ~10 s on an idle box; allow 60 s before calling a boot failed.
• ⛔ Do not run a test suite next to a build. Both reds below were timeout flakes caused by exactly that. R3's browser rounds should keep concurrency to 2–3 on this 4-CPU box.

Red gates — filed, not fixed

Both reproduced twice, both checked for whether they are pre-existing, neither is a defect in the product at this sha.

• pnpm objectui:build fails on a cold tree: build-console.sh pre-builds @objectstack/client outside turbo, so spec/core dists are missing and the DTS build dies #9307 — pnpm objectui:build fails on a cold tree. build-console.sh pre-builds @objectstack/client with a bare pnpm build instead of through turbo, so turbo's dependsOn: ["^build"] is bypassed, spec/core dists don't exist, and the DTS pass dies. Latent since b990bc258 (2026-07-02) — that block is unchanged across 3549 commits, so it is pre-existing, not a regression. It also self-heals on retry (tsup writes dist/index.mjs before the DTS step, and the guard tests for that file), which makes a deterministic ordering bug read as flake. Workaround used here: pnpm exec turbo run build --filter=@objectstack/client... first.
• flaky: two default-timeout tests red pnpm test under full-repo parallelism — types/src/node.test.ts (5s) and dogfood/test/semantic-roles.dogfood.test.ts (10s hookTimeout) #9311 — two default-timeout tests red the suite under any parallel neighbour: types/src/node.test.ts:178 (5 s testTimeout) and dogfood/test/semantic-roles.dogfood.test.ts:52 (10 s hookTimeout against a bootStack measured at 27 s unloaded). Both pass in isolation; both passed in the full --continue --concurrency=2 run. Same class as the closed precedents flaky: lazy-deps 的两条 dist 探针用例在整仓并发下撞 5s 默认超时(兄弟用例已设 30s) #3662 / plugin-audit 的 zh-CN 本地化用例在全仓并行下必然超时：冷 import('@objectstack/core') 撞 20s testTimeout #4186 / protocol-handshake 的 ReDoS 断言用绝对 50ms 墙钟，并行满负载时会把无关 PR 染红 #4485 / lint: runtime-lazy-deps.test.ts "gating a flow in-process" runs on the default 5s timeout and flakes under load — its cold-load sibling already carries COLD_LOAD_TIMEOUT_MS #5421 / flaky(core): health-monitor.test.ts 的「leaves no ref'd timer behind when the health check wins the race」(#4875)在合并队列全量跑间歇红 —— 踢掉 PR #6269 一次,重排即过 #6329.

No PR, no commits, nothing landed in the repo tree from this card.

---

Generated by Claude Code

[os-zhuang]

Returned to pm:queue — dead dispatch, nothing was ever delivered. Maintainer-authorised sweep of stale pm:dispatched cards; PM seat, session session_01NYgmGheCzM6NrHZN436Cxf.

Why this card is being returned rather than left dispatched

pm:dispatched asserts "a seat is working this". That assertion was true when written and nothing has re-checked it since — so a card whose seat died stays invisible to every queue query while reading as taken. This one measured dead on all four independent signals:

signal	reading
last issue activity	2026-08-17T13:22:42Z — ~18h
open PR	none
remote branch claude/issue-9298-*	none (git ls-remote)
commits on main citing #9298	none (git log origin/main --grep)

The last row is the one that matters. Two other cards in this same sweep looked equally dead by the first three signals and turned out to be finished — #8193 (both halves merged, closed just now) and #9190 (fix landed via #9324). The difference is visible only in main's history, because a merged PR deletes its branch, and a PR that says Part of rather than Fixes leaves no link on the card at all.

Here that row is empty. Nothing landed, and no branch was ever pushed.

What the next seat should know

Do not treat this as a fresh card. It was dispatched once and produced nothing, so the first question is whether the card is still well-formed — R0 provisions a shared QA tree and takes a machine-lane baseline at a named commit (e4e5c6e3), and a baseline pinned to a commit that is now far behind main may need re-anchoring before the work means anything. Re-verify the premise before claiming.

No prejudice against the original seat: agents die on quota and on rate limits, and tonight two did. The defect is that nothing noticed for eighteen hours.

---

Generated by Claude Code

[os-support-ai]

Triage: routed domain:devx (half-annotated sweep — pm:queue with no lane meant no lane's listing surfaced it): provisioning the shared QA tree and taking the machine-lane baseline is repo/workflow infrastructure. The QA wave's orchestration context lives on the #9296 anchor; this card is the R0 execution ticket. (Triage seat, session session_019gCKd9EZfQ6MbGTnMHHJvW.)

---

Generated by Claude Code

[os-zhuang]

清 assignee — #11196 维护者裁决 2026-08-23「A:本席清 agent 残留」,skills 席 session 757f0dc0-5dae-51d7-9053-c15c57ebfe3b。证据:08-18 已有明确判定「Returned to pm:queue — dead dispatch, nothing was ever delivered」,该回收只翻了标签——assignee 是死认领残留的教科书案例。标签未动;新认领席重新 assign + 声明即可。

---

Generated by Claude Code