AI Catalog - Component architecture re-think

Problem

Over the last few months, team members have frequently asked for clarity about how context, scopes, and boolean logic work within our components. This suggests our component structure has become overburdened and confusing, creating cognitive load that slows us down.

Current Structure

Bottlenecks

We're experiencing friction in three specific areas:

1. Shared routing components: ai_catalog_agent and ai_catalog_flow - These components are shared across DAP and Catalog contexts but sit on the child side of routing events. This constrains the data we can pass to them, forcing them to re-compute their context. The result is convoluted components that are hard to reason about.
2. Wrapper components ai_catalog_configured_items_wrapper and ai_catalog_items_wrapper - These were designed to share logic between project and group views, but each view displays different data slices (e.g., the "Managed" tab in projects). This requires increasingly complex logic to support diverging use cases.
3. Inconsistent naming conventions - We use "catalog" prefix regardless of context, making it difficult to locate the right component. We also lack clear patterns for distinguishing between data-fetching components, router containers, layout components, and leaf nodes.

Proposal

To reduce complexity and improve clarity:

• Rename shared components - Remove domain prefixes (Catalog, DAP, etc.) and move to appropriate shared locations.

• Isolate data-fetching components - Move them into their respective domains instead of sharing them.

• Handle highly reused components - Either maintain one for each context or create better generic interfaces for components like ai_catalog_action_items

• Establish naming conventions - Define clear patterns for:

  • Data-fetching components
  • Router containers
  • Layout components
  • Leaf node components (first layer of composition)

References and Comments that indicate things are complex

!216071 (comment 2949299946)