⌂ все дашборды/Качество и аудиты← Vault-Audit-2026-07-07 · Watcher-Token-Audit →

Аудит KEEP-ядра волта: синк · реиндекс · бэкап · карта · гигиена · свежесть

21.08.2026, 22:15–22:35 · 6 независимых линий + критик полноты · строго read-only · каждый вердикт с уликой (команда + вывод) · 152 проверки

Вердикт одним абзацем: данные волта ПРЯМО СЕЙЧАС не теряются и массовое удаление восстановимо несколькими независимыми слоями (git-история + 14 датированных бандлов + карантин удалений на зеркале — всё проверено фактом). НО «всё качественно» сказать нельзя: облачная нога бэкапа мертва ~11 дней, и её сторож зелёный по построению; гибель/кража машины сегодня = потеря всего. Плюс россыпь «вечно зелёных» сторожей — ровно тот класс, которого ты боишься: косяк уже случился, а никто не закричал.

Что доказанно здоровое: Syncthing-демон жив, 10/11 шар идеально догнаны, подключённые пиры need=0, конфликты не перезаписывают файлы молча · реиндекс RAG бежит каждые 15 мин (сегодня 22:07, exit 0, 21519 чанков) и ночной инкремент зелёный · локальный бэкап НАСТОЯЩИЙ версионный: git-bundle с полной историей, 14 датированных копий, свежий бандл сегодня 06:15 на двух дисках · утренняя починка «зеркало≠бэкап» реально встала: mass-delete gate + 30-дневный карантин удалений, проверено чтением новой версии.

■ КРАСНАЯ — бэкап волта

🟥 КРИТИЧНО: облачная нога 'drive-offsite' МЕРТВА с ~10.08 — D:\GoogleDrive2023 это локальная папка, которую DriveFS не синкает 11 дней; бандлы 11–21.08, скорее всего, НЕ в облаке, при этом писатель ежедневно печатает 'RESULT drive-o
Три независимые улики: (1) Get-Volume — смонтированы только C/D/E/F, стриминговых дисков Google Drive (G:=dzyatkovskiy.a, I:=a2 по таблице media в root_preference_sqlite.db) НЕТ; (2) базы синка аккаунта 114398196644476066382 (владелец root D:\GoogleDrive2023,
чинить: Отдельная сессия починки (не read-only): перелогинить/перезапустить Google Drive клиент до появления mount G:/I: и живого metadata_sqlite_db; затем убедиться, что бандлы 11–21.08 доехали в облако (проверка С ОБЛАЧНОЙ сто
🟧 Сторож (healthcheck) не ловит смерть облака по построению: он проверяет файлы в D:-папке, которая локальна — 'вечно зелёный' по offsite при мёртвом облаке; вдобавок его актуальный вердикт — устаревший ложный PROBLEM
backup_healthcheck.py (чтение кода): проверяет свежесть/verify бандла в resolve_drive()-папке = D:\GoogleDrive2023\Obsidian-Backup — это диск этой же машины, доезд в облако не проверяется ничем. health-latest.md (18.08 23:52): VERDICT PROBLEM из-за лага _origi
чинить: В healthcheck добавить проверку облачной стороны (Drive API list по Obsidian-Backup/vault, либо хотя бы liveness DriveFS: mount G:/I: присутствует + mtime metadata_sqlite_db < 24h). Частоту поднять с weekly.
🟧 3-2-1 честно: 4 копии на 4 разных физических дисках ОДНОЙ машины; offsite = 0 работающих; Syncthing-пиры (5 узлов, 3 сейчас online, вкл. Hetzner VPS) — зеркала, НЕ бэкап, их смягчает только .stversions
Копии: (1) E:\Obsidian рабочая + полный .git (SSD OBSIDIAN_2026 3726GB); (2) C:\ObsidianBackup — 14 версионных бандлов (HDD PaloAlto main 952GB); (3) D:\GoogleDrive2023\Obsidian-Backup — те же 14 бандлов (HDD 8TbSintra 7452GB), offsite-роль мертва (см. critica
чинить: После оживления DriveFS: подтвердить доезд свежего бандла в облако с облачной стороны. Рассмотреть вторую offsite-рельсу, независимую от DriveFS-клиента (например, rclone-пуш бандла по расписанию с проверкой квитанции).
🟨 Вывод по сценарию 'сейчас массово удалить файлы волта': восстановимо ПОЛНОСТЬЮ, несколькими независимыми слоями; невосстановимый сценарий — только гибель всей машины
Слои восстановления на текущую минуту: (1) git-история волта на E: — любое состояние, мгновенно (vault_backup.py коммитит перед каждым бэкапом, DELETE_BLOCK-растяжка на >=50 необъяснимых удалений — видна в логе 21.08: '286 deletions staged; 286 recoverable');
✅ Задача 'Obsidian Backup to Drive' жива и успешна; расписание 06:15, а не 03:00 из ТЗ — это осознанный перенос
schtasks /query /tn "Obsidian Backup to Drive" /v: Status=Ready, Last Run Time=21-Aug-26 6:15:01, Last Result=0, Next=22-Aug-26 6:15, Task=E:\Obsidian\_imports\backup_to_drive.cmd. Перенос 02:00→06:15 задокументирован в backup_to_drive.py (комментарий 2026-07-
✅ backup_to_drive.py — настоящий ВЕРСИОННЫЙ бэкап, не зеркало: git-bundle с полной историей + датированные файлы + copy-only
Чтение E:\Obsidian\_imports\backup_to_drive.py: git bundle create --all (полная история в одном файле), KEEP_BUNDLES=14 датированных бандлов, bundle verify после сборки, _originals через robocopy /E /XO (никогда /MIR — удаления не реплицируются), post-verify п
✅ Утренняя починка ff411c75 касалась ДРУГОЙ рельсы — daily_backup_E_to_F.ps1 (E:\ → F:\E-mirror, robocopy /MIR): именно она звалась бэкапом, а была зеркалом с окном восстановления НОЛЬ; теперь у неё mass-delete gate + 30-дневный кар
E:\Obsidian\_imports\backup\: daily_backup_E_to_F.ps1.bak-pre-massdelete-gate-20260821 (11:43, 3210 байт — старая версия: голый /MIR, удаления реплицировались и folded в exit 0-7 как SUCCESS) против новой версии 16:37 (20086 байт): (1) MASS-DELETE GATE — dry-r
✅ Фактическая свежесть на приёмниках: оба локальных приёмника несут сегодняшний бандл (возраст ~16 ч), зеркало F: — возраст ~5.5 ч
ls C:\ObsidianBackup\vault\ и D:\GoogleDrive2023\Obsidian-Backup\vault\: по 14 бандлов 08.08–21.08, свежий Anton-Knowledge-2026-08-21.bundle 1 646 709 816 байт, mtime Aug 21 06:15 на ОБОИХ. last-backup.txt на обоих: 2026-08-21 06:15:01, HEAD 3091e2e9ce. F:\E-m

не проверено (6)

Облачная сторона Google Drive напрямую: какие бандлы реально лежат в облаке и дата последнего доехавшего — MCP-коннектор Drive вернул 'requires additional permissions' (нужен recon
Причина смерти DriveFS-синка (перелогин/пауза/замена диска D:) — установлен только момент (~10.08 05:59-06:01 по mtime WAL и обвалу размера логов), не причина
.stversions на Syncthing-пирах (какое окно восстановления даёт каждый пир, есть ли волт на FLEET-ANCHOR VPS фактически) — не проверял с их стороны
Живой прогон _test_mass_delete_gate.ps1/py — не запускал (тест гоняет robocopy по песочнице = запись; вне read-only мандата); улика работоспособности гейта — только сегодняшний жив
Restore-drill (git clone из бандла в пустую папку) — не выполнял; целостность бандла принята по 'git bundle verify OK' писателя и healthcheck 18.08
Отправились ли алерты bus_send из нового гейта при реальном блоке — блока ещё не было, ветка не испытана вживую

■ ЖЁЛТАЯ — Syncthing-синхронизация

🟧 Сторож sync_check.ps1 слеп к 4 из 11 шар (включая machine-bus, где сейчас ошибки): список папок берёт из config.xml, протухшего с 25.06
Прогон sync_check.ps1 22:14:03 показал 7 папок и 'RESULT: all GREEN, EXIT=0', при том что /rest/config/folders даёт 11 шар и machine-bus несёт errors=2/pullErrors=2. Исходник строки 37-43: '$folders = @($x.configuration.folder)' из config.xml с комментарием 'o
чинить: В sync_check.ps1 поменять порядок источников: сперва /rest/config/folders (REST-истина), config.xml только фолбэк. Тот же разворот для устройств. Это правка одной ветки if в строках 39-44 (READ-ONLY аудит — не правил)
🟧 На шаре machine-bus (шина флота) застряли 2 элемента: файл maintenance-gate от Маяка не может доехать на хаб из-за кейс-коллизии имени, плюс завис delete каталога
GET /rest/folder/errors?folder=machine-bus: (1) '_transit\scripts-from-FLEET-ANCHOR\_maintenance_gate_day_fleet-anchor.json :: remote uses different upper or lowercase characters than local _maintenance_gate_day_FLEET-ANCHOR.json' (modifiedBy=3IWEVTJ=fleet-anc
чинить: Переименовать одну из сторон кейс-коллизии (например, на Маяке привести имя к нижнему регистру либо на хабе удалить локальный _maintenance_gate_day_FLEET-ANCHOR.json) и разобрать ignored-файлы в _sync-conflict-archive ли
🟧 laptop-HP17 офлайн 7 суток (с 14.08 20:09) и накопил долг: волт догнан лишь на 79.6% (106 713 файлов, 2.1 GB), machine-bus на 37.2%, imports на 61.6%; при возврате есть риск воскрешения старых копий
GET /rest/stats/device: JR2M6T4 lastSeen=2026-08-14T20:09:52+01:00, connected=False. GET /rest/db/completion?device=JR2M6T4...: anton-knowledge completion=79.6% needItems=106713 needBytes=2141982409; machine-bus 37.2% needItems=3096; claude-imports 61.6% needB
чинить: Разбудить/поднять HP17 (или зафиксировать его статус в fleet-реестре как спящий); после подъёма дать ему догнаться до need=0 прежде чем списывать/двигать файлы на общих шарах
🟨 nataly-win-nb была онлайн сегодня до 19:41, но по claude-home догнана лишь на 18.5% (должна 6 951 файл / 432 MB) — либо большой ignore-набор на её стороне, либо хронически стоящий синк этой шары
GET /rest/stats/device: UTH2ZU7 lastSeen=2026-08-21T19:41:23+01:00. GET /rest/db/completion?device=UTH2ZU7...&folder=claude-home: completion=18.5% needItems=6951 needBytes=432680823; при этом anton-knowledge у неё 99.4%, claude-secrets 100%. С хаба read-only н
чинить: Задача её узлу по шине: показать свой /rest/db/status?folder=claude-home и .stignore; если не ignore, а затык — чинить у неё
🟨 sync-conflict файлы (строгий паттерн, без .stversions/архивов): волт 20, ~/.claude 25 (из них skills 13 — сошлось с гардом старта сессии), _imports 2; обе коллизии local-*/общий подтверждены; есть СВЕЖИЕ драки сегодня
Get-ChildItem -Recurse c фильтром regex 'sync-conflict-\d{8}-\d{6}-[A-Z0-9]{7}': vault=20, .claude=25, skills=13, imports=2 (нестрогий счёт скрипта: 20/36/13/2 — разница = заметки с 'sync-conflict' в имени и файлы в _skills-attic). Коллизии: local-brain-onboar
чинить: Прогнать resolve_conflicts.py (dry-run -> --quarantine) по волту и .claude; отдельно разобрать two-writer на ACTIVE_NOW.md (доска onair) — это живой паттерн, не хвост
🟨 Скрипт показал 'PEERS: 2 connected', фактически подключены 3: MacBook-Anton переподключается (флап), в момент прогона был в разрыве
sync_check.ps1 22:14:03: 'OK PEERS: 2 connected (TCP22000=5)'. GET /rest/system/connections 22:19:26: connected=True у 3IWEVTJ fleet-anchor (startedAt 09:54:10), J2RQJA4 MacBook-Ruslana (startedAt 20:02:10), 4YSJ7MU MacBook-Anton (startedAt 22:17:30 — соединен
✅ Демон Syncthing жив, все подключённые пиры догнаны: 11 живых шар, у 10 state=idle и needItems=0; ошибок папок нет нигде, кроме machine-bus
GET /rest/db/status по каждой шаре из /rest/config/folders (22:15): anton-knowledge idle need=0 local=195566; claude-config idle 0/1366; claude-home idle 0/1596; claude-imports idle 0/4272; claude-memory idle 0/709; claude-scripts-shared idle 0/122; claude-sec
✅ Прямо СЕЙЧАС данные не теряются: хаб держит глобальную истину, подключённые пиры на need=0, единственный реальный недоезд = 138-байтный gate-файл Маяка (кейс-коллизия) и один застрявший delete
Совокупность: все шары need=0 кроме machine-bus (needItems=2); folder/errors пусты по 10 из 11 шар; identity green; конфликтные копии сохранены рядом с живыми файлами (ничего не перезаписано молча — у Syncthing проигравшая версия лежит как *.sync-conflict-*),

не проверено (5)

Взгляд со стороны пиров: их локальные демоны, их .stignore и их db/status (аудит строго с хаба; сверка клана = спросить каждую машину по шине)
Причина 18.5% у nataly-win-nb по claude-home: ignore-набор vs реальный затык — различимо только с её машины
Содержимое .stignore хаба (объясняющее разрывы local<global: claude-home 1596/9498, skills 204/227) — не влияет на вердикт о потерях
Диф содержимого свежих конфликтов ACTIVE_NOW.md и Posting-Full-Dashboard.html (что именно разошлось)
Здоровье вложенной пары anton-knowledge / _machine-bus (грабли D2) глубже факта, что обе шары idle

■ ЖЁЛТАЯ — гигиена волта и конфига (хаб A-2022BAYAREA)

🟧 Корневой git-снапшот ~/.claude МЁРТВ с 19.08 05:52 (2.6 суток), при этом задача каждые 15 мин рапортует успех — silent-green класс §5.5
git -C ~/.claude log -1 => 'e5104e7... 2026-08-19 05:52:38 auto-snapshot'; Get-ScheduledTaskInfo 'Claude Config Git Snapshot' => LastRunTime 21-Aug-26 22:07:37, LastTaskResult 0, NextRunTime 22:22:36 (каденс 15 мин жив); git status --porcelain -uall => 252 нез
чинить: См. следующие 3 находки — корень доказан воспроизведением; чинится в 3 слоях: пустой embedded-репо, перезаписанный .gitignore, скрипт без проверки exit-кода
🟧 Корень 1 (доказан воспроизведением): git add -A фаталит exit 128 на projects/C--Users-Anton/memory — вложенный git-репо с НУЛЁМ коммитов, gitlink не создаётся, весь add отменяется, индекс пуст, commit коммитит ничего
PS 5.1 повтор тела цикла скрипта: git -C C:\Users\Anton\.claude add -A --dry-run => "error: 'projects/C--Users-Anton/memory/' does not have a commit checked out; fatal: adding files failed; add_exit=128"; git -C .../C--Users-Anton/memory log -1 => 'fatal: your
чинить: Либо дать пустому репо первый коммит (--allow-empty), либо снести его .git, либо заигнорить /projects/C--Users-Anton/ в root .gitignore
🟧 Корень 2: root .gitignore хаба перезаписан 19.08 09:03 версией с MacBook через claude-config синк — whitelist расширился на projects/ (что и подставило пустой репо под add), плюс два узла дерутся за один файл (нарушение 'один файл
git diff .gitignore: старая шапка 'Root-level backup repo for ~/.claude (2026-07-05)... covers ONLY the root canon' заменена на 'MacBook-Anton ~/.claude git-backup — WHITELIST' с !/skills !/scripts !/projects/*/memory; mtime .gitignore = 2026-08-19 09:03:55 (п
чинить: Развести .gitignore по узлам (per-machine, вне синкаемого канала) или вернуть хабовый вариант и исключить файл из claude-config шары
🟧 Корень 3: claude_git_snapshot.ps1 маскирует сбой — не проверяет $LASTEXITCODE после git add/commit, печатает 'committed' при проваленном коммите; try/catch не ловит git-фаталы (native stderr не кидает исключение в PS 5.1)
Код скрипта: 'git -C $repo add -A; $changes = git -C $repo status --porcelain; if ($changes) { git commit ... | Out-Null; Write-Output ("committed: ...") }' — ни одной проверки exit-кода; grep ErrorActionPreference => exit 1 (нет); в моём повторе add_exit=128,
чинить: После add и commit проверять $LASTEXITCODE, при !=0 печатать ERROR и выставлять ненулевой exit скрипта, чтобы LastTaskResult краснел
🟨 Частичная страховка жива: суб-репо коммитят исправно, зеркало _config-backup покрывает CLAUDE.md+settings.json; БЕЗ страховки с 19.08 остался CLAUDE.CHANGELOG.md и прочий root-канон
Последние коммиты: skills 2026-08-21 22:07:38, scripts 22:07:39, hooks 22:07:39, scheduled-tasks 22:07:39, memory 22:07:40, _config-backup 21:52:38; в скрипте зеркалится только @('CLAUDE.md','settings.json'); CLAUDE.CHANGELOG.md изменён 21.08 21:50 и висит нез
чинить: Добавить CLAUDE.CHANGELOG.md в зеркало _config-backup (одна строка в скрипте) — независимо от починки root-репо
🟨 Битые ссылки волта: 9225 битых body-линков из 320726 (2.9%) + 447 wikilink-утечек в память (MEMORY-LEAK) + 98 dangling frontmatter-refs; сам прибор validate_links.py жив и бежит
python E:\Obsidian\_imports\validate_links.py => 'scanned 78273 files in 17 curated dirs; body links 320726 | broken 9225 | MEMORY-LEAK 447; fm refs 40941 | DANGLING 98 (196 occurrences)'; ночной orphan-scan бежал сегодня: _nightly.log => 'done 21-Aug-26 2:47:
чинить: Тренд не замерен (нет исторической точки сравнения в этом аудите) — завести счётчик broken в ночной прогон и смотреть динамику; 9225 руками не чинится, нужен батч-фиксер по классам
🟨 MEMORY.md хаба: 22909 байт = 91.6% жёсткого бюджета 25000 (warn-порог 20000 пробит), 135/200 строк; вырос со стартовых 20768 за сессию
wc -c/-l C:\Users\Anton\.claude\projects\E---CLAUDE-PaloAltoPC-June26\memory\MEMORY.md => 22909 байт, 135 строк (лимит харнеса 25KB/200 строк, хвост режется молча)
чинить: Ничего руками (§10.0: жмёт только суточный оптимизатор узла); строка-репорт оставлена — до красной зоны ~2KB
🟨 .bak-мусор в волте: 492 файла, копится в _Dashboards (221) — janitor туда не ходит; sync-conflict почти весь прибран (4247 из 4286 лежат в .stversions/_sync-conflict-archive), живых 39
find по E:\Obsidian\Anton-Knowledge: *.bak* => 492 (топ: _Dashboards 221, .stversions 54, 10-Tasks 50, 00-System 34); *sync-conflict* => 4286, из них .stversions 3890 + _sync-conflict-archive 357; живых вне архивов 39
чинить: Расширить janitor на _Dashboards/*.bak (221 файл — 45% всего мусора в одной папке)
🟨 Две машины прямо сейчас дерутся за _machine-bus/_onair/ACTIVE_NOW.md — 2 свежих sync-conflict за последний час
stat живых конфликтов: ACTIVE_NOW.sync-conflict-20260821-215113-4YSJ7MU.md (21:50) и ACTIVE_NOW.sync-conflict-20260821-221353-4YSJ7MU.md (22:10) — оба от узла 4YSJ7MU
чинить: Не чинил (read-only); класс известный — onair-доска пишется с двух узлов одновременно, кандидат в Breakage-Journal строкой
✅ Индекс памяти hub-and-spoke работает: из 677 memory-файлов напрямую в MEMORY.md указаны 127, остальные закрыты хабами; истинных сирот (не упомянут НИГДЕ, ни в одном memory-файле) всего 24. Стартовая цифра '153 без указателя' не по
Счёт: 677 *.md всего; grep каждого имени по MEMORY.md => 549 не упомянуты напрямую (это норма — спицы живут в хабах); grep по конкатенации ВСЕХ memory-файлов => 24 файла с 0 внешних упоминаний
✅ Волт-git жив и свеж: последний коммит моложе 20 минут на момент проверки
git -C E:\Obsidian\Anton-Knowledge log -1 => 'e5104e7 2026-08-21 22:00:02 +0100 вечер 21.08: догоняющий скан журнала...' (проверка ~22:15)

не проверено (5)

Полный список 9225 битых ссылок (validate_links вывод обрезан на заголовке — смотрел только сводку)
История Task Scheduler (Get-WinEvent) за 19-21.08 — вывод скрипта в задаче не пишется никуда, восстановить его печать за прошлые дни нельзя
Политика очистки .stversions (3890 конфликт-копий + 54 .bak — растёт или ротируется, возраст не мерил)
Наличие таких же пустых embedded-репо на других узлах флота (класс может жить и на пирах — та же связка Mac-gitignore + claude-config синк)
Кто именно создал пустой projects/C--Users-Anton/memory/.git (git init без коммита) — авторство не установить read-only

■ ЖЁЛТАЯ — свежесть выходов (§5.5: возраст ВЫХОДА у потребителя), хаб A-2022BAYAREA

🟧 fb-watch-daily мёртв 16 дней, а его downstream-файл fb_wall_window.json мёртв 47 дней и продолжает кормить day_ledger ложными нулями: леджер за 20.08 показывает «Посты: FB 0 · X 0» на основе файла от 05.07
ls: E:/Obsidian/_imports/content-factory/fb_posts_scan.json mtime 2026-08-05T22:37 (16.0д); fb_wall_window.json mtime 2026-07-05T19:32 (47д); x_wall_window.json 2026-08-06T20:25 (15д). day_ledger.py строки 203-204 читают именно fb_wall_window.json/x_wall_windo
чинить: Поднять рельсу fb-watch (Claude-in-Chrome side-panel на хабе либо Graph API: FB_USER_TOKEN в secrets\fb_graph.env, проверка python ~\.claude\scripts\fb_posts_poll.py check); отдельно: output_freshness сторожит fb_posts_s
🟧 Вердикт STALE по content-drain-writer стоит на врущем приборе: mtime штампа откачен назад — файл СОЗДАН сегодня 10:41 и внутри написано 2026-08-21T10:41:19, но LastWriteTime = 19.08 12:22; сторож меряет mtime и кричит 2.4д на дета
PowerShell Get-Item _stamps\content-drain-daily.stamp: CreationTime 21-Aug-26 10:41:11, LastWriteTime 19-Aug-26 12:22:17; содержимое файла: «content-drain-daily 2026-08-21T10:41:19». При этом drafts/ содержит 4 черновика от 21.08 19:02-19:32 (серия NPC, source
чинить: Разобрать, кто пишет штамп с подменой mtime (запись через copy/rename с переносом атрибутов либо Syncthing-откат); сторожу надёжнее читать ISO-дату ИЗ ТЕКСТА штампа, а не mtime. НЕ чинил (read-only)
🟧 Вторая сторона той же детали: прогон content-drain 20.08 23:14 отштамповал heartbeat и вышел exit=0, сам же написав «Файлы созданы или изменены: нет» (дверь к диску заклинило) — зелёный кран без легшей работы, ровно тот класс, рад
tail C:\Users\Anton\.claude\scripts\_content-drain-daily.log: «…дверь к диску заклинило раньше, чем робот смог прочитать очередь … Файлы созданы или изменены: нет. [20.08.2026, 23:13 RU] heartbeat stamped: content-drain-daily; exit=0 20-Aug-26 23:14:40.78». he
чинить: Прогон, не породивший артефакта, не должен штамповать heartbeat/exit=0 — вернуть не-ноль либо штамповать только после post_output_check.py content-drain-daily
🟧 headless-auth RED: OAuth для headless claude -p упёрся в недельный лимит подписки — все ночные LLM-роботы хаба стоят до сброса (4am Europe/London), сегодняшняя ночь свежести уже под ударом
cron_watchdog прогон 21.08: «RED headless-auth: smoke returned no OK (token=store, loggedIn=True): You've hit your weekly limit · resets 4am (Europe/London) → все ночные LLM-роботы стоят/портят данные»
чинить: Дождаться сброса (сегодня 4am London) либо claude auth login под a2; после сброса перепрогнать пропущенные ночные (facebook-diary и содержательные краны) за пропущенный день
🟧 MCP-краны молчат неделями: tg-calendar-agenda 616ч (25.7д), reddit-warmup-lead 616ч, alpha-to-tg 271ч (11.3д), five-hard-monthly 497ч и вовсе не зарегистрирован в REGISTRY_MCP (стамп-сирота); их выходы никто не производит → потреб
python cron_watchdog.py (боевой прогон, см. minor-находку ниже): «RED tg-calendar-agenda МОЛЧИТ 616 ч · alpha-to-tg МОЛЧИТ 271 ч · reddit-warmup-lead МОЛЧИТ 616 ч · five-hard-monthly МОЛЧИТ 497 ч — кран НЕ в REGISTRY_MCP». Оговорка: tg-calendar-agenda возможно
чинить: По каждому решить: жив (перезапустить кран) / умер (снять стамп и строку надзора, чтобы не был вечно-красным волком); five-hard-monthly зарегистрировать или удалить устаревший стамп
🟨 Win-Планировщик: 4 задачи Disabled (bus-guard, Claude Sessions to Vault Daily, heartbeat-relay, UFO-UAP Digest Weekly) и 2 падают с LastResult=1 (Claude Config Integrity Gate, Fleet Manifest Check) — сторожа целостности конфига и
cron_watchdog: «win=29 mcp-wired=41 red=11; RED bus-guard ОТКЛЮЧЁН · Claude Config Integrity Gate СБОЙ LastResult=1 (0x1) · Claude Sessions to Vault Daily ОТКЛЮЧЁН · Fleet Manifest Check СБОЙ LastResult=1 · heartbeat-relay ОТКЛЮЧЁН · UFO-UAP Digest Weekly ОТКЛ
чинить: Прочитать логи двух падающих задач и решить судьбу четырёх Disabled (намеренно выключены или забыты); не трогал (read-only)
🟨 Инструментальная граблина: cron_watchdog.py не знает --help — мой вызов «--help» отработал как боевой прогон и отправил один штатный алярм в 03 (dual-rail bus_send), нарушив read-only намерение аудита; содержимое алярма = реальный
grep argv cron_watchdog.py: обрабатывается только «--dry» (строка 415), --help не перехватывается; вывод прогона завершился строкой «alerted (changed)». Read-only режим у этого инструмента = флаг --dry
чинить: Добавить перехват -h/--help (печать usage, exit 0), чтобы справка не стреляла алярмом; Антону знать: в 03 сегодня ~22:15 один алярм от watchdog — это мой аудиторский вызов, не спонтанный
✅ output_freshness (движок scripts/_shared/output_freshness.py) жив и отработал: 31 выход под надзором, 29 OK, 2 STALE (content-drain-writer 2.4д, fb-watch-daily 16.0д)
python C:\Users\Anton\.claude\scripts\_shared\output_freshness.py --dry-run --force → «2/31 выходов протухли … content-drain-writer: возраст 2.4д > лимит 30ч | fb-watch-daily: возраст 16.0д > лимит 30ч … (dry-run: alarm NOT sent)». --force понадобился из-за ma
✅ Ключевые артефакты-потребители свежие: System-Health.html — метка ВНУТРИ 2026-08-21 12:00 (≈10ч); Task-Backlog.html — mtime 21.08 04:30, данные до 21.08; Fleet-Routines-Registry.html — mtime 21.08 10:48, внутренние метки до 2026-0
grep дат внутри файлов + ls: System-Health.html «2026-08-21 12:00» (mtime 12:00); Task-Backlog.html содержит 1×2026-08-21, 31×2026-08-20 (mtime 04:30); Fleet-Routines-Registry.html «2026-08-21T05:56» (mtime 10:48); DayLedgers/day-ledger-2026-08-20.md mtime 202

не проверено (6)

Потребление алярмов в TG-чате 03 (кто читает и реагирует) — чат не открывал
Свежесть выходов на пирах/Маяке — аудит только хаба
Корень откаченного mtime у content-drain-daily.stamp (кто и как пишет штамп) — требует эксперимента с записью, вне read-only
Кто именно писал сегодняшние черновики drafts/ (drain-робот в 10:41 или живая voice-сессия hub:5656) — по артефактам похоже на второе, не доказано
Посылки _transit/_deploy непринятые (лейн §7.5) — вне линии
Причина tg-calendar-agenda: намеренный СТОП (память calendar-agenda-stopped) vs поломка — вердикт не выносил

■ ЖЁЛТАЯ — карта системы

🟧 RED на карте даёт НЕ score (98/100 нарисован зелёным #2ecc71), а два critical/daily чека в статусе FAIL: chk-broken-assets и chk-lint-flags; правило в подвале дашборда дословно «Будим (RED) только на critical/daily-падения»
sqlite system.db check_result за 2026-08-21 05:47:06: chk-broken-assets daily/critical fail «6 broken: Claude Config Integrity Gate, Claude Desktop Interactive Launch, Claude Intention Daily, Claude Routine Rights Census, Claude Sessions Digest SHADOW»; chk-li
чинить: красное = разобрать 13 broken-задач (см. классы ниже) + разгрести 13 lint-флагов; это работа не этой read-only сессии
🟧 Класс №2 broken (4 задачи) — НАСТОЯЩИЕ поломки, все вне волта: Approval-Clock-Tick rc=3 (зависший telethon-замок), Config Integrity Gate rc=1 (config усох, гейт честно красный), Desktop Interactive Launch rc=1 (AppX-контейнер слом
_approval_clock_tick.log 21.08 20:56: «[LOCK-STUCK] @***ySsd lock held 13929s by pid 42628 (TTL 300s)… cmd=publish_canon.py … dump rc=3»; _config_integrity.log: «config_integrity RED: config SHRANK -> hooks baseline 136, now 135»; Breakage-Journal 19.08: Claud
чинить: замок: убить/дождаться pid 42628 (уже разбирается сессией tg-rail 20:2x-21:5x); integrity gate: если удаление хука законно — python config_integrity_gate.py snapshot; Desktop AppX — отдельный разбор, runbook отсутствует
🟨 Класс №1 broken (6 задач): rc=123 = недельный лимит подписки Claude, самолечится после ресета — Gmail Digest Morning, Intention Daily, Preference Sweep Daily, Token Spend Watchdog, Voice Triage Daily + утренние прогоны Content Fac
Breakage-Journal 2026-08-20 (Mac16): живая проба claude_run.py вернула rc=123 «You've hit your weekly limit · resets Aug 21 at 5pm»; все лаунчеры этих задач идут через claude_run.py по подписке (ANTHROPIC_API_KEY unset в .cmd); schtasks: все Enabled/Ready, Las
чинить: ничего — после ресета лимита (Aug 21 5pm по часам вендора) следующие плановые прогоны зазеленеют сами; проверить завтра после 08:45
🟨 Премисса «сверься с журналом»: в Breakage-Journal за 21.08 записи о сознательном выключении Content Factory НЕТ — улика сознательности живёт только в самих .cmd (маркер RETIRED-30D + census wf_3614ad0d)
grep -i 'Content Factory|content_factory|result=123|exit 123' по Breakage-Journal.md = 0 строк про списание; смежное в журнале есть (строка 756: STOP-POSTING.flag 8 суток держал контент-каскад), и флаг снят сегодня: файл _machine-bus/STOP-POSTING.flag.lifted-2
чинить: списание рутины стоило бы оставлять строкой в журнале/реестре списаний, а не только комментарием в лаунчере — иначе следующий аудитор снова примет труп за поломку
🟨 Класс №3 broken (2 задачи) — бухгалтерия, не поломка: Routine Rights Census и Sessions Digest SHADOW Disabled с 09.08, но в реестре списаний их нет
system.db asset detail обеих: «state=Disabled last=08/09/2026 result=0 | Disabled, но в реестре списаний её НЕТ»
чинить: вписать обе в реестр списаний — карта перестанет считать их broken
🟨 Дашборд отстаёт от БД: HTML и System-Automations.md = снимок 12:00 (11 broken), а system.db успел сделать ещё 2 скана — 16:31 (12 broken) и 20:06 (13 broken, добавились FB Watch Daily и Consensus Tick, которых на дашборде нет). Сч
mtime System-Health.html = Aug 21 12:00; sqlite scan_run: (2026-08-21 05:45, broken=6) → (12:00, 11) → (16:31, 12) → (20:06, 13); chk-broken-assets писал «6 broken» потому что бежал в 05:47, до дневных смертей
✅ Волт-ядро (sync/reindex/backup/vault-пайплайны) ЗЕЛЁНОЕ целиком — ни одна из broken-задач его не касается
chk-vault-backup-fresh pass «last commit 1.0h ago (Anton-Knowledge)»; chk-restore-drill pass (restored .bak-anna-contact 2311 bytes); chk-db-integrity pass «all dbs ok»; дашборд: Brain Reindex Daily/Frequent/Watchdog/Weekly = ok result=0 (frequent last 21.08 1
✅ Content Factory Daily и FB Watch Daily broken на карте — это ПРОТУХШИЙ статус: обе сознательно списаны СЕГОДНЯ в 17:22 (карта снята в 12:00, до списания). Это не поломка
head -3 content_factory_daily.cmd и fb_watch_daily.cmd: «REM RETIRED-30D 2026-08-21 census wf_3614ad0d, mandate /decide anton 17:22. Corpse per census. Review 2026-09-20» + «exit /b 0» (бэкап .bak-retire-20260821 рядом); schtasks «Claude Content Factory Daily»
чинить: ничего чинить не надо; косметика: скан завтра сам перекрасит их в ok (exit 0)
✅ Карта обновится САМА сегодня ночью: полный пересбор (скан + chk-чеки + HTML + MOC) = задача «System Architect Nightly» ежедневно в 05:45, она жива; дневные сканы 12:00/16:31/20:06 — ad-hoc прогоны сессий, они пишут только в БД
schtasks «System Architect Nightly»: State=Enabled, Status=Ready, Last Run 21.08 05:45 rc=0, Next Run 22.08 05:45, Task To Run=E:\Obsidian\_imports\arch\run_architect.cmd; check_result все от 05:47:06 (чеки бегут только ночью); подвал дашборда: «Этот экран и з

не проверено (6)

13 lint-флагов chk-lint-flags пофлажно не разбирал (каждый — свой класс, отдельная работа)
пер-задачные логи лимит-класса (Gmail/Intention/Preference/Token/Voice) не открывал — класс доказан журнальной записью 20.08 rc=123 и общим кодом лаунчеров, но конкретный текст отк
какой именно бак (bb/a2/подписка хаба) упёрся в weekly limit и точный часовой пояс ресета «Aug 21 5pm» — не устанавливал
Consensus Tick rc=1: корень не копал (по соседству с telethon-замком, но улики его лога не читал)
семантика exit=3 vs exit=1 у approval_clock за пределами прочитанного лога
E:/Obsidian/_imports/system.db (0 байт, Jul 25) — пустой дубль, истинная БД = _imports/arch/system.db; кто держит пустышку — не выяснял

■ ЖЁЛТАЯ — RAG reindex (второй мозг)

🟨 Обещание 'search lag ≤15 min' в худшем случае нарушается вдвое: cooldown <15м + расписание 15м дают фактическое обновление индекса раз в ~30 мин
Лог _reindex_frequent_log.txt, хвост за сегодня: 21:22 'cooldown: index refreshed 14.8m ago (<15m) -> skip', 21:37 прогон, 21:52 'refreshed 13.9m ago -> skip', 22:07 прогон — строгий паттерн через раз (84 запуска задачи за сегодня, реальных реиндексов ~половин
чинить: Снизить cooldown в reindex_frequent.py с 15м до ~12м (или сдвинуть порог ниже периода расписания), чтобы каждый 15-минутный тик реально реиндексировал; НЕ чинил — read-only мандат
🟨 В e5-индексе живёт чанк той же заметки с Mac-путём чужого узла — дубль записей с разной географией путей
Проба BRAIN_EMB_BACKEND=e5: среди хитов src: /Users/anton/Obsidian/Anton-Knowledge/02-Decisions/decision-2026-08-21-routine-org-model.md (Mac-путь) РЯДОМ с E:\Obsidian\...\decision-2026-08-21-routine-org-model.md (локальный). Вероятный источник — шард с Mac-уз
чинить: Нормализовать пути шардов к vault-относительным при мердже в e5-индекс, иначе дубли жгут топ-K слоты; не чинил — read-only
✅ Задача 'Brain Reindex Frequent (15m)' жива и зелёная
schtasks /query /v: Status=Ready, Last Run Time=21-Aug-26 22:07:01, Last Result=0, Next Run Time=21-Aug-26 22:22:00, REP=PT15M, запуск pythonw.exe E:\Obsidian\_imports\reindex_frequent.py; лог _reindex_frequent_log.txt: прогон 22:07:01 -> 'индекс OpenAI: 21519
✅ Задача 'Brain Reindex Daily incremental ' (имя без скобок, в CSV задвоена — вероятно 2 триггера) отработала сегодня успешно
schtasks /query /v: Last Run Time=21-Aug-26 4:00:02, Last Result=0, Next Run=22-Aug-26 3:00:00, Task To Run=E:\Obsidian\_imports\reindex_daily.cmd; лог _reindex_log.txt 04:00: 'cooldown: index refreshed 6.9m ago -> skip' + openai index 21259 чанков reuse=21259
✅ Индексы, которые реально читает brain_ask.py, свежие: 5.4 мин (OpenAI) и 6.6 мин (e5) на момент проверки
brain_ask.py строки 40-43: OAI_EMB=_brain_oai.npy, OAI_META=_brain_oai_meta.pkl, E5_EMB=_brain_e5.npy, E5_META=_brain_e5_meta.pkl. mtime: _brain_oai.npy и _brain_oai_meta.pkl = 21-Aug-26 22:09:30, _brain_e5.npy и _brain_e5_meta.pkl = 21-Aug-26 22:08:23, при Ge
✅ Гейт _test_reindex_frequent.py зелёный полностью
python E:\Obsidian\_imports\_test_reindex_frequent.py -> 15/15 OK (вкл. 'index output is fresh (< 90 min) -> _brain_e5_done.txt is 6.9 min old', 'trigger still armed NEXT=2026-08-21T22:22:00'), 'ВЕРДИКТ: РЕГРЕССИЙ НЕТ', EXIT=0
✅ Живая проба: сегодняшняя заметка decision-2026-08-21-routine-org-model (создана 17:45:53, правлена 21:58:15) находится хитом №1 — lag-тест пройден
python brain_ask.py "оргмодель рутины сотрудники" -> EXIT=0, 12 hits; хит 1: [rr=4.97] src: E:\Obsidian\Anton-Knowledge\02-Decisions\decision-2026-08-21-routine-org-model.md; хит 2: task-2026-08-21-routine-org-model-rollout.md (тоже сегодняшний). Правка заметк
✅ Оба эмбеддинг-бэкенда живы: OpenAI (prod) и e5 (локальный GPU fallback)
OpenAI: реиндекс 22:09:30 встроил 503 новых чанка через API ('embed 256/503', dim=3072, exit 0) + явная проба BRAIN_EMB_BACKEND=openai -> EXIT=0, заметка найдена, fallback-сообщений в stderr нет. e5: явная проба BRAIN_EMB_BACKEND=e5 -> EXIT=0, заметка найдена,

не проверено (4)

Свежесть шардов пиров внутри _machine-bus\_brain-shards (Brain Shard Tick result 0 виден, содержимое шардов не вскрывал)
Содержимое _reindex_watchdog.log (mtime 01-Jul — либо ротация, либо watchdog пишет в другое место; сам таск result 0)
Индекс сессий _brain_sessions_meta.pkl (21-Aug 3:30) — отдельная линия, не входила в задание
Точная причина задвоения строки 'Brain Reindex Daily incremental ' в CSV schtasks (вероятно 2 триггера одной задачи; оба ряда идентичны, result 0 — не копал глубже)

🔍 Критик полноты — где сам аудит слаб (честно)

🟥 Главный critical всего аудита (бэкап: «бандлы 11–21.08 НЕ в облаке») оставлен гипотезой «скорее всего» — облачная сторона не проверена, хотя read-only путь существовал: чтение drive.google.com в залогиненном браузере = GET, а «один Chrome на 5 машинах» делает
🟧 Вердикт «восстановимо ПОЛНОСТЬЮ» стоит на self-attestation: целостность бандла принята по 'git bundle verify OK' самого писателя + healthcheck 18.08, при этом ТОТ ЖЕ healthcheck в этой же линии доказан «вечно зелёным по offsite» и несущим «устаревший ложный PR
🟧 chk-broken-assets — один из ДВУХ драйверов RED на карте системы — не вскрыт вообще: в findings есть только его имя. Половина причины красного статуса карты не исследована, лейн при этом закрыт yellow — классическое «красное, замаскированное жёлтым»
🟧 Approval-Clock-Tick rc=3 (зависший telethon-замок) — это рельса 02 POLICE / QQQ (§3.1): если тик мёртв, перепинги и эскалации Tier-2-асков не идут, аски гниют молча. Аудит списал в «настоящие поломки, все вне волта» без оценки: сколько дней стоит, висят ли сей
🟧 Межлинейное противоречие о времени ресета weekly-лимита не замечено: линия карты цитирует «Aug 21 5pm», линия свежести — «4am Europe/London». От этого зависят два вердикта: «сегодняшняя ночь свежести уже под ударом» и «карта обновится САМА в 05:45» (System Arc
🟧 Прямое противоречие линий по fb-watch не сведено: карта говорит «FB Watch Daily сознательно списана сегодня 17:22, это не поломка», свежесть говорит «fb-watch-daily мёртв 16 дней, downstream fb_wall_window.json мёртв 47 дней и кормит day_ledger ложными нулями»
🟧 Оба «ok»-вердикта синк-линии («все подключённые пиры догнаны need=0», «данные не теряются») стоят на ОДНОМ приборе — REST/БД самого хаба. Встречная методика названа самой сводкой (спросить машины по шине / heartbeat в 03) и не использована; уверенность вердикт
🟧 Аудит сам создал бесплатный трассер и не воспользовался им: вызов cron_watchdog «--help» отправил живой алярм в 03 (dual-rail bus_send) — идеальная возможность проверить доставку и потребление рта сторожей, но чат 03 так и не открыт. Весь слой watchdog'ов конч
🟨 HP17 «офлайн 7 суток» подан major-долгом без RECALL по контексту: standing-память away-mode-45-days говорит «hub один до ~сент» — офлайн ноута, вероятно, ШТАТНЫЙ. Реальный риск (воскрешение старых копий при возврате) заявлен без чтения настроек versioning на х
🟨 _reindex_watchdog.log с mtime 01-Jul (7 недель тишины) отправлен в «не проверено» с удобной вилкой «либо ротация, либо пишет в другое место» — а это возможный мёртвый сторож RAG-рельсы, т.е. ровно silent-green класс §5.5; линия при этом зелёная на result 0 пла
🟨 Свежесть brain-шардов пиров принята по «Brain Shard Tick result 0» — код выхода задачи вместо возраста ВЫХОДА у потребителя, что прямо противоречит принципу линии (§5.5: сторожим возраст выхода). Вход мозга от пиров не доказан
🟨 Линия свежести назвала System-Health.html «свежим» (внутренняя метка 12:00, ≈10ч), тогда как линия карты показала: БД ушла на 2 скана вперёд (16:31 и 20:06, broken 11→13). Формальная свежесть ≤ суток есть, контентная протухлость потребителя (карта врёт на 2 за
🟨 Blast radius синка claude-config 19.08 09:03 не измерен: установлена перезапись только root .gitignore с MacBook, но что ещё перезаписал тот же синк — не смотрели. Рядом в линии карты висит Config Integrity Gate rc=1 «config усох» — возможно, то же событие; св
🟨 Шина _machine-bus — KEEP-рельса (§0.12, §7.3) — не имеет собственной линии аудита: фрагменты размазаны по трём линиям (2 застрявших элемента + кейс-коллизия, драка за ACTIVE_NOW.md, слепой sync_check), а вердикта по рельсе целиком (доставка посылок §7.5, живос
🟨 headless-auth RED («все ночные LLM-роботы хаба стоят») + 6 задач rc=123 из линии карты = ОДИН инцидент «бак подписки упёрся», размазанный по двум линиям без сводной карточки, владельца и без влияния на статус: линия свежести осталась yellow при глобальном стоп

🧒 Простыми словами. Проверили сердце системы. Хорошая новость: если сегодня случайно всё стереть, мы всё вернём — есть и история изменений, и 14 дневных слепков, и корзина на 30 дней. Плохая: одна из страховок (копия в облаке Google) умерла 11 дней назад, а её сторож так устроен, что смотрит не туда и рапортует «всё хорошо». Если сгорит сам компьютер — облачной копии не окажется. Чинится перелогином Google Drive, нужны твои руки на минуту. Остальное — жёлтое: сторожа кое-где слепые или спят, две машины дерутся за один файл, у ноутбука недосинк за неделю (он штатно спит). Ничего из этого прямо сейчас данные не ест. Починки уже расписаны роботам на утро.