diff --git a/personal/projects/personal-os/personal-os-action-plan-2026-10-05.md b/personal/projects/personal-os/personal-os-action-plan-2026-10-05.md
index 68c76107..f6d9e2e4 100755
--- a/personal/projects/personal-os/personal-os-action-plan-2026-10-05.md
+++ b/personal/projects/personal-os/personal-os-action-plan-2026-10-05.md
@@ -1,8 +1,32 @@
 # Personal OS — план действий E1–E5
 
+## Этапный план планировщика: данные, действия, исполнение, проверка
+
+Обновлено 18.10.2026. Этот раздел задаёт порядок дальнейшей работы. Экспериментальные запуски остановлены; текущий Python-черновик `f/attend/attention_loop_e5` сохраняется как материал для проверки. Цель: система выделяет следующие действия из содержания работ, готовит ИИ-результаты и составляет выполнимый week/day plan.
+
+Основа: [фиксированные workflows с промежуточными проверками](https://www.anthropic.com/engineering/building-effective-agents), [адресное дочитывание контекста](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents), [evals с кодовыми, модельными и человеческими проверками](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents), [планирование с зависимостями и ограничениями ресурсов](https://developers.google.com/optimization/scheduling/job_shop). Ниже — применение этих практик к Personal OS. Объёмы 60/40 и пять дней проверки — предлагаемые параметры проекта.
+
+Рабочий data flow: **изменения Asana/GitHub/локальной работы → проверенные факты → следующие действия и зависимости → week/day planner → ИИ-runs → проверенные артефакты → обновлённые личные действия**. Windmill управляет переходами; новые обработчики — Python/SQL.
+
+1. **Сначала зафиксировать проверку качества.** Для всех имеющихся отчётов выполнить машинный аудит полей, ссылок, дат и противоречий. Для 60 разнородных работ я составляю эталон по первоисточникам; 40 других работ остаются отложенной проверкой. Ожидания: кто действует, что уже сделано, следующий шаг, доказанная зависимость, требуемый результат. Все обнаруженные ошибки текущих опытов входят в регрессионные случаи. Тебе передаются только неоднозначности личных решений и ответственности. **Сделать:** набор случаев, эталон и воспроизводимый eval-run с версиями входов и промптов. **Проверить:** отдельно полноту отбора, достоверность фактов, правильность действий и выполнимость плана.
+
+2. **Разделить первоисточники, факты и предложения.** Коллекторы инкрементально берут изменения после последнего успешного cursor. Рабочий контур: открытые назначения на Алексе, адресные запросы/review, релевантные подзадачи его проектов; события завершения сохраняются для истории результатов. Факт получает `work_id, field, value, source_ref, source_revision, observed_at, acceptance`. Интерпретация модели получает статус candidate. Пространный отчёт хранится как диагностический артефакт; обработчики читают типизированные записи и адресные доказательства. **Сделать:** контракт фактов, проверку свежести объектов и точные связи task↔PR↔worktree. **Проверить:** свой PR с внешним reviewer, готовый локальный fix и чужая подзадача распознаются раздельно.
+
+3. **Собирать достаточный контекст конкретной работы.** По изменившемуся `work_id` Python выбирает карточку, нужных предков, адресные обсуждения и точно связанные PR/worktree. Модель получает краткий указатель источников и запрашивает нужные поля/фрагменты. Каждый прочитанный фрагмент сохраняется с revision/hash; неизменившаяся работа использует прежний результат. Если нужного доказательства нет, результат содержит конкретный `needs_evidence`, который возвращается сборщику. **Сделать:** retriever, проверку точности и полноты получаемых источников, лимиты и журнал чтений. **Проверить:** network crash и P1/P2 различаются; история Git не превращается в функциональную зависимость. Размер входа измеряется вместе с качеством на эталоне.
+
+4. **Получать действия из содержания и текущего этапа работы.** Отдельный обработчик выдаёт `action_id, work_id, actor, next_step, prerequisites, deadline, output, acceptance, human_estimate, ai_run_spec, evidence_refs`. Он учитывает существующую реализацию и явно разделяет факт, гипотезу и предлагаемое решение. Код проверяет исполнителя, даты, SHA, зависимости и наличие результатов. Смысловая проверка сверяет конкретные утверждения с источниками; её ошибки измеряются на эталоне независимо от генератора. **Сделать:** action builder и проверку утверждений. **Проверить:** неподтверждённые сроки, перепутанные task/PR и повторная реализация готового fix отклоняются; свой review request даёт внешнее ожидание.
+
+5. **Доказать реальное исполнение одного ИИ-workflow.** Сначала один ограниченный сценарий: подготовить техническую проверку либо черновик ответа. Windmill вызывает конкретный Python-handler с `handler_version, input_refs+hashes, workdir/base_sha, output_schema, acceptance, timeout`. Run сохраняет события и реальный артефакт; повторный запуск с тем же ключом не дублирует исполнение. Человеческая проверка становится доступной после получения и проверки артефакта. **Сделать:** адаптер имеющегося исполнителя, хранилище результатов и контракт run events. **Проверить:** `run → artifact → acceptance → human review`, включая ошибку, повтор и изменение исходного SHA. Для временных сбоев использовать [retries/error handling Windmill](https://www.windmill.dev/docs/flows/error_handling).
+
+6. **Составлять неделю и день алгоритмом ограничений.** Python-planner получает проверенный граф действий, явные приоритеты, сроки, оценки human/AI/review и бюджет из `work_schedule/day_state`. Он выбирает результаты периода и размещает их шаги: зависимости соблюдены, личные шаги не пересекаются, human+review помещаются в доступное время, ИИ учитывает свою очередь/ресурс. Дедлайн хранится отдельно от даты выполнения; ожидание коллег сохраняется отдельно от личной загрузки. Для размещения проверить Python OR-Tools CP-SAT; политику приоритетов сопоставить с эталонными решениями. **Сделать:** модель ограничений, week/day plan с версиями и объяснением выбора/переноса. **Проверить:** известные ошибки дат, исполнителей и придуманной длины дня воспроизводимо устранены.
+
+7. **Пройти отложенные случаи и пять рабочих дней в теневом режиме.** До включения регулярного плана прогнать 40 отложенных работ с повторными попытками и replay пяти дневных снимков. Я сравниваю выводы с источниками и эталоном. Отдельно измеряются критические ошибки, пропущенные обязательства, лишние действия, цена/время и чувствительность к изменению источников. Допуск к следующему этапу: ноль наблюдённых критических ошибок, каждое обязательное действие включено либо имеет доказанный blocker, каждый существенный факт прослеживается до источника. **Сделать:** отчёт приёмки и проверку runtime. В runtime отдельно проверить очереди: текущий единственный Python worker занят также длительными сборщиками; планировщик должен получать предсказуемое время исполнения.
+
+8. **Подключить наблюдение и карьерный отбор к принятой основе.** Для рабочего дня: `ActivityWatch + action/run events → привязка к текущему действию → фактический прогресс → signal policy → локальный inbox`; проверить завершение ИИ-run, превышение рабочего блока и блокировку следующего шага. Для карьеры: `завершённая работа + подтверждённый вклад + артефакты → evidence ledger → сопоставление с growth areas → кандидаты из текущего backlog → week planner`. **Сделать:** привязку активности, политику сигналов, профиль карьерных целей и доказательства вклада. **Проверить:** каждый сигнал и карьерная рекомендация имеют конкретное основание и действие.
+
 ## Рабочий план 18.10.2026: оценка модели и три прикладных процесса
 
-Статус: план реализации по запросу Алекса от 18.10.2026. Этот раздел задаёт ближайшие работы вместо общих формулировок E2–E5 ниже. **Формат планов и ответов — без таблиц. Обязательное ограничение: оркестрация — Windmill; новые шаги — Python и SQL. Новых JS/TypeScript-обработчиков, Node-сервисов и отдельного оркестратора не создавать.** Имена обработчиков ниже обозначают Python/SQL-шаги соответствующих Windmill flows. Новые таблицы и параметры — предлагаемые контракты. Изменение документа не включает расписаний или ИИ-исполнения.
+Статус: справочная детализация контрактов по запросу Алекса от 18.10.2026. Порядок реализации и приёмки задаёт раздел «Этапный план планировщика» выше. **Формат планов и ответов — без таблиц. Обязательное ограничение: оркестрация — Windmill; новые шаги — Python и SQL. Новых JS/TypeScript-обработчиков, Node-сервисов и отдельного оркестратора не создавать.** Имена обработчиков ниже обозначают Python/SQL-шаги соответствующих Windmill flows. Новые таблицы и параметры — предлагаемые контракты. Изменение документа не включает расписаний или ИИ-исполнения.
 
 ### План поставки и чего не хватает — кратко
 
diff --git a/personal/projects/personal-os/personal-os-system-review-index.md b/personal/projects/personal-os/personal-os-system-review-index.md
index ea612960..c8f16b01 100755
--- a/personal/projects/personal-os/personal-os-system-review-index.md
+++ b/personal/projects/personal-os/personal-os-system-review-index.md
@@ -20,6 +20,8 @@ updated: '2026-10-18'
 
 **Сейчас работать по [[personal-os-action-plan-2026-10-05]].** В нём — детальные пакеты E1.1–E1.5, результаты, проверки, зависимости и участие Алекса. Обоснование выбора компонентов — [[personal-os-six-layer-analysis-2026-10-05]].
 
+Актуальный порядок реализации: [[personal-os-action-plan-2026-10-05#Этапный план планировщика: данные, действия, исполнение, проверка|Этапный план планировщика]]. Входы, обработчики, выходы, недостающие компоненты и приёмка по восьми этапам.
+
 Архитектурные противоречия устранены в плане: одна PostgreSQL-модель, immutable evidence и типизированные claims, semantic acceptance, единая публикация, scoped feedback, один владелец каждого collector и последовательные gates реализации. Runtime по этому плану ещё не внедрён; новые запуски и расписания не включались.
 
 | Документ | Назначение |