docs(plans): lead decision 59, current snapshot view

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/plans/2026-09-26_lead-decisions.md

@@ -968,3 +968,22 @@ which stay with him. Each item names who decided it and what happened.
       broker holds the token and gives the reviewer no push action.
     - Slice 1 needs no Vikunja labels. The business file example comes
       from row S1, and the template file waits for it.
+59. **A stale poll read stays stored but isn't shown as current
+    (2026-10-04).** Source: Dewey, `agents/dewey/work/wui/SLICE1-VIEWS.md`
+    section 8 (revision 2, sha256 1b31e1d2…, Dewey's uncommitted working
+    file). The case: a board read that began before the broker's own move
+    is written, because its digest differs, and it then becomes the
+    latest snapshot. So `tasks_open` shows the old bucket until the next
+    tick. Dewey's check confirmed it against schema v3a.
+    - The poller keeps writing the row. A snapshot records what Vikunja
+      returned, and dropping one to make a view right would thin the
+      evidence.
+    - The schema decides what "current" means, once, for every reader. A
+      v3b amendment adds a view of each task's current snapshot. It skips
+      a `poll` row whose `read_at` is at or before the task's latest
+      `self` snapshot, and `tasks_open` is built on that view. The Q1
+      module, the CLI and the WebUI read the view and don't reimplement
+      the rule. Darkwing writes v3b, with a mutant that drops the rule.
+    - Dewey's Q3 correction also stands: the trail joins a task to its
+      request through `task.created`'s `request`, not through `subject`
+      on the `human.input` event.