Skip to main content

​
Development checks

Run scripts/setup.sh once per clone to install the Lefthook checks for staged Rust, dashboard and website TypeScript, and OpenAPI contract changes. Run the documentation checks below for MDX changes.
Dashboard checks run from apps/dashboard:

​
Dashboard UI

The dashboard uses the stock shadcn/ui base-nova preset initialized with shadcn CLI 4.19.0, Tailwind CSS v4, Base UI primitives, CSS-variable theming, Geist, and Lucide icons. apps/dashboard/components.json is the registry configuration. Add UI primitives through the current CLI from apps/dashboard:
Use generated components from @/components/ui and Tailwind utilities in routes. Keep product composition in app or non-ui components, and avoid restoring global element styles that override the stock shadcn component variants. Documentation checks run from apps/docs:

​
Keep contracts synchronized

deploy/contract/governance.openapi.yaml is canonical for the Control API. After changing it:
CI rejects a stale openapi/next.yaml snapshot. After changing SQLx queries, run scripts/prepare-sqlx.sh; scripts/check-sqlx-queries.sh enforces that the offline metadata remains current. Exercise cross-service journeys with tests/e2e/run.sh smoke or tests/e2e/run.sh full. See the repository’s CONTRIBUTING.md for the issue-first workflow, Conventional Commit and PR naming, and CLA requirements.

​
Publish a documentation version

Update the Cargo workspace and OpenAPI versions, finish the Next documentation, then run:
The command refuses version mismatches and existing releases, freezes the MDX and API contract, and makes the new stable release the default Mintlify version. Do not edit a frozen release except to correct a material documentation or security error. Commit the generated apps/docs/<version> directory, OpenAPI snapshot, and docs.json update. A release doesn’t need a documentation snapshot; make one only when you want a frozen docs version. Run npm run check:release -- <version> to confirm it still matches Next.

​
Extend the product

Adding a harness requires a common harness variant, a single-writer configuration adapter, detection metadata, and gateway wiring. Adding a gateway requires a compiled GatewayAdapter plus any provider-specific proxy and credential lifecycle support; harness writers should not contain gateway-specific selection logic. See Harness adapter architecture for the version-range contract, operation-set ownership, package compatibility, and required boundary tests. See Gateway adapter architecture for the compiled registry, service and harness ownership boundaries, provisioning choices, proxy changes, and end-to-end verification.