daytona-flow-validator

# Daytona Flow Validator Use this skill to decide whether a Daytona Electron or browser flow actually works. Launching the sandbox is separate. This skill owns the feedback loop. ## Core Rule Never report success from a click, script return value, or recording alone. Validate the same path a human would take, using CDP to drive Chrome or Electron instead of replacing the journey with hidden state changes. Every meaningful action must follow this loop: 1. Observe with `browser_snapshot` first. 2. Act with `browser_click` or `browser_fill` against snapshot UIDs whenever possible. 3. Observe again with `browser_snapshot`. 4. Assert the expected URL, text, state, process, network, or file result. 5. Capture a screenshot checkpoint when the visible state matters. If any assertion is missing, the flow is not validated yet. When a coded eval exists, prefer `pnpm evals --flow <flow-id>` because the runner binds assertions, screenshots, and validation metadata into one HTML proof. Use manual CDP only to debug or to create a new coded flow. Use `browser_eval`, direct API calls, localStorage writes, filesystem edits, or database changes only when a human-visible path is impossible, unavailable in the current product, or needed as setup for data that the UI cannot create yet. When you use one of these shortcuts, say so in the report and do not let it replace the visible click-by-click demo claim. ## Human-Visible Demo Standard For founder, designer, PR, or eval evidence, record ...