@automatebrowser/mcp 0.3.0

package/skills/automate-browser/references/page-interaction.md

@@ -0,0 +1,237 @@
+# Interacting with a page
+
+## Contents
+
+| Section | What it answers |
+|---|---|
+| [Refs, not selectors](#refs-not-selectors) | How you address an element |
+| [Finding an element cheaply](#finding-an-element-cheaply) | `browser_find` vs a full snapshot |
+| [The interaction tools](#the-interaction-tools) | click, type, hover, drag, select, clear, scroll |
+| [Filling a form](#filling-a-form-in-one-call) | `browser_fill_form` |
+| [Clicking what a snapshot cannot name](#clicking-what-a-snapshot-cannot-name) | Canvases, maps, PDFs |
+| [Waiting](#waiting-for-the-page-to-catch-up) | `wait_for` vs `wait` vs settle options |
+| [Actionability](#actionability-why-a-click-refuses) | Why a click refused before running |
+| [Stale refs](#when-a-ref-goes-stale) | Recovering from a re-render |
+
+---
+
+## Refs, not selectors
+
+Every interaction addresses an element by a **`ref`** handle plus a human-readable `element`
+description, never a raw CSS selector:
+
+```
+browser_click { element: "the Sign in button", ref: "e17" }
+```
+
+Refs come from `browser_snapshot` or `browser_find`. The `element` string is not decoration — it is
+what appears in the error if the click refuses, and what the user sees in the audit log. Describe the
+thing as a person would.
+
+## Finding an element cheaply
+
+`browser_snapshot` is the **map, not the data**. It returns the page's interactive elements with
+their refs. Read it once to learn the page's shape, then stop — it is the most expensive call in the
+set.
+
+When you already know what you are after, `browser_find` is far smaller:
+
+```
+browser_find { text: "Add to basket" }
+browser_find { role: "button", max: 5 }
+browser_find { selector: "form#checkout input" }
+```
+
+It returns matching elements with refs you can act on immediately. Reach for a full snapshot only
+when you genuinely need to survey an unfamiliar page.
+
+`browser_snapshot { verbose: true }` returns the fuller tree; `{ filePath }` writes it to disk instead
+of into your context.
+
+## The interaction tools
+
+| Tool | Required | Notes |
+|---|---|---|
+| `browser_click` | `element`, `ref` — or `x`, `y` | `dblClick: true` for double-click |
+| `browser_type` | `element`, `ref`, `text`, `submit` | `submit` is required — say whether to press Enter |
+| `browser_hover` | `element`, `ref` | For menus that open on hover |
+| `browser_select_option` | `element`, `ref`, `values` | `values` is an array, even for one |
+| `browser_drag` | `startElement`, `startRef`, `endElement`, `endRef` | Both ends need a description |
+| `browser_clear` | `ref` | Empties an input properly, better than typing over |
+| `browser_press_key` | `key` | `"Enter"`, `"Control+A"`, `"Escape"` — no ref, goes to the page |
+| `browser_scroll` | — | `{ ref }` scrolls to an element, or `{ dx, dy }`, or `{ to: "bottom" }` |
+
+## Filling a form in one call
+
+Do not click-and-type field by field. `browser_fill_form` takes them all at once and is dramatically
+faster and less brittle:
+
+```
+browser_fill_form { fields: [
+  { element: "email", ref: "e3", value: "a@b.com" },
+  { element: "country", ref: "e7", value: "United Kingdom" }
+] }
+```
+
+It handles text inputs, selects, checkboxes and radios. Submit separately, so a failed fill never
+half-submits a form.
+
+**Read the count, not the error flag.** A fill where some fields landed and some did not is neither
+a success nor a failure, and the flag alone cannot say so. It returns `outcome: "partial"`, the
+`Filled 2/3 field(s)` line with a `✗ ref: reason` for each field that refused, and the same thing
+structured as `{ filled, total, errors }`. Only a fill where **nothing** landed sets `isError`.
+Acting on the flag without reading the count is how a form gets submitted a third empty.
+
+**A checkbox or radio takes a boolean and nothing else** — `"true"` or `"false"` (also `1`/`0`,
+`on`/`off`, `yes`/`no`, `checked`/`unchecked`). Any other value is refused for those two, as a
+per-field error; the rest of the batch still fills. **Pick one option of a group by setting THAT
+option's own ref to `"true"`** — not by passing the option's label, which is how a `<select>` is
+filled and is refused here. `"false"` on a radio clears it and leaves the group with nothing selected;
+it never promotes a sibling.
+
+**A form that spans frames still goes in ONE call.** This is the one tool that may mix prefixes: a
+checkout puts the card number inside an embedded widget and the address in the page around it, and
+splitting that up would defeat the tool. Pass the fields in the order you want them written and that
+is the order they are written, even when the batch crosses back and forth.
+
+Three things follow from that, and they are the ones worth relying on:
+
+- **Nothing is written until every ref parses.** A bad prefix anywhere refuses the whole call with the
+  form untouched, rather than stopping halfway through with no way to tell how far it got.
+- **Failures are per field, and name the ref you passed.** A frame that has gone fails only its own
+  fields; the rest of the batch still reports its own result. Read `errors`, not just the count.
+- **Submit is still separate.** Nothing here changes that.
+
+`browser_clear` follows the same rules. Both reach a field inside a shadow root, so a design-system
+input with a perfectly good ref is fillable.
+
+## Clicking what a snapshot cannot name
+
+A canvas, an embedded map, a PDF viewer — nothing in the accessibility tree to point at. Click by
+coordinate instead:
+
+```
+browser_click { x: 420, y: 310 }
+```
+
+Coordinates are viewport pixels. The reply names what was actually under the point, so you can tell a
+hit from a miss. Pass **either** a ref or coordinates, never both; giving both is refused before
+anything runs.
+
+## Waiting for the page to catch up
+
+In order of preference:
+
+1. **`include: "snapshot"`** on the action itself — the fresh page comes back in the same reply, with
+   no second call. On `browser_navigate`, `browser_click` and `browser_type` **only**; elsewhere it is
+   rejected. The plain `includeSnapshot: true` reaches further — those three plus `browser_hover`,
+   `browser_select_option` and `browser_drag`, but **not** `press_key`, `fill_form`, `clear` or
+   `scroll`.
+2. **`browser_wait_for`** — waits for a real condition: `{ selector }`, `{ text }`, `{ urlPattern }`,
+   or `{ state }`. This is the right tool when a site swaps content without navigating.
+3. **`settleMs` / `waitUntil`** on the action — tune how long it waits for the page to go quiet after
+   acting.
+4. **`browser_wait { time }`** — a blind sleep. Last resort. It is either too short and flaky or too
+   long and slow, and usually both on different days.
+
+### The defaults these three already have
+
+They are **not** in the tool schemas, deliberately — a sentence in a schema is re-sent on every
+request, and saying these six times over cost 10% of the entire tool budget. Read them here, once:
+
+| | Navigation (`browser_navigate`, back/forward) | Interactions (click, type, hover, …) |
+|---|---|---|
+| `includeSnapshot` | **true** — a snapshot comes back unasked | **false** — the reply stays lean |
+| `waitUntil` | **`load`** | **`auto`** |
+| `settleMs` | 15 s cap for navigate, 10 s for back/forward | **2000** |
+
+So you rarely need to set any of them. Set `includeSnapshot: false` on a navigation whose page you
+are not about to touch; set `waitUntil: "none"` when you want the reply immediately and will wait for
+a real condition yourself; and prefer an explicit `browser_snapshot` when what you actually want is
+fresh refs, or `browser_eval` when one value would answer the question.
+
+### Reading a navigation's `settled`
+
+`settled: true` means **the navigation you asked for** finished — not that the tab says "complete",
+which straight after a reload still describes the page you are leaving. Three things follow:
+
+- A `#fragment` jump, or a history step that stays inside one document, settles as soon as the url
+  changes. No load event is coming for one of those.
+- A transition that never starts — a link that turns out to be a download, an unanswered "Leave site?"
+  prompt, a forward entry that was not there — gives up after **about a second** with `settled: false`.
+  The tab is asked before that is believed, so a navigation the browser is merely slow to begin gets
+  its full budget: Chrome re-attempts a page it has refused before after roughly **3 seconds**, and
+  that used to come back as a page that never loaded.
+- **`settled: false` is not a failure.** It means the load was not seen to finish inside what you
+  allowed. Read `urlAfter` and `navigated` for what actually happened, then take a fresh snapshot
+  before you use any ref.
+
+`settleMs` only ever shortens the wait (15 s for `browser_navigate`, 10 s for back/forward). The one
+exception to `waitUntil: "none"` returning immediately is `initScript`: the script has to stay
+installed until the new document is built, so that combination waits for the page to commit.
+
+### When a navigation did not happen at all
+
+`browser_navigate` no longer claims success regardless. If the tab is not where you asked it to go,
+the reply opens with `Did NOT reach <url> — after 2.0s the tab was still on <old url>`, and that line
+appears **inside the snapshot reply too**, at the top. Believe it: the snapshot underneath it is the
+OLD page, and every ref in it belongs to that page. Do not act on them as though you had arrived.
+
+Read it as an observation over a window, not a verdict. The server re-asks the tab for up to 2 s
+before saying anything, because a page the browser is slow to commit lands roughly 700 ms late, and
+that wait is paid only when the first answer already said nothing had moved. It is a race against a
+still-moving browser, so at the boundary it can warn about a page that arrives a moment later, or stay
+quiet about one that bounces back — 14 of 16 real navigations were reported correctly.
+
+It stays silent wherever an unchanged url is correct: a reload, `waitUntil: "none"`, a navigation to
+the page already open, and a redirect that lands somewhere other than the url you typed. So the line
+appearing means something went wrong; its absence is not a guarantee that nothing did.
+
+## Actionability: why a click refuses
+
+Every interaction waits for the element to be genuinely ready — visible, enabled, not moving, and not
+covered by something else — before acting. A refusal names **which check failed and what was in the
+way**:
+
+> `NOT_ACTIONABLE: "Submit" is covered by "Cookie consent banner"`
+
+That is usually the real bug, not a timing problem. Dismiss the overlay rather than retrying or
+padding the wait.
+
+**The one exception, and it will catch you: an element that fades in with a CSS transition never
+becomes visible in your background tab.** Chrome does not advance transitions in a tab it is not
+drawing, so the opacity stays at its starting value indefinitely — the script sets the target, the
+animation never runs, and you get `failed the "visible" check` no matter how long you wait. Measured
+2026-09-01. Padding the timeout cannot help.
+
+When a click refuses as invisible and the element is one a human would see appear — a modal, a
+dropdown, a toast, anything revealed on interaction — that is this, not a slow page. Either drive the
+element's final state directly (`browser_eval` to read it, or act on what the fade reveals), or
+`browser_switch_tab` to bring the tab forward, accepting that you are taking the user's focus.
+
+## When a ref goes stale
+
+Refs survive small re-renders and recover themselves once if the page swapped the element out
+underneath you. When one truly cannot be found you get `STALE_REF`, and the recovery is always the
+same: take a fresh `browser_find` or `browser_snapshot` and use the new ref.
+
+**Do not cache refs across a navigation.** A new document means new refs, always.
+
+**Frames:** an embedded widget is a separate document. **Every** frame's refs are prefixed `f1:`,
+`f2:` and so on — same-origin ones too, and a `srcdoc` frame as well. Pass them through unchanged;
+they work like any other ref. In the page tree an `<iframe>` shows as a bare `- iframe` marker and its
+contents appear below under their own `- frame <url>` heading, never inline.
+
+**But one INTERACTION acts inside one frame.** For `browser_click`, `browser_hover`, `browser_type`,
+`browser_select_option`, `browser_drag` and `browser_eval`, every ref in the call has to carry the
+same prefix, and **no prefix means the top page** — it is not a wildcard that joins whatever frame the
+other ref named. `browser_drag { startRef: "f3:e9c4", endRef: "e1a2" }` is a mismatch, not a
+shorthand, and you get `BAD_ARGS` before anything is clicked, typed or dragged. There is no
+cross-frame drag; do the work one frame at a time.
+
+`browser_fill_form` and `browser_clear` are the exception and may mix frames freely — see
+[Filling a form in one call](#filling-a-form-in-one-call).
+
+Copy a prefix exactly as the snapshot printed it. A half-written one — `f3:` alone, `fx:e1a2` — is
+refused rather than guessed at, because guessing means acting on a same-named element in the wrong
+document and telling you it worked.

package/skills/automate-browser/references/reading-and-extraction.md

@@ -0,0 +1,113 @@
+# Reading a page and extracting data
+
+## Contents
+
+| Section | What it answers |
+|---|---|
+| [Pick the cheapest tool](#pick-the-cheapest-tool-that-answers-the-question) | read_page vs find vs get_html vs eval |
+| [The extraction loop](#the-extraction-loop) | The shape of a scraping task |
+| [Extract with a function](#extract-with-a-function-not-an-expression) | Using `browser_eval` properly |
+| [Big results](#big-results-go-to-a-file) | Keeping output out of your context |
+| [Pagination](#pagination) | Walking multiple pages |
+| [What will bite you](#what-will-bite-you) | Late rendering, frames, infinite lists |
+
+---
+
+## Pick the cheapest tool that answers the question
+
+| You want | Use | Why not the others |
+|---|---|---|
+| The visible text of the page | `browser_read_page` | Cheapest. Already stripped of markup. `format: "markdown"` keeps headings and links; `maxLength` caps it. |
+| A few elements matching text, role or selector | `browser_find` | Returns `ref`s you can act on, and is far smaller than a snapshot |
+| A table, repeated cards, any structure | `browser_eval` with a **function** | Returns real JSON. Do the mapping in the page, not in your head. |
+| The raw markup of one element | `browser_get_html { ref }` | Whole-page HTML is almost never what you want |
+| The page's interactive shape | `browser_snapshot` | The most expensive call here — for finding things to click, not for reading |
+
+`browser_read_page` is the default answer to "what does this page say". Reach past it only when you
+need structure it has thrown away.
+
+## The extraction loop
+
+```
+browser_navigate → browser_read_page          (does the answer just fall out?)
+                 → browser_find               (locate the container)
+                 → browser_eval (function)    (map it to JSON)
+                 → next page
+```
+
+Take a snapshot only if you cannot find what you need without one.
+
+## Extract with a function, not an expression
+
+`browser_eval` takes either an `expression` (a quick one-liner) or a `function` plus `args` of element
+refs. The function form is what you want for anything structured, because a ref passed in `args`
+arrives as a real element:
+
+```js
+// browser_eval {
+//   function: "(row) => ({ name: row.querySelector('.name').innerText, price: row.querySelector('.price').innerText })",
+//   args: ["e4k2"]
+// }
+```
+
+For a whole table, one call beats one call per row:
+
+```js
+// browser_eval {
+//   function: "() => [...document.querySelectorAll('table tbody tr')].map(r => [...r.cells].map(c => c.innerText.trim()))"
+// }
+```
+
+Return **plain JSON-serialisable values**. DOM nodes do not survive the trip. Passing both
+`expression` and `function` is refused, and `args` without `function` is refused — both before
+anything runs.
+
+## Big results go to a file
+
+`browser_eval`, `browser_snapshot` and `browser_screenshot` all take `filePath`. A five-thousand-row
+table pasted into your reply costs more than the whole task did. Write it, then read the file with
+your normal file tools.
+
+```
+browser_eval { function: "...", filePath: "./out/rows.json" }
+```
+
+Paths are sandboxed to the folders your editor advertises, plus any in `AUTOMATE_BROWSER_WORKSPACE`,
+plus the temp directory. A refusal names the directories it *would* have accepted, so you do not have
+to guess. Editors that advertise none (Cline, Zed, Windsurf, Gemini CLI, Codex) leave only the
+server's working directory — if that is the refusal you hit, tell the user to set that variable to the
+folder they want written, rather than suggesting they turn the sandbox off. Writing to the temp
+directory always works and needs no configuration at all.
+
+## Pagination
+
+Prefer the URL over the button when the site puts the page number in the URL — one call instead of
+three, and it cannot get stuck mid-animation:
+
+```
+browser_navigate { url: ".../results?page=2" }
+```
+
+Otherwise click and wait for the content to change, not for a fixed delay:
+
+```
+browser_click { element: "next page", ref: "e9", include: "snapshot" }
+```
+
+`include` returns the fresh page in the same reply. Use `browser_wait_for` when the site swaps content
+without navigating.
+
+## What will bite you
+
+- **A page that renders after load** returns nothing on a first read. `browser_wait_for` a selector or
+  some text, then read.
+- **Content behind a scroll** may not be in the DOM at all on an infinite list. Scroll, then read, and
+  repeat — do not assume one read got everything.
+- **Refs go stale on a re-render.** You get `STALE_REF` and the tool names the fix. Never cache a ref
+  across a navigation.
+- **An embedded widget** — a map, a payment field — is a separate frame, whether or not it shares
+  the page's origin. Reads reach inside it. Its contents appear under their own `- frame <url>`
+  heading rather than inline, and its refs are prefixed `f1:` and so on. Pass them through unchanged.
+  An `<iframe>` in the tree itself is just a marker; look below for its block.
+- **Rate limits and terms of use are yours to respect.** This drives the user's real, logged-in
+  browser: whatever you do is done as them, from their address, with their account.

package/skills/automate-browser/references/sessions-and-state.md

@@ -0,0 +1,186 @@
+# Sessions, logins and browser state
+
+## Contents
+
+| Section | What it answers |
+|---|---|
+| [Start from "already signed in"](#start-from-already-signed-in) | Why you usually do not log in at all |
+| [Credentials](#never-type-credentials-you-were-not-given) | The hard line |
+| [2FA and CAPTCHA](#2fa-captcha-and-consent-screens) | How to stop cleanly |
+| [Cookies and storage](#cookies-and-storage) | Reading and setting session state, and what is redacted |
+| [Dialogs](#dialogs) | `alert`, `confirm`, `prompt`, "Leave site?" |
+| [Uploads and downloads](#uploads-and-downloads) | Files in and out |
+| [Restricted pages](#restricted-pages) | What refuses automation outright |
+| [Signed-in vs signed-out bugs](#when-something-works-signed-in-and-fails-signed-out) | Diagnosing the difference |
+| [Recipe: a session that will not stick](#recipe-it-says-i-am-signed-out--the-cookie-is-not-sticking) | Six calls, cheapest first |
+
+---
+
+## Start from "already signed in"
+
+This drives the user's **real** browser. If they are signed in, **you are signed in** — navigating to
+the page is usually the whole job. Do not go hunting for a login form first; check whether the page
+you want simply loads.
+
+```
+browser_navigate { url: "https://app.example.com/settings" }
+browser_read_page
+```
+
+Landing on a login screen is the *signal* that a session is missing. It is not an invitation to type
+credentials you were never given.
+
+## Never type credentials you were not given
+
+If a flow needs a password and none was supplied: stop and say so. Do not read one out of a password
+manager, a `.env` file, the page, or the repository. Ask, or hand the step back.
+
+## 2FA, CAPTCHA and consent screens
+
+A one-time code cannot be produced by you, and a CAPTCHA is a deliberate wall. The right move is a
+clean pause:
+
+1. Say exactly what the page is asking for.
+2. Say that the tab is ready and waiting.
+3. Stop, and let the user finish that step themselves.
+4. Resume with `browser_snapshot` when they say they are through.
+
+If the tab is one you opened in the background, use `browser_switch_tab` to bring it to them — this is
+precisely the "show me" case that tool exists for.
+
+Do not retry a CAPTCHA, and never click "resend code" repeatedly. That locks accounts.
+
+## Cookies and storage
+
+| Tool | Use |
+|---|---|
+| `browser_get_cookies` | Confirm a session cookie exists for this origin |
+| `browser_set_cookie` | Restore a session you were explicitly given |
+| `browser_storage` | `localStorage` / `sessionStorage` — where single-page apps keep tokens |
+
+Values are **redacted by default** in what comes back, because they are the keys to the account.
+`revealValues: true` exists; treat anything you do see as a secret and never write it to a file, a
+commit, or a message.
+
+**The same applies to request and response headers.** `browser_get_network_request` returns both
+header sets with the body, and hides the value of `authorization`, `proxy-authorization`, `cookie`
+and `set-cookie`, plus any name containing `token`, `api-key`, `apikey`, `secret`, `password` or
+`credential` — case-insensitively, and the same `revealValues: true` opts out. Names are always
+kept and the result counts what it withheld, so `<redacted>` means "an auth header you cannot see",
+never "no auth header". That distinction is usually the whole answer when a request returns `401`.
+You rarely need the real value: whether the header was **sent** is the bug, not what was in it.
+
+Cookies are scoped to the URL of the tab you are driving, so navigate to the origin first.
+
+A cookie session is shared across tabs of the same browser profile, so a tab you open is already
+signed in. What is **not** shared is `sessionStorage` — a token kept there dies with its tab.
+
+## Dialogs
+
+`browser_handle_dialog { action: "accept" | "dismiss", promptText }` answers `alert`, `confirm` and
+`prompt`. It also answers the native "Leave site?" prompt, which page JavaScript cannot even see.
+
+This matters more than it sounds: **an unanswered dialog freezes the page**, so anything injected into
+it never runs and your call waits out its entire timeout. A call that hangs and then times out is a
+dialog until proven otherwise.
+
+For a navigation you already know will trigger one, arm it in advance — this needs advanced mode:
+
+```
+browser_navigate { url: "...", handleBeforeUnload: "accept" }
+```
+
+## Uploads and downloads
+
+- **`browser_upload_file { ref, filePaths }`** needs advanced mode — call
+  `browser_advanced_mode { enable: true }` first, or you get `ADVANCED_MODE_REQUIRED`. The `ref` must
+  point at the file input itself.
+  - A file input inside a **same-origin** frame or a shadow root works.
+  - One inside a **cross-origin** frame (`f3:` prefixed) is **refused**, and says the frame is why.
+    The debugger session it drives does not extend into another origin's document. Nothing about the
+    ref is wrong, so a fresh snapshot will not help — there is no upload path into that frame.
+- **`browser_downloads`** lists what the browser has downloaded, **with the path on disk**, so you can
+  read the file afterwards. `wait: true` blocks until an in-flight transfer finishes rather than
+  returning a half-written file.
+
+## Restricted pages
+
+`chrome://` URLs, the extension store, the PDF viewer and other browser-internal pages refuse
+injection — you get `RESTRICTED_PAGE`. There is no workaround. Open a normal `http(s)` page.
+
+## When something works signed in and fails signed out
+
+The failure is usually silent — a redirect, or a button that does nothing. Two cheap checks:
+
+- `browser_click { ..., include: "console, network" }` — a 401 or 403 shows up in the network block,
+  in the same reply as the click.
+- `browser_issues` — the only tool that sees failures producing **no console error at all**: blocked
+  third-party cookies, content-security-policy blocks, mixed content, CORS. A dropped third-party
+  cookie is a very common cause of "it works when I do it by hand".
+
+## Recipe: "it says I am signed out" / "the cookie is not sticking"
+
+Six calls, cheapest first. Do not start by setting a cookie — you almost never need to.
+
+**1. Be on the origin.** Cookies are scoped to the URL of the tab you are driving, so a
+`browser_get_cookies` from the wrong page is an empty answer that means nothing.
+
+```
+browser_navigate { url: "https://app.example.com" }
+browser_get_cookies
+```
+
+**2. Is the cookie there at all?** Three different answers, three different bugs:
+
+| What you see | What it means |
+|---|---|
+| No cookie for the origin | It was never set, or it was set on a different domain |
+| The cookie is there, page still logged out | The app is not reading it — look at storage, step 3 |
+| The cookie is there, requests still 401 | It is not being *sent* — look at issues, step 4 |
+
+Values come back **redacted**. You do not need to reveal them to answer any of the three.
+
+**3. Single-page apps usually keep the token somewhere else.**
+
+```
+browser_storage
+```
+
+`localStorage` survives the tab; **`sessionStorage` dies with it**. A session that works until you
+open a second tab is almost always a `sessionStorage` token.
+
+**4. Check what the console cannot see.**
+
+```
+browser_issues
+```
+
+**A dropped third-party cookie is the single most common cause of "it works when I do it by hand"**,
+and it produces no console error whatsoever. Same for a CSP block on the auth iframe.
+
+**5. Catch the status code on the action itself.**
+
+```
+browser_click { ref: "e7", element: "Save", include: "console, network" }
+```
+
+The 401 or 403 arrives in the same reply as the click, so you never have to guess which request the
+button made.
+
+**6. To see what a stranger sees, use a private window — never the user's own session.**
+
+```
+browser_new_tab { incognito: true, url: "https://app.example.com" }
+```
+
+Its own cookie jar, its own empty storage, and closing it ends the session with nothing to clean up.
+This needs the one-off "Allow in Incognito" setting a **person** has to switch on; without it you get
+`INCOGNITO_BLOCKED`. Ask, and do not retry.
+
+**Never diagnose by clearing the user's cookies or storage.** That signs them out of a browser they
+are actually using, and it destroys the evidence you were sent to look at.
+
+## Leave the session as you found it
+
+Do not sign the user out, clear their storage, or revoke sessions to "clean up". You are a guest in
+the browser they actually use.