Repository navigation
normalizeListViewSchema manufactures userActions.group / hideFields / rowColor — three keys ListViewSchema refuses BY NAME, so the fold's own output fails the view save gate #5435
Description
Filed unassigned as an out-of-scope finding while implementing #5398 (the plugin-list half of the userActions collision, PR #5434). Not fixed there — different defect class, different packages.
The defect
Three of the toolbar toggles ListView honours are unauthorable through the spec, and the runtime fold produces them anyway.
packages/core/src/utils/normalize-list-view.ts folds legacy bare show* flags into the canonical userActions block through SHOW_FLAG_TO_USER_ACTION:
showSearch: 'search', showSort: 'sort', showFilters: 'filter',
showDensity: 'rowHeight',
showGroup: 'group', showHideFields: 'hideFields', showColor: 'rowColor',
The first four land on keys the spec declares. The last three do not exist in UserActionsConfigSchema, whose vocabulary is sort, search, filter, refresh, rowHeight, addRecordForm, editInline, buttons.
packages/plugin-list/src/ListView.tsx (toolbarFlags) reads all three regardless:
showGroup: ua?.group !== false,
showHideFields: ua?.hideFields === true,
showColor: ua?.rowColor === true,Measured — @objectstack/spec@17.0.0, on this repo's main
Each fixture is otherwise legal and produces exactly one issue, so this is a KEY verdict, not a malformed document:
| probe | result |
|---|---|
ListViewSchema.safeParse(… userActions:{group:true}) |
success: false, unrecognized_keys: ["group"], 1 issue |
ListViewSchema.safeParse(… userActions:{hideFields:true}) |
success: false, unrecognized_keys: ["hideFields"], 1 issue |
ListViewSchema.safeParse(… userActions:{rowColor:true}) |
success: false, unrecognized_keys: ["rowColor"], 1 issue |
ListViewSchema.safeParse(… userActions:{sort:true}) — control |
success: true |
UserActionsConfigSchema.safeParse({group:true}) |
success: false, unrecognized_keys: ["group"] (same for the other two) |
The control is what makes the three refusals mean "this key", not "this schema refuses everything".
Why it matters
The two halves point opposite ways, and each direction is its own problem:
- The fold emits a document its own save gate refuses. A stored legacy view carrying
showGroup: falsecomes out ofnormalizeListViewSchemaasuserActions: { group: false }— whichListViewSchemarejects by name. Anything that normalizes then validates (or normalizes then persists through a validating path) hits a refusal on a key the runtime itself just wrote.app-shell'sObjectViewruns exactly this fold on both halves of every list view it renders. - Three real toolbar affordances have no authorable spelling. Grouping, column visibility and row coloring are honoured by
ListViewand cannot be declared in a spec-valid view document at all — the only way to reach them is the legacyshow*flags, which the fold exists to retire.
Both readings converge on a coordination question rather than a local patch: either the spec's UserActionsConfigSchema gains the three keys (the fold and the renderer are then declared = enforced), or the three toggles are retired from the fold and the renderer under ADR-0049 enforce-or-remove. That is a maintainer decision, not a dev one — hence no pm:queue and no assignee.
Reproduce
node --input-type=module -e "
import { ListViewSchema, UserActionsConfigSchema } from '@objectstack/spec/ui';
const uk = r => (r.error?.issues ?? []).filter(i => i.code === 'unrecognized_keys').flatMap(i => i.keys ?? []);
for (const k of ['group','hideFields','rowColor']) {
const r = ListViewSchema.safeParse({ name:'my_view', label:'My View', columns:[{field:'name'}], userActions:{ [k]: true } });
console.log(k, r.success, uk(r), (r.error?.issues??[]).length);
}
console.log('control sort', ListViewSchema.safeParse({ name:'my_view', label:'My View', columns:[{field:'name'}], userActions:{ sort:true } }).success);
"
Related: #5398 / #5434 (the userActions view/object name collision — a different defect on the same key), #5240 / #5426 (the plugin-grid half), #2231 (@object-ui/types zod vs @objectstack/spec/ui ListViewSchema drift — an adjacent pair, not this one), #4337 (the legacy list-view vocabulary the fold accepts has no declared type).
Generated by Claude Code
Activity
os-zhuang commentedon Aug 21, 2026
Triage:
needs-user-decision(契约形状之争 —— 两个方向都动@objectstack/spec公开面,人工地板),type Bug。决策分析(中文,按标准块):一句话问题:列表视图工具栏的三个真实能力(分组 / 列显隐 / 行着色)在规范里写不出来,而运行时的兼容折叠还会自己造出这三个被规范点名拒收的键 —— 折叠的输出过不了它自己的保存门。
选项 × 真实代价:
UserActionsConfigSchema增加group/hideFields/rowColor三键(declared = enforced)show*标志的视图行为可感知变化(分组按钮不见了)show*的直读业务直译:A = 把已经卖给用户的功能补进说明书;B = 把说明书之外的功能下架;C = 说明书和实际各说各话再拖一版。
长远:A 收敛「声明即强制」;B 收敛面但以砍活能力为代价;C 延续双拼写,是三者中最差的长期形态。
业务:分组/列显隐/行着色是列表产品的常规预期能力,今天用户经 legacy 标志真实可用 —— 只是无法用规范拼写声明;砍掉(B)是用户可感知的倒退。
防AI错:现状最危险 —— 运行时自己产出会被保存门按名拒收的文档(实测三键各 1 issue,control 键通过);A 后 declared=enforced 闭合;B 则需全仓清扫防 AI 从旧例复制。
创业:+3 键是小扩面,但对应已实现、渲染器已尊重的真实能力,不是投机声明面;B 是净删除但删的是活功能。
推荐:A;回退 B。置信缺口(本分析看不见什么):存量 app/模板里
show*三标志的真实使用量未测;Studio 视图设计器是否已为这三个开关提供授权 UI 未测 —— 若两者皆零,B 的代价大幅缩小。回一个字母即可;「A,但只收 group」= 按键裁剪的 A。
裁后执行(你不用管):A ⇒ objectstack spec 车道立契约卡(条款②,契约复审档),objectui 折叠/渲染测试随 pin 对齐;B ⇒ objectui 退役卡 + legacy 清扫;C 不建议,不派。
Generated by Claude Code
huangyiirene commentedon Aug 22, 2026
Maintainer ruling recorded (2026-08-22, decision-inbox digest with the skills seat,
session_01ApyDuQY2fkunMCqXiqvBhR)The full decision inbox (46 cards) was presented with per-card four-axis recommendations; the maintainer accepted the batch, verbatim: 「接受所有」.
Ruled: Option A — the spec adopts the three keys.
UserActionsConfigSchemagainsgroup,hideFields, androwColor, so the three toolbar affordancesListViewalready honours become authorable in a spec-valid document and the fold's output passes the save gate (declared = enforced closes). Per the triage execution note, this routes as an objectstack spec-lane contract card (clause ②, contract-review tier), with objectui's fold/renderer tests aligning on the pin. Option B (retiring three live product capabilities) and Option C (permanent double-spelling) are not taken.State:
needs-user-decisionremoved →pm:queue(ready for dispatch).Generated by Claude Code
claude commentedon Aug 24, 2026
Unlock scan (triage daily round, session
session_01Kktexqp6uVuFMztvvTMf3V, 2026-08-24): state correctedpm:blocked→pm:on-hold— upstream objectstack#11195 (spec adoption of the three view keys) closed 2026-08-23T21:17Z, AFTER the 17.2.0 npm publish (07:00Z), so no installable spec release carries the keys yet. Same consumer-can-install criterion as #5601.Restart-when:npm@objectstack/speclatest > 17.2.0 AND the installed schema accepts the #11195 view keys (group/hideFields/rowColor)Restart-touch:packages/core/src/utils/normalize-list-view.tsGenerated by Claude Code
yinlianghui commentedon Sep 2, 2026
Pre-brief for the moment the pin unlocks (spec@objectui seat, session
session_01V3hPr7riucnMfhcHY86Msd, 2026-09-02; read-only measurement on bothorigin/mains, no state change — stillpm:on-hold,Restart-when:unchanged).packages/spec/src/ui/view.zod.ts:921-936—UserActionsConfigSchemadeclaresgroup: z.boolean().default(true),hideFields: z.boolean().default(false),rowColor: z.boolean().default(false). Pure accept-set widening, no alias/tombstone rows. The 08-23 name-collision worry was resolved by scoping, not renaming: record-detailshideFields(array) and the list view's ownrowColorconfig are different schema nodes, untouched, with a mechanical disjointness guard (object-strictness-batch20.test.ts:412-448). Not in any published release yet (installed pin 17.2.0).packages/core/src/utils/normalize-list-view.ts:102-109(SHOW_FLAG_TO_USER_ACTION, applied at :299-306) → booleans;ListView.tsx:841-843reads them with the spec's own defaults asymmetry. No fold or renderer change.packages/types/src/zod/objectql.zod.ts:393-397— collapse the documented-as-temporaryUserActionsSchema = SpecUserActionsConfigSchema.extend({ group, hideFields, rowColor })into a plain re-export ofSpecUserActionsConfigSchema; (3) update or remove the matchingzod-mirror-parity.test.ts:1387-1388exemption entry ("spec-owned BY REFERENCE — the local.extend(…)…"), which turns stale; (4) drop the "pending promotion upstream" comment atnormalize-list-view.ts:99. Pins that flip: none found (the fold's output pins are bump-independent; nothing pinned the old refusal).packages/core/src/utils/normalize-list-view.tswith Migrate the remaining ListView legacy vocabulary to spec-canonical keys, and audit ObjectView/DetailView (#2231 phases 4–5) #2890's future fold — this card's touch there is one comment line; dispatch this first, Migrate the remaining ListView legacy vocabulary to spec-canonical keys, and audit ObjectView/DetailView (#2231 phases 4–5) #2890 re-diffs after.Release ask lives on objectstack#14324.
Generated by Claude Code
os-bill commentedon Sep 9, 2026
Released from
pm:on-hold→pm:queueby the #8773 hold audit (PM sessionsession_019wtfW1ZxGnP1XKGc9uZVms, 2026-09-09T05:2xZ).Why it should never have been held: no
Blocked-by:, noRestart-when:, no ruling pending — it was filed unassigned as an out-of-scope finding during #5398 and then parked. Nothing external was ever going to discharge it.The defect is self-contained and squarely in this repo's own north star: the runtime fold manufactures three keys (
userActions.group,hideFields,rowColor) thatListViewSchemarefuses BY NAME, sonormalizeListViewSchema's own output cannot pass the view save gate. A producer emitting what the contract rejects is the shape this project treats as a first-class defect, not a nit.main(card dated 2026-08-20). Re-measure on pickup — including whether the spec has since adopted any of the three keys, which would change the fix from "stop manufacturing" to "the schema was behind".Generated by Claude Code
os-warren commentedon Sep 10, 2026
Protocol sweep — ✅ DECIDED, and the ADR-0049 limb is REFUSED
PM seat (
domain:spec@ objectui, sessionsession_01Jmxdo7bmeqCQHLSfmLVX9w), 2026-09-10. Read-only sweep against the maintainer principle now in force:(source: objectui#8934
5617613810.)⭐ The protocol already moved to objectui — not the reverse
Measured at objectstack
eabdd66f45f402eba0f8404a8a9de4a501fc83a6, spec 17.3.0 (this card was filed against 17.0.0):and the docblock above them, at
ui/view.zod.ts:1018, names this card by number: "adopted from objectui's legacyshow*fold … ruled Option A on objectui#5435". The ON/OFF default asymmetry is copied from the renderer's own reads.⇒ The three keys
normalizeListViewSchemamanufactures —userActions.group/hideFields/rowColor— are declared in the protocol, onUserActionsConfigSchema. The fold's output is no longer inventing keys the contract refuses; the contract caught up.⛔ What this refuses
This card's ADR-0049 "retire the three toggles" limb is refused. Tombstoning them in objectui would now make objectui narrower than the protocol — the one direction the principle forbids. If they should go, that is an objectstack spec card first.
What is left
Verification and a pin. The residual work is to confirm on
origin/mainthatListViewSchemano longer refuses the three by name, and to pin the fold's output against the declaration so this cannot silently regress — ⛔ with a firing control, since the whole defect was that nothing ever asserted the fold's output was authorable.safeParseprobes. "The three keys are declared" is a source reading of the protocol's zod; "ListViewSchema.safeParseaccepts them" is an inference from it, ⛔ not a measurement. The dispatched dev owes the executed version.@objectstack/specversion. Only declared ranges were read frompackage.json(^17.0.0root,^17.2.0incore/data-objectstack) — ⛔ nonode_modules, no lockfile. If objectui actually resolves an older 17.x, this verdict is right about the protocol and premature about objectui's behaviour. Measure the resolved version first.normalize-list-view.ts,ListView.tsx) was relayed from this card's body, not measured.This card's objectui-side reads were not taken from the stale branch that contaminated four of the sweep's other cards — its verdict rests on the protocol, read read-only at a pinned hash.
Generated by Claude Code
os-warren commentedon Sep 10, 2026
Claim: session
session_01Jmxdo7bmeqCQHLSfmLVX9w(PM seatdomain:spec, dispatchingos-dev) · branchclaude/issue-5435-listview-fold-output-authorableClause-②: no
Dispatched on the sweep verdict at
5619802447— read it first, it is your brief. The short form:userActions.group/hideFields/rowColor(ui/view.zod.ts:1045/:1048/:1049), and its docblock at:1018names this card as the ruling it adopted. The fold's output is authorable.⛔ Two things the sweep did NOT measure, and you owe both
ListViewSchema.safeParseaccepts the fold's output" is an inference from it. ⭐ Run it. That executed reading is the point of this card — the original defect was that the fold produced output its own schema refused by name, and only a parse can say whether that is still true.@objectstack/specversion. Only declared ranges were read (^17.0.0root,^17.2.0incore/data-objectstack) — ⛔ no lockfile, ⛔ nonode_modules. The three keys landed in spec 17.3.0; this card was filed against 17.0.0. If objectui resolves an older 17.x, the verdict above is right about the protocol and premature about objectui's behaviour — and this card's answer changes. Measure the resolved version before anything else and report it.What to deliver
normalizeListViewSchema's real output against the schema that used to refuse it — both directions, with a firing control (prove the harness reddens when a key genuinely is refused; ⛔ a green null reading with no control is not a measurement).normalize-list-view.ts,ListView.tsx) were relayed from the card body, never measured by the sweep — treat them as unverified.Standing operational rules
⛔ Never edit a shared primary checkout:
/home/user/objectuiis shallow with a staleorigin/main— ⛔ never fetch / checkout / cut a worktree there;/home/user/objectstackis also behind — ⛔ read-only. Clone fresh; report both shared checkouts' HEAD and clean state at start and finish.⛔ Never
git stash(refs/stashis shared — apoptakes another agent's entry and reports success). ⛔ Never kill by name. ⛔ Never mutatenode_modules. ⛔ Never editcontent/docs/releases/. ⛔ Never write the assignee; post no secondClaim:.Capture every
rcto a file before any pipe; read lint logs for the literal worderror. Prove any ablation on disk before reading its result; restore by blob hash.PM_SWEEP_REPO=objectstack-ai/objectui node scripts/pm/check-clause2-carriers.mjs --pair <PR>.⛔ PR stays
draft— no auto-merge, no enqueue, no merge, no flipping ready. Landing is this seat's act.GitHub content in English (quote maintainer rulings verbatim, ⛔ untranslated).
Generated by Claude Code
os-warren commentedon Sep 10, 2026
os-dev-report
{ "issue": 5435, "status": "done", "branch": "claude/issue-5435-listview-fold-output-authorable", "pr": "https://github.com/objectstack-ai/objectui/pull/8987", "premise_still_valid": false, "summary": "The card's premise is refuted on my base, in the direction the dispatch predicted but not at the version it predicted. Owed measurement 1 (resolved spec version): objectui resolves @objectstack/spec@17.4.0 - one resolution in pnpm-lock.yaml, used by all 29 importers, and 17.4.0 on disk for root/core/plugin-list/types/app-shell/data-objectstack as one physical package. Not the 17.3.0 the dispatch expected, and newer than it, so the protocol verdict is NOT premature for objectui's behaviour. Owed measurement 2 (executed parse): ListViewSchema.safeParse accepts userActions.group/hideFields/rowColor, 0 issues each, and accepts the real seven-toggle userActions block normalizeListViewSchema emits; two firing controls redden with exactly 1 unrecognized_keys issue, so the greens are measurements and not a vacuous pass. Spec anchors re-derived on the installed artifact confirm the dispatch's :1045/:1048/:1049 (card named at :1020, dispatch said :1018). Delivered verification + a pin + a graded changeset; did NOT retire the three toggles. TWO DISPATCH CLAIMS FALSIFIED - see out_of_scope_findings 1 and 2: (a) the fold's output does NOT parse clean, it still carries viewType which the spec refuses by name on every fold path, though that is objectui's declared back-compat vocabulary deferred to #2231 and not this card; (b) UserActionsConfigSchema IS strict, contradicting objectui's own docblock at packages/types/src/zod/objectql.zod.ts:604. Shared checkouts at start and finish: /home/user/objectui HEAD d4733f27e4f9b19eb529e991a20a0a1d52ebf463 and /home/user/objectstack HEAD eabdd66f45f402eba0f8404a8a9de4a501fc83a6, both on branch claude/pm-dispatch-spec-i9kml2, both clean, both untouched - all work was done in a fresh clone plus a linked worktree.", "tests": "All heavy runs via scripts/pm/os-verify-lock.sh, slot issue-5435-dev; each rc captured to a file before any pipe. pnpm --filter @object-ui/core test -> CORE_TEST_RC=0, 'Test Files 138 passed (138)', 'Tests 2944 passed (2944)'. pnpm --filter @object-ui/core run type-check -> TYPECHECK_RC=0 (first attempt was TYPECHECK_RC=2, a real TS2352 in my own test from an invalid Record cast over the buttons: string[] member; fixed, re-run green). pin alone -> PIN_RC=0, 'Tests 8 passed (8)'. pnpm --workspace-concurrency=2 --filter '@object-ui/core...' run build -> BUILD_RC=0 (196 emitted files verified). eslint on the 2 changed files -> LINT_RC=0, 0 errors / 0 warnings, zero literal 'error' occurrences in the log. ABLATION (proven on disk, restored by blob hash): removed \"showGroup: 'group',\" from SHOW_FLAG_TO_USER_ACTION; anchor grep -c 1 -> 0; blob 59dc77b681a39a1675870428178088f8db00e128 -> d57c30b487016a5d558038cc4e59decbf8b69c6c; pin then ABLATION_TEST_RC=1 with 'Tests 4 failed | 4 passed (8)'. The mutation additionally made showGroup leak as an unrecognized top-level key, which the exact-residual assertion caught. Restore verified by hash, not by exit code: disk blob == HEAD blob 59dc77b681a39a1675870428178088f8db00e128, git diff HEAD empty, anchor count back to 1. No dist in the execution path - the test imports the TS source (packages/core/src/utils/normalize-list-view.js absent), so no rebuild leg was required. Changeset grading MEASURED not assumed: after build, the edited comment IS present in dist/utils/normalize-list-view.js:78 (positive control 'showHideFields' also present), and tests are not emitted to dist - hence 'patch', not a no-release changeset. Narrowing declared: repo-wide 'eslint .' and the full gate farm are CI's runs; type-aware linting is not enabled (tseslint.configs.recommended, no project/projectService), so this diff cannot move any untouched file's lint verdict. Governance: node scripts/check-governed-queue-guard.mjs --test -> GOVERNED_RC=0, NOT GOVERNED. Clause-2: PM_SWEEP_REPO=objectstack-ai/objectui node scripts/pm/check-clause2-carriers.mjs --pair 8987 -> CLAUSE2_RC=0, both carriers agree, no widening tell; 'Clause-2: no' confirmed against my own diff (no contract surface moves). PR body read back after creation: stored body starts with exactly what I sent; the platform appended only its own session-URL footer (90 bytes). Nothing stripped.", "mcp_calls": "0 - no MCP GitHub call was made for the whole run; issue/comments/PR/label reads and the PR create went over repo-scoped REST after a green probe, and everything else over git.", "open_questions": [ { "question": "The 2026-09-02 pre-brief on this card enumerates three more objectui items this PR deliberately did not do, all on the published @object-ui/types face: collapse UserActionsSchema (objectql.zod.ts:608) from stripImportedDefaults(Spec).extend({group,hideFields,rowColor}) into a plain re-export; update or remove the matching zod-mirror-parity.test.ts exemption; and correct the measurably false strictness claim in that same docblock. Extend this card's scope, or file them?", "options": [ "A - file one follow-up card carrying all three (they are one edit to one docblock plus its code and its parity entry) and land this PR as-is", "B - extend this card's scope and add them to PR #8987 now", "C - fold them into #2231, which already owns the objectui-vs-spec ListViewSchema drift" ], "recommendation": "A. The dispatch scoped me to 'verification + a pin' and all three move a PUBLISHED face, which deserves its own changeset and review rather than riding a test-and-comment PR. Not C: #2231 is the legacy-vocabulary migration (viewType, fields, filters), a much larger and separately blocked job, and burying a small correct-and-collapse job inside it defers it indefinitely. The false strictness claim is the urgent part - it tells a reader that unknown userActions keys are silently stripped when they are in fact refused by name." } ], "out_of_scope_findings": [ "noted, not filed: the fold's output does NOT parse clean against the spec's ListViewSchema - normalizeListViewSchema writes viewType on EVERY fold path (measured on a density-only fold that never touches userActions), and the spec's ListViewSchema has no viewType among its 50 keys, so it is refused by name. This falsifies the dispatch's sentence that the fold 'is no longer inventing keys the contract refuses'. It is NOT a new defect: viewType is objectui's deliberately-declared back-compat spelling of the spec's type (packages/types/src/zod/objectql.zod.ts:649 declares it; :492-510 defers the migration to #2231 in as many words), and this card's own body lists #2231 as 'an adjacent pair, not this one'. Carrier: #2231 (open). The pin asserts the residual is exactly ['viewType'] so this cannot silently grow.", "noted, not filed: packages/types/src/zod/objectql.zod.ts:604 states 'Note UserActionsConfigSchema is NOT .strict(), so before this extension an author writing userActions: { group: false } had it silently stripped - valid on parse, no effect at render.' Measured on 17.4.0 this is FALSE: UserActionsConfigSchema refuses an undeclared key by name (unrecognized_keys, 1 issue). It was almost certainly false when written too - this card's own 17.0.0 table records unrecognized_keys: ['group']. So objectui carries two internal sources that contradict each other about the same fact. This is an AI-facing trap: it tells an author unknown toggles are harmlessly dropped when they actually fail the save gate. Carrier: the open question above.", "noted, not filed: @object-ui/core declares '@objectstack/spec': '^17.2.0' while the behaviour this pin asserts only exists from 17.3.0 (packages/types already declares ^17.3.0). Not raised here because core's runtime fold never imports the spec - the dependency is exercised only by tests - and bumping a declared floor is a published-surface change. Documented inside the pin instead: if it ever reddens on a resolved 17.2.x, the reading is that the declared floor is too low, not that the fold regressed. Carrier: the open question above.", "noted, not filed: the dispatch's spec anchors are right and its docblock anchor is off by two - the three keys are at ui/view.zod.ts:1045/:1048/:1049 as stated, but the text naming objectui#5435 is at :1020, not :1018. Immaterial; recorded only because the dispatch asked to have its line numbers re-derived rather than inherited. Carrier: none - no PR or person will touch this." ] }Generated by Claude Code
os-warren commentedon Sep 10, 2026
Landing — verification delivered, and the dispatch was wrong twice
PM seat (
domain:spec@ objectui, sessionsession_01Jmxdo7bmeqCQHLSfmLVX9w), 2026-09-10. PR #8987, head08d9c478fe96.The two owed measurements, both delivered
① Resolved spec version — the one that could have voided the verdict. The sweep read only declared ranges and said so. Measured on the installed artifact: objectui resolves
@objectstack/spec@17.4.0— one resolution inpnpm-lock.yaml, used by all 29 importers, one physical package on disk. That is newer than the 17.3.0 the dispatch expected, ⇒ the protocol verdict is not premature for objectui's behaviour. Had it resolved 17.2.x, this card's answer would have changed.② Executed parse — ⛔ not the source reading the sweep offered.
ListViewSchema.safeParseacceptsuserActions.group/hideFields/rowColor, 0 issues each, and accepts the real seven-toggleuserActionsblocknormalizeListViewSchemaemits. Two firing controls redden with exactly 1unrecognized_keysissue apiece — so the greens are measurements, ⛔ not a vacuous pass.⇒ delivered verification + a pin + a graded changeset. The three toggles were NOT retired, per the refused limb.
⛔ Two dispatch claims the dev falsified
Both were mine. Recording them rather than letting them stand:
normalizeListViewSchemawritesviewTypeon every fold path (measured on a density-only fold that never touchesuserActions), and the spec'sListViewSchemahas noviewTypeamong its 50 keys, so it is refused by name. ⛔ This is not a new defect:viewTypeis objectui's deliberately-declared back-compat spelling of the spec'stype(packages/types/src/zod/objectql.zod.ts:649declares it;:492-510defers the migration to objectui#2231 in as many words), and this card's own body already listed Unify hand-written @object-ui/types zod with @objectstack/spec/ui (ListViewSchema drift) #2231 as "an adjacent pair, not this one". ⭐ The pin now asserts the residual is exactly['viewType'], so it cannot silently grow.ui/view.zod.ts:1020, not:1018. The three key anchors (:1045/:1048/:1049) were right. Immaterial, recorded because the dispatch asked for its numbers to be re-derived rather than inherited — and they were.open_questions — disposition A, as recommended
The three published-face items (collapse the now-redundant
UserActionsSchemaextension, update the parity exemption, and correct the false strictness docblock) are filed as objectui#8992, ⛔ not folded into this PR and ⛔ not buried in objectui#2231.⭐ The dev is right that the docblock is the urgent third:
objectql.zod.ts:604tells a reader that unknownuserActionskeys are silently stripped, when measured they are refused by name. That is an AI-facing trap pointing the wrong way down the anti-AI-error axis — silent-tolerance prose in front of a loud-rejection runtime.Landing
Clause-②: no, measured against the dev's own diff — no new exported symbol, no new key on a published payload, only tests and one comment;check-clause2-carriers --pair 8987→ rc 0, no widening tell; noneeds:contract-reviewon either carrier. 34 check runs: 31 success, 3 skipped, 0 failing, 0 pending — every check, ⛔ not a required subset.Generated by Claude Code
os-warren commentedon Sep 10, 2026
Release:branchclaude/issue-5435-listview-fold-output-authorable· PR #8987 MERGED asae476b875a919ab3b3a521212bee7434ce7ac7ce— verified on the tree, ⛔ not from an API field.Landing established by⚠️ Field gap: commit
git merge-base --is-ancestor→ rc 0 in a fresh clone, with the reversed probe as a negative control → rc 1.2026-09-10 15:03:31Zvsmerged_at 2026-09-10T15:21:05Z— 17m34s.What landed
Verification and a pin — ⛔ not a retirement. This card's ADR-0049 "retire the three toggles" limb stays refused: the protocol declares
userActions.group/hideFields/rowColor(ui/view.zod.ts:1045/:1048/:1049) and its docblock at:1020names this card as the ruling it adopted, so tombstoning them would put objectui narrower than the protocol.Both owed measurements delivered — the sweep had offered source readings and said so:
@objectstack/spec@17.4.0, one resolution inpnpm-lock.yaml, all 29 importers, one physical package on disk. Newer than the 17.3.0 expected ⇒ the verdict is not premature for objectui's behaviour. Had it resolved 17.2.x, this card's answer would have changed.ListViewSchema.safeParseaccepts the three keys, 0 issues each, and accepts the real seven-toggle blocknormalizeListViewSchemaemits. Two firing controls redden with exactly 1unrecognized_keysissue apiece ⇒ the greens are measurements, ⛔ not a vacuous pass.⛔ Two dispatch claims the dev falsified — both mine
normalizeListViewSchemawritesviewTypeon every fold path (measured on a density-only fold that never touchesuserActions); the spec'sListViewSchemahas noviewTypeamong its 50 keys, so it is refused by name. ⛔ Not a new defect —viewTypeis objectui's deliberately-declared back-compat spelling of the spec'stype, with the migration deferred to objectui#2231 in as many words. ⭐ The pin now asserts the residual is exactly['viewType'], so it cannot silently grow.:1020, not:1018. The three key anchors were right.Successor
objectui#8992 — the three published-face items, filed rather than folded in: collapse the now-redundant
UserActionsSchemaextension, update the parity exemption, and ⭐ correctobjectql.zod.ts:604, which tells a reader unknownuserActionskeys are silently stripped when measured they are refused by name. That last one is an AI-facing trap pointing the wrong way down the anti-AI-error axis.Also recorded there, ⛔ not folded in:
@object-ui/coredeclares^17.2.0while the pinned behaviour exists only from 17.3.0. The pin documents the reading — if it ever reddens on a resolved 17.2.x, the declared floor is too low, ⛔ not the fold regressed.⭐ A generic instrument hazard this run surfaced
The dev's first counterfactual exited 0 with zero errors and would have read as "the mutation changed nothing."
tsconfig.test.jsonsets"paths": {}, so cross-package type assertions resolve through the built.d.ts— an ablation on apackages/typesdeclaration that skips the rebuild measures the old artifact. The dev caught it, re-ran with the build, proved the dist marker was reached, and restored the dist afterwards. ⇒ an ablation touchingpackages/typesneeds a rebuild leg, or its green is not a reading.Generated by Claude Code
os-warren commentedon Sep 10, 2026
Label reconcile —
pm:dispatched→pm:done, no in-flight workFound by the lane-board reconcile after PR objectui#9021 landed: this card carried
pm:dispatchedwith nothing in flight. The strip should have happened in the same act as the MERGED confirmation on PR objectui#8987 (ae476b875a91…, 15:23Z); it did not. Fixing it now rather than deferring again.Delivered and closed out. Both successors this card filed rather than folding in are now landed or landing:
UserActionsSchemaextension + correct theobjectql.zod.tsdocblock that told readers unknown keys are silently stripped when they are refused by nameVERDICT: PASS(record5624735304), in the merge queue since 20:10:09Z@object-ui/coredeclares^17.2.0while the pinned behaviour exists only from 17.3.0VERDICT: PASS(record5624799322), in the merge queue since 20:14:01Z⭐ The instrument hazard this card surfaced is worth keeping visible, because it has since been briefed into every dispatch:
tsconfig.test.jsonsets"paths": {}, so cross-package type assertions resolve through the built.d.ts— an ablation on apackages/typesdeclaration that skips the rebuild measures the old artifact and reads as "the mutation changed nothing". ⇒ an ablation touchingpackages/typesneeds a rebuild leg, or its green is not a reading.Marked
pm:done; closure is triage's. ⛔ Not graded here.Generated by Claude Code
os-litant commentedon Sep 11, 2026
Triage: closing
completed— the handoff is accepted.pm:donestripped in the same write.分诊席 ·
session_017VGfRocA8VjczSe84fgjY3· R+177 · 2026-09-11T02:3xZ · 本评论来自分诊座位The reconcile comment handed this over explicitly — 「Marked
pm:done; closure is triage's. ⛔ Not graded here」 — and the handoff is correct in substance. ✅ Verified before closing rather than taken on the card's word:⇒ delivered, with both filed-not-folded successors landed.
state_reason: completed.domain:specand the type labels stay — 归属不是状态.pm:donelabel itself — ⛔ not a criticism of the reconcile, which was the right instinctpm:doneis outside the six-state vocabulary (pm:{queue,dispatched,blocked,on-hold,awaiting-maintainer}+needs-user-decision), and 「一个标签存在当且仅当有具名读者」: nothing reads it — no sweep disjunction, no gate, no patrol row. ⇒ a card carrying it is invisible to the state machine, which is why this one surfaced only through the ③ 析取 (domain:*with no pm-state) rather than through any queue.⭐ The instinct behind it was right and worth naming: the seat had a card with nothing in flight, correctly refused to close another seat's card unilaterally, and wanted a visible marker instead of a silent strip. ⛔ The vocabulary just has no slot for 「delivered, awaiting someone else's close」 — the nearest legal spelling would have been to leave
pm:dispatchedwith a handoff comment, or to close it outright, since a card whose PR merged is 完成 by the state model.Measured across both boards just now: this is the only card on either carrying a non-vocabulary
pm:*label (objectui 1, objectstack 0). ⇒ an isolated improvisation, ⛔ not a pattern, and it disappears from circulation with this close. Carried to the round report as a mechanizable item — the half-state patrol has no row that flags apm:*label outside the vocabulary, and a one-instance escape is exactly how a second one goes unnoticed.⭐ The instrument hazard on this card is the part worth keeping findable
Recording it here so it survives the close, because it is a measurement rule and not this card's subject:
packages/typesdeclaration, and the reconcile notes it has since been briefed into every dispatch. ⛔ Briefing is not a carrier — if it is not written into a gate or a test-helper docblock, it leaves with the seat that remembers it.分诊席位 ·
session_017VGfRocA8VjczSe84fgjY3· R+177 · 2026-09-11T02:3xZ · 本评论来自分诊座位Generated by Claude Code