obsidian-vault/personal/projects/personal-os/personal-os-action-plan-2026-10-05.md

Personal OS — план действий E1–E5

Текущий runtime 14.10.2026: Asana collector заменён постоянным worker в основной personal_os, с Windmill schedule каждые пять минут, live roster scans каждые 15 минут и events cursors. Все 28 живых списков проектов перечитаны, обнаружено 35 620 memberships. Очередь изменений, связанные объекты и фоновая сверка продолжаются и показаны отдельно. Legacy read projection и общий writer lock реализованы; старый collector архивирован. Контракт и проверка runtime.

Историческая сверка до этого rollout дала 21/28 по ID scan 06.10, 35 080 memberships, 11 недоступных direct tasks и 1 685 внешних dependency targets. Эти числа не являются текущим live freshness отчётом.

Основание: исследование шести уровней, архитектурные контракты, контракт данных R2. Этот документ конкретизирует порядок исполнения. Предложения о технологиях не означают, что они уже установлены или выбраны по результатам испытаний.

Что делаем сейчас

Дополнение 14.10.2026 — work items и контекст дизайнов реализованы и перенесены в основную БД. Каждый локальный ворктри без принятой связи должен получать отдельный устойчивый work item на дашборде для ручного либо агентского резолва: привязать существующую работу/задачу, учитывать локально, исключить с причиной либо подготовить и завести задачу Asana. Повторный сбор сохраняет item и принятое решение. В контекст работы добавляются tech-design задачи Asana, опубликованные документы и их драфты Obsidian, включая драфты без Asana ID; смысловые совпадения проходят резолв. Порядок, действия и критерии приёмки — в текущем плане GitHub и рабочих ситуаций. Проверены устойчивые items, сохранение решений, цепочки дизайнов, отдельный вызов локальной модели из Windmill и безопасное создание задачи из черновика. Пользователь разрешил основной перенос; все 17 таблиц перенесены с совпадением полных хешей. Windmill и дашборд переключены на personal_os.

Текущая итерация — E1: сделать проверяемой загрузку Asana-проектов. Пилот трёх проектов завершён; по его результату расширен scope. Полный ID-обход завершён для 28 проектов: 26 текущих подписок и два проверенных пилота. Задачи из остальных проектов, напрямую связанные с пользователем, грузятся адресно. В конце должны быть видны полный доступный состав выбранных проектов, все принадлежности задач, доступная история и дерево подзадач. Для каждого пробела будет причина, для каждого запуска — воспроизводимый отчёт.

Начальный порядок: Apple Team Meta Project → Apple Feature Flags Registry → Scheduled Rotations. Meta Project даёт разные типы объектов и известные примеры потерь; остальные проверяют переносимость решения. Размер полных проектов пока не измерен, поэтому длительность массовой выгрузки определяется после дешёвого обхода IDs.

В исходном рабочем зеркале были пропуски задач, комментариев и связей. Тестовый E1 backfill теперь сверен с независимым ID-обходом всех трёх пилотов; отчёт. Это не означает полноту всех источников, рабочего зеркала или готовность персонального ранжирования.

Кто что делает

Участник	Ответственность	Когда нужен
Codex	Подготовка изменений и проверок, технические решения, сверки, отчёты, актуализация документации	Каждый пакет работ
Алекс	Смысл неоднозначных обязанностей, актуальные карьерные цели, выбор между существенными личными приоритетами	E2/E4, по коротким подготовленным карточкам
Алекс	Подтверждение применения миграции рабочей БД после предъявления конкретного изменения, проверки и восстановления	Перед E1.5, согласно пользовательскому правилу о миграциях
Алекс	Границы обработки частных данных и расхода на модели, если выбранный эксперимент требует внешнего inference	Перед соответствующим прогоном E3; после подготовки конкретного предложения

Выбор имён таблиц, технических ключей, тестовых объектов и алгоритма обхода — работа Codex. Алекс не составляет вручную реестр IDs и не размечает весь архив. Новые агентские запуски, расписания и запись в корпоративные системы — отдельные решения, они не следуют из создания этого плана.

E1. Пять пакетов ближайшей реализации

E1.1. Зафиксировать область и воспроизвести потери

Действие: подготовить независимый способ проверки сборщика до изменения его поведения.

Работа	Конкретный результат
Зафиксировать исходное состояние	Релевантный diff, версии схемы/SDK, список читателей project_gid, владельцы текущих запусков. Чужие незавершённые изменения остаются учтёнными в исходном состоянии.
Описать область пилота	Три проекта с названиями и проверенными source IDs; типы объектов; поля; правила рекурсивного обхода и пределы доступа. IDs читаются из API/сохранённой выборки.
Воспроизвести известные потери	Fixtures нескольких memberships, закрытой встречи, детей Retrospectives, пропавших задач и частичного API-ответа.
Проверить договор с Asana SDK	Реальная форма ответа и next_page; больше одной страницы; поддерживаемые параметры endpoint. Тестируется установленная версия библиотеки.
Собрать исходный отчёт	Объекты source/local, missing IDs, несовпадающие поля, непроверенные разделы; без заявления о полноте на основании лимитированной страницы.

Предлагаемые артефакты: test/asana-coverage.test.js, test/fixtures/asana-coverage/, scripts/asana-coverage-audit.js, planning/asana-coverage-pilot/README.md. Это новые планируемые файлы, сейчас их наличие не заявляется. Частные подробные ответы остаются в разрешённом локальном хранилище; в переносимые fixtures попадают минимизированные данные без секретов.

Приёмка: тесты воспроизводят потери текущего кода; auditor не вызывает тот же нормализатор для формирования эталона и результата. На странице с next_page отчёт никогда не ставит complete.

Твой результат: одна таблица «что именно теряем и чем проверим исправление». Никакой ручной настройки источников от тебя на этом шаге не требуется.

E1.2. Сохранить все связи и различать полный/частичный ответ

Действие: подготовить новую модель хранения Asana, совместимую с текущими читателями.

Изменение	Правило
Множественная принадлежность	Отдельные связи task–project–section; одна задача может иметь несколько проектов. Пользовательская секция My Tasks хранится отдельно от секции проекта.
Обновление связи	Полный ответ о memberships заменяет текущий набор в транзакции; отсутствующее в частичном ответе поле означает «не загружено». Пустой полный список означает реальное отсутствие memberships на момент наблюдения.
Версии наблюдений	Source ID, fetched/observed time, source modified time, content hash, набор реально прочитанных полей, ссылка на исходный ответ. Снимки с тем же содержимым повторно не размножаются.
Состояние сбора	Run/project/object-type, начало/окончание, страница/checkpoint, счётчики, ошибки, completeness и причина ограничения. Отсутствие доступа отличается от пустого раздела.
Совместимость	project_gid временно остаётся совместимым скалярным представлением; граф и новый auditor читают все memberships. Старые source priority и possibly_deleted не используются как доказательство текущей ответственности или удаления объекта.

Дорабатываются db.js, shape нормализованной задачи и версия схемы. Новая миграция использует существующий контракт source records/relations, насколько он уже реализован; если это ещё только проект R2, минимальные Asana-таблицы служат adapter storage с явным mapping в R2. Создание второго независимого реестра истины недопустимо.

Миграция подготовлена в migrations/005_asana_coverage.sql и применена только к отдельной тестовой БД. Применение к рабочей БД входит в E1.5.

Критические проверки: два проекта у одной задачи; перенос секции; снятие membership; полный пустой список; ответ без поля; повтор одного payload; более старый source snapshot после нового; rollback транзакции при ошибке. Устаревший снимок сохраняется как наблюдение, но не перезаписывает более свежее текущее состояние. При равном timestamp и конфликтующем содержимом требуется повторная сверка, а не произвольный победитель.

Приёмка: все memberships восстановлены из доступного raw для пилота; неполные ответы не стирают поля; историческое состояние не выдаётся за актуальное. Полнота raw отдельно проверяется по source API.

E1.3. Сделать полный обход и устойчивое продолжение

Действие: реализовать отдельный scoped backfill и сверку, не подменяя ими весь текущий рабочий цикл.

Часть	Что меняется
Задачи проекта	Обход /projects/{gid}/tasks по реальным offset-токенам; получение нужных полей; явная проверка включения старых закрытых задач. Исторический обход не ограничен изменениями последних 30 дней.
Подзадачи	Полный обход страниц и рекурсия по детям; visited set по source ID; защита от циклов; checkpoint очереди. Достижение лимита означает partial, а не успешную полноту.
Stories	Начальная загрузка доступной истории открытых и закрытых задач. Режим полного чтения игнорирует старый story cursor; при повторной сверке замечает редакции уже известных комментариев.
Зависимости и поля	Все страницы доступных dependencies/dependents; parent, followers, custom fields, due_at и project metadata. Ошибка возвращается как ошибка раздела, а не пустой список связей.
Продолжение и ошибки	Run-start watermark, повторяемые записи, checkpoint только после сохранения данных, ограниченные retries с Retry-After/backoff, возобновление после остановки. Просроченный offset приводит к безопасному переобходу раздела с дедупликацией.

Полный первичный обход не строится на task search. По официальной документации поиск не поддерживает обычную offset-пагинацию и имеет задержку индексации; общий проектный endpoint поддерживает offset и отдельный фильтр завершённых задач. Параметр modified_since, который текущий код передаёт проектному endpoint, не перечислен в его текущем контракте: считать его рабочим инкрементальным фильтром без проверки нельзя. Project tasks, Search, Pagination.

На первом scoped пилоте повторная сверка небольших проектов может читать полный список IDs/метаданных и обновлять изменившееся. Более дешёвый инкрементальный механизм выбирается по проверенному API-контракту и измеренному объёму. Search остаётся способом обнаружения кандидатов, но не сертификатом полноты.

Граница обхода: все задачи с membership в трёх проектах и их доступные потомки. Внешние зависимости загружаются как ссылки/минимальные карточки; весь соседний проект не обходится рекурсивно автоматически. Messages, status updates и содержимое вложений получают отдельные строки coverage. Их неподдерживаемый импорт обозначается как gap, не скрывается общим complete.

Исчезновение из полного списка означает «не наблюдается в этом контейнере». Оно может быть переносом, удалением или изменением доступа. Удаление объекта нельзя вывести из одного отсутствия в проекте; окончание известной связи и неизвестный статус самого объекта хранятся раздельно.

Артефакт: scripts/asana-project-backfill.js с выбранным scope, checkpoint/resume, бюджетом и явной целевой БД. Read-only ID-обход — scripts/asana-coverage-scan-ids.js; независимая сверка тестовой БД — scripts/asana-coverage-verify.js. Режим dry-run перечисляет только ID. Пробный полный backfill Meta Project запущен на отдельной тестовой БД; итоговая сверка ещё не готова.

Приёмка: более одной страницы задач/stories/детей, глубина дерева больше одного уровня, повторные страницы, одинаковые timestamps, 403/429/5xx, обрыв процесса, expired offset, редактирование старого комментария и отсутствие поля проходят проверку.

E1.4. Сверить полный доступный срез

Действие: прогнать новые пути на тестовом контуре с разрешённым чтением исходных систем и предъявить доказательства покрытия.

Порядок загрузки: сначала Meta Project до полной сверки, затем Feature Flags Registry, затем Scheduled Rotations. После первого проекта корректируется оценка числа API-запросов и времени. Лимит запросов/времени у каждого запуска явный; исчерпание сохраняет очередь и статус partial для продолжения.

Проверка	Условие приёмки
Состав	Разность source/local множеств IDs пуста для доступного согласованного среза. Каждый исключённый объект имеет объяснение.
Поля	Все memberships, completion, assignee, выбранные timestamps/поля совпадают на стабилизированной проверяемой версии.
Истории и дерево	Для доступных выбранных задач совпадают story IDs и parent–child связи; известные потерянные комментарии и дети присутствуют.
Повтор и восстановление	Повтор не создаёт дублей; остановка и продолжение дают тот же результат, что непрерывный обход; частичный сбой не двигает успешный watermark всего проекта.
Состояния	Отсутствие доступа, отсутствие в контейнере, неполная загрузка, устаревшая проверка и подтверждённая пустота различимы в отчёте.

Asana не обещает единый транзакционный snapshot на всё время длительного обхода. Поэтому manifest содержит интервал наблюдения. Изменившиеся во время чтения объекты повторно проверяются; подвижные расхождения остаются отмеченными, а не маскируются заявлением «100% на одну секунду».

Эталон проверяет обход и сохранение раздельно: сохранённые ответы API до нормализации сравниваются с БД; пагинация проверяется контрактными fixtures и повторным независимым перечислением IDs. Количество строк, выданное одним и тем же ошибочным загрузчиком, не является независимым подтверждением полноты.

Поставка: coverage-before.json, coverage-after.json, список расхождений с причинами, отчёт о повторе/возобновлении, короткая Markdown-таблица для Алекса. Во всех файлах — run ID, scope, время, версия кода и схемы. Статистика относится к трём проектам, не ко всей компании.

Приёмка E1.4: нет необъяснённых потерь в проверенной доступной области; оставшиеся gaps явно разделены по типам содержимого. Неполный источник не повышает общий статус до полной рабочей картины.

E1.5. Подключить исправленный путь к рабочему зеркалу

Действие: подготовить и выполнить контролируемое применение после проверки на тестовом контуре.

До подтверждения применения рабочей миграции предъявляются конкретный SQL/diff, backup/restore-проверка, влияние на читателей, ожидаемые блокировки и порядок возврата к предыдущему collector. Это требование пользовательской инструкции о миграциях; оно не блокирует подготовку кода, fixtures и тестового результата.

Сначала устраняется конкуренция старого writer с backfill: единый lease/lock на затрагиваемый scope или согласованное короткое окно применения. После миграции legacy writer не должен перезаписывать более свежие данные или новые связи. Откат приложения сохраняет новые данные; удаление таблиц не является стандартным способом отката.

После применения — один ручной scoped backfill и повторная сверка. Интеграция в существующий collector сохраняет явное разделение initial backfill / reconciliation / incremental. Изменение частоты запусков, новый launchd job и вызовы моделей не входят в этот пакет. Текущие потребители проходят целевую регрессию: My Tasks sections, work-demand, project-truth и day-coordinator в затронутых путях.

Готовность E1: доступный корпус трёх проектов восстановлен в рабочем зеркале, все memberships доступны новым читателям, проверяемые истории/дети загружены, ошибки видимы, повтор и восстановление проверены. Сохраняется список непокрытых Messages/вложений/исторических версий, если источники их ещё не предоставляют.

Твой результат: можно открыть проект и получить честный ответ «что мы о нём загрузили, что изменилось и что ещё не видим». Интерпретации ответственности и приоритетов на этом этапе ещё не объявляются готовыми.

E2. Получить общий корпус и эталон смысла

Зависимость: первые реальные эпизоды готовятся после сверки Meta Project; окончательная оценка компонентов начинается после E1.4 и проверки необходимых дополнительных источников.

Пакет	Работа	Готовый результат
E2.1 Другие источники	Выборочно сверить Zoom, Mattermost и GitHub с их локальными экспортами. Для начала — по три подходящих объекта каждого вида; расширять только по найденным проблемам. Проверить полный transcript/тред/review, авторов, время и ссылку.	Coverage matrix по всем четырём источникам; целевые задачи исправления пробелов.
E2.2 Эпизоды	Собрать 60–100 связных примеров разных проектов, периодов и состояний; включить тихие обязательства и случаи без упоминания пользователя.	Версионированный dataset с source spans, а не россыпью случайных сообщений.
E2.3 Явный граф	Source IDs, все memberships, parent/dependency/PR links, участники; alias mapping разных аккаунтов при подтверждении.	Исходный граф без модельных догадок и схема неизвестных типов.
E2.4 Эталон	Для каждого примера задать ожидаемые объекты, допустимые связи, время, состояние и отношение к пользователю.	Независимая разметка; tuning и holdout отделены по проектам/времени.
E2.5 Обзор	Показать несколько направлений с источниками и gaps; отдельно проверить модели формальной структуры, работ и компетенций.	Первый проверяемый экран/HTML-отчёт рабочего контекста, ещё без дневного планирования.

Загрузка missing Messages/статусных обновлений или расшифровка схем включается в E2, если без них выбранный эпизод неразрешим. Остальные пробелы отмечаются. Расширение корпуса не превращается в бесконечное предварительное требование собрать всю компанию.

Предварительную разметку готовит Codex по источникам. Алекс проверяет максимум пять неоднозначных карточек за один подход: «какая ответственность / какое решение / на чём основано». Непроверенная модельная разметка остаётся черновиком; её нельзя использовать как независимую истину для оценки той же модели.

Приёмка: есть разные направления и типы участия; ни один удобный кейс не определяет вывод; источник отвечает за свои факты; набор позволяет отдельно измерить классификацию, связывание и текущий статус. Неизвестность из-за отсутствующего источника считается корректным допустимым ответом, если она названа.

E3. Выбрать готовые механизмы по результатам

Зависимость: E2 даёт воспроизводимый корпус и согласованные правила обработки частных данных.

Пакет	Эксперимент	Решение
E3.1 Исходный вариант	Явные связи + PostgreSQL lexical retrieval + правила	Зафиксировать исходное качество, время, ручную нагрузку.
E3.2 Дешёвое извлечение	Добавить GLiNER2 на том же корпусе; неоднозначное оставить неизвестным	Определить, какие категории извлекаются локально достаточно хорошо.
E3.3 Граф	Cognee с source IDs/временными ролями против Graphiti на одинаковых эпизодах	Выбрать один механизм или сохранить исходный вариант, если прирост не оправдывает обслуживание.
E3.4 Трудные случаи	Проверить отмены, отрицания, неявный адресат, непрямую связь и состояние во времени	Определить узкую область более сильного анализатора и его допустимые данные/бюджет.
E3.5 Решение	Сравнить ошибки, стоимость, экспорт, replay и сложность поддержки	Один decision record: компонент, backend, модели, версии, основания выбора и нерешённые ограничения.

Перед скачиванием моделей/установкой сервисов составляется конкретная конфигурация: лицензии, размер, RAM, место на диске, разрешённые источники, ожидаемый объём прогона. Jev участвует только как отдельно допустимый закрытый сравнительный вариант. Отдельный graph backend — перестраиваемый индекс; PostgreSQL остаётся реестром принятых утверждений.

Метрики разделяются: recall кандидатов, precision/recall связей по классам, ложные merge, правильность отмен и времени, доля корректного unknown, latency, RAM, стоимость и минуты проверки. Сравнение не сводится к среднему качеству ответа или внешнему виду графа. Для обязательных негативных fixtures требуются отсутствие ложных merge и доказательство каждой принятой модельной связи; на holdout публикуются фактические числа и объём выборки.

Приёмка: выбранный компонент сокращает собственный код при измеримом приемлемом качестве и переносимом результате. В архитектуру добавляются только выигравшие механизмы. Сам эксперимент не включает постоянного фонового LLM-потока.

E4. Проверить твою роль и персональные приоритеты

Зависимость: рабочая структура и источник каждого утверждения проходят E3.

Пакет	Что делает Codex	Что проверяет Алекс
E4.1 Профиль	Собирает текущие области, назначения, ротации, подтверждённый опыт и исторические цели с датами	Устаревшие области, реальные границы ответственности, актуальность целей
E4.2 Отношение	Делит работы на прямые обязанности, пересечения, смежные компетенции, карьерные возможности и контекст	Несколько пограничных примеров с источниками
E4.3 Важность	Строит объяснимую матрицу влияния/срочности с готовностью и ценой участия	Пять подготовленных сравнений важных кандидатов за подход
E4.4 Наблюдение	В течение двух рабочих недель фиксирует рекомендации и фактические изменения без автозаписи в рабочие системы	Короткие поправки «не моё / позже / решено / важно по другой причине»
E4.5 Калибровка	Проверяет пропуски по независимо выбранным работам и исправляет конкретные правила	Принимает или отклоняет смысловые изменения профиля

Каждая рекомендация показывает путь связи с пользователем, источники, срок действия и неизвестность, которая способна поменять порядок. Наличие компетенции не становится обязанностью; карьерная возможность не превращается в принятое обязательство без выбора пользователя.

Приёмка: обязательные критические случаи не потеряны; качество top-k измерено; объяснения короткие и проверяемые; есть охват нескольких направлений; случайный шум не перестраивает приоритеты. Если качество слабое, исправляется конкретный предыдущий слой, а не добавляется ещё одна модель поверх ошибочного графа.

E5. Замкнуть планирование, ретроспекцию и эксплуатацию

Зависимость: понятны актуальные обязанности и качество ранжирования по E4.

Пакет	Поставка	Проверка
E5.1 Ёмкость дня	Календарные окна, конец дня, перерывы, текущий фокус и заявленное состояние	Объединение пересекающихся встреч, отсечение прошедшего времени, неизвестная занятость без выдуманной доступности
E5.2 План	Одно следующее действие, небольшой резерв, причина выбора и условия пересмотра	Сроки/зависимости соблюдены; несрочные обновления не прерывают фокус
E5.3 Исправления	Один feedback endpoint/формат с указанием затронутого факта, роли, приоритета или нагрузки	Исправление пересчитывает зависимые обзоры и сохраняет историю
E5.4 Ретроспектор	План–факт, причины переноса, реальные результаты, цена обслуживания самой системы	Игнорирование не трактуется как неважность; улучшения проходят replay и проверку версии
E5.5 Эксплуатация	Backup/restore, crash recovery, отсутствие дублей, мониторинг coverage, rollback модели/правил	Проверены восстановление и деградация источников; выбранные пользовательские сценарии читают один snapshot

Первый UI — минимальный локальный экран или готовый клиент с adapter, выбранный по трудоёмкости. Полировка iPad и сложная визуализация всей компании не блокируют приёмку понимания работ. Super Productivity рассматривается как готовый UI; OR-Tools подключается только при измеренной необходимости более сложного планирования.

Приёмка: система уменьшает ручной поиск контекста и удержание обязательств в голове; соблюдает границы дня; полезна на реальных рабочих неделях; исправления доходят до карьерного обзора и подготовки встреч. Целевой бюджет регулярного обслуживания — до 10 минут в неделю после настройки, его достижение измеряется. Расписание постоянной работы утверждается по итогам ручного/ограниченного пилота вместе с конкретными полномочиями и бюджетом.

Зависимости и независимая подготовка

flowchart LR
  A[E1.1 Область и воспроизведение] --> B[E1.2 Хранение]
  A --> C[E1.3 Обход и продолжение]
  B --> D[E1.4 Полная сверка]
  C --> D
  D --> E[E1.5 Рабочее зеркало]
  D --> F[E2 Корпус и эталон]
  F --> G[E3 Выбор механизмов]
  G --> H[E4 Роль и важность]
  H --> I[E5 План и ретро]

После фиксации контракта E1.1 независимы подготовка схемы хранения и adapter/tests. Во время backfill можно готовить формат эпизода и проверять покрытие Zoom/Mattermost/GitHub. Смысловые выводы о качестве системы требуют уже сверенного корпуса. Совместные изменения asana.js, sync.js, db.js должен интегрировать один владелец, чтобы избежать несовместимых вариантов записи.

Это карта допустимой параллельной работы, а не сообщение о запущенных агентах. Создание новых задач/агентов не выполнено этим планированием.

Как принимать результаты без длинных отчётов

Каждый пакет заканчивается карточкой одного формата:

Поле	Содержание
Что теперь работает	Один конкретный проверяемый результат
Доказательство	Файл/отчёт, scope, числа проверок и оставшиеся gaps
Что ещё не сделано	Только ограничение, существенное для текущего вывода
Решение Алекса	Конкретный выбор с подготовленными вариантами, только если от него зависит следующий шаг
Следующее действие	Один пакет с ID из этого плана

Статусы пакетов: planned, in_progress, verified, blocked. verified ставится после описанной приёмки; сохранение документа не закрывает реализацию. При блокировке фиксируется конкретная причина и продолжается независимая подготовка. Часы/даты окончания backfill оцениваются после E1.1 по фактическому числу объектов и ограничениям API; фиктивного календарного обещания сейчас нет.

Рабочая очередь на выходе из планирования

Пакет	Статус	Следующий проверяемый результат
E1.1	verified — отчёт и fixtures	6 тестов, независимый полный ID-обход SDK и source/local diff
E1.2	in_progress — схема и writer проверены на тестовой БД	Совместимый projection для старых читателей
E1.3	complete — три проекта загружены в отдельную тестовую БД	7658 уникальных задач с потомками и 125 970 stories
E1.4	verified для трёх пилотов — итоговые отчёты	4618/4618 исходных memberships; известных потерь и неполных разделов нет
E1 expansion	постоянный worker запущен — runtime и проверка	Живые списки 28/28 проектов сверены; очередь изменений и фоновые refresh видны отдельно. 21/28 относится к историческому backfill
E1.5	worker/projection/lock реализованы и проверены; начальная очередь догоняется	Windmill schedule 5 минут, живые cursors, независимые retries, E1 и совместимая legacy read projection; старый collector заменён
E2–E3	E2 in_progress, E3 planned	486 работ с кандидатами модели; независимый эталон, semantic acceptance и сравнение graph-механизмов ещё не приняты
E4–E5	planned	Проверенные личные приоритеты и посильный контур внимания

Текущий runtime E1: постоянный worker вместо checkpoint-only backfill. Он автоматически догоняет изменения и продолжает сверки; полнота оценивается по живым source cursors и queue gaps. Успешный batch не означает пустую очередь или актуальность всех связанных объектов.