[2026-09-16 22:31:00] taiga-vault: family/documents/vault-sync/2026-09-16-silent-tick-clusters.md

2026-09-16 22:31:01 +00:00
parent 40bea4ad1e
commit e49a439cda
1 changed files with 26 additions and 0 deletions
@@ -74,6 +74,32 @@ Exit 0, «Pushed ✓» по всем трём фазам. Фаза 1 (и фаз
 Проверка: `/vault`, `/obsidian-syncthing` и bare — все на `812173b`,
 `git status --porcelain` в `/vault` пуст.
 ## Поправка 22:30 UTC — кластер реален, но метод замера уже верный
 Перезамер тем же **оконным** методом (окно лога 2026-09-15 11:35:19 → 2026-09-16 22:30:20):
 **421 тик, 7 молчащих (1,66 %)** — вдвое больше, чем на 13:25 (0,96 %), при неизменном окне
 метода. Значит вывод «молчащие тики идут одиночно» тоже неверен — плотность **меняется во времени**:
 | тик (UTC) | dur | комментарий |
 |---|---|---|
 | 2026-09-15 13:55 | 5,8 с | |
 | 2026-09-15 22:50 | 7,4 с | |
 | 2026-09-16 12:10 | 6,1 с | |
 | 2026-09-16 13:45 | 6,5 с | |
 | 2026-09-16 16:45 | 6,0 с | |
 | 2026-09-16 18:25 | 7,1 с | |
 | 2026-09-16 20:15 | 7,3 с | |
 5 из 7 — в интервале 09-16 12:10 → 20:15 (~1 молчащий на 2 ч вместо ожидаемого 1 на ~14 ч).
 То есть артефактом метода были конкретные «кластеры» 16:55→17:15 и 23:45→00:00 (их
 опровержение в начале заметки остаётся в силе), но **сам феномен кластеризации реального
 времени существует**. Минутное сопоставление по-прежнему непригодно, оконное — пригодно.
 Дополнительно в `executions.db` найден отдельный режим отказа, не связанный с LLM:
 `2026-09-15 11:30:10 status=failed error='Fire claim lost; execution was not started.'`
 — тик потерян на стороне планировщика, скрипт не вызывался. Единичный случай, на 22:30
 не повторялся.
 ## Что не сделано
 Корневая причина — prompt-задача: каждый тик требует LLM-раунда, а раунд иногда