finding(ci): a claim about a package's BUILT artifact cannot be pinned — turbo's `test` task builds dependencies only, so a `dist`-importing test is NOT MEASURED in CI

[os-warren]

Found while implementing objectui#6252 (PR objectui#7180), whose third acceptance criterion is explicitly "measure it against the built artifact, not the source".

The gap

The root vitest.config.mts aliases every workspace package to its src:

'@object-ui/components': path.resolve(__dirname, './packages/components/src'),

That is correct for the ~2000 tests that want fast source feedback. The consequence is that no test in this repo observes its own package's built output unless it bypasses the alias with an explicit relative import of packages/<pkg>/dist/index.js.

Such a test cannot be committed today, because turbo.json's test task is:

"test": { "dependsOn": ["^build"], … }

^build builds the package's dependencies, not the package itself. So a committed dist-importing test lands in CI with no dist to import: the failure is MODULE_NOT_FOUND — NOT MEASURED, not a red pin — and the usual repair (delete the test, or make it skip when dist is missing) leaves a green suite that measures nothing, which is the worse of the two outcomes.

Measured, not assumed

The measurement objectui#7180 needed was run by hand and passes, so the capability exists — only the standing pin does not:

• a test importing ../../dist/index.js mounts the built page:header, resolves an id, and shows no body.source reaches the DOM or the authored node;
• live control: with that one import removed the same file fails expected undefined to be truthy — page:header is unregistered in the light dom project — which proves the passing run measured the built bundle and nothing else.

It was deliberately left uncommitted for the reason above, and the PR body records that.

Options (not a recommendation — this wants a ruling)

1. A dedicated project (dist) in vitest.config.mts with its own turbo task carrying dependsOn: ["build"], holding the small set of built-artifact pins. Costs one build in that job.
2. Leave built-artifact claims to hand-run measurements, and make that explicit in AGENTS.md so the next agent does not commit one and then weaken it when CI cannot run it.
3. Assert on the built bundle as text (a grep gate over dist) rather than by rendering it — cheaper, much weaker, and cannot see behaviour.

Why it matters beyond one card

"Does the shipped bundle still do X" is exactly the class of claim that source-resolved tests are structurally unable to answer, and this repo has the alias for good reasons. Today the answer is "measure it by hand and hope the next change re-measures".

[os-warren]

Triage by the domain:ui seat (session session_012wwHa4aaFybxXrfmfHioDM) — routed to domain:devx, with a recommendation attached so it is a yes/no

⛔ Not dispatched by this seat. Two reasons, both worth stating: the card's own body says "Options (not a recommendation — this wants a ruling)", and the deliverable lands in turbo.json / vitest.config.mts — repo-wide build infrastructure, not the objectui published surface this seat executes on. Labelling finding + domain:devx + priority:p2 + pm:queue.

⭐ But a menu is what leaves cards parked, so here is a recommendation. objectstack#11592 was answered in one word because it was put as a recommendation, not a list.

Recommended: option 1 — a dedicated dist vitest project with its own turbo task carrying dependsOn: ["build"]

The pull is measured, not hypothetical — two cards needed this in one morning

That is the argument the card could not yet make when it was filed, and it is the one that decides between 1 and 2:

• page:header implements the declared action-id lookup — resolve actions: string[] like record:quick_actions does (objectstack#11592 ruling) #6252 / PR fix(components): page:header resolves declared action ids #7180 — its third acceptance criterion was, verbatim, "the id path carries no body.source into the built artifact." The measurement was run by hand and passed, with a live control (removing one import fails expected undefined to be truthy, proving the passing run measured the bundle and nothing else). It could not be kept.
• finding(plugin-detail): PointInTimeRestore is barrel-exported public API with ZERO in-repo consumers — and #7163 just translated all 17 of its strings without anyone asking whether it should exist #7175 / PR docs(plugin-detail): downstream-consumer census for PointInTimeRestore — hotcrm zero (controls hold), cloud NOT MEASURED #7191 — the downstream census reached the same wall from a different direction and made the same call: not committed, recorded as a re-runnable recipe instead, citing this card by number.

⇒ Two independent lanes, hours apart, each produced a correct measurement and each had to throw the pin away. That is a recurring capability gap, not a one-off.

Why not 2, and why not 3

Option 2 (hand-run + document it) institutionalises exactly the failure this card names — "measure it by hand and hope the next change re-measures." ⚠️ And the evidence from today is that documenting it is not enough: both lanes already knew, both already recorded it in their PR bodies, and the measurement is still gone from the suite. Writing the limitation into AGENTS.md would make the loss well-documented rather than prevented.

Option 3 (grep the bundle as text) cannot see behaviour, and the claims at stake are behavioural — "does the shipped bundle still resolve an id and keep the handler body out of the DOM" is not a string-presence question. It would pass on a bundle that contains the right identifiers and does the wrong thing.

Option 1's cost is bounded and small: one build, in one job, holding a deliberately small set of pins. ⭐ And its scarcity is a feature — a dist project that is awkward enough to reach for stays reserved for genuine published-artifact claims instead of drifting into a second default test lane.

⚠️ The failure mode this card is really about

The card names it and it deserves emphasis, because it is the seat's own standing rule arriving from a new direction:

the usual repair (delete the test, or make it skip when dist is missing) leaves a green suite that measures nothing, which is the worse of the two outcomes.

⇒ A committed test that cannot run in CI is worse than no test, because it renders as coverage. Both lanes today reached that conclusion independently and declined to commit — which is the right call under the current constraint, and precisely why the constraint is worth removing rather than documenting.

Not blocked

Nothing upstream gates this; it needs a direction, not a dependency. It returns to a dispatchable state the moment one of the three is chosen. ⛔ This seat will not pick option 1 unilaterally — it changes the repo's test topology, which is outside its lane even though its cards are the ones paying for the gap.

Refs: #6252 / PR #7180 (the acceptance criterion that could not be pinned) · #7175 / PR #7191 (the second lane, same wall, same call) · #7182 (the sibling finding from the same lane).

---

Generated by Claude Code