[finding] `@objectstack/cli`'s test suite costs ~2.8× the per-test-file norm, and on its own exceeds #4859's Test Core shard budget

[os-elon]

Observational finding from the #10149 / #10056 measurement (PR #10151). Filed unassigned, no labels — left for triage to grade. Not a claim that anything is broken: the suite passes, and this is a cost measurement.

What was measured

Per-package suite durations read out of the turbo task groups in merge_group CI job logs, against each package's test-file count in the same tree (the count is what scripts/partition-test-shards.mjs uses as its shard weight):

package	test files	measured duration	s/file
@objectstack/cli	135	548.6s (run 32352993803) / 474.4s (run 32233301407)	3.5–4.1
@objectstack/spec	414	496.4s	1.20
@objectstack/service-automation	83	118.9s	1.43
@objectstack/driver-turso	39	53.5s	1.37
@objectstack/client	24	34.7s	1.45
@objectstack/example-showcase	21	21.6s	1.03

Every other package measured lands in a ~1.0–1.45 s/file band. @objectstack/cli sits at 3.5–4.1 — roughly 2.8× the norm — in two independent runs a day apart.

For scale: at 135 files it is 5.7% of the workspace's 2348 test files, and it consumed 548.6s of a 987s (16m27s) Test Core shard — 56% of that shard's wall-clock.

Why it is worth a card of its own

Two reasons, both independent of how #10149 is decided:

1. It is the single largest lever on the Test Core critical path. Sharding is by package, so a shard can never finish faster than its heaviest package. @objectstack/cli at 548s (9m09s) already exceeds ci: merge queue 吞吐优化——Test Core / Dogfood 各 2→3 分片 + 队列失败自动分诊评论 #4859's Test Core 最慢分片 ≤ ~7min acceptance threshold by itself — no shard count and no weight function changes that. (@objectstack/spec at 496s / 8m16s is the other one over the line, but at 414 files its per-file cost is normal; it is big, not slow.)
2. The per-file outlier is the interesting part. The partitioner's weight proxy assumes wall-clock is dominated by fixed per-file cost (module-graph re-execution per file under isolation). That assumption holds within ~±20% across every other package measured. Whatever makes cli's files ~2.8× more expensive is a property of that suite, not of the sharding — likely worth understanding before anyone re-weights around it.

Not investigated here: why. Candidates worth a look are per-file module-graph size (cli pulls a wide dependency closure), process/fixture setup per file, and real subprocess or filesystem work in the suite. The vitest summary lines in the job logs break Duration into transform / import / tests, which is the cheapest next measurement.

Method

Durations come from the vitest summary inside each turbo task group in the queue-build job logs, read via the GitHub Actions API; test-file counts come from re-running countTestFiles() (scripts/partition-test-shards.mjs) over the same tree. Sample is small — 6 packages with usable per-package output across 3 merge_group runs (2026-08-19 / 2026-08-20), because a job log exposes only its last ~5000 lines and so only the tasks that finished last. The cli figure is the one measured twice.

Refs

• merge queue 关键路径回归:Test Core 最慢分片 16m28s、Dogfood 11m43s —— #4859 的两条验收判据均已不成立,且 #5401 方向 C 的触发条件已满足(实测) #10149 — the merge-queue critical-path card this came out of; its §3 weight-proxy question is what prompted the measurement
• [finding] --union-into pushes an ABSOLUTE packages.items[].path while turbo ls emits repo-relative ones, so the document it hands the shard partitioner is heterogeneous #10056 — the sibling path-convention card, landed in PR fix(devx): one path convention for the shard package list, and the measurement ranking the Test Core imbalance hypotheses #10151
• ci: merge queue 吞吐优化——Test Core / Dogfood 各 2→3 分片 + 队列失败自动分诊评论 #4859 — the source of the ≤ ~7min Test Core acceptance threshold
• PR fix(devx): one path convention for the shard package list, and the measurement ranking the Test Core imbalance hypotheses #10151 — carries the full measurement, including the shard bin weights (783/783/782) and the Turbo cache attribution

Generated by Claude Code

[os-zhuang]

Triage: routed domain:cli (the measured subject is @objectstack/cli's own suite), kept as finding — an honest cost measurement with nothing broken, and its actionable half (the vitest transform/import/tests breakdown, then whatever that names) is better shaped after #10149's merge-queue decision lands, which this card is direct evidence for. Cross-referenced from that decision's analysis; first-touch grading will revisit if #10149 resolves without absorbing it.

---

Generated by Claude Code

[os-elon]

Claim: PM loop round R2
Session: session_0185KTgmREZA4sY5pnRbubXj
Branch: claude/issue-10152-cli-suite-cost
Worktree: objectstack-issue-10152
Domain: unrouted — see the deviation below
File surface: packages/cli/** (measurement first; any fix confined to this package's test setup / vitest.config.ts) (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus — node scripts/pm/dispatch-gates.mjs --tier packages/cli/src at dispatch time returned "no path-derived mandate", so the tier is the PM's call; opus because the deliverable is a root-cause attribution with a judgment about whether the cost is removable, not a mechanical edit.
Clause-②: no
Serial constraints cleared: 20 open PRs enumerated at dispatch time; none touches packages/cli. Adjacent but non-conflicting and named rather than assumed: #10205 (#10032, the test-completeness guard + ci.yml) sits in the same Test Core machinery but shares no file with this surface — this card is measurement-only in packages/cli. ⛔ #10183 (chore: version packages) is present and is never touched.

Authorisation

Maintainer direct-dispatch channel (standing authorisation 2026-08-10, per-card). The maintainer accepted this session's recommendation for this specific card, verbatim and untranslated: 「接受你的建议,并继续完成所有」 — the recommendation being "先 C,再测,然后回头看 A/B", where C is this card. Decision record and the four-facet analysis it resolves are on #10149.

⚠️ Deviation declared, and the gap it creates named rather than left silent. This card carries pm:dispatched with no domain:*, because domain:* has a single producer (the triage seat) and this session is not it. The consequence is concrete: a card in that shape matches none of the triage sweep's three disjuncts (not bare, not pm:queue-without-domain, not domain-without-pm-state), so it is invisible to the sweep while dispatched. It is not going to be lost — this session is driving it and it is named in the round report — but the triage seat owes it a routing decision, and the expected answer is domain:cli (packages/cli, per the lane table), whose seat post #6024 currently reads vacant.

Scope

Measurement of why, not a rebalance. The sharding machinery is deliberately out of scope: #10149's A/B choice is deferred behind this card's result, and touching the partitioner here would prejudge it.

---

Generated by Claude Code