VBI Development Handbook
Repository-level rules for VBI work. Keep this file as the routing layer: use it
for the non-negotiable principles, then load only the reference that matches the
package, practice, or entropy risk in front of you.
Core Rules
- Work from the owner and source of truth: DSL, Builder, Provider API, generator,
example JSON, or local utility.
- Reduce maintenance cost. Prefer deletion, simplification, extraction, or moving
ownership over adding compatibility layers.
- Use real needs to drive abstraction, deletion to fight entropy, and naming and
boundaries to make code explain itself. See
references/software-entropy.md#optimization-habits.
- Builder owns DSL mutation. UI, CLI, agent, app, and practice code should use
Builder or public package APIs instead of rebuilding internals.
- Generated artifacts are outputs, not primary fixes. Change the source and
regenerate when needed.
- Do not cross ownership boundaries casually: packages must not depend on apps,
and practices must not import another practice's private
src/*.
- For
apps/vbi_be and apps/vbi_fe, use the Docker-only workflows in
references/apps/vbi-be.md and references/apps/vbi-fe.md for runtime,
debugging, validation, and build commands. Do not run those app workflows
directly on the host unless the user explicitly overrides this rule.
- When deleting or renaming, clean imports, calls, types, comments, tests, docs,
generated references, and old names in the same change.
Ownership Map
packages/vbi: VBIChartDSL, Builder, dashboard/report/insight state, and
collaborative editing.
packages/vquery: QueryDSL-to-SQL and query execution.
packages/vseed: VSeed examples, lowering, and rendering specs.
packages/vbi-agent: Builder Agent runtime and tool protocol.
packages/vbi-component: shared component layer for VBI.
packages/vbi-react: React integration.
apps/*: product applications, docs website, backend, provider, and CLI.
practices/*: independent practice examples. Treat
practices/vbi-react-starter as the @visactor/vbi-react integration starter,
separate from the self-contained practice apps.
Run repository-level commands from the repo root unless a package script requires
otherwise.
References
Load only the relevant reference:
Keep generic guidance directly under references/. Put app-specific guidance
under references/apps/, package-specific guidance under
references/packages/, and practice-specific guidance under
references/practices/.
references/software-entropy.md: maintainability, refactoring, cleanup,
deletion, generated-surface control, and optimization habits.
references/apps/website.md: apps/website, Rspress docs, generated
API/example docs, and multilingual documentation synchronization.
references/apps/vbi-be.md: apps/vbi_be, NestJS backend, Prisma,
collaboration server, and Docker-only backend development workflow.
references/apps/vbi-fe.md: apps/vbi_fe, Next.js frontend, UI state,
service clients, and Docker-only frontend development workflow.
references/packages/vbi.md: packages/vbi, VBI DSL,
Builder/sub-builder design, headless logic boundaries, and TDD expectations.
references/packages/vquery.md: packages/vquery, QueryDSL-to-SQL, DuckDB
execution, example-driven tests, and coverage expectations.
references/packages/vseed.md: packages/vseed, VSeed examples, and
generated VSeed documentation.
references/practices/minimalist.md: practices/minimalist.
references/practices/standard.md: practices/standard.
references/practices/streamlined.md: practices/streamlined.
references/practices/professional.md: practices/professional.
Validation
Prefer the narrowest proving command first, then repository gates when practical:
For apps/vbi_be and apps/vbi_fe, use the in-container commands from
references/apps/vbi-be.md and references/apps/vbi-fe.md instead of the
host-local examples below.
pnpm --filter <package-name> run test
pnpm --filter <package-name> run lint
pnpm --filter <package-name> run typecheck
pnpm run lint:check
pnpm run typecheck
If generated artifacts are affected, run the generator first and inspect the
generated diff. Report any validation that could not run and why.
1---2name: development3description: Use for VBI monorepo development: apps, packages, practices, website documentation, repository-level workflows, generated artifacts, validation commands, source-of-truth decisions, software entropy control, maintainability, refactoring, dead-code deletion, and constraining messy LLM-generated code.4---56# VBI Development Handbook78Repository-level rules for VBI work. Keep this file as the routing layer: use it9for the non-negotiable principles, then load only the reference that matches the10package, practice, or entropy risk in front of you.1112## Core Rules1314- Work from the owner and source of truth: DSL, Builder, Provider API, generator,15 example JSON, or local utility.16- Reduce maintenance cost. Prefer deletion, simplification, extraction, or moving17 ownership over adding compatibility layers.18- Use real needs to drive abstraction, deletion to fight entropy, and naming and19 boundaries to make code explain itself. See20 `references/software-entropy.md#optimization-habits`.21- Builder owns DSL mutation. UI, CLI, agent, app, and practice code should use22 Builder or public package APIs instead of rebuilding internals.23- Generated artifacts are outputs, not primary fixes. Change the source and24 regenerate when needed.25- Do not cross ownership boundaries casually: packages must not depend on apps,26 and practices must not import another practice's private `src/*`.27- For `apps/vbi_be` and `apps/vbi_fe`, use the Docker-only workflows in28 `references/apps/vbi-be.md` and `references/apps/vbi-fe.md` for runtime,29 debugging, validation, and build commands. Do not run those app workflows30 directly on the host unless the user explicitly overrides this rule.31- When deleting or renaming, clean imports, calls, types, comments, tests, docs,32 generated references, and old names in the same change.3334## Ownership Map3536- `packages/vbi`: VBIChartDSL, Builder, dashboard/report/insight state, and37 collaborative editing.38- `packages/vquery`: QueryDSL-to-SQL and query execution.39- `packages/vseed`: VSeed examples, lowering, and rendering specs.40- `packages/vbi-agent`: Builder Agent runtime and tool protocol.41- `packages/vbi-component`: shared component layer for VBI.42- `packages/vbi-react`: React integration.43- `apps/*`: product applications, docs website, backend, provider, and CLI.44- `practices/*`: independent practice examples. Treat45 `practices/vbi-react-starter` as the `@visactor/vbi-react` integration starter,46 separate from the self-contained practice apps.4748Run repository-level commands from the repo root unless a package script requires49otherwise.5051## References5253Load only the relevant reference:5455Keep generic guidance directly under `references/`. Put app-specific guidance56under `references/apps/`, package-specific guidance under57`references/packages/`, and practice-specific guidance under58`references/practices/`.5960- `references/software-entropy.md`: maintainability, refactoring, cleanup,61 deletion, generated-surface control, and optimization habits.62- `references/apps/website.md`: `apps/website`, Rspress docs, generated63 API/example docs, and multilingual documentation synchronization.64- `references/apps/vbi-be.md`: `apps/vbi_be`, NestJS backend, Prisma,65 collaboration server, and Docker-only backend development workflow.66- `references/apps/vbi-fe.md`: `apps/vbi_fe`, Next.js frontend, UI state,67 service clients, and Docker-only frontend development workflow.68- `references/packages/vbi.md`: `packages/vbi`, VBI DSL,69 Builder/sub-builder design, headless logic boundaries, and TDD expectations.70- `references/packages/vquery.md`: `packages/vquery`, QueryDSL-to-SQL, DuckDB71 execution, example-driven tests, and coverage expectations.72- `references/packages/vseed.md`: `packages/vseed`, VSeed examples, and73 generated VSeed documentation.74- `references/practices/minimalist.md`: `practices/minimalist`.75- `references/practices/standard.md`: `practices/standard`.76- `references/practices/streamlined.md`: `practices/streamlined`.77- `references/practices/professional.md`: `practices/professional`.7879## Validation8081Prefer the narrowest proving command first, then repository gates when practical:8283For `apps/vbi_be` and `apps/vbi_fe`, use the in-container commands from84`references/apps/vbi-be.md` and `references/apps/vbi-fe.md` instead of the85host-local examples below.8687```bash88pnpm --filter <package-name> run test89pnpm --filter <package-name> run lint90pnpm --filter <package-name> run typecheck91pnpm run lint:check92pnpm run typecheck93```9495If generated artifacts are affected, run the generator first and inspect the96generated diff. Report any validation that could not run and why.