finding(devx): two package `test` entries carry `--passWithNoTests` while the package HAS test files — the entry cannot notice its own collection going empty

[baozhoutao]

Filed bare by the dev seat working objectui#9106 (branch claude/issue-9106-zero-test-package-exclusion), as an adjacent member of the same class, found while deriving the package-test-script population. Not fixed there: objectui#9106's scope is the three test-less members, and this is a different adjudication about two members that do have tests. No domain:*, no priority, no type, no assignee, no pm:* — routing and grading belong to triage.

What was measured

On 1e0e46af9, walking all 46 workspace manifests under packages/*, apps/*, examples/* and counting test files per member:

member	test script	test files on disk	collected by the root config
packages/plugin-ai	vitest run --passWithNoTests --root ../.. packages/plugin-ai/	2	yes (vitest list packages/plugin-ai/ resolves, exit 0)
packages/vscode-extension	vitest run --passWithNoTests --root ../.. packages/vscode-extension/	2	yes (vitest list packages/vscode-extension/ resolves, exit 0)

Every one of the other 41 members that declares a test script spells it without the flag: vitest run --root ../.. DIR/.

Why the flag is load-bearing in the wrong direction here

The root config does not set passWithNoTests to a constant. It sets it to the negation of whether the CLI named test filters:

passWithNoTests: !cliHasTestFilters(process.argv),

A positional path filter is a test filter, so for the 41 ordinary entries the value is already false: a filter that collects nothing exits 1, loudly. That is the property objectui#3288 installed and objectui#8240 relied on.

--passWithNoTests on the command line overrides it back to true. So for these two members only:

• delete or rename their two test files, move them under a directory the root config excludes, or mis-spell the positional after a refactor, and pnpm --filter PKG test exits 0 having run nothing;
• and unlike the three test-less members recorded in objectui#9106, these two have real coverage to lose, so the silent green would be hiding something.

This is the class objectstack#13799 names — 「a battery that never ran is indistinguishable from one that passed」 — held open for two packages by a flag that today changes no observable outcome, which is exactly why nobody notices it.

What this does NOT claim

Nothing is red today and no user is affected: both entries collect their files and pass. The defect is latent. It is also possible the flag was added deliberately at a moment when one of these packages had no tests yet and was simply never removed when tests arrived — the fix would then be a two-token deletion, but that is a judgement for whoever owns the entry, not something to assume.

Adjacent, checked, and not this

• objectui#9106 (open) — the three members with no test files at all, where the question is the opposite one: whether to give them an entry. Its carrier asserts that no member has a test script and zero test files, which is a different partition from this one and stays green with these two flags in place.
• objectui#8991 (closed) — members with test files and NO test script.
• objectui#7814 (open) — appending a path to a package test script widens instead of narrowing.
• objectui#8240 / objectui#8096 (closed) — the console entry; its --no-passWithNoTests is the deliberate opposite of this, because a --project filter is not a test filter and would otherwise inherit true.

Dedup: one targeted MCP search_issues call over this vocabulary returned 10 results, with objectui#9106 itself returned as the control that the query reaches this subject. The repo-scoped REST read path works from this container but /search/issues answers 403 (the container's egress proxy binds sessions to their configured repositories), so the search went through MCP.

Generated by Claude Code, session session_01FhBNJcLRZLe8M87VcUgpKr.