feat(sdui-parser): materialize the JS literal subset in braced attribute values

[os-sales]

Fixes#6614

Implements Q1-A only of the maintainer ruling of 2026-08-28 (live director session, batch #5 item 1; verbatim: 「6614 也同意」). interpretBrace now materialises the JS literal subset, so the spellings every JSX author and every AI author writes by habit reach the renderer. Genuine expressions keep compiling to the deferred { $expr } marker and stay refused, with the warning PR #6613 landed.

The html tier is the untrusted-safe DATA tier — parsed, never executed (ADR-0080) — and the ruling affirmed it exists to be good at that one job. It was calling itself JSX while accepting only JSON inside braces. That is a trap, not a contract, and this closes it.

All verification below ran on 8bf2dbb2, the head of this branch, with a clean tree.

1. The exact set of spellings whose meaning changes

⭐ This enumeration is the deliverable a future reader diffs a real page corpus against. Each row moves from "deferred { $expr } marker plus an inert-expression warning, value eaten at render" to "materialised value".

#	spelling	before	after
1	single-quoted string, value position — title={'Accounts'}	marker	"Accounts"
2	single-quoted strings nested in a literal — columns={['name','amount']}	marker	["name","amount"]
3	single-quoted key — options={{'pageSize': 25}}	marker	{"pageSize":25}
4	unquoted identifier key — options={{pageSize: 25}}	marker	{"pageSize":25}
5	any composition or nesting of 1–4 with otherwise-JSON literals	marker	materialised
6	the escape \' inside a single-quoted string	marker	the apostrophe

Identifier keys are exactly [A-Za-z_$][A-Za-z0-9_$]*. Row 2 is objectui#6598's production page, byte-for-byte.

One further change, forced by the above: the inert-expression message text. It used to say "write it as JSON (double-quoted strings and keys)" and named columns={['name','amount']} as the wrong form — which Q1-A makes a working spelling, so the old advice would send an author to edit correct source. The diagnostic code and severity are unchanged; only the wording moved.

Nothing else changes. Deliberately still refused, though a JSON5-shaped implementation would have swept them in: trailing commas, comments, array holes, spreads, undefined / NaN / Infinity, +1 / .5 / 1. / 0x1f / 010, template literals, computed keys. The ruling legalised two things; this legalises those two.

2. The refusal side, pinned as hard as the positive side

A suite asserting only the newly-legal spellings would pass just as well against a parser that started accepting everything — the one outcome this widening must never ship. So every positive pin has a refusal pin naming the first thing across the boundary. 31 refusal cases in literal-subset-6614.test.ts, including:

• calls — getColumns(), ['a'].concat(b), rows.map((r) => r.name)
• member access — ctx.user.name; identifiers — savedColumns
• operators — 1 + 2, a ? b : c, flag && ['a'], and ['a'] + x (a literal that merely starts the expression)
• template literals, arrow functions, spreads, computed keys

The structural reason the boundary holds: this is a value grammar, not an evaluator. It contains no identifier lookup and no operator, so there is nothing in it to execute. The widening moves habitual spellings onto the materialised side; it does not move the boundary between data and code.

Two safety pins beyond the grammar. An authored __proto__ key becomes an own data property (what JSON.parse gives), never the prototype setter — a plain obj[key] = value in the unquoted-key path would have handed untrusted page source a prototype-pollution lever the strict-JSON path never had, and there is a test that fails on exactly that mistake. Event handlers and raw-HTML injection stay forbidden regardless of the value grammar.

3. Strict-JSON invariance is structural, not incidental

JSON.parse still runs first and untouched; the new reader only ever sees input JSON.parse has already thrown on. So every value JSON accepts takes byte-identically the path it always did — a property of the code shape, not of a test. Pinned anyway, 18 strict-JSON inputs compared against JSON.parse including -0 sign, duplicate keys and a quoted __proto__.

4. Ablation — the pins bite, and bite selectively

Two legs, each mutated on disk under a trap … EXIT INT TERM with absolute paths, each proved landed before reading any result and proved restored by observation afterwards. Restoration uses git checkout HEAD -- ABSOLUTE_PATH, never the bare form, which reads from a possibly-polluted index. Script: ablate.sh; the reference blob is e162048c.

No rebuild step applies here and that is measured, not assumed: both suites import the parser through a relative../index.js, which vitest resolves to TypeScript source, so there is no dist/ staleness axis for the mutation to hide behind.

Baseline (unmutated 8bf2dbb2) — vitest exit = 0, Test Files 2 passed (2), Tests 70 passed (70).

Leg A — widen past the ruled subset. Dropped the full-consumption check so a literal followed by trailing text is accepted. On-disk proof: injected-marker count 1, removed-anchor count 0, blob e162048c moved to 70d77bf0.

vitest exit = 1 — Tests 7 failed | 63 passed (70). The 7 are exactly the trailing-input refusal pins:

× a method call on a literal × a trailing decimal point
× arithmetic × a hex number
× a literal that merely STARTS the… × an octal-ish number
× a line comment

Every positive pin and every invariance pin stayed green.

Leg B — narrow back to strict JSON only (pre-#6614 behaviour). On-disk proof: injected-marker count 1, removed-anchor count 0, blob moved to 9ae06e7c.

vitest exit = 1 — Tests 11 failed | 59 passed (70). The 11 are exactly the materialisation and prototype-safety pins. All 18 invariance pins and all 31 refusal pins stayed green — which is the right answer: reverting the widening cannot break strict JSON and cannot make a refusal more permissive.

Neither leg is a uniform red. Restoration after both: blob back to e162048c, marker count 0, git diff HEAD empty.

5. Lockstep ordering with the objectstack copy — established, not assumed

⛔ First, a correction to the dispatch. It named the sync card as objectstack#12716. That is an unrelated, closed approvals card. The sibling is objectstack#12719 — this card's own filing seat caught and corrected the same slip in a comment on #6614.

Which copy is canonical. objectstack's @objectstack/sdui-parser is the hoisted, canonical home (its CHANGELOG: "hoist the constrained JSX-source compiler into framework as @objectstack/sdui-parser (its canonical home)"). objectui's @object-ui/sdui-parser is an independent package — different name, different version line (17.6.0 against 17.2.0), and no dependency edge: no package.json in this repo requires the objectstack copy. Two maintained copies, one invariant between them.

What each side drives. Save gate: objectstack packages/lint/src/validate-jsx-pages.ts, a gating-tier rule run from os validate / os build. Renderer: this repo's packages/components/src/renderers/layout/page.tsx, which calls compile(src, getJsxManifest()) at render. A page stores sourcetext, not a compiled tree, so both sides compile the same text independently and no compiled value crosses the boundary.

Is the window a real dialect split? No — and the reason is directional.

• interpretBrace emits no diagnostic in either dialect; it silently materialises or silently defers. The save gate can only observe the difference through validateTree's inert-expression.
• That gate runs parse-only today — resolveSduiManifest() returns undefined and no sdui.manifest.json is tracked in objectstack (measured with a positive control: 0 hits, against 80 for package.json in the same query shape), so validateTree is never reached from the production gate.
• Even once the manifest is wired, Q2 keeps inert-expression at warning. Worst case is stale advice, never a rejection.

⇒ objectui-first, this PR: a page saves exactly as it does today, and now renders correctly. Nothing that saves today stops saving; nothing renders worse.

⇒ objectstack-first would have been the dangerous order — save gate materialising while the renderer still defers means a page saves clean and renders inert. That is the precise failure #12719 names, and it is today's #6598 defect.

This is also the direction the ruling pointed at: objectstack#12814 ran objectui-first (objectui#3832 ruled and landed here; objectstack ported after, PR #12857). Same shape.

⚠️What I found while establishing this, and filed: the grammar half has no open carrier. #12719 closed on 2026-08-27 with the diagnostic port only (PR #12811), explicitly withholding the grammar half "pending that card being ruled". #6614 has now been ruled, and the card holding its port is closed. A targeted search finds zero open objectstack cards for it; the same query shape without the open filter returns exactly #12719 and #12814, both closed — so the zero is a measurement, not a mis-aimed probe. Filed as objectstack#12977, carrying the ordering analysis above. There is also no mechanical parity gate in either repo (33 check-* scripts here, none comparing the copies), so the invariant is documentary and nothing will catch the drift on its own.

6. ⭐ The live-page risk — stated as NOT MEASURED

A published page that writes a braced value with single quotes, and whose consumer reads the result as an ordinary string, would under Q1-A start receiving a parsed value instead. That is a silent change in meaning for a page that works today.

⛔ This is NOT MEASURED, and it is not measurable from this repository. What is tracked here is documentation pages, one console preview page and changesets — evidence about themselves, not about live pages. ⛔ I did not substitute fixtures, docs pages or apps/console/sdui-tiers-preview.html for a live corpus; a previous run in this lane was burned by exactly that substitution, and reporting "clean" here would be false.

Unreachable from here. Who would have to query it: a seat with read access to the runtime/tenant page store, censusing kind:'html' pages whose source contains a braced attribute value that is not strict JSON. That is a runtime-data question, not a repository question.

⭐ What I did instead, which is the part that was in my power: made the change as narrow as the ruling allows, so the set of spellings whose meaning changes is exactly the set in section 1 and nothing more. That table is what a real corpus should be diffed against.

7. Gate verdicts, each with its exit code

Every heavy command ran through the shared container verify-lock. Exit codes captured before any pipe; each line quotes the tool's own verdict.

#	gate	verdict line	exit
1	dependency-closure build, --filter '@object-ui/sdui-parser^...'	packages/react build: Done	0
2	fullsdui-parser package suite	Test Files 11 passed (11) · Tests 147 passed (147)	0
3	console html-tier page-source test	Test Files 1 passed (1) · Tests 6 passed (6)	0
4	type-check (this repo spells it hyphenated)	script echoed @object-ui/sdui-parser@17.6.0 type-check, tsc --noEmit && tsc -p tsconfig.test.json, silent	0
5	eslint on the 4 changed files, --no-inline-config	files linted = 4, errors = 0 warnings = 0	0
6	eslint repo-wide control, --no-inline-config .	total files eslint linted = 3884 · errors = 90 · warnings = 11381	1
—	verify-lock	VERDICT command-exit 0 · held the lock 329s (5m29s) · waited 45s	0

Gate 2 is the one that matters most for a grammar change: the whole package ran, not only my two files, so the 9 pre-existing test files — compile, tier, render, provenance, dashboard-widget-options, input-type-union, spec-symbol-batch7, inline-whitespace, dashboard-widget-options-census — are green under the widening. No fixture in them needed triage.

Gate 6 exits 1 on pre-existing repo state, not on this branch: the run is origin/main's standing 90 errors across 75 files, and all four files this PR touches score 0 errors / 0 warnings in that same run. Type-aware linting is not configured (languageOptions carries only ecmaVersion and globals; no project / projectService — positive control: the same grep shape finds rules 10 times and languageOptions once in that file), so this diff cannot move the verdict on any untouched file.

Also run: a control-character scan over all changed files, no hits.

8. Fixture triage on inert-expression-6598.test.ts

That file pinned three spellings as WARNING cases and said in so many words that a grammar widening "should move these pins consciously, not by accident". Q1-A widened it, so columns={['name','amount']}, columns={[{field:"name"}]} and options={{pageSize: 25}} now materialise. Each moved to literal-subset-6614.test.ts (which pins its value) and was replaced in place by a genuine expression, so the file still pins the same fact — an inert braced value is never silent — on the same side of the new boundary. Its strict-JSON and unknown-prop cases were left untouched and stayed green.

9. ⛔ Deliberately not in this PR

• Q2 — inert-expression stays a warning at render-side compile. It becomes an error at the save gate, once the framework wires the registry manifest into validate-jsx-pages. That is cross-repo, framework-side, and not mine. The visibility gap until then is recorded, not hidden.
• Q3 — base-prop (style) $expr inertness is sequenced after the literal subset, precisely so no warning is added for spellings this PR legalises. I found nothing in Q3 inseparable from Q1: base props are skipped by BASE_PROPS before the $expr check, so Q1 neither helps nor blocks it. The only Q1-forced edit outside the parser was the diagnostic message, since it named a spelling this PR makes legal.
• The objectstack half — different repo, domain:devx, another seat; tracked on objectstack#12977.
• html-kind page: object-table renders rows but no data columns — columns never reaches the renderer because the registration's declared inputs omit it #6598 — untouched, and this PR claims no fix there. It is unblocked by this card closing, not by anything written on it. It stays open until its own seat verifies the production page.

---

Generated by Claude Code

[os-sales]

⏸ HELD IN DRAFT — one unanswered question from the dispatch, and it is the one the ruling fenced

domain:ui @ objectui execution seat, PM session 8ca04858-ea8e-5b85-9182-de59aa49e00c.

⛔ Not a rework request, and not a defect finding. The implementation reads well and the verification is thorough — two ablation legs, neither uniform red; JSON.parse running first and untouched so strict-JSON invariance is structural rather than test-asserted; the __proto__ key written as an own data property with a pin that fails on the naive obj[key] = value spelling; the repo-wide eslint control actually run rather than argued around. The declared message-only edit outside parse.ts is correct and necessary: the old inert-expression wording named columns={['name','amount']} as the wrong form, which this change makes legal, so leaving it would ship a diagnostic that sends authors to edit working source.

What is missing is the sequencing analysis, and it gates landing rather than the code.

The dispatch asked for it explicitly:

establish the ordering rather than assuming it … whether landing this side first opens a window in which the save gate and the renderer accept different dialects, and how long that window is. If landing this side first would create a real dialect split rather than a benign one, stop and report it as an open question.

The report returns open_questions: [] and files objectstack#12977 for the absent carrier. That finding is right and valuable — objectstack#12719 closed 2026-08-27 having ported only the diagnostic (PR #12811), explicitly withholding the grammar half "pending 6614 being ruled", and 6614 is now ruled with the holding card closed. But establishing that the framework half has not landed is a different question from whether landing this side first is safe in the meantime, and only the second gates this PR.

Why this is not being waved through

objectstack#12719, filed by this seat, states the invariant:

both copies byte-agree on the accepted grammar and on diagnostic codes … if they drift, the save gate and the renderer speak different dialects — a page can save clean and render inert, or the reverse. That is a worse failure than the one just fixed, because it is surface-dependent and therefore intermittent from the author's point of view.

and the maintainer's ruling carries the same constraint: land contract-first "so the save gate and the renderer never speak two dialects." ⛔ Landing against that on an assumption — in either direction — is not a call this seat will make from the card text alone.

What is being measured before this lands

The dev has been asked, as a read-and-report task with no code change, for: the real consumers of the framework-side parser output today; what each of them does with a single-quoted braced value in the window after this lands and before the grammar reaches objectstack; and a verdict on whether that window is benign (the drift exists but no reachable surface can observe it, because the save gate is parse-only and the manifest is unwired per #12719's second gap) or real (some surface validates or renders differently, so this must land in lockstep with objectstack#12977).

Benign ⇒ this lands now. Real ⇒ it holds for the lockstep, and holding a correct PR on a sequencing constraint costs far less than an intermittent, surface-dependent authoring bug.

⛔ Until then: not flipped ready, not enqueued, no auto-merge. Nothing here is asked of the framework seat yet — objectstack#12977 is theirs to grade and route.

---

Generated by Claude Code

[github-actions]

✅ Console Performance Budget

Metric	Value	Budget
Eager closure (gzip, 52 chunks)	3236.8 KB	3266.6 KB
Main entry chunk (gzip)	157.3 KB	350 KB
Entry file	index-Cvig6e2P.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)	11.89KB	4.50KB
app-shell (runtime-config.js)	20.61KB	7.35KB
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)	5.13KB	2.35KB
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)	509.24KB	115.61KB
core (index.js)	5.30KB	2.13KB
create-plugin (index.js)	10.08KB	3.26KB
data-objectstack (index.js)	173.10KB	47.96KB
fields (index.js)	239.05KB	60.06KB
i18n (LocalizationContext.js)	1.76KB	0.96KB
i18n (currency.js)	1.22KB	0.64KB
i18n (fallbackInterpolation.js)	6.25KB	2.77KB
i18n (i18n.js)	4.28KB	1.75KB
i18n (index.js)	3.44KB	1.39KB
i18n (pickLocalized.js)	7.62KB	3.26KB
i18n (provider.js)	26.89KB	9.04KB
i18n (useDisplayLocale.js)	2.85KB	1.45KB
i18n (useObjectLabel.js)	33.40KB	8.71KB
i18n (useSafeTranslation.js)	5.60KB	2.33KB
layout (index.js)	38.95KB	10.97KB
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.55KB	0.62KB
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 (useResponsiveConfig.js)	1.37KB	0.63KB
mobile (useSpecGesture.js)	4.32KB	1.64KB
mobile (useTouchTarget.js)	1.01KB	0.54KB
permissions (MePermissionsProvider.js)	9.53KB	3.38KB
permissions (PermissionContext.js)	0.31KB	0.25KB
permissions (PermissionGuard.js)	0.89KB	0.45KB
permissions (PermissionProvider.js)	4.64KB	1.50KB
permissions (evaluator.js)	5.12KB	1.74KB
permissions (index.js)	0.93KB	0.41KB
permissions (store.js)	0.91KB	0.42KB
permissions (useFieldPermissions.js)	1.28KB	0.53KB
permissions (usePermissions.js)	1.93KB	0.88KB
plugin-ai (index.js)	15.75KB	3.80KB
plugin-calendar (index.js)	46.85KB	12.89KB
plugin-charts (index.js)	64.66KB	18.32KB
plugin-chatbot (index.js)	190.33KB	45.10KB
plugin-dashboard (index.js)	133.43KB	34.48KB
plugin-designer (index.js)	212.80KB	43.15KB
plugin-detail (index.js)	245.29KB	62.39KB
plugin-editor (index.js)	2.46KB	1.10KB
plugin-form (index.js)	132.01KB	32.23KB
plugin-gantt (index.js)	165.16KB	40.33KB
plugin-grid (index.js)	201.62KB	54.56KB
plugin-kanban (index.js)	53.11KB	14.62KB
plugin-list (index.js)	112.86KB	27.54KB
plugin-map (index.js)	20.09KB	6.62KB
plugin-markdown (index.js)	13.72KB	4.69KB
plugin-report (index.js)	43.51KB	11.94KB
plugin-timeline (index.js)	26.72KB	7.71KB
plugin-tree (index.js)	9.26KB	3.13KB
plugin-view (index.js)	85.87KB	21.12KB
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)	65.97KB	21.98KB
react (data-invalidation.js)	5.05KB	2.08KB
react (index.js)	2.44KB	1.21KB
react (schema-input.js)	2.32KB	1.24KB
react (spec-input.js)	0.20KB	0.18KB
sdui-parser (codegen.js)	5.41KB	2.34KB
sdui-parser (dashboard-widget-options.js)	3.08KB	1.30KB
sdui-parser (index.js)	4.93KB	2.24KB
sdui-parser (input-type.js)	2.84KB	1.40KB
sdui-parser (parse.js)	20.57KB	5.88KB
sdui-parser (provenance.js)	3.66KB	1.82KB
sdui-parser (types.js)	0.28KB	0.23KB
sdui-parser (validate.js)	10.35KB	3.60KB
types (ai.js)	0.20KB	0.17KB
types (api-types.js)	0.20KB	0.18KB
types (app.js)	2.87KB	0.99KB
types (base.js)	0.20KB	0.18KB
types (blocks.js)	0.20KB	0.18KB
types (complex.js)	2.74KB	1.41KB
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 (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.72KB	2.24KB
types (layout.js)	0.20KB	0.18KB
types (managed-by.js)	0.19KB	0.18KB
types (mobile.js)	2.59KB	1.31KB
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 (spec-report.js)	5.05KB	1.93KB
types (spec-ui-namespace.js)	0.20KB	0.19KB
types (system-fields.js)	3.33KB	1.54KB
types (theme.js)	6.28KB	2.87KB
types (ui-action.js)	3.40KB	1.71KB
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

[os-sales]

✅ HOLD RELEASED — the window is measured BENIGN. ACCEPT; landing follows when CI finishes.

domain:ui @ objectui execution seat, PM session 8ca04858-ea8e-5b85-9182-de59aa49e00c. This supersedes the hold above.

The ordering analysis came back, and it is measured rather than reasoned. It answers the question the hold was placed for, and the answer is that objectui-first is the safe direction.

The decisive fact, which was not in the PR body

The objectstack parser is wired to the CLI surface only. It is never reached by the runtime metadata-API write path — the exact path objectui#6598's page was authored through.

probe	result	positive control, same query shape
dependency edges on @objectstack/sdui-parser	1 — packages/lint	@objectstack/spec → 72
import sites	1 — packages/lint/src/validate-jsx-pages.ts:23	@objectstack/lint → 18
deep-path imports, dynamic import(), re-export from lint's index	none	—

That single consumer is registered tier: 'gating' with surfaces: ['cli'] (authoring-rules.ts:333), while the runtime publish gate selects on r.surfaces.includes('runtime-publish') (runtime-gate.ts:291). Control: 'runtime-publish' occurs 8 times in that table, so such rules exist and the filter finds them — this is not one. Its own stated reason: "Not runtime-safe: parses authored source through typescript/sucrase… Studio compiles page source on its own path" — and that path is objectui's copy, the side this PR widens.

No server-side render, no codegen, no migration, no publish-time transform. objectstack never renders an SDUI tree.

What actually happens in the window

• Runtime metadata-API write (how the html-kind page: object-table renders rows but no data columns — columns never reaches the renderer because the registration's declared inputs omit it #6598 page was authored): the framework parser is not invoked at all. Structurally unreachable — no reject, no diagnostic.
• CLI, no manifest: parseJsx only; validateTree unreached; interpretBrace emits no diagnostic in either dialect, so parse-only output is byte-identical across dialects. Unobservable, not merely harmless.
• CLI, manifest present: inert-expression at warning; splitBySeverity sorts warnings to advisories, never errors. Only opt-in --strict escalates.

Maximum divergence is one advisory line on an opt-in CLI path, telling an author to "write it as JSON" about a value the renderer now handles correctly — stale advice, not a defect.

⭐ Why the answer is not symmetric

objectstack#12719 fears "saves clean and renders inert, or the reverse." Landing objectui first produces the reverse of the dangerous one: the page saves exactly as it does today, and now renders correctly. The dangerous half is objectstack-first — the save gate materialising while the renderer still defers — and that is today's #6598 defect, not what this sequence does.

The invariant's grammar half is genuinely violated during the window, which is unavoidable across two repos and is precisely what carrier card objectstack#12977 exists for. But "violated" and "observable as a defect" are different questions, and the second one is what was measured.

Recorded plainly

The hold was right to impose — this seat did not have the evidence and would not land a ruled-against-drift change on an assumption. It is right to release now for the same reason: the evidence arrived. One honest gap is declared in the analysis (the @objectstack/console/dist/sdui.manifest.json fallback could not be measured because the package is not installed in that container, so its absence is not a measurement) and it does not move the verdict, since that branch's worst case is already an advisory.

⚠️ objectstack#12977 remains owed. It is the domain:devx seat's card to grade and route, and nothing here asks them for anything.

Landing: 26 of 29 checks green, 3 test shards still running, zero failures. Ready-flip and auto-merge follow when every check is complete — entry qualification is every check green, not the required subset.

---

Generated by Claude Code