QM's dev workflow spans a main server, separate background worker, and isolated test helpers—all started via npm scripts and configured through environment variables and distinct TypeScript configs for type-checking different layers (runtime, contract, CLI). Feature requests must be authored as human-written .txt or .md files in the adrs/ folder; bug reports go to GitHub issues.
The main server is started with node --env-file-if-exists=.env src/index.ts; the dev server additionally sets SHUTDOWN_DRAIN_MS=2000 and uses --watch for hot reload.[1] The background job worker is started separately via the worker npm script, which runs node --env-file-if-exists=.env src/runs/worker-main.ts.[1]
Server-side type-checking uses tsc --noEmit; a separate typecheck:contract script checks against tsconfig.contract.json to validate the public API contract.[1] CLI type-checking is done via npm run typecheck, which runs tsc -p tsconfig.json — a separate config from the build tsconfig.[2]
qm dev --ci [up|down] runs CI mode: core services only (Slack in-process), with no pool lease, intended for live end-to-end CI runs.[3]
Tests in test/orchestrator.test.ts use a freshApp() helper that calls buildApp from src/wiring.ts with a fresh temporary data directory per test, ensuring isolation without shared state.[4] spyProvisioning in test/orchestrator.test.ts wraps sandbox.provision and sandbox.teardown to track provisioned (total ever provisioned) and live (currently active) sandbox counts for use in test assertions.[4]
Feature requests are submitted as a human-written .txt or .md file added to the adrs/ folder via PR — AI-expanded formal proposals are explicitly not accepted. Bug reports go as GitHub issues.[5]
Sources