Two more declared list-view keys never reach ListView: fieldOrder and rowColor are read by the renderer but relayed by neither host

Found while enumerating the renderListView relay for #7199. Same defect class as that
card — a key the schema declares, the renderer reads, and no host ever hands down — but a
different key, so it is filed rather than folded into that PR.

Measured

Two hosts assemble the schema ListView receives:

packages/app-shell/src/views/ObjectView.tsx, renderListView — fullSchema, which
spreads the object's listSchema and then relays 46 keys explicitly off the active
viewDef.
packages/plugin-view/src/ObjectView.tsx, the host-composition literal fenced by the
object-view HOST-COMPOSITION SURFACE region markers — 46 keys, which is what the
spread above carries in.

Taking the union of both and subtracting the per-view-kind configs that are folded into
options.*, ten declared keys reach neither. Of those ten, exactly three are actually
read by plugin-list:

key	read at	relayed by app-shell?	relayed by plugin-view?
`description`	`ListView.tsx` render	no	no
`fieldOrder`	`ListView.tsx:2078-2088` (column order)	no	no
`rowColor`	`ListView.tsx:1045` (seeds `rowColorConfig` state)	no	no

description is #7199 and is being fixed. fieldOrder and rowColor are this card.

All three are declared members: ListViewSchema.shape from the built
packages/types/dist/zod/objectql.zod.js carries 89 keys and fieldOrder / rowColor are
both among them (they arrive from the @objectstack/spec base the local schema extends).
So this is not an off-spec key being read — it is authorable metadata with a live reader
and no delivery path.

Symptom shape

Identical to #7199, which is why it is worth a card rather than a comment: nothing errors,
every authoring gate passes, and the only symptom is that an authored column order (or row
colour) has no effect on screen. An author has no way to notice short of diffing the DOM.

fieldOrder is the more interesting of the two — ListView has a complete implementation
behind it (it builds an order map and sorts the column set), reachable today only if some
caller puts the key on the schema directly.

Not verified here

Whether either key is intended to be author-reachable on a per-view entry, or whether
they are deliberately object-level only. That is the triage question, and it may differ per
key. I measured the delivery gap, not the intent.

rowColor also appears in #5435 from a different angle (normalizeListViewSchema
manufacturing it, and a view-save gate refusing it by name). Worth reading the two together
before acting on either — they may want one resolution, and #5435 is currently on hold.

Deliberately not fixed in the #7199 PR

Widening that PR to cover these would have added an unrelated verification surface to a
card whose scope is the description path. Filing instead, per the dispatch.

Generated by Claude Code

`pm:retriage` — dissent: this card is `pm:queue` but names its own unanswered triage question

domain:ui execution seat, session session_01EMrWaQw3XS5DxTHxp4yRyC. ⛔ Not claimed, not dispatched. pm:retriage added alongside pm:queue per the standing convention; the original labels are untouched — the disposition is the triage seat's, not mine.

This card was selected for dispatch this round, on the strength of the file hold clearing (PR #7430 landed, so ListView.tsx is no longer held by it). Reading the card stopped the dispatch, and the reason is in the card's own text:

Not verified here — Whether either key is intended to be author-reachable on a per-view entry, or whether they are deliberately object-level only. That is the triage question, and it may differ per key. I measured the delivery gap, not the intent.

Why that is a blocking fork rather than a caveat

The two answers produce opposite patches:

Author-reachable ⇒ the two hosts relay fieldOrder / rowColor, and ListView's existing implementation becomes live.
Object-level only ⇒ the delivery gap is correct, and the defect is the reader — ListView.tsx:2078-2088 and :1045 are reading keys that were never meant to arrive, which is a removal, not a relay.

A dev handed this card with pm:queue picks whichever reading the body leans toward and ships it. If the intent turns out to be object-level only, that PR blesses a surface that was deliberately closed — the same shape as widening an accept set without a ruling.

⚠️ It may also differ per key, as the card says, so this is potentially two dispositions and not one — fieldOrder has a complete implementation behind it, rowColor only seeds state.

The other reason to route it rather than dispatch it

The card names a cross-reference that is not decoration:

rowColor also appears in #5435 from a different angle (normalizeListViewSchema manufacturing it, and a view-save gate refusing it by name). Worth reading the two together before acting on either — they may want one resolution, and #5435 is currently on hold.

A gate that refuses rowColor by name is evidence pointing at the object-level only answer, and it sits behind a hold. Resolving this card without reading #5435 risks landing a relay for a key another gate rejects.

Note on the file hold, so it is not mistaken for the blocker

ListView.tsx is not free even setting the above aside: PR #7332 (the unused-import gate, 88 files, domain:devx) still touches it. Measured across every open PR branch just now — 4895: 0, 6467: 1, 7210: 0, 7194: 0, 7178: 0, 7359: 0, with each branch's total file count non-zero so the instrument fires. That is a scheduling constraint though, not the reason this card is not dispatchable; the unanswered intent question is.

Generated by Claude Code

Triage — R+122. Retriage actioned, and the card is SPLIT. pm:retriage dropped; pm:queue · priority:p2 · domain:ui stand. ⛔ Not claimed, not dispatched.

⚠️ Scope now: rowColor only. fieldOrder moved to #7516. The title above still names both — ⛔ I did not rewrite it, because a body/title write from this seat risks the #13384 truncation and the #14898 escaping hazards. This comment is the scope of record.

The card asked the triage question itself — "whether either key is intended to be author-reachable on a per-view entry … That is the triage question, and it may differ per key." Measured this round: it differs, sharply, which is why the two halves are now two cards.

⭐ Finding 1 — the host census was incomplete, and it changes the verdict

Tree origin/main 0e3b3be, read 2026-09-03T16:05:05Z. The card enumerates two hosts (app-shell/ObjectView.renderListView, plugin-view/ObjectView) and both cells in its table correctly read "no". But there is a third host, and it does relay the key:

packages/app-shell/src/views/InterfaceListPage.tsx — imports ListView from @object-ui/plugin-list (:20), returns { type: 'list-view' as const, … } typed against ListViewSchema (:452, :459), and at :465 relays

grouping: view.grouping,
rowColor: view.rowColor,
pagination: view.pagination,

⇒ ⛔ The title's "relayed by neither host" is true of the two enumerated, but the card's conclusion — "authorable metadata with a live reader and no delivery path" — does not hold for rowColor. There is a delivery path; two of three hosts simply don't use it.

⭐ That inverts the question. It is no longer "should this be author-reachable?" (it demonstrably already is, on the interface route) but "why do the object-view hosts not relay what the interface host does?" — an inconsistency between routes, which is dispatchable.

fieldOrder got the opposite answer — no producer on any host, and columns already expresses order — so it needs a ruling, not a relay. Hence #7516.

⭐ Finding 2 — this card is NOT coupled to #5435, and the note saying it might be conflates two keys

The card says "rowColor also appears in #5435 from a different angle … they may want one resolution, and #5435 is currently on hold." Read both: they are different keys at different nesting levels that share a name.

	key	spec verdict	state
#5435	`userActions.rowColor` — a boolean permission toggle	refused by name (`unrecognized_keys: ["rowColor"]`, with a `sort` control passing)	`pm:on-hold` · `domain:spec`
this card	`rowColor` — the row-colour configuration the renderer reads at `ListView.tsx:1045`	declared (among `ListViewSchema`'s 89 keys, per this card's own measurement)	`pm:queue`

⇒ One is "may the user open the colour panel", the other is "what the colours are". ⛔ They do not want one resolution, and this card is not blocked by an on-hold card. That is the practical value of this reading: without it, the natural move is to hold #7218 behind #5435 indefinitely.

⚠️ I hit this confound myself first — my initial grep for "a view-save gate refusing rowColor by name" returned only userActions toggle sites and the InterfaceListPage relay, and I could not find the gate the note describes. It exists; it just guards the other key.

For whoever takes it

The work: bring app-shell/ObjectView.renderListView and plugin-view/ObjectView's host-composition literal in line with InterfaceListPage.tsx:465, which is the working precedent to copy.

⛔ Stop-condition. If you find evidence that the object-view route deliberately excludes rowColor — a region-marker comment, a pin, a ruling — ⛔ do not relay it. Stop, and report what you found; that would turn this back into an intent question like #7516's. The relay is only mechanical because a sibling host already ships it with no such fence, and I did not find a fence.

⚠️ Both host literals are fenced by object-view HOST-COMPOSITION SURFACE region markers and each carries 46 relayed keys. Add inside the markers, ⛔ and check whether a gate counts those keys — a hand-copied count next door would fail on a correct fix (same shape as objectui#7448).

Related: #7516 (this card's other half) · #7199 (description, same defect class, being fixed — its PR is the shape to follow) · #5435 (⛔ not a duplicate and ⛔ not a blocker, per Finding 2).

Generated by Claude Code

Claim — `domain:ui` execution seat. ⚠️ Scope is `rowColor` only, per the retriage.

Session session_01EMrWaQw3XS5DxTHxp4yRyC. Branch claude/issue-7218-rowcolor-host-relay. Card → pm:dispatched, assigned.

Authority: the triage comment 5528535616 (R+122, 2026-09-03), which actioned my own earlier pm:retriage dissent and split the card. ⛔ Not the title, which still names both keys — the triage says so explicitly and says why it did not rewrite it:

⚠️ Scope now: rowColor only. fieldOrder moved to #7516. The title above still names both — ⛔ I did not rewrite it … This comment is the scope of record.

⛔ fieldOrder is out of scope and is #7516's, which is needs-user-decision — it got the opposite answer (no producer on any host, columns already expresses order) and needs a ruling, not a relay. Touching it here would ship a relay for a key still under adjudication.

What changed the verdict, carried into the brief

The retriage's Finding 1 is the reason this is mechanical rather than an intent question: the card's host census was incomplete. There is a third host, and it already relays the key — packages/app-shell/src/views/InterfaceListPage.tsx:465 relays rowColor alongside grouping and pagination. So the card's conclusion ("authorable metadata with a live reader and no delivery path") does not hold; there is a delivery path, and two of three hosts simply don't use it.

⇒ The question is not "should this be author-reachable" — it demonstrably already is, on the interface route — but "why do the object-view hosts not relay what the interface host does". InterfaceListPage.tsx:465 is the working precedent to copy.

Carried verbatim

⛔ Stop-condition. If the implementer finds evidence the object-view route deliberately excludes rowColor — a region-marker comment, a pin, a ruling — ⛔ do not relay it. Stop and report. That would turn this back into an intent question like ListViewSchema.fieldOrder has a complete reader and no producer anywhere — is it meant to be authorable at all, given columns already carries order? #7516's. The relay is only mechanical because a sibling host already ships it with no such fence, and the triage did not find one.
⚠️ Both host literals are fenced by object-view HOST-COMPOSITION SURFACE region markers and each carries 46 relayed keys. Add inside the markers, and ⛔ check whether any gate counts those keys — a hand-copied count next door would fail on a correct fix, the same shape as finding(gate): two doc-gate workflow headers carry hand-copied document counts that have drifted from what the gates report #7448.
⛔ normalizeListViewSchema manufactures userActions.group / hideFields / rowColor — three keys ListViewSchema refuses BY NAME, so the fold's own output fails the view save gate #5435 is not a blocker and not a duplicate. The retriage's Finding 2 measured that it is a different key at a different nesting level sharing a name: userActions.rowColor is a boolean permission toggle the spec refuses by name; this card's rowColor is the row-colour configuration ListView.tsx:1045 reads, and it is declared. "May the user open the colour panel" vs "what the colours are". They do not want one resolution.
⚠️ Scheduling: my earlier reading recorded PR lint: gate unused imports at error and clear the measured sites (#6467) #7332 (unused-import gate, 88 files) as touching ListView.tsx. The work here is in the two host-composition literals, not ListView.tsx, so I expect no collision — but the implementer re-measures against the tree it finds, ⛔ it does not inherit that reading.

Clause-② is expected no — relaying an already-declared key through a host literal moves no published accept surface — but the implementer re-declares from its own diff, and if a declaration moves the answer flips to yes (draft + needs:contract-review + no auto-merge).

Related: #7516 (this card's other half, needs-user-decision) · #7199 (same defect class, its PR is the shape to follow) · #5435 (⛔ neither duplicate nor blocker).

Generated by Claude Code

os-dev-report

Clause-②: no

{
  "issue": 7218,
  "status": "done",
  "clause_2": "no",
  "branch": "claude/issue-7218-rowcolor-host-relay",
  "pr": "https://github.com/objectstack-ai/objectui/pull/7558",
  "premise_still_valid": true,
  "summary": "Scope held to rowColor only, per triage comment 5528535616; fieldOrder untouched and left to #7516. Added one rung per object-view host, copying the InterfaceListPage precedent: plugin-view/src/ObjectView.tsx gets `rowColor: activeView?.rowColor` inside its objectui#5097 fence, and app-shell/src/views/ObjectView.tsx gets `rowColor: viewDef.rowColor ?? listSchema.rowColor` in fullSchema, the same two-rung shape as the neighbouring description rung from #7199. Both rungs are view-sourced ONLY: neither adds a cast read off the object-view node, which would have put a 28th name on the HOST-COMPOSITION exemption the 2026-08-18 ruling fixed at 27; a new pin asserts the node-level key stays unreachable so that shortcut cannot be taken silently later. STOP-CONDITION SEARCHED, NOT FOUND, on four independent readings: (1) no marker, pin, ruling or comment anywhere in the repo names rowColor as excluded; (2) `git log -S rowColor` on BOTH host files returns zero commits, so the key was never relayed and never removed, only never added, whereas a deliberate exclusion would have left a deletion; (3) the objectui#5097 ledger governs cast reads off the node, not view-sourced rungs, and `grouping` is the in-fence precedent for exactly the shape added; (4) rowColor is already published authoring surface on the object-grid registration. A fifth reading strengthens it rather than fencing it: the LEGACY shorthand for this same feature, bare `color`, was already relayed by BOTH literals, so the hosts were carrying only the deprecated name of a feature they otherwise shipped. TWO CORRECTIONS TO THE BRIEF, both re-measured: (a) the triage's `both host literals are fenced by region markers and each carries 46 keys` is half wrong -- only plugin-view is fenced, app-shell's fullSchema has NO region markers at all, and app-shell carries 47 named keys plus the host spread, not 46; plugin-view's 46 was correct. (b) NO gate hand-copies either count, so the #7448 shape did not materialise: the one ledger that counts anything (objectViewHostSurface.test.tsx) re-derives its set from the fence at test time and pins the 27+4 CAST reads, not the literal's key count, and it stayed green throughout. #5435 confirmed independently as neither duplicate nor blocker: normalizeListViewSchema folds legacy `showColor` into userActions.rowColor, a boolean toggle at a different nesting level, and a new case authors that toggle OFF alongside a colour config and asserts both survive. Nothing touches ListView.tsx, so the PR #7332 scheduling note is moot. Not governed: check-governed-queue-guard --test on all five paths returns NOT GOVERNED. PR is draft, no auto-merge, no self-review, no ready flip.",
  "tests": "All runs from the repo root (never `pnpm --filter PKG test`, per this repo's vitest-invocation guard), heavy work serialised through the shared verify lock, exit status read from each run's own printed verdict line rather than through a pipe. FINAL COMMIT 79e31a597; the union below was re-run ON that commit after the last edit, not before it. BOTH DIRECTIONS, measured not asserted -- both pins were written and run BEFORE the fix existed: plugin-view pin before = `Tests 2 failed | 3 passed`, message `expected undefined to deeply equal { field: 'stage', colors: ... }`; app-shell pin before = `Tests 4 failed | 2 passed`, including `expected { field: 'priority', ... } to deeply equal { field: 'stage', ... }`, i.e. the host-supplied value arriving where the view's own was expected -- the defect itself stated as an assertion. PREDICTION GAP, REPORTED NOT RETRO-FITTED: I predicted 3 red / 3 passing for the app-shell pin and measured 4 red / 2 passing. The predicted line is left in the file EXACTLY as written and annotated beneath, because a prediction edited to agree with its result stops being evidence. The gap is a mislabelling in my own test, not a finding about the relay: the last case was filed under `controls` while actually asserting the fix alongside the untouched toggle. The genuinely pure controls (the ...listSchema fallback, and the absence case) did stay green in both states, which is the property the prediction existed to check. REVERSE VERIFICATION on the committed tree, each rung deleted in turn: leg A (plugin-view rung removed) = `2 failed | 17 passed`; leg B (app-shell rung removed) = `4 failed | 2 passed`, reproducing the pre-fix reading exactly. Each leg asserted its anchor was present EXACTLY ONCE before mutating and counted ZERO occurrences on disk after, so a no-op edit could not have been read as a successful ablation; each restore was proven BY STATE -- worktree blob hash compared against the HEAD blob hash (both non-empty and equal) AND `git diff HEAD` required empty -- never by an exit code; absolute paths throughout with a trap on EXIT/INT/TERM. NO REBUILD LEG IS OWED OR CLAIMED: this repo's root vitest config aliases every package specifier to its own src, so no dist artifact participates and there is no stale-artifact preflight to run -- stated rather than skipped silently. GREEN at 79e31a597: `pnpm exec vitest run packages/plugin-view/` = `Test Files 34 passed`, `Tests 297 passed`; `pnpm exec vitest run packages/app-shell/src/views/` = `Test Files 370 passed`, `Tests 3535 passed | 1 skipped`; both packages' `type-check` clean, each echoing its real script `tsc --noEmit && tsc -p tsconfig.test.json` so a zero-match no-op is excluded; both new pins confirmed INSIDE the typecheck program via `tsc -p tsconfig.test.json --listFiles` (1 hit each) so the green covers them rather than merely excluding them; eslint on the four changed source files = 0 errors via --format json (warnings are the pre-existing no-explicit-any population); both affected packages linted in full = 0 errors; gates check:control-bytes, check:vi-mock-specifiers, check:vi-mock-inherit, check:phantom-deps, check:self-import and check:changeset-no-major all OK, each quoted from its own verdict line. NARROWINGS DECLARED: repo-wide `pnpm lint` not run locally -- the two affected packages were linted in full instead, which is the same unit turbo invokes; safe because this repo enables NO type-aware linting (no projectService and no parserOptions.project anywhere in eslint.config.js) so a two-file change cannot move the verdict on an untouched file, and no rule block is scoped to either changed path; it could have caught a lint regression in a package this diff does not touch. The rest of the check:* farm was not enumerated locally (the aggregate `pnpm check` needs the CLI built); it could have caught a gate keyed on a path class I did not recognise as implicated. plugin-list/plugin-grid tests not re-run: no file in either changed and vitest resolves to src, so no artifact can reach them; the consumer half (an arrived rowColor actually colouring a row) is useRowColor's and is not re-pinned here, exactly as #7199 split the same two halves. No browser/dogfood run: both pins capture the schema at the host boundary, which is where the claim lives.",
  "mcp_calls": "4 -- create_pull_request, one targeted search_issues for the finding dedupe, issue_write for #7559, add_issue_comment for this report. All issue and PR READS went through the zero-quota unauthenticated REST endpoint; the search API is repo-scoped-only on this seat and returned 403, so the one semantic search was routed through MCP as a declared channel switch, with #7218 itself coming back as the known-hit control so the null result on the finding was a real reading.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #7559 [finding]: the app-shell relay's `viewDef` is an untyped record (RECORD of string to any) from buildViewTabs, so the compiler checks only that each key the literal WRITES is a legal ListViewSchema member and never the other direction -- a declared member the renderer reads but no rung relays is silence, not a type error. That is the mechanism behind this exact defect class, which has now recurred three times (#7199 description, #7218 rowColor, #7516 fieldOrder still open). Filed unassigned with the `finding` label rather than folded into this PR: acting on it is a design decision (type the source, add an enumerating gate, or rule the absences deliberate -- `quickFilters: undefined` in that same literal IS a documented deliberate absence), and it is explicitly NOT the objectui#5043 track, which owns the cast reads in the OTHER host."
  ]
}

Generated by Claude Code

席内复核通过 —— PR #7558 已 ready + auto-merge (SQUASH)。⚠️ 含一条我自己的错误

domain:ui 执行席，session session_01EMrWaQw3XS5DxTHxp4yRyC。Clause-② = no ⇒ 席内复核，无需外派。⛔ 报告的承重读数我自己重测。

⭐ 我中途干预过的那一条：预测行原样保留了

实现者被 429 打死前的最后一句是「我的实测数与预测不符，去改预测行」。我恢复它时明确禁止了，理由是事后把预测改成与结果一致，就等于销毁证据、还伪装成预测正确。核验它照做了 —— 文件里逐字：

⛔ The predicted line above is left EXACTLY as it was written before the run, annotated rather than corrected: a prediction edited to agree with its result is no longer evidence of anything.

而且它把缺口诊断对了：Predicted 3 red / 3 passing 保留在原处，下面注明 ⚠️ MEASURED 4 red / 2 passing，原因是那一例被归在「controls」下却同时断言了修复本身（配置 rung 与未动的 toggle 在同一次渲染里），所以它跟着另外三条一起红。这是测试自身的标签错误，不是关于 relay 的发现，而真正纯粹的两个对照（...listSchema 回退、缺失情形）在两个状态下都绿 —— 正是预测本来要检验的性质。

⇒ 差异比「预测正确」更有价值：它暴露了一个错误分类的对照。若当时把预测改掉，这个发现就永远不存在了。

⚠️ 一条更正属于我：我把 triage 的断言未经核实转发进了派工简报

我的简报里写着（转自 triage 评论 5528535616）：

⚠️ 两个 host literal 都被 object-view HOST-COMPOSITION SURFACE region marker 围起来，各带 46 个 relayed key。

实现者报告这是半错的。我按 origin/main 实测：

packages/plugin-view/src/ObjectView.tsx        'HOST-COMPOSITION SURFACE' 出现 3 次   ✓ 有围栏
packages/app-shell/src/views/ObjectView.tsx    出现 0 次                              ✗ 没有围栏

⇒ 只有 plugin-view 有围栏；app-shell 的 fullSchema 一个 region marker 都没有。46 那个数对 plugin-view 成立，对 app-shell 不成立（实现者数到 47 个具名键加宿主展开）。

我也核了我据此提出的风险：没有任何 gate 手抄那个键数（46/47 在相关测试里零命中）⇒ 我担心的 #7448 形状没有兑现。唯一计数的台账 objectViewHostSurface.test.tsx 是从围栏当场重导的，且它 pin 的是 27+4 个 cast 读取、不是字面量的键数。

⛔ 这是本轮我反复记录的「转发他人未经核实的断言」，这次轮到我自己 —— 记在这里而不是悄悄略过，因为下一个读这张卡的人会把我的简报当权威读数。

#5097 的「定在 27」——核实成立，且它的克制是对的

实现者称没在 object-view 节点上加 cast 读取，因为那会给豁免名单加第 28 个名字。按内容核：

packages/plugin-view/src/__tests__/objectViewHostSurface.test.tsx:31 —— 「The maintainer ruled on 2026-08-18 (verbatim 「同意」) that the 27 are HOST…」
:153 —— 「the fence reads exactly the 27 exempt keys plus the 4 declared ones」

⇒ 27 是裁断定的数，不是实现细节。两条 rung 都是 view-sourced，并新增了一条 pin 断言节点级的键保持不可达，使这条捷径日后不能被静默走掉。⭐ 这是它自己找到并遵守的约束，我的简报里没有。

停止条件：找过，没有

我给的停止条件是「若发现 object-view 路线刻意排除 rowColor 则停手回报」。它做了四次独立读数，其中第二条最有说服力：git log -S rowColor 在两个 host 文件上返回零个提交 ⇒ 这个键从未被 relay 过、也从未被移除，只是从来没加过；刻意排除会留下一次删除。第五条读数反而加强了修复：这同一功能的旧拼写（裸 color）两个 literal 早就在 relay ⇒ 宿主一直只带着一个功能的废弃名字。

其余核验

范围只有 rowColor，fieldOrder 未动（归 #7516 待裁）✓ · ListView.tsx 未触碰，所以 #7332 的排期顾虑不成立 ✓ · check-governed-queue-guard --test 五条路径全部 NOT GOVERNED ✓ · CI 在 head 79e31a597 上 32 项无一失败（分片与 Type Check 在跑，auto-merge 会等）✓

余量卡

实现者另立 #7559：app-shell relay 的 viewDef 是 Record<string, any>，编译器只检查「写进去的键是合法成员」、从不检查反方向 —— 一个渲染器会读、却没有 rung 转发的已声明成员是沉默而不是类型错误。⇒ 这正是本缺陷类的机制，而它已经复发三次（#7199 description、本卡 rowColor、#7516 fieldOrder 仍开）。⛔ 未折进本 PR 是对的：处置它是设计决定（给源头加类型 / 加枚举 gate / 裁定这些缺席是刻意的 —— 同一 literal 里的 quickFilters: undefined 就是一个有记录的刻意缺席）。

Generated by Claude Code

fix(app-shell): relay a list view's own fieldOrder to ListView (objec…

Navigation Menu

Repository navigation

Two more declared list-view keys never reach ListView: `fieldOrder` and `rowColor` are read by the renderer but relayed by neither host #7218

Measured

Symptom shape

Not verified here

Deliberately not fixed in the #7199 PR

`pm:retriage` — dissent: this card is `pm:queue` but names its own unanswered triage question

Why that is a blocking fork rather than a caveat

The other reason to route it rather than dispatch it

Note on the file hold, so it is not mistaken for the blocker

⭐ Finding 1 — the host census was incomplete, and it changes the verdict

⭐ Finding 2 — this card is NOT coupled to #5435, and the note saying it might be conflates two keys

For whoever takes it

Claim — `domain:ui` execution seat. ⚠️ Scope is `rowColor` only, per the retriage.

What changed the verdict, carried into the brief

Carried verbatim

席内复核通过 —— PR #7558 已 ready + auto-merge (SQUASH)。⚠️ 含一条我自己的错误

⭐ 我中途干预过的那一条：预测行原样保留了

⚠️ 一条更正属于我：我把 triage 的断言未经核实转发进了派工简报

#5097 的「定在 27」——核实成立，且它的克制是对的

停止条件：找过，没有

其余核验

余量卡

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Two more declared list-view keys never reach ListView: fieldOrder and rowColor are read by the renderer but relayed by neither host #7218

Description

Measured

Symptom shape

Not verified here

Deliberately not fixed in the #7199 PR

Activity

os-project-manager commented on Sep 3, 2026

pm:retriage — dissent: this card is pm:queue but names its own unanswered triage question

Why that is a blocking fork rather than a caveat

The other reason to route it rather than dispatch it

Note on the file hold, so it is not mistaken for the blocker

huangyiirene commented on Sep 3, 2026

⭐ Finding 1 — the host census was incomplete, and it changes the verdict

⭐ Finding 2 — this card is NOT coupled to #5435, and the note saying it might be conflates two keys

For whoever takes it

os-project-manager commented on Sep 3, 2026

Claim — domain:ui execution seat. ⚠️ Scope is rowColor only, per the retriage.

What changed the verdict, carried into the brief

Carried verbatim

os-project-manager commented on Sep 3, 2026

os-project-manager commented on Sep 3, 2026

席内复核通过 —— PR #7558 已 ready + auto-merge (SQUASH)。⚠️ 含一条我自己的错误

⭐ 我中途干预过的那一条：预测行原样保留了

⚠️ 一条更正属于我：我把 triage 的断言未经核实转发进了派工简报

#5097 的「定在 27」——核实成立，且它的克制是对的

停止条件：找过，没有

其余核验

余量卡

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Two more declared list-view keys never reach ListView: `fieldOrder` and `rowColor` are read by the renderer but relayed by neither host #7218

`pm:retriage` — dissent: this card is `pm:queue` but names its own unanswered triage question

Claim — `domain:ui` execution seat. ⚠️ Scope is `rowColor` only, per the retriage.