Where the test world stands: company, seed, loaded scenario, twin time, event count, auth mode, active faults, checkpoints, and the timeline entries due next. Changes nothing. Call it first to get your bearings.

Throw away everything since the start and rebuild the seeded world (the loaded scenario's, if one is loaded), with its timeline and faults. Checkpoints go too; webhook subscriptions and the auth mode stay. To undo only part of a run, use twin_rewind. Answers with the new status.

Twin time stands still until you move it. Scheduled scenario events happen on the way, each at its own time, and the webhooks they cause are delivered to the subscribed URLs before this answers; 0 minutes only sends deliveries already due. Answers with the new twin time and how many scenario events happened.

Make something happen now, as if someone did it in the vendor's own app: jobber newClients or payInvoices; housecallpro newCustomers, completeJobs, invoiceJobs, or payInvoices (quickbooks has none). Each takes params: how many. Recorded with source "control"; its webhooks are delivered before this answers. Answers with the events it recorded.

Name the current moment (log position, twin time, and fault dice), to list changes since it with twin_changes or go back to it with twin_rewind. A name already taken moves to now. Answers with the checkpoint.

What changed since a checkpoint, one line per event, oldest first: when, which vendor, what, and its source. Set onlyFromApi to see only what your code's API calls did. Changes nothing. For whole events, use twin_export_log.

Undo everything recorded after a checkpoint: records, twin time, and fault dice go back, so the same requests meet the same faults again. Checkpoints taken after it are dropped. Answers with the new status.

The ready-made scenarios twin_load_scenario can load by name, and what each one tests. Changes nothing.

Throw away the current world and build one from a scenario: a ready-made one by name (see twin_list_scenarios), or your own YAML (seed, startTime, world, faults, auth, timeline). Give one of the two. A scenario that doesn't load leaves the twin as it was. twin_reset comes back to its start. Answers with the new status.

Replace the active fault rules, so the vendor APIs fail the way real ones do. Each rule: { name, vendor: quickbooks|jobber|housecallpro, method?, pathIncludes?, pathExcludes?, rate: 0-1, effect: { status?: HTTP error status, latencyMs?, message?, lostResponse?: do the work, then answer with status } }. A rule with webhook: TOPIC or "*" (and no method, pathIncludes, or pathExcludes) affects webhook deliveries instead: effect { duplicate?: true, delayMs? }. An empty list turns faults off. Bad rules change nothing. Answers with the active rules' names.

How the vendor APIs treat bearer tokens: "any-token" accepts anything; "oauth" accepts only unexpired tokens from the twin's OAuth endpoints. Changes no records. Answers with the mode.

Replace the webhook subscriptions, as an app would set them up in the vendor's developer settings. Each: { vendor: quickbooks | jobber | housecallpro, url, topics, clientId, clientSecret (signs deliveries: for Jobber the app's OAuth client secret, for QuickBooks its verifier token, for Housecall Pro its signing secret) }. quickbooks topics: qbo.customer.created.v1, qbo.customer.updated.v1, qbo.invoice.created.v1, qbo.invoice.updated.v1, qbo.payment.created.v1. jobber topics: CLIENT_CREATE, INVOICE_UPDATE. housecallpro topics: customer.created, customer.updated, job.created, job.scheduled, job.completed, job.paid, invoice.created, invoice.sent, invoice.payment.succeeded, invoice.paid. Answers as twin_webhooks does.

The webhook subscriptions, without their secrets, and the latest deliveries with how each went. Changes nothing.

The event log as JSON Lines, one whole event per line, oldest first: everything, or only what happened since a checkpoint. Changes nothing. For a one-line summary of each, use twin_changes.