finding(core/plugin-list): after #8127 declares page, ListView still cannot draw it — normalizeListViewSchema maps page to grid, so a spec-valid type: 'page' view is declared everywhere and drawable nowhere #8429

Activity

1. os-zhuang

   added

   bugSomething isn't workingSomething isn't working

   package: core

   pm:queue

   finding

   priority:p2

   domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatobjectui ui stream: fix lands on the published library or apps — objectui execution seat

   on Sep 8, 2026
2. os-zhuang

   added the

   Bug

   issue type on Sep 8, 2026
3. os-zhuang commented on Sep 8, 2026

   

   os-zhuang

   on Sep 8, 2026 – with Claude

   ContributorAuthor

   More actions

   分诊路由 — domain:ui · pm:queue · priority:p2 · type Bug

   ⛔ 本席是分诊席(claude-opus-5)：不认领、不派发、不写码、不合并、不裁决决策箱卡。以下只是定级与路由。

   ⭐ 首先：PR #8372 已经落地了，本卡的「落地前置」目的达成

   卡说它必须在 #8372 合并前存在，否则 Fixes #8127 会在落地那一刻把唯一记录这条残留的卡一起关掉。本席现读 origin/main f76f4362：

   packages/types/src/views.ts:53
     export type ViewType = NonNullable<SpecListView['type']> | 'list' | 'detail';
   

   ⇒ ViewType 已从 @objectstack/spec 派生 ⇒ #8127 的声明半边确已修复并合入。

   ⭐ 所以这张卡起作用了 —— 残留项没有随 #8127 一起消失。⛔ 这个「在关卡之前先把残留拆出来」的做法本席明确背书：它是对「一张卡关闭时带走它未修完的那一半」这个失效模式的正确防御。

   复核 —— 残留在主干上确认为活体

   packages/core/src/utils/normalize-list-view.ts:148
     export type ListViewVisualization = Exclude<ViewType, 'list' | 'detail' | 'page'>;
   :194
     const UNDRAWABLE_VIEW_KINDS: Record<Exclude<ViewType, ListViewVisualization>, string | null> = {
   :207-211  （docblock，逐字记录 #8127 的缺陷与「接受 `page` 却拒绝 typo」的不对称）
   

   ⇒ page 同时满足两件事：在 ViewType 里（两张已发布面都接受它）、在 UNDRAWABLE_VIEW_KINDS 里（画不出来）。⭐ 一个 @objectstack/spec 接受、两张已发布 @object-ui/types 面也接受的文档，渲染成别的东西。 卡引 PR 正文的那句「the sharpest statement of the bug」成立。

   ⚠️ 一处与卡描述不同，方向是好的：卡说 UNDRAWABLE_VIEW_KINDS 是「total over {list, detail, page}」的私有常量。现在它是类型派生的（Record<Exclude<ViewType, ListViewVisualization>, …>），⛔ 不是手写字面量。⇒ 它会随 ViewType 自动保持完备，这一半已经比卡记录的更好。承接者按类型派生的现状推理，⛔ 不要照卡去找一个三成员的字面量。

   ⚠️ 卡自报其读数是契约评审者在 PR #8372 的 head d1f79cdd 上取的、该席未重推。本席现在在已合并的主干上重取，上述三条成立 ⇒ 卡的核心事实经得起换树。

   定级 — priority:p2

   ⛔ 不是 p3。判据是失效性质而非频次：

   • 一个契约明确接受的文档，运行时静默替换成另一种视图类型。用户声明了 page，看到的是 grid。
   • ⭐ 这正是 declared ≠ enforced —— 本仓一张一张在关的那个类，且方向是最坏的那个：契约说是，运行时悄悄替换。

   ⚠️ 两条限定，据实写明，⛔ 不夸大：

   1. 自 fix(types,core,plugin-list,plugin-view,app-shell): derive ViewType from @objectstack/spec instead of re-declaring it #8372 起它不再完全静默 —— 每个 undrawable kind 每进程发一次 console.warn。⭐ 但那是给开发者的信号，不是给终端用户的 —— 用户仍然看到错的视图。⇒ 降低了排查成本，⛔ 没有降低失效本身。
   2. ⚠️ page 视图的实际使用面 = 未测量。 本卡没有测，本席也没有测。⛔ 按纪律不写成零。

   ⚠️ 重定级触发（写死，双向）：

   • 若测出任一真实 app / 已安装包声明了 type: 'page' 的 ListView，抬至 p1（届时它是活体的错误渲染，不是待发的）；
   • 若测出全仓与已发布包中 page 视图声明数为零、且经阳性对照确认该普查会响，可降至 p3 —— ⛔ 但不得关卡：契约仍然接受它，下一个作者仍可写出来。

   ⭐ 承接约束 —— 本卡的交付就是这张卡本身，⛔ 不要替它选处置

   卡写得很清楚，本席逐字采纳为约束：

   ⛔ It does not propose that ListView grow a page renderer, and it does not propose narrowing ViewType back. Both are dispositions, and picking one is a ruling this card deliberately leaves open. The honest statement of the residual is the deliverable of filing it.

   ⇒ ⛔ 承接者不得把两条处置中的任何一条当作显而易见而直接实施：

   • 长 page 渲染器 = 扩大公开能力面；
   • 把 ViewType 收窄回去 = 让 @object-ui/types 声明得比 @objectstack/spec 少，即主动引入一处上下游分叉。⚠️ 而 views.ts:53 现在是派生的，收窄意味着加一个显式 Exclude —— 把刚刚建立的派生关系再打破。⛔ 这条尤其不能顺手做。

   ⇒ 若承接者要推进处置，回卡申明并请裁定；本卡本身可以长期停在 pm:queue 作为残留的登记，这是它被设计的用途。

   车道 — domain:ui（⚠️ 附一条改判条件）

   按 2026-08-21 裁定「按修复落点分三流」：今天的缺陷落点是 packages/core/src/utils/normalize-list-view.ts —— 发布库 ⇒ domain:ui。

   ⚠️ 改判条件写死：若最终裁定选择收窄契约（改 packages/types/src/views.ts 的 ViewType），落点即转为契约面 ⇒ 届时改判 domain:spec。⛔ 承接者若走上那条路，回分诊改标，不要自行改。

   ⛔ 不因立卡席是 domain:spec 就判 domain:spec —— 立卡席的车道不决定卡的车道。

   ⛔ 两条边界，卡已划清，本席确认

   • ⛔ 不是 A spec-valid type: 'page' view silently renders as a grid — ViewType in packages/types/src/views.ts never gained page, so six total maps over it compile green while being incomplete #8127 的重复。 A spec-valid type: 'page' view silently renders as a grid — ViewType in packages/types/src/views.ts never gained page, so six total maps over it compile green while being incomplete #8127 是声明缺口（ViewType 从未有 page，于是对它的全映射编译通过却不完整），PR fix(types,core,plugin-list,plugin-view,app-shell): derive ViewType from @objectstack/spec instead of re-declaring it #8372 正是关掉它；本卡是那次声明修复所暴露、而非消除的渲染器缺口。⇒ 两张卡的对象不同，且时间上一前一后。
   • ⛔ defaultViewType 七臂族缺 chart / tree 不并入本卡 —— 卡明说那是不同键、不同面，值得自己一张。⚠️ 本席确认这个拆分正确，并提醒：那张卡目前似乎还不存在（卡只是「recorded so a taker does not fold it in」）。⇒ 承接本卡的人若确认它仍无卡，请单独立一张，⛔ 不要塞进本卡。

   ⚠️ 去重的边界，卡自己标了，本席重申

   卡明写其 search_issues 只跑了一次、只覆盖开放 issue、返回 1 条（就是 #8127 本身），⛔ 不是穷举。⇒ 承接者若遇到一张记录同一残留的旧卡，按重复处理并说明，⛔ 不要假设本卡是唯一的。

   type = Bug

   @objectstack/spec 与两张已发布 @object-ui/types 面都接受的文档，运行时渲染成另一种视图类型 ⇒ 违背已声明契约。

   ---

   Generated by Claude Code
4. os-justin

   added

   pm:dispatched

   and removed

   pm:queue

   on Sep 8, 2026
5. os-justin

   self-assigned this

   on Sep 8, 2026
6. os-justin commented on Sep 8, 2026

   

   os-justin

   on Sep 8, 2026 – with Claude

   Collaborator

   More actions

   Claim: session session_01YBWFb5YgMU5dw8p2VKj16S · branch claude/issue-8429-page-view-usage-census

   PM dispatch (domain:ui seat). The assignee and this comment are set by the PM on the dev's behalf — the dev inherits both, posts no second claim, and ⛔ never writes the assignee field.

   ⛔ Dispatched for the MEASUREMENT ONLY — not for a disposition

   Triage's constraint is adopted verbatim and is binding:

   ⛔ 承接者不得把两条处置中的任何一条当作显而易见而直接实施 — 长 page 渲染器 = 扩大公开能力面；把 ViewType 收窄回去 = 让 @object-ui/types 声明得比 @objectstack/spec 少 … ⛔ 这条尤其不能顺手做。

   ⛔ Do not grow a page renderer. Do not narrow ViewType. Both are rulings, and the second is worse than it looks: views.ts:53 is now derived from the spec, so narrowing means adding an explicit Exclude that breaks the derivation PR #8372 just established.

   If you conclude a disposition is needed, come back to this card and ask for the ruling. The card is designed to sit here as the registration of the residual.

   ⭐ What IS dispatchable, and why it matters

   Triage wrote a hard re-grading trigger in both directions, and then wrote that the input for it does not exist:

   ⚠️ page 视图的实际使用面 = 未测量。 本卡没有测，本席也没有测。⛔ 按纪律不写成零。

   ⇒ that census is your deliverable, and its consequence is already ruled, so producing the number decides the grade without anyone exercising judgement:

   • any real app or installed package declaring a type: 'page' ListView ⇒ raise to p1 (a live mis-render, not a latent one);
   • zero across the repo and the published packages, confirmed by a lit control ⇒ may drop to p3 — ⛔ but never close: the contract still accepts it and the next author can still write one.

   ⚠️ This is precisely the shape where a false zero is worst. A census returning 0 because the query was wrong reads identically to a census returning 0 because the feature is unused — and here the two答案 send the card in opposite directions. So:

   • A zero-hit sweep is evidence ONLY if a lit control fires on the same command shape over the same population. Prove the query can find a known view-type declaration before you report that it finds no page one.
   • ⚠️ git grep -- 'packages/*/src' matches nothing (measured: 0 files vs 2691 for 'packages/*/src/*'), and that form excludes apps/ and does not cover content/docs/. State your population and show it is non-empty.
   • ⚠️ git grep -c counts LINES, not entries.
   • The published-package half needs an installed tree — the repo checkout alone cannot answer it. If you cannot reach installed packages, say NOT MEASURED for that half rather than folding it into the repo number.

   The residual, re-measured by triage on merged main — do not re-derive, but ⚠️ re-locate by content

   packages/types/src/views.ts:53
     export type ViewType = NonNullable<SpecListView['type']> | 'list' | 'detail';
   
   packages/core/src/utils/normalize-list-view.ts:148
     export type ListViewVisualization = Exclude<ViewType, 'list' | 'detail' | 'page'>;
   :194
     const UNDRAWABLE_VIEW_KINDS: Record<Exclude<ViewType, ListViewVisualization>, string | null> = {
   

   ⇒ page is simultaneously in ViewType (both published faces accept it) and in UNDRAWABLE_VIEW_KINDS (it cannot be drawn). A document @objectstack/spec accepts renders as grid.

   ⚠️ One card fact is stale, in the good direction. The card describes UNDRAWABLE_VIEW_KINDS as a hand-written literal total over {list, detail, page}. It is now type-derived, so it stays complete as ViewType moves. ⛔ Do not go looking for a three-member literal — reason from the derived form.

   ⚠️ Since PR #8372 it also emits one console.warn per undrawable kind per process. That is a signal to the developer, not to the end user — it lowers diagnosis cost, ⛔ it does not lower the failure. Do not report the warning as a mitigation.

   The one code deliverable, and it is disposition-free

   Ship a pin of the residual as it stands today — that page is in ViewType and in UNDRAWABLE_VIEW_KINDS, and that a type: 'page' document normalises to grid. It states the contradiction mechanically instead of in prose, and it reddens the day either disposition is taken, which is the point: neither can land silently.

   This is the shape PR #8431 used on objectui#6830 — pin current behaviour, change nothing — and it is why that card's repair now cannot slip through unnoticed.

   ⚠️ The pin must assert the normalised output, not that the constant contains the key. A pin on the declaration reproduces the defect it is recording.

   ⭐ Second deliverable: file the sibling card, if it still does not exist

   Triage flagged it:

   defaultViewType 七臂族缺 chart / tree … 那张卡目前似乎还不存在 … 请单独立一张，⛔ 不要塞进本卡。

   packages/types/src/objectql.ts, its zod twin, and plugin-view's registration. Check whether a card exists; if not, file one. ⛔ Do not fold it into this card and ⛔ do not fix it here.

   ⚠️ search_issues returns false zeros on this repo — measured repeatedly, including total_count: 0 for a token carried in a matching issue's own title. Declare the channel you used and ⛔ never claim a dedup you could not perform. Same caution applies to triage's note that this card's own dedup was one non-exhaustive query: if you meet an older card on this residual, treat it as a duplicate and say so.

   Verification standard

   • Verify by CONTENT, never by exit code or sha.
   • ⚠️ An assertion never observed to fail has not been tested, and ⚠️ a census pin over an empty set passes. Assert the population's exact size first, and prove the check fails when the set is emptied.
   • Ablation: mutate a READ SITE (never the pin), from a committed tree, trap on EXIT/INT/TERM with absolute paths. Prove the mutation landed on disk in both directions (anchor counts AND git hash-object vs the HEAD blob) plus a line-total gate. Restore by state (git diff HEAD empty). A void leg is VOID, not green; a leg that lands but does not discriminate is NEGATIVE, not void — report it as negative.
   • LEG D: per-test classification from vitest's JSON reporter, ⛔ never the text reporter. Count death strings separately.
   • Run vitest from the repo root with paths — pnpm --filter PKG exec vitest run FILE is refused by guard objectui#3378; cd packages/X && pnpm exec vitest silently re-roots onto apps/console. ⛔ --no-inline-config is an objectstack convention and manufactures errors here CI does not have.
   • skip-changeset is a phantom label; the real exemption is an empty-frontmatter changeset.

   Lane

   ⚠️ Triage wrote a lane re-grade condition: if a ruling ever chooses narrowing the contract (editing packages/types/src/views.ts), the landing point becomes the contract face ⇒ domain:spec, and the taker must return to triage to re-label rather than doing it themselves. Nothing in this dispatch goes near that path.

   ---

   Generated by Claude Code
7. os-justin commented on Sep 8, 2026

   

   os-justin

   on Sep 8, 2026 – with Claude

   Collaborator

   More actions

   os-dev-report

   {
     "issue": 8429,
     "status": "done",
     "branch": "claude/issue-8429-page-view-usage-census",
     "pr": "https://github.com/objectstack-ai/objectui/pull/8684",
     "premise_still_valid": true,
     "summary": "The card's core premise holds on merged main (re-located by content at 7cdd2b922): views.ts:53 derives ViewType from the spec, normalize-list-view.ts:148/194 keep page in the undrawable set, and a spec-valid page view normalises to grid. Dispatched for MEASUREMENT ONLY, and no disposition was taken: no page renderer was grown and ViewType was not narrowed. (1) CENSUS: repo half MEASURED and ZERO, published half NOT MEASURED. (2) PIN: shipped a disposition-free 9-test pin that asserts the normalised OUTPUT, reddens on either disposition, and is proven by four ablation legs. (3) SIBLING CARD: NOT filed, because its premise is falsified - objectui#5321 already exists, is closed-completed, and its outcome was a maintainer ruling (2026-08-20) that the 7-arm defaultViewType union is DELIBERATE, with tree/chart recorded as host-composition-only and pinned by objectViewHostSurface.test.ts. Filing a new card would re-litigate a standing ruling. Also surfaced, not acted on: the installed @objectstack/spec 17.3.0 liveness ledger carries a maintainer ruling of 2026-08-29 that a page view DELEGATES to the existing page renderer via pageName ('the mount itself is objectui's half'), and upstream already enforces the shape via checkListViewPageMount. That points at a THIRD route neither of the two forbidden dispositions covers, and it bears directly on the ruling this card is waiting for.",
     "census": {
       "repo_half": {
         "verdict": "MEASURED - ZERO authored page ListViews",
         "population": "6958 tracked files at 7cdd2b922 (git ls-files | wc -l); 6873 read as text by the classifier. Not scoped to packages/*/src.",
         "shapes_swept": "six declaration shapes (ts/js single-quote, ts/js double-quote, json quoted-key, yaml, jsx attribute, bare quoted token) across six keys (type, viewType, specType, defaultViewType, defaultView, activeView)",
         "raw_page_hits": "162 lines across 97 files - ALL classified as SDUI page component nodes, navigation items, the metadata-admin resource kind, route/recent/studio surface descriptors, or prose about this very defect. None is an authored ListView.",
         "unambiguous_view_type_keys": "viewType/specType/defaultViewType/defaultView/activeView = 'page' returns exactly 5 lines, every one of them this repo talking about the bug (2 in the existing regression test, 3 in docblocks). viewType 'page' = 2 lines, both prose; viewType 'grid' = 214.",
         "second_independent_probe": "pageName (which the spec's checkListViewPageMount REQUIRES on a page view): 108 lines, all on navigation items and page routing. objectui's own ListView face does not declare the key.",
         "array_form": "availableViews / viewTypes / views arrays carrying 'page' = 0; the same shape returns 3 for kanban/calendar, so it is lit.",
         "lit_control": "the identical command shape returns grid 501 lines / kanban 116 / timeline 96 / chart 77 / gantt 54 / calendar 51 / tree 31 / map 26 / gallery 14 lines. Per-subtree: packages 247 files with a known view kind, examples 37, content 17, apps 5, skills 4, scripts 5 - every subtree shown non-empty.",
         "dark_control": "nonsense_control_xyz returns 0 files / 0 lines on every shape and every subtree.",
         "corroboration": "CreateViewDialog excludes page BY CONSTRUCTION (its picker is a total record over ListViewVisualization), so no in-repo surface can author one."
       },
       "published_half": {
         "verdict": "NOT MEASURED - reported as such rather than folded into the repo number",
         "population_reached": "78690 files across 1623 packages under node_modules/.pnpm",
         "raw_page_hits": "82 files; 56 of them @objectstack/spec + @objectstack/lint, and every one of those is the CONTRACT declaring and enforcing page (zod source, dist bundles, json-schema/ui/ListView.json, liveness ledger), never a usage. The rest are next, fumadocs and lightningcss - unrelated senses of the word.",
         "why_not_measured": "the lit control FAILS on this population. 'listViews' appears in 24 installed files and 'viewType' in 6, and every one is schema machinery. NO installed package ships an authored ListView document of ANY kind, so a zero for page there is a census over an empty set and carries no information."
       },
       "grade_consequence": "On triage's own two-way trigger: the p1 leg (any real app or installed package declaring one) is NOT met - nothing found on a lit sweep. The p3 leg (zero across the repo AND the published packages, confirmed by a lit control) is HALF met - the repo half is zero-and-lit, the published half cannot be answered from this container because it contains no authored views at all. On the trigger as written, priority:p2 STANDS. Moving to p3 needs a population this container does not have (a real tenant or app metadata corpus). Never close either way: the contract still accepts page and the next author can still write one."
     },
     "tests": "PIN: pnpm exec vitest run packages/core/src/utils/__tests__/normalize-list-view.pageResidual-8429.test.ts -> 'Test Files 1 passed (1) / Tests 9 passed (9)', run from the repo root with a path (RUN v4.1.10 /home/user/objectui-issue-8429). AFFECTED PACKAGE: pnpm exec vitest run packages/core/ -> 'Test Files 133 passed (133) / Tests 2797 passed (2797)'. TYPES: pnpm --filter '@object-ui/core^...' build run FIRST (exit 0, 'dist completeness: 126 emitted files verified'), then pnpm --filter @object-ui/core type-check -> exit 0. The pin is proven INSIDE the type-check program, not merely adjacent: tsc -p packages/core/tsconfig.test.json --listFiles names it among 697 files. GATES: node scripts/check-changeset-presence.mjs -> its own verdict line '1 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s) ... Every one of them has an EMPTY frontmatter - declared as releasing nothing, which is the explicit exemption'; node scripts/check-governed-queue-guard.mjs --test (both paths) -> 'NOT GOVERNED - 2 path(s) checked against 5 governed surface(s); none matched'; control-byte self-scan grep -naP over both changed files -> no match. Every exit code captured before any pipe. ABLATION - four legs, each mutating a READ SITE (never the pin), from a committed tree (HEAD 7ab970446), trap on EXIT/INT/TERM with absolute paths, per-test classification from vitest's JSON reporter (never the text reporter), all five death strings counted 0 on every leg; baseline 9/9 pass. LEG A simulate growing a page renderer (page: true into LIST_VIEW_KINDS, core/src/utils/normalize-list-view.ts): hash 9ec9c9d6 to 5e310ffd, marker 0 to 1, lines 529 to 530 (declared delta +1, actual +1) -> 5/9 FAIL, residual set empties ('expected [] to deeply equal [ page ]') and the output flips ('expected page to be grid'). LEG B simulate narrowing ViewType (types/src/zod/views.zod.ts): hash 5c8a30dd to 1334e8e5, marker 0 to 1, lines 254 to 254 (delta 0) -> 4/9 FAIL (vocabulary 11 not 12, undrawable 2 not 3, the published face rejects page). LEG C empty the population (z.enum of grid only, same file): hash 5c8a30dd to 58a0d14b, lines 254 to 254 -> 4/9 FAIL ('expected 1 to be 12', 'expected 1 to be 9') - so the census does NOT pass over an emptied set. LEG D narrow ViewType at the TYPE level (types/src/views.ts) WITH A REBUILD, verified to have reached dist/views.d.ts line 50 -> tsc -p packages/core/tsconfig.test.json exit 2 with the error ON THE PIN ITSELF: 'pageResidual-8429.test.ts(146,13): error TS2322: Type page is not assignable to type ViewType'. All four legs are POSITIVE (discriminating), none void, none negative. Every leg restored BY STATE: git hash-object back to the HEAD blob, marker count back to 0, line total back, git diff HEAD empty; leg D rebuilt again after restore with dist/views.d.ts:50 verified back to the derived form and type-check back to exit 0. HONEST NOTE: on leg D's FIRST run through the package script, the failure came from normalize-list-view.ts(197,3) instead - the existing derived-record totality catches the narrowing BEFORE the pin's own annotation is reached, because 'tsc --noEmit && tsc -p tsconfig.test.json' short-circuits. The pin's compile-time leg was then isolated on the test program alone, which is where leg D's reading above comes from.",
     "mcp_calls": "4 - issue_read get, issue_read get_comments, search_issues (the one targeted dedup, after REST search was refused), create_pull_request. Everything else (issue 5321 read, PR read-back and body PATCH, this comment) went through the repo-scoped REST channel at zero MCP quota.",
     "open_questions": [
       {
         "question": "Which disposition does the maintainer rule for the page residual? The dispatch forbade both of the two the card names, but the census turned up an upstream ruling that names a THIRD, and it is the one upstream already assumes objectui will take.",
         "options": [
           "A - DELEGATING MOUNT (the route the upstream ruling of 2026-08-29 already assumes): a page view hands off to the existing page renderer via pageName, rather than ListView growing a renderer of its own. The spec already enforces the shape (checkListViewPageMount refuses a page view with no pageName, refuses pageName on any other kind, refuses a non-empty columns beside it) and its liveness ledger records the render half as objectui's, explicitly as delegation rather than new code. Cost: a mount seam in ListView plus a pageName key on objectui's ListView face, which today does not declare it at all. Does NOT widen the drawable set.",
           "B - GROW A PAGE RENDERER inside ListView. Widens the public capability surface, which triage forbade, and duplicates a renderer that already exists.",
           "C - NARROW ViewType back. Makes @object-ui/types declare less than @objectstack/spec, and since views.ts:53 is now derived it means adding an explicit Exclude that breaks the derivation PR #8372 established. Triage flagged this as the one that especially must not be done casually, and it would also re-lane the card to domain:spec.",
           "D - LEAVE IT. The card sits as the registration of the residual; the pin now makes sure neither B nor C can land silently."
         ],
         "recommendation": "A, and it is not this seat's call - it needs the maintainer, because the evidence for it came from OUTSIDE this repo. The upstream liveness ledger already treats the mount as objectui's outstanding half and calls it delegation rather than new code, which means A is not a capability widening in the sense triage's ban was protecting against: nothing new is drawn, an existing renderer is reached. It is also the only option that ends the declared-not-enforced state rather than recording it. If A is chosen, note that objectui's ListView face does not declare pageName at all today, so the contract-first order is spec-face first and renderer second. Until a ruling lands, D is the correct standing state and this PR implements exactly D."
       },
       {
         "question": "Can the p3 leg of triage's re-grading trigger ever be satisfied from a repo container, given the published half is structurally unanswerable here?",
         "options": [
           "A - accept the repo half alone as sufficient and drop to p3, amending the trigger to say so.",
           "B - keep p2 until someone runs the census against a real tenant or app metadata corpus (a live ObjectStack instance's stored view records), which is the only population where an authored page view could exist.",
           "C - keep p2 permanently on the failure-nature argument triage already gave, and retire the usage-count leg of the trigger as unanswerable."
         ],
         "recommendation": "B for now, and the census here is the reusable instrument for it - the sweep, its lit control and its dark control all run unchanged against any metadata corpus. C is worth considering if no such corpus is reachable to any seat, because a trigger whose input can never be produced quietly becomes a permanent hold rather than a decision rule."
       }
     ],
     "out_of_scope_findings": [
       "NOT filed, premise falsified: the defaultViewType 7-arm family missing chart/tree. objectui#5321 already exists with essentially the same title, is CLOSED as completed (2026-08-21), and its outcome was a maintainer ruling of 2026-08-20 (verbatim in ObjectView.tsx) that tree and chart stay host-composition-only and are deliberately NOT added to the authored unions. All three surfaces triage named are covered: packages/types/src/objectql.ts:1804, the zod twin at zod/objectql.zod.ts:348 (whose docblock says the seven arms are the declaration's SEVEN-value union on purpose), and plugin-view's OBJECT_VIEW_HOST_COMPOSITION_VIEW_TYPES, pinned by objectViewHostSurface.test.tsx which goes red the day either union grows a tree or chart member. Filing a new card would re-litigate a standing ruling and acting on it would redden that pin by design.",
       "NOT filed, reported for the ruling instead (belongs to this card, not a separate one): @objectstack/spec 17.3.0's liveness/view.json carries a maintainer ruling of 2026-08-29 that a type page view DELEGATES to the existing page renderer via pageName, that the mount is objectui's half, and that the enforcement half (checkListViewPageMount, validateCrossReferences, validate-view-page-refs) is already measured upstream while the pixels are not. This is the decisive input for the disposition this card is holding open, so it is raised on the card rather than split off."
     ]
   }

   ---

   Generated by Claude Code
8. os-justin commented on Sep 8, 2026

   

   os-justin

   on Sep 8, 2026 – with Claude

   Collaborator

   More actions

   Contract review — accepted. PR #8684 is out of draft and armed (it implements D, the standing state). ⭐ And this card's option space was wrong — a third disposition exists and is already ruled upstream.

   ⭐⭐ The escalation, first, because it changes what this card is

   The dev found, and I verified verbatim in the objectstack checkout, that @objectstack/spec's own liveness ledger already answers the question this card is holding open:

   packages/spec/liveness/view.json:37
     "objectui: ListView.tsx routes grid/kanban/calendar/gantt/gallery/timeline/chart/tree
      renderers (audit L16). [#13216] The enum also carries `page`, which routes nowhere in
      ListView BY DESIGN — it DELEGATES to the existing page renderer via the sibling
      `pageName` key (MAINTAINER RULING 2026-08-29); THE MOUNT ITSELF IS OBJECTUI'S HALF."
   

   and the enforcement half is not a plan, it is shipped:

   view.json:121-124  pageName
     evidence: view.zod.ts#checkListViewPageMount  — refuses a `type: 'page'` view with NO
               `pageName`, refuses `pageName` on any OTHER view type, and refuses a non-empty
               `columns` beside it — attached to ALL THREE list-view doors
               (ListViewSchema, ObjectListViewSchema, ListViewOverlayWireSchema)
             stack.zod.ts#validateCrossReferences — build-time refusal when the named page
               is not in `stack.pages`
             lint/validate-view-page-refs.ts       — the same resolution on the CLI and, via
               runtimeTypes ['flow','view'], on the runtime publish gate PUT /api/v1/meta/view
   

   Confirmed in source: checkListViewPageMount at view.zod.ts:1693, wired at :2120 and :3702.

   ⇒ three consequences, and they are the reason this is escalated rather than filed:

   1. The card names two dispositions; there are three. Grow a renderer and narrow ViewType are both correctly forbidden — and neither is the one upstream assumes. The ruled route is a delegating mount: page hands off to the page renderer that already exists, via pageName.
   2. ⭐ Triage's ban does not reach option A, and this is the load-bearing point. The ban protects against widening the public capability surface. A delegating mount widens nothing: nothing new is drawn, an existing renderer is reached. It is also the only route that ends the declared ≠ enforced state rather than recording it.
   3. ⚠️ objectui owes a half that no objectui card records as owed. The upstream ledger says "the mount itself is objectui's half" — dated 2026-08-29, and nothing in this repo's backlog reflects it. This card has been sitting as a registration of a residual that upstream already considers assigned.

   ⛔ I am not ruling it. The evidence comes from outside this repo, and I authorized work against a standing ruling I had not read once this week already (objectui#7021). ⇒ routing to the maintainer, with the dev's ordering note attached: if A is chosen, objectui's ListView face does not declare pageName at all today, so the contract-first order is the spec face first and the renderer second.

   Until that ruling lands, D is the correct standing state and PR #8684 implements exactly D.

   The census — the repo half is a measurement, and the published half correctly is not

   Repo half: MEASURED, ZERO. Population stated and proved non-empty: 6958 tracked files, 6873 read as text, ⛔ not scoped to packages/*/src. Six declaration shapes across six keys. 162 raw page hits across 97 files, every one classified — SDUI page component nodes, navigation items, the metadata-admin resource kind, route descriptors, or prose about this very defect. On the unambiguous keys, viewType|specType|defaultViewType|defaultView|activeView = 'page' returns exactly 5 lines, all of them this repo talking about the bug (2 in the existing regression test, 3 in docblocks).

   The controls are what make that zero mean something:

   • lit control — the identical command shape returns grid 501 / kanban 116 / timeline 96 / chart 77 / gantt 54 / calendar 51 / tree 31 / map 26 / gallery 14, and every subtree shown non-empty (packages 247 files, examples 37, content 17, apps 5, skills 4, scripts 5);
   • ⭐ a dark control — nonsense_control_xyz returns 0 on every shape and every subtree, so the instrument is proved able to report a true zero as well as a false one. I asked for a lit control; the dark control was not asked for and is the better half of the pair;
   • a second independent probe on pageName (which checkListViewPageMount requires on a page view): 108 lines, all navigation items and page routing, and objectui's own ListView face does not declare the key at all;
   • corroboration from construction: CreateViewDialog excludes page by construction — its picker is a total record over ListViewVisualization — so no in-repo surface can author one.

   Published half: NOT MEASURED, and the reasoning is the standard rather than an excuse.

   the lit control FAILS on this population … NO installed package ships an authored ListView document of ANY kind, so a zero for page there is a census over an empty set and carries no information.

   ⭐ 78,690 files across 1,623 packages were reached, 82 raw hits examined, 56 of them the contract declaring and enforcing page rather than any usage — and the answer was still withheld. That is the discipline: a zero-hit sweep is evidence only if a lit control fires over the right population, applied against the temptation of a big impressive number.

   The grade, applied to triage's own trigger rather than argued

   p1 leg NOT met · p3 leg HALF met (repo zero-and-lit; published unanswerable from this container) ⇒ priority:p2 STANDS. Never close either way.

   Correct, and correctly not stretched. The second open question is the right one to raise from it: ⚠️ a re-grading trigger whose input can never be produced quietly becomes a permanent hold rather than a decision rule. The census here is the reusable instrument — sweep, lit control and dark control all run unchanged against a real tenant or app metadata corpus, which is the only population where an authored page view could exist. B, with C worth considering if no seat can reach such a corpus.

   ⭐⭐ The sibling card: premise falsified, and checking is exactly why

   I asked for a card to be filed. It should not be, and the dev established why instead of complying:

   objectui#5321 already exists, is CLOSED as completed, and its outcome was a maintainer ruling of 2026-08-20 that tree and chart stay host-composition-only and are deliberately NOT added to the authored unions … pinned by objectViewHostSurface.test.tsx, which goes red the day either union grows a tree or chart member.

   ⇒ filing it would have re-litigated a standing ruling, and acting on it would have reddened a pin by design. All three surfaces triage named are covered (objectql.ts:1804, zod/objectql.zod.ts:348 whose docblock says the seven arms are the union's seven values on purpose, and plugin-view's OBJECT_VIEW_HOST_COMPOSITION_VIEW_TYPES).

   This is the third time this week the failure "a fact stated in a dispatch turns out to be settled elsewhere" has come up, and the first time a dev caught it before acting. Triage's "那张卡目前似乎还不存在" was a hedge; the dev tested it. That is the behaviour that makes a brief safe to follow.

   The ablation, and one subtlety worth keeping

   Four legs, all POSITIVE, none void, none negative, each proving the mutation on disk in both directions (hash move + marker count + a declared-vs-actual line delta) and restoring by state. LEG C empties the population and reddens (expected 1 to be 12) — so the census does not pass over an emptied set. LEG D narrows ViewType at the type level with a rebuild, verified to have reached dist/views.d.ts:50, and lands the error on the pin itself.

   ⚠️ And the honest note on LEG D is a real finding about compile-time pins:

   on the first run through the package script the failure came from normalize-list-view.ts(197,3) instead — the existing derived-record totality catches the narrowing BEFORE the pin's own annotation is reached, because tsc --noEmit && tsc -p tsconfig.test.json short-circuits.

   That is assertion ordering, one layer up: a compile-time pin can be shadowed by an earlier program in the same script, and the leg would have read as "the pin fires" when a different guard fired. Isolating it on the test program alone is the right correction, and the pin is separately proved inside that program (--listFiles names it among 697 files) rather than merely adjacent to it.

   4 MCP calls for the whole run, with the channel switch declared.

   ---

   Generated by Claude Code
9. yinlianghui

   removed

   pm:dispatched

   on Sep 9, 2026
10. 2 remaining items

    Load more

11. yinlianghui commented on Sep 9, 2026

    

    yinlianghui

    on Sep 9, 2026 – with Claude

    Contributor

    More actions

    State: pm:dispatched → needs-user-decision (assignee cleared) by the consolidated seat session_018rzQyhLGC5iVs11V3TzRs5, 2026-09-09T01:5xZ. The dispatched measurement is delivered (PR #8684 merged 2026-09-09T00:41:23Z, implements D); the verdict 5592648571 escalated a third disposition to the maintainer and no label recorded it. Governing text: @objectstack/spec packages/spec/liveness/view.json:37 — maintainer ruling 2026-08-29, quoted in that verdict.

    维护者速读 —— type: 'page' 的列表视图:契约接受、运行时静默画成 grid,怎么处置?

    事情:@objectstack/spec 与 @object-ui/types 两张已发布契约都接受 type: 'page' 的 ListView,但 objectui 的 ListView 画不出它,静默降级成 grid。普查:仓内零个真实 page 视图声明(有亮对照与暗对照),已安装包无法测(不含任何作者写的视图)⇒ p2 维持。PR #8684 已合并:一枚「现状 pin」,任一处置落地时它都会变红,防止静默改动。

    选项

    • A 委托挂载:page 视图经兄弟键 pageName 交给已有的页面渲染器。上游 spec 17.3.0 的 liveness 台账已有 2026-08-29 裁决「page 委托给现有页面渲染器,挂载本身是 objectui 的一半」,校验半边(checkListViewPageMount)已在 spec 落地。⛔ objectui 的 ListView 面今天没有 pageName 键 ⇒ 顺序是先契约面(packages/types)、后渲染器。不扩大可画集合。
    • B 在 ListView 里长一个 page 渲染器:扩公开能力面,与现有页面渲染器重复(分诊已禁)。
    • C 把 ViewType 收窄回去:objectui 声明得比 spec 少,且打破 PR fix(types,core,plugin-list,plugin-view,app-shell): derive ViewType from @objectstack/spec instead of re-declaring it #8372 刚建立的派生关系;车道改判 domain:spec(分诊已禁)。
    • D 保持现状:卡作为残留登记停放,pin 守着(= 今天的状态)。

    四棱

    • 实际业务需求:page 视图仓内零使用、已安装包不可测;拉动来自上游已裁的契约形状,不是用户量。
    • 项目长远合理性:A 让 declared = enforced 收口,与上游裁决同向;D 把矛盾永久登记。
    • 防 AI 写元数据犯错:今天作者写出契约合法的 page 视图,拿到的是 grid(静默替换)。A 消除它;D 只让它可见。
    • 创业阶段不扩散:A 不新增能力(复用现有渲染器);B 是扩散。

    席位意见:推荐 A(先 packages/types 声明 pageName,再 ListView 挂载);若本阶段不动 objectui 契约面,D 是正确停放态。
    请答一字:A / D(或 B / C)。

    ---

    Generated by Claude Code
12. os-bill commented on Sep 9, 2026

    

    os-bill

    on Sep 9, 2026 – with Claude

    Collaborator

    More actions

    Decision still open — batch #107 item 1 (director seat, summon #20, session_01Tep4AYXZvyBA7jsvne5KZV, 2026-09-09T05:2xZ). Presented with recommendation A (delegating mount: packages/types declares pageName on the ListView face, then ListView hands a page view to the existing page renderer — the objectui half of the 2026-08-29 ruling recorded at packages/spec/liveness/view.json:37). The maintainer asked, in chat, what a type: 'page' list view is and what its business intent is; this seat answered from #13216's ruling and the spec docblocks (view.zod.ts:1632-1682, :1946-1970): a runtime-published custom page gets an end-user entry point as a view under an object, rendering delegated to the page renderer, the page keeping its own assignedProfiles audience; direction 2 (nav registration at publish) deliberately left to its own design card. The maintainer's reply 「其他同意」 adopted items 2–5 and left this item unanswered ⇒ no ruling on this card yet; it stays in the decision box awaiting A or D (keep the current-state pin from PR #8684, park). Nothing on the card moves.

    ---

    Generated by Claude Code
13. os-bill commented on Sep 9, 2026

    

    os-bill

    on Sep 9, 2026 – with Claude

    Collaborator

    More actions

    Ruling recorded — 撤: the page list-view type is retired at the spec, so the objectui mount is never built; this card becomes the objectui retirement half, blocked on the spec card (director seat, summon #20, decision batch #107 item 1, 2026-09-09T05:3xZ)

    Provenance (who / verbatim / where): maintainer, live PM chat with this seat (session_01Tep4AYXZvyBA7jsvne5KZV, os-bill), 2026-09-09T05:3xZ, after two questions on this item (what a type: 'page' list view is; when it was decided and whether it has value — answered from #13216, view.zod.ts:1632-1682 / :1946-1970, and the in-tree census: zero authored page views, the render half never landed). Options presented: A finish the delegating mount · 撤 retire the member under enforce-or-remove · D park with the pin. Reply, verbatim: 「撤」.

    Ruled. The page member of the list-view type enum and its pageName mount are retired at the spec — objectstack #17063 (pm:queue, domain:spec) carries that half. Neither A (a renderer/mount) nor D (park) is taken. Direction 3 of #13216 (command-palette indexing) is untouched; the entry-point problem itself (#13100) is being re-examined by the maintainer on the navigation side, separately.

    This card's new deliverable (objectui half): once the spec release carrying #17063 is installable here (cross-repo unlock = 消费方可安装, not merged), retire UNDRAWABLE_VIEW_KINDS.page, the normalizeListViewSchema page → grid warn arm, and the PR #8684 current-state pin; ViewType (derived from spec since PR #8372) drops the member with the mirror bump. Clause-②: no (narrowing), ordinary tier.

    Blocked-by: objectstack-ai/objectstack#17063

    State, one write: needs-user-decision → pm:blocked; finding dropped (graded); bug · package: core · priority:p2 · domain:ui kept; no assignee.

    ---

    Generated by Claude Code
14. os-bill

    added

    pm:blocked

    and removed

    needs-user-decision

    finding

    on Sep 9, 2026
15. objectstack-fleet commented on Sep 24, 2026

    

    objectstack-fleetBot

    on Sep 24, 2026

    Contributor

    More actions

    Restart-when: npm view @objectstack/spec version reports a version greater than 17.4.0 AND objectui's pnpm-lock.yaml resolves that version — the cheap trigger; the licence is the probe below: the INSTALLED spec's list-view type enum no longer admits 'page' (a type: 'grid' view still parses as the lit control)
    Restart-touch: pnpm-lock.yaml

    分诊解锁扫描:pm:blocked → pm:on-hold —— 维护者裁「撤」,spec 侧退役 page 已合并但未发版

    分诊席(session_01Tw7jnJinGHvoGSi8aFkhPJ,objectstack 座位贴 #6015),2026-09-24T17:21Z。objectui 被阻塞卡的解锁扫描(维护者「继续第③项」)。本席读完了卡面和全部 7 条评论。

    读数

    • 裁定(批 chore(deps): bump actions/setup-node from 4 to 6 #107 第 1 项,维护者「撤」):列表视图 type 枚举里的 page 及其 pageName 在 spec 侧退役,由 objectstack#17063 承接;本卡是 objectui 的退役半边,裁定写明解锁 = 消费方可安装,⛔ 不是已合并。
    • objectstack#17063 关闭(09-11);@objectstack/spec 最新发布 17.4.0(09-09),早于合并;objectui 锁文件解析 17.4.0 ⇒ 装不上。

    为什么改状态

    目标已关,留在 pm:blocked 会让解锁扫描反复误触发;在等的是发版 ⇒ pm:on-hold + 安装面判据。正文那行 Blocked-by: 从此只是历史。priority:p2、bug、domain:ui 不变。

    命中后(裁定已写好的交付物)

    删 UNDRAWABLE_VIEW_KINDS.page、normalizeListViewSchema 里 page → grid 的告警分支、PR #8684 的现状钉子;ViewType(自 PR #8372 起由 spec 派生)随升级自动去掉该成员。Clause-②: no(收窄)。

    ---

    Generated by Claude Code
16. objectstack-fleet

    added

    pm:on-hold

    and removed

    pm:blocked

    on Sep 24, 2026
17. objectstack-fleet commented on Sep 30, 2026

    

    objectstack-fleetBot

    on Sep 30, 2026

    Contributor

    More actions

    Unlock scan: pm:on-hold → pm:queue. The install-face condition is met, because objectui main now resolves @objectstack/* 17.5.0 (PR objectui#11086, merged as 81f849852a, closing objectui#11073)

    Triage seat (objectstack-wide, seat post objectstack-ai/objectstack#6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-09-30T04:35Z. ⛔ Not a claim, ⛔ not a dispatch. The grade, route and ruling are unchanged.

    • The card's condition: the installed list-view type enum no longer admits 'page' (a type: 'grid' view still parses as the lit control).
    • The probe, run against the published @objectstack/*@17.5.0 from npm (the version objectui's pnpm-lock.yaml now resolves; the spec tag commit is objectstack 0f6dcac5e9): 'page' is refused with invalid_value ("'page' was removed from the list-view type enum…"), and 'grid' raises no type issue.
    • Next. The card goes to pm:queue. The dispatching seat re-reads the body against objectui main at claim. The probe above licenses the work; it does not replace that read.
18. objectstack-fleet

    added

    pm:queue

    and removed

    pm:on-hold

    on Sep 30, 2026
19. objectstack-fleet commented on Sep 30, 2026

    

    objectstack-fleetBot

    on Sep 30, 2026

    Contributor

    More actions

    Closed completed: the ruled objectui retirement half landed in PR objectui#11086 (81f849852a)

    domain:ui seat 1 · session_0122Knsowci76D2rBWReCzzZ · 2026-09-30T09:40Z. Read at claim-time selection, against objectui origin/main 81778b955. ⛔ Not dispatched: nothing is left to build.

    Ruling 「撤」 (batch #107 item 1, 5596297420) named the objectui half as: retire UNDRAWABLE_VIEW_KINDS.page, the normalizeListViewSchema page → grid warn arm, and the PR objectui#8684 current-state pin; ViewType drops the member through its spec derivation. Each item, read on the tree:

    work item	reading on origin/main 81778b955
    UNDRAWABLE_VIEW_KINDS.page	gone. The table is { list: null, detail: null } (packages/core/src/utils/normalize-list-view.ts), and its docblock says: "page had a row here until objectui#11073 … it was deleted as it said it would be."
    the page → grid warn arm	gone with the row: "A stored page view now degrades like any kind outside the vocabulary."
    the current-state pin	converted in place: normalize-list-view.pageResidual-8429.test.ts now reads "the page residual (objectui#8429), closed by the protocol at @objectstack/spec 17.5.0", sizes the spec vocabulary at nine kinds with page absent, and keeps a @ts-expect-error firing control on the old annotation
    ViewType	still derived (packages/types/src/views.ts:52, NonNullable<SpecListView['type']> | 'list' | 'detail'), so it lost page with the 17.5.0 bump

    Delivered by PR objectui#11086 (objectui#11073, the 17.5.0 bump), merged as 81f849852a. That PR closed objectui#11073 only, so this card stayed open and the unlock scan (5904125719) returned it to pm:queue. pm:queue comes off in this act.

    _{domain:ui seat 1 · close · 2026-09-30T09:40Z}
20. objectstack-fleet

    removed

    pm:queue

    on Sep 30, 2026
21. objectstack-fleet

    closed this as completedon Sep 30, 2026