04 — Existing Component Inventory and Reuse Map
Objective
Reuse valid existing frontend components before creating new ones. The implementation must inspect the repository and classify components instead of replacing department workspaces with generic templates.
Required inventory roots
apps/web/src/components/activation
apps/web/src/components/l1/domains/*/views
apps/web/src/components/l1/workspace
apps/web/src/components/l1/navigation
apps/web/src/components/l1/workbench
apps/web/src/components/connectivity
apps/web/src/components/governance
apps/web/src/components/intelligence
apps/web/src/components/_deprecated
Classification
| Classification | Meaning |
|---|---|
| Keep | Component and data boundary are already suitable |
| Adapt | UI is useful but routing, state, or data source must change |
| Move | Useful component is under a deprecated or incorrect path |
| Merge | Multiple components implement the same user surface |
| Retire | Component encodes an obsolete product, runtime, or provider assumption |
| Missing | No reusable implementation exists |
Inventory record
export interface ComponentInventoryRecord {
path: string;
exportedName: string;
domain: string;
viewId: string;
routeCandidate: string;
classification: "keep" | "adapt" | "move" | "merge" | "retire" | "missing";
localInteractions: string[];
dependencies: string[];
notes?: string;
}
Department views
Every component under apps/web/src/components/l1/domains/*/views must be recorded with:
- Department
- View label
- Route
- Required permissions
- Applicable industries
- Existing filters
- Existing cards, tables, charts, drawers, and actions
- Missing local interactions
- Twin opportunity points
Account Success requirement
The Account Success inventory is the first required mapping. All valid views in apps/web/src/components/l1/domains/account-success/views must be included in the Work registry. A generic Account Success lens does not replace these views.
Template reuse rule
External template categories may provide interaction and layout patterns for authentication, dashboards, agents, AI workspaces, inboxes, marketplaces, tables, and responsive layouts. They must not replace repository-native domain views or introduce a second design system.
Provider boundary review
Flag any frontend component that directly imports or calls:
- Supabase or database clients
- Redis, KV, or object storage SDKs
- Nango or provider SDKs
- Descope management APIs
- MCP runtime clients
- Model provider clients
- Firebase
These components must be adapted to local frontend contracts for the v0 UI increment.
Deliverable
The implementation report must include a table of inventoried components, classifications, final routes, and whether each was reused, moved, adapted, merged, retired, or newly created.