fix(schema-catalog): spell filter-builder operators the way the mirror declares them

[os-sam]

Fixes #6939

Seven "operator" spellings in three schema-catalog fixtures move from the spec's alias
table (eq / lt / gt) to the members FilterOperatorSchema actually declares
(equals / less_than / greater_than), so the entries pass safeValidateSchema.

Contract-first, per the maintainer's standing principle: the protocol declares the
snake_case vocabulary, so the corpus was the side that was wrong. No enum member was
added, and a pin now says so mechanically.

This is the last remaining row of objectui#6939. The other seven component groups landed
and are closed already; nothing in them is touched here.

Repair round 2 — what moved, and one finding that did not reproduce

An isolated contract review returned FAIL on this pin — not on the change it guards.
Every finding was reproduced here before it was repaired, and the one that disagreed with
the report is recorded as such rather than quietly "fixed".

• Blocking — the PRESERVED identity legs could not tell the two corpora apart under
  the alias mutation. Reproduced with a throwaway probe, repaired with the guard its
  NEW-direction twin already carried, re-measured in Reverse verification below.
• The invented-operator payload no longer spends a repo-wide-looking absent token; see
  the zero-controls note under Readings.
• The corpus figure now describes this head (501) instead of the base (500).
• ⚠️ Did not reproduce: the report is that this body carried a clause-② clearance
  sentence sourced from a bare check-clause2-carriers run. Measured against the body as
  it stood at head 3bcecc4095, fetched back from the API before this revision was
  written, with grep -o … | wc -l: 0 occurrences of the checker's name, 0 of the
  word clearance, 0 of PM_SWEEP_REPO, 0 of scripts/pm — against 1
  occurrence each of three firing controls on the same instrument and the same bytes
  (Clause-②, Implemented-by, and the card-closing line at the top). ⚠️ Those zeros
  describe that revision and ⛔ not the text you are reading: this paragraph now contains
  two of the strings it counted, which is exactly why it names the bytes it was taken over
  rather than leaving the count to read as live. There was no such sentence to delete, and
  none was added. The Clause-②: no declaration at the end is the only clause-② text
  this body has ever carried; taking that gate is the seat's reading, not this branch's,
  and this body does not claim it.
• Base merge (⛔ merge, never rebase, ⛔ never force-push): origin/main merged in
  twice — first the three commits objectui#9541, objectui#9548 and objectui#9551, then
  objectui#9552 when it landed mid-round. Each time the intersection with this branch's nine
  files is 0 paths, measured. Every figure below was re-taken on the final merged tree,
  not carried forward; the two that move are named where they appear.

Readings (mine, re-measured — base b7479abc74, head 5c08bc8966 after merging origin/main)

Corpus for every count below, re-measured at this head: 501 tracked files under
examples/, 443 of them .json. ⚠️ The 500 this body carried before was the
base figure — this branch's own new pin file is the 501st, so that sentence described a
tree this pull request does not ask anyone to land. The .json subset is what every count
in the table is drawn from and it does not move: 443 at the base and 443 at this head,
checked rather than assumed. Occurrences counted with git grep -o … | wc -l, files with
git grep -l … | wc -l.

reading	before	after
"operator": occurrences anywhere under examples/	7	7
of those, in the refused dialect (eq/lt/gt)	7	0
of those, in the declared vocabulary	0	7
files carrying them	3	3

Per file, both states: product-search.json 3, search-interface.json 2,
with-conditions.json 2. Values before: eq x3, gt x3, lt x1. After: equals x3,
greater_than x3, less_than x1. The diff is 7 insertions / 7 deletions across exactly
those three data files.

⭐ The control that makes the first row load-bearing: every "operator": occurrence
anywhere under examples/ is also 7, so coverage of the refused dialect was 100 %, not
"a few exceptions".

Zero-controls, same corpus, same run: the same-subject known-hit control "conditions":
returns 5, so the zero above is a reading rather than a silent miss.

⛔ This branch lands no repo-wide-looking absent-token literal, and that is deliberate.
A generic absent token is clean only while nothing in the tree contains it, so consuming
one as a test literal spends it for everyone afterwards. An earlier revision of the new pin
used one as its invented-operator payload: measured repo-wide, that token went from 0
occurrences / 0 files at the base and on origin/main to 3 occurrences / 1 file at
the old head — spent exactly the way zzqx_no_such_key already is here (6 occurrences /
3 files, which is why that one was not used either). The payload is now
filter_builder_6939_invented_operator, which names this card and this component so that
nobody reaches for it as a repo-wide control. Its occurrence count before it was
written, taken with the same instrument over the whole tree: 0 occurrences / 0 files at
the base, at the old head and on origin/main; the firing control for that zero, same
instrument and same corpus, is FilterOperatorSchema at 24 occurrences / 15 files. The
pin also asserts at runtime that the payload is not a member of FilterOperatorSchema, so
that refusal leg cannot go green on a payload the mirror happens to accept.

Vocabulary, read at runtime from the built dist rather than restated:
FilterOperatorSchema has 14 members and contains 0 of 3 of eq / lt / gt.

Acceptance notes

The two directions pull opposite ways and each is measured separately. ⚠️ objectui#6318's
rule — a "correction" that renders identically proves the edit was wrong — was written
where the correction repaired a broken render. Here it inverts: objectui#7561 (PR
#9305) had already routed the operator trigger's identity comparison through
normalizeFilterOperator, so all three dialects already drew their label. The aliases
were validation-broken, not render-broken ⇒ a render that moves is this change's
failure signal.

Direction NEW — it validates (the property added)

The card's own instrument, node packages/cli/dist/cli.js check, run from the repo root
over the same tree in both states, and re-taken on the merged tree (632 files analyzed each
time, unchanged by the merge; the alias state produced by reverting only the three data
files in place). ⚠️ The instrument prints ✓ All checks passed and exits 0 in both
states — only the bucket listing discriminates, so the listing is what is read here:

• before — 3 files in the "carries a registered ObjectUI component type but did not
  validate" bucket: with-conditions.json (type filter-builder),
  product-search.json (type filter-builder), and one unrelated
  packages/vscode-extension/schemas/objectui-schema.json (type object).
• after — 1 file: only the unrelated vscode-extension one.

search-interface.json roots at stack, so check validates its root and never counted
it; its nested filter-builder node is measured directly in the new pin so the fifth file
is not silently unexamined.

Pinned per entry in examples/schema-catalog/test/filter-builder-operator-vocabulary-6939.test.tsx,
with three refusal controls so .success cannot be satisfied by a mirror that accepts
everything:

• the alias dialect each entry used to author is still refused — this is the assertion
  that would go green if someone ever repaired a red here by widening the enum;
• the dropdown's own camelCase dialect is still refused (see the open half below);
• an invented operator is refused.

Direction PRESERVED — it renders the same (the property protected)

The "before" arm is reconstructed in memory from the same tree by swapping only the
operator spellings back, so the proof keeps working in a checkout that never saw the old
bytes. Per entry, four readings must be equal between the arms: full textContent,
element count, the type attribute of every input, and the text of every operator
trigger. All three entries: equal. Operator trigger labels, unchanged in both states —
product-search Equals / Less than / Greater than, search-interface Equals /
Greater than, with-conditions Greater than / Equals — and not one blank cell.

Anti-vacuity for that equality needs two guards, and ⚠️ the second one was missing
until repair round 2. The first: a leg that swaps in a genuinely different operator must
move the render, and it does. The second: the alias arm of the identity leg must itself
have moved. withOperators falls through on a key it does not hold, and FORMER_ALIAS
is keyed on the DECLARED spellings — so against a corpus authored in the alias dialect the
arm degenerates to an identity transform, and the leg renders the same document twice and
asserts it equals itself.

Reproduced before it was repaired, with a throwaway probe built from the pin's own helpers
that asserts only that the two arms differ: 3 passed unmutated / 3 failed under the alias
mutation, the failures reading
expected [ 'eq', 'lt', 'gt' ] to not deeply equal [ 'eq', 'lt', 'gt' ]. The probe was
deleted; the tree is clean. Both identity legs now carry the per-row swap guard that the
NEW-direction twin in the same file already had — the one on the leg named the alias
dialect it used to author is still REFUSED — and so does the invented-operator leg, which
had the identical hole.

⭐ The same failure class had already been repaired once inside this pin, on the leg that
proves the identity assertions CAN fail: it keyed its swap table on the canonical spellings
this branch landed, so it went quiet the moment the corpus was re-authored in another
dialect. That leg now derives its table from whatever the entry currently spells. Both
repairs are the same lesson — a swap table keyed on one dialect is a silent no-op against
any other — and this card exists because of exactly that class.

Reverse verification

Mutation: revert only the three data files to the alias dialect. Prediction written down
before each run. Landing proven on disk in both directions (canonical anchors 3/2/2 to
0/0/0, alias anchors 0/0/0 to 3/2/2) and by blob hash against HEAD for all three files;
the harness aborts with a void reading unless the totals are 0 canonical / 7 alias, carries
trap … EXIT INT TERM with an absolute repo root, and restores with
git checkout HEAD -- path against an absolute path.

Before the repair, under the mutation: NEW reddened at 21 failed | 60 passed, while
PRESERVED scoped with -t PRESERVED stayed 7 passed | 14 skipped. That green is
withdrawn: three of those seven were the identity legs comparing the alias corpus with
itself.

After the repair, same mutation, same harness:

• both directions redden: Tests 25 failed | 56 passed (81) across the three pin
  files. The four reds beyond the pre-repair 21 are the three identity legs — each failing
  with expected 'eq' not to be 'eq', the same shape the NEW-direction twin fails with —
  and the invented-operator leg failing on its own new swap guard.
• PRESERVED, scoped: Tests 3 failed | 4 passed | 14 skipped (21), verbose reporter,
  every name printed. The three no operator cell is blank legs stay green on purpose:
  they measure the authored corpus only, so under the mutation they are a genuine reading
  about the alias corpus rather than a vacuous one. The identity legs can fail leg stays
  green for the same reason — its table is derived, not keyed.
• unmutated, at this head: Test Files 3 passed (3) / Tests 81 passed (81).

⇒ The property the PRESERVED direction claims is proven where it is true — at this head,
unmutated, where the two arms demonstrably differ — and the pin now fails loudly on a
migration back to the alias dialect instead of going quiet. ⛔ The earlier claim that
PRESERVED "stays green" under the mutation is not restated: nothing in that run was
comparing the alias corpus to the repaired one.

Restore proven by state, not by exit code, after every leg: git status --porcelain
empty, git diff HEAD empty, and git hash-object on each of the three files equal to its
HEAD blob.

Two existing pins recorded the old corpus state

Both are re-aimed, not deleted, so each still names the key that moved:

• examples/schema-catalog/test/filter-builder-operator-alias-trigger-7561.test.tsx held a
  fence asserting the catalog still authors the alias table. That fence belonged to
  objectui#7561's narrower scope — it deliberately changed no catalog data — and this
  card's remainder is what lifts it. The assertion is inverted: the entries must now
  author a declared member, and a migration back to either off-contract dialect reddens
  it. Its correction table also had to grow the canonical spellings, or the control arm
  would silently have become an identity compare. ⚠️ The two vocabularies overlap on three
  members (equals, contains, in are spelled alike), so the old form of its
  anti-vacuity leg — "no member of one appears in the other" — is not available and the
  new one asserts per row that every non-coinciding spelling actually moved.
• packages/types/src/__tests__/filter-builder-mirror-6939.test.ts pinned the residual
  refusal mechanically. Those rows now assert the entries validate, and the enum-not-widened
  claim is carried by a new refusal control rather than by the residual.

Two comments in files this branch touches stated the old corpus as fact and were repaired
in place (objectui#7853's citation discipline); one cross-file line address in the types
pin was dropped for a content citation while that paragraph was being rewritten.

⛔ The bigger half, named and left alone

The builder's dropdown emits its own camelCase ids, and the mirror refuses them: read
at runtime from the built dist, FILTER_BUILDER_OPERATORS has 22 members, of which
3 (equals, contains, in) are accepted by FilterOperatorSchema and 19 are
refused — notEquals, containsCaseInsensitive, notContains, isEmpty, isNotEmpty,
greaterThan, lessThan, greaterOrEqual, lessOrEqual, before, after, between,
notIn, startsWith, endsWith, isNull, isNotNull, exists, notExists.

⇒ a filter a user edits in the UI and stores is refused by the mirror exactly as these
fixtures were. No card owns that today. It is pinned here as a refusal so it cannot go
quiet, and ⛔ it is not ruled or repaired here. objectui#7561 is not addressed by this pull
request either — its deliverable already landed.

⛔ plugin-kanban's KanbanColumn / KanbanCard / KanbanSchema untouched: that
conflict is with the maintainer.

Verification

Exit codes captured before any pipe; every figure read from the instrument's own verdict
line. Heavy runs serialized through ../objectstack's shared verify lock
(OS_VERIFY_LOCK_SLOT=objectui-6939-dev), all VERDICT command-exit 0.

• pnpm exec vitest run --maxWorkers=2 examples/schema-catalog/ packages/types/ — the two
  affected packages in full: Test Files 223 passed (223) / Tests 6702 passed (6702).
  ⚠️ Re-quoted on the merged tree: this row read 6665 before the base merge, which
  modifies 4 packages/types/src/__tests__ files and adds none, so the file count is
  unchanged and the test count is not. Re-taken again after the second merge: both figures
  are the same on the final head.
• pnpm exec vitest run --maxWorkers=2 packages/components/src/__tests__/filter-builder*.test.tsx
  — Test Files 12 passed (12) / Tests 254 passed (254).
• turbo run build then turbo run type-check for @object-ui/types,
  @object-ui/components, @object-ui/example-schema-catalog with --concurrency=2 —
  29 and 32 tasks successful, zero error TS. ⚠️ Build first is load-bearing: without the
  dependency closure built, type-check reports TS2307 Cannot find module and says
  nothing about this diff.
• turbo run lint for the same three plus lint:root — 4 tasks successful,
  0 errors (953 / 288 / 32 pre-existing warnings, none of them in the touched file;
  the types figure was 286 before the base merge).
• Gates, each redirect-then-read, all re-taken at this head after the merge:
  check:control-bytes OK over 7727 tracked text files (7719 before the merges), plus a
  manual grep -naP control-byte scan over the touched file returning no match — with a
  firing control on the same instrument, a synthetic line carrying one control byte, which
  matches; check:new-line-citations 0 new citation(s); check:test-path-roots OK;
  check-changeset-presence 9 file(s) changed … declares 1 changeset(s) and
  "Every one of them has an EMPTY frontmatter"; changeset:check (fixed-group and
  no-major) OK; check:changeset-claims OK; check:doc-example-ids
414 real reference(s) all resolve; check:vi-mock-specifiers, check:vi-mock-inherit,
  check:vi-mock-override-shape, check:comment-mask-corpus, check:unreferenced-sources
  all exit 0; regenerate:check index.ts is up to date (432 entries).
  ⚠️ Recorded because it reads like a red and is not one: pnpm run check:changeset-presence
  and check:changeset-no-major exit 1 with empty output — neither script name exists
  in this repo (ERR_PNPM_NO_SCRIPT). The real invocations are
  node scripts/check-changeset-presence.mjs and pnpm changeset:check, and those are the
  runs quoted above.
• node scripts/check-governed-queue-guard.mjs --test over this branch's nine paths:
  NOT GOVERNED.

Changeset: empty frontmatter, the gate's explicit "releases nothing" declaration. The two
files under a released package are test files whose only change is comments and
assertions; the data files live in a private, changeset-ignored example package.

Narrowings declared, one line each with what each could have caught:

1. Repo-wide pnpm lint replaced by the three affected packages' own lint plus
   lint:root — exactly what turbo run lint invokes for them. ESLint here is not
   type-aware, so this diff cannot move a verdict on a file it does not touch.
2. packages/components is type-checked and linted in full, but only its 12
   filter-builder* test files are run; the change there is a comment. A full-package run
   could have caught an unrelated regression, and CI runs it.
3. No other package's tests were run: the three data files are consumed through
   examples/schema-catalog/src/index.ts, whose only in-repo readers are that package's
   own tests and the docs site's example resolver (by id, unchanged). CI runs the full farm.

Clause-②: no — three data files move into an already-declared accepted set. No member
added, no published type or export moved.

Implemented-by: claude/issue-6939-filter-builder-catalog-operator-spellings

🤖 Generated with Claude Code

https://claude.ai/code/session_01L5xpA5q533BgTTNADibEFt

---

Generated by Claude Code

[github-actions]

✅ Console Performance Budget

Metric	Value	Budget
Eager closure (gzip, 329 chunks)	3063.0 KB	3104.5 KB
Main entry chunk (gzip)	145.7 KB	350 KB
Entry file	index-DzmHDIpZ.js	—
Status	PASS	—

The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it.

---

📦 Bundle Size Report

Package	Size	Gzipped
app-shell (consoleActionDispatch.js)	0.20KB	0.19KB
app-shell (index.js)	16.69KB	6.21KB
app-shell (runtime-config.js)	20.68KB	7.36KB
app-shell (types.js)	0.01KB	0.04KB
app-shell (urlParams.js)	10.06KB	3.86KB
auth (ActiveOrganizationStorage.js)	25.05KB	9.16KB
auth (AuthContext.js)	0.31KB	0.24KB
auth (AuthGuard.js)	2.07KB	1.00KB
auth (AuthProvider.js)	40.18KB	10.59KB
auth (AuthShell.js)	3.49KB	1.40KB
auth (ForgotPasswordForm.js)	12.21KB	3.45KB
auth (LoginForm.js)	18.15KB	5.39KB
auth (PreviewBanner.js)	0.90KB	0.50KB
auth (RegisterForm.js)	6.65KB	2.22KB
auth (SocialSignInButtons.js)	9.61KB	3.89KB
auth (UserMenu.js)	3.41KB	1.23KB
auth (auth-gate-events.js)	1.29KB	0.66KB
auth (authStyles.js)	5.04KB	1.72KB
auth (createAuthClient.js)	40.21KB	10.80KB
auth (createAuthenticatedFetch.js)	8.46KB	3.43KB
auth (index.js)	3.19KB	1.44KB
auth (invitation-status.js)	1.22KB	0.70KB
auth (org-roles.js)	6.66KB	2.78KB
auth (phone-identifier.js)	1.11KB	0.66KB
auth (types.js)	0.59KB	0.35KB
auth (useAuth.js)	5.30KB	1.02KB
auth (useWorkspaceAdminStatus.js)	11.08KB	4.58KB
collaboration (CommentThread.js)	26.08KB	7.56KB
collaboration (LiveCursors.js)	3.17KB	1.27KB
collaboration (PresenceAvatars.js)	6.49KB	2.64KB
collaboration (PresenceProvider.js)	2.79KB	1.13KB
collaboration (index.js)	1.68KB	0.73KB
collaboration (useCollaborationTranslation.js)	6.05KB	2.52KB
collaboration (useCommentSearch.js)	1.98KB	0.88KB
collaboration (useConflictResolution.js)	7.75KB	1.86KB
collaboration (useMentionNotifications.js)	1.81KB	0.68KB
collaboration (usePresence.js)	6.33KB	1.84KB
collaboration (useRealtimeSubscription.js)	7.91KB	2.01KB
components (index.js)	544.93KB	130.50KB
core (index.js)	8.52KB	3.41KB
create-plugin (index.js)	27.94KB	9.51KB
data-objectstack (index.js)	215.98KB	59.97KB
fields (index.js)	249.20KB	62.88KB
i18n (LocalizationContext.js)	1.76KB	0.96KB
i18n (builtinAggregateLabels.js)	0.86KB	0.49KB
i18n (currency.js)	1.22KB	0.64KB
i18n (fallbackInterpolation.js)	6.25KB	2.77KB
i18n (i18n.js)	8.87KB	3.64KB
i18n (index.js)	5.22KB	2.26KB
i18n (pickLocalized.js)	9.86KB	3.95KB
i18n (provider.js)	32.15KB	10.49KB
i18n (useDisplayLocale.js)	2.85KB	1.45KB
i18n (useObjectLabel.js)	34.34KB	9.17KB
i18n (useSafeTranslation.js)	5.60KB	2.33KB
layout (index.js)	38.83KB	10.95KB
mobile (MobileProvider.js)	0.92KB	0.49KB
mobile (ResponsiveContainer.js)	0.94KB	0.38KB
mobile (breakpoints.js)	1.51KB	0.70KB
mobile (createOfflineDataSource.js)	5.61KB	1.75KB
mobile (index.js)	1.99KB	0.87KB
mobile (offlineQueue.js)	3.91KB	1.35KB
mobile (pwa.js)	0.97KB	0.49KB
mobile (serviceWorker.js)	1.48KB	0.62KB
mobile (serviceWorkerSource.js)	3.41KB	1.48KB
mobile (useBreakpoint.js)	1.54KB	0.65KB
mobile (useGesture.js)	6.96KB	1.98KB
mobile (useOfflineSync.js)	1.99KB	0.72KB
mobile (usePullToRefresh.js)	2.53KB	0.85KB
mobile (useResponsive.js)	0.72KB	0.42KB
mobile (useSpecGesture.js)	4.39KB	1.66KB
mobile (useTouchTarget.js)	1.01KB	0.54KB
permissions (MePermissionsProvider.js)	13.52KB	4.88KB
permissions (PermissionContext.js)	0.31KB	0.25KB
permissions (PermissionGuard.js)	0.89KB	0.45KB
permissions (PermissionProvider.js)	6.24KB	2.16KB
permissions (discardProofCache.js)	1.04KB	0.55KB
permissions (evaluator.js)	8.39KB	3.10KB
permissions (index.js)	0.93KB	0.41KB
permissions (store.js)	0.91KB	0.42KB
permissions (useFieldPermissions.js)	1.28KB	0.53KB
permissions (usePermissions.js)	4.83KB	2.27KB
plugin-ai (index.js)	14.81KB	3.63KB
plugin-calendar (index.js)	49.99KB	14.24KB
plugin-charts (index.js)	71.33KB	19.90KB
plugin-chatbot (index.js)	195.34KB	46.51KB
plugin-dashboard (index.js)	131.44KB	34.65KB
plugin-designer (index.js)	215.94KB	44.33KB
plugin-detail (index.js)	252.48KB	65.61KB
plugin-editor (index.js)	2.23KB	1.05KB
plugin-form (index.js)	136.71KB	34.16KB
plugin-gantt (index.js)	167.62KB	41.26KB
plugin-grid (index.js)	212.83KB	57.97KB
plugin-kanban (index.js)	46.63KB	14.53KB
plugin-list (index.js)	112.67KB	27.68KB
plugin-map (index.js)	21.48KB	6.99KB
plugin-markdown (index.js)	13.88KB	4.80KB
plugin-report (index.js)	43.41KB	11.93KB
plugin-timeline (index.js)	30.07KB	8.74KB
plugin-tree (index.js)	10.58KB	3.72KB
plugin-view (index.js)	84.89KB	20.96KB
providers (DataSourceProvider.js)	0.75KB	0.39KB
providers (MetadataProvider.js)	1.37KB	0.59KB
providers (ThemeProvider.js)	1.90KB	0.85KB
providers (UploadProvider.js)	11.66KB	3.50KB
providers (index.js)	0.45KB	0.23KB
providers (types.js)	0.01KB	0.04KB
react-runtime (index.js)	5.62KB	2.34KB
react (LazyPluginLoader.js)	4.47KB	1.63KB
react (SchemaRenderer.js)	99.04KB	32.62KB
react (data-invalidation.js)	5.05KB	2.08KB
react (index.js)	4.63KB	2.18KB
react (schema-input.js)	4.25KB	2.04KB
react (spec-input.js)	0.20KB	0.18KB
sdui-parser (codegen.js)	6.58KB	2.74KB
sdui-parser (dashboard-widget-options.js)	3.08KB	1.30KB
sdui-parser (index.js)	5.66KB	2.50KB
sdui-parser (input-type.js)	2.84KB	1.40KB
sdui-parser (kanban-quick-add.js)	3.89KB	1.87KB
sdui-parser (parse.js)	25.28KB	7.80KB
sdui-parser (provenance.js)	3.66KB	1.82KB
sdui-parser (types.js)	0.28KB	0.23KB
sdui-parser (validate.js)	14.82KB	4.99KB
types (ai.js)	0.20KB	0.17KB
types (api-types.js)	0.20KB	0.18KB
types (app.js)	2.87KB	1.00KB
types (base.js)	0.20KB	0.18KB
types (blocks.js)	0.20KB	0.18KB
types (complex.js)	2.93KB	1.49KB
types (crud.js)	0.20KB	0.18KB
types (dashboard-filter-alias.js)	6.23KB	2.74KB
types (data-display.js)	3.75KB	1.85KB
types (data-protocol.js)	0.20KB	0.19KB
types (data.js)	0.20KB	0.18KB
types (designer.js)	1.85KB	0.85KB
types (disclosure.js)	0.20KB	0.18KB
types (error-code.js)	1.54KB	0.88KB
types (expression.js)	0.20KB	0.18KB
types (feedback.js)	0.20KB	0.18KB
types (field-types.js)	0.20KB	0.18KB
types (form.js)	0.20KB	0.18KB
types (http-inflight.js)	8.87KB	3.73KB
types (http-retry.js)	4.32KB	2.02KB
types (icon-key-migration.js)	4.26KB	1.63KB
types (index.js)	4.74KB	2.25KB
types (layout.js)	0.20KB	0.18KB
types (managed-by.js)	0.19KB	0.18KB
types (mobile.js)	4.73KB	2.28KB
types (navigation.js)	0.20KB	0.18KB
types (objectql.js)	0.20KB	0.18KB
types (overlay.js)	0.20KB	0.18KB
types (permissions.js)	0.20KB	0.18KB
types (plugin-scope.js)	0.20KB	0.18KB
types (record-components.js)	0.20KB	0.19KB
types (record-semantics.js)	1.28KB	0.67KB
types (registry.js)	0.20KB	0.18KB
types (reports.js)	0.20KB	0.18KB
types (select-option.js)	0.20KB	0.19KB
types (spec-report.js)	5.05KB	1.93KB
types (spec-ui-namespace.js)	0.20KB	0.19KB
types (strict-authoring-face.js)	14.04KB	5.36KB
types (system-fields.js)	3.33KB	1.54KB
types (theme.js)	6.28KB	2.87KB
types (ui-action.js)	8.11KB	3.32KB
types (views.js)	0.20KB	0.18KB
types (widget.js)	0.20KB	0.18KB

Size Limits

• ✅ Core packages should be < 50KB gzipped
• ✅ Component packages should be < 100KB gzipped
• ⚠️ Plugin packages should be < 150KB gzipped

[github-actions]

✅ Console Performance Budget

Metric	Value	Budget
Eager closure (gzip, 329 chunks)	3063.0 KB	3104.5 KB
Main entry chunk (gzip)	145.7 KB	350 KB
Entry file	index-DzmHDIpZ.js	—
Status	PASS	—

The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it.

---

📦 Bundle Size Report

Package	Size	Gzipped
app-shell (consoleActionDispatch.js)	0.20KB	0.19KB
app-shell (index.js)	16.69KB	6.21KB
app-shell (runtime-config.js)	20.68KB	7.36KB
app-shell (types.js)	0.01KB	0.04KB
app-shell (urlParams.js)	10.06KB	3.86KB
auth (ActiveOrganizationStorage.js)	25.05KB	9.16KB
auth (AuthContext.js)	0.31KB	0.24KB
auth (AuthGuard.js)	2.07KB	1.00KB
auth (AuthProvider.js)	40.18KB	10.59KB
auth (AuthShell.js)	3.49KB	1.40KB
auth (ForgotPasswordForm.js)	12.21KB	3.45KB
auth (LoginForm.js)	18.15KB	5.39KB
auth (PreviewBanner.js)	0.90KB	0.50KB
auth (RegisterForm.js)	6.65KB	2.22KB
auth (SocialSignInButtons.js)	9.61KB	3.89KB
auth (UserMenu.js)	3.41KB	1.23KB
auth (auth-gate-events.js)	1.29KB	0.66KB
auth (authStyles.js)	5.04KB	1.72KB
auth (createAuthClient.js)	40.21KB	10.80KB
auth (createAuthenticatedFetch.js)	8.46KB	3.43KB
auth (index.js)	3.19KB	1.44KB
auth (invitation-status.js)	1.22KB	0.70KB
auth (org-roles.js)	6.66KB	2.78KB
auth (phone-identifier.js)	1.11KB	0.66KB
auth (types.js)	0.59KB	0.35KB
auth (useAuth.js)	5.30KB	1.02KB
auth (useWorkspaceAdminStatus.js)	11.08KB	4.58KB
collaboration (CommentThread.js)	26.08KB	7.56KB
collaboration (LiveCursors.js)	3.17KB	1.27KB
collaboration (PresenceAvatars.js)	6.49KB	2.64KB
collaboration (PresenceProvider.js)	2.79KB	1.13KB
collaboration (index.js)	1.68KB	0.73KB
collaboration (useCollaborationTranslation.js)	6.05KB	2.52KB
collaboration (useCommentSearch.js)	1.98KB	0.88KB
collaboration (useConflictResolution.js)	7.75KB	1.86KB
collaboration (useMentionNotifications.js)	1.81KB	0.68KB
collaboration (usePresence.js)	6.33KB	1.84KB
collaboration (useRealtimeSubscription.js)	7.91KB	2.01KB
components (index.js)	544.93KB	130.50KB
core (index.js)	8.52KB	3.41KB
create-plugin (index.js)	27.94KB	9.51KB
data-objectstack (index.js)	215.98KB	59.97KB
fields (index.js)	249.20KB	62.88KB
i18n (LocalizationContext.js)	1.76KB	0.96KB
i18n (builtinAggregateLabels.js)	0.86KB	0.49KB
i18n (currency.js)	1.22KB	0.64KB
i18n (fallbackInterpolation.js)	6.25KB	2.77KB
i18n (i18n.js)	8.87KB	3.64KB
i18n (index.js)	5.22KB	2.26KB
i18n (pickLocalized.js)	9.86KB	3.95KB
i18n (provider.js)	32.15KB	10.49KB
i18n (useDisplayLocale.js)	2.85KB	1.45KB
i18n (useObjectLabel.js)	34.34KB	9.17KB
i18n (useSafeTranslation.js)	5.60KB	2.33KB
layout (index.js)	38.83KB	10.95KB
mobile (MobileProvider.js)	0.92KB	0.49KB
mobile (ResponsiveContainer.js)	0.94KB	0.38KB
mobile (breakpoints.js)	1.51KB	0.70KB
mobile (createOfflineDataSource.js)	5.61KB	1.75KB
mobile (index.js)	1.99KB	0.87KB
mobile (offlineQueue.js)	3.91KB	1.35KB
mobile (pwa.js)	0.97KB	0.49KB
mobile (serviceWorker.js)	1.48KB	0.62KB
mobile (serviceWorkerSource.js)	3.41KB	1.48KB
mobile (useBreakpoint.js)	1.54KB	0.65KB
mobile (useGesture.js)	6.96KB	1.98KB
mobile (useOfflineSync.js)	1.99KB	0.72KB
mobile (usePullToRefresh.js)	2.53KB	0.85KB
mobile (useResponsive.js)	0.72KB	0.42KB
mobile (useSpecGesture.js)	4.39KB	1.66KB
mobile (useTouchTarget.js)	1.01KB	0.54KB
permissions (MePermissionsProvider.js)	13.52KB	4.88KB
permissions (PermissionContext.js)	0.31KB	0.25KB
permissions (PermissionGuard.js)	0.89KB	0.45KB
permissions (PermissionProvider.js)	6.24KB	2.16KB
permissions (discardProofCache.js)	1.04KB	0.55KB
permissions (evaluator.js)	8.39KB	3.10KB
permissions (index.js)	0.93KB	0.41KB
permissions (store.js)	0.91KB	0.42KB
permissions (useFieldPermissions.js)	1.28KB	0.53KB
permissions (usePermissions.js)	4.83KB	2.27KB
plugin-ai (index.js)	14.81KB	3.63KB
plugin-calendar (index.js)	49.99KB	14.24KB
plugin-charts (index.js)	71.33KB	19.90KB
plugin-chatbot (index.js)	195.34KB	46.51KB
plugin-dashboard (index.js)	131.44KB	34.65KB
plugin-designer (index.js)	215.94KB	44.33KB
plugin-detail (index.js)	252.48KB	65.61KB
plugin-editor (index.js)	2.23KB	1.05KB
plugin-form (index.js)	136.71KB	34.16KB
plugin-gantt (index.js)	167.62KB	41.26KB
plugin-grid (index.js)	212.83KB	57.97KB
plugin-kanban (index.js)	46.63KB	14.53KB
plugin-list (index.js)	112.67KB	27.68KB
plugin-map (index.js)	21.48KB	6.99KB
plugin-markdown (index.js)	13.88KB	4.80KB
plugin-report (index.js)	43.41KB	11.93KB
plugin-timeline (index.js)	30.07KB	8.74KB
plugin-tree (index.js)	10.58KB	3.72KB
plugin-view (index.js)	84.89KB	20.96KB
providers (DataSourceProvider.js)	0.75KB	0.39KB
providers (MetadataProvider.js)	1.37KB	0.59KB
providers (ThemeProvider.js)	1.90KB	0.85KB
providers (UploadProvider.js)	11.66KB	3.50KB
providers (index.js)	0.45KB	0.23KB
providers (types.js)	0.01KB	0.04KB
react-runtime (index.js)	5.62KB	2.34KB
react (LazyPluginLoader.js)	4.47KB	1.63KB
react (SchemaRenderer.js)	99.04KB	32.62KB
react (data-invalidation.js)	5.05KB	2.08KB
react (index.js)	4.63KB	2.18KB
react (schema-input.js)	4.25KB	2.04KB
react (spec-input.js)	0.20KB	0.18KB
sdui-parser (codegen.js)	6.58KB	2.74KB
sdui-parser (dashboard-widget-options.js)	3.08KB	1.30KB
sdui-parser (index.js)	5.66KB	2.50KB
sdui-parser (input-type.js)	2.84KB	1.40KB
sdui-parser (kanban-quick-add.js)	3.89KB	1.87KB
sdui-parser (parse.js)	25.28KB	7.80KB
sdui-parser (provenance.js)	3.66KB	1.82KB
sdui-parser (types.js)	0.28KB	0.23KB
sdui-parser (validate.js)	14.82KB	4.99KB
types (ai.js)	0.20KB	0.17KB
types (api-types.js)	0.20KB	0.18KB
types (app.js)	2.87KB	1.00KB
types (base.js)	0.20KB	0.18KB
types (blocks.js)	0.20KB	0.18KB
types (complex.js)	2.93KB	1.49KB
types (crud.js)	0.20KB	0.18KB
types (dashboard-filter-alias.js)	6.23KB	2.74KB
types (data-display.js)	3.75KB	1.85KB
types (data-protocol.js)	0.20KB	0.19KB
types (data.js)	0.20KB	0.18KB
types (designer.js)	1.85KB	0.85KB
types (disclosure.js)	0.20KB	0.18KB
types (error-code.js)	1.54KB	0.88KB
types (expression.js)	0.20KB	0.18KB
types (feedback.js)	0.20KB	0.18KB
types (field-types.js)	0.20KB	0.18KB
types (form.js)	0.20KB	0.18KB
types (http-inflight.js)	8.87KB	3.73KB
types (http-retry.js)	4.32KB	2.02KB
types (icon-key-migration.js)	4.26KB	1.63KB
types (index.js)	4.74KB	2.25KB
types (layout.js)	0.20KB	0.18KB
types (managed-by.js)	0.19KB	0.18KB
types (mobile.js)	4.73KB	2.28KB
types (navigation.js)	0.20KB	0.18KB
types (objectql.js)	0.20KB	0.18KB
types (overlay.js)	0.20KB	0.18KB
types (permissions.js)	0.20KB	0.18KB
types (plugin-scope.js)	0.20KB	0.18KB
types (record-components.js)	0.20KB	0.19KB
types (record-semantics.js)	1.28KB	0.67KB
types (registry.js)	0.20KB	0.18KB
types (reports.js)	0.20KB	0.18KB
types (select-option.js)	0.20KB	0.19KB
types (spec-report.js)	5.05KB	1.93KB
types (spec-ui-namespace.js)	0.20KB	0.19KB
types (strict-authoring-face.js)	14.04KB	5.36KB
types (system-fields.js)	3.33KB	1.54KB
types (theme.js)	6.28KB	2.87KB
types (ui-action.js)	8.11KB	3.32KB
types (views.js)	0.20KB	0.18KB
types (widget.js)	0.20KB	0.18KB

Size Limits

• ✅ Core packages should be < 50KB gzipped
• ✅ Component packages should be < 100KB gzipped
• ⚠️ Plugin packages should be < 150KB gzipped

[claude]

Contract review

Verdict: FAIL — head judged 3bcecc4095abf5bf4c388a68f890c1318dabccdd (base merge-base b7479abc74100e022b5f1233fd14d4fabc891788).

Independent seat; nothing taken on trust. All eight claims re-measured in my own worktree at
3bcecc4095, worktree clean before and after every ablation. Seven of the eight reproduce exactly.
The eighth — the PRESERVED direction of the ablation, which this card names as its load-bearing
proof — reproduces numerically and is hollow: three of its seven green tests compare a tree
with itself under the mutation. That is the one failure mode this card exists to be about, and the
same commit that repaired it in the sibling leg left it standing in the leg that carries the
headline claim. Details in claim 5.

⭐ The code change itself is correct, and the property it claims is genuinely proven — just not by
the reading the PR body cites for it. The remedy is one line that already exists 30 lines above the
defect. See "What would turn this green".

---

Claim 1 — the data diff is 7/7 in 3 files; the enum untouched by blob identity · PASS

git diff --numstat b7479abc74 3bcecc4095 -- examples/schema-catalog/src/schemas/components-complex-filter-builder/

→ files=3 ins=7 del=7. Every changed line is a conditions[].operator value:
eq×3 → equals×3, gt×3 → greater_than×3, lt×1 → less_than×1. Nothing else moves in
those files.

Enum, by blob identity rather than diff emptiness:

git rev-parse b7479abc74:packages/types/src/zod/complex.zod.ts 3bcecc4095:… origin/main:…

→ 73bc7dc5cf0bc6d1f9bdc848f80a09b19233b7f8 at all three. packages/types/src/complex.ts likewise
identical (b9e15f920893…). ⛔ No enum member added.

Whole-diff surface: 9 files = 1 changeset + 3 data JSON + 5 test files. git diff --name-only
shows no non-test src file in any package, and examples/schema-catalog/src/index.ts is
untouched (pnpm --filter @object-ui/example-schema-catalog run regenerate:check → "index.ts is
up to date (432 entries)", exit 0). No published type or export moves.

Claim 2 — the counting · PASS on the figures, with two control defects

Corpus stated per number. git grep -o … | wc -l for occurrences, git grep -l … | wc -l for files.

reading (corpus: tracked files under examples/)	base b7479abc74	head 3bcecc4095
tracked files / of which .json	500 / 443	501 / 443
"operator": occurrences	7	7
"operator": "(eq|lt|gt)"	7	0
"operator": "(equals|less_than|greater_than)"	0	7
files carrying "operator":	3	3
same-subject control "conditions":	5 (fires)	5 (fires)
clean-absent-token control qqzz_absent_token_9999	0	3

Per file, both states: product-search 3 / search-interface 2 / with-conditions 2 — reproduced
by git grep -o '"operator":' <ref> -- <file> | wc -l. The alias→canonical figures are exact.

⚠️ Finding C2-a (medium) — this PR retires the lane's clean absent-token control by consuming it
as a test literal. Repo-wide: git grep -o 'qqzz_absent_token_9999' <ref> -- . gives 0
occurrences / 0 files at b7479abc74 and on origin/main, and 3 occurrences / 1 file at
3bcecc4095 — examples/schema-catalog/test/filter-builder-operator-vocabulary-6939.test.tsx:209-211,
where it is the invented-operator payload. The PR body publishes "the clean absent token
qqzz_absent_token_9999 returns 0 occurrences in 0 files" — true of the base, false of the head
this PR asks to land. After this lands the token is polluted exactly as zzqx_no_such_key already
is (6 occurrences / 3 files), and every future review that reaches for it gets a non-zero from a
token it believed absent. Use a fresh literal in the pin, or declare the token spent.

⚠️ Finding C2-b (low) — "Corpus for every count below: 500 tracked files under examples/" is
the base corpus. At the head it is 501: this PR's own new pin file is the 501st. The .json
subset (443) is unchanged, so no count in the table is affected; the corpus sentence is.

Claim 3 — FilterOperatorSchema read at runtime from the built dist · PASS

cd examples/schema-catalog && node --input-type=module -e "import('@object-ui/types/zod')…"

Resolved from packages/types/dist/zod/index.zod.js (printed by import.meta.resolve, so this is
the built artifact and not the source). → 14 members:
equals, not_equals, contains, not_contains, starts_with, ends_with, greater_than, greater_than_or_equal, less_than, less_than_or_equal, in, not_in, is_null, is_not_null.
['eq','lt','gt'].filter(a => opts.includes(a)).length → 0 of 3.

Claim 4 — the card's own instrument, paired · PASS, and the AFTER non-zero is that file and nothing else

node packages/cli/dist/cli.js check from the repo root, both states, mutation = revert only the
three data files in place (trap-protected harness, restore proven by blob hash).

• AFTER (3bcecc4095 as landed): Analyzing 632 files... → ⚠️ 1 file in the
  did-not-validate bucket, and the listing names exactly one:
  packages/vscode-extension/schemas/objectui-schema.json (type "object"). That path is not in the
  PR's 9 files (git diff --name-only … -- packages/vscode-extension/ → 0) and exists unchanged on
  origin/main. ⭐ No fourth thing is being tolerated: the bucket header count and the listed rows
  agree at 1.
• BEFORE (alias dialect): Analyzing 632 files... → 3 files: the same vscode-extension
  file, plus with-conditions.json and product-search.json, both (type "filter-builder").

search-interface.json roots at stack and is never counted by check — consistent with the
dev's note, and its nested node is measured directly in the new pin, so the fifth file is not left
unexamined.

⚠️ Instrument caveat worth recording: objectui check printed ✓ All checks passed and exited 0
in both states, including the 3-file one. The exit code does not discriminate here; only the
bucket listing does. The dev read the listing, which is the right reading.

Claim 5 — the two-direction ablation · (A) PASS · (B) FAIL

Mutation in both directions: revert only the three data files to the alias dialect. Landing proven
on disk before each run (canonical anchors 0 0 0, alias anchors 3 2 2), restore proven after by
git hash-object against HEAD for all three files plus an empty git status --porcelain.

(A) NEW REDDENS — reproduced exactly.

vitest run --maxWorkers=2 --reporter=verbose \
  examples/schema-catalog/test/filter-builder-operator-vocabulary-6939.test.tsx \
  examples/schema-catalog/test/filter-builder-operator-alias-trigger-7561.test.tsx \
  packages/types/src/__tests__/filter-builder-mirror-6939.test.ts

Unmutated: Test Files 3 passed (3) / Tests 81 passed (81). Under the mutation:
Tests 21 failed | 60 passed (81). I read all 21 names: 20 are validation-direction assertions
(validates as authored, every authored operator is a DECLARED member, the alias dialect … is still REFUSED, the dropdown's own … dialect is still REFUSED, the nested-node rows, the types-side
now validates too rows) and the 21st is the inverted fence
⛔ the catalog files author the DECLARED vocabulary…. Exactly as claimed. No PRESERVED test is
among the reds.

(B) PRESERVED STAYS GREEN — the figure reproduces, the proof does not. ⛔ This is the FAIL.

Figure first, so there is no dispute about it: same mutation, -t PRESERVED scoped to the
vocabulary pin → Tests 7 passed | 14 skipped (21), verbose, all seven named and run — all
three "as authored renders exactly as the alias arm did", all three "and no operator cell is
blank", and the repaired anti-vacuity leg. Nothing skipped that should have run.

Now what those three identity legs actually compared. The leg is
measure(asAuthored(id)) vs measure(withOperators(id, FORMER_ALIAS)), and
withOperators applies table[c.operator] ?? c.operator
(filter-builder-operator-vocabulary-6939.test.tsx:121). FORMER_ALIAS is keyed on the
canonical spellings — { equals: 'eq', greater_than: 'gt', less_than: 'lt' } (:71-75). Under
the mutation the entries already spell eq / gt / lt, so no key matches and every operator
falls through unchanged. The arm is an identity transform.

Measured, not inferred. I added a throwaway probe (since removed; tree clean) that reuses the pin's
own asAuthored, withOperators, operatorsOf and FORMER_ALIAS verbatim and asserts only
expect(asItWas).not.toEqual(authored):

• at 3bcecc4095 unmutated → Tests 3 passed (3) — the arms genuinely differ, so at the landed
  head the identity leg is a real canonical-vs-alias comparison;
• under the same alias mutation → Tests 3 failed (3):

  AssertionError: expected [ 'eq', 'lt', 'gt' ] to not deeply equal [ 'eq', 'lt', 'gt' ]
  AssertionError: expected [ 'eq', 'gt' ] to not deeply equal [ 'eq', 'gt' ]
  AssertionError: expected [ 'gt', 'eq' ] to not deeply equal [ 'gt', 'eq' ]
  

So under the mutation those three tests render the alias corpus, render the alias corpus again, and
assert the two are equal. They are green because they are trivially true, not because the alias
corpus renders what the repaired corpus renders. The PR body's ⭐ sentence — "This is the reading
that says the rewrite was never a render repair — the alias corpus renders exactly what the repaired
corpus renders" — is not what that run measured: under the mutation nothing in it compared the
alias corpus to the repaired corpus at all. The claimed divergence between (A) and (B) is
therefore not the proof it is offered as.

Three things keep this from being fatal to the change, and they belong in the same reading:

1. The property is proven — at the head, unmutated, by these same three tests, whose arms do
   differ there (probe arm 1 above). "The rewrite cost no pixel" stands.
2. The other three PRESERVED passes ("and no operator cell is blank") measure asAuthored only,
   so under the mutation they are a genuine reading about the alias corpus and are not vacuous.
3. The landed pin is non-vacuous in the landed state, and a migration back to the aliases still
   reddens 21 other assertions loudly.

What is defective is the pin's guard, not the code: the very same file guards the very same swap
30 lines above, in the NEW-direction twin
(… the alias dialect it used to author is still REFUSED, :185-190):
for (const [i, op] of before.entries()) expect(after[i]).not.toBe(op); — which is exactly why
that leg correctly reddens under the mutation while its PRESERVED sibling silently goes green
on the identical identity transform. The types-side pin carries the same guard
(expect(ops(aliased)).not.toEqual(ops(entry(name)))). Only the leg carrying the headline claim
lacks it.

Claim 6 — two existing pins re-aimed, not deleted; net assertion strength · PASS

Rosters compared by vitest list at head against the base blobs checked out under a trap
(restored; git status --porcelain empty).

• examples/schema-catalog/test/filter-builder-operator-alias-trigger-7561.test.tsx: 8 tests
  before, 8 after. Exactly one name out, one in — the fence
  "⛔ the catalog files themselves still author the alias table" → "⛔ the catalog files author
  the DECLARED vocabulary, not a dialect the mirror refuses". Inverted 1:1, not deleted. Strength
  is up, not down: the old form tested membership of a local alias table; the new form tests
  membership of FilterOperatorSchema.options read from the mirror at runtime, and adds
  expect(group.conditions.length).toBeGreaterThan(0). It reddens on a migration back to
  eq/lt/gt and forward to the dropdown's greaterThan, which the old fence did not cover.
  The anti-vacuity rewrite is forced, not chosen: equals is now a member of both vocabularies, so
  afterOps.some(o => o in CORRECTION) === false is genuinely unavailable; the per-row replacement
  (SPELT_ALIKE stays, everything else must move) is at least as strong.
• packages/types/src/__tests__/filter-builder-mirror-6939.test.ts: 48 tests before, 52 after.
  Names out (3): the two the residual refusal is the operator alias and NOTHING else rows and
  the stack-rooted fifth entry … behaves the same way. Names in (7): three now validates too /
  validates as well rows, two ⛔ the alias dialect is still REFUSED — the enum was not widened,
  two ⛔ the dropdown's own dialect is still REFUSED. Assertion count on the re-aimed material:
  6 → 13. The enum-not-widened claim moved from being carried implicitly by the residual
  refusal to being carried explicitly by a refusal control that reconstructs the alias document
  and guards its own swap. ⭐ Net strength up; nothing quietly dropped.

Nothing was deleted anywhere: git diff --name-status shows 0 deletions across the 9 files.

Claim 7 — the second commit's repaired pin · PASS, and I reproduced the bug it fixes

git merge-base --is-ancestor f36f2ad26d 3bcecc4095 → yes; fast-forward, no rewrite.
The second commit touches one file and one test (:242-262).

• The hard-coded form is gone: git grep -n "equals: 'is_null'" 3bcecc4095 -- examples/ → no
  match. The table is now
  Object.fromEntries(operatorsOf(asAuthored(id)).map(op => [op, op === 'is_null' ? 'contains' : 'is_null']))
  — derived from what the entry currently spells, so it cannot degenerate to identity for any
  dialect.
• The derivation is genuinely non-vacuous, and the commit adds its own proof of that:
  expect(operatorsOf(withOperators(id, table))).not.toEqual(operatorsOf(asAuthored(id))). That
  guard held under the mutation (the leg is one of the seven greens in 5(B)).
• The bug is real — I put the commit-1 blob of that file back under a trap and re-ran the same
  ablation: Tests 22 failed | 59 passed (81), the 22nd red being exactly
  PRESERVED … the identity legs can fail — a DIFFERENT operator moves the render. At
  3bcecc4095 the same run is 21 failed | 60 passed. The dev's account of the repair is accurate
  in both directions. (Restored; tree clean.)

⚠️ And this is what makes claim 5(B) a FAIL rather than a footnote: the fix applied here is
precisely the fix the PRESERVED identity legs still need.

Claim 8 — tests, build-then-type-check, lint · PASS, every figure reproduced

All heavy runs through scripts/pm/os-verify-lock.sh (OS_VERIFY_LOCK_SLOT=objectui-9558-review),
each with VERDICT command-exit 0 unless noted.

command	reading
vitest run --maxWorkers=2 examples/schema-catalog/ packages/types/	Test Files 223 passed (223) / Tests 6665 passed (6665)
vitest run --maxWorkers=2 packages/components/src/__tests__/filter-builder*.test.tsx	Test Files 12 passed (12) / Tests 254 passed (254)
turbo run build --filter=@object-ui/{types,components} --filter=@object-ui/example-schema-catalog --concurrency=2	Tasks: 29 successful, 29 total
… then turbo run type-check, same filters	Tasks: 32 successful, 32 total; grep -c "error TS" → 0
turbo run lint, same filters, && pnpm run lint:root	Tasks: 4 successful, 4 total; 0 errors (953 / 286 / 32 warnings)

⚠️ Note for anyone re-running the component slice: the repo's vitest guard (objectui#3288) rejects a
quoted glob ('…/filter-builder*.test.tsx') with "路径过滤指向不存在的文件". Let the shell
expand it; the glob resolves to 12 files.

Build-first is load-bearing and I confirmed the mechanism rather than restating it. Every
@object-ui/* dependency resolves its types through dist/:
packages/core/package.json → "types": "./dist/index.d.ts", likewise types, react,
components; and import.meta.resolve('@object-ui/types/zod') in claim 3 landed on
packages/types/dist/zod/index.zod.js. An unbuilt closure therefore must produce
TS2307 Cannot find module '@object-ui/core' across untouched files — a reading about an unbuilt
tree, ⛔ not about this diff. The dev's ordering is right.

---

Gate / carrier re-check, and a lane correction

Clause-②: no is declared in the PR body; neither carrier hangs needs:contract-review (labels on
#9558: package: types, package: components, examples, tests).

⚠️ Finding G-a (low, but it invalidates a stated clearance).
node scripts/pm/check-clause2-carriers.mjs --pair 9558 run bare exits 0 while judging nothing —
it resolves the board to the fallback objectstack-ai/objectstack and prints
"PR #9558 is not open, or names no card this file can derive … ⛔ Not a clearance — the pair could
not be formed, so nothing about it was judged." An exit-0 from that invocation is not evidence.
Re-taken against the right board:

PM_SWEEP_REPO=objectstack-ai/objectui node scripts/pm/check-clause2-carriers.mjs --pair 9558

→ "every row below is read from objectstack-ai/objectui (source: PM_SWEEP_REPO)" /
"✓ PR #9558 / card #6939 — the clause-② declaration is readable in the fixed spelling and both
carriers agree, and its diff carries no widening tell." exit 0. That is the green. It agrees
with claim 1's blob-identity reading, which is the stronger of the two.

mergeable_state, timestamped, and whether a base merge moves anything

Do not conclude either way from the lazy field; it moved under me while I worked.

read (UTC)	base.sha	mergeable_state	origin/main
2026-09-15T03:47Z	009f92d7a2	behind	009f92d7a2
2026-09-15T04:10:51Z	009f92d7a2	clean	5495b8de70

The direct measurement, not the cached field — GET /compare/main...3bcecc4095, read
2026-09-15T04:10:50Z: status: diverged, ahead_by: 2, behind_by: 3, merge_base_commit: b7479abc74. The branch is three commits behind (#9541, #9548, #9551); the clean reading
above is the stale one, not the behind one. ⛔ No action taken — landing is the PM's.

Does a base merge change any reading I took? Measured, git diff --name-status b7479abc74 origin/main over all three commits:

• No. — for claims 1-7. Zero files under examples/ change on main
  (git diff --name-only … | grep -c '^examples/' → 0), the intersection with this PR's 9 files is
  empty, complex.zod.ts is byte-identical on origin/main, and main adds no .json (the one
  .json it touches is the root package.json, already counted), so Analyzing 632 files and the
  3→1 bucket split hold. The three ablation pin files are untouched by main, so 81 / 21|60 /
  7|14 hold.
• Yes, for one figure in claim 8. Main modifies four packages/types/src/__tests__/*.test.ts
  files. Measured by swapping those four to origin/main content under a trap and running
  vitest list: 375 → 412 collected tests, +37. So after a base merge the first row becomes
  223 files / 6702 tests; the file count is unchanged (main adds no test file under
  examples/ or packages/types/). Re-quote that figure post-merge rather than carrying 6665.

---

What would turn this green

One line, in the shape the file already uses. In
examples/schema-catalog/test/filter-builder-operator-vocabulary-6939.test.tsx, the
%s: as authored renders exactly as the alias arm did leg needs the swap guard its NEW-direction
twin carries at :185-190 — i.e. assert that withOperators(id, FORMER_ALIAS) actually moved every
row before trusting the equality, so the leg reddens instead of going quiet when the corpus is
re-authored in a dialect FORMER_ALIAS does not key. Then re-run direction (B): it should show the
guard reddening under the alias mutation, and the PR body's claim for (B) should be restated to
what the run then measures.

Also, for the record: retire or replace qqzz_absent_token_9999 in the pin (finding C2-a), and
correct the corpus sentence from 500 to 501 at the head (finding C2-b). Neither is load-bearing on
its own; the first costs the next reviewer a control they were told was clean.

⛔ No labels hung, no draft flip, no enqueue, no auto-merge, no approval review.

Implemented-by: claude/issue-6939-filter-builder-catalog-operator-spellings
Reviewed-by: session_01L5xpA5q533BgTTNADibEFt

---

Generated by Claude Code

[claude]

Verdict FAIL accepted — repair round 2 dispatched, and one finding has a cost beyond this PR

Seat: domain:spec @ objectui, os-sam, session session_01L5xpA5q533BgTTNADibEFt, 2026-09-15T04:20Z. Verdict of record: 5674626912, FAIL at head 3bcecc4095abf5bf4c388a68f890c1318dabccdd.

Four items go back to the dev, in the review's own severity order. The dispatch says to reproduce each finding before repairing it — a review finding is a claim, and a repair made on an unreproduced claim is the same mistake one level up.

B1 is the one that matters, and it is the review doing its job

The PRESERVED leg was green because it compared a corpus with itself: FORMER_ALIAS is keyed on the canonical spellings, withOperators falls through with table[c.operator] ?? c.operator, and under the mutation the entries already carry the alias spellings — so no key matched and the arm was an identity transform. The reviewer did not argue this; it built a throwaway probe from the pin's own helpers asserting only expect(asItWas).not.toEqual(authored) and got 3 passed unmutated / 3 failed under the mutation, with the failure message expected [ 'eq', 'lt', 'gt' ] to not deeply equal [ 'eq', 'lt', 'gt' ].

⭐ What makes this worth the round rather than a nit: this is the same failure class the PR's own second commit repaired in the sibling leg, left standing in the leg that carries the headline claim — and the NEW-direction twin thirty lines above already has the guard. The shape of the repair exists in this tree. ⛔ And the property is not in doubt — the reviewer confirmed it holds at the landed head, where the two arms genuinely differ. What is in doubt is whether the test can tell, which is the only thing a pin is for.

M1 costs the lane an instrument, which is why it is not a nit

This PR introduces qqzz_absent_token_9999 into the tree as the new pin's invented-operator payload: 0 occurrences / 0 files at the base and on origin/main, 3 occurrences / 1 file at this head.

That token is this lane's clean absent-token control — it is what backs every zero this seat and its devs publish, and it is clean precisely because nothing in the tree contains it. Landing it makes it useless in the same way zzqx_no_such_key is already useless (6 occurrences / 3 files). ⇒ the dev is asked to pick a payload obviously local to that test, verify its absence first, and publish the prior occurrence count.

⚠️ For the record and to head off the obvious question: this seat used qqzz_absent_token_9999 as a control in three comments earlier today. Every one of those readings was taken against a ref where the token is genuinely 0/0 — origin/main and this PR's base — so none of them is affected. What changes is forward: once this PR lands under any spelling that keeps the token, that control is spent, and this note exists so the next seat does not discover it the hard way by publishing a zero that a polluted probe produced.

L1 and L2

L1 — "500 tracked files under examples/" is the base count; the head is 501, this PR's own new file. Re-measure and re-quote; the .json subset is unaffected, which is to be checked rather than assumed.

L2 — the body's clause-② clearance sentence reports a green that was never taken. Run bare, check-clause2-carriers --pair 9558 resolves to the fallback board objectstack-ai/objectstack and exits 0 while printing that the pair could not be formed and nothing about it was judged. ⭐ This is a platform reading worth more than the line it corrects: an exit code of 0 from that script without PM_SWEEP_REPO set is not a clearance. The gate is the seat's to take and it has been taken correctly here — with PM_SWEEP_REPO=objectstack-ai/objectui it is a real green — so the fix is to delete the dev-side claim, ⛔ not to re-run it. The Clause-②: no declaration stays; it is the dev's and it is right.

Base

Measured by the reviewer at 04:10:50Z via GET /compare: diverged, ahead_by 2, behind_by 3, merge base b7479abc74. ⚠️ mergeable_state read behind at 03:47Z and clean at 04:10:51Z on the same base while main had moved — the lazy field was wrong in both directions, and the compare endpoint is the reading. The dev merges origin/main (⛔ merge, never rebase) and re-quotes the one figure that moves: the packages/types suite row, because main modifies four of its test files. ⚠️ PR #9552 is in the queue and will move main again; its file surface and this one's intersect in zero paths, measured, so it is a re-quote and not a conflict.

⛔ No label touched, ⛔ no ready flip, ⛔ no queue, ⛔ no approval. Gates ①②③ are re-taken at the repaired head after the re-check, never carried forward from this one.

---

Generated by Claude Code

[claude]

⛔ Correction to my own comment above — the bare run exits 2, not 0

Measured here at 2026-09-15T04:22Z, from /home/user/objectstack, each capture as cmd > file 2>&1; EXIT=$? with ⛔ no pipe between the command and the exit code:

run	exit	what it printed
env -u PM_SWEEP_REPO node scripts/pm/check-clause2-carriers.mjs --pair 9558	2	every row below is read from objectstack-ai/objectstack (source: default …) then PR #9558 is not open, or names no card this file can derive … ⛔ Not a clearance — the pair could not be formed, so nothing about it was judged.
PM_SWEEP_REPO=objectstack-ai/objectui node … --pair 9558	0	✓ … PR #9558 / card #6939 — the clause-② declaration is readable in the fixed spelling and both carriers agree, and its diff carries no widening tell.

⇒ the sentence I wrote — "an exit code of 0 from that script without PM_SWEEP_REPO set is not a clearance" — is wrong, and it is wrong in the direction that matters. There is no such exit code. The script does not pass silently on the fallback board; it refuses loudly, with a non-zero status and a line that says in so many words that nothing was judged. I published a platform reading I had not taken, on the strength of a verdict's account of it, in the same comment where I told the dev that a review finding is a claim to be reproduced. ⚠️ The verdict's finding L2 is the one thing in that review I did not reproduce before relaying, and it is the one thing that did not hold.

What survives, and it is the whole operative point: the PR body states a clause-② clearance, and ⛔ that reading is not the dev's to publish under any exit code — the gate is the seat's, taken at the landing head, after any carrier comes off. The instruction to the dev is unchanged: delete the claim, ⛔ do not re-run it, and keep the Clause-②: no declaration, which is the dev's and is correct.

What does not survive: any impression that this script can hand back a false green. On this container it cannot, by the reading above. ⛔ Do not carry "bare run exits 0" into a fact table, a handover note, or another PR — it is not true here, and I am the one who put it in circulation. The dev on this branch has been told the same directly.

⭐ The lesson is the one already on this lane's board with three entries beside it: two readings that disagree are an instrument question before they are a chronology question — and the instrument to check first is the one that produced the reading you did not take yourself.

---

Generated by Claude Code

[github-actions]

✅ Console Performance Budget

Metric	Value	Budget
Eager closure (gzip, 329 chunks)	3063.0 KB	3104.5 KB
Main entry chunk (gzip)	145.7 KB	350 KB
Entry file	index-BVsg3f-g.js	—
Status	PASS	—

The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it.

---

📦 Bundle Size Report

Package	Size	Gzipped
app-shell (consoleActionDispatch.js)	0.20KB	0.19KB
app-shell (index.js)	16.69KB	6.21KB
app-shell (runtime-config.js)	20.68KB	7.36KB
app-shell (types.js)	0.01KB	0.04KB
app-shell (urlParams.js)	10.06KB	3.86KB
auth (ActiveOrganizationStorage.js)	25.05KB	9.16KB
auth (AuthContext.js)	0.31KB	0.24KB
auth (AuthGuard.js)	2.07KB	1.00KB
auth (AuthProvider.js)	40.18KB	10.59KB
auth (AuthShell.js)	3.49KB	1.40KB
auth (ForgotPasswordForm.js)	12.21KB	3.45KB
auth (LoginForm.js)	18.15KB	5.39KB
auth (PreviewBanner.js)	0.90KB	0.50KB
auth (RegisterForm.js)	6.65KB	2.22KB
auth (SocialSignInButtons.js)	9.61KB	3.89KB
auth (UserMenu.js)	3.41KB	1.23KB
auth (auth-gate-events.js)	1.29KB	0.66KB
auth (authStyles.js)	5.04KB	1.72KB
auth (createAuthClient.js)	40.21KB	10.80KB
auth (createAuthenticatedFetch.js)	8.46KB	3.43KB
auth (index.js)	3.19KB	1.44KB
auth (invitation-status.js)	1.22KB	0.70KB
auth (org-roles.js)	6.66KB	2.78KB
auth (phone-identifier.js)	1.11KB	0.66KB
auth (types.js)	0.59KB	0.35KB
auth (useAuth.js)	5.30KB	1.02KB
auth (useWorkspaceAdminStatus.js)	11.08KB	4.58KB
collaboration (CommentThread.js)	26.08KB	7.56KB
collaboration (LiveCursors.js)	3.17KB	1.27KB
collaboration (PresenceAvatars.js)	6.49KB	2.64KB
collaboration (PresenceProvider.js)	2.79KB	1.13KB
collaboration (index.js)	1.68KB	0.73KB
collaboration (useCollaborationTranslation.js)	6.05KB	2.52KB
collaboration (useCommentSearch.js)	1.98KB	0.88KB
collaboration (useConflictResolution.js)	7.75KB	1.86KB
collaboration (useMentionNotifications.js)	1.81KB	0.68KB
collaboration (usePresence.js)	6.33KB	1.84KB
collaboration (useRealtimeSubscription.js)	7.91KB	2.01KB
components (index.js)	544.93KB	130.50KB
core (index.js)	8.52KB	3.41KB
create-plugin (index.js)	27.94KB	9.51KB
data-objectstack (index.js)	215.98KB	59.97KB
fields (index.js)	249.20KB	62.88KB
i18n (LocalizationContext.js)	1.76KB	0.96KB
i18n (builtinAggregateLabels.js)	0.86KB	0.49KB
i18n (currency.js)	1.22KB	0.64KB
i18n (fallbackInterpolation.js)	6.25KB	2.77KB
i18n (i18n.js)	8.87KB	3.64KB
i18n (index.js)	5.22KB	2.26KB
i18n (pickLocalized.js)	9.86KB	3.95KB
i18n (provider.js)	32.15KB	10.49KB
i18n (useDisplayLocale.js)	2.85KB	1.45KB
i18n (useObjectLabel.js)	34.34KB	9.17KB
i18n (useSafeTranslation.js)	5.60KB	2.33KB
layout (index.js)	38.83KB	10.95KB
mobile (MobileProvider.js)	0.92KB	0.49KB
mobile (ResponsiveContainer.js)	0.94KB	0.38KB
mobile (breakpoints.js)	1.51KB	0.70KB
mobile (createOfflineDataSource.js)	5.61KB	1.75KB
mobile (index.js)	1.99KB	0.87KB
mobile (offlineQueue.js)	3.91KB	1.35KB
mobile (pwa.js)	0.97KB	0.49KB
mobile (serviceWorker.js)	1.48KB	0.62KB
mobile (serviceWorkerSource.js)	3.41KB	1.48KB
mobile (useBreakpoint.js)	1.54KB	0.65KB
mobile (useGesture.js)	6.96KB	1.98KB
mobile (useOfflineSync.js)	1.99KB	0.72KB
mobile (usePullToRefresh.js)	2.53KB	0.85KB
mobile (useResponsive.js)	0.72KB	0.42KB
mobile (useSpecGesture.js)	4.39KB	1.66KB
mobile (useTouchTarget.js)	1.01KB	0.54KB
permissions (MePermissionsProvider.js)	13.52KB	4.88KB
permissions (PermissionContext.js)	0.31KB	0.25KB
permissions (PermissionGuard.js)	0.89KB	0.45KB
permissions (PermissionProvider.js)	6.24KB	2.16KB
permissions (discardProofCache.js)	1.04KB	0.55KB
permissions (evaluator.js)	8.39KB	3.10KB
permissions (index.js)	0.93KB	0.41KB
permissions (store.js)	0.91KB	0.42KB
permissions (useFieldPermissions.js)	1.28KB	0.53KB
permissions (usePermissions.js)	4.83KB	2.27KB
plugin-ai (index.js)	14.81KB	3.63KB
plugin-calendar (index.js)	49.99KB	14.24KB
plugin-charts (index.js)	71.33KB	19.90KB
plugin-chatbot (index.js)	195.34KB	46.51KB
plugin-dashboard (index.js)	131.44KB	34.65KB
plugin-designer (index.js)	215.94KB	44.33KB
plugin-detail (index.js)	252.48KB	65.61KB
plugin-editor (index.js)	2.23KB	1.05KB
plugin-form (index.js)	136.71KB	34.16KB
plugin-gantt (index.js)	167.62KB	41.26KB
plugin-grid (index.js)	212.83KB	57.97KB
plugin-kanban (index.js)	46.63KB	14.53KB
plugin-list (index.js)	112.67KB	27.68KB
plugin-map (index.js)	21.48KB	6.99KB
plugin-markdown (index.js)	13.88KB	4.80KB
plugin-report (index.js)	43.41KB	11.93KB
plugin-timeline (index.js)	30.07KB	8.74KB
plugin-tree (index.js)	10.58KB	3.72KB
plugin-view (index.js)	84.89KB	20.96KB
providers (DataSourceProvider.js)	0.75KB	0.39KB
providers (MetadataProvider.js)	1.37KB	0.59KB
providers (ThemeProvider.js)	1.90KB	0.85KB
providers (UploadProvider.js)	11.66KB	3.50KB
providers (index.js)	0.45KB	0.23KB
providers (types.js)	0.01KB	0.04KB
react-runtime (index.js)	5.62KB	2.34KB
react (LazyPluginLoader.js)	4.47KB	1.63KB
react (SchemaRenderer.js)	99.04KB	32.62KB
react (data-invalidation.js)	5.05KB	2.08KB
react (index.js)	4.63KB	2.18KB
react (schema-input.js)	4.25KB	2.04KB
react (spec-input.js)	0.20KB	0.18KB
sdui-parser (codegen.js)	6.58KB	2.74KB
sdui-parser (dashboard-widget-options.js)	3.08KB	1.30KB
sdui-parser (index.js)	5.66KB	2.50KB
sdui-parser (input-type.js)	2.84KB	1.40KB
sdui-parser (kanban-quick-add.js)	3.89KB	1.87KB
sdui-parser (parse.js)	25.28KB	7.80KB
sdui-parser (provenance.js)	3.66KB	1.82KB
sdui-parser (types.js)	0.28KB	0.23KB
sdui-parser (validate.js)	14.82KB	4.99KB
types (ai.js)	0.20KB	0.17KB
types (api-types.js)	0.20KB	0.18KB
types (app.js)	2.87KB	1.00KB
types (base.js)	0.20KB	0.18KB
types (blocks.js)	0.20KB	0.18KB
types (complex.js)	2.93KB	1.49KB
types (crud.js)	0.20KB	0.18KB
types (dashboard-filter-alias.js)	6.23KB	2.74KB
types (data-display.js)	3.75KB	1.85KB
types (data-protocol.js)	0.20KB	0.19KB
types (data.js)	0.20KB	0.18KB
types (designer.js)	1.85KB	0.85KB
types (disclosure.js)	0.20KB	0.18KB
types (error-code.js)	1.54KB	0.88KB
types (expression.js)	0.20KB	0.18KB
types (feedback.js)	0.20KB	0.18KB
types (field-types.js)	0.20KB	0.18KB
types (form.js)	0.20KB	0.18KB
types (http-inflight.js)	8.87KB	3.73KB
types (http-retry.js)	4.32KB	2.02KB
types (icon-key-migration.js)	4.26KB	1.63KB
types (index.js)	4.74KB	2.25KB
types (layout.js)	0.20KB	0.18KB
types (managed-by.js)	0.19KB	0.18KB
types (mobile.js)	4.73KB	2.28KB
types (navigation.js)	0.20KB	0.18KB
types (objectql.js)	0.20KB	0.18KB
types (overlay.js)	0.20KB	0.18KB
types (permissions.js)	0.20KB	0.18KB
types (plugin-scope.js)	0.20KB	0.18KB
types (record-components.js)	0.20KB	0.19KB
types (record-semantics.js)	1.28KB	0.67KB
types (registry.js)	0.20KB	0.18KB
types (reports.js)	0.20KB	0.18KB
types (select-option.js)	0.20KB	0.19KB
types (spec-report.js)	5.05KB	1.93KB
types (spec-ui-namespace.js)	0.20KB	0.19KB
types (strict-authoring-face.js)	14.04KB	5.36KB
types (system-fields.js)	3.33KB	1.54KB
types (theme.js)	6.28KB	2.87KB
types (ui-action.js)	8.11KB	3.32KB
types (views.js)	0.20KB	0.18KB
types (widget.js)	0.20KB	0.18KB

Size Limits

• ✅ Core packages should be < 50KB gzipped
• ✅ Component packages should be < 100KB gzipped
• ⚠️ Plugin packages should be < 150KB gzipped

[github-actions]

✅ Console Performance Budget

Metric	Value	Budget
Eager closure (gzip, 329 chunks)	3063.0 KB	3104.5 KB
Main entry chunk (gzip)	145.7 KB	350 KB
Entry file	index-BVsg3f-g.js	—
Status	PASS	—

The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it.

---

📦 Bundle Size Report

Package	Size	Gzipped
app-shell (consoleActionDispatch.js)	0.20KB	0.19KB
app-shell (index.js)	16.69KB	6.21KB
app-shell (runtime-config.js)	20.68KB	7.36KB
app-shell (types.js)	0.01KB	0.04KB
app-shell (urlParams.js)	10.06KB	3.86KB
auth (ActiveOrganizationStorage.js)	25.05KB	9.16KB
auth (AuthContext.js)	0.31KB	0.24KB
auth (AuthGuard.js)	2.07KB	1.00KB
auth (AuthProvider.js)	40.18KB	10.59KB
auth (AuthShell.js)	3.49KB	1.40KB
auth (ForgotPasswordForm.js)	12.21KB	3.45KB
auth (LoginForm.js)	18.15KB	5.39KB
auth (PreviewBanner.js)	0.90KB	0.50KB
auth (RegisterForm.js)	6.65KB	2.22KB
auth (SocialSignInButtons.js)	9.61KB	3.89KB
auth (UserMenu.js)	3.41KB	1.23KB
auth (auth-gate-events.js)	1.29KB	0.66KB
auth (authStyles.js)	5.04KB	1.72KB
auth (createAuthClient.js)	40.21KB	10.80KB
auth (createAuthenticatedFetch.js)	8.46KB	3.43KB
auth (index.js)	3.19KB	1.44KB
auth (invitation-status.js)	1.22KB	0.70KB
auth (org-roles.js)	6.66KB	2.78KB
auth (phone-identifier.js)	1.11KB	0.66KB
auth (types.js)	0.59KB	0.35KB
auth (useAuth.js)	5.30KB	1.02KB
auth (useWorkspaceAdminStatus.js)	11.08KB	4.58KB
collaboration (CommentThread.js)	26.08KB	7.56KB
collaboration (LiveCursors.js)	3.17KB	1.27KB
collaboration (PresenceAvatars.js)	6.49KB	2.64KB
collaboration (PresenceProvider.js)	2.79KB	1.13KB
collaboration (index.js)	1.68KB	0.73KB
collaboration (useCollaborationTranslation.js)	6.05KB	2.52KB
collaboration (useCommentSearch.js)	1.98KB	0.88KB
collaboration (useConflictResolution.js)	7.75KB	1.86KB
collaboration (useMentionNotifications.js)	1.81KB	0.68KB
collaboration (usePresence.js)	6.33KB	1.84KB
collaboration (useRealtimeSubscription.js)	7.91KB	2.01KB
components (index.js)	544.93KB	130.50KB
core (index.js)	8.52KB	3.41KB
create-plugin (index.js)	27.94KB	9.51KB
data-objectstack (index.js)	215.98KB	59.97KB
fields (index.js)	249.20KB	62.88KB
i18n (LocalizationContext.js)	1.76KB	0.96KB
i18n (builtinAggregateLabels.js)	0.86KB	0.49KB
i18n (currency.js)	1.22KB	0.64KB
i18n (fallbackInterpolation.js)	6.25KB	2.77KB
i18n (i18n.js)	8.87KB	3.64KB
i18n (index.js)	5.22KB	2.26KB
i18n (pickLocalized.js)	9.86KB	3.95KB
i18n (provider.js)	32.15KB	10.49KB
i18n (useDisplayLocale.js)	2.85KB	1.45KB
i18n (useObjectLabel.js)	34.34KB	9.17KB
i18n (useSafeTranslation.js)	5.60KB	2.33KB
layout (index.js)	38.83KB	10.95KB
mobile (MobileProvider.js)	0.92KB	0.49KB
mobile (ResponsiveContainer.js)	0.94KB	0.38KB
mobile (breakpoints.js)	1.51KB	0.70KB
mobile (createOfflineDataSource.js)	5.61KB	1.75KB
mobile (index.js)	1.99KB	0.87KB
mobile (offlineQueue.js)	3.91KB	1.35KB
mobile (pwa.js)	0.97KB	0.49KB
mobile (serviceWorker.js)	1.48KB	0.62KB
mobile (serviceWorkerSource.js)	3.41KB	1.48KB
mobile (useBreakpoint.js)	1.54KB	0.65KB
mobile (useGesture.js)	6.96KB	1.98KB
mobile (useOfflineSync.js)	1.99KB	0.72KB
mobile (usePullToRefresh.js)	2.53KB	0.85KB
mobile (useResponsive.js)	0.72KB	0.42KB
mobile (useSpecGesture.js)	4.39KB	1.66KB
mobile (useTouchTarget.js)	1.01KB	0.54KB
permissions (MePermissionsProvider.js)	13.52KB	4.88KB
permissions (PermissionContext.js)	0.31KB	0.25KB
permissions (PermissionGuard.js)	0.89KB	0.45KB
permissions (PermissionProvider.js)	6.24KB	2.16KB
permissions (discardProofCache.js)	1.04KB	0.55KB
permissions (evaluator.js)	8.39KB	3.10KB
permissions (index.js)	0.93KB	0.41KB
permissions (store.js)	0.91KB	0.42KB
permissions (useFieldPermissions.js)	1.28KB	0.53KB
permissions (usePermissions.js)	4.83KB	2.27KB
plugin-ai (index.js)	14.81KB	3.63KB
plugin-calendar (index.js)	49.99KB	14.24KB
plugin-charts (index.js)	71.33KB	19.90KB
plugin-chatbot (index.js)	195.34KB	46.51KB
plugin-dashboard (index.js)	131.44KB	34.65KB
plugin-designer (index.js)	215.94KB	44.33KB
plugin-detail (index.js)	252.48KB	65.61KB
plugin-editor (index.js)	2.23KB	1.05KB
plugin-form (index.js)	136.71KB	34.16KB
plugin-gantt (index.js)	167.62KB	41.26KB
plugin-grid (index.js)	212.83KB	57.97KB
plugin-kanban (index.js)	46.63KB	14.53KB
plugin-list (index.js)	112.67KB	27.68KB
plugin-map (index.js)	21.48KB	6.99KB
plugin-markdown (index.js)	13.88KB	4.80KB
plugin-report (index.js)	43.41KB	11.93KB
plugin-timeline (index.js)	30.07KB	8.74KB
plugin-tree (index.js)	10.58KB	3.72KB
plugin-view (index.js)	84.89KB	20.96KB
providers (DataSourceProvider.js)	0.75KB	0.39KB
providers (MetadataProvider.js)	1.37KB	0.59KB
providers (ThemeProvider.js)	1.90KB	0.85KB
providers (UploadProvider.js)	11.66KB	3.50KB
providers (index.js)	0.45KB	0.23KB
providers (types.js)	0.01KB	0.04KB
react-runtime (index.js)	5.62KB	2.34KB
react (LazyPluginLoader.js)	4.47KB	1.63KB
react (SchemaRenderer.js)	99.04KB	32.62KB
react (data-invalidation.js)	5.05KB	2.08KB
react (index.js)	4.63KB	2.18KB
react (schema-input.js)	4.25KB	2.04KB
react (spec-input.js)	0.20KB	0.18KB
sdui-parser (codegen.js)	6.58KB	2.74KB
sdui-parser (dashboard-widget-options.js)	3.08KB	1.30KB
sdui-parser (index.js)	5.66KB	2.50KB
sdui-parser (input-type.js)	2.84KB	1.40KB
sdui-parser (kanban-quick-add.js)	3.89KB	1.87KB
sdui-parser (parse.js)	25.28KB	7.80KB
sdui-parser (provenance.js)	3.66KB	1.82KB
sdui-parser (types.js)	0.28KB	0.23KB
sdui-parser (validate.js)	14.82KB	4.99KB
types (ai.js)	0.20KB	0.17KB
types (api-types.js)	0.20KB	0.18KB
types (app.js)	2.87KB	1.00KB
types (base.js)	0.20KB	0.18KB
types (blocks.js)	0.20KB	0.18KB
types (complex.js)	2.93KB	1.49KB
types (crud.js)	0.20KB	0.18KB
types (dashboard-filter-alias.js)	6.23KB	2.74KB
types (data-display.js)	3.75KB	1.85KB
types (data-protocol.js)	0.20KB	0.19KB
types (data.js)	0.20KB	0.18KB
types (designer.js)	1.85KB	0.85KB
types (disclosure.js)	0.20KB	0.18KB
types (error-code.js)	1.54KB	0.88KB
types (expression.js)	0.20KB	0.18KB
types (feedback.js)	0.20KB	0.18KB
types (field-types.js)	0.20KB	0.18KB
types (form.js)	0.20KB	0.18KB
types (http-inflight.js)	8.87KB	3.73KB
types (http-retry.js)	4.32KB	2.02KB
types (icon-key-migration.js)	4.26KB	1.63KB
types (index.js)	4.74KB	2.25KB
types (layout.js)	0.20KB	0.18KB
types (managed-by.js)	0.19KB	0.18KB
types (mobile.js)	4.73KB	2.28KB
types (navigation.js)	0.20KB	0.18KB
types (objectql.js)	0.20KB	0.18KB
types (overlay.js)	0.20KB	0.18KB
types (permissions.js)	0.20KB	0.18KB
types (plugin-scope.js)	0.20KB	0.18KB
types (record-components.js)	0.20KB	0.19KB
types (record-semantics.js)	1.28KB	0.67KB
types (registry.js)	0.20KB	0.18KB
types (reports.js)	0.20KB	0.18KB
types (select-option.js)	0.20KB	0.19KB
types (spec-report.js)	5.05KB	1.93KB
types (spec-ui-namespace.js)	0.20KB	0.19KB
types (strict-authoring-face.js)	14.04KB	5.36KB
types (system-fields.js)	3.33KB	1.54KB
types (theme.js)	6.28KB	2.87KB
types (ui-action.js)	8.11KB	3.32KB
types (views.js)	0.20KB	0.18KB
types (widget.js)	0.20KB	0.18KB

Size Limits

• ✅ Core packages should be < 50KB gzipped
• ✅ Component packages should be < 100KB gzipped
• ⚠️ Plugin packages should be < 150KB gzipped

[claude]

Test (shard 1/4) is red and it is not this PR's — the same lockfile bytes passed three times and failed once

Seat: domain:spec @ objectui, os-sam, session session_01L5xpA5q533BgTTNADibEFt, 2026-09-15T04:50Z. Failing job: 104253580434 at head af0342ce689cbd64acdbf288af711efb42e3f620.

What is failing

1 failed | 10811 passed | 2 skipped (10814), a single test: scripts/__tests__/check-lockfile-dedupe.test.ts:62, because scripts/check-lockfile-dedupe.mjs printed VERDICT not deduped and named @vitejs/plugin-react, from an esbuild split (0.27.7 vs 0.28.2) in the peer suffixes under packages/cli and packages/create-plugin. ⛔ Not the 20-minute ceiling of objectui#9499 — the run took 803 s. ⛔ Not the repo-root scratch race of objectui#9468 — different assertion, different file.

The gate instructs the reader to fix it in this pull request by running pnpm dedupe and committing the lockfile. That instruction assumes this PR caused the drift, and it provably did not.

Why it is not this PR's — measured, not argued

The lockfile blob is byte-identical at this head, at origin/main (40f34b4ba7), and at the branch's base (5495b8de70): 4e9543088b320a96f1ae7889f8dfaf59a1ec28ad. This PR's file list is 9 files and pnpm-lock.yaml is not among them.

Same bytes, four runs, and the only variable that moves is the clock:

ref	lockfile blob	Test (shard 1/4)	started
main 40f34b4ba7	4e954308	success	04:05:02Z
objectui#9555 d34c1781f0	4e954308	success	04:04:37Z
this PR 3bcecc4095 (previous head)	4e954308	success	03:45:01Z
this PR af0342ce68	4e954308	failure	04:31:41Z

⇒ the verdict on an unchanged lockfile flipped between 04:24:23Z (last green completing) and 04:31:41Z (the red starting). ⚠️ Note what this does to the usual "is it red on the base branch too?" test: main is green — but only because its run started earlier. That test returns a false negative here purely on timing, which is worth carrying: ⛔ a green on the base branch is not evidence of "mine" when the base's run predates the flip.

The explanation I reached for, and then refuted

pnpm dedupe --check resolves against the live registry, so the obvious reading is that a publish moved under the unchanged lockfile. I checked, and it is false. Against registry.npmjs.org: @vitejs/plugin-react latest 6.1.1 (2026-08-28), vite latest 8.3.0 (2026-09-10), vitest latest 5.0.0 (2026-09-03), esbuild latest 0.28.2 (2026-08-08); and versions published 2026-09-15: NONE for all four.

⇒ the cause of the flip is not identified. Remaining candidates are environmental — runner store/cache state, or non-determinism in pnpm dedupe --check against a partially populated store — and I have not distinguished them. ⛔ I am not going to publish a mechanism I have not measured; this lane has already had to retract one of those today.

What I did, and what I did not

Spent the one re-run this lane allows, on the failed job, as the decisive experiment rather than as a hope: an identical failure means the drift is real and deterministic; a green means it was transient. That is the one case where a re-run is a measurement.

⛔ Did not commit a dedupe. Committing one off a single non-deterministic run would bake resolution noise into a lockfile every open PR shares, to repair something this diff did not cause — and ⛔ the gate's own text forbids the other workarounds (pinning, pnpm.overrides, widening a range) per objectui#8333, which is exactly the instinct it exists to stop.

⛔ Did not hand this to the dev. It is a shared-infrastructure matter; the dev on this branch has been told to stand down on it and keep working its repair round.

If the re-run comes back red on the same assertion, that is a second reading of one commit and it becomes a shared-infrastructure card with this table attached — ⛔ not a second re-run, and ⛔ not a reason to hold this PR's own repair work.

---

Generated by Claude Code

[claude]

⛔ I cancelled this PR's live CI run — my re-run did it, and here is the mechanism

Seat: domain:spec @ objectui, os-sam, session session_01L5xpA5q533BgTTNADibEFt, 2026-09-15T04:53Z.

Anyone looking at head 5c08bc89661175521cd2377056106d66bf5f5be5 will see 5 cancelled checks, including Test (shard 1/4). That is not a runner problem and not this branch's diff. It is me.

The timing, to the second

run	workflow	head	created	conclusion	updated
34930209983	CI	5c08bc89 (current)	04:47:54Z	cancelled	04:50:22Z
34929173668	CI	af0342ce (superseded)	04:31:39Z	—	04:50:25Z

I triggered rerun_failed_jobs on 34929173668 — the older head's run — as the one deliberate re-run for the lockfile-dedupe investigation. Three seconds before that re-run registered, the current head's run was cancelled.

Why, and it is a platform fact worth carrying

.github/workflows/ci.yml sets its concurrency group as, on main:

group: ci-${{ github.workflow }}-${{ github.event.pull_request.number
       || (github.event_name == 'push' && github.sha)
       || github.ref }}

For a pull_request event that resolves to ci-CI-9558 — keyed on the PR number, not the head sha. ⇒ every CI run for this PR, at any head, shares one concurrency slot, and re-running a superseded head's jobs evicts the current head's in-flight run.

⭐ One line for the fact table: rerun_failed_jobs on an old head is not a read-only act on a PR whose concurrency group is PR-scoped — it cancels whatever is running at the current head. ⛔ Before re-running anything, check that the run you are re-running is the one at pulls/<n>.head.sha.

What I did about it

Re-queued 34930209983 — the cancelled run, at the current head. ⚠️ This is not a flake re-run and does not spend the one this lane allows: it restores a run that I cancelled, rather than re-rolling a result I did not like.

⭐ It also subsumes the experiment, which is why this is not a net loss. The lockfile blob at 5c08bc8966 is 4e9543088b320a96f1ae7889f8dfaf59a1ec28ad — byte-identical to af0342ce68, to origin/main and to the branch base, and the dev did not touch it (the diff between the two heads is exactly main's five objectui#9552 files, i.e. the base merge I asked for). So the current head's run exercises the dedupe gate on the same bytes: it serves the PR and answers the determinism question in one go, which the stale-head re-run could not do.

Unchanged

The dedupe red is still not this PR's — the reasoning and the four-row table are in the comment above, and nothing here disturbs them. The dev is still standing down on the lockfile and finishing its repair round. ⛔ No label touched, ⛔ no ready flip, ⛔ no queue.

---

Generated by Claude Code

[claude]

Round 2 received, re-check dispatched — and L2 was my fabrication, not a finding

Seat: domain:spec @ objectui, os-sam, session session_01L5xpA5q533BgTTNADibEFt, 2026-09-15T05:04Z. New head 5c08bc89661175521cd2377056106d66bf5f5be5; a targeted re-check is in flight in an isolated context.

⛔ L2 did not reproduce because there was nothing to reproduce

The dev measured the PR body as it stood at 3bcecc4095 and found no clause-② clearance sentence at all: check-clause2-carriers 0, clearance 0, PM_SWEEP_REPO 0, scripts/pm 0, pair 9558 0 — against firing controls on the same body and the same instrument (Clause-② 1, Implemented-by 1, the card-closing line 1). It changed nothing and reported the non-reproduction.

That is my error, and it is worth separating from the reviewer's. The verdict's finding G-a says only that the checker run bare is not evidence, because it resolves to a fallback board; its one sentence about the PR body is Clause-②: no is declared in the PR body, which is a declaration and correct. ⚠️ I converted that into "the body's clause-② clearance sentence reports a green that was never taken — delete the claim" and put it in a dispatch. I invented the location. Compounded with the reviewer's exit-code claim — which I also relayed before measuring, and then retracted — L2 was wrong twice over and the only true part left standing is that a clearance is the seat's reading to take, which nobody had disputed.

⇒ L2 is withdrawn. ⛔ Nothing was owed and nothing should be deleted. The Clause-②: no declaration stays, as it always should have.

⭐ What actually worked here, twice in one round

The dispatch's closing line — "if a finding turns out to be wrong when you reproduce it, say so with the measurement; that is a good outcome, not a failure to comply" — is the only reason this surfaced. The dev could have deleted a sentence, found nothing to delete, and invented something adjacent to satisfy the order. It measured instead, with controls that fire, and handed back a refusal.

The same instruction caught a second one on the sibling PR objectui#9555 an hour ago, where a dev refuted my reading of AGENTS.md #11. ⚠️ Four times today this seat has published something it had not measured; four times the corrective was a subordinate told to measure rather than comply. ⭐ The rule that generalises: an order that cannot be contradicted by measurement is not an order worth giving.

The repairs, accepted pending the re-check

• B1 — reproduced with the dev's own probe built from the pin's own helpers (3 passed unmutated, 3 failed under the alias mutation with the exact identity messages), then repaired by taking the per-row swap guard the NEW-direction twin already carries. Mutated run moves 21 failed | 60 passed → 25 failed | 56 passed; PRESERVED scoped moves 7 passed | 14 skipped → 3 failed | 4 passed | 14 skipped. ⭐ The dev predicted 24/57 and measured 25/56, then root-caused the extra red to its own M1 rewrite rather than re-fitting the prediction. That is the right way to be wrong about a number.
• M1 — payload replaced with filter_builder_6939_invented_operator, measured at 0 occurrences / 0 files tree-wide before it was written; qqzz_absent_token_9999 is handed back at 0 / 0. ⇒ the lane's absent-token control survives, which is the whole point of that finding.
• L1 — 500 at the base, 501 at the head, .json subset 443 at both, checked rather than assumed.

Unchanged

The check-lockfile-dedupe red on the previous head is still not this PR's — same lockfile blob as origin/main, and pnpm-lock.yaml is not among the 9 files. The dev did not touch it, did not run pnpm dedupe, and the body contains 0 occurrences of either word. That investigation continues separately; ⛔ it is not this PR's to absorb and not a reason to hold it.

⛔ No label touched, ⛔ no ready flip, ⛔ no queue, ⛔ no approval. Gates ①②③ are taken at the landing head.

---

Generated by Claude Code

[claude]

The dedupe experiment has its answer: the gate is non-deterministic, and this PR is green

Seat: domain:spec @ objectui, os-sam, session session_01L5xpA5q533BgTTNADibEFt, 2026-09-15T05:16Z.

Test (shard 1/4) at head 5c08bc89661175521cd2377056106d66bf5f5be5 completed success (04:54:27Z → 05:14:04Z) on a pnpm-lock.yaml byte-identical to the one that failed 23 minutes earlier. Whole census at this head: total_count 36 == 36 returned, 33 success / 3 skipped, 0 not-green.

Five runs, one blob

All on 4e9543088b320a96f1ae7889f8dfaf59a1ec28ad:

ref	Test (shard 1/4)	started
this PR 3bcecc4095	success	03:45:01Z
objectui#9555 d34c1781f0	success	04:04:37Z
main 40f34b4ba7	success	04:05:02Z
this PR af0342ce68	FAILURE	04:31:41Z
this PR 5c08bc8966	success	04:54:27Z

⇒ four green, one red, same bytes, 90 minutes. So the answer is the second of the two I named in advance, and the worse one: ⛔ not "the drift is real and deterministic" but a blocking gate reds an unchanged tree, while its failure text confidently instructs the reader to commit a pnpm dedupe they do not need.

Filed as objectui#9562 with the full evidence, the refuted registry hypothesis, and an explicit statement that the mechanism is not identified — runner store state, network conditions during resolution, or genuine non-determinism in pnpm dedupe --check all remain open, and I am not publishing a mechanism I have not measured.

⚠️ One limit on the headline, stated rather than buried: 1 red in 5 is a rate, not a proof of randomness. What five runs establish firmly is that byte-identical input produced both verdicts — enough to rule out "the lockfile drifted" and enough to make the gate's own remedy dangerous. ⛔ Not enough to characterise the distribution.

⛔ Two artefacts of my own handling, so nobody inherits them as data

1. The failure record on af0342ce68 is gone from the obvious query. My re-run of that head was itself cancelled, so "latest Test (shard 1/4) per head" now reports cancelled there and loses the red entirely. The failure survives only as job 104253580434 in run 34929173668. ⇒ anyone rebuilding the table above from head state will not see it; read it by job id.
2. objectui#9562's title shipped mangled and has been repaired. I wrote the card's title inside a double-quoted python3 -c string containing backticks, and bash command-substituted them — the title lost its own subject and read "[finding] is a BLOCKING gate…". ⚠️ This is a trap this lane had already recorded, with a rule attached (write anything containing backticks through a quoted heredoc, never -c "…"), and I did not follow my own rule. Repaired via heredoc and verified byte-equal to the intended string.

Where this PR stands

Green at its head, with B1, M1 and L1 repaired and L2 withdrawn as my fabrication. A targeted re-check is in flight; ⛔ gates ①②③ are taken at the landing head after it returns, never carried forward from this comment.

---

Generated by Claude Code

[claude]

Contract review

Verdict: PASS — head judged 5c08bc89661175521cd2377056106d66bf5f5be5, merge-base with origin/main = 40f34b4ba77bddd9d7a56a3527f8fa6c3e1e4e50 (i.e. main is fully contained: git rev-parse origin/main matched the PR's base.sha, and git rev-list --count origin/main ^HEAD → 0).

Implemented-by: claude/issue-6939-filter-builder-catalog-operator-spellings
Reviewed-by: session_01L5xpA5q533BgTTNADibEFt

Targeted re-check of the four findings in 5674626912, plus the six items the dispatch named. Fresh --no-hardlinks clone in my own scratchpad, origin re-pointed at the real remote and re-fetched before any merge-base gate; heavy runs through scripts/pm/os-verify-lock.sh (OS_VERIFY_LOCK_SLOT=objectui-9558-review-r2), every one VERDICT command-exit read from the wrapper's own line. ⛔ I took no after-number on trust — B1 was re-opened by rebuilding the defect, not by re-reading the fix.

---

B1 — the PRESERVED identity legs · RESOLVED, and I built the degenerate case myself

⭐ The load-bearing measurement is not that the repaired pin reddens. It is that the same mutation, on the same disk, against the pin blob one commit earlier, still goes green — so the guard, and nothing else in the round, is what closes the hole.

Mutation in every run below: revert only the three catalog data files to the alias dialect by checking out their b7479abc74 blobs (verified byte-identical to origin/main, so the mutation is the dialect and nothing else). Harness carries trap … EXIT INT TERM with an absolute repo root, aborts with a void reading unless the anchors land, and restores with git checkout HEAD -- <absolute path>.

proof	reading
mutation reached disk	sha256sum before → after on all three: f0d12b9aa947518b→758089b6d85ef6a1, 7ac6de0c3f466297→d75811875af32c39, 5f8e78c2aa402fae→cd4f1741caef234f; anchors canonical=7 alias=0 → canonical=0 alias=7; cmp -s against a pristine copy differs on all three
restore was byte-identical	cmp (which localises the first differing byte, and printed nothing) against the pristine copies for all four touched files, sha256 back to the four values above, git status --porcelain empty after every leg

The degenerate case, reconstructed:

pin blob	-t PRESERVED, same mutation	verdict
3bcecc4095 (pre-repair)	Tests 7 passed | 14 skipped (21)	⛔ the hole, reproduced by me — the identity legs pass on an identity transform
5c08bc8966 (this head)	Tests 3 failed | 4 passed | 14 skipped (21)	⭐ closed — the three reds are the identity legs, failing expected 'eq' not to be 'eq' / expected 'gt' not to be 'gt', the same shape the NEW-direction twin fails with

The four greens that remain are the three and no operator cell is blank legs and the identity legs can fail, exactly as the body says, and for the reason it gives: those measure the authored corpus only, or derive their table.

And I went looking for a second way through, because the new guard is per-row over beforeOps and a zero-row corpus would satisfy it vacuously. Probe: set value.conditions to [] in all three entries ("operator" occurrences 7→0, same-subject control "conditions" still 5, so the edit landed). Result: Tests 7 failed | 14 skipped (21) — all seven PRESERVED legs redden, the identity legs on expect(authored.operatorTriggers.length).toBeGreaterThan(0). ⇒ the zero-row route is closed too. Restored, git status --porcelain empty.

Full three-file mutated run at this head: Tests 25 failed | 56 passed (81). Unmutated at this head: Test Files 3 passed (3) / Tests 81 passed (81).

The prediction miss — checked against the failure list, not the prose · the dev's account holds

The dev predicted 24 / 57 and measured 25 / 56, root-causing the extra red to its own M1 rewrite. I did not take that root-cause on its word; I ran the same mutation against the pre-repair pin, captured both verbose failure rosters, and diffed the names:

comm -23 fail25.txt fail21.txt   # reds at this head that were not reds pre-repair

→ exactly 4, and they are:

1. NEW … .success is not vacuous — an invented operator is refused
   2-4. PRESERVED … {product-search, search-interface, with-conditions}: as authored renders exactly as the alias arm did

comm -13 the other way → 0: no red disappeared. The pre-repair roster is 21, this head's is 25. So the prediction of 24 assumed three new reds (the identity legs) and missed the fourth, and the fourth is precisely the invented-operator leg — which fails on the M1 rewrite's new line, expect(operatorsOf(bogus)).not.toEqual(operatorsOf(asAuthored(…))), with expected [ 'eq', 'lt', 'gt' ] to not deeply equal [ 'eq', 'lt', 'gt' ]. ⭐ Worth naming: that leg was also vacuous pre-repair under this mutation — it went green off the alias corpus's own refusal, not off the invented payload — so M1's rewrite closed a second instance of the same class as a side effect. The account is accurate against the roster.

M1 — the absent-token control · RESOLVED

Corpus stated: all tracked files, pathspec . — 7812 tracked files at this head, 7810 on origin/main, 7803 at b7479abc74. Occurrences git grep -o … | wc -l, files git grep -l … | wc -l.

token	b7479abc74	3bcecc4095	origin/main	this head
qqzz_absent_token_9999	0 / 0	3 / 1	0 / 0	0 / 0
filter_builder_6939_invented_operator	0 / 0	0 / 0	0 / 0	1 / 1

⇒ the lane's control is handed back clean, and the replacement was genuinely absent everywhere before it was written. Its single occurrence is the const INVENTED on line 213 of the new pin. Controls for those zeros, same instrument and same corpus: same-subject firing control FilterOperatorSchema 24 occurrences / 15 files at this head (16 / 12 on origin/main); my own clean absent-token control — ⛔ not zzqx_no_such_key (polluted, 6 / 3) and ⛔ not qqzz_absent_token_9999 (itself under test) — is wkzv_review_control_20260915, proven 0 / 0 at all four refs before I used it.

The pin also asserts expect(DECLARED_OPERATORS).not.toContain(INVENTED), so that refusal leg cannot go green on a payload the mirror happens to accept.

L1 — the corpus figure · RESOLVED, and the .json subset is measured rather than assumed

git ls-tree -r --name-only <ref> -- examples/ | wc -l, and the same piped through grep -c '\.json$':

ref	tracked under examples/	of which .json
b7479abc74	500	443
origin/main	500	443
3bcecc4095	501	443
this head	501	443

The body's "501 … 443 of them .json" and "443 at the base and 443 at this head, checked rather than assumed" both reproduce. The 501st is this branch's own new pin file; the .json subset every count in the table is drawn from does not move.

L2 — the clause-② clearance claim · DID NOT REPRODUCE. The dev is right, and so is the dispatch's own retraction.

⚠️ How I handled the trap first, because the current body quotes the strings it counted. A naive count over the body as it stands now reads non-zero — check-clause2-carriers 1, clearance 2, PM_SWEEP_REPO 1, scripts/pm 1 — and every one of those occurrences is inside a single bullet. I localised that bullet by its own bytes rather than by eye: it is the range [1419, 2511) of the 19434-character body, from - ⚠️ **Did not reproduce:** to - **Base merge**. Excise exactly that range and the same instrument over the remaining bytes reads 0 / 0 / 0 / 0, while the firing controls on those same remaining bytes still fire — Clause-② 1, Implemented-by 1. ⇒ the trap is fully contained in the paragraph that declares itself, and outside it the only clause-② text in the live body is the declaration.

But the question is about the body at 3bcecc4095, so I went and got those bytes. ⛔ GitHub's REST API exposes no body revision history, and the GraphQL userContentEdits route that does is refused from this seat — measured, POST /graphql → HTTP 403, "GitHub GraphQL is not available from Claude Code sessions; use the REST API". What I judged instead is an on-disk full GET /repos/objectstack-ai/objectui/pulls/9558 capture whose own head.sha field reads 3bcecc4095abf5bf4c388a68f890c1318dabccdd. ⛔ A stray file is not evidence, so I corroborated it on four independent points before relying on it:

1. its head.sha is the judged head and its base.sha (009f92d7a2…) is the base recorded in the prior verdict's own timestamped table;
2. all three passages the prior verdict quotes verbatim from the body resolve in it under whitespace normalisation (the body is hard-wrapped, so a raw grep -F misses them) — "the clean absent token …returns 0 occurrences in 0 files" 1, "the alias corpus renders exactly what the repaired corpus renders" 1, and the corpus sentence, which reads there as *Corpus for every count below: *500 tracked files under examples/ (443 of them .json );
3. all three are 0 in the current body — i.e. the capture is the pre-repair revision, not a copy of the live one;
4. its size, 12231 bytes / 206 lines, matches the figure the dev independently published for the bytes it measured.

On those bytes, grep -o … | wc -l:

reading on the body at 3bcecc4095 (12231 bytes, 206 lines)	occ
check-clause2-carriers	0
clearance	0
PM_SWEEP_REPO	0
scripts/pm	0
widened net: clause, carrier, cleared, clear, PM_SWEEP, check-clause	0 each
firing control Clause-②	1
firing control Implemented-by	1
firing control Fixes #6939	1
clean absent-token control wkzv_review_control_20260915	0

grep -n 'lause\|②' over that body returns exactly one line — line 197, which reads Clause-②: no — three data files move into an already-declared accepted set. That is the declaration, which is the dev's to make and which is correct.

My independent ruling. No clause-② clearance claim has ever existed in that PR body. Nor anywhere else it would have been owed from — measured on the branch's other artifacts, each with a control that fires:

• the 5 commit messages 40f34b4b..HEAD (3557 bytes): check-clause2-carriers 0, clearance 0, PM_SWEEP_REPO 0, scripts/pm 0, Clause-② 0 — control filter-builder 4;
• the 9 changed files at this head: all four strings 0 — control operator 182;
• the changeset: no clause-② text at all;
• card 24 catalog entries fail safeValidateSchema because the Zod mirror names a key its renderer never reads (8 components) #6939, body + all 29 comments reconciled against the endpoint's own comments total (216863 bytes): check-clause2-carriers 3 and clearance 1, and I attributed every one of them by byte offset to its enclosing comment — all four are inside the dev's own round-2 report 5674998329, reporting this very non-reproduction. Control 6939 78; absent-token control 0.

⇒ the string existed on this PR only in the review comment 5674626912, the dispatch 5674660651 and the correction 5674668282 — seat-side, never branch-side. Reading the prior verdict's G-a on its own terms, it says the bare invocation is not evidence and then re-takes the reading itself; its one sentence about the body is that Clause-②: no is declared there, which is true. G-a also never appears in that verdict's own "What would turn this green", which lists only the guard, C2-a and C2-b. ⇒ nothing was ever owed here, the dev correctly refused to delete a sentence that did not exist, and recording the non-reproduction in the body — with the bytes it was taken over named, so the count does not read as live — was the right disposal.

⭐ And the exit-code half, taken myself from /home/user/objectstack, each capture cmd > out 2> err; EXIT=$? with ⛔ no pipe between command and status:

run	exit	printed
node scripts/pm/check-clause2-carriers.mjs --pair 9558 (bare)	2	…read from objectstack-ai/objectstack (source: default…) then PR #9558 is not open, or names no card this file can derive … ⛔ Not a clearance — the pair could not be formed, so nothing about it was judged.
PM_SWEEP_REPO=objectstack-ai/objectui node … --pair 9558	0	✓ … PR #9558 / card #6939 — the clause-② declaration is readable in the fixed spelling and both carriers agree, and its diff carries no widening tell.

⇒ the prior verdict's "exits 0 while judging nothing" is wrong on this container; the correction in 5674668282 is right, and the script cannot hand back a false green here. The carrier gate itself is green at this head, and both carriers agree.

---

The rest of the dispatch's list

5 · Nothing else moved. git diff --name-only 40f34b4b HEAD | wc -l → 9; | grep -c 'pnpm-lock.yaml' → 0 against a control on the same listing (grep -c 'filter-builder' → 9). pnpm-lock.yaml is byte-identical at b7479abc74, origin/main and this head (blob 4e9543088b320a96f1ae7889f8dfaf59a1ec28ad at all three) and appears in 0 paths of git diff --name-only b7479abc74 5c08bc8966 -- pnpm-lock.yaml. Round 2 touched exactly one file: filter-builder-operator-vocabulary-6939.test.tsx, 28 insertions / 4 deletions — B1's guard and M1's payload, nothing else. Enum untouched by blob identity, not by diff emptiness: packages/types/src/zod/complex.zod.ts = 73bc7dc5cf0bc6d1f9bdc848f80a09b19233b7f8 and packages/types/src/complex.ts = b9e15f920893372749d3fd7dd93b4d075ebe0d69 at base, origin/main and this head. ⛔ No member added.

Both base merges intersect this branch's files in zero paths, measured per merge from its own merge-base, not asserted: abb2eccdb8 (second parent 5495b8de70) brought 17 files, 5c08bc8966 (second parent 40f34b4b, = origin/main) brought 5; comm -12 against the 9 → 0 and 0. Control on the same instrument: comm -12 of each list with itself → 17 and 9. Neither merge carries conflict-resolution content of its own (git show --cc --name-only empty for both).

6 · The merge was performed, not simulated. Head is a true merge commit (3 entries from git rev-list --parents -n1), f36f2ad26d, 3bcecc4095, abb2eccdb8 and af0342ce68 are all ancestors of it (no rebase, no force-push), and origin/main is fully contained. My own reading on that tree, after pnpm install --frozen-lockfile (lockfile untouched) and turbo run build (Tasks: 29 successful, 29 total):

command	reading
vitest run --maxWorkers=2 examples/schema-catalog/ packages/types/	Test Files 223 passed (223) / Tests 6702 passed (6702)
vitest run --maxWorkers=2 packages/components/src/__tests__/filter-builder*.test.tsx (shell-expanded; pathspec = 12 files)	Test Files 12 passed (12) / Tests 254 passed (254)

223 / 6702 reproduces exactly.

CI at this head, reconciled against the endpoint's own total_count: 36 of 36 check runs accounted for — 33 success, 3 skipped, 0 red. Type Check, Lint, all four Test (shard n/4), Control Byte Scan, Line Citation Gate, Changeset Declaration and Governed Surface Queue Guard are all green, and no check-lockfile-dedupe run is present at this head at all. ⇒ the dedupe matter is not visible here and is not this PR's to absorb.

---

New finding

⚠️ N-1 (MINOR) — the guard is per-row, so it false-reds on a legitimate future catalog edit. Measured, not read off the source. Append one ordinary condition spelling a declared member to with-conditions.json:

{ "id": "3", "field": "name", "operator": "contains", "value": "ada" }

The entry still validates and still renders — validates as authored and every authored operator is a DECLARED member both stay green — and yet 4 assertions across 2 files go red: the repaired PRESERVED … as authored renders exactly as the alias arm did on expected 'contains' not to be 'contains', its NEW-direction twin ⛔ the alias dialect it used to author is still REFUSED, and two legs of the re-aimed filter-builder-operator-alias-trigger-7561 pin. FORMER_ALIAS keys only equals / greater_than / less_than, so any fourth spelling falls through and the per-row expect(afterOps[i]).not.toBe(op) reddens on a row the author did nothing wrong to. The message names the guard, not the edit, so the next author reads it as "contains is not allowed", which is false.

⭐ Why this does not block: it is fail-closed, not fail-open, and it is pre-existing — the NEW twin and the 7561 pin already behaved this way before round 2; the repair made PRESERVED symmetric with them rather than introducing the class. Worth recording because the repair widens the blast radius by one more leg, and because there is a concrete alternative with the same B1 coverage and less brittleness: the dev's own probe shape, whole-array expect(afterOps).not.toEqual(beforeOps), still reddens under the alias mutation (all three rows fall through ⇒ arrays equal) but survives the contains append. The trade-off against per-row is consistency with the twin, so this is a judgement call for the dev, ⛔ not a defect I am asserting.

(Restored after the probe: sha256 back to 5f8e78c2aa402fae, git status --porcelain empty.)

What I could not measure

• The live 3bcecc4095 body as GitHub would serve it. REST carries no body revision history and GraphQL userContentEdits is refused from this seat (HTTP 403, measured). My L2 ruling rests on the corroborated on-disk capture described above. Strictly, it cannot exclude a body edit between that capture (updated_at 2026-09-15T03:44:36Z, taken 03:48Z) and the verdict at 04:13Z; for the finding to have been real, such an edit would have had to insert a clearance sentence into a body whose byte count then still matched what the dev independently measured. I judge that excluded on the evidence, and name the gap rather than paper it.
• Not re-taken this round (carried from the prior verdict, which PASSed them, and not re-opened by the 28-line round-2 diff): the objectui check 632-file bucket split 3→1, the check:* gate roster (check:control-bytes 7727 text files, check:doc-example-ids 414, regenerate:check 432 entries), the turbo run type-check / lint task counts and warning figures — CI's own Type Check and Lint are green at this head — and the FILTER_BUILDER_OPERATORS 22 / 3 / 19 reading.
• Whether this PR should land — ⛔ not this seat's call.

⛔ No label hung or removed, ⛔ no draft flip, ⛔ no enqueue, ⛔ no auto-merge, ⛔ no approval review, ⛔ no file, body or card edited.

---

Generated by Claude Code

[claude]

Enqueued — three of three at 5c08bc8966, PASS accepted, N-1 dispositioned

Read and written 2026-09-15T05:30–05:31Z by domain:spec @ objectui, os-sam, session session_01L5xpA5q533BgTTNADibEFt. Verdict of record: 5675242885, PASS.

#	gate	reading	at
①	declared head == pulls/9558.head.sha	5c08bc89661175521cd2377056106d66bf5f5be5 both sides, full 40-character string equality	05:30:39Z
②	PM_SWEEP_REPO=objectstack-ai/objectui node scripts/pm/check-clause2-carriers.mjs --pair 9558	exit 0 — declaration readable in the fixed spelling, both carriers agree, no widening tell	05:30:39Z
③	pre-flip	36/36, {success: 33, skipped: 3}, 0 not-green, 0 running, legacy success, mergeable_state: clean	05:30:39Z
③	re-taken post-flip	37/37, {success: 34, skipped: 3}, 0 not-green, 0 running, legacy success, head unmoved	05:31:28Z

The 37th check is the guard's second run, 05:30:57 → 05:31:10Z — 13 s, inside the 11–28 s band. added_to_merge_queue is on the timeline at 05:31:43Z.

Why this review is worth reading even though it passed

It did not accept the after-numbers. It rebuilt the defect: the same alias mutation against the pre-repair pin blob still gives 7 passed | 14 skipped, so the guard — and nothing else in the round — is what closes the hole. Then it hunted a second way through, since a per-row guard is vacuous on a zero-row corpus, and closed that too (conditions: [] reddens all seven legs). It verified the dev's prediction-miss account by name-diffing the failure rosters rather than reading its prose: exactly 4 new reds, 0 disappeared.

On L2 it ruled independently and went past what was asked — recovering the pre-repair body bytes, corroborating that capture on four points before relying on it, and then checking every other place a clearance could have been owed from: commit messages, the 9 changed files, the changeset, and card objectui#6939's body plus all 29 comments, attributing each hit by byte offset. All seat-side. ⭐ And it named the gap it could not close: REST serves no body revision history and GraphQL userContentEdits is refused from this seat (HTTP 403, measured), so the ruling rests on a corroborated capture rather than on the bytes GitHub would serve. That is the right way to report a limit.

N-1 — recorded, not repaired, and here is the reasoning

The new guard is per-row, so appending one legitimate condition spelling a declared member ("operator": "contains") leaves the entry validating and rendering while reddening 4 assertions across 2 files, with the misleading message expected 'contains' not to be 'contains'.

Disposition: Acceptance notes, no card, no fifth round. Three reasons, in order of weight:

1. It is fail-closed. A future author gets a red they must investigate, ⛔ not a silent pass. That is the opposite of the class this PR exists to close.
2. It is pre-existing, not introduced: the NEW-direction twin and the objectui#7561 pin already behaved this way. The repair makes PRESERVED symmetric with its siblings; it widens the blast radius by one leg rather than creating the shape.
3. The alternative the reviewer offers (whole-array not.toEqual) closes B1 identically and survives the append, but costs consistency with the twin — a genuine trade-off, which the reviewer explicitly framed as a judgement call and ⛔ declined to assert as a defect. ⛔ Rolling a fifth round to swap a guard for its sibling's shape, on a p2 card already two rounds deep, is scope creep.

⚠️ Carrier named, so this is not a silent drop: whoever next edits the filter-builder catalog pins meets it, and the verdict above carries the reproduction and the alternative in full.

⭐ Contrast with the sibling PR objectui#9555, where I did take another round for a MINOR: that one shipped, on a customer-facing docs page, and was false. This one is test-only, fails safe, and is a trade-off rather than an error. The difference is what the finding does to someone who is not in this thread.

Queue transit has been 18.5–20.5 min over eleven readings, so a merge is expected around 05:50–05:52Z — a range this seat keeps re-measuring, ⛔ not a promise.

---

Generated by Claude Code