Rebuild a hosted control plane around the open shadcn CLI and registry format, not a new component library

You are building a fresh implementation inspired by the shadcn-ui/ui repository.
Treat the repository as a reverse-engineering reference, not as the default destination codebase.
Infer the product, architecture, entities, and flows from the reference repository, then rebuild the core system intentionally from scratch.
Do not blindly clone the original repo. Do not default to patching or refactoring it in place.
Build in small phases and keep the first version focused and maintainable.
Product thesis: Build a system that lets teams publish, version, approve, and distribute shadcn-compatible components from a private registry while keeping the existing install UX familiar.
Commercial/product framing: The repo signals a distribution platform more than a standalone SaaS app: the CLI, registry build scripts, and demo/docs site already solve public component delivery. The commercial gap is private, governed distribution across multiple codebases. A hosted control plane can monetize ownership, permissions, versioning, and compatibility management without trying to outcompete the open library itself.
Target user: A frontend platform team or design-system owner who needs one source of truth for reusable React/Next.js components, variants, and presets across several apps.
MVP scope:
- Private registry namespaces with read access for authenticated org members
- Publish and version component manifests compatible with the existing shadcn CLI install flow
- A web UI to browse components, versions, and changelogs inside one org
- Basic approval workflow for promoting a component from draft to published
- Signed or immutable manifest references to reduce accidental drift
- Framework-aware registry entries for Next.js and React projects
- Install command support that resolves public and private registries without breaking third-party registries
- Simple audit trail for publish, update, and install events
Stack assumptions:
- TypeScript monorepo with workspace boundaries similar to the current repo
- Next.js app for the registry/control-plane UI, matching the `apps/v4` surface
- A Node-based CLI package that reads registry config and installs component files
- Registry data stored as JSON manifests and file assets, since the current product is code-distribution oriented
- Public/private registry resolution must preserve compatibility with third-party registries mentioned in issue #10496
- Tailwind/Radix-style component output remains the main artifact type
- CI exists, but tests are thin or absent; add contract tests around registry resolution first
Key entities:
- Organization: id, name, slug, plan, createdAt
- Registry: id, orgId, name, visibility, baseUrl
- Component: id, registryId, name, description, category
- ComponentVersion: id, componentId, version, manifestPath, checksum
- AccessGrant: id, orgId, registryId, role, subjectType
- InstallEvent: id, orgId, registryId, componentVersionId, targetApp
Core pages / routes / flows:
- Registry browser (`/org/[slug]/registries/[registrySlug]`): List components, versions, and framework compatibility for an org or registry.
- Component detail (`/org/[slug]/registries/[registrySlug]/components/[name]`): Show manifest, changelog, install snippet, and published versions.
- Publish flow (`/org/[slug]/registries/[registrySlug]/publish`): Upload or sync a new component version and run validation before release.
- Access management (`/org/[slug]/settings/access`): Grant read or publish permissions to teams, users, or service accounts.
- CLI install flow (`shadcn add <component>` / registry resolver): Resolve public or private registry entries, fetch files, and merge config safely.
- Approval flow (`/org/[slug]/registries/[registrySlug]/components/[name]/approve`): Move draft content to published state with a controlled review step.
Backend services / modules:
- Registry resolution service: Resolve component identifiers to manifests, assets, and compatibility metadata
- Manifest validation module: Check schema, file paths, checksum, framework targets, and compatibility rules
- Auth and org access module: Authenticate users and enforce org-scoped registry permissions
- Publishing pipeline: Accept component sources, generate registry artifacts, version them, and mark them immutable
- Audit/event log: Record publish, approval, and install events
- Compatibility adapter layer: Translate or preserve third-party registry conventions and config merge behavior
Do not build yet:
- A full marketplace for arbitrary community components
- Billing and subscription management before the registry contract is stable
- Multi-cloud infrastructure or self-hosted deployment tooling
- Deep analytics dashboards beyond a basic audit log
- Figma sync, design-token orchestration, or premium connectors
- Replacing the open CLI workflow with a new proprietary install experience
Major risks / blockers:
- Open-source distribution keeps the core component value easy to copy
- Third-party registry compatibility bugs can damage trust fast
- The repo evidence shows missing tests, which makes contract drift likely
- Auth, billing, observability, and env setup are missing, so a hosted layer needs fresh infrastructure
- Thin README and weak external positioning make it easy to under-specify the actual product boundary
- Partial multi-tenancy suggests org boundaries may exist conceptually but not be complete in code
Work in phases. After each phase, summarize what was built, what remains, and which assumptions from the reference repo you intentionally did or did not keep.

Phase 2 core flow

Objective: Create the minimum private registry service and browser

Deliverables:
- Org, registry, component, and version data model
- Authenticated registry browser UI
- Publish endpoint for new component versions
- Read API for CLI consumption
- Basic access grants
- Exit: An org can publish and browse private components
- Exit: The CLI can fetch a private manifest with auth
- Exit: Versions are immutable after publish

Rules:
- Implement the core pages, routes, and backend modules needed for the happy path in the fresh build.
- Use the reference repo for behavior and architecture cues, not as the code target.
- Preserve maintainability and add only the minimum comments needed.

Start by reverse engineering the reference repository, then implement the fresh build in the smallest clean sequence.

Deploy and finalization

Objective: Prepare the implementation for release, verification, and handoff.

Deliverables:
- Verify the main flows work.
- Check configuration, environment assumptions, and release blockers.
- Summarize remaining risks and suggested follow-up work.

Rules:
- Do not add speculative infrastructure.
- Focus on practical release readiness, tests, and explicit known gaps versus the reference repo.

Start by reverse engineering the reference repository, then implement the fresh build in the smallest clean sequence.