[2026-10-05] eagle: personal/projects/personal-os/personal-os-action-plan-2026-10-05.md personal/projects/personal-os/personal-os-architecture-decision-2026-10-04.md personal/projects/personal-os/personal-os-six-layer-analysis-2026-10-05.md personal/projects/personal-os/personal-os-system-review-index.md

2026-10-05 11:42:23 +06:00
1 parent 7f7998a974
commit 8b1e33b5bb
@@ -0,0 +1,237 @@
+# Personal OS — план действий E1–E5
+
+Дата: 05.10.2026. Статус: **план подготовлен; реализация E1 ещё не начата**.
+
+Основание: [исследование шести уровней](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md), [архитектурные контракты](/Users/admin/Developer/personal-os/planning/personal-os-architecture-decision-2026-10-04.md), [контракт данных R2](/Users/admin/Developer/personal-os/planning/personal-os-evidence-graph-design-2026-10-04.md). Этот документ конкретизирует порядок исполнения. Предложения о технологиях не означают, что они уже установлены или выбраны по результатам испытаний.
+
+## Что делаем сейчас
+
+**Текущая итерация — 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](https://developers.asana.com/reference/gettasksforproject), [Search](https://developers.asana.com/reference/searchtasksforworkspace), [Pagination](https://developers.asana.com/docs/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. Получить общий корпус и эталон смысла
+
+**Зависимость:** первые реальные эпизоды готовятся после сверки 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 минут в неделю после настройки, его достижение измеряется. Расписание постоянной работы утверждается по итогам ручного/ограниченного пилота вместе с конкретными полномочиями и бюджетом.
+
+## Зависимости и независимая подготовка
+
+```mermaid
+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.**
@@ -28,6 +28,8 @@

 ## Порядок реализации

+[Детальный план действий E1–E5](/Users/admin/Developer/personal-os/planning/personal-os-action-plan-2026-10-05.md) задаёт исполняемые пакеты. Сейчас в очереди E1.1: fixtures подтверждённых потерь и независимая сверка покрытия. Изменение runtime ещё не начато.
+
 | Этап | Конкретный результат и gate |
 |---|---|
 | E1. Покрытие | Полный согласованный срез трёх проектов; upstream/local manifest; все memberships, stories и дети; проверка повторного обхода. |
@@ -2,6 +2,8 @@

 5 октября 2026. Исследование, выборочная проверка Asana и проект реализации. **Реализация предложенных изменений не запускалась.**

+**Порядок исполнения:** [детальный план действий E1–E5](/Users/admin/Developer/personal-os/planning/personal-os-action-plan-2026-10-05.md), включая пять пакетов ближайшей итерации, владельцев, зависимости и приёмку. Первый пакет — E1.1: воспроизведение потерь и независимый coverage report.
+
 ## Решение и границы

 **Следующий этап — восстановить проверяемое покрытие нескольких проектов и на этом корпусе испытать построение рабочего графа.** Покупка корпоративного продукта больше не является первым пунктом плана. Условия: личный доступ к существующим системам компании, открытые компоненты, локальная эксплуатация, отсутствие обязательных изменений процессов компании.
@@ -5,12 +5,13 @@ updated: 2026-10-05
 ---
 # Personal OS: план и анализ шести уровней

-**Сначала читать [[personal-os-six-layer-analysis-2026-10-05]].** Он определяет текущие ограничения и очередность E1–E5; ниже — контракты и исторические исследования R2. Выборочный аудит уже подтвердил пропуски Asana; исправления кода ещё предстоят.
+**Сейчас работать по [[personal-os-action-plan-2026-10-05]].** Детальные пакеты E1.1–E1.5, результаты, проверки, зависимости и участие Алекса. Первый пакет — воспроизведение потерь и независимый отчёт покрытия; реализация ещё не начата. Обоснование выбора компонентов — [[personal-os-six-layer-analysis-2026-10-05]].

 Архитектурные противоречия устранены в плане: одна PostgreSQL-модель, immutable evidence и типизированные claims, semantic acceptance, единая публикация, scoped feedback, один владелец каждого collector и последовательные gates реализации. Runtime по этому плану ещё не внедрён; новые запуски и расписания не включались.

 | Документ | Назначение |
 |---|---|
+| [[personal-os-action-plan-2026-10-05]] | Текущая очередь E1–E5: ближайшие пакеты, поставки, проверки и зависимости. |
 | [[personal-os-system-review-2026-10-04]] | Полный план: роли, data flow, инструкции, расписания, SC1–SC8, AC01–AC16 и R0–R4. |
 | [[personal-os-evidence-graph-design-2026-10-04]] | Конкретные таблицы, ключи, typed relations, время, discovery, принятие claims, lineage и публикация. Заменяет ранний иллюстративный DDL. |
 | [[personal-os-architecture-decision-2026-10-04]] | Единый выбранный стек и порядок поставки для утверждения. |