Verification
The test and parity arsenal, from fast isolated-database suites to real engine journeys run against a release candidate.
Verification runs at two altitudes: deterministic suites that never touch a live system, and real journeys that exercise sandboxes and engines end to end.
Deterministic suites
- Backend suite against an isolated throwaway database, so it never disturbs a live one.
- Frontend suite and the shared package suites.
- Root typecheck across every package with
bun run typecheck.
These are fast, stable, and safe to run anywhere.
Full-stack and real journeys
| Command | What it exercises |
|---|---|
cd backend && bun run e2e |
A mock full-stack pass including Slack and memory outbox delivery, and crash-survival stages. |
cd backend && bun run e2e:real |
Real sandboxes end to end. |
cd backend && bun run soak |
Storm coverage over the durable lanes. |
bun backend/test/e2e/ui-sweep/sweep.ts |
Browser coverage of the rendered surfaces. |
Release parity canaries
Before a candidate can ship, the guarded release runs real engine journeys against it, not mocks, and it runs them twice:
- Candidate matrix. The full parity matrix runs on the host against the candidate, before it is publicly advertised.
- Public re-run. After the candidate is atomically activated, the hard journeys rerun through the authenticated public APIs.
The case matrix covers: repo-clone, github-pr-detail, gcs-list,
computer-browser, full-desktop, desktop-recording, artifact-publish,
thread-resume, model-switch, subagent-fanout, web-search,
automation-lifecycle, workpiece-deck,
workpiece-sheet, workpiece-document, workpiece-pdf,
cross-thread-memory, knowledge-search, skill-playbook, and
inbound-attachment.
PARITY_CASES and PARITY_ENGINES can narrow one certification run to a
targeted probe, but scoping never skips the gate itself, and the public re-run
always executes the full case matrix.
A candidate that fails a parity journey does not ship, and the lane rolls the environment back. See Deployment lanes.