Skip to content

Contributing & community

Terminal window
# TypeScript packages (npm workspaces at the repo root)
npm install
npm run build # renderer (tsc + single-file bundle), react, angular wrappers
npm test # rule-engine conformance fixtures + renderer component tests
# Editor
cd editor && npm install && npx ng serve # http://localhost:4200, backend at :8080
# Backend (Java 21; Mongo at localhost:27017)
cd backend && ./mvnw spring-boot:run
./mvnw test # integration tests on embedded MongoDB

The Playwright end-to-end suite in e2e/ runs against the Docker stack (docker compose up, then npm test inside e2e/).

Question types are the designed extension point — a new one needs only registry modules (core semantics, renderer template, editor panel, backend validator), zero changes to navigation, persistence, or the rule engine. The repo’s adding-a-question-type guide walks through it using the email type as the worked example.

The rule engine’s semantics are pinned by JSON conformance fixtures in shared/rule-fixtures/ — the TypeScript suite loads them, and any future server-side engine must pass the same files. If you touch rule behavior, you touch the fixtures.

The repository’s README carries a note on how the project was built — designed and specified by its owner, with much of the implementation written from those specifications using AI tooling, and design decisions, code review, and maintenance staying human. This documentation site was produced the same way: every documented behavior was verified against the source code rather than the design documents, and the discrepancies that turned up are tracked in the site repo for triage.

MIT, for the tool and this site. No telemetry, no phone-home — and this site follows suit: no tracking scripts, no cookies.