diff --git a/docs/decisions/ADR-0155-the-mac-app-may-add-albums-if-the-listener-turns-it-on.md b/docs/decisions/ADR-0155-the-mac-app-may-add-albums-if-the-listener-turns-it-on.md
index 677d9e3a..44fe74cf 100644
--- a/docs/decisions/ADR-0155-the-mac-app-may-add-albums-if-the-listener-turns-it-on.md
+++ b/docs/decisions/ADR-0155-the-mac-app-may-add-albums-if-the-listener-turns-it-on.md
@@ -39,7 +39,7 @@ Implementation:
   - **Zip timestamps carry no time zone.** Extracted on the Mac and copied to the NAS, files landed
     four hours in the future. The importer should give added files the time of the import rather
     than the zip's.
-  - **The single-track form is still unverified:** no single was bought.
+  - **The single-track form is still unverified:** no single was bought. (Since verified; see below.)
 - **Built and shipped in 1.5.1 (68)** (`familiar-apple` #235, #236) and run on the reference Mac
   against the NAS share. The first run had `~/Downloads` chosen as both folders and faithfully
   added both albums into Downloads; #236 refuses that pairing and keys the import ledger to its
@@ -57,6 +57,28 @@ Implementation:
     `Bonobo/Distance in Static` and `Max Cooper/Feeling Is Structure` on the NAS. The first attempt
     failed at the copy (macOS `rsync` has no `--protect-args`), and the hash check then refused
     both albums with nothing reaching the library, which is the behaviour point 4 asks for.
+- **The formats checked against real downloads** (2026-10-25, `familiar-apple` #238): Boards of
+  Canada's *Hi Scores* in AAC, Ogg Vorbis, ALAC, WAV and AIFF, each passed to
+  `testARealDownloadIsRecognised`. Every zip has the same flat layout and `cover.jpg`, all entries
+  stored. AAC, Ogg Vorbis, ALAC and AIFF are recognised and added. **Bandcamp's WAV files carry no
+  tags at all**, only `fmt ` and `data` chunks, with no `LIST`/`INFO` and no `id3 `. So a WAV
+  download is never recognised, and Settings → Adding says so. Recognising a WAV by its zip's
+  layout alone was rejected, because nothing in the files would say who sold them. Chrome saved
+  the second to fifth downloads as `Boards of Canada - Hi Scores (N).zip`. That broke the layout
+  check a custom domain depends on, so #238 drops a browser's trailing `(N)` before comparing.
+- **The add itself had never run against the NAS, and failed every time** (found 2026-10-26, fixed
+  in #238). The earlier real runs only reached "already in your library", which is checked before
+  anything is written. In 1.5.1 (69) every *Hi Scores* zip and the single failed with
+  `NSPOSIXErrorDomain 45 "Operation not supported"`. On the SMB share, `renamex_np(RENAME_EXCL)`
+  is `ENOTSUP`. A plain `rename` works there, refuses a non-empty destination with `ENOTEMPTY`,
+  and replaces only an empty folder. So point 4's no-replace rule holds with a plain-rename
+  fallback. The staging folder was removed after each failure, as point 4 asks. Failures had been
+  kept in the ledger forever, with nothing in Settings to ask again, so they are now retried at the
+  next launch.
+- **The single-track form is verified** (Max Cooper, *Waves*, FLAC, 2026-10-26). Bandcamp saves it
+  as `Artist - Title.flac`, not with the album's prefix. It carries `TITLE`, `ARTIST`,
+  `ALBUMARTIST`, `ALBUM`, `TRACKNUMBER`, `DATE`, `ISRC` and `COMMENT=Visit
+  https://maxcooper.bandcamp.com`, and it is added as `Max Cooper/Emergence`.
 
 Extends [ADR-0140](ADR-0140-familiar-server-enforces-zero-touch-with-a-seatbelt-profile.md) and
 [ADR-0154](ADR-0154-familiar-does-not-acquire-music.md).