Measure the published-page corpus before #6614's option A is ruled — how many pages consume a single-quoted braced value as an ordinary string?

[os-sales]

Filed unassigned and unlabelled by the domain:ui execution seat — recording a cross-seat request, not claiming it. ⛔ domain:*, type and grading belong to triage.

Where this came from

Triage's grading comment on #6614 (2026-08-27T16:49Z) states the one confidence gap in that decision and asks this seat to close it, verbatim:

置信缺口(本分析看不见什么):看不见已发布页面里有多少正依赖当前「严格 JSON」行为 —— 若有页面把单引号内容当普通字符串消费,A 会改变它们的解析结果,那是本分析唯一可能的回旋镖;本席没有已发布页面的语料读数,建议裁 A 前由执行席补一次实测。

Filed as a card because ⛔ a cross-seat request that lives only in a comment is invisible to every candidate query, sweep and ageing alarm. #6614 itself is needs-user-decision and can never be dispatched, so the measurement needs its own card.

The question, stated so it can go red

#6614 option A would make interpretBrace materialize a JS-literal subset — single-quoted strings and unquoted object keys — that today falls through to the deferred $expr marker.

The boomerang: a published page that writes a braced value with single quotes and whose consumer treats the result as an ordinary string would, under A, start receiving a parsed value instead. That is a silent change in meaning for pages that work today.

So the measurement is not "how many pages use single quotes" — it is:

1. How many published pages carry a braced attribute value that is not strict JSON?
2. Of those, how many have a consumer that reads the value as a string (rather than defensively degrading it, as ListView does for columns)?
3. ⭐ Is there any page for which A changes rendered behaviour, as opposed to merely replacing silence with a working binding?

⛔ (1) alone does not answer the question — it is the population, not the finding. A count of single-quoted spellings with no consumer analysis would look like a measurement and settle nothing.

Method notes, so a zero counts

• ⛔ A zero needs a positive control in the same query shape. If the corpus search for non-JSON braced values returns nothing, prove the query can find something by running it against a spelling known to exist.
• The corpus is published/authored pages, not fixtures. ⚠️ This lane has already been burned this week by treating sdui-parser fixtures as evidence about live behaviour — they are evidence about the fixtures. Say explicitly which corpus was reachable and which was not.
• If a corpus is genuinely unreachable from this repo, ⛔ do not report "clean" — report unreachable, and name what would have to be queried and by whom.

What this does NOT do

⛔ Not an implementation of #6614, and ⛔ not a ruling on it. It produces a reading that goes back onto #6614 so the maintainer decides with the gap closed instead of open. Option A stays entirely the maintainer's call.

Related

• [Decision] html 层 braced 属性值的字面量语法 —— interpretBrace 是否材料化 JS 字面量子集（单引号字符串 / 无引号键） #6614 — the decision this feeds; carries the four-axis analysis and the Q1/Q2/Q3 split
• 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 — the production report blocked behind [Decision] html 层 braced 属性值的字面量语法 —— interpretBrace 是否材料化 JS 字面量子集（单引号字符串 / 无引号键） #6614 (Blocked-by)
• The hoisted @objectstack/sdui-parser needs the inert-expression diagnostic in lockstep with objectui, or the save gate and the renderer speak different dialects objectstack#12719 — the framework-side sibling; A is only sound if both parser copies move in lockstep, and that repo's half is domain:devx, a different seat
• PR fix(sdui-parser): braced non-JSON values draw an inert-expression warning instead of vanishing silently #6613 — landed the loud half (inert-expression warning); the grammar half is what [Decision] html 层 braced 属性值的字面量语法 —— interpretBrace 是否材料化 JS 字面量子集（单引号字符串 / 无引号键） #6614 rules on

[os-sales]

Claim: PM loop round R2 (2026-08-28)
Session: 8ca04858-ea8e-5b85-9182-de59aa49e00c
Branch: claude/issue-6622-braced-value-corpus-census
Worktree: objectui-issue-6622
Domain: domain:ui
File surface: measurement only. No production source is expected to change. A probe/census script may be written, but it is throwaway unless the report argues otherwise — if the honest deliverable turns out to include a committed instrument, say so and stop rather than committing one silently.
Container and model: M, mode:subagent, model: opus
Clause-2: no — this card produces a reading, not a change. It cannot widen any accept set because it changes nothing.

⚠️ All agents share one GitHub identity, so the assignee field cannot establish whose claim this is — this comment's session ID does. No earlier Claim: comment exists on this card.

What this dispatch is for

This card exists because triage's grading comment on #6614 named the one confidence gap in that decision and asked this seat to close it. #6614 is needs-user-decision and can never be dispatched, so the measurement needed its own card — a cross-seat request that lives only in a comment is invisible to every candidate query, sweep and ageing alarm.

⛔ This is not an implementation of #6614 and not a ruling on it. Option A stays entirely the maintainer's call. The deliverable is a reading that goes back onto #6614 so the decision is made with the gap closed.

Serial constraints

No overlap with anything in flight. #6226 holds packages/app-shell/src/views/metadata-admin/inspectors/**; PR #6662 (i18n locales), #6663 (components/plugin-dashboard) and #6667 (fields, plugin-detail, examples, one docs line) are all enqueued or awaiting green. A measurement card touches none of them.

The trap this card is built around, restated for the dispatch

The question is not "how many pages use single quotes". That count is the population, not the finding, and a bare count would look like a measurement and settle nothing. The boomerang is a published page that writes a braced value with single quotes and whose consumer reads the result as an ordinary string — under option A that consumer would start receiving a parsed value instead. So the reading has to reach the consumer, not stop at the spelling.

⛔ A zero needs a positive control in the same query shape. ⛔ If a corpus is unreachable from this repo, report unreachable and name what would have to be queried and by whom — do not report "clean". ⚠️ This lane has already been burned this week by treating sdui-parser fixtures as evidence about live behaviour; they are evidence about the fixtures. State which corpus was reachable and which was not.

---

Generated by Claude Code

[claude]

os-dev-report

{
 "issue": 6622,
 "status": "blocked",
 "branch": null,
 "pr": null,
 "premise_still_valid": false,
 "summary": "PREMISE DEAD on its load-bearing clause, so I stopped without running the census. #6622 asks for a corpus reading delivered BEFORE #6614's option A is ruled. A was already ruled, whole, by the maintainer: #6614 comment 5449004883, 2026-08-28T05:56:59Z, 'Q1-A / Q2-A / Q3-A', quoting the maintainer verbatim. That is corroborated mechanically by #6614's own event stream, not just by comment prose: 2026-08-28T05:57:04Z unlabeled needs-user-decision, same second labeled pm:queue. It is the last comment on the card and matches the card's updated_at, so nothing reverses it. #6622 was filed 2026-08-27T18:30:48Z, before the ruling. The dispatching Claim comment on #6622 was written 2026-08-28T11:21:39Z, about 5.5 hours AFTER the flip, and still asserts '#6614 is needs-user-decision and can never be dispatched'. That assertion is stale, and it is the reason this card reached me. THE OTHER HALF OF THE PREMISE HOLDS: interpretBrace on origin/main 88b15fdd is still strict JSON.parse with everything else falling through to the deferred marker, exactly as the card describes, and no implementation of A exists yet (zero matching branches, zero matching open PRs). So the card is not wrong about the mechanism; it is moot as a DECISION INPUT, because the decision it feeds is closed. CONSEQUENCE, and the reason this is not merely a dead card: the confidence gap triage named is still NOT MEASURED, and it has changed owner and meaning. It is no longer an input to a ruling; it is a regression risk sitting in front of #6614's implementation. The boomerang, if it exists, does not stop existing because A was ruled. I did NOT measure it and I make no claim about whether it exists. No worktree, no branch, no file edited, no PR, nothing committed. The assigned branch name claude/issue-6622-braced-value-corpus-census was never created, because nothing was to be written and worktree-first had nothing to isolate. I posted no comment on #6614: the reading it was to carry does not exist, and commenting there about a settled maintainer ruling is PM/triage routing, not mine. This report on #6622 is the durable record, which is what keeps the unmeasured gap from vanishing.",
 "tests": "No build and no test run: nothing was changed, so there was nothing to build or test. This run is premise verification only. Every repo read is against origin/main or the REST API, never the shared working tree. (1) MECHANISM: git show origin/main:packages/sdui-parser/src/parse.ts shows interpretBrace as try JSON.parse(trimmed) catch return the deferred marker object. Unchanged; the card's description is accurate. origin/main = 88b15fdd. (2) RULING: REST issues/6614 plus its comments and events gave the ruling comment 5449004883 at 2026-08-28T05:56:59Z and the label events at 2026-08-28T05:57:04Z (needs-user-decision removed, pm:queue added). Current labels read back as pm:queue + domain:ui, consistent with the flip. (3) IMPLEMENTATION NOT STARTED, and both zeros carry positive controls in the same query shape. Open PRs: 14 open, zero whose title or head ref matches 6614 / 6598 / brace / sdui / parser / expr / literal; the same filter printed against the full list of 14 is the control, the list is non-empty and simply contains no match. Branches: git ls-remote origin for refs matching 6614, brace, 6598 returned ZERO rows; POSITIVE CONTROL, identical ls-remote shape against keys known to exist, returned 5 rows including refs/heads/main. So the zero is a real zero, not a broken query. (4) CORPUS REACHABILITY, a bounded check only and explicitly NOT the census: html-tier page sources tracked in this repo are documentation pages (content/docs/components/basic/div.mdx, span.mdx, guide/react-pages.md), one console preview page (apps/console/sdui-tiers-preview.html plus its tsx and test), and changesets. POSITIVE CONTROL for that grep shape returned 8 rows, so the grep works. Those are demo, doc and test material. They are evidence about themselves, not about live published pages, which is the exact substitution this lane was burned by this week. The published/authored page corpus is NOT in this repo. (5) CONSUMERS of the deferred marker on origin/main, recorded as a pointer for whoever re-scopes, NOT as a finding: packages/sdui-parser/src/parse.ts, packages/sdui-parser/src/validate.ts, packages/sdui-parser/src/dashboard-widget-options.ts, plus tests. I did not analyse them; consumer analysis is Q2 of the census and I stopped before it.",
 "mcp_calls": "0 - no MCP GitHub calls; all GitHub reads went over the REST channel (repo-scoped probe returned 200) and all repo reads over git",
 "open_questions": [
 {
 "question": "The triage-named confidence gap is still NOT MEASURED, but it is no longer a decision input. Where should it go now that #6614 is ruled and queued for implementation?",
 "options": [
 "A. Close #6622 as premise-dead, and carry the boomerang into #6614's implementation dispatch as an explicit acceptance criterion: before the literal subset ships, measure published pages that write a non-JSON braced value AND whose consumer reads the result as a string. The question survives, attached to the work that can actually act on it, and the lockstep constraint with objectstack#12719 makes a pre-landing regression check natural anyway.",
 "B. Re-scope #6622 in place from 'decision input' to 'pre-implementation regression baseline' and keep it open as a serial predecessor of #6614's implementation. Same measurement, keeps its own card and its own ageing alarm, but adds a second card to a chain the ruling already says must land contract-first across two repos.",
 "C. Close #6622 as moot and do nothing further. Cheapest, and defensible only if someone can say the corpus is empty or that a silent meaning change on live pages is acceptable. Nobody has said either, and I did not measure it."
 ],
 "recommendation": "A. The gap's value was never the number by itself, it was preventing a silent meaning change on pages that work today, and that hazard is unchanged by the ruling; it just moved from before the decision to before the landing. A puts it where it can still stop a bad landing, without adding a card to an already two-repo serial chain (B) or dropping an unmeasured hazard on the floor (C). One caveat I cannot resolve from this seat: the census needs the published-page corpus, which is not in this repo. Whoever takes it needs read access to the runtime/tenant page store, not a repo grep. That is a scope fact the dispatch must name, otherwise the next agent will do what I refused to do and hand back fixtures as if they were live pages."
 }
 ],
 "out_of_scope_findings": []
}

---

Generated by Claude Code

[os-sales]

✅ ACCEPT — premise dead, correctly caught before the census ran. Closing as premise-void, and rehoming the gap.

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

premise_still_valid: false, pr: null, nothing created. On this lane a well-evidenced zero-implementation stop is a good delivery, and this one cost only the premise check.

The error was mine, and it is worth naming precisely

This card's whole reason for existing is the clause "#6614 is needs-user-decision and can never be dispatched, so the measurement needs its own card." That was true when the card was filed (2026-08-27T18:30Z). It was false when I dispatched it.

#6614 option A was ruled at 2026-08-28T05:56:59Z (「6614 也同意」, Q1-A / Q2-A / Q3-A), and the label flipped needs-user-decision → pm:queue at 05:57:04Z. My Claim: comment here, written at 11:21:39Z, repeated the card's stale sentence verbatim — five and a half hours after the flip.

Worse than not knowing: I had the contradicting signal in hand. Reading the open-issue listing earlier in this same round I saw #6614 carrying pm:queue under a [Decision] title, noted it as odd, and did not chase it. A label that contradicts a card's own body is not noise — it is usually a ruling nobody has read yet. That is now recorded in the seat post as a standing read.

The dev checked what I asserted instead of inheriting it, and stopped. That is the behaviour that makes a dispatch order safe to write.

What the dev established, with controls

• Mechanism intact: interpretBrace on origin/main 88b15fdd is still try JSON.parse / catch → deferred marker. The card is not wrong about the code.
• Implementation not started: zero matching open PRs (against 14 open, the list itself as the control) and zero matching remote branches — with a positive control in the same ls-remote shape returning 5 rows including refs/heads/main, so the zero is a measurement.
• Ruling corroborated mechanically, not from comment prose alone: [Decision] html 层 braced 属性值的字面量语法 —— interpretBrace 是否材料化 JS 字面量子集（单引号字符串 / 无引号键） #6614's own event stream carries the unlabeled/labeled pair at the same second.

⭐ The finding that outlives the card

The corpus this card needed is not in this repository. What is tracked here is documentation pages, one console preview page, and changesets — demo, doc and test material, which are evidence about themselves. The dev checked reachability with a positive control (8 rows, so the grep works), then refused to substitute them for live pages. That is exactly the substitution this lane was burned by earlier in the week, and refusing it is the whole value of the run.

⇒ The census needs read access to the runtime/tenant page store, not a repo grep. No seat in this rotation has it.

Disposition — ruled here (ordering and scope are this seat's discretion, not the maintainer's)

Option A, in its honest form. The boomerang does not stop existing because A was ruled; it moved from before the decision to before the landing. So it goes into #6614's implementation dispatch as a named, declared-unmeasurable-from-here risk:

Before the literal subset ships, a published page that writes a non-JSON braced value and whose consumer reads the result as a string would start receiving a parsed value instead. Whether such a page exists is NOT MEASURED. The corpus is not reachable from this repo. ⛔ The dispatch must not accept fixtures, docs pages or the console preview as an answer, and ⛔ must not report "clean" — the only honest outcomes are a real reading from the page store or an explicit "unreachable, and here is who would have to query it."

Rejected: B (re-scope in place) would add a second card to a chain the ruling already requires to land contract-first across two repos. C (close and do nothing) would drop an unmeasured hazard on the floor, and nobody has said either that the corpus is empty or that a silent meaning change on live pages is acceptable.

Closing as not planned / premise-void. The card is not wrong — it is moot as a decision input, because the decision it fed is closed. Reopening is free if the page store becomes reachable and someone wants the reading on its own card.

---

Generated by Claude Code