diff --git a/docs/testing.md b/docs/testing.md
index 3973148..1132d09 100644
--- a/docs/testing.md
+++ b/docs/testing.md
@@ -63,6 +63,20 @@ into separate layer-shell windows.
 - [ ] The Home button returns to Wonder Ink
 - [ ] Fullscreen YouTube video uses the whole display
 - [ ] Leaving fullscreen restores the correct geometry above the dock
+- [ ] Chrome has **no sway title bar** — the window starts at Chrome's
+      own tab strip, and Chrome's tabs and address bar are still there
+- [ ] Chrome still maximises and minimises as before
+- [ ] After a reboot, no "Restore pages? Chrome didn't shut down
+      correctly" bubble
+- [ ] Chrome does not offer to save passwords
+- [ ] `chrome://policy` lists PasswordManagerEnabled as an applied
+      managed policy
+- [ ] Website logins still persist across a reboot
+- [ ] Clicking Browser when Chrome is closed shows a throbber on the
+      dock button until the window appears
+- [ ] Clicking Browser when Chrome is already open feels immediate,
+      with no throbber
+- [ ] The pointer shows a busy cursor while it is over the dock
 - [ ] No first-run, default-browser or sign-in nag appears
 - [ ] `chrome://policy` lists the Ekklesia policies as applied, with no
       "unknown policy" entries
diff --git a/docs/wonder-ink.md b/docs/wonder-ink.md
new file mode 100644
index 0000000..ed13125
--- /dev/null
+++ b/docs/wonder-ink.md
@@ -0,0 +1,104 @@
+# Wonder Ink: Present view video
+
+## The observation
+
+On the classroom endpoint:
+
+- Vimeo videos embedded in Wonder Ink **play correctly** in the normal
+  lesson view.
+- The **same** videos in Wonder Ink's **Present** view stop immediately
+  when Play is pressed.
+
+## What this rules out
+
+The system's video capability is fine. The same video, the same host,
+the same browser and the same codecs work a click earlier in the same
+session. Nothing is missing from the machine.
+
+**No codecs or media packages were installed for this, and none should
+be.** Installing packages to fix a problem that is not a missing package
+would leave the classroom carrying software it does not need, and would
+not fix Present view.
+
+Nothing in the system was changed for this.
+
+## The decisive test
+
+Run it once at the endpoint. This separates "Wonder Ink" from "the
+classroom's Chrome configuration" in one step:
+
+```
+sudo mv /etc/opt/chrome/policies /etc/opt/chrome/policies.off
+google-chrome --user-data-dir=/tmp/plain-chrome
+```
+
+That is a stock Chrome with a clean profile and no classroom policy at
+all. Sign in, open the lesson, press Present, press Play.
+
+- **Still fails** — it is Wonder Ink, and nothing here can fix it.
+  Report it to them with the console output below.
+- **Works** — something in the classroom configuration is responsible,
+  and the next section is where to look.
+
+Afterwards:
+
+```
+sudo mv /etc/opt/chrome/policies.off /etc/opt/chrome/policies
+rm -rf /tmp/plain-chrome
+```
+
+## If it turns out to be this end
+
+Two candidates, in order of likelihood. **Neither has been applied.**
+
+### 1. The autoplay gesture chain
+
+Chrome refuses to start audible playback without a user gesture. If
+Present view starts the player programmatically after its own view
+transition, the gesture from the Present click may not carry, and
+Chrome rejects the play. That would look exactly like this: fine when
+you click the player directly, dead when the view starts it for you.
+
+This is stock Chrome behaviour, not a classroom setting — a plain Chrome
+on any machine would do the same, which is what the decisive test above
+checks.
+
+Diagnostic: open DevTools (F12) in Present view and press Play. A
+rejected autoplay logs:
+
+```
+NotAllowedError: play() failed because the user didn't interact
+with the document first.
+```
+
+If that appears, the fix is a scoped policy, not a global one:
+
+```json
+"AutoplayAllowlist": ["https://app.wonderink.org"]
+```
+
+`AutoplayAllowlist` is recognised by Chrome 152 — verified against the
+installed binary. It has deliberately **not** been added, because
+allowing autoplay everywhere on a classroom machine is a real change and
+should follow evidence, not a guess.
+
+### 2. A popup window that sway tiles
+
+sway tiles new windows rather than floating them. If Present view opens
+a second browser window, it gets a tiled geometry the site did not
+expect, and a player that is resized or re-parented mid-start can stop.
+
+Diagnostic, while Present view is open:
+
+```
+swaymsg -t get_tree | grep -c google-chrome
+```
+
+More than one Chrome window means this is worth pursuing.
+
+### 3. Not the classroom policies
+
+For completeness, so nobody re-audits them: the managed policy in
+`/etc/opt/chrome/policies/managed/` sets first-run, sign-in, password
+and homepage behaviour only. None of it touches media, autoplay,
+iframes, fullscreen or site permissions.