chore(mvp): define V1 component recatalogation handoff

[egdev6]

Context

For the MVP, we will keep the current component tasks as they are. Components can still be merged in their current location when they meet the current minimum quality bar.

This means MVP delivery is not blocked by the future component architecture cleanup.

MVP merge rule

A component can be accepted during MVP when it satisfies the current review baseline:

• TypeScript passes.
• Tests exist or the absence of tests is explicitly justified by current infrastructure/scope.
• Storybook coverage is reasonable for the implemented behavior.
• Accessibility basics are covered.
• Token usage does not introduce major visual-system drift.
• No known functional blocker remains.
• Any cataloging mismatch is documented as V1 follow-up work.

Next step after MVP

The recatalogation work moves to milestone V1.

V1 will reorganize the MVP component catalog using the new taxonomy:

• primitives
• atoms
• molecules
• organisms

The V1 work should not be mixed into MVP component PRs unless a change is required to pass the current MVP quality bar.

V1 planning issues

The V1 milestone now tracks the recatalogation work in separate issues:

• Inventory and target taxonomy for all MVP components.
• Primitives and atoms recatalogation.
• Molecules and organisms recatalogation.
• Exports, Storybook, and documentation migration.
• Final verification and cleanup.

[egdev6]

Created V1 recatalogation plan

• chore(v1): inventory MVP components and assign target taxonomy #223 — Inventory MVP components and assign target taxonomy
• refactor(v1): recatalog MVP primitives and atoms #224 — Recatalog MVP primitives and atoms
• refactor(v1): recatalog MVP molecules and organisms #225 — Recatalog MVP molecules and organisms
• docs(v1): update exports, Storybook taxonomy, and migration notes #226 — Update exports, Storybook taxonomy, and migration notes
• chore(v1): verify final component recatalogation #227 — Verify final component recatalogation