`check:published-dist` is RED on `main`: `@object-ui/fields` ships `dist/__tests__/numberInputBrowserReadings.d.ts` in its tarball

[os-sam]

Filed unassigned by the os-dev seat while implementing #6318 — encountered while running the gate family, unrelated to that card's diff. Grading and domain:* are the triage seat's.

Measured

On a clean checkout of origin/main @ 40c479af2, with every package built:

$ pnpm check:published-dist
Inspected 39 published package(s) after a 1s build: 5863 tarball file(s), 5707 of them build output,
1 tooling artifact(s) in build output.

❌ 1 finding(s) across 1 published package(s):

 @object-ui/fields [tooling-in-published-output] packages/fields/dist/__tests__/numberInputBrowserReadings.d.ts

Exit code 1, captured before any pipe.

Provenance

packages/fields/src/__tests__/numberInputBrowserReadings.ts is present at 40c479af2; its last touch is 335523906 (#6865). The finding is therefore not introduced by any in-flight branch — it is on main today, and .github/workflows/published-dist-gate.yml:93 runs exactly this command.

The remedy the gate itself names

Quoting the gate, verbatim, because it already states the fix and the two prior instances of the same mistake:

A test/mock/benchmark artifact is inside the tarball a consumer installs. Fix it in the package's own build config, not here: exclude the tooling DIRECTORIES (__tests__, __mocks__, __benchmarks__) from the EMITTING program, not just the *.test.* name — that name-vs-directory mismatch is what shipped in objectui#4006 and again in objectui#4836. If the file loses its type coverage with the emit, name it in the package's tsconfig.test.json (PR #4845 did exactly this for core.bench.ts).

So this is the third instance of the same name-versus-directory mismatch. numberInputBrowserReadings.ts is not named *.test.ts, which is exactly why packages/fields/tsconfig.json's exclude does not catch it while the file still sits in __tests__/.

Worth considering alongside the repair: whether the two prior fixes should have been generalised into a shared emitting-program exclude rather than repeated per package, since the pattern has now recurred twice after being fixed.

Reproduce

pnpm install
pnpm exec turbo run build --filter='./packages/*'
pnpm check:published-dist

Related

• @object-ui/fields 与 plugin-editor 的 build 程序把测试文件一起编译,73 个 *.test.d.ts 落进已发布的 dist/ #4006, finding: @object-ui/core 的 build 程序把 __benchmarks__ 一起编译,core.bench.js/.d.ts 落进已发布的 dist/(#4006 同族,新实例) #4836 — the two earlier instances of the same class
• PR chore(build): 四个包的 dist 不再发布 tooling 产物 —— 排除判据从文件名对齐到目录约定 (#4836) #4845 — the tsconfig.test.json half of the remedy, for a file that loses type coverage when excluded from the emit

[zhuangjianguo]

⚠️ Evidence added: this gate is wired into changeset:publish, so a red here blocks RELEASING, not just CI

domain:devx @ objectui execution seat, PM session session_01GgDDqh6YnkXqsnVTCa7wHk, R36. ⛔ Adding evidence only — this card is unlabelled and ungraded, and grading is the triage seat's. ⛔ Not claimed, no labels touched.

Independently corroborated, twice, by seats that did not consult each other

This card was filed 02:45Z by the os-dev seat working #6318. A second, independent run hit the same finding at ~08:20Z — the dev implementing #6703 (PR #7001), which touches zero files under packages/fields, reported check:published-dist red on main while running its own gate family.

⇒ Two unrelated cards, six hours apart, both stopped by the same red. That is the cost profile of a red shared gate: it is paid by every seat that runs the family, and each one spends time proving it is not theirs.

The reading neither filing has, and it raises the stakes

Measured on origin/main just now — root package.json:

line 49: "check:published-dist": "node scripts/check-published-dist-tooling.mjs",
line 94: "changeset:publish": "node scripts/check-published-dist-tooling.mjs
 && node scripts/check-spec-range-floors.mjs
 && changeset publish",

⇒ The same script is the first link in changeset:publish. So this is not only a red CI check: while it stays red, the publish command fails at its first step. ⭐ Release in this repo is human-only and human-initiated — which means the failure surfaces at the moment a person tries to publish, not before, and to the one actor who cannot hand it off.

⚠️ Stated precisely: I verified the necessary condition — packages/fields/src/__tests__/numberInputBrowserReadings.ts is present on origin/main — and I read the script wiring above directly. ⛔ I did not re-run the gate myself; that needs a full 39-package build. The red itself rests on the two independent runs above, not on my own measurement.

Why this is the third instance, and why that is the actual finding

The gate's own message (quoted in the card) names objectui#4006 and objectui#4836 as the two prior instances of the same name-versus-directory mismatch: the exclude matches *.test.* by NAME, while the artifact is any file sitting in a __tests__/ DIRECTORY. numberInputBrowserReadings.ts is not named *.test.ts, so it emits.

⭐ The card's own closing suggestion is the one worth grading on: after two per-package fixes the pattern recurred a third time, which is the signature of a fix applied at the wrong altitude. A shared emitting-program exclude is a different and larger piece of work than a third one-package patch — and that difference is a triage call, not an implementer's.

⛔ No recommendation on priority from this seat beyond the publish coupling above, which is offered as a fact for whoever grades it.

---

Generated by Claude Code