test(scripts): pin @object-ui/fields' published stylesheet as a third subject

[zhuangjianguo]

Fixes#6438

scripts/__tests__/plugin-published-stylesheet.test.ts ran its per-package
assertions over exactly two subjects, plugin-grid and plugin-kanban.
@object-ui/fields was not one of them — and it is the package whose stylesheet
has actually been shipping to consumers since #4059, the very defect the test's
own header cites as the reason the shape exists. Its dist/index.css was
guarded by the four write-time assertions inside the shared builder, which run
only during a build; CI runs this suite on an unbuilt worktree, so nothing in
the test run inspected it.

This adds fields as a third subject. The suite goes from 14 tests to 20
(three subjects times six per-package assertions, plus two standalone).

Premise re-verified on the merged ref

Re-read on main = e33b44796, item for item, rather than inherited:
packages/fields/scripts/build-css.mjs (notbuild-stylesheet.mjs) imports
createPluginStylesheetBuilder at line 94 and exports PACKAGE_ROOT / PACKAGE_NAME
(96/97), MUST_SURVIVE / CLASS_CEILING (114/132), builder / buildOptions
(161/163) behind the isEntrypoint guard (171) — the same shape the two plugins
export. SUBJECTS was at test line 91.

How the CARD_THEMED entry was derived

Independently, from the sheet the build actually emits — not read back off
fields' own MUST_SURVIVE, which would have looked identical while pinning
nothing.

Method: build fields' sheet through the shared builder, then keep every
surviving class whose own declarations resolve a --color-* token declared in
packages/components/src/index.css's @theme block (35 tokens) — the file that
package does not publish, which is exactly what makes an in-monorepo build the
only possible producer of these utilities.

That yields 17 surviving themed classes out of 163 surviving total. Two
independent corroborations:

• packages/fields/scripts/build-css.mjs records, from @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059, that "17 of those
  depend on the ObjectUI @theme block" — the same count, reached by a
  different method.
• The three utilities @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059 names (bg-primary/20, hover:bg-accent/30,
  ring-destructive/50) are 3 of the 17, confirming they were the starting
  corpus and not the answer. The other 14 are ones a literal-grep method could
  not see.

Only 3 of the 17 appear in MUST_SURVIVE, so the list is demonstrably not that
list read back.

Banner: taken from buildOptions, and why nothing changed

fields passes a per-package header (HEADER, line 147, into buildOptions at
line 168); plugin-grid's buildOptions has no header key and inherits the
shared defaultHeader. The emitted sheet is header plus the sheet, so any
assertion reading the banner from the shared default would judge fields wrongly.

Surveyed before writing: no assertion in the suite reads the emitted banner,
so the caveat is preventive here, not corrective. The one assertion that
inspects the whole css string — "carries utilities only" — was checked against
fields' actual HEADER bytes and none of its three patterns can match it. The
module header now records the rule for anything added later. A banner pin is
not added here, for a reason recorded as a follow-up below.

Proof the new assertions have teeth

"The suite is green after I added it" is not evidence — a green assertion that
inspects nothing is precisely the defect this card records. Two ablations, each
proving the mutation reached disk before measuring, and each proving the restore
by blob hash rather than by exit code:

1. A themed utility stops being produced.hover:bg-primary/10 is in the
derived list and deliberately not in MUST_SURVIVE, so the builder's
write-time throw does not fire and mask the result. Its single usage site in
RecordPickerDialog.tsx was retargeted to hover:bg-primary/15.

• on disk: occurrences of the removed text 1 to 0, injected text 0 to 1; blob moved 1e9d341d to 3e0a4915
• result: Tests 1 failed | 19 passed, the failure being
  fields > emits the themed utilities only this build can produce with
  AssertionError: expected [ 'hover:bg-primary/10' ] to deeply equal []
• restore: blob back to 1e9d341d, git diff HEAD empty

2. The manifest declaration breaks. fields' exports['./style.css'] was
pointed at ./dist/nope.css, which also proves the subject name resolves to
packages/fields.

• on disk: injected 1, original pair 0; blob moved 5e442f18 to 98eeea6f
• result: Tests 1 failed | 19 passed, the failure being
  fields > declares the export AND the step that produces it
• restore: blob back to 5e442f18, git diff HEAD empty

In both runs exactly one assertion went red and it was a fields one, with
plugin-grid and plugin-kanban still green — so the red is subject-specific,
not a global break.

The finding that justifies the per-package coverage

Under ablation 1 the union assertion, "gives every themed utility the card
measured a producer", stayed green. Measured cause: plugin-grid also emits
hover:bg-primary/10, so the union was satisfied by another subject while
fields' own sheet had genuinely regressed. Adding fields to SUBJECTS is what
buys the coverage; adding it only to CARD_THEMED would have reproduced the
defect this card records.

Verification

Union run on the final commit, git rev-parse --short HEAD = 1219b8d88, tree clean:

• npx vitest run scripts/__tests__/plugin-published-stylesheet.test.ts --maxWorkers=2 — Tests 20 passed (20), exit 0
• pnpm type-check:scripts — exit 0. Load-bearing: the shared builder's own comment records that this reads the options types through this test file, and fields is the first subject to pass header.
• pnpm type-check:coverage — 45/46 via type-check, 41/41 packages compile their tests
• pnpm check:control-bytes — OK (scanned 5850 tracked text file(s))
• pnpm changeset:check — no major, fixed group OK
• node scripts/check-changeset-presence.mjs — "no changeset is owed"; the changeset is an explicit no-release declaration in the empty-frontmatter shape this repo uses for test-only changes
• eslint on the changed file — 0 errors, 0 warnings

Lint was narrowed to the changed file rather than run farm-wide, and the
narrowing is measured, not assumed: the file count comes from eslint's own
--format json output (1 file), and type-aware linting is not enabled in
eslint.config.js (no projectService, project: or parserOptions;
control term rules hits 10 times in the same file, so the query was live), so
this diff cannot move the verdict on any untouched file. CI runs the full farm
regardless.

Follow-up, filed not ridden along

The emitted banner is pinned by nothing, and it cannot be pinned cleanly today:
the shared builder does not export its defaultHeader, so an assertion covering
all three subjects would need a tolerant fallback in the test for the two
packages that declare no header — the consumer-side leniency this repo's
contract-first rule says to fix at the producer instead. That is a
producer-side change with its own review, so it is recorded rather than ridden
along here.

---

Generated by Claude Code

[zhuangjianguo]

Fixes#6438

scripts/__tests__/plugin-published-stylesheet.test.ts ran its per-package
assertions over exactly two subjects, plugin-grid and plugin-kanban.
@object-ui/fields was not one of them — and it is the package whose stylesheet
has actually been shipping to consumers since #4059, the very defect the test's
own header cites as the reason the shape exists. Its dist/index.css was
guarded by the four write-time assertions inside the shared builder, which run
only during a build; CI runs this suite on an unbuilt worktree, so nothing in
the test run inspected it.

This adds fields as a third subject. The suite goes from 14 tests to 20
(three subjects times six per-package assertions, plus two standalone).

Premise re-verified on the merged ref

Re-read on main = e33b44796, item for item, rather than inherited:
packages/fields/scripts/build-css.mjs (notbuild-stylesheet.mjs) imports
createPluginStylesheetBuilder at line 94 and exports PACKAGE_ROOT / PACKAGE_NAME
(96/97), MUST_SURVIVE / CLASS_CEILING (114/132), builder / buildOptions
(161/163) behind the isEntrypoint guard (171) — the same shape the two plugins
export. SUBJECTS was at test line 91.

How the CARD_THEMED entry was derived

Independently, from the sheet the build actually emits — not read back off
fields' own MUST_SURVIVE, which would have looked identical while pinning
nothing.

Method: build fields' sheet through the shared builder, then keep every
surviving class whose own declarations resolve a --color-* token declared in
packages/components/src/index.css's @theme block (35 tokens) — the file that
package does not publish, which is exactly what makes an in-monorepo build the
only possible producer of these utilities.

That yields 17 surviving themed classes out of 163 surviving total. Two
independent corroborations:

• packages/fields/scripts/build-css.mjs records, from @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059, that "17 of those
  depend on the ObjectUI @theme block" — the same count, reached by a
  different method.
• The three utilities @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059 names (bg-primary/20, hover:bg-accent/30,
  ring-destructive/50) are 3 of the 17, confirming they were the starting
  corpus and not the answer. The other 14 are ones a literal-grep method could
  not see.

Only 3 of the 17 appear in MUST_SURVIVE, so the list is demonstrably not that
list read back.

Banner: taken from buildOptions, and why nothing changed

fields passes a per-package header (HEADER, line 147, into buildOptions at
line 168); plugin-grid's buildOptions has no header key and inherits the
shared defaultHeader. The emitted sheet is header plus the sheet, so any
assertion reading the banner from the shared default would judge fields wrongly.

Surveyed before writing: no assertion in the suite reads the emitted banner,
so the caveat is preventive here, not corrective. The one assertion that
inspects the whole css string — "carries utilities only" — was checked against
fields' actual HEADER bytes and none of its three patterns can match it. The
module header now records the rule for anything added later. A banner pin is
not added here, for a reason recorded as a follow-up below.

Proof the new assertions have teeth

"The suite is green after I added it" is not evidence — a green assertion that
inspects nothing is precisely the defect this card records. Two ablations, each
proving the mutation reached disk before measuring, and each proving the restore
by blob hash rather than by exit code:

1. A themed utility stops being produced.hover:bg-primary/10 is in the
derived list and deliberately not in MUST_SURVIVE, so the builder's
write-time throw does not fire and mask the result. Its single usage site in
RecordPickerDialog.tsx was retargeted to hover:bg-primary/15.

• on disk: occurrences of the removed text 1 to 0, injected text 0 to 1; blob moved 1e9d341d to 3e0a4915
• result: Tests 1 failed | 19 passed, the failure being
  fields > emits the themed utilities only this build can produce with
  AssertionError: expected [ 'hover:bg-primary/10' ] to deeply equal []
• restore: blob back to 1e9d341d, git diff HEAD empty

2. The manifest declaration breaks. fields' exports['./style.css'] was
pointed at ./dist/nope.css, which also proves the subject name resolves to
packages/fields.

• on disk: injected 1, original pair 0; blob moved 5e442f18 to 98eeea6f
• result: Tests 1 failed | 19 passed, the failure being
  fields > declares the export AND the step that produces it
• restore: blob back to 5e442f18, git diff HEAD empty

In both runs exactly one assertion went red and it was a fields one, with
plugin-grid and plugin-kanban still green — so the red is subject-specific,
not a global break.

The finding that justifies the per-package coverage

Under ablation 1 the union assertion, "gives every themed utility the card
measured a producer", stayed green. Measured cause: plugin-grid also emits
hover:bg-primary/10, so the union was satisfied by another subject while
fields' own sheet had genuinely regressed. Adding fields to SUBJECTS is what
buys the coverage; adding it only to CARD_THEMED would have reproduced the
defect this card records.

Verification

Union run on the final commit, git rev-parse --short HEAD = 1219b8d88, tree clean:

• npx vitest run scripts/__tests__/plugin-published-stylesheet.test.ts --maxWorkers=2 — Tests 20 passed (20), exit 0
• pnpm type-check:scripts — exit 0. Load-bearing: the shared builder's own comment records that this reads the options types through this test file, and fields is the first subject to pass header.
• pnpm type-check:coverage — 45/46 via type-check, 41/41 packages compile their tests
• pnpm check:control-bytes — OK (scanned 5850 tracked text file(s))
• pnpm changeset:check — no major, fixed group OK
• node scripts/check-changeset-presence.mjs — "no changeset is owed"; the changeset is an explicit no-release declaration in the empty-frontmatter shape this repo uses for test-only changes
• eslint on the changed file — 0 errors, 0 warnings

Lint was narrowed to the changed file rather than run farm-wide, and the
narrowing is measured, not assumed: the file count comes from eslint's own
--format json output (1 file), and type-aware linting is not enabled in
eslint.config.js (no projectService, project: or parserOptions;
control term rules hits 10 times in the same file, so the query was live), so
this diff cannot move the verdict on any untouched file. CI runs the full farm
regardless.

Follow-up, filed not ridden along

The emitted banner is pinned by nothing, and it cannot be pinned cleanly today:
the shared builder does not export its defaultHeader, so an assertion covering
all three subjects would need a tolerant fallback in the test for the two
packages that declare no header — the consumer-side leniency this repo's
contract-first rule says to fix at the producer instead. That is a
producer-side change with its own review, so it is recorded rather than ridden
along here.

---

Generated by Claude Code

[zhuangjianguo]

Fixes#6438

scripts/__tests__/plugin-published-stylesheet.test.ts ran its per-package
assertions over exactly two subjects, plugin-grid and plugin-kanban.
@object-ui/fields was not one of them — and it is the package whose stylesheet
has actually been shipping to consumers since #4059, the very defect the test's
own header cites as the reason the shape exists. Its dist/index.css was
guarded by the four write-time assertions inside the shared builder, which run
only during a build; CI runs this suite on an unbuilt worktree, so nothing in
the test run inspected it.

This adds fields as a third subject. The suite goes from 14 tests to 20
(three subjects times six per-package assertions, plus two standalone).

Premise re-verified on the merged ref

Re-read on main = e33b44796, item for item, rather than inherited:
packages/fields/scripts/build-css.mjs (notbuild-stylesheet.mjs) imports
createPluginStylesheetBuilder at line 94 and exports PACKAGE_ROOT / PACKAGE_NAME
(96/97), MUST_SURVIVE / CLASS_CEILING (114/132), builder / buildOptions
(161/163) behind the isEntrypoint guard (171) — the same shape the two plugins
export. SUBJECTS was at test line 91.

How the CARD_THEMED entry was derived

Independently, from the sheet the build actually emits — not read back off
fields' own MUST_SURVIVE, which would have looked identical while pinning
nothing.

Method: build fields' sheet through the shared builder, then keep every
surviving class whose own declarations resolve a --color-* token declared in
packages/components/src/index.css's @theme block (35 tokens) — the file that
package does not publish, which is exactly what makes an in-monorepo build the
only possible producer of these utilities.

That yields 17 surviving themed classes out of 163 surviving total. Two
independent corroborations:

• packages/fields/scripts/build-css.mjs records, from @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059, that "17 of those
  depend on the ObjectUI @theme block" — the same count, reached by a
  different method.
• The three utilities @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059 names (bg-primary/20, hover:bg-accent/30,
  ring-destructive/50) are 3 of the 17, confirming they were the starting
  corpus and not the answer. The other 14 are ones a literal-grep method could
  not see.

Only 3 of the 17 appear in MUST_SURVIVE, so the list is demonstrably not that
list read back.

Banner: taken from buildOptions, and why nothing changed

fields passes a per-package header (HEADER, line 147, into buildOptions at
line 168); plugin-grid's buildOptions has no header key and inherits the
shared defaultHeader. The emitted sheet is header plus the sheet, so any
assertion reading the banner from the shared default would judge fields wrongly.

Surveyed before writing: no assertion in the suite reads the emitted banner,
so the caveat is preventive here, not corrective. The one assertion that
inspects the whole css string — "carries utilities only" — was checked against
fields' actual HEADER bytes and none of its three patterns can match it. The
module header now records the rule for anything added later. A banner pin is
not added here, for a reason recorded as a follow-up below.

Proof the new assertions have teeth

"The suite is green after I added it" is not evidence — a green assertion that
inspects nothing is precisely the defect this card records. Two ablations, each
proving the mutation reached disk before measuring, and each proving the restore
by blob hash rather than by exit code:

1. A themed utility stops being produced.hover:bg-primary/10 is in the
derived list and deliberately not in MUST_SURVIVE, so the builder's
write-time throw does not fire and mask the result. Its single usage site in
RecordPickerDialog.tsx was retargeted to hover:bg-primary/15.

• on disk: occurrences of the removed text 1 to 0, injected text 0 to 1; blob moved 1e9d341d to 3e0a4915
• result: Tests 1 failed | 19 passed, the failure being
  fields > emits the themed utilities only this build can produce with
  AssertionError: expected [ 'hover:bg-primary/10' ] to deeply equal []
• restore: blob back to 1e9d341d, git diff HEAD empty

2. The manifest declaration breaks. fields' exports['./style.css'] was
pointed at ./dist/nope.css, which also proves the subject name resolves to
packages/fields.

• on disk: injected 1, original pair 0; blob moved 5e442f18 to 98eeea6f
• result: Tests 1 failed | 19 passed, the failure being
  fields > declares the export AND the step that produces it
• restore: blob back to 5e442f18, git diff HEAD empty

In both runs exactly one assertion went red and it was a fields one, with
plugin-grid and plugin-kanban still green — so the red is subject-specific,
not a global break.

The finding that justifies the per-package coverage

Under ablation 1 the union assertion, "gives every themed utility the card
measured a producer", stayed green. Measured cause: plugin-grid also emits
hover:bg-primary/10, so the union was satisfied by another subject while
fields' own sheet had genuinely regressed. Adding fields to SUBJECTS is what
buys the coverage; adding it only to CARD_THEMED would have reproduced the
defect this card records.

Verification

Union run on the final commit, git rev-parse --short HEAD = 1219b8d88, tree clean:

• npx vitest run scripts/__tests__/plugin-published-stylesheet.test.ts --maxWorkers=2 — Tests 20 passed (20), exit 0
• pnpm type-check:scripts — exit 0. Load-bearing: the shared builder's own comment records that this reads the options types through this test file, and fields is the first subject to pass header.
• pnpm type-check:coverage — 45/46 via type-check, 41/41 packages compile their tests
• pnpm check:control-bytes — OK (scanned 5850 tracked text file(s))
• pnpm changeset:check — no major, fixed group OK
• node scripts/check-changeset-presence.mjs — "no changeset is owed"; the changeset is an explicit no-release declaration in the empty-frontmatter shape this repo uses for test-only changes
• eslint on the changed file — 0 errors, 0 warnings

Lint was narrowed to the changed file rather than run farm-wide, and the
narrowing is measured, not assumed: the file count comes from eslint's own
--format json output (1 file), and type-aware linting is not enabled in
eslint.config.js (no projectService, project: or parserOptions;
control term rules hits 10 times in the same file, so the query was live), so
this diff cannot move the verdict on any untouched file. CI runs the full farm
regardless.

Follow-up, filed not ridden along

The emitted banner is pinned by nothing, and it cannot be pinned cleanly today:
the shared builder does not export its defaultHeader, so an assertion covering
all three subjects would need a tolerant fallback in the test for the two
packages that declare no header — the consumer-side leniency this repo's
contract-first rule says to fix at the producer instead. That is a
producer-side change with its own review, so it is recorded rather than ridden
along here.

---

Generated by Claude Code

[zhuangjianguo]

Fixes#6438

scripts/__tests__/plugin-published-stylesheet.test.ts ran its per-package
assertions over exactly two subjects, plugin-grid and plugin-kanban.
@object-ui/fields was not one of them — and it is the package whose stylesheet
has actually been shipping to consumers since #4059, the very defect the test's
own header cites as the reason the shape exists. Its dist/index.css was
guarded by the four write-time assertions inside the shared builder, which run
only during a build; CI runs this suite on an unbuilt worktree, so nothing in
the test run inspected it.

This adds fields as a third subject. The suite goes from 14 tests to 20
(three subjects times six per-package assertions, plus two standalone).

Premise re-verified on the merged ref

Re-read on main = e33b44796, item for item, rather than inherited:
packages/fields/scripts/build-css.mjs (notbuild-stylesheet.mjs) imports
createPluginStylesheetBuilder at line 94 and exports PACKAGE_ROOT / PACKAGE_NAME
(96/97), MUST_SURVIVE / CLASS_CEILING (114/132), builder / buildOptions
(161/163) behind the isEntrypoint guard (171) — the same shape the two plugins
export. SUBJECTS was at test line 91.

How the CARD_THEMED entry was derived

Independently, from the sheet the build actually emits — not read back off
fields' own MUST_SURVIVE, which would have looked identical while pinning
nothing.

Method: build fields' sheet through the shared builder, then keep every
surviving class whose own declarations resolve a --color-* token declared in
packages/components/src/index.css's @theme block (35 tokens) — the file that
package does not publish, which is exactly what makes an in-monorepo build the
only possible producer of these utilities.

That yields 17 surviving themed classes out of 163 surviving total. Two
independent corroborations:

• packages/fields/scripts/build-css.mjs records, from @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059, that "17 of those
  depend on the ObjectUI @theme block" — the same count, reached by a
  different method.
• The three utilities @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059 names (bg-primary/20, hover:bg-accent/30,
  ring-destructive/50) are 3 of the 17, confirming they were the starting
  corpus and not the answer. The other 14 are ones a literal-grep method could
  not see.

Only 3 of the 17 appear in MUST_SURVIVE, so the list is demonstrably not that
list read back.

Banner: taken from buildOptions, and why nothing changed

fields passes a per-package header (HEADER, line 147, into buildOptions at
line 168); plugin-grid's buildOptions has no header key and inherits the
shared defaultHeader. The emitted sheet is header plus the sheet, so any
assertion reading the banner from the shared default would judge fields wrongly.

Surveyed before writing: no assertion in the suite reads the emitted banner,
so the caveat is preventive here, not corrective. The one assertion that
inspects the whole css string — "carries utilities only" — was checked against
fields' actual HEADER bytes and none of its three patterns can match it. The
module header now records the rule for anything added later. A banner pin is
not added here, for a reason recorded as a follow-up below.

Proof the new assertions have teeth

"The suite is green after I added it" is not evidence — a green assertion that
inspects nothing is precisely the defect this card records. Two ablations, each
proving the mutation reached disk before measuring, and each proving the restore
by blob hash rather than by exit code:

1. A themed utility stops being produced.hover:bg-primary/10 is in the
derived list and deliberately not in MUST_SURVIVE, so the builder's
write-time throw does not fire and mask the result. Its single usage site in
RecordPickerDialog.tsx was retargeted to hover:bg-primary/15.

• on disk: occurrences of the removed text 1 to 0, injected text 0 to 1; blob moved 1e9d341d to 3e0a4915
• result: Tests 1 failed | 19 passed, the failure being
  fields > emits the themed utilities only this build can produce with
  AssertionError: expected [ 'hover:bg-primary/10' ] to deeply equal []
• restore: blob back to 1e9d341d, git diff HEAD empty

2. The manifest declaration breaks. fields' exports['./style.css'] was
pointed at ./dist/nope.css, which also proves the subject name resolves to
packages/fields.

• on disk: injected 1, original pair 0; blob moved 5e442f18 to 98eeea6f
• result: Tests 1 failed | 19 passed, the failure being
  fields > declares the export AND the step that produces it
• restore: blob back to 5e442f18, git diff HEAD empty

In both runs exactly one assertion went red and it was a fields one, with
plugin-grid and plugin-kanban still green — so the red is subject-specific,
not a global break.

The finding that justifies the per-package coverage

Under ablation 1 the union assertion, "gives every themed utility the card
measured a producer", stayed green. Measured cause: plugin-grid also emits
hover:bg-primary/10, so the union was satisfied by another subject while
fields' own sheet had genuinely regressed. Adding fields to SUBJECTS is what
buys the coverage; adding it only to CARD_THEMED would have reproduced the
defect this card records.

Verification

Union run on the final commit, git rev-parse --short HEAD = 1219b8d88, tree clean:

• npx vitest run scripts/__tests__/plugin-published-stylesheet.test.ts --maxWorkers=2 — Tests 20 passed (20), exit 0
• pnpm type-check:scripts — exit 0. Load-bearing: the shared builder's own comment records that this reads the options types through this test file, and fields is the first subject to pass header.
• pnpm type-check:coverage — 45/46 via type-check, 41/41 packages compile their tests
• pnpm check:control-bytes — OK (scanned 5850 tracked text file(s))
• pnpm changeset:check — no major, fixed group OK
• node scripts/check-changeset-presence.mjs — "no changeset is owed"; the changeset is an explicit no-release declaration in the empty-frontmatter shape this repo uses for test-only changes
• eslint on the changed file — 0 errors, 0 warnings

Lint was narrowed to the changed file rather than run farm-wide, and the
narrowing is measured, not assumed: the file count comes from eslint's own
--format json output (1 file), and type-aware linting is not enabled in
eslint.config.js (no projectService, project: or parserOptions;
control term rules hits 10 times in the same file, so the query was live), so
this diff cannot move the verdict on any untouched file. CI runs the full farm
regardless.

Follow-up, filed not ridden along

The emitted banner is pinned by nothing, and it cannot be pinned cleanly today:
the shared builder does not export its defaultHeader, so an assertion covering
all three subjects would need a tolerant fallback in the test for the two
packages that declare no header — the consumer-side leniency this repo's
contract-first rule says to fix at the producer instead. That is a
producer-side change with its own review, so it is recorded rather than ridden
along here.

---

Generated by Claude Code

[zhuangjianguo]

Fixes#6438

scripts/__tests__/plugin-published-stylesheet.test.ts ran its per-package
assertions over exactly two subjects, plugin-grid and plugin-kanban.
@object-ui/fields was not one of them — and it is the package whose stylesheet
has actually been shipping to consumers since #4059, the very defect the test's
own header cites as the reason the shape exists. Its dist/index.css was
guarded by the four write-time assertions inside the shared builder, which run
only during a build; CI runs this suite on an unbuilt worktree, so nothing in
the test run inspected it.

This adds fields as a third subject. The suite goes from 14 tests to 20
(three subjects times six per-package assertions, plus two standalone).

Premise re-verified on the merged ref

Re-read on main = e33b44796, item for item, rather than inherited:
packages/fields/scripts/build-css.mjs (notbuild-stylesheet.mjs) imports
createPluginStylesheetBuilder at line 94 and exports PACKAGE_ROOT / PACKAGE_NAME
(96/97), MUST_SURVIVE / CLASS_CEILING (114/132), builder / buildOptions
(161/163) behind the isEntrypoint guard (171) — the same shape the two plugins
export. SUBJECTS was at test line 91.

How the CARD_THEMED entry was derived

Independently, from the sheet the build actually emits — not read back off
fields' own MUST_SURVIVE, which would have looked identical while pinning
nothing.

Method: build fields' sheet through the shared builder, then keep every
surviving class whose own declarations resolve a --color-* token declared in
packages/components/src/index.css's @theme block (35 tokens) — the file that
package does not publish, which is exactly what makes an in-monorepo build the
only possible producer of these utilities.

That yields 17 surviving themed classes out of 163 surviving total. Two
independent corroborations:

• packages/fields/scripts/build-css.mjs records, from @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059, that "17 of those
  depend on the ObjectUI @theme block" — the same count, reached by a
  different method.
• The three utilities @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059 names (bg-primary/20, hover:bg-accent/30,
  ring-destructive/50) are 3 of the 17, confirming they were the starting
  corpus and not the answer. The other 14 are ones a literal-grep method could
  not see.

Only 3 of the 17 appear in MUST_SURVIVE, so the list is demonstrably not that
list read back.

Banner: taken from buildOptions, and why nothing changed

fields passes a per-package header (HEADER, line 147, into buildOptions at
line 168); plugin-grid's buildOptions has no header key and inherits the
shared defaultHeader. The emitted sheet is header plus the sheet, so any
assertion reading the banner from the shared default would judge fields wrongly.

Surveyed before writing: no assertion in the suite reads the emitted banner,
so the caveat is preventive here, not corrective. The one assertion that
inspects the whole css string — "carries utilities only" — was checked against
fields' actual HEADER bytes and none of its three patterns can match it. The
module header now records the rule for anything added later. A banner pin is
not added here, for a reason recorded as a follow-up below.

Proof the new assertions have teeth

"The suite is green after I added it" is not evidence — a green assertion that
inspects nothing is precisely the defect this card records. Two ablations, each
proving the mutation reached disk before measuring, and each proving the restore
by blob hash rather than by exit code:

1. A themed utility stops being produced.hover:bg-primary/10 is in the
derived list and deliberately not in MUST_SURVIVE, so the builder's
write-time throw does not fire and mask the result. Its single usage site in
RecordPickerDialog.tsx was retargeted to hover:bg-primary/15.

• on disk: occurrences of the removed text 1 to 0, injected text 0 to 1; blob moved 1e9d341d to 3e0a4915
• result: Tests 1 failed | 19 passed, the failure being
  fields > emits the themed utilities only this build can produce with
  AssertionError: expected [ 'hover:bg-primary/10' ] to deeply equal []
• restore: blob back to 1e9d341d, git diff HEAD empty

2. The manifest declaration breaks. fields' exports['./style.css'] was
pointed at ./dist/nope.css, which also proves the subject name resolves to
packages/fields.

• on disk: injected 1, original pair 0; blob moved 5e442f18 to 98eeea6f
• result: Tests 1 failed | 19 passed, the failure being
  fields > declares the export AND the step that produces it
• restore: blob back to 5e442f18, git diff HEAD empty

In both runs exactly one assertion went red and it was a fields one, with
plugin-grid and plugin-kanban still green — so the red is subject-specific,
not a global break.

The finding that justifies the per-package coverage

Under ablation 1 the union assertion, "gives every themed utility the card
measured a producer", stayed green. Measured cause: plugin-grid also emits
hover:bg-primary/10, so the union was satisfied by another subject while
fields' own sheet had genuinely regressed. Adding fields to SUBJECTS is what
buys the coverage; adding it only to CARD_THEMED would have reproduced the
defect this card records.

Verification

Union run on the final commit, git rev-parse --short HEAD = 1219b8d88, tree clean:

• npx vitest run scripts/__tests__/plugin-published-stylesheet.test.ts --maxWorkers=2 — Tests 20 passed (20), exit 0
• pnpm type-check:scripts — exit 0. Load-bearing: the shared builder's own comment records that this reads the options types through this test file, and fields is the first subject to pass header.
• pnpm type-check:coverage — 45/46 via type-check, 41/41 packages compile their tests
• pnpm check:control-bytes — OK (scanned 5850 tracked text file(s))
• pnpm changeset:check — no major, fixed group OK
• node scripts/check-changeset-presence.mjs — "no changeset is owed"; the changeset is an explicit no-release declaration in the empty-frontmatter shape this repo uses for test-only changes
• eslint on the changed file — 0 errors, 0 warnings

Lint was narrowed to the changed file rather than run farm-wide, and the
narrowing is measured, not assumed: the file count comes from eslint's own
--format json output (1 file), and type-aware linting is not enabled in
eslint.config.js (no projectService, project: or parserOptions;
control term rules hits 10 times in the same file, so the query was live), so
this diff cannot move the verdict on any untouched file. CI runs the full farm
regardless.

Follow-up, filed not ridden along

The emitted banner is pinned by nothing, and it cannot be pinned cleanly today:
the shared builder does not export its defaultHeader, so an assertion covering
all three subjects would need a tolerant fallback in the test for the two
packages that declare no header — the consumer-side leniency this repo's
contract-first rule says to fix at the producer instead. That is a
producer-side change with its own review, so it is recorded rather than ridden
along here.

---

Generated by Claude Code

[zhuangjianguo]

Fixes#6438

scripts/__tests__/plugin-published-stylesheet.test.ts ran its per-package
assertions over exactly two subjects, plugin-grid and plugin-kanban.
@object-ui/fields was not one of them — and it is the package whose stylesheet
has actually been shipping to consumers since #4059, the very defect the test's
own header cites as the reason the shape exists. Its dist/index.css was
guarded by the four write-time assertions inside the shared builder, which run
only during a build; CI runs this suite on an unbuilt worktree, so nothing in
the test run inspected it.

This adds fields as a third subject. The suite goes from 14 tests to 20
(three subjects times six per-package assertions, plus two standalone).

Premise re-verified on the merged ref

Re-read on main = e33b44796, item for item, rather than inherited:
packages/fields/scripts/build-css.mjs (notbuild-stylesheet.mjs) imports
createPluginStylesheetBuilder at line 94 and exports PACKAGE_ROOT / PACKAGE_NAME
(96/97), MUST_SURVIVE / CLASS_CEILING (114/132), builder / buildOptions
(161/163) behind the isEntrypoint guard (171) — the same shape the two plugins
export. SUBJECTS was at test line 91.

How the CARD_THEMED entry was derived

Independently, from the sheet the build actually emits — not read back off
fields' own MUST_SURVIVE, which would have looked identical while pinning
nothing.

Method: build fields' sheet through the shared builder, then keep every
surviving class whose own declarations resolve a --color-* token declared in
packages/components/src/index.css's @theme block (35 tokens) — the file that
package does not publish, which is exactly what makes an in-monorepo build the
only possible producer of these utilities.

That yields 17 surviving themed classes out of 163 surviving total. Two
independent corroborations:

• packages/fields/scripts/build-css.mjs records, from @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059, that "17 of those
  depend on the ObjectUI @theme block" — the same count, reached by a
  different method.
• The three utilities @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059 names (bg-primary/20, hover:bg-accent/30,
  ring-destructive/50) are 3 of the 17, confirming they were the starting
  corpus and not the answer. The other 14 are ones a literal-grep method could
  not see.

Only 3 of the 17 appear in MUST_SURVIVE, so the list is demonstrably not that
list read back.

Banner: taken from buildOptions, and why nothing changed

fields passes a per-package header (HEADER, line 147, into buildOptions at
line 168); plugin-grid's buildOptions has no header key and inherits the
shared defaultHeader. The emitted sheet is header plus the sheet, so any
assertion reading the banner from the shared default would judge fields wrongly.

Surveyed before writing: no assertion in the suite reads the emitted banner,
so the caveat is preventive here, not corrective. The one assertion that
inspects the whole css string — "carries utilities only" — was checked against
fields' actual HEADER bytes and none of its three patterns can match it. The
module header now records the rule for anything added later. A banner pin is
not added here, for a reason recorded as a follow-up below.

Proof the new assertions have teeth

"The suite is green after I added it" is not evidence — a green assertion that
inspects nothing is precisely the defect this card records. Two ablations, each
proving the mutation reached disk before measuring, and each proving the restore
by blob hash rather than by exit code:

1. A themed utility stops being produced.hover:bg-primary/10 is in the
derived list and deliberately not in MUST_SURVIVE, so the builder's
write-time throw does not fire and mask the result. Its single usage site in
RecordPickerDialog.tsx was retargeted to hover:bg-primary/15.

• on disk: occurrences of the removed text 1 to 0, injected text 0 to 1; blob moved 1e9d341d to 3e0a4915
• result: Tests 1 failed | 19 passed, the failure being
  fields > emits the themed utilities only this build can produce with
  AssertionError: expected [ 'hover:bg-primary/10' ] to deeply equal []
• restore: blob back to 1e9d341d, git diff HEAD empty

2. The manifest declaration breaks. fields' exports['./style.css'] was
pointed at ./dist/nope.css, which also proves the subject name resolves to
packages/fields.

• on disk: injected 1, original pair 0; blob moved 5e442f18 to 98eeea6f
• result: Tests 1 failed | 19 passed, the failure being
  fields > declares the export AND the step that produces it
• restore: blob back to 5e442f18, git diff HEAD empty

In both runs exactly one assertion went red and it was a fields one, with
plugin-grid and plugin-kanban still green — so the red is subject-specific,
not a global break.

The finding that justifies the per-package coverage

Under ablation 1 the union assertion, "gives every themed utility the card
measured a producer", stayed green. Measured cause: plugin-grid also emits
hover:bg-primary/10, so the union was satisfied by another subject while
fields' own sheet had genuinely regressed. Adding fields to SUBJECTS is what
buys the coverage; adding it only to CARD_THEMED would have reproduced the
defect this card records.

Verification

Union run on the final commit, git rev-parse --short HEAD = 1219b8d88, tree clean:

• npx vitest run scripts/__tests__/plugin-published-stylesheet.test.ts --maxWorkers=2 — Tests 20 passed (20), exit 0
• pnpm type-check:scripts — exit 0. Load-bearing: the shared builder's own comment records that this reads the options types through this test file, and fields is the first subject to pass header.
• pnpm type-check:coverage — 45/46 via type-check, 41/41 packages compile their tests
• pnpm check:control-bytes — OK (scanned 5850 tracked text file(s))
• pnpm changeset:check — no major, fixed group OK
• node scripts/check-changeset-presence.mjs — "no changeset is owed"; the changeset is an explicit no-release declaration in the empty-frontmatter shape this repo uses for test-only changes
• eslint on the changed file — 0 errors, 0 warnings

Lint was narrowed to the changed file rather than run farm-wide, and the
narrowing is measured, not assumed: the file count comes from eslint's own
--format json output (1 file), and type-aware linting is not enabled in
eslint.config.js (no projectService, project: or parserOptions;
control term rules hits 10 times in the same file, so the query was live), so
this diff cannot move the verdict on any untouched file. CI runs the full farm
regardless.

Follow-up, filed not ridden along

The emitted banner is pinned by nothing, and it cannot be pinned cleanly today:
the shared builder does not export its defaultHeader, so an assertion covering
all three subjects would need a tolerant fallback in the test for the two
packages that declare no header — the consumer-side leniency this repo's
contract-first rule says to fix at the producer instead. That is a
producer-side change with its own review, so it is recorded rather than ridden
along here.

---

Generated by Claude Code

[zhuangjianguo]

Fixes#6438

scripts/__tests__/plugin-published-stylesheet.test.ts ran its per-package
assertions over exactly two subjects, plugin-grid and plugin-kanban.
@object-ui/fields was not one of them — and it is the package whose stylesheet
has actually been shipping to consumers since #4059, the very defect the test's
own header cites as the reason the shape exists. Its dist/index.css was
guarded by the four write-time assertions inside the shared builder, which run
only during a build; CI runs this suite on an unbuilt worktree, so nothing in
the test run inspected it.

This adds fields as a third subject. The suite goes from 14 tests to 20
(three subjects times six per-package assertions, plus two standalone).

Premise re-verified on the merged ref

Re-read on main = e33b44796, item for item, rather than inherited:
packages/fields/scripts/build-css.mjs (notbuild-stylesheet.mjs) imports
createPluginStylesheetBuilder at line 94 and exports PACKAGE_ROOT / PACKAGE_NAME
(96/97), MUST_SURVIVE / CLASS_CEILING (114/132), builder / buildOptions
(161/163) behind the isEntrypoint guard (171) — the same shape the two plugins
export. SUBJECTS was at test line 91.

How the CARD_THEMED entry was derived

Independently, from the sheet the build actually emits — not read back off
fields' own MUST_SURVIVE, which would have looked identical while pinning
nothing.

Method: build fields' sheet through the shared builder, then keep every
surviving class whose own declarations resolve a --color-* token declared in
packages/components/src/index.css's @theme block (35 tokens) — the file that
package does not publish, which is exactly what makes an in-monorepo build the
only possible producer of these utilities.

That yields 17 surviving themed classes out of 163 surviving total. Two
independent corroborations:

• packages/fields/scripts/build-css.mjs records, from @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059, that "17 of those
  depend on the ObjectUI @theme block" — the same count, reached by a
  different method.
• The three utilities @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059 names (bg-primary/20, hover:bg-accent/30,
  ring-destructive/50) are 3 of the 17, confirming they were the starting
  corpus and not the answer. The other 14 are ones a literal-grep method could
  not see.

Only 3 of the 17 appear in MUST_SURVIVE, so the list is demonstrably not that
list read back.

Banner: taken from buildOptions, and why nothing changed

fields passes a per-package header (HEADER, line 147, into buildOptions at
line 168); plugin-grid's buildOptions has no header key and inherits the
shared defaultHeader. The emitted sheet is header plus the sheet, so any
assertion reading the banner from the shared default would judge fields wrongly.

Surveyed before writing: no assertion in the suite reads the emitted banner,
so the caveat is preventive here, not corrective. The one assertion that
inspects the whole css string — "carries utilities only" — was checked against
fields' actual HEADER bytes and none of its three patterns can match it. The
module header now records the rule for anything added later. A banner pin is
not added here, for a reason recorded as a follow-up below.

Proof the new assertions have teeth

"The suite is green after I added it" is not evidence — a green assertion that
inspects nothing is precisely the defect this card records. Two ablations, each
proving the mutation reached disk before measuring, and each proving the restore
by blob hash rather than by exit code:

1. A themed utility stops being produced.hover:bg-primary/10 is in the
derived list and deliberately not in MUST_SURVIVE, so the builder's
write-time throw does not fire and mask the result. Its single usage site in
RecordPickerDialog.tsx was retargeted to hover:bg-primary/15.

• on disk: occurrences of the removed text 1 to 0, injected text 0 to 1; blob moved 1e9d341d to 3e0a4915
• result: Tests 1 failed | 19 passed, the failure being
  fields > emits the themed utilities only this build can produce with
  AssertionError: expected [ 'hover:bg-primary/10' ] to deeply equal []
• restore: blob back to 1e9d341d, git diff HEAD empty

2. The manifest declaration breaks. fields' exports['./style.css'] was
pointed at ./dist/nope.css, which also proves the subject name resolves to
packages/fields.

• on disk: injected 1, original pair 0; blob moved 5e442f18 to 98eeea6f
• result: Tests 1 failed | 19 passed, the failure being
  fields > declares the export AND the step that produces it
• restore: blob back to 5e442f18, git diff HEAD empty

In both runs exactly one assertion went red and it was a fields one, with
plugin-grid and plugin-kanban still green — so the red is subject-specific,
not a global break.

The finding that justifies the per-package coverage

Under ablation 1 the union assertion, "gives every themed utility the card
measured a producer", stayed green. Measured cause: plugin-grid also emits
hover:bg-primary/10, so the union was satisfied by another subject while
fields' own sheet had genuinely regressed. Adding fields to SUBJECTS is what
buys the coverage; adding it only to CARD_THEMED would have reproduced the
defect this card records.

Verification

Union run on the final commit, git rev-parse --short HEAD = 1219b8d88, tree clean:

• npx vitest run scripts/__tests__/plugin-published-stylesheet.test.ts --maxWorkers=2 — Tests 20 passed (20), exit 0
• pnpm type-check:scripts — exit 0. Load-bearing: the shared builder's own comment records that this reads the options types through this test file, and fields is the first subject to pass header.
• pnpm type-check:coverage — 45/46 via type-check, 41/41 packages compile their tests
• pnpm check:control-bytes — OK (scanned 5850 tracked text file(s))
• pnpm changeset:check — no major, fixed group OK
• node scripts/check-changeset-presence.mjs — "no changeset is owed"; the changeset is an explicit no-release declaration in the empty-frontmatter shape this repo uses for test-only changes
• eslint on the changed file — 0 errors, 0 warnings

Lint was narrowed to the changed file rather than run farm-wide, and the
narrowing is measured, not assumed: the file count comes from eslint's own
--format json output (1 file), and type-aware linting is not enabled in
eslint.config.js (no projectService, project: or parserOptions;
control term rules hits 10 times in the same file, so the query was live), so
this diff cannot move the verdict on any untouched file. CI runs the full farm
regardless.

Follow-up, filed not ridden along

The emitted banner is pinned by nothing, and it cannot be pinned cleanly today:
the shared builder does not export its defaultHeader, so an assertion covering
all three subjects would need a tolerant fallback in the test for the two
packages that declare no header — the consumer-side leniency this repo's
contract-first rule says to fix at the producer instead. That is a
producer-side change with its own review, so it is recorded rather than ridden
along here.

---

Generated by Claude Code

[zhuangjianguo]

Fixes#6438

scripts/__tests__/plugin-published-stylesheet.test.ts ran its per-package
assertions over exactly two subjects, plugin-grid and plugin-kanban.
@object-ui/fields was not one of them — and it is the package whose stylesheet
has actually been shipping to consumers since #4059, the very defect the test's
own header cites as the reason the shape exists. Its dist/index.css was
guarded by the four write-time assertions inside the shared builder, which run
only during a build; CI runs this suite on an unbuilt worktree, so nothing in
the test run inspected it.

This adds fields as a third subject. The suite goes from 14 tests to 20
(three subjects times six per-package assertions, plus two standalone).

Premise re-verified on the merged ref

Re-read on main = e33b44796, item for item, rather than inherited:
packages/fields/scripts/build-css.mjs (notbuild-stylesheet.mjs) imports
createPluginStylesheetBuilder at line 94 and exports PACKAGE_ROOT / PACKAGE_NAME
(96/97), MUST_SURVIVE / CLASS_CEILING (114/132), builder / buildOptions
(161/163) behind the isEntrypoint guard (171) — the same shape the two plugins
export. SUBJECTS was at test line 91.

How the CARD_THEMED entry was derived

Independently, from the sheet the build actually emits — not read back off
fields' own MUST_SURVIVE, which would have looked identical while pinning
nothing.

Method: build fields' sheet through the shared builder, then keep every
surviving class whose own declarations resolve a --color-* token declared in
packages/components/src/index.css's @theme block (35 tokens) — the file that
package does not publish, which is exactly what makes an in-monorepo build the
only possible producer of these utilities.

That yields 17 surviving themed classes out of 163 surviving total. Two
independent corroborations:

• packages/fields/scripts/build-css.mjs records, from @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059, that "17 of those
  depend on the ObjectUI @theme block" — the same count, reached by a
  different method.
• The three utilities @object-ui/fields declares a ./style.css export but nothing builds dist/index.css for it — the subpath quick-start teaches looks unresolvable #4059 names (bg-primary/20, hover:bg-accent/30,
  ring-destructive/50) are 3 of the 17, confirming they were the starting
  corpus and not the answer. The other 14 are ones a literal-grep method could
  not see.

Only 3 of the 17 appear in MUST_SURVIVE, so the list is demonstrably not that
list read back.

Banner: taken from buildOptions, and why nothing changed

fields passes a per-package header (HEADER, line 147, into buildOptions at
line 168); plugin-grid's buildOptions has no header key and inherits the
shared defaultHeader. The emitted sheet is header plus the sheet, so any
assertion reading the banner from the shared default would judge fields wrongly.

Surveyed before writing: no assertion in the suite reads the emitted banner,
so the caveat is preventive here, not corrective. The one assertion that
inspects the whole css string — "carries utilities only" — was checked against
fields' actual HEADER bytes and none of its three patterns can match it. The
module header now records the rule for anything added later. A banner pin is
not added here, for a reason recorded as a follow-up below.

Proof the new assertions have teeth

"The suite is green after I added it" is not evidence — a green assertion that
inspects nothing is precisely the defect this card records. Two ablations, each
proving the mutation reached disk before measuring, and each proving the restore
by blob hash rather than by exit code:

1. A themed utility stops being produced.hover:bg-primary/10 is in the
derived list and deliberately not in MUST_SURVIVE, so the builder's
write-time throw does not fire and mask the result. Its single usage site in
RecordPickerDialog.tsx was retargeted to hover:bg-primary/15.

• on disk: occurrences of the removed text 1 to 0, injected text 0 to 1; blob moved 1e9d341d to 3e0a4915
• result: Tests 1 failed | 19 passed, the failure being
  fields > emits the themed utilities only this build can produce with
  AssertionError: expected [ 'hover:bg-primary/10' ] to deeply equal []
• restore: blob back to 1e9d341d, git diff HEAD empty

2. The manifest declaration breaks. fields' exports['./style.css'] was
pointed at ./dist/nope.css, which also proves the subject name resolves to
packages/fields.

• on disk: injected 1, original pair 0; blob moved 5e442f18 to 98eeea6f
• result: Tests 1 failed | 19 passed, the failure being
  fields > declares the export AND the step that produces it
• restore: blob back to 5e442f18, git diff HEAD empty

In both runs exactly one assertion went red and it was a fields one, with
plugin-grid and plugin-kanban still green — so the red is subject-specific,
not a global break.

The finding that justifies the per-package coverage

Under ablation 1 the union assertion, "gives every themed utility the card
measured a producer", stayed green. Measured cause: plugin-grid also emits
hover:bg-primary/10, so the union was satisfied by another subject while
fields' own sheet had genuinely regressed. Adding fields to SUBJECTS is what
buys the coverage; adding it only to CARD_THEMED would have reproduced the
defect this card records.

Verification

Union run on the final commit, git rev-parse --short HEAD = 1219b8d88, tree clean:

• npx vitest run scripts/__tests__/plugin-published-stylesheet.test.ts --maxWorkers=2 — Tests 20 passed (20), exit 0
• pnpm type-check:scripts — exit 0. Load-bearing: the shared builder's own comment records that this reads the options types through this test file, and fields is the first subject to pass header.
• pnpm type-check:coverage — 45/46 via type-check, 41/41 packages compile their tests
• pnpm check:control-bytes — OK (scanned 5850 tracked text file(s))
• pnpm changeset:check — no major, fixed group OK
• node scripts/check-changeset-presence.mjs — "no changeset is owed"; the changeset is an explicit no-release declaration in the empty-frontmatter shape this repo uses for test-only changes
• eslint on the changed file — 0 errors, 0 warnings

Lint was narrowed to the changed file rather than run farm-wide, and the
narrowing is measured, not assumed: the file count comes from eslint's own
--format json output (1 file), and type-aware linting is not enabled in
eslint.config.js (no projectService, project: or parserOptions;
control term rules hits 10 times in the same file, so the query was live), so
this diff cannot move the verdict on any untouched file. CI runs the full farm
regardless.

Follow-up, filed not ridden along

The emitted banner is pinned by nothing, and it cannot be pinned cleanly today:
the shared builder does not export its defaultHeader, so an assertion covering
all three subjects would need a tolerant fallback in the test for the two
packages that declare no header — the consumer-side leniency this repo's
contract-first rule says to fix at the producer instead. That is a
producer-side change with its own review, so it is recorded rather than ridden
along here.

---

Generated by Claude Code