Skip to main content
PRD verification requires app framework 2.10.0 or later.

​
How the suite runs

prd:test boots the app’s own server against a throwaway test database with every service stubbed, runs each entry in isolation, and writes pass/fail back into prd.json. Nothing is shared between entries: each gets a fresh database and its own seeds, so results are deterministic and order-independent. The suite also runs as part of every synthetiq-app build, so a change that breaks a verified requirement fails the build that introduced it. This is why failures reach the agent making the change rather than the reviewer.

​
Results stay current

Results are tied to the code that produced them. After a build changes the app, affected entries show as needs re-recording in the PRD view until their tests re-run. The previous evidence isn’t discarded, but it visibly refers to an older version of the app, so a passing entry always means the current code passed.

​
The evidence ships with the app

Recordings, manifests, and prd.json are published as part of the app. Someone installing it reviews the same evidence the builder saw: the videos, timelines, snapshots, and service-call records are part of the product, not build artifacts left on the author’s machine.

​
Existing apps

An app that predates its PRD gets one through the same standard, not a bulk generation pass: the agent first presents a complete inventory of the sections, features, and access rules it intends to verify for approval, then implements it section by section, with each section’s entries passing before it moves on. The end state matches a PRD built alongside the app from day one.