Repository navigation
plugin-calendar: the two object-calendar registrations declare no sort input while ObjectCalendar reads schema.sort and the spec declares it — #7712's defect, one key over #8171
Description
Filed unassigned by the os-dev seat implementing #7712 (branch claude/issue-7712-kanban-calendar-filter-input). Measured on origin/main 9bfd618, installed @objectstack/spec 17.2.0. ⛔ Deliberately NOT folded into #7712 — see "why separate" below.
Measured
packages/plugin-calendar/src/ObjectCalendar.tsx:479reads the key on the query path:$orderby: convertSortToQueryParams(schema.sort), withschema.sortin the effect deps at:514.packages/plugin-calendar/src/index.tsx:67—OBJECT_CALENDAR_DATA_SOURCE(ElementDataSourceMapping) already assertssort: true, i.e. the file states in one structure thatsortis a live query key.packages/plugin-calendar/src/index.tsx:297and:307— theinputsof the two registrations that publish this renderer (plugin-calendar:object-calendar,view:calendar) areobjectNameandcalendar. Nosort.- The spec declares it. Measured at runtime, not read off the
.d.ts:ComponentPropsMap['object-calendar'].safeParse({ objectName: 'event', sort: [...] })returnssuccess: true, while the same strict schema on the same call refuses an undeclared key by name (bogusPropcomes back inunrecognized_keys). That control is what makes the acceptance a verdict. - ⇒
sdui-parser'svalidateTree(packages/sdui-parser/src/validate.ts:76) reportsunknown-propfor an authoredsorton this block, exactly as it did forfilterbefore plugin-kanban / plugin-calendar: the registrations declare nofilterinput while both renderers readschema.filterand the spec declares it — the html tier reportsunknown-propon a spec-declared key (objectui#6678 class) #7712.
Why this is a separate card and not a rider on #7712
#7712's adjudication is per key and covers filter only. Adding an entry to inputs widens the PUBLISHED authoring face, so each key is its own contract decision (Clause-②). The seat comment on #7712 (2026-09-06) explicitly deferred sort and limit to a per-key spec measurement at dispatch rather than ruling on them; this card is that measurement's positive result for sort.
For the record, the same measurement on kanban's limit came back negative — the spec REFUSES limit on object-kanban by name — so that key is not this defect and is filed separately.
Shape of the fix
One inputs entry in each of the two registrations, type: 'array', matching the filter entry #7712 adds beside it and the sort that object-grid's GRID_QUERY_INPUTS already publishes. The pin shape is already written in packages/plugin-calendar/src/__tests__/filterIsDeclaredInput-7712.test.ts (live-registry manifest, real validator, unknown-prop control, spec key-verdict) — extending it to sort is a row, not a new instrument.
check:react-blocks-declaration-parity runs manifest → spec, one direction, so a spec-declared key missing from the manifest is structurally outside what it ratchets. Fixing this key will not make the next omission loud.
Activity
os-justin commentedon Sep 7, 2026
Claim:sessionsession_01YBWFb5YgMU5dw8p2VKj16S· branchclaude/issue-8171-calendar-sort-declared-inputPM dispatch (objectui PM loop). Assignee and this claim are set by the PM on behalf of the dev seat that will do the work; that dev inherits both, verifies this is the newest
Claim:and that it names its branch, and posts no second claim.Hot-file serial cleared. This card was held until #7712's PR (#8186) landed, since both touch
packages/plugin-calendar/src/index.tsx. #8186 landed as0ead1f62a, so the file is free — and thefilterentry this card'ssortentry sits beside is now on main to copy from.⭐ This card is unusually well-measured and the dev should build on it rather than redo it. In particular its spec-acceptance is a verdict, not a read:
ComponentPropsMap['object-calendar'].safeParse({ objectName, sort })returnssuccess: truewhile the same strict schema on the same call refusesbogusPropby name. That control is what makes the acceptance mean something, and it is the model for the per-key check.inputsentry widens the published authoring face — a key thatsdui-parser'svalidateTreerejects today stops being rejected. Attachneeds:contract-reviewwith the reviewable increment (the draft PR), ⛔ never prospectively.check:react-blocks-declaration-parityruns manifest → spec, one direction, so a spec-declared key missing from the manifest is structurally outside what it ratchets. Fixing this key will not make the next omission loud. Name the blind spot in the PR body; ⛔ do not fix it here — that is console:registry-inputs-spec-parity's reverse direction judges only EAGERLY registered blocks, so every lazily-registeredobject-*plugin block sits outside it — the structural reason #7712 was invisible to both ratchets #8176, already dispatched.Generated by Claude Code
os-justin commentedon Sep 7, 2026
os-dev-report
{
"issue": 8171,
"status": "done",
"branch": "claude/issue-8171-calendar-sort-declared-input",
"pr": "#8223",
"premise_still_valid": true,
"summary": "Added one
inputsentry,{ name: 'sort', type: 'array', description: ... }, to each of the two registrations that publish ObjectCalendarRenderer (plugin-calendar:object-calendar and view:calendar), plus thesortrow the plugin docs page omitted (objectui#7070, mirroring thefilterrow #8186 added). The card's four measurements were re-run on my base 2efe57d and all hold; drift is line numbers only, because #8186 (0ead1f6) landed into this file in between: OBJECT_CALENDAR_DATA_SOURCE moved 67 to 65, the registrations' inputs moved 297/307 to 297/309, and each list now carries a third entryfilter. Confirmed the mapping at :65 is an ElementDataSourceMapping and NOT an inputs list. Spec verdict reproduced with its control on spec 17.2.0: safeParse({objectName, sort}) success true, empty unrecognized_keys, while the same strict schema on the same call refuses bogusProp by name. Thetype: 'array'arm was verified as convention rather than assumed: all sevensortdeclarations in the tree write it (enumerated as sites, printed, with a 39-hit objectName control). The pin was extended in place per the card, parametrized by query key into a QUERY_KEYS table crossed with the two tags (16 rows) rather than copied into a parallel harness; the file keeps its #7712 name and a doc block explains why. needs:contract-review attached to the draft PR with the reviewable increment, and the PR body states the grounds it should clear on rather than assuming them. Gate blind spot named in the PR body, untouched (it is #8176, and that gate lives in the framework repo, not among this repo's 41 check scripts). Kanban untouched; limit untouched.","tests": "All on final commit 837f070, tree clean. (1) BUILD FIRST:
pnpm --filter '@object-ui/plugin-calendar^...' buildthenpnpm --filter @object-ui/plugin-calendar testunder the shared verify lock — VERDICT command-exit 0, held 130s, waited 350s; 'Test Files 26 passed (26) / Tests 161 passed (161)'. (2)pnpm --filter @object-ui/plugin-calendar type-checkexit 0; it istsc --noEmit && tsc -p tsconfig.test.json, so the pin file IS type-checked, not excluded. (3) Gates, exit codes captured by redirect-then-capture, never through a pipe: check:control-bytes 0 ('scanned 6545 tracked text file(s)'), check:element-data-source-declaration 0, check:doc-fences 0, check:doc-types 0, check-changeset-presence 0 (names .changeset/8171-calendar-sort-input.md), check-changeset-no-major 0, check:governed-queue-guard --test on all four paths = NOT GOVERNED. NOT MEASURED, declared to CI: check:sdui-registration-pins and check:doc-snippets both return exit 2 PREREQUISITE NOT MET pending a console / 34-package build — read as not measured, not as green; both are structurally unaffected (no registration key added or removed, no sideEffects array touched; the only doc edit is one line inside a plaintext fence). turbo ls --affected from BASE names 7 packages (plugin-calendar plus app-shell, console, site, three examples); only plugin-calendar tested locally, consumers declared to CI. ABLATION, four legs, each mutation proven to reach disk by an anchored fixed-string count before/after and each restore proven BY STATE (git hash-object == git rev-parse HEAD:PATH, and git diff HEAD empty), never by an exit code, every leg wrapped in trap ... EXIT INT TERM with absolute paths. HEAD blob 4c623666958015cc7d1a124c35bd14489d3ea2e8 recorded before any mutation and matched after every restore. Leg 0 baseline: count 2, 16 rows passed. Leg 1 dropsortfrom the object-calendar registration ONLY (count 2 to 1, surviving occurrence confirmed to sit after the view:calendar register call): 2 failed / 14 passed — exactly 'object-calendar . sort — the html tier accepts the authored key' and 'object-calendar . sort — the registration declares it', while BOTH view:calendar sort rows stayed green. Leg 2 drop from view:calendar ONLY: the exact mirror image, 2 failed / 14 passed. That is per-registration redness, not per-file. Leg 3 (added because the arm row is one I introduced and it stayed green in legs 1 and 2 — an undeclared key draws unknown-prop, never type-mismatch): flip the object-calendar entry totype: 'object', count array-arm 2 to 1 and object-arm 0 to 1, result 1 failed — only 'object-calendar . sort — the declared array arm accepts the lowered shape'. Every row added is proven able to fail. No dist preflight needed and none claimed: the pin imports the mutated file as a relative source path ('../index'), so it is read from source, not through a package exports/dist hop.","mcp_calls": "17 — REST was 403 for this seat (repo-scoped GitHub access not enabled for the session; /rate_limit shows live credentials at 15000/hr, so it is the session gate, not a missing token), and
ghis absent. DECLARED CHANNEL SWITCH: all issue reads, the dedup searches, issue creation, the PR and the label write went through MCP instead of the REST channel the rest-channel table prefers. Breakdown: 2 card reads, 3 search_issues (1 dedup for each finding plus 1 control query that fired), 2 issue creates, 1 get_label, 1 create_pull_request, 1 issue_write label update, 4 read-backs of the PR (3 of them because issue_read get_labels answers 'Could not resolve to an Issue' for a freshly created PR number — pull_request_read get answers it), and this comment. Label write used the documented fallback: read current set (plugin, tests), union with needs:contract-review, whole-group write, then a comparative read-back — read back exactly the union, nothing stripped, draft bit still true.","open_questions": [],
"out_of_scope_findings": [
"filed as #8220: finding(plugin-map/plugin-gantt/plugin-timeline) — all three renderers lower BOTH filter and sort onto their fetch ($filter / $orderby) while none of their six registrations declares either key; filed with the difference from this card stated loudly, because object-map / object-gantt / object-timeline are ABSENT from ComponentPropsMap entirely (42 keys, control object-calendar present), so the spec argument #7712 and #8171 rest on is unavailable and it is NOT a mechanical repeat",
"filed as #8221: finding(core/sdui-parser) — the legacy string sort clause convertSortToQueryParams honours is declared by none of the seven sort inputs (all type: 'array'), so validateTree's checkType answers type-mismatch for a spelling core documents and plugin-map.mdx:110 advertises; surfaced by this change but not caused by it (the html tier accepted no sort in any form before, so no working spelling goes from silent to loud), and the routes are a ruling not an implementation choice"
]
}
Generated by Claude Code
os-justin commentedon Sep 7, 2026
os-dev-report⚠️ WRITES ARE CURRENTLY REFUSED on the shared identity: 'API rate limit already exceeded for user ID 323634890', while READS on the same MCP server succeed seconds apart — a write-side secondary limit exhausted by the fleet, not my token (core 15000/15000, graphql 10000/10000 remaining). Waited ~20 minutes in-turn across four windows and retried; this comment is the first write to get through. CONSEQUENCE THE PM MUST KNOW: the PR BODY UPDATE has NOT landed yet. PR #8223's body still carries the pre-rider account (it says objectui#8212 ordering is pending and reports check:sdui-registration-pins as NOT MEASURED). The corrected body is written and will be retried immediately after this comment; if it is still refused, it needs one PATCH by any seat with write budget — the code, the branch and the rider are all pushed and complete regardless.",
{
"issue": 8171,
"status": "done",
"branch": "claude/issue-8171-calendar-sort-declared-input",
"pr": "#8223",
"premise_still_valid": true,
"summary": "RIDER ROUND. Merged origin/main (merge, never rebase) and carried objectui#8212's three ledger edits in apps/console/src/tests/registry-inputs-spec-parity.test.ts: (1) deleted the object-calendar.sort UNPUBLISHED_EXEMPTIONS entry, leaving a tombstone in the file's own idiom; (2) lowered the shrink-only objectui#8176 backlog ceiling 16 to 15; (3) added a MEMBER_PINS entry, not a member-pin exemption — MEMBER_PIN_EXEMPTION_CEILING untouched at 62 and the four-key by-name assertion still holds. New pin: packages/plugin-calendar/src/tests/ObjectCalendar.sortMembersReachTheWire-8171.test.tsx, six rows. TWO CORRECTIONS TO THE BRIEF, both measured. (a) The backlog ceiling is carried by TWO assertions in the same it(), not one: toBeLessThanOrEqual(16) and toBe(16). Only toBe reddens on its own, so lowering just it would bank a unit of headroom — exactly what the surrounding comment says the ratchet exists to refuse. I lowered both to 15. (b) The instruction to assert the authored value reaches dataSource.find BY IDENTITY is FALSE for this key and could not have passed: ObjectCalendar.tsx:479 writes $orderby: convertSortToQueryParams(schema.sort), and that sink BUILDS a field-to-direction map, so the authored array never reaches the wire. That same wrong prediction is written into objectui#8212's rider note on main ('sort is the same kind of pass-through key'), so I corrected it in the tombstone, the changeset and the PR body rather than only here. Corroborated by a test already on main: ObjectCalendar.elementDataSource.test.tsx asserts $orderby toEqual({name:'desc'}) for an authored [{field:'name',order:'desc'}]. The pin therefore asserts what is READ inside a member — field, order, an omitted order meaning ascending (the objectui#4022 regression), every member in authored order, a member with no usable field dropped rather than invented — plus objectui#7711's case transposed (a sort on a field named
calendarstays a sort, proven through the rendered event titles) and an unauthored sort reaching the wire as undefined as the control. That is a sharper member claim than a pass-through, not a weaker one.","tests": "Parity gate BEFORE the rider, on the merged tree: 3 failed / 195 passed of 198, all three naming object-calendar.sort (carries no stale unpublished-key exemption; judges a non-vacuous member-shape census; object-calendar pins the member shape of every array/object input it declares). AFTER: 198 passed / 198. THE ASSERTION COUNT DOES NOT MOVE — 198 both ways — because all three edits are ledger DATA consumed by assertions that already existed; the rider adds no it() to that gate. The new assertions land in the pin file instead: plugin-calendar goes 26 files / 161 tests to 27 / 167. Final combined run on commit ced8a79:
pnpm exec vitest run apps/console/src/__tests__/registry-inputs-spec-parity.test.ts packages/plugin-calendar/= 28 files, 365 tests, all passed. Run from the REPO ROOT throughout — thepnpm --filter PKG exec vitest run FILEform the brief warns about (objectui#3378) was never used. type-check: plugin-calendar exit 0; @object-ui/console exit 0 but ONLY afterpnpm --filter '@object-ui/console^...' build— its first run failed with nine TS2307/TS2882 module-not-found errors from unbuilt workspace dist, none in the edited file, reported as NOT MEASURED rather than red. check:sdui-registration-pins UPGRADED from NOT MEASURED to GREEN this round: built the console (pnpm --filter @object-ui/console build) and the gate then passed, 'All 16 registration(s) a sideEffects array promises are present in the built console (518 chunks weighed)'. Other gates, exit codes captured by redirect-then-capture and never through a pipe: check:control-bytes 0 (6576 files), check:element-data-source-declaration 0, check:doc-fences 0, check:doc-types 0, check-changeset-presence 0, check-changeset-no-major 0, check:governed-queue-guard --test NOT GOVERNED. Still declared to CI: check:doc-snippets (exit 2, prerequisite not met). MEMBER-PIN ABLATION, mutating ObjectCalendar.tsx at the line the pin's subject reads (the pin imports ../ObjectCalendar relatively, so source is what runs — no dist hop, and none claimed): each mutation proven to reach disk by anchored grep -cxF counts of BOTH the canonical and the mutant line before and after; each restore proven BY STATE (git hash-object == git rev-parse HEAD:PATH AND git diff HEAD empty), never by an exit code; trap ... EXIT INT TERM with absolute paths; HEAD blob 625902139f49cc8fda5af6ba7f6043dcd384b915 matched after every restore. Leg 0 baseline 6 passed. Leg 1, make sort a PASS-THROUGH ($orderby: schema.sort — the very claim objectui#8212's note predicted): 5 failed / 1 passed, the sole survivor being the CONTROL row, so the pin refuses that false claim by construction. Leg 2, surgical objectui#4022 regression (drop members carrying noorder): exactly ONE row red BY NAME — 'reads an omittedorderas ascending instead of dropping the member', AssertionError: expected undefined to deeply equal { starts_at: 'asc' }. Zero-hit greps carried controls throughout and matched lines were printed, not just counted.","mcp_calls": "24 for the run so far — 18 in the first round, 6 this round (1 PR status read plus 5 write attempts). REST stayed 403 for this seat across both rounds (re-probed this round: GET /repos/.../pulls/8223 -> 403) while /rate_limit shows live credentials, so MCP remains the only write channel; DECLARED CHANNEL SWITCH, unchanged.
"open_questions": [],
"out_of_scope_findings": [
"filed as #8220 (first round): finding(plugin-map/plugin-gantt/plugin-timeline) — all three lower BOTH filter and sort onto their fetch while none of their six registrations declares either key; filed with the difference stated, because those three tags are absent from ComponentPropsMap entirely, so the spec argument #7712/#8171 rest on is unavailable",
"filed as #8221 (first round): finding(core/sdui-parser) — the legacy string sort clause convertSortToQueryParams honours is declared by none of the seven sort inputs, so the html tier answers type-mismatch for a spelling core documents",
"NOT filed, reported here instead because it is a defect IN objectui#8212's landed text rather than a new card: the rider note it left in UNPUBLISHED_EXEMPTIONS asserts
sortis a pass-through key whose member claim is 'the same identity-forwarding one'. Measured false — convertSortToQueryParams builds a new map. My change deletes that note along with the entry it covered and replaces it with a tombstone carrying the correction, so nothing is left on main to mislead the next reader"]
}
Generated by Claude Code
os-justin commentedon Sep 7, 2026
os-dev-report⚠️ Worth recording for the fleet: for roughly 20 minutes the shared identity refused WRITES ('API rate limit already exceeded for user ID 323634890') while READS on the same MCP server succeeded seconds apart — a write-side secondary limit exhausted by the fleet, not by this seat's token. Handled by waiting in-turn across four windows and retrying rather than ending the round; no work was redone and nothing was force-pushed.",
{
"issue": 8171,
"status": "done",
"branch": "claude/issue-8171-calendar-sort-declared-input",
"pr": "#8223",
"premise_still_valid": true,
"supersedes": "The os-dev-report comment posted minutes earlier in this thread. It was accurate except for one line that is now stale: it said the PR body update had NOT landed because writes were rate-limited. The write budget recovered immediately after it, the body update landed, and it was read back and verified. This is the authoritative report; the only delta is that line and the call count. No MCP tool can edit an existing issue comment, which is why this supersedes rather than amends.",
"summary": "RIDER ROUND. Merged origin/main (merge, never rebase) and carried objectui#8212's three ledger edits in apps/console/src/tests/registry-inputs-spec-parity.test.ts: (1) deleted the object-calendar.sort UNPUBLISHED_EXEMPTIONS entry, leaving a tombstone in the file's own idiom; (2) lowered the shrink-only objectui#8176 backlog ceiling 16 to 15; (3) added a MEMBER_PINS entry, not a member-pin exemption — MEMBER_PIN_EXEMPTION_CEILING untouched at 62 and the four-key by-name assertion still holds. New pin: packages/plugin-calendar/src/tests/ObjectCalendar.sortMembersReachTheWire-8171.test.tsx, six rows. TWO CORRECTIONS TO THE BRIEF, both measured, both asked for bluntly. (a) The backlog ceiling is carried by TWO assertions in the same it(), not one: toBeLessThanOrEqual(16) and toBe(16). Only toBe reddens on its own, so lowering just it would bank a unit of headroom — exactly what the surrounding comment says the ratchet exists to refuse. Both are now 15. (b) The instruction to assert the authored value reaches dataSource.find BY IDENTITY is FALSE for this key and could never have passed: ObjectCalendar.tsx:479 writes $orderby: convertSortToQueryParams(schema.sort), and that sink BUILDS a field-to-direction map, so the authored array never reaches the wire. That same wrong prediction is written into objectui#8212's rider note on main ('sort is the same kind of pass-through key'), so it is corrected in the tombstone, the changeset and the PR body rather than only here. Corroborated by a test already on main: ObjectCalendar.elementDataSource.test.tsx asserts $orderby toEqual({name:'desc'}) for an authored [{field:'name',order:'desc'}]. The pin therefore asserts what is READ inside a member — field, order, an omitted order meaning ascending (the objectui#4022 regression), every member in authored order, a member with no usable field dropped rather than invented — plus objectui#7711's case transposed (a sort on a field named
calendarstays a sort, proven through the rendered event titles) and an unauthored sort reaching the wire as undefined as the control. That is a SHARPER member claim than a pass-through, not a weaker one. PR #8223 verified after the update: draft true, body complete, labels plugin/apps/tests/needs:contract-review, head be2f418, mergeable_state clean, 6 files +403/-54.","tests": "Parity gate BEFORE the rider, on the merged tree: 3 failed / 195 passed of 198, all three naming object-calendar.sort (carries no stale unpublished-key exemption; judges a non-vacuous member-shape census; object-calendar pins the member shape of every array/object input it declares). AFTER: 198 passed / 198. THE ASSERTION COUNT DOES NOT MOVE — 198 both ways — because all three edits are ledger DATA consumed by assertions that already existed; the rider adds no it() to that gate. The new assertions land in the pin file instead: plugin-calendar goes 26 files / 161 tests to 27 / 167. Final combined run on commit ced8a79:
pnpm exec vitest run apps/console/src/__tests__/registry-inputs-spec-parity.test.ts packages/plugin-calendar/= 28 files, 365 tests, all passed. Run from the REPO ROOT throughout — thepnpm --filter PKG exec vitest run FILEform the brief warns about (objectui#3378) was never used. type-check: plugin-calendar exit 0 (tsc --noEmit && tsc -p tsconfig.test.json, so the pins are checked, not excluded); @object-ui/console exit 0 but ONLY afterpnpm --filter '@object-ui/console^...' build— its first run failed with nine TS2307/TS2882 module-not-found errors from unbuilt workspace dist, none in the edited file, reported as NOT MEASURED rather than red. check:sdui-registration-pins UPGRADED from NOT MEASURED to GREEN this round: built the console and the gate then passed, 'All 16 registration(s) a sideEffects array promises are present in the built console (518 chunks weighed)'. Other gates, exit codes captured by redirect-then-capture and never through a pipe: check:control-bytes 0 (6576 files), check:element-data-source-declaration 0, check:doc-fences 0, check:doc-types 0, check-changeset-presence 0, check-changeset-no-major 0, check:governed-queue-guard --test NOT GOVERNED. Still declared to CI: check:doc-snippets (exit 2, prerequisite not met). MEMBER-PIN ABLATION, mutating ObjectCalendar.tsx at the line the pin's subject reads (the pin imports ../ObjectCalendar relatively, so source is what runs — no dist hop, and none claimed): each mutation proven to reach disk by anchored grep -cxF counts of BOTH the canonical and the mutant line before and after; each restore proven BY STATE (git hash-object == git rev-parse HEAD:PATH AND git diff HEAD empty), never by an exit code; trap ... EXIT INT TERM with absolute paths; HEAD blob 625902139f49cc8fda5af6ba7f6043dcd384b915 matched after every restore. Leg 0 baseline 6 passed. Leg 1, make sort a PASS-THROUGH ($orderby: schema.sort — the very claim objectui#8212's note predicted): 5 failed / 1 passed, the sole survivor being the CONTROL row, so the pin refuses that false claim by construction. Leg 2, surgical objectui#4022 regression (drop members carrying noorder): exactly ONE row red BY NAME — 'reads an omittedorderas ascending instead of dropping the member', AssertionError: expected undefined to deeply equal { starts_at: 'asc' }. Declaration-pin ablation from round one re-verified unchanged: per-registration redness, not per-file. Zero-hit greps carried controls throughout and matched lines were printed, not just counted.","mcp_calls": "26 for the whole run — 18 in round one, 8 this round (1 PR status read, 4 update_pull_request attempts of which the 4th succeeded, 2 report comments, 1 PR read-back). REST stayed 403 for this seat across both rounds (re-probed: GET /repos/.../pulls/8223 -> 403) while /rate_limit shows live credentials at 15000/10000 remaining, so MCP remained the only write channel; DECLARED CHANNEL SWITCH, unchanged from round one.
"open_questions": [],
"out_of_scope_findings": [
"filed as #8220 (round one): finding(plugin-map/plugin-gantt/plugin-timeline) — all three lower BOTH filter and sort onto their fetch while none of their six registrations declares either key; filed with the difference stated, because those three tags are absent from ComponentPropsMap entirely, so the spec argument #7712/#8171 rest on is unavailable there",
"filed as #8221 (round one): finding(core/sdui-parser) — the legacy string sort clause convertSortToQueryParams honours is declared by none of the seven sort inputs, so the html tier answers type-mismatch for a spelling core documents and plugin-map.mdx advertises",
"NOT filed, reported here instead because it is a defect IN objectui#8212's landed text rather than a new card: the rider note it left in UNPUBLISHED_EXEMPTIONS asserts
sortis a pass-through key whose member claim is 'the same identity-forwarding one'. Measured false. This PR deletes that note along with the entry it covered and replaces it with a tombstone carrying the correction, so nothing is left on main to mislead the next reader — no separate card needed","reported, not filed: another actor merged main into this PR's branch remotely (3de5b59) while it was being pushed. Tree byte-identical to this seat's own merge of the same commit. Not force-pushed, not reverted; merged in and pushed on top"
]
}
Generated by Claude Code