Development

Build, test, package, and now verify the docs app as part of the normal repo workflow.

Toolkit QA

Before pushing changes, run:

npm run web:check
vp check
vp test
npm run coverage
npm run standalone:smoke
vp pack
npm pack --dry-run

What those do:

npm run web:check: verifies the committed Solid web bundle matches the source app
vp check: formatting, linting, and type checks
vp test: unit tests
npm run coverage: unit tests plus a local coverage report in coverage/coverage-summary.json
npm run standalone:smoke: builds the current-platform standalone binary and runs --help
vp pack: builds the CLI bundle into dist/cli.js
npm run browser:e2e: runs Chromium smoke coverage against the toolkit web workspace and docs site
npm pack --dry-run: shows the exact npm package contents without publishing

vp build is for web apps. This repo is a CLI package, so the build step here is vp pack.

The docs app now lives in docs/ and should be treated as a first-class build target.

npm run docs:dev
npm run docs:check

docs:check runs the Fumadocs content build, Next.js type generation, TypeScript checking, and the Next production build.

Install the Chromium browser once before running the browser smoke suite locally:

npm run browser:install
npm run browser:e2e

Normal release flow:

Finish the change on main.
Run toolkit QA plus npm run docs:check.
Preview the notes with npm run release:notes if you want to inspect the next published summary.
Run npm run release:patch, release:minor, or release:major.
Let GitHub Actions publish the already-bumped version.
GitHub Actions then creates the matching GitHub Release with generated notes, package metadata, commit highlights, a committed changelog entry, and standalone release archives.

Release history is published in both places:

The repo intentionally stays single-package for the toolkit itself. The docs app is a separate docs/ directory, not a full workspace split.

For the current service boundaries, read-model layer, and registry seams, see /docs/architecture.