A drafted test is a test whose expectations were read off a real run rather than imagined. suite draft runs the automation once and reads state.json and logs.txt back through the platform's own reader. It prints a suite JSON you can review and tighten. It never writes into a suite registry by itself.
#Running the draft
npx tsx orchestrator/cli.ts suite draft process-invoices
npx tsx orchestrator/cli.ts suite draft process-invoices --id invoices-happy-path --labels smoke --credentials acme --out suites/invoices-drafted.json
The automation id names automations/<automation>.automation.ts. --id sets the test id. --labels attaches labels for subset runs. --credentials names vault assets the run needs, resolved the same way a suite run resolves them. --out writes the suite to a file; without it the JSON is printed. --headed shows the browser while it runs.
#What the draft asserts
The drafter is deliberately conservative. It asserts the things a run proves and stays silent about the things it does not.
statusis the terminal status the run actually reached, so the draft is honest about what happened.totalsAtLeastcarries a lower bound of one transaction when the run reported any and zero system exceptions when it reported none. Lower bounds are stable: exact counts move with the data, while "at least one transaction and no system failures" is true of every honest run and false of a run that skipped its work.logContainscarries up to two log markers. They are chosen to be long enough to mean something and free of digits, because ids, counts and timestamps vary run to run and an assertion that only holds on Tuesdays is worse than none.maxDurationMsis three times the observed duration, with a floor of 30 seconds, so the budget has headroom.
If the observed status was not success, the draft says so in a note rather than asserting a failing status as if it were expected. If the run reported zero transactions, or a system exception, the draft notes that it cannot bless those and asserts less. When it can assert only the terminal status, it says that too: a status-only draft is the weakest kind of test.
#Provenance
A drafted test is never mistaken for a reviewed one. It carries generatedBy and draftedFrom. The CLI and Studio show them wherever the test appears.
{
"generatedBy": "suite draft (from observed run evidence)",
"draftedFrom": "process-invoices-draft-m4k2-a91c"
}
The purpose text is generated from the observed run and starts with DRAFTED from run. It tells you plainly to replace it with what the test is supposed to prove. Tighten the purpose and, where you can, tighten the assertions before relying on the test as a smoke check. suite show prints each test's assertion strength (strong or status-only) so a weak draft does not accumulate unnoticed.
#From draft to suite
Review the JSON, then register it.
npx tsx orchestrator/cli.ts suite draft process-invoices --out suites/invoices-drafted.json
npx tsx orchestrator/cli.ts suite add suites/invoices-drafted.json
npx tsx orchestrator/cli.ts suite run process-invoices-drafted
A draft that needs a credential looks for the vault before it runs and refuses by name if the asset is missing, so a draft never quietly proves less than it claims. The same rule holds when the drafted test later runs inside a suite.