docs: Add ADR 004 - Component Library Restructure

[AliceR]

Proposes renaming /storybook to /core and establishing it as the primary location for library components with gradual migration from the current scattered structure.

Context

• Current library components are scattered throughout /app directory
• Need clear separation between library and application-specific code
• Opportunity to modernize build system based on successful Vite adoption

Proposed Solution

• Rename /storybook → /core to reflect library purpose
• Gradual migration strategy with backward compatibility
• Dual build system during transition (legacy Parcel + new Vite)
• Re-export strategy to avoid immediate component copying
• Future state: standalone /core package

Benefits

• Modern development environment with Vite
• Clear component library boundaries
• Unified documentation and development
• Future-proof architecture for standalone library
• Low-risk incremental migration path

With this setup, it will be much easier to keep track of our refactor and migration work!

[netlify]

✅ Deploy Preview for veda-ui ready!

Name	Link
🔨 Latest commit	74cd15f
🔍 Latest deploy log	https://app.netlify.com/projects/veda-ui/deploys/68c7c92a20af810008f8357b
😎 Deploy Preview	https://deploy-preview-1871--veda-ui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[vgeorge]

Hi @AliceR, thanks for putting this ADR together, this is much needed. I agree with the problem statement and the decision to give our component library a proper home.

Thinking about the long term, I’d like to propose a small shift. My view is that the component library should be a standalone package, and apps like Storybook or the legacy SPA should be separated from it. Storybook is just a dev viewer for components (and potentially a docs website in the future), and the SPA in /app is a instance app that uses them and will be deprecated in the future in favor of next-veda-ui.

That’s why I think it makes sense to set up a monorepo with /packages and /apps. It gives us the target structure right away, and the migration then becomes about moving things into the right place.

Proposed steps

Step 1 – Create structure
Root package.json with workspaces (pnpm or yarn). Add /packages and /apps. Create /packages/components as the new clean library folder.

Step 2 – Start migrating components
Bring over the most critical pieces from /app/scripts/components. Keep compatibility by re-exporting.

Step 3 – Move Storybook
Relocate to /apps/storybook. Reconfigure it to import from /packages/components.

Step 4 – Isolate legacy SPA and shared code
Move /app to /apps/legacy-spa. Extract shared utilities into /packages/utils.

Why this path

• Clear separation between reusable packages and runnable apps
• Proper decoupling between the library and its consumers
• A standard, scalable setup that matches what we’ll need as VEDA grows

This follows the spirit of your ADR but pushes us to a more conventional and future-proof end state.

[aboydnw]

How does this approach integrate with the plugin framework repo that we recently started, and with this idea that the plugin marketplace will have plugins made from components outside of veda-ui?