You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
finding(types,plugin-tree): the per-view tree config ObjectTree reads from a host-composed view (parentField, labelField, fields, defaultExpandedDepth) is declared by no exported type — only the module-local TreeConfig in ObjectTree.tsx #8253
Filed by the domain:devx @ objectui execution seat (PM session session_01FhBNJcLRZLe8M87VcUgpKr, R46, 2026-09-07T05:12Z) from the objectui#5174 batch-33 report (PR #8251, head ef6bf35f1). Dedup: the seat's REST list read over 446 open issues (control term check-doc-snippet-types: 21 hits) finds no card naming TreeConfig, schema.tree, or a host-only config type; objectui#7917 names ObjectTreeSchema on a different question (the authored node schema's export/registration), not this one.
What the tree says (738a20949, re-verified by the seat)
objectui#5321 (maintainer ruling B, 2026-08-20, implemented in PR Record tree and chart as host-composition-only view types, and give tree its icon (#5321) #5589): tree and chart are host-composition-only view types — neither ObjectViewSchema.defaultViewType (packages/types/src/objectql.ts:1804) nor NamedListView.type (:1988) admits them; the tree branch runs only when a host passes ObjectView a views prop.
On that path the renderer reads a per-view config: packages/plugin-tree/src/ObjectTree.tsx:109 (schema.tree || schema.filter?.tree), then :116–120 (parentField, labelField, defaultExpandedDepth, fields). The only declaration of that config's shape is the module-local, non-exportedTreeConfig at ObjectTree.tsx:81.
The live host is the console (stored view records passed as views; its create-view dialog offers tree). So a real consumer writes this config today with no type to write it against, and the plugin README (before PR docs(plugin-tree): compile the README's snippet against the authorable surface #8251) taught it as if it were authored metadata — which is how batch 33 found it.
Why it is a finding, and what the decision is
Declared ≠ enforced on a host contract: the ruling deliberately keeps tree off the authored unions, but "host-only" does not by itself say whether the host config should have an exported type. Two honest routes: (a) export a TreeViewConfig (or fold it into the host views entry type ObjectViewProps.views element) so the console and any other host write it against a contract; (b) record it as intentionally untyped host config in the same place #5321's exemption is recorded, so nobody re-derives a local interface (objectui#7646's private-copy shape — PR #8251 deliberately did not). Either is a packages/types / plugin-treesrc/** change and a maintainer-adjacent question, so it is a card, not a burn-down rider. Related, recorded not carded: ObjectTree.tsx:119 reads schema.titleField as a labelField fallback, and titleField is not declared on ObjectTreeSchema.
Verification recipe
git fetch origin main
git show origin/main:packages/plugin-tree/src/ObjectTree.tsx | sed -n '78,90p;105,122p'
git grep -n "TreeConfig" origin/main -- packages/types/src packages/plugin-tree/src
Filed by the
domain:devx @ objectuiexecution seat (PM sessionsession_01FhBNJcLRZLe8M87VcUgpKr, R46, 2026-09-07T05:12Z) from the objectui#5174 batch-33 report (PR #8251, headef6bf35f1). Dedup: the seat's REST list read over 446 open issues (control termcheck-doc-snippet-types: 21 hits) finds no card namingTreeConfig,schema.tree, or a host-only config type; objectui#7917 namesObjectTreeSchemaon a different question (the authored node schema's export/registration), not this one.What the tree says (
738a20949, re-verified by the seat)treeandchartas host-composition-only view types, and givetreeits icon (#5321) #5589):treeandchartare host-composition-only view types — neitherObjectViewSchema.defaultViewType(packages/types/src/objectql.ts:1804) norNamedListView.type(:1988) admits them; thetreebranch runs only when a host passesObjectViewaviewsprop.packages/plugin-tree/src/ObjectTree.tsx:109(schema.tree || schema.filter?.tree), then:116–120(parentField,labelField,defaultExpandedDepth,fields). The only declaration of that config's shape is the module-local, non-exportedTreeConfigatObjectTree.tsx:81.views; its create-view dialog offerstree). So a real consumer writes this config today with no type to write it against, and the plugin README (before PR docs(plugin-tree): compile the README's snippet against the authorable surface #8251) taught it as if it were authored metadata — which is how batch 33 found it.Why it is a finding, and what the decision is
Declared ≠ enforced on a host contract: the ruling deliberately keeps
treeoff the authored unions, but "host-only" does not by itself say whether the host config should have an exported type. Two honest routes: (a) export aTreeViewConfig(or fold it into the hostviewsentry typeObjectViewProps.viewselement) so the console and any other host write it against a contract; (b) record it as intentionally untyped host config in the same place #5321's exemption is recorded, so nobody re-derives a local interface (objectui#7646's private-copy shape — PR #8251 deliberately did not). Either is apackages/types/plugin-treesrc/**change and a maintainer-adjacent question, so it is a card, not a burn-down rider. Related, recorded not carded:ObjectTree.tsx:119readsschema.titleFieldas alabelFieldfallback, andtitleFieldis not declared onObjectTreeSchema.Verification recipe
Refs objectui#5174, PR #8251, objectui#5321, objectui#7917.
Generated by Claude Code