fix(test): point test:integration at projects that exist, and pin the script/config agreement

[os-litant]

Fixes#7096

Measured at head 652bd11e0.

The defect, confirmed

pnpm test:integration was vitest run --project ui while no project named ui existed, so the script could not run at all. Reproduced on the base commit ad3d4029a:

$ pnpm exec vitest run --project ui
Error: No projects matched the filter "ui".
INNER_EXIT=1

Why it drifted — history, not a typo

ui was a real project once. It was declared in vitest.workspace.ts (1bdba0693, 2026-02-28) as the complement of unit: every *.test.ts / *.test.tsx under packages, apps and examples except the four pure-logic packages.

85c872487 (2026-05-24) deleted that file, because Vitest 4 removed defineWorkspace and had been silently ignoring it. That took unitandui down together. unit was later re-declared as an inline project in vitest.config.mts (e850c5695) — a commit that never touched package.json — so pnpm test:unit started resolving again by accident. Nothing ever re-declared ui.

So the script had been naming a project that stopped existing three months earlier, and no run ever reported it: a script nobody invokes is a script nobody sees fail.

The change

- "test:integration": "vitest run --project ui",+ "test:integration": "vitest run --project dom --project dom-heavy",

The stale name moves to the projects that exist; no project named ui is added to vitest.config.mts. dom + dom-heavy is what ui covered, expressed in today's split — the two DOM tiers are the complement of unit among the root-level projects, which is precisely the population ui was defined as.

One judgement call, called out for review: apps/console is its own project today (name @object-ui/console, derived by Vitest from that directory's package.json), and the 2026-02 ui glob did include apps/*/src/**. It is not included here — that project is an app's own suite with its own alias config, not the renderer integration tier, and pnpm test covers it either way. Say the word and it becomes a third --project.

The pin

scripts/__tests__/package-scripts-vitest-projects.test.ts holds the two halves to each other: every --project name a root script passes must be a project this repo declares.

The assertion is a subset check (script names ⊆ declared names), so an over-wide declared set can never fail it — which makes every leg of the derivation silently vacuous unless it carries its own control. Each one does, asserted against a name measured on this tree:

• the extractor collects every--project occurrence, not just the last. This is deliberate and is why parseVitestArgv from scripts/vitest-invocation-guard.mjs is not reused: that parser keeps flags in a plain object, so a repeated flag collapses to its last value — and --project dom --project dom-heavy is exactly that shape. Reusing it would have checked dom-heavy and quietly skipped dom. Controlled by a case asserting both names come back, plus --project=NAME and two no-match forms.
• the inline projects — unit, dom, dom-heavy, and the env-gated dist — read off the config's source text. Controlled by asserting all four are found.
• the project brought in by config path — @object-ui/console, whose name appears as no name: literal anywhere in the repo. Without this leg a root script that legitimately named it would go red. Controlled by asserting it is found; measured with pnpm exec vitest list --project @object-ui/console, which resolves.
• a negative control that the derivation does not answer yes to everything, deliberately using a nonsense name rather than ui, so the control stays a control instead of quietly becoming policy about which names are allowed.

Source text, not an import (ZONE 2 assumption 5). An import answers a different question: the dist project only materialises when OBJECTUI_DIST_PINS=1, so the imported project list depends on the environment while the declaration surface does not. Importing would also execute that file's module scope — including its --project dist argv guard, which throws — inside the test process.

Evidence

Every heavy run went through the shared verify lock (OS_VERIFY_LOCK_SLOT=dev-7096); exit codes captured after redirection, never across a pipe.

Pin red before the script change (pin written first, measured on the unmodified tree):

❯ |unit| scripts/__tests__/package-scripts-vitest-projects.test.ts (8 tests | 1 failed)
AssertionError: Root scripts filter on 1 project(s) that vitest.config.mts does not declare,
so those scripts cannot run:
pnpm test:integration → --project ui
Declared: @object-ui/console, dist, dom, dom-heavy, unit
Test Files 1 failed (1)
Tests 1 failed | 7 passed (8)
INNER_EXIT=1

The other 7 — every control — passed there, so the red is the subset check firing, not a broken derivation.

Pin green after, at head 652bd11e0:Test Files 1 passed (1) / Tests 8 passed (8), INNER_EXIT=0.

The card's acceptance — the script now starts and runs:

> object-ui-monorepo@ test:integration
> vitest run --project dom --project dom-heavy --shard=1/16
Test Files 92 passed (92)
Tests 1054 passed (1054)
INNER_EXIT=0

Declared narrowing: that is one shard of sixteen, not the whole tier. pnpm exec vitest list --filesOnly --project dom --project dom-heavy collects 1463 files (1429 dom + 34 dom-heavy) — both filters resolve, and an unsharded run of that surface does not fit this container's ~10-minute foreground cap. CI runs the same files as pnpm test --shard=n/4.

Ablation (after committing, so HEAD holds the fix). Only the script line was reverted to --project ui. The mutation was proven on disk by anchoring on both texts — injected "vitest run --project ui" present ×1, removed --project dom --project dom-heavy absent ×0 — and by blob hash bef1402ad… differing from the HEAD blob 1bb6f8fcc…; the script aborts rather than measure if either check fails. No rebuild leg applies: the pin reads both files off disk with fs.readFileSync, with no built artifact between them. Under the mutation the pin went red naming pnpm test:integration → --project ui, ABLATED_PIN_EXIT=1. Restore was git checkout HEAD -- ABSOLUTE_PATH (with an absolute-path trap … EXIT INT TERM) and is proven by state, not exit code: worktree blob 1bb6f8fccaaaed7c58a61a352e3ae2d3d803d1ae equals the HEAD blob, git diff HEAD empty, git status clean.

Other gates, all with their own verdict line:

command	verdict
pnpm exec vitest run scripts/__tests__/	Test Files 97 passed (97) / Tests 2738 passed (2738), exit 0
pnpm test:unit --shard=1/8 (unchanged)	Test Files 102 passed (102) / Tests 1546 passed (1546), exit 0
pnpm type-check:scripts	exit 0 — and tsc --listFiles confirms the new file is in the program (1 hit), so this is a measurement, not a vacuous pass
pnpm lint:root	✖ 33 problems (0 errors, 33 warnings), exit 0; the new file alone lints clean at exit 0
pnpm lint:coverage	✅ lint coverage: 46/46 packages linted, 0 with outstanding errors
pnpm type-check:coverage	✅ type-check coverage: 45/46 via type-check … / ✅ test type-check coverage: 41/41
node scripts/check-control-bytes.mjs	✅ check-control-bytes: OK (scanned 6016 tracked text file(s); skipped 85 binary)
node scripts/check-changeset-presence.mjs	✅ No source or published contract of a released package changed in this range, so no changeset is owed.
node scripts/check-changeset-no-major.mjs	✅ No changeset declares a major bump.
node scripts/check-governed-queue-guard.mjs --test …	✅ NOT GOVERNED — 2 path(s) checked against 5 governed surface(s); none matched.

No changeset — the presence gate's own verdict line above says none is owed: root package.json is not published source and the pin is a test.

Nothing else teaches this script.git grep -n "test:integration" origin/main returns exactly one hit, package.json:25. Nothing under AGENTS.md, CLAUDE.md, .claude/**, skills/**, content/docs/** or docs/** mentions it, so no governed or docs surface needed touching. For the record, skills/objectui/guides/testing.md:45 does name the project split (--project unit / dom / dom-heavy) and stays accurate after this change.

Session: https://claude.ai/code/session_01NRRumy89BYdW9ogbcdHTho

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[os-litant]

Fixes#7096

Measured at head 652bd11e0.

The defect, confirmed

pnpm test:integration was vitest run --project ui while no project named ui existed, so the script could not run at all. Reproduced on the base commit ad3d4029a:

$ pnpm exec vitest run --project ui
Error: No projects matched the filter "ui".
INNER_EXIT=1

Why it drifted — history, not a typo

ui was a real project once. It was declared in vitest.workspace.ts (1bdba0693, 2026-02-28) as the complement of unit: every *.test.ts / *.test.tsx under packages, apps and examples except the four pure-logic packages.

85c872487 (2026-05-24) deleted that file, because Vitest 4 removed defineWorkspace and had been silently ignoring it. That took unitandui down together. unit was later re-declared as an inline project in vitest.config.mts (e850c5695) — a commit that never touched package.json — so pnpm test:unit started resolving again by accident. Nothing ever re-declared ui.

So the script had been naming a project that stopped existing three months earlier, and no run ever reported it: a script nobody invokes is a script nobody sees fail.

The change

- "test:integration": "vitest run --project ui",+ "test:integration": "vitest run --project dom --project dom-heavy",

The stale name moves to the projects that exist; no project named ui is added to vitest.config.mts. dom + dom-heavy is what ui covered, expressed in today's split — the two DOM tiers are the complement of unit among the root-level projects, which is precisely the population ui was defined as.

One judgement call, called out for review: apps/console is its own project today (name @object-ui/console, derived by Vitest from that directory's package.json), and the 2026-02 ui glob did include apps/*/src/**. It is not included here — that project is an app's own suite with its own alias config, not the renderer integration tier, and pnpm test covers it either way. Say the word and it becomes a third --project.

The pin

scripts/__tests__/package-scripts-vitest-projects.test.ts holds the two halves to each other: every --project name a root script passes must be a project this repo declares.

The assertion is a subset check (script names ⊆ declared names), so an over-wide declared set can never fail it — which makes every leg of the derivation silently vacuous unless it carries its own control. Each one does, asserted against a name measured on this tree:

• the extractor collects every--project occurrence, not just the last. This is deliberate and is why parseVitestArgv from scripts/vitest-invocation-guard.mjs is not reused: that parser keeps flags in a plain object, so a repeated flag collapses to its last value — and --project dom --project dom-heavy is exactly that shape. Reusing it would have checked dom-heavy and quietly skipped dom. Controlled by a case asserting both names come back, plus --project=NAME and two no-match forms.
• the inline projects — unit, dom, dom-heavy, and the env-gated dist — read off the config's source text. Controlled by asserting all four are found.
• the project brought in by config path — @object-ui/console, whose name appears as no name: literal anywhere in the repo. Without this leg a root script that legitimately named it would go red. Controlled by asserting it is found; measured with pnpm exec vitest list --project @object-ui/console, which resolves.
• a negative control that the derivation does not answer yes to everything, deliberately using a nonsense name rather than ui, so the control stays a control instead of quietly becoming policy about which names are allowed.

Source text, not an import (ZONE 2 assumption 5). An import answers a different question: the dist project only materialises when OBJECTUI_DIST_PINS=1, so the imported project list depends on the environment while the declaration surface does not. Importing would also execute that file's module scope — including its --project dist argv guard, which throws — inside the test process.

Evidence

Every heavy run went through the shared verify lock (OS_VERIFY_LOCK_SLOT=dev-7096); exit codes captured after redirection, never across a pipe.

Pin red before the script change (pin written first, measured on the unmodified tree):

❯ |unit| scripts/__tests__/package-scripts-vitest-projects.test.ts (8 tests | 1 failed)
AssertionError: Root scripts filter on 1 project(s) that vitest.config.mts does not declare,
so those scripts cannot run:
pnpm test:integration → --project ui
Declared: @object-ui/console, dist, dom, dom-heavy, unit
Test Files 1 failed (1)
Tests 1 failed | 7 passed (8)
INNER_EXIT=1

The other 7 — every control — passed there, so the red is the subset check firing, not a broken derivation.

Pin green after, at head 652bd11e0:Test Files 1 passed (1) / Tests 8 passed (8), INNER_EXIT=0.

The card's acceptance — the script now starts and runs:

> object-ui-monorepo@ test:integration
> vitest run --project dom --project dom-heavy --shard=1/16
Test Files 92 passed (92)
Tests 1054 passed (1054)
INNER_EXIT=0

Declared narrowing: that is one shard of sixteen, not the whole tier. pnpm exec vitest list --filesOnly --project dom --project dom-heavy collects 1463 files (1429 dom + 34 dom-heavy) — both filters resolve, and an unsharded run of that surface does not fit this container's ~10-minute foreground cap. CI runs the same files as pnpm test --shard=n/4.

Ablation (after committing, so HEAD holds the fix). Only the script line was reverted to --project ui. The mutation was proven on disk by anchoring on both texts — injected "vitest run --project ui" present ×1, removed --project dom --project dom-heavy absent ×0 — and by blob hash bef1402ad… differing from the HEAD blob 1bb6f8fcc…; the script aborts rather than measure if either check fails. No rebuild leg applies: the pin reads both files off disk with fs.readFileSync, with no built artifact between them. Under the mutation the pin went red naming pnpm test:integration → --project ui, ABLATED_PIN_EXIT=1. Restore was git checkout HEAD -- ABSOLUTE_PATH (with an absolute-path trap … EXIT INT TERM) and is proven by state, not exit code: worktree blob 1bb6f8fccaaaed7c58a61a352e3ae2d3d803d1ae equals the HEAD blob, git diff HEAD empty, git status clean.

Other gates, all with their own verdict line:

command	verdict
pnpm exec vitest run scripts/__tests__/	Test Files 97 passed (97) / Tests 2738 passed (2738), exit 0
pnpm test:unit --shard=1/8 (unchanged)	Test Files 102 passed (102) / Tests 1546 passed (1546), exit 0
pnpm type-check:scripts	exit 0 — and tsc --listFiles confirms the new file is in the program (1 hit), so this is a measurement, not a vacuous pass
pnpm lint:root	✖ 33 problems (0 errors, 33 warnings), exit 0; the new file alone lints clean at exit 0
pnpm lint:coverage	✅ lint coverage: 46/46 packages linted, 0 with outstanding errors
pnpm type-check:coverage	✅ type-check coverage: 45/46 via type-check … / ✅ test type-check coverage: 41/41
node scripts/check-control-bytes.mjs	✅ check-control-bytes: OK (scanned 6016 tracked text file(s); skipped 85 binary)
node scripts/check-changeset-presence.mjs	✅ No source or published contract of a released package changed in this range, so no changeset is owed.
node scripts/check-changeset-no-major.mjs	✅ No changeset declares a major bump.
node scripts/check-governed-queue-guard.mjs --test …	✅ NOT GOVERNED — 2 path(s) checked against 5 governed surface(s); none matched.

No changeset — the presence gate's own verdict line above says none is owed: root package.json is not published source and the pin is a test.

Nothing else teaches this script.git grep -n "test:integration" origin/main returns exactly one hit, package.json:25. Nothing under AGENTS.md, CLAUDE.md, .claude/**, skills/**, content/docs/** or docs/** mentions it, so no governed or docs surface needed touching. For the record, skills/objectui/guides/testing.md:45 does name the project split (--project unit / dom / dom-heavy) and stays accurate after this change.

Session: https://claude.ai/code/session_01NRRumy89BYdW9ogbcdHTho

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[os-litant]

Fixes#7096

Measured at head 652bd11e0.

The defect, confirmed

pnpm test:integration was vitest run --project ui while no project named ui existed, so the script could not run at all. Reproduced on the base commit ad3d4029a:

$ pnpm exec vitest run --project ui
Error: No projects matched the filter "ui".
INNER_EXIT=1

Why it drifted — history, not a typo

ui was a real project once. It was declared in vitest.workspace.ts (1bdba0693, 2026-02-28) as the complement of unit: every *.test.ts / *.test.tsx under packages, apps and examples except the four pure-logic packages.

85c872487 (2026-05-24) deleted that file, because Vitest 4 removed defineWorkspace and had been silently ignoring it. That took unitandui down together. unit was later re-declared as an inline project in vitest.config.mts (e850c5695) — a commit that never touched package.json — so pnpm test:unit started resolving again by accident. Nothing ever re-declared ui.

So the script had been naming a project that stopped existing three months earlier, and no run ever reported it: a script nobody invokes is a script nobody sees fail.

The change

- "test:integration": "vitest run --project ui",+ "test:integration": "vitest run --project dom --project dom-heavy",

The stale name moves to the projects that exist; no project named ui is added to vitest.config.mts. dom + dom-heavy is what ui covered, expressed in today's split — the two DOM tiers are the complement of unit among the root-level projects, which is precisely the population ui was defined as.

One judgement call, called out for review: apps/console is its own project today (name @object-ui/console, derived by Vitest from that directory's package.json), and the 2026-02 ui glob did include apps/*/src/**. It is not included here — that project is an app's own suite with its own alias config, not the renderer integration tier, and pnpm test covers it either way. Say the word and it becomes a third --project.

The pin

scripts/__tests__/package-scripts-vitest-projects.test.ts holds the two halves to each other: every --project name a root script passes must be a project this repo declares.

The assertion is a subset check (script names ⊆ declared names), so an over-wide declared set can never fail it — which makes every leg of the derivation silently vacuous unless it carries its own control. Each one does, asserted against a name measured on this tree:

• the extractor collects every--project occurrence, not just the last. This is deliberate and is why parseVitestArgv from scripts/vitest-invocation-guard.mjs is not reused: that parser keeps flags in a plain object, so a repeated flag collapses to its last value — and --project dom --project dom-heavy is exactly that shape. Reusing it would have checked dom-heavy and quietly skipped dom. Controlled by a case asserting both names come back, plus --project=NAME and two no-match forms.
• the inline projects — unit, dom, dom-heavy, and the env-gated dist — read off the config's source text. Controlled by asserting all four are found.
• the project brought in by config path — @object-ui/console, whose name appears as no name: literal anywhere in the repo. Without this leg a root script that legitimately named it would go red. Controlled by asserting it is found; measured with pnpm exec vitest list --project @object-ui/console, which resolves.
• a negative control that the derivation does not answer yes to everything, deliberately using a nonsense name rather than ui, so the control stays a control instead of quietly becoming policy about which names are allowed.

Source text, not an import (ZONE 2 assumption 5). An import answers a different question: the dist project only materialises when OBJECTUI_DIST_PINS=1, so the imported project list depends on the environment while the declaration surface does not. Importing would also execute that file's module scope — including its --project dist argv guard, which throws — inside the test process.

Evidence

Every heavy run went through the shared verify lock (OS_VERIFY_LOCK_SLOT=dev-7096); exit codes captured after redirection, never across a pipe.

Pin red before the script change (pin written first, measured on the unmodified tree):

❯ |unit| scripts/__tests__/package-scripts-vitest-projects.test.ts (8 tests | 1 failed)
AssertionError: Root scripts filter on 1 project(s) that vitest.config.mts does not declare,
so those scripts cannot run:
pnpm test:integration → --project ui
Declared: @object-ui/console, dist, dom, dom-heavy, unit
Test Files 1 failed (1)
Tests 1 failed | 7 passed (8)
INNER_EXIT=1

The other 7 — every control — passed there, so the red is the subset check firing, not a broken derivation.

Pin green after, at head 652bd11e0:Test Files 1 passed (1) / Tests 8 passed (8), INNER_EXIT=0.

The card's acceptance — the script now starts and runs:

> object-ui-monorepo@ test:integration
> vitest run --project dom --project dom-heavy --shard=1/16
Test Files 92 passed (92)
Tests 1054 passed (1054)
INNER_EXIT=0

Declared narrowing: that is one shard of sixteen, not the whole tier. pnpm exec vitest list --filesOnly --project dom --project dom-heavy collects 1463 files (1429 dom + 34 dom-heavy) — both filters resolve, and an unsharded run of that surface does not fit this container's ~10-minute foreground cap. CI runs the same files as pnpm test --shard=n/4.

Ablation (after committing, so HEAD holds the fix). Only the script line was reverted to --project ui. The mutation was proven on disk by anchoring on both texts — injected "vitest run --project ui" present ×1, removed --project dom --project dom-heavy absent ×0 — and by blob hash bef1402ad… differing from the HEAD blob 1bb6f8fcc…; the script aborts rather than measure if either check fails. No rebuild leg applies: the pin reads both files off disk with fs.readFileSync, with no built artifact between them. Under the mutation the pin went red naming pnpm test:integration → --project ui, ABLATED_PIN_EXIT=1. Restore was git checkout HEAD -- ABSOLUTE_PATH (with an absolute-path trap … EXIT INT TERM) and is proven by state, not exit code: worktree blob 1bb6f8fccaaaed7c58a61a352e3ae2d3d803d1ae equals the HEAD blob, git diff HEAD empty, git status clean.

Other gates, all with their own verdict line:

command	verdict
pnpm exec vitest run scripts/__tests__/	Test Files 97 passed (97) / Tests 2738 passed (2738), exit 0
pnpm test:unit --shard=1/8 (unchanged)	Test Files 102 passed (102) / Tests 1546 passed (1546), exit 0
pnpm type-check:scripts	exit 0 — and tsc --listFiles confirms the new file is in the program (1 hit), so this is a measurement, not a vacuous pass
pnpm lint:root	✖ 33 problems (0 errors, 33 warnings), exit 0; the new file alone lints clean at exit 0
pnpm lint:coverage	✅ lint coverage: 46/46 packages linted, 0 with outstanding errors
pnpm type-check:coverage	✅ type-check coverage: 45/46 via type-check … / ✅ test type-check coverage: 41/41
node scripts/check-control-bytes.mjs	✅ check-control-bytes: OK (scanned 6016 tracked text file(s); skipped 85 binary)
node scripts/check-changeset-presence.mjs	✅ No source or published contract of a released package changed in this range, so no changeset is owed.
node scripts/check-changeset-no-major.mjs	✅ No changeset declares a major bump.
node scripts/check-governed-queue-guard.mjs --test …	✅ NOT GOVERNED — 2 path(s) checked against 5 governed surface(s); none matched.

No changeset — the presence gate's own verdict line above says none is owed: root package.json is not published source and the pin is a test.

Nothing else teaches this script.git grep -n "test:integration" origin/main returns exactly one hit, package.json:25. Nothing under AGENTS.md, CLAUDE.md, .claude/**, skills/**, content/docs/** or docs/** mentions it, so no governed or docs surface needed touching. For the record, skills/objectui/guides/testing.md:45 does name the project split (--project unit / dom / dom-heavy) and stays accurate after this change.

Session: https://claude.ai/code/session_01NRRumy89BYdW9ogbcdHTho

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[os-litant]

Fixes#7096

Measured at head 652bd11e0.

The defect, confirmed

pnpm test:integration was vitest run --project ui while no project named ui existed, so the script could not run at all. Reproduced on the base commit ad3d4029a:

$ pnpm exec vitest run --project ui
Error: No projects matched the filter "ui".
INNER_EXIT=1

Why it drifted — history, not a typo

ui was a real project once. It was declared in vitest.workspace.ts (1bdba0693, 2026-02-28) as the complement of unit: every *.test.ts / *.test.tsx under packages, apps and examples except the four pure-logic packages.

85c872487 (2026-05-24) deleted that file, because Vitest 4 removed defineWorkspace and had been silently ignoring it. That took unitandui down together. unit was later re-declared as an inline project in vitest.config.mts (e850c5695) — a commit that never touched package.json — so pnpm test:unit started resolving again by accident. Nothing ever re-declared ui.

So the script had been naming a project that stopped existing three months earlier, and no run ever reported it: a script nobody invokes is a script nobody sees fail.

The change

- "test:integration": "vitest run --project ui",+ "test:integration": "vitest run --project dom --project dom-heavy",

The stale name moves to the projects that exist; no project named ui is added to vitest.config.mts. dom + dom-heavy is what ui covered, expressed in today's split — the two DOM tiers are the complement of unit among the root-level projects, which is precisely the population ui was defined as.

One judgement call, called out for review: apps/console is its own project today (name @object-ui/console, derived by Vitest from that directory's package.json), and the 2026-02 ui glob did include apps/*/src/**. It is not included here — that project is an app's own suite with its own alias config, not the renderer integration tier, and pnpm test covers it either way. Say the word and it becomes a third --project.

The pin

scripts/__tests__/package-scripts-vitest-projects.test.ts holds the two halves to each other: every --project name a root script passes must be a project this repo declares.

The assertion is a subset check (script names ⊆ declared names), so an over-wide declared set can never fail it — which makes every leg of the derivation silently vacuous unless it carries its own control. Each one does, asserted against a name measured on this tree:

• the extractor collects every--project occurrence, not just the last. This is deliberate and is why parseVitestArgv from scripts/vitest-invocation-guard.mjs is not reused: that parser keeps flags in a plain object, so a repeated flag collapses to its last value — and --project dom --project dom-heavy is exactly that shape. Reusing it would have checked dom-heavy and quietly skipped dom. Controlled by a case asserting both names come back, plus --project=NAME and two no-match forms.
• the inline projects — unit, dom, dom-heavy, and the env-gated dist — read off the config's source text. Controlled by asserting all four are found.
• the project brought in by config path — @object-ui/console, whose name appears as no name: literal anywhere in the repo. Without this leg a root script that legitimately named it would go red. Controlled by asserting it is found; measured with pnpm exec vitest list --project @object-ui/console, which resolves.
• a negative control that the derivation does not answer yes to everything, deliberately using a nonsense name rather than ui, so the control stays a control instead of quietly becoming policy about which names are allowed.

Source text, not an import (ZONE 2 assumption 5). An import answers a different question: the dist project only materialises when OBJECTUI_DIST_PINS=1, so the imported project list depends on the environment while the declaration surface does not. Importing would also execute that file's module scope — including its --project dist argv guard, which throws — inside the test process.

Evidence

Every heavy run went through the shared verify lock (OS_VERIFY_LOCK_SLOT=dev-7096); exit codes captured after redirection, never across a pipe.

Pin red before the script change (pin written first, measured on the unmodified tree):

❯ |unit| scripts/__tests__/package-scripts-vitest-projects.test.ts (8 tests | 1 failed)
AssertionError: Root scripts filter on 1 project(s) that vitest.config.mts does not declare,
so those scripts cannot run:
pnpm test:integration → --project ui
Declared: @object-ui/console, dist, dom, dom-heavy, unit
Test Files 1 failed (1)
Tests 1 failed | 7 passed (8)
INNER_EXIT=1

The other 7 — every control — passed there, so the red is the subset check firing, not a broken derivation.

Pin green after, at head 652bd11e0:Test Files 1 passed (1) / Tests 8 passed (8), INNER_EXIT=0.

The card's acceptance — the script now starts and runs:

> object-ui-monorepo@ test:integration
> vitest run --project dom --project dom-heavy --shard=1/16
Test Files 92 passed (92)
Tests 1054 passed (1054)
INNER_EXIT=0

Declared narrowing: that is one shard of sixteen, not the whole tier. pnpm exec vitest list --filesOnly --project dom --project dom-heavy collects 1463 files (1429 dom + 34 dom-heavy) — both filters resolve, and an unsharded run of that surface does not fit this container's ~10-minute foreground cap. CI runs the same files as pnpm test --shard=n/4.

Ablation (after committing, so HEAD holds the fix). Only the script line was reverted to --project ui. The mutation was proven on disk by anchoring on both texts — injected "vitest run --project ui" present ×1, removed --project dom --project dom-heavy absent ×0 — and by blob hash bef1402ad… differing from the HEAD blob 1bb6f8fcc…; the script aborts rather than measure if either check fails. No rebuild leg applies: the pin reads both files off disk with fs.readFileSync, with no built artifact between them. Under the mutation the pin went red naming pnpm test:integration → --project ui, ABLATED_PIN_EXIT=1. Restore was git checkout HEAD -- ABSOLUTE_PATH (with an absolute-path trap … EXIT INT TERM) and is proven by state, not exit code: worktree blob 1bb6f8fccaaaed7c58a61a352e3ae2d3d803d1ae equals the HEAD blob, git diff HEAD empty, git status clean.

Other gates, all with their own verdict line:

command	verdict
pnpm exec vitest run scripts/__tests__/	Test Files 97 passed (97) / Tests 2738 passed (2738), exit 0
pnpm test:unit --shard=1/8 (unchanged)	Test Files 102 passed (102) / Tests 1546 passed (1546), exit 0
pnpm type-check:scripts	exit 0 — and tsc --listFiles confirms the new file is in the program (1 hit), so this is a measurement, not a vacuous pass
pnpm lint:root	✖ 33 problems (0 errors, 33 warnings), exit 0; the new file alone lints clean at exit 0
pnpm lint:coverage	✅ lint coverage: 46/46 packages linted, 0 with outstanding errors
pnpm type-check:coverage	✅ type-check coverage: 45/46 via type-check … / ✅ test type-check coverage: 41/41
node scripts/check-control-bytes.mjs	✅ check-control-bytes: OK (scanned 6016 tracked text file(s); skipped 85 binary)
node scripts/check-changeset-presence.mjs	✅ No source or published contract of a released package changed in this range, so no changeset is owed.
node scripts/check-changeset-no-major.mjs	✅ No changeset declares a major bump.
node scripts/check-governed-queue-guard.mjs --test …	✅ NOT GOVERNED — 2 path(s) checked against 5 governed surface(s); none matched.

No changeset — the presence gate's own verdict line above says none is owed: root package.json is not published source and the pin is a test.

Nothing else teaches this script.git grep -n "test:integration" origin/main returns exactly one hit, package.json:25. Nothing under AGENTS.md, CLAUDE.md, .claude/**, skills/**, content/docs/** or docs/** mentions it, so no governed or docs surface needed touching. For the record, skills/objectui/guides/testing.md:45 does name the project split (--project unit / dom / dom-heavy) and stays accurate after this change.

Session: https://claude.ai/code/session_01NRRumy89BYdW9ogbcdHTho

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[os-litant]

Fixes#7096

Measured at head 652bd11e0.

The defect, confirmed

pnpm test:integration was vitest run --project ui while no project named ui existed, so the script could not run at all. Reproduced on the base commit ad3d4029a:

$ pnpm exec vitest run --project ui
Error: No projects matched the filter "ui".
INNER_EXIT=1

Why it drifted — history, not a typo

ui was a real project once. It was declared in vitest.workspace.ts (1bdba0693, 2026-02-28) as the complement of unit: every *.test.ts / *.test.tsx under packages, apps and examples except the four pure-logic packages.

85c872487 (2026-05-24) deleted that file, because Vitest 4 removed defineWorkspace and had been silently ignoring it. That took unitandui down together. unit was later re-declared as an inline project in vitest.config.mts (e850c5695) — a commit that never touched package.json — so pnpm test:unit started resolving again by accident. Nothing ever re-declared ui.

So the script had been naming a project that stopped existing three months earlier, and no run ever reported it: a script nobody invokes is a script nobody sees fail.

The change

- "test:integration": "vitest run --project ui",+ "test:integration": "vitest run --project dom --project dom-heavy",

The stale name moves to the projects that exist; no project named ui is added to vitest.config.mts. dom + dom-heavy is what ui covered, expressed in today's split — the two DOM tiers are the complement of unit among the root-level projects, which is precisely the population ui was defined as.

One judgement call, called out for review: apps/console is its own project today (name @object-ui/console, derived by Vitest from that directory's package.json), and the 2026-02 ui glob did include apps/*/src/**. It is not included here — that project is an app's own suite with its own alias config, not the renderer integration tier, and pnpm test covers it either way. Say the word and it becomes a third --project.

The pin

scripts/__tests__/package-scripts-vitest-projects.test.ts holds the two halves to each other: every --project name a root script passes must be a project this repo declares.

The assertion is a subset check (script names ⊆ declared names), so an over-wide declared set can never fail it — which makes every leg of the derivation silently vacuous unless it carries its own control. Each one does, asserted against a name measured on this tree:

• the extractor collects every--project occurrence, not just the last. This is deliberate and is why parseVitestArgv from scripts/vitest-invocation-guard.mjs is not reused: that parser keeps flags in a plain object, so a repeated flag collapses to its last value — and --project dom --project dom-heavy is exactly that shape. Reusing it would have checked dom-heavy and quietly skipped dom. Controlled by a case asserting both names come back, plus --project=NAME and two no-match forms.
• the inline projects — unit, dom, dom-heavy, and the env-gated dist — read off the config's source text. Controlled by asserting all four are found.
• the project brought in by config path — @object-ui/console, whose name appears as no name: literal anywhere in the repo. Without this leg a root script that legitimately named it would go red. Controlled by asserting it is found; measured with pnpm exec vitest list --project @object-ui/console, which resolves.
• a negative control that the derivation does not answer yes to everything, deliberately using a nonsense name rather than ui, so the control stays a control instead of quietly becoming policy about which names are allowed.

Source text, not an import (ZONE 2 assumption 5). An import answers a different question: the dist project only materialises when OBJECTUI_DIST_PINS=1, so the imported project list depends on the environment while the declaration surface does not. Importing would also execute that file's module scope — including its --project dist argv guard, which throws — inside the test process.

Evidence

Every heavy run went through the shared verify lock (OS_VERIFY_LOCK_SLOT=dev-7096); exit codes captured after redirection, never across a pipe.

Pin red before the script change (pin written first, measured on the unmodified tree):

❯ |unit| scripts/__tests__/package-scripts-vitest-projects.test.ts (8 tests | 1 failed)
AssertionError: Root scripts filter on 1 project(s) that vitest.config.mts does not declare,
so those scripts cannot run:
pnpm test:integration → --project ui
Declared: @object-ui/console, dist, dom, dom-heavy, unit
Test Files 1 failed (1)
Tests 1 failed | 7 passed (8)
INNER_EXIT=1

The other 7 — every control — passed there, so the red is the subset check firing, not a broken derivation.

Pin green after, at head 652bd11e0:Test Files 1 passed (1) / Tests 8 passed (8), INNER_EXIT=0.

The card's acceptance — the script now starts and runs:

> object-ui-monorepo@ test:integration
> vitest run --project dom --project dom-heavy --shard=1/16
Test Files 92 passed (92)
Tests 1054 passed (1054)
INNER_EXIT=0

Declared narrowing: that is one shard of sixteen, not the whole tier. pnpm exec vitest list --filesOnly --project dom --project dom-heavy collects 1463 files (1429 dom + 34 dom-heavy) — both filters resolve, and an unsharded run of that surface does not fit this container's ~10-minute foreground cap. CI runs the same files as pnpm test --shard=n/4.

Ablation (after committing, so HEAD holds the fix). Only the script line was reverted to --project ui. The mutation was proven on disk by anchoring on both texts — injected "vitest run --project ui" present ×1, removed --project dom --project dom-heavy absent ×0 — and by blob hash bef1402ad… differing from the HEAD blob 1bb6f8fcc…; the script aborts rather than measure if either check fails. No rebuild leg applies: the pin reads both files off disk with fs.readFileSync, with no built artifact between them. Under the mutation the pin went red naming pnpm test:integration → --project ui, ABLATED_PIN_EXIT=1. Restore was git checkout HEAD -- ABSOLUTE_PATH (with an absolute-path trap … EXIT INT TERM) and is proven by state, not exit code: worktree blob 1bb6f8fccaaaed7c58a61a352e3ae2d3d803d1ae equals the HEAD blob, git diff HEAD empty, git status clean.

Other gates, all with their own verdict line:

command	verdict
pnpm exec vitest run scripts/__tests__/	Test Files 97 passed (97) / Tests 2738 passed (2738), exit 0
pnpm test:unit --shard=1/8 (unchanged)	Test Files 102 passed (102) / Tests 1546 passed (1546), exit 0
pnpm type-check:scripts	exit 0 — and tsc --listFiles confirms the new file is in the program (1 hit), so this is a measurement, not a vacuous pass
pnpm lint:root	✖ 33 problems (0 errors, 33 warnings), exit 0; the new file alone lints clean at exit 0
pnpm lint:coverage	✅ lint coverage: 46/46 packages linted, 0 with outstanding errors
pnpm type-check:coverage	✅ type-check coverage: 45/46 via type-check … / ✅ test type-check coverage: 41/41
node scripts/check-control-bytes.mjs	✅ check-control-bytes: OK (scanned 6016 tracked text file(s); skipped 85 binary)
node scripts/check-changeset-presence.mjs	✅ No source or published contract of a released package changed in this range, so no changeset is owed.
node scripts/check-changeset-no-major.mjs	✅ No changeset declares a major bump.
node scripts/check-governed-queue-guard.mjs --test …	✅ NOT GOVERNED — 2 path(s) checked against 5 governed surface(s); none matched.

No changeset — the presence gate's own verdict line above says none is owed: root package.json is not published source and the pin is a test.

Nothing else teaches this script.git grep -n "test:integration" origin/main returns exactly one hit, package.json:25. Nothing under AGENTS.md, CLAUDE.md, .claude/**, skills/**, content/docs/** or docs/** mentions it, so no governed or docs surface needed touching. For the record, skills/objectui/guides/testing.md:45 does name the project split (--project unit / dom / dom-heavy) and stays accurate after this change.

Session: https://claude.ai/code/session_01NRRumy89BYdW9ogbcdHTho

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[os-litant]

Fixes#7096

Measured at head 652bd11e0.

The defect, confirmed

pnpm test:integration was vitest run --project ui while no project named ui existed, so the script could not run at all. Reproduced on the base commit ad3d4029a:

$ pnpm exec vitest run --project ui
Error: No projects matched the filter "ui".
INNER_EXIT=1

Why it drifted — history, not a typo

ui was a real project once. It was declared in vitest.workspace.ts (1bdba0693, 2026-02-28) as the complement of unit: every *.test.ts / *.test.tsx under packages, apps and examples except the four pure-logic packages.

85c872487 (2026-05-24) deleted that file, because Vitest 4 removed defineWorkspace and had been silently ignoring it. That took unitandui down together. unit was later re-declared as an inline project in vitest.config.mts (e850c5695) — a commit that never touched package.json — so pnpm test:unit started resolving again by accident. Nothing ever re-declared ui.

So the script had been naming a project that stopped existing three months earlier, and no run ever reported it: a script nobody invokes is a script nobody sees fail.

The change

- "test:integration": "vitest run --project ui",+ "test:integration": "vitest run --project dom --project dom-heavy",

The stale name moves to the projects that exist; no project named ui is added to vitest.config.mts. dom + dom-heavy is what ui covered, expressed in today's split — the two DOM tiers are the complement of unit among the root-level projects, which is precisely the population ui was defined as.

One judgement call, called out for review: apps/console is its own project today (name @object-ui/console, derived by Vitest from that directory's package.json), and the 2026-02 ui glob did include apps/*/src/**. It is not included here — that project is an app's own suite with its own alias config, not the renderer integration tier, and pnpm test covers it either way. Say the word and it becomes a third --project.

The pin

scripts/__tests__/package-scripts-vitest-projects.test.ts holds the two halves to each other: every --project name a root script passes must be a project this repo declares.

The assertion is a subset check (script names ⊆ declared names), so an over-wide declared set can never fail it — which makes every leg of the derivation silently vacuous unless it carries its own control. Each one does, asserted against a name measured on this tree:

• the extractor collects every--project occurrence, not just the last. This is deliberate and is why parseVitestArgv from scripts/vitest-invocation-guard.mjs is not reused: that parser keeps flags in a plain object, so a repeated flag collapses to its last value — and --project dom --project dom-heavy is exactly that shape. Reusing it would have checked dom-heavy and quietly skipped dom. Controlled by a case asserting both names come back, plus --project=NAME and two no-match forms.
• the inline projects — unit, dom, dom-heavy, and the env-gated dist — read off the config's source text. Controlled by asserting all four are found.
• the project brought in by config path — @object-ui/console, whose name appears as no name: literal anywhere in the repo. Without this leg a root script that legitimately named it would go red. Controlled by asserting it is found; measured with pnpm exec vitest list --project @object-ui/console, which resolves.
• a negative control that the derivation does not answer yes to everything, deliberately using a nonsense name rather than ui, so the control stays a control instead of quietly becoming policy about which names are allowed.

Source text, not an import (ZONE 2 assumption 5). An import answers a different question: the dist project only materialises when OBJECTUI_DIST_PINS=1, so the imported project list depends on the environment while the declaration surface does not. Importing would also execute that file's module scope — including its --project dist argv guard, which throws — inside the test process.

Evidence

Every heavy run went through the shared verify lock (OS_VERIFY_LOCK_SLOT=dev-7096); exit codes captured after redirection, never across a pipe.

Pin red before the script change (pin written first, measured on the unmodified tree):

❯ |unit| scripts/__tests__/package-scripts-vitest-projects.test.ts (8 tests | 1 failed)
AssertionError: Root scripts filter on 1 project(s) that vitest.config.mts does not declare,
so those scripts cannot run:
pnpm test:integration → --project ui
Declared: @object-ui/console, dist, dom, dom-heavy, unit
Test Files 1 failed (1)
Tests 1 failed | 7 passed (8)
INNER_EXIT=1

The other 7 — every control — passed there, so the red is the subset check firing, not a broken derivation.

Pin green after, at head 652bd11e0:Test Files 1 passed (1) / Tests 8 passed (8), INNER_EXIT=0.

The card's acceptance — the script now starts and runs:

> object-ui-monorepo@ test:integration
> vitest run --project dom --project dom-heavy --shard=1/16
Test Files 92 passed (92)
Tests 1054 passed (1054)
INNER_EXIT=0

Declared narrowing: that is one shard of sixteen, not the whole tier. pnpm exec vitest list --filesOnly --project dom --project dom-heavy collects 1463 files (1429 dom + 34 dom-heavy) — both filters resolve, and an unsharded run of that surface does not fit this container's ~10-minute foreground cap. CI runs the same files as pnpm test --shard=n/4.

Ablation (after committing, so HEAD holds the fix). Only the script line was reverted to --project ui. The mutation was proven on disk by anchoring on both texts — injected "vitest run --project ui" present ×1, removed --project dom --project dom-heavy absent ×0 — and by blob hash bef1402ad… differing from the HEAD blob 1bb6f8fcc…; the script aborts rather than measure if either check fails. No rebuild leg applies: the pin reads both files off disk with fs.readFileSync, with no built artifact between them. Under the mutation the pin went red naming pnpm test:integration → --project ui, ABLATED_PIN_EXIT=1. Restore was git checkout HEAD -- ABSOLUTE_PATH (with an absolute-path trap … EXIT INT TERM) and is proven by state, not exit code: worktree blob 1bb6f8fccaaaed7c58a61a352e3ae2d3d803d1ae equals the HEAD blob, git diff HEAD empty, git status clean.

Other gates, all with their own verdict line:

command	verdict
pnpm exec vitest run scripts/__tests__/	Test Files 97 passed (97) / Tests 2738 passed (2738), exit 0
pnpm test:unit --shard=1/8 (unchanged)	Test Files 102 passed (102) / Tests 1546 passed (1546), exit 0
pnpm type-check:scripts	exit 0 — and tsc --listFiles confirms the new file is in the program (1 hit), so this is a measurement, not a vacuous pass
pnpm lint:root	✖ 33 problems (0 errors, 33 warnings), exit 0; the new file alone lints clean at exit 0
pnpm lint:coverage	✅ lint coverage: 46/46 packages linted, 0 with outstanding errors
pnpm type-check:coverage	✅ type-check coverage: 45/46 via type-check … / ✅ test type-check coverage: 41/41
node scripts/check-control-bytes.mjs	✅ check-control-bytes: OK (scanned 6016 tracked text file(s); skipped 85 binary)
node scripts/check-changeset-presence.mjs	✅ No source or published contract of a released package changed in this range, so no changeset is owed.
node scripts/check-changeset-no-major.mjs	✅ No changeset declares a major bump.
node scripts/check-governed-queue-guard.mjs --test …	✅ NOT GOVERNED — 2 path(s) checked against 5 governed surface(s); none matched.

No changeset — the presence gate's own verdict line above says none is owed: root package.json is not published source and the pin is a test.

Nothing else teaches this script.git grep -n "test:integration" origin/main returns exactly one hit, package.json:25. Nothing under AGENTS.md, CLAUDE.md, .claude/**, skills/**, content/docs/** or docs/** mentions it, so no governed or docs surface needed touching. For the record, skills/objectui/guides/testing.md:45 does name the project split (--project unit / dom / dom-heavy) and stays accurate after this change.

Session: https://claude.ai/code/session_01NRRumy89BYdW9ogbcdHTho

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[os-litant]

Fixes#7096

Measured at head 652bd11e0.

The defect, confirmed

pnpm test:integration was vitest run --project ui while no project named ui existed, so the script could not run at all. Reproduced on the base commit ad3d4029a:

$ pnpm exec vitest run --project ui
Error: No projects matched the filter "ui".
INNER_EXIT=1

Why it drifted — history, not a typo

ui was a real project once. It was declared in vitest.workspace.ts (1bdba0693, 2026-02-28) as the complement of unit: every *.test.ts / *.test.tsx under packages, apps and examples except the four pure-logic packages.

85c872487 (2026-05-24) deleted that file, because Vitest 4 removed defineWorkspace and had been silently ignoring it. That took unitandui down together. unit was later re-declared as an inline project in vitest.config.mts (e850c5695) — a commit that never touched package.json — so pnpm test:unit started resolving again by accident. Nothing ever re-declared ui.

So the script had been naming a project that stopped existing three months earlier, and no run ever reported it: a script nobody invokes is a script nobody sees fail.

The change

- "test:integration": "vitest run --project ui",+ "test:integration": "vitest run --project dom --project dom-heavy",

The stale name moves to the projects that exist; no project named ui is added to vitest.config.mts. dom + dom-heavy is what ui covered, expressed in today's split — the two DOM tiers are the complement of unit among the root-level projects, which is precisely the population ui was defined as.

One judgement call, called out for review: apps/console is its own project today (name @object-ui/console, derived by Vitest from that directory's package.json), and the 2026-02 ui glob did include apps/*/src/**. It is not included here — that project is an app's own suite with its own alias config, not the renderer integration tier, and pnpm test covers it either way. Say the word and it becomes a third --project.

The pin

scripts/__tests__/package-scripts-vitest-projects.test.ts holds the two halves to each other: every --project name a root script passes must be a project this repo declares.

The assertion is a subset check (script names ⊆ declared names), so an over-wide declared set can never fail it — which makes every leg of the derivation silently vacuous unless it carries its own control. Each one does, asserted against a name measured on this tree:

• the extractor collects every--project occurrence, not just the last. This is deliberate and is why parseVitestArgv from scripts/vitest-invocation-guard.mjs is not reused: that parser keeps flags in a plain object, so a repeated flag collapses to its last value — and --project dom --project dom-heavy is exactly that shape. Reusing it would have checked dom-heavy and quietly skipped dom. Controlled by a case asserting both names come back, plus --project=NAME and two no-match forms.
• the inline projects — unit, dom, dom-heavy, and the env-gated dist — read off the config's source text. Controlled by asserting all four are found.
• the project brought in by config path — @object-ui/console, whose name appears as no name: literal anywhere in the repo. Without this leg a root script that legitimately named it would go red. Controlled by asserting it is found; measured with pnpm exec vitest list --project @object-ui/console, which resolves.
• a negative control that the derivation does not answer yes to everything, deliberately using a nonsense name rather than ui, so the control stays a control instead of quietly becoming policy about which names are allowed.

Source text, not an import (ZONE 2 assumption 5). An import answers a different question: the dist project only materialises when OBJECTUI_DIST_PINS=1, so the imported project list depends on the environment while the declaration surface does not. Importing would also execute that file's module scope — including its --project dist argv guard, which throws — inside the test process.

Evidence

Every heavy run went through the shared verify lock (OS_VERIFY_LOCK_SLOT=dev-7096); exit codes captured after redirection, never across a pipe.

Pin red before the script change (pin written first, measured on the unmodified tree):

❯ |unit| scripts/__tests__/package-scripts-vitest-projects.test.ts (8 tests | 1 failed)
AssertionError: Root scripts filter on 1 project(s) that vitest.config.mts does not declare,
so those scripts cannot run:
pnpm test:integration → --project ui
Declared: @object-ui/console, dist, dom, dom-heavy, unit
Test Files 1 failed (1)
Tests 1 failed | 7 passed (8)
INNER_EXIT=1

The other 7 — every control — passed there, so the red is the subset check firing, not a broken derivation.

Pin green after, at head 652bd11e0:Test Files 1 passed (1) / Tests 8 passed (8), INNER_EXIT=0.

The card's acceptance — the script now starts and runs:

> object-ui-monorepo@ test:integration
> vitest run --project dom --project dom-heavy --shard=1/16
Test Files 92 passed (92)
Tests 1054 passed (1054)
INNER_EXIT=0

Declared narrowing: that is one shard of sixteen, not the whole tier. pnpm exec vitest list --filesOnly --project dom --project dom-heavy collects 1463 files (1429 dom + 34 dom-heavy) — both filters resolve, and an unsharded run of that surface does not fit this container's ~10-minute foreground cap. CI runs the same files as pnpm test --shard=n/4.

Ablation (after committing, so HEAD holds the fix). Only the script line was reverted to --project ui. The mutation was proven on disk by anchoring on both texts — injected "vitest run --project ui" present ×1, removed --project dom --project dom-heavy absent ×0 — and by blob hash bef1402ad… differing from the HEAD blob 1bb6f8fcc…; the script aborts rather than measure if either check fails. No rebuild leg applies: the pin reads both files off disk with fs.readFileSync, with no built artifact between them. Under the mutation the pin went red naming pnpm test:integration → --project ui, ABLATED_PIN_EXIT=1. Restore was git checkout HEAD -- ABSOLUTE_PATH (with an absolute-path trap … EXIT INT TERM) and is proven by state, not exit code: worktree blob 1bb6f8fccaaaed7c58a61a352e3ae2d3d803d1ae equals the HEAD blob, git diff HEAD empty, git status clean.

Other gates, all with their own verdict line:

command	verdict
pnpm exec vitest run scripts/__tests__/	Test Files 97 passed (97) / Tests 2738 passed (2738), exit 0
pnpm test:unit --shard=1/8 (unchanged)	Test Files 102 passed (102) / Tests 1546 passed (1546), exit 0
pnpm type-check:scripts	exit 0 — and tsc --listFiles confirms the new file is in the program (1 hit), so this is a measurement, not a vacuous pass
pnpm lint:root	✖ 33 problems (0 errors, 33 warnings), exit 0; the new file alone lints clean at exit 0
pnpm lint:coverage	✅ lint coverage: 46/46 packages linted, 0 with outstanding errors
pnpm type-check:coverage	✅ type-check coverage: 45/46 via type-check … / ✅ test type-check coverage: 41/41
node scripts/check-control-bytes.mjs	✅ check-control-bytes: OK (scanned 6016 tracked text file(s); skipped 85 binary)
node scripts/check-changeset-presence.mjs	✅ No source or published contract of a released package changed in this range, so no changeset is owed.
node scripts/check-changeset-no-major.mjs	✅ No changeset declares a major bump.
node scripts/check-governed-queue-guard.mjs --test …	✅ NOT GOVERNED — 2 path(s) checked against 5 governed surface(s); none matched.

No changeset — the presence gate's own verdict line above says none is owed: root package.json is not published source and the pin is a test.

Nothing else teaches this script.git grep -n "test:integration" origin/main returns exactly one hit, package.json:25. Nothing under AGENTS.md, CLAUDE.md, .claude/**, skills/**, content/docs/** or docs/** mentions it, so no governed or docs surface needed touching. For the record, skills/objectui/guides/testing.md:45 does name the project split (--project unit / dom / dom-heavy) and stays accurate after this change.

Session: https://claude.ai/code/session_01NRRumy89BYdW9ogbcdHTho

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[os-litant]

Fixes#7096

Measured at head 652bd11e0.

The defect, confirmed

pnpm test:integration was vitest run --project ui while no project named ui existed, so the script could not run at all. Reproduced on the base commit ad3d4029a:

$ pnpm exec vitest run --project ui
Error: No projects matched the filter "ui".
INNER_EXIT=1

Why it drifted — history, not a typo

ui was a real project once. It was declared in vitest.workspace.ts (1bdba0693, 2026-02-28) as the complement of unit: every *.test.ts / *.test.tsx under packages, apps and examples except the four pure-logic packages.

85c872487 (2026-05-24) deleted that file, because Vitest 4 removed defineWorkspace and had been silently ignoring it. That took unitandui down together. unit was later re-declared as an inline project in vitest.config.mts (e850c5695) — a commit that never touched package.json — so pnpm test:unit started resolving again by accident. Nothing ever re-declared ui.

So the script had been naming a project that stopped existing three months earlier, and no run ever reported it: a script nobody invokes is a script nobody sees fail.

The change

- "test:integration": "vitest run --project ui",+ "test:integration": "vitest run --project dom --project dom-heavy",

The stale name moves to the projects that exist; no project named ui is added to vitest.config.mts. dom + dom-heavy is what ui covered, expressed in today's split — the two DOM tiers are the complement of unit among the root-level projects, which is precisely the population ui was defined as.

One judgement call, called out for review: apps/console is its own project today (name @object-ui/console, derived by Vitest from that directory's package.json), and the 2026-02 ui glob did include apps/*/src/**. It is not included here — that project is an app's own suite with its own alias config, not the renderer integration tier, and pnpm test covers it either way. Say the word and it becomes a third --project.

The pin

scripts/__tests__/package-scripts-vitest-projects.test.ts holds the two halves to each other: every --project name a root script passes must be a project this repo declares.

The assertion is a subset check (script names ⊆ declared names), so an over-wide declared set can never fail it — which makes every leg of the derivation silently vacuous unless it carries its own control. Each one does, asserted against a name measured on this tree:

• the extractor collects every--project occurrence, not just the last. This is deliberate and is why parseVitestArgv from scripts/vitest-invocation-guard.mjs is not reused: that parser keeps flags in a plain object, so a repeated flag collapses to its last value — and --project dom --project dom-heavy is exactly that shape. Reusing it would have checked dom-heavy and quietly skipped dom. Controlled by a case asserting both names come back, plus --project=NAME and two no-match forms.
• the inline projects — unit, dom, dom-heavy, and the env-gated dist — read off the config's source text. Controlled by asserting all four are found.
• the project brought in by config path — @object-ui/console, whose name appears as no name: literal anywhere in the repo. Without this leg a root script that legitimately named it would go red. Controlled by asserting it is found; measured with pnpm exec vitest list --project @object-ui/console, which resolves.
• a negative control that the derivation does not answer yes to everything, deliberately using a nonsense name rather than ui, so the control stays a control instead of quietly becoming policy about which names are allowed.

Source text, not an import (ZONE 2 assumption 5). An import answers a different question: the dist project only materialises when OBJECTUI_DIST_PINS=1, so the imported project list depends on the environment while the declaration surface does not. Importing would also execute that file's module scope — including its --project dist argv guard, which throws — inside the test process.

Evidence

Every heavy run went through the shared verify lock (OS_VERIFY_LOCK_SLOT=dev-7096); exit codes captured after redirection, never across a pipe.

Pin red before the script change (pin written first, measured on the unmodified tree):

❯ |unit| scripts/__tests__/package-scripts-vitest-projects.test.ts (8 tests | 1 failed)
AssertionError: Root scripts filter on 1 project(s) that vitest.config.mts does not declare,
so those scripts cannot run:
pnpm test:integration → --project ui
Declared: @object-ui/console, dist, dom, dom-heavy, unit
Test Files 1 failed (1)
Tests 1 failed | 7 passed (8)
INNER_EXIT=1

The other 7 — every control — passed there, so the red is the subset check firing, not a broken derivation.

Pin green after, at head 652bd11e0:Test Files 1 passed (1) / Tests 8 passed (8), INNER_EXIT=0.

The card's acceptance — the script now starts and runs:

> object-ui-monorepo@ test:integration
> vitest run --project dom --project dom-heavy --shard=1/16
Test Files 92 passed (92)
Tests 1054 passed (1054)
INNER_EXIT=0

Declared narrowing: that is one shard of sixteen, not the whole tier. pnpm exec vitest list --filesOnly --project dom --project dom-heavy collects 1463 files (1429 dom + 34 dom-heavy) — both filters resolve, and an unsharded run of that surface does not fit this container's ~10-minute foreground cap. CI runs the same files as pnpm test --shard=n/4.

Ablation (after committing, so HEAD holds the fix). Only the script line was reverted to --project ui. The mutation was proven on disk by anchoring on both texts — injected "vitest run --project ui" present ×1, removed --project dom --project dom-heavy absent ×0 — and by blob hash bef1402ad… differing from the HEAD blob 1bb6f8fcc…; the script aborts rather than measure if either check fails. No rebuild leg applies: the pin reads both files off disk with fs.readFileSync, with no built artifact between them. Under the mutation the pin went red naming pnpm test:integration → --project ui, ABLATED_PIN_EXIT=1. Restore was git checkout HEAD -- ABSOLUTE_PATH (with an absolute-path trap … EXIT INT TERM) and is proven by state, not exit code: worktree blob 1bb6f8fccaaaed7c58a61a352e3ae2d3d803d1ae equals the HEAD blob, git diff HEAD empty, git status clean.

Other gates, all with their own verdict line:

command	verdict
pnpm exec vitest run scripts/__tests__/	Test Files 97 passed (97) / Tests 2738 passed (2738), exit 0
pnpm test:unit --shard=1/8 (unchanged)	Test Files 102 passed (102) / Tests 1546 passed (1546), exit 0
pnpm type-check:scripts	exit 0 — and tsc --listFiles confirms the new file is in the program (1 hit), so this is a measurement, not a vacuous pass
pnpm lint:root	✖ 33 problems (0 errors, 33 warnings), exit 0; the new file alone lints clean at exit 0
pnpm lint:coverage	✅ lint coverage: 46/46 packages linted, 0 with outstanding errors
pnpm type-check:coverage	✅ type-check coverage: 45/46 via type-check … / ✅ test type-check coverage: 41/41
node scripts/check-control-bytes.mjs	✅ check-control-bytes: OK (scanned 6016 tracked text file(s); skipped 85 binary)
node scripts/check-changeset-presence.mjs	✅ No source or published contract of a released package changed in this range, so no changeset is owed.
node scripts/check-changeset-no-major.mjs	✅ No changeset declares a major bump.
node scripts/check-governed-queue-guard.mjs --test …	✅ NOT GOVERNED — 2 path(s) checked against 5 governed surface(s); none matched.

No changeset — the presence gate's own verdict line above says none is owed: root package.json is not published source and the pin is a test.

Nothing else teaches this script.git grep -n "test:integration" origin/main returns exactly one hit, package.json:25. Nothing under AGENTS.md, CLAUDE.md, .claude/**, skills/**, content/docs/** or docs/** mentions it, so no governed or docs surface needed touching. For the record, skills/objectui/guides/testing.md:45 does name the project split (--project unit / dom / dom-heavy) and stays accurate after this change.

Session: https://claude.ai/code/session_01NRRumy89BYdW9ogbcdHTho

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code