confirm-an-action-in-a-browser-you-drive

Establish whether an action in somebody else's web interface actually happened, when a stale success looks like a fresh one and an open form looks like a failure.

Procedure

  1. start start. Goes next to s1
  2. action Put the content in without the clipboard, RW (reversible-write). Goes on_fail to s9; next to s2
  3. action Find the control, then click that element, RW (reversible-write), requires approval. Goes rollback to s8; on_fail to s9; next to s3
  4. action Undo it, before doing it again, RW (reversible-write), requires approval. Goes next to __end_aborted
  5. wait Give the confirmation time to appear. Goes next to s4
  6. end aborted. Terminal
  7. decision Is a confirmation on screen?. Goes if none to s5; if default to s6
  8. wait Wait again before believing it failed. Goes retry to s4; next to s7
  9. decision Is the confirmation this one?. Goes if stale to s7; if default to s10
  10. check Look for the result itself, not the sign. Goes on_fail to s9; next to s10
  11. escalate Stop rather than repeat the action. Terminal
  12. decision Is the interface offering something else now?. Goes if upsell to s11; if default to s12
  13. action Decline it explicitly, RO (read-only). Goes next to __end_success
  14. action Write down that it went out, and when, RO (read-only). Goes next to __end_success
  15. end success. Terminal

Open the graph on its own page — larger, printable, and an address you can send.

Walk it without running it — you answer what your environment would answer, and the path, the capabilities, the approvals and the distance back to an undo come out of the document. Nothing executes; there is no Run button here and there will not be one.

How this stands to other procedures

See it as a composition — what running all of it would grant, and whose trust level it would really carry.

Trust

T2 · attested 2026-10-11 · runbooks.directory

Nobody has attested this record. That is the ordinary case: T2 is what the catalog can check on its own, and T3 needs somebody to run the procedure and sign for it.

  • Link liveness has not been checked: it needs a network and the catalog builds without one. Run pnpm gates --online where there is one.

Steps

  1. s1 action — Put the content in without the clipboard (reversible-write)
  2. s2 action — Find the control, then click that element (reversible-write) — requires approval
  3. s3 wait — Give the confirmation time to appear
  4. s4 decision — Is a confirmation on screen?
  5. s5 wait — Wait again before believing it failed
  6. s6 decision — Is the confirmation this one?
  7. s7 check — Look for the result itself, not the sign
  8. s10 decision — Is the interface offering something else now?
  9. s11 action — Decline it explicitly (read-only)
  10. s12 action — Write down that it went out, and when (read-only)
  11. s8 action — Undo it, before doing it again (reversible-write) — requires approval
  12. s9 escalate — Stop rather than repeat the action

Capabilities

This is a privilege request. Check it against your own allowlist before running.

    Provenance

    Source
    https://runbooks.directory/r/std/confirm-an-action-in-a-browser-you-drive/source.md
    Fetched
    2026-09-04
    Source last checked
    not since it was captured on 2026-09-04 — recorded as current
    Licence
    CC-BY-4.0
    How it got here
    Written by this catalog's maintainers and reviewed in full.
    Highest risk in this procedure
    reversible-write

    Take it with you

    Run it under supervision

    Runs here, on your machine, under supervision: every step is proposed before it happens, an approval gate stops for you, and a failed expectation goes where the procedure says rather than on to the next step. Nothing is sent anywhere. To supervise an agent that is doing the work instead, runbooks hook sits in its tool-call path.

    npx @runbooks/cli run std/confirm-an-action-in-a-browser-you-drive@1.0.0 --as "$(whoami)" \
  --input confirmation=<what the interface shows when the action succeeded>