UI Tree Architecture Review

Review the UI tree as a set of ownership and change boundaries. The goal is not a preferred framework pattern or a target number of components; it is a tree whose nodes hide meaningful complexity, expose understandable contracts, and keep likely changes local.

Read REPORT-TEMPLATE.md before writing the report. It is the single source of truth for the output structure. Use the terms node, parent, child, boundary, contract, state owner, composition, locality, and leverage consistently across technologies.

1. Establish scope and evidence

Identify the application entry points and the user-visible tree or trees in scope. Inspect the source files that construct them, the node definitions, styles/layout rules, state and data sources, tests, fixtures, story/demo files, routing, and relevant project instructions. Use repository-native commands and conventions to discover files; do not infer architecture from filenames alone.

Trace each selected tree top-down. For every node, record its parent, children, rendered responsibility, inputs, outputs/events, state read or owned, external effects, styling/layout authority, and tests or isolated examples. Distinguish observed facts from inferences. If the tree cannot be reconstructed from available evidence, report the missing evidence and stop rather than inventing structure.

Completion criterion: the scope names every inspected entry point and selected tree, and the inventory accounts for each visible node's implementation, contract, state/effect source, and available verification evidence.

2. Map the change axes

For the main user flows, simulate representative changes: a visual-only change, a behavior change, a state or data change, an accessibility change, and a cross-cutting change. Follow the files and contracts each change touches. Note repeated edits, prop/event forwarding, hidden context, duplicated state, parent knowledge of child internals, and changes that cross unrelated responsibilities.

Use the deletion test for every proposed boundary: if removing the node merely moves the same coordination and knowledge into its parent, the node is shallow; if it hides policy, layout, state transition, adaptation, lifecycle, or a meaningful variation behind a stable contract, it may be earning its keep. Use the change-axis test: nodes are stronger when the reasons to change inside them travel together and likely changes outside them do not.