docs/plans/10-speaker-recognition.md

@@ -103,9 +103,14 @@ query path.
 ```
 
 `Recognizes()` requires both `enabled` and a `model_path`, so a half-filled block reads as off
-rather than as a capability that fails every turn. With `enabled` and no model the daemon still
-attaches the three methods — profiles can be created, listed and deleted — and logs that
-recognition is blocked.
+rather than as a capability that fails every turn.
+
+That gate was written, documented, and then never called. It is called now, and the behaviour it
+describes changed with it. `enabled` with no `model_path` used to attach all three methods and log
+that enrolment was on. Today `newSpeakerWiring` returns nil, so the methods are absent, and the log
+says why: there is nothing to embed with, so enrol, list and forget would all be no-ops. That is
+the one config shape where the operator most needs to be told otherwise, and it was the shape that
+lied.
 
 ## Still open
 

docs/qa.md

@@ -1,6 +1,6 @@
 # QA plan: checking Maven properly
 
-*Last verified: 2026-08-02 @ 20aa2d5. Living doc: correct it in place, do not append.*
+*Last verified: 2026-08-04 @ 58635f1. Living doc: correct it in place, do not append.*
 
 Written 2026-08-01, after the 35-PR stack landed and the box came back up.
 Refreshed 2026-08-02 against the live list, after PRs #85-#90.
@@ -471,6 +471,25 @@ at any address (**478**). `allow_private` does work, measured both ways.
 `CaptureStart`. There is no `cmd/mavheard`, no mavweb route, and `mavenclient`
 never calls it (**480**). Two of its QA steps are also stale.
 
+**Four stale QA steps were rewritten on 04-08-2026** under **480**, against the
+code rather than against what the plans said. All four failed the same way: the
+daemon was right and the step described an older daemon.
+
+| Step | Said | Says now |
+|---|---|---|
+| 253/3 | boots with the methods unknown | refuses to boot, `config.go:1651` |
+| 253/10 | no `:transcript` note by default | true only with a summary present |
+| 255/5 | `speaker: enrolment on, recognition BLOCKED` | that line is gone, the capability stays off |
+| 252/3 | `vision: stored image <id-prefix>` | `vision: stored <id>`, `vision.go:199` |
+
+Two of them are worth reading past the correction. 253/10 was false in exactly
+the scenario 253/16 creates, because `writeNotes` saves the transcript whenever
+the summary is empty so a dead llama-server does not lose the meeting. And 255/5
+changed because `Recognizes()` was written as the gate, documented as one, and
+never called — calling it turned `enabled` with no model from a half-working
+capability into a refusal. Enrolling into a store nothing can match against is
+not a working half.
+
 **257, netscan.** Steps 2, 3 and 9 pass at unit level. Step 1 fails. Steps 4 to 8
 need the block enabled. Step 10 is Bluetooth and stays skipped.