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

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

Актуальное состояние на 10.10.2026. Рабочая БД для E1 — PostgreSQL personal_os на localhost:5432. Сборщик LaunchAgent использует E1_TARGET_DATABASE_URL=postgresql://admin@localhost:5432/personal_os; временная БД на 55439 больше не является целью записи. Миграция 005_asana_coverage.sql применена, восстановленные E1-данные импортированы. LaunchAgent com.personalos.asana-expansion-e1 продолжает backfill с сохранённого checkpoint каждые 15 минут. На момент проверки проходят строгую сверку 17 из 28 проектов; 11 проектов, 11 прямых задач и 995 внешних зависимостей остаются неполными. Подробный журнал: расширение E1 в репозитории.

Дата: 05.10.2026. Статус: историческое состояние на дату подготовки — план подготовлен; реализация E1 ещё не начата.

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

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

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

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

Первые страницы этих проектов уже проверены; найдены пропуски задач, комментариев и связей. Полное покрытие ни одного из трёх проектов пока не доказано. Готовность E1 не означает полноту всех источников или готовность персонального ранжирования.

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

Участник	Ответственность	Когда нужен
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. Создание второго независимого реестра истины недопустимо.

Названия и номер миграции фиксируются после E1.1; 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 с режимами audit/dry-run, выбранным scope, checkpoint/resume и отчётом; shared helpers в asana.js/sync.js. У CLI должен быть явный target БД и идентификатор run. Имена флагов фиксируются при реализации, готовой команды запуска пока нет.

Приёмка: более одной страницы задач/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. Получить общий корпус и эталон смысла

Дополнение 11.10: перед батчем E2 нужны триаж шума и зеркало GitHub PR; ситуации Алекса (шум, не начатое, устаревшее, локальные эксперименты, тихие merge, draft, неотработанные ревью) становятся контрольными случаями. См. personal-os-windmill-system-map-2026-10-10 §6.

Зависимость: первые реальные эпизоды готовятся после сверки 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	planned — первый	Fixtures и исходный coverage report с воспроизведёнными потерями
E1.2–E1.3	planned — после контракта E1.1	Хранение всех memberships и возобновляемый полный обход
E1.4–E1.5	planned — после проверок	Сверенный доступный корпус трёх проектов в рабочем зеркале
E2–E3	planned	Общий эталон и выбранный открытый механизм извлечения/графа
E4–E5	planned	Проверенные личные приоритеты и посильный контур внимания

Первый пакет реализации: E1.1 — воспроизводимые проверки потерь и независимый отчёт покрытия Asana.