Skip to Content
Technical setup

Technical setup

This repository is a pnpm workspace managed by Turborepo. It builds two surfaces from the same source: the Nextra documentation site and the shadcn-compatible JSON consumed by Circle Health applications.

Manifest-backed stack

One workspace builds the catalog and the files it documents.

Package versions below come directly from the workspace manifests. The lockfile fixes the resolved dependency graph.

System boundary

The Registry distributes source, not a runtime UI package. @circle/ui is the private authoring package inside this workspace. Consumers use the shadcn CLI, receive files in their own source tree, and own those files from then on.

BoundaryResponsibility
AuthoringReact modules, CSS tokens, localized copy, skills, and item metadata.
RegistryImport rewriting, dependency discovery, targets, and item manifests.
DocumentationCatalog navigation, previews, usage, sample data, and public payloads.
ConsumerInstalled source, application integration, and later local changes.

Build pipeline

Author
Source and configuration
packages · skills · config
Compile
Registry manifests
registry/berlin · generated
Publish
Static JSON payloads
apps/docs/public
Consume
Application-owned source
shadcn writes into the app
Documentation branch: generated item metadata + docs config + changelogdocs:sync → MDX catalog

1. Author

The durable sources are:

  • packages/ui/src for components, blocks, utilities, types, and localized copy
  • packages/styles/src/globals.css for base CSS variables and typography
  • skills for installable agent workflows
  • config/registry/items.json for item metadata and target overrides
  • config/registry/styles.json for theme variants
  • config/registry/site.json for namespaces, aliases, and the public host
  • config/docs/registry.json for catalog grouping and navigation

Every root component must have one explicit registry item. An entry exported from packages/ui/src/index.ts can also receive a live documentation preview.

2. Compile

pnpm registry:sync runs scripts/registry/build.mjs. The script:

  1. reads authored source and registry configuration;
  2. maps each source module to one registry item;
  3. rewrites local imports to namespaced registry paths;
  4. derives npm and registry dependencies from imports;
  5. writes transformed source to registry/berlin; and
  6. writes manifests and catalog metadata to config/registry/generated and registry.json.

Explicit dependencies and file targets in items.json supplement values that cannot be derived from imports.

3. Publish

pnpm registry:build performs the registry sync, then runs shadcn build once per namespace. The resulting JSON is written below apps/docs/public:

/circle-ui/{name}.json /blocks/{name}.json /utilities/{name}.json /i18n/{name}.json /skills/{name}.json

The documentation application and these static payloads are served from registry.circle.health.

4. Generate documentation

pnpm docs:sync combines generated item metadata with docs configuration. It produces catalog pages, sidebar maps, skill pages, the CircleOS PII-mask page, and the rendered changelog.

Handwritten pages such as this one explain durable concepts. Item reference pages are generated so their install commands and dependencies stay aligned with the public payload. An item listed in its namespace’s authoredItems configuration keeps its handwritten page while still using live RegistryItem sections for installation and dependency data.

Workspace map

PathOwns
packages/uiInstallable React and TypeScript source.
packages/stylesBase CSS and Circle Health design tokens.
config/registryRegistry definitions plus generated manifests.
config/docsCatalog information architecture.
registry/berlinTransformed source passed to the shadcn builder.
apps/docs/contentHandwritten and generated Nextra MDX.
apps/docs/publicPublic registry JSON, fonts, brand assets, and synthetic data.
scripts/registryRegistry compilation and public-payload builds.
scripts/docsDocumentation synchronization.
scripts/sample-dataSynthetic lab-report and intake-form generation.

Documentation runtime

The docs app uses the Next.js App Router with Nextra. The catch-all route at apps/docs/app/[[...mdxPath]]/page.tsx imports pages from apps/docs/content. apps/docs/content/_meta.tsx owns the top-level navigation.

The docs package runs registry and docs generation in both predev and prebuild. A local or production Next.js build therefore uses current generated artifacts instead of whatever happened to be on disk beforehand.

The root layout marks the site noindex, nofollow, and noarchive. That is a crawler policy, not access control.

Generated boundaries

Change the source on the left, then regenerate the output on the right.

Source of truthGenerated output
packages/ui, packages/styles, skillsregistry/berlin
config/registry/*.json and authored sourceconfig/registry/generated, registry.json
Generated namespace manifestsRegistry JSON under apps/docs/public
Generated item metadata + config/docsComponent, block, utility, and skill catalog pages
CHANGELOG.mdapps/docs/content/changelog.mdx
scripts/circle-os/pii-mask.jsapps/docs/content/utilities/pii-mask.mdx
scripts/sample-data configuration and sourcesPDFs and manifests under apps/docs/public/sample-data

Do not hand-edit generated output. The relevant build removes and recreates managed directories.

Local workflow

Start the docs application:

pnpm install pnpm dev:docs

After changing registry source or configuration:

pnpm registry:build pnpm docs:sync pnpm typecheck pnpm build

pnpm build is the production gate. Turborepo type-checks the private UI package, rebuilds registry and docs artifacts through the docs package hooks, and runs the Next.js production build.

Failure modes

  • An unconfigured root component stops the registry build.
  • A catalogued item missing from config/docs/registry.json stops docs sync.
  • An authoredItems entry without its handwritten page stops docs sync.
  • Hand edits below generated paths are overwritten on the next build.
  • Reinstalling a registry item in a consumer may replace its local changes; inspect the consumer diff before accepting an update.
  • The generated JSON is committed. Unexpected payload changes should be investigated before merge, not hidden from the diff.
Last updated on