Extension: :tree_view sub_group nesting + file_leaf row variant

[ty13r]

Context

Audited under ariston-ui Wave AshUI-3.7 comp-fidelity audit. The :tree_view canonical widget needs two related extensions: sub_group nesting for Explorer's repo → kind hierarchy, and a file_leaf row variant for folder-path rows distinct from artifact rows.

Canonical-kind grep proof:

• Renderer (live_ui): packages/live_ui/lib/live_ui/renderer.ex:644 — def render(%{element: %Element{kind: :tree_view}})
• IUR widget enumeration: packages/unified_iur/lib/unified_iur/widgets.ex:35 — @data_view_kinds [:list, :table, :tree_view, :stat, :key_value, :info_list]
• NOT in packages/unified-ui/lib/unified_ui/widget_components.ex catalog — predates PR Catalog schema relaxation: drop source field (per Pascal Discord 2026-05-16) #178/Shell primitives: author 7 widgets (top_strip, mode_nav, sidebar_*, unread_badge, command_palette) #179. Confirming current canonical status with Pascal (same as sibling :tabs extension issue).

Comp gap (audit findings EX-1 + EX-2, extension table lines 243-244)

Audit	Missing	Comp use case
EX-1	sub_group nesting	Explorer surface: repo → kind sub-group (ADRs / Specs / Plans) → leaf rows
EX-2	file_leaf row variant	Explorer + Map: folder-path file rows distinct from artifact rows

These are grouped because both extend :tree_view's node-shape and they may compose together in the file_tree_browser widget being proposed separately at Wave 3.7-B (see ariston-ui/.spec/proposals/widgets/file_tree_browser.md once filed).

Proposed extensions

EX-1: sub_group nesting

Add a :sub_group node kind alongside :artifact_row and the proposed :file_leaf:

tree_view_node:
  kind: :folder | :sub_group | :artifact_row | :file_leaf   # :sub_group NEW
  label: String.t()
  children: [tree_view_node()]    # for :folder + :sub_group only
  ...

:sub_group differs from :folder in semantics:

• :folder represents filesystem-style folder hierarchy
• :sub_group represents a categorical grouping (e.g., "ADRs", "Specs") within a repo card

The visual treatment may differ: :folder has the expand chevron; :sub_group may use a header style + dimmed appearance.

EX-2: file_leaf row variant

Add a :file_leaf node kind for filesystem-path row rendering:

file_leaf_node:
  kind: :file_leaf
  path: String.t()           # e.g., "lib/foo/bar.ex"
  name: String.t()           # e.g., "bar.ex"
  glyph: String.t() | nil    # extension-derived OR explicit
  meta: map() | nil          # last-modified, size, etc.

Distinct from :artifact_row because:

• :file_leaf is filesystem-anchored (path + name)
• :artifact_row is artifact-anchored (id + title + status + counts)

Both render as leaf rows but with different attr shapes.

Open questions for Pascal

1. :tree_view extension vs new canonical kind? (Repeated from audit row 219.) The proposed file_tree_browser widget (filed at ariston-ui .spec/proposals/widgets/file_tree_browser.md — separate spec) might be a sibling kind. If file_tree_browser is its own kind, do these :tree_view extensions still belong on :tree_view?
2. Canonical authority: same as sibling :tabs extension — is :tree_view in unified_iur/widgets.ex still authoritative, or does it need migration into widget_components.ex first?
3. :sub_group semantics: how does Pascal want to express categorical-group vs folder-hierarchy distinction? Different kind (proposed), or single :folder kind with a variant attr (:folder | :sub_group)?
4. :file_leaf glyph computation: derived from extension server-side or client-side? Pure attr or computed convention?
5. Mixed-mode trees: can a :folder contain both :sub_group children AND :file_leaf children, or are levels homogeneous?
6. :artifact_row and :file_leaf overlap: should :file_leaf actually be a variant of :artifact_row, sharing most attrs but with file-specific semantics? Cleaner ontology.

ARIA implications

• :sub_group: render as a role="group" container with aria-label={label}
• :file_leaf: aria-label="File: {name}" for the row; standard treeitem semantics for tree-view containment

Cross-references

• Comp-audit: ariston-ui docs/wave-ashui-3-7-comp-fidelity-audit.md extension table lines 243-244 + audit gap table line 219
• Audit findings EX-1 (sub_group) + EX-2 (file_leaf)
• Related spec: file_tree_browser widget proposal (forthcoming at ariston-ui .spec/proposals/widgets/file_tree_browser.md)
• Sibling extension issue: :tabs count badge (similar canonical-authority question)
• :artifact_row canonical: packages/unified-ui/lib/unified_ui/widget_components.ex:97 (composition consideration per Q6)
• Wave 3.7-A retrospective: ariston-ui docs/wave-ashui-3-7-a-retrospective.md

Status

DRAFT extension proposal — Pascal's design calls on (Q1) :tree_view extension vs new file_tree_browser kind and (Q2) canonical authority + migration to widget_components.ex likely determine the scope substantially.