A Play is an automated email flow. Use the management helper to inspect its definition and execution history. Use the inspection helper for previews and current email controls.
Read the current state
With BARUA_MANAGEMENT_KEY and the installed skill:
node "$BARUA_SKILL/scripts/manage.mjs" capabilities
node "$BARUA_SKILL/scripts/manage.mjs" play-catalog
Success returns the allowed operations and the available Plays. Use a returned Play slug with play --play-id and play-definition --play-id. Do not invent a Play ID. Follow returned version cursors when reading version history.
Propose a change
Read Propose and operate a Play before writing. It defines the current revision and validation requirements. Use play-validate and play-simulate with the documented inputs before submitting changes for approval.
Play changes require play:write; launch authority is separate. Complete the required journey review before setup proposals. An approved definition does not by itself prove that live admission or sending is enabled.
Preview and diagnose
Use inspect.mjs play-preview --play-id with a private input file for a selected revision and step. The inspection reference defines the example preview body and the additional people:read permission for person-based previews.
Use play-runs and play-trace to inspect execution, then play-admissions for admission decisions. Enabled pixel observations can trigger marketing Plays for identified people under the existing marketing basis. Server events remain authoritative for consent and transactional email. A backfill event cannot trigger a lifecycle send.
Verify the outcome
Follow the management proof procedure after the final setup change or resumed operation. Report the observed delivery state and the review package. Read emails and previews shows where to inspect the resulting message.
If a Play is paused or a review is pending, read that state before attempting another action. Recover a blocked task covers retries and owner decisions.