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 b928ca19..629d3d62 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
@@ -2,17 +2,17 @@
 
 ## Рабочий план 18.10.2026: оценка модели и три прикладных процесса
 
-Статус: план реализации по запросу Алекса от 18.10.2026. Этот раздел задаёт ближайшие работы вместо общих формулировок E2–E5 ниже. Новые имена обработчиков, таблиц и параметры далее — предлагаемые контракты, а не существующий runtime. Изменение документа не включает расписаний или ИИ-исполнения.
+Статус: план реализации по запросу Алекса от 18.10.2026. Этот раздел задаёт ближайшие работы вместо общих формулировок E2–E5 ниже. **Формат планов и ответов — без таблиц. Обязательное ограничение: оркестрация — Windmill; новые шаги — Python и SQL. Новых JS/TypeScript-обработчиков, Node-сервисов и отдельного оркестратора не создавать.** Имена обработчиков ниже обозначают Python/SQL-шаги соответствующих Windmill flows. Новые таблицы и параметры — предлагаемые контракты. Изменение документа не включает расписаний или ИИ-исполнения.
 
-### A. Общий data flow и управляющий процесс
+### A. Общий data flow и оркестрация в Windmill
 
 ```text
 Asana / GitHub / Mattermost / Zoom / заметки
   → versioned source records
   → проверка извлечения + нормализация предметов, действий, участников и времени
   → work_facts + work_actions + work_relations + work_search_index
-  → work_director получает source_changed / action_changed / run_changed /
-      calendar_changed / focus_changed / user_changed / timer
+  → Windmill flows получают changed work/action/run IDs и версии входов;
+      Windmill schedules запускают дневные, недельные и минутные проверки
       ├─ week_planner → weekly_plan → day_planner → human_queue + ai_run_specs
       ├─ day_observer → observed_intervals → signal_policy → local_signal_inbox
       └─ career_matcher → contribution_ledger + career_opportunities
@@ -21,7 +21,18 @@ Asana / GitHub / Mattermost / Zoom / заметки
 
 Единица планирования — конкретное действие, единица ИИ-исполнения — run с проверяемым результатом, единица наблюдения — временной интервал, единица карьерного анализа — вклад/возможность, связанная с актуальной целью. `work_id` связывает их с корневой работой; `task_gid`, `action_id`, `run_id` сохраняют конкретный объект.
 
-**Управляющий процесс `work_director`** — proposed wrapper для planned `f/attend/roles_importance_e4` и `f/attend/attention_loop_e5`. Один durable dispatcher читает события с cursor/lease; heartbeat 60 с обслуживает таймеры и восстановление. Повтор события определяется по `(kind, object_id, source_revision, policy_version)`; пересчёт затрагивает только зависимые работы. Collector Asana и claim updater сохраняют своих владельцев; директор не дублирует их опрос.
+**Управление выполняют Windmill flows и schedules.** Изменившийся work ID передаётся следующему flow выходом предыдущего шага; parent flow связывает нормализацию, действия и пересчёт. Windmill jobs сохраняют статусы, очередность, retries и результаты; SQL-ограничение `(kind, object_id, source_revision, policy_version)` обеспечивает идемпотентность предметной обработки. Одноминутное расписание относится к flow наблюдения дня, а не к отдельному dispatcher. Collector Asana и claim updater сохраняют своих владельцев.
+
+- **`f/analyse/corpus_and_gold_e2`**. Шаги реализации: SQL-выборка + Python-проверки/разметка/метрики. Запуск → результат: Ручной audit и проверка новой версии метода → evaluation artifacts.
+- **`f/analyse/work_context`**. Шаги реализации: SQL current records → Python resolve/index/actor steps → SQL upsert. Запуск → результат: После source/claim revision → facts, relations, index.
+- **`f/analyse/work_actions`**. Шаги реализации: SQL facts/requests → Python decomposition/validation → SQL action DAG. Запуск → результат: После work context → конкретные human/AI actions.
+- **`f/attend/week_plan`**. Шаги реализации: SQL ready actions → Python budget/order → SQL versioned plan. Запуск → результат: Первый рабочий старт недели и принятые существенные изменения → недельный план.
+- **`f/attend/attention_loop_e5`**. Шаги реализации: SQL day state/actions → Python day plan/observe/signal policy → SQL inbox. Запуск → результат: Старт дня; наблюдение раз в 60 с; run/action changes → дневной план и сигналы.
+- **`f/execute/workflow_run`**. Шаги реализации: SQL read accepted spec → Python handler → SQL events/artifacts. Запуск → результат: Только допущенный run spec → результат и waiting_review/action event.
+- **`f/attend/roles_importance_e4`**. Шаги реализации: SQL profile/contributions/open works → Python match/check → SQL opportunities. Запуск → результат: Profile/contribution change и перед week plan → вклад и карьерные кандидаты.
+
+
+Это целевые flows плана. Реализация новых шагов — Python/SQL внутри Windmill; в flow предусмотрены ограничение параллелизма, retries и таймаут. Общий локальный model lock сохраняется для inference. Доступ к Mac-local ActivityWatch/артефактам задаётся входным ресурсом конкретного Python-шага; отдельный JS runner этим планом не вводится.
 
 Состояния дня: `off`, `available`, `focus`, `meeting`, `break`. При старте рабочей недели строится week plan, при старте дня — day plan. Изменения источников объединяются по работе за 60 с и обновляют кандидатов; во время focus новый обычный план публикуется как предложение на границе блока. Явная правка пользователя применяется сразу. Новые ИИ-runs и обычные сигналы выдаются только внутри рабочего интервала. Уже работающий run может завершиться и сохранить результат; его review поступает в ближайшее рабочее окно.
 
@@ -42,12 +53,11 @@ Asana / GitHub / Mattermost / Zoom / заметки
 5. Сначала сохранить ожидаемые объекты, решения/отмены, роли, даты и существенные пропуски из оригиналов; затем сопоставить с ответом. Для задач поиска составить 40 контрольных запросов и ожидаемые связанные материалы. Факты могут иметь `supported`, `contradicted`, `insufficient_source`; недостающий факт в доступном входе учитывается как пропуск.
 6. Итоговые артефакты в локальном приватном evaluation-каталоге: `audit_manifest.json`, `checks.jsonl`, `gold.jsonl`, `split.json`, `error_patterns.json`, `holdout_metrics.json`. Каждый вердикт содержит work/run/claim ID, версию входа, цитату, объяснение, evaluator и policy version. Неоднозначность сохраняется как unresolved; независимую оценку той же моделью не подменять её самооценкой.
 
-| Прикладной допуск | Начальный критерий для holdout | Что показывается в результате |
-|---|---|---|
-| Извлечение утверждений | precision ≥95%, recall существенных фактов ≥90% | Числитель/знаменатель по классам, ошибки и интервалы неопределённости с группировкой по работам |
-| Критические решения/attribution | 0 обнаруженных случаев «отмена = реализация» и «чужой вклад = вклад Алекса» | Конкретные regression cases; ноль на выборке не объявляется гарантией на весь корпус |
-| Поиск контекста | recall@20 ≥90% на 40 запросах | Найденные/пропущенные материалы и выигрыш относительно поиска без модельных полей |
-| Отказ при нехватке данных | `insufficient_source` с указанием пробела | Отдельная оценка; отказ не скрывает пропуск, если ответ был в доступном источнике |
+- **Извлечение утверждений**. Начальный критерий для holdout: precision ≥95%, recall существенных фактов ≥90%. Что показывается в результате: Числитель/знаменатель по классам, ошибки и интервалы неопределённости с группировкой по работам.
+- **Критические решения/attribution**. Начальный критерий для holdout: 0 обнаруженных случаев «отмена = реализация» и «чужой вклад = вклад Алекса». Что показывается в результате: Конкретные regression cases; ноль на выборке не объявляется гарантией на весь корпус.
+- **Поиск контекста**. Начальный критерий для holdout: recall@20 ≥90% на 40 запросах. Что показывается в результате: Найденные/пропущенные материалы и выигрыш относительно поиска без модельных полей.
+- **Отказ при нехватке данных**. Начальный критерий для holdout: `insufficient_source` с указанием пробела. Что показывается в результате: Отдельная оценка; отказ не скрывает пропуск, если ответ был в доступном источнике.
+
 
 Это предлагаемые пороги первого допуска. Польза и допуск оцениваются отдельно по полю и потребителю: полезный поисковый компонент не разрешает автоматически признавать ответственность или релиз. Основную разметку и разбор выполняет Codex; чтение Алекcом всего каталога не является этапом плана. Личные цели и выбор приоритетов отражаются отдельной явной пользовательской настройкой, а не объявляются фактом моделью.
 
@@ -55,17 +65,16 @@ Asana / GitHub / Mattermost / Zoom / заметки
 
 ### C. Куда идут существующие поля
 
-| Поля schema v2 | Обработчик и конкретная операция | Выход/потребитель |
-|---|---|---|
-| `subject`, `components[]` | `index_work`: нормализовать aliases компонентов в IDs, построить FTS по предмету и проверенным statements | `work_search_index(work_id, component_ids, competency_ids, search_text tsvector, source_revision)` для поиска контекста и карьерных кандидатов |
-| `claims[].state/statement/evidence` | `resolve_facts`: проверить основание, выделить `subject_key`, `scope/platform`, время действия и supersession; сопоставить отмену с тем же предметом | `work_facts` → допустимые решения/ограничения для action builder, краткого обзора и contribution ledger |
-| `claims[].confirmed` | `audit_model`: сравнить самооценку с проверкой; посчитать ошибки уверенности | Диагностика метода; публикацию определяет verdict проверки |
-| `timeline[].date/event/evidence` | `resolve_facts`: восстановить порядок по event time и источникам | История решений/участия; вход проверки актуальности, а не сортировка по времени загрузки |
-| `people[].name/role`, `alex.mentioned/assignee/author` | `resolve_actor`: сопоставить с task/story/account IDs; отделить участие в конкретной подзадаче от корня | Подтверждённые actor/action relations |
-| `alex.responsible/relevance/intersection_kind` | `resolve_responsibility`: проверить адресата и основание; значения none/awareness/review/dependency/commitment/owner/unknown различать | Кандидаты ролей → проверенные обязанности/консультации/контекст для E4 |
-| `explicit_links[]` | `link_sources`: URL → object ID → чтение объекта → проверка отношения | `work_relations`; поиск сначала по точным связям |
-| `unknowns[]` | `fetch_context`: создать адресную задачу дочитывания, максимум 3 попытки на вопрос и версию входа | Новый evidence packet либо видимый unresolved gap |
-| `current_state` | `render_work`: заново собрать резюме из текущих разрешённых facts | Краткая карточка; archived summary остаётся сравнительным материалом |
+- **`subject`, `components[]`**. Обработчик и конкретная операция: `index_work`: нормализовать aliases компонентов в IDs, построить FTS по предмету и проверенным statements. Выход/потребитель: `work_search_index(work_id, component_ids, competency_ids, search_text tsvector, source_revision)` для поиска контекста и карьерных кандидатов.
+- **`claims[].state/statement/evidence`**. Обработчик и конкретная операция: `resolve_facts`: проверить основание, выделить `subject_key`, `scope/platform`, время действия и supersession; сопоставить отмену с тем же предметом. Выход/потребитель: `work_facts` → допустимые решения/ограничения для action builder, краткого обзора и contribution ledger.
+- **`claims[].confirmed`**. Обработчик и конкретная операция: `audit_model`: сравнить самооценку с проверкой; посчитать ошибки уверенности. Выход/потребитель: Диагностика метода; публикацию определяет verdict проверки.
+- **`timeline[].date/event/evidence`**. Обработчик и конкретная операция: `resolve_facts`: восстановить порядок по event time и источникам. Выход/потребитель: История решений/участия; вход проверки актуальности, а не сортировка по времени загрузки.
+- **`people[].name/role`, `alex.mentioned/assignee/author`**. Обработчик и конкретная операция: `resolve_actor`: сопоставить с task/story/account IDs; отделить участие в конкретной подзадаче от корня. Выход/потребитель: Подтверждённые actor/action relations.
+- **`alex.responsible/relevance/intersection_kind`**. Обработчик и конкретная операция: `resolve_responsibility`: проверить адресата и основание; значения none/awareness/review/dependency/commitment/owner/unknown различать. Выход/потребитель: Кандидаты ролей → проверенные обязанности/консультации/контекст для E4.
+- **`explicit_links[]`**. Обработчик и конкретная операция: `link_sources`: URL → object ID → чтение объекта → проверка отношения. Выход/потребитель: `work_relations`; поиск сначала по точным связям.
+- **`unknowns[]`**. Обработчик и конкретная операция: `fetch_context`: создать адресную задачу дочитывания, максимум 3 попытки на вопрос и версию входа. Выход/потребитель: Новый evidence packet либо видимый unresolved gap.
+- **`current_state`**. Обработчик и конкретная операция: `render_work`: заново собрать резюме из текущих разрешённых facts. Выход/потребитель: Краткая карточка; archived summary остаётся сравнительным материалом.
+
 
 `work_claim_entities` даёт текущие версии claims; архивный `result_json` даёт subject/components для первого индекса. При изменении источников индекс и резюме перестраиваются с новым source revision. Старые subject/components не маскируются как актуальные. Свободные `statement` и `alex`-JSON не являются прямым входом планировщика: следующий явный шаг — выделение действий и actor relations из оригиналов и проверенных фактов.
 
@@ -75,15 +84,14 @@ Asana / GitHub / Mattermost / Zoom / заметки
 
 **Вход:** текущие открытые Asana tasks, адресные неразрешённые requests/reviews, PR situations, подтверждённые действия/зависимости, доступные окна, принятые личные priorities и career opportunities.
 
-| Шаг/обработчик | Точный отбор и операция | Выход |
-|---|---|---|
-| `build_actions` после source/work revision | Взять `completed=false AND assignee=Alex`; добавить прямые адресные requests, requested review и run events `needs_human=true`. Сопоставить ответ именно с запросом/тредом и предметом: произвольный поздний комментарий не закрывает все запросы задачи | Дедуплицированные actions с основанием и конкретным ожидаемым результатом |
-| `decompose_work` при новом действии/изменении scope | По оригиналу, разрешённым facts и acceptance разбить работу на DAG действий. Разделить human decision/review и AI-шаги. Назначить AI только шагу с существующим handler, входами, output contract и разрешёнными capabilities | Action DAG: кто делает каждый шаг и какие предыдущие результаты нужны |
-| `compute_capacity` при calendar/day change | На каждый день объединить busy intervals, пересечь с рабочим временем и now..work_end; вычесть перерывы. Выделить 30% остатка как резерв. Планируемое human work + human review ≤70% остатка. AI wall time учитывается отдельно от человеческого времени | Доступные human windows и очереди compute/review |
-| `week_planner` первый рабочий старт недели + существенная deadline/capacity change | `status=ready`, все `depends_on` выполнены; действия со сроком до конца недели, carried-over из прошлого плана, priority_pin; карьерные кандидаты в пределах discretionary budget. `blocked` видны отдельно, в исполнение идут их unblock actions | Weekly plan: до 3 основных результатов, actions, human/AI budget, резерв и основания порядка |
-| `day_planner` work_start + изменение плана на границе focus/review window | Из weekly plan взять ready actions, помещающиеся в свободные окна и review budget; отдельно добавить срочные подтверждённые обязанности текущего дня | Day plan: 1 основное human action, до 2 резервных, окна review и список AI run drafts |
-| `prepare_run` при готовности AI action | Построить run spec и recheck source/base SHA. Уникальность `(action_id, spec_hash)`. Запускать после принятой execution policy в пределах compute/review budget | `workflow_run` с проверяемым артефактом; human review — отдельное действие |
-| `reconcile_plan` после run result / принятого review / изменения task | Проверить acceptance, обновить только соответствующий action и зависящий DAG, учесть фактическое время | Следующий ready шаг; завершение run само по себе не закрывает родительскую Asana task |
+- **`build_actions` после source/work revision**. Точный отбор и операция: Взять `completed=false AND assignee=Alex`; добавить прямые адресные requests, requested review и run events `needs_human=true`. Сопоставить ответ именно с запросом/тредом и предметом: произвольный поздний комментарий не закрывает все запросы задачи. Выход: Дедуплицированные actions с основанием и конкретным ожидаемым результатом.
+- **`decompose_work` при новом действии/изменении scope**. Точный отбор и операция: По оригиналу, разрешённым facts и acceptance разбить работу на DAG действий. Разделить human decision/review и AI-шаги. Назначить AI только шагу с существующим handler, входами, output contract и разрешёнными capabilities. Выход: Action DAG: кто делает каждый шаг и какие предыдущие результаты нужны.
+- **`compute_capacity` при calendar/day change**. Точный отбор и операция: На каждый день объединить busy intervals, пересечь с рабочим временем и now..work_end; вычесть перерывы. Выделить 30% остатка как резерв. Планируемое human work + human review ≤70% остатка. AI wall time учитывается отдельно от человеческого времени. Выход: Доступные human windows и очереди compute/review.
+- **`week_planner` первый рабочий старт недели + существенная deadline/capacity change**. Точный отбор и операция: `status=ready`, все `depends_on` выполнены; действия со сроком до конца недели, carried-over из прошлого плана, priority_pin; карьерные кандидаты в пределах discretionary budget. `blocked` видны отдельно, в исполнение идут их unblock actions. Выход: Weekly plan: до 3 основных результатов, actions, human/AI budget, резерв и основания порядка.
+- **`day_planner` work_start + изменение плана на границе focus/review window**. Точный отбор и операция: Из weekly plan взять ready actions, помещающиеся в свободные окна и review budget; отдельно добавить срочные подтверждённые обязанности текущего дня. Выход: Day plan: 1 основное human action, до 2 резервных, окна review и список AI run drafts.
+- **`prepare_run` при готовности AI action**. Точный отбор и операция: Построить run spec и recheck source/base SHA. Уникальность `(action_id, spec_hash)`. Запускать после принятой execution policy в пределах compute/review budget. Выход: `workflow_run` с проверяемым артефактом; human review — отдельное действие.
+- **`reconcile_plan` после run result / принятого review / изменения task**. Точный отбор и операция: Проверить acceptance, обновить только соответствующий action и зависящий DAG, учесть фактическое время. Выход: Следующий ready шаг; завершение run само по себе не закрывает родительскую Asana task.
+
 
 Предлагаемая очередность ready actions: ближайший жёсткий deadline/отрицательный slack → явный priority_pin → адресное обязательство/разблокирование коллег → source priority → career relevance внутри оставшегося класса. Карьерный вес не перемещает несрочную возможность выше обязательного срока. Если обязательства не помещаются, план сохраняет overflow с требуемым решением, а не увеличивает рабочий день.
 
@@ -121,14 +129,13 @@ ActivityWatch window/AFK/editor/browser + accepted worktree bindings + run event
 
 `day_observer` читает локальные ActivityWatch данные, а не делает полный внешний sync каждую минуту. Browser task/PR ID, accepted worktree→work link и явный focus override связывают интервал с работой; неизвестный интервал сохраняется отдельно и не приписывается ближайшей задаче. Window/AFK старше 90 с прекращают положительную классификацию текущей работы. Продолжительность считается по объединению интервалов без двойного счёта; AFK и meetings учитываются отдельно от focus.
 
-| Сигнал | Фильтр/порог первой версии | Когда доставлять | Для чего |
-|---|---|---|---|
-| `run_needs_review` | Подтверждённый run state `waiting_review`, `needs_human=true`, artifact существует | Ближайшее review window или конец focus блока | Открыть конкретный результат AI и продолжить DAG |
-| `deadline_capacity_conflict` | Действие имеет подтверждённый deadline, а доступные окна до него меньше remaining human + review minutes | Однократно при обнаружении; показать конкретный конфликт | Перепланировать объём/очередность |
-| `action_overrun` | Тот же action дольше `max(1.5 × planned_minutes, planned_minutes + 15)` | На границе блока, не повторять до изменения action | Предложить остановку, продолжение либо новый run расследования |
-| `context_switching` | ≥5 переходов между известными work IDs за 15 мин; исключить AFK и meetings | В ближайшее окно обзора | Показать фактические переключения и предложить закрепить фокус |
-| `break_due` | 50 мин непрерывной наблюдаемой активности без AFK ≥5 мин | В момент порога, мягкая локальная карточка | Напомнить о перерыве; это таймер активности, не вывод о здоровье/усталости |
-| `day_end` | `now >= work_end`; один сигнал на дату | На границе рабочего дня | Сохранить незавершённое и ближайшее продолжение для следующего дня |
+- **`run_needs_review`**. Фильтр/порог первой версии: Подтверждённый run state `waiting_review`, `needs_human=true`, artifact существует. Когда доставлять: Ближайшее review window или конец focus блока. Для чего: Открыть конкретный результат AI и продолжить DAG.
+- **`deadline_capacity_conflict`**. Фильтр/порог первой версии: Действие имеет подтверждённый deadline, а доступные окна до него меньше remaining human + review minutes. Когда доставлять: Однократно при обнаружении; показать конкретный конфликт. Для чего: Перепланировать объём/очередность.
+- **`action_overrun`**. Фильтр/порог первой версии: Тот же action дольше `max(1.5 × planned_minutes, planned_minutes + 15)`. Когда доставлять: На границе блока, не повторять до изменения action. Для чего: Предложить остановку, продолжение либо новый run расследования.
+- **`context_switching`**. Фильтр/порог первой версии: ≥5 переходов между известными work IDs за 15 мин; исключить AFK и meetings. Когда доставлять: В ближайшее окно обзора. Для чего: Показать фактические переключения и предложить закрепить фокус.
+- **`break_due`**. Фильтр/порог первой версии: 50 мин непрерывной наблюдаемой активности без AFK ≥5 мин. Когда доставлять: В момент порога, мягкая локальная карточка. Для чего: Напомнить о перерыве; это таймер активности, не вывод о здоровье/усталости.
+- **`day_end`**. Фильтр/порог первой версии: `now >= work_end`; один сигнал на дату. Когда доставлять: На границе рабочего дня. Для чего: Сохранить незавершённое и ближайшее продолжение для следующего дня.
+
 
 Параметры 90 с, 5/15 мин, 50 мин, 1.5×/+15 мин — proposed defaults для пятидневного пилота, не измеренные личные нормы. Focus/review/break boundaries фиксируются отдельным day state. Обычные action/run/context signals при focus ожидают его границы; day_end и наступление work boundaries обслуживаются таймером.
 
@@ -172,33 +179,30 @@ LIMIT 20;
 
 ### G. Что критически добавить: проверенный разрыв и ближайшая поставка
 
-Read-only сверка 18.10: в основной БД есть `work_claim_*`, `work_update_*`, `work_demands`, `work_items`, `work_situations`, `day_state`, `focus_feedback`, `activity_daily`, старые executor tables. Контракты `work_actions`, актуальных plans, workflow run events, calendar, signal delivery и career profile/ledger выше — следующие добавочные части. Наличие старой executor-таблицы не доказывает выполнение нового run contract.
+Read-only сверка 18.10: в основной БД есть `work_claim_*`, `work_update_*`, `work_demands`, `work_items`, `work_situations`, `day_state`, `focus_feedback`, `activity_daily`, старые executor tables. Контракты `work_actions`, актуальных plans, workflow run events, calendar, signal delivery и career profile/ledger выше — следующие добавочные части, реализуемые SQL-миграциями и Python/SQL-шагами Windmill. Наличие старой executor-таблицы не доказывает выполнение нового run contract.
+
+- **Источник времени для week/day**. Что уже есть / где проверено: `source-snapshot.js`: calendar unknown; `capacity-model.js` принимает meetings/workEndAt. Минимальная поставка и проверка: Calendar adapter с полным горизонтом следующей недели, cancelled/overlap/updated_at; work_schedule + override. Union/clip meetings даёт воспроизводимые свободные окна.
+- **Из текста работы в исполнимый шаг**. Что уже есть / где проверено: `work-demand.js`: assignment/request/dependency candidates; claims schema v2. Минимальная поставка и проверка: Action builder + нормализация предмета/времени/actor + acceptance + human/review estimates. На пяти реальных работах получается DAG с конкретным следующим шагом.
+- **Разделение моей и AI-работы**. Что уже есть / где проверено: `agent-run-adapters.js` содержит normalizer; sessions metadata сохраняют state/needs_human unknown. Минимальная поставка и проверка: Registry и один реальный runner adapter: spec → run events → artifact → review action. Replay событий не создаёт двойной run/review.
+- **Ограниченный план и пересчёт**. Что уже есть / где проверено: `day-coordinator.js`: shadow actions и capacity; полноценного week/action plan нет. Минимальная поставка и проверка: Week/day planner с budget, dependencies, overflow и версиями; изменение deadline/run/calendar пересчитывает затронутые actions.
+- **Привязка наблюдения к работе**. Что уже есть / где проверено: `work-timeline.js` связывает редактор в основном через PR; accepted work_items уже есть. Минимальная поставка и проверка: Подключить accepted worktree→work/action, local 60-сек observer; проверить 20 интервалов по реальным URL/path/AFK, unknown остаётся отдельным.
+- **Доставка сигнала и его жизнь**. Что уже есть / где проверено: `generate-attention.js` создаёт feed; `day-coordinator.js` пишет delivery none. Минимальная поставка и проверка: Signal inbox + local UI transport + dedupe/seen/snooze/resolved. Проверить run review, конфликт срока и day_end сквозным replay.
+- **Карьерный профиль и возможности**. Что уже есть / где проверено: `agent/career-notes.md`: апрельские goals имеют оговорку о давности; Obsidian profile содержит отдельные факты. Минимальная поставка и проверка: Profile importer + active rubric/goals + ledger + top-3 opportunities со specific action/evidence. Новая opportunity присоединяется к week plan только через принятое решение.
+- **Допуск смысловых полей**. Что уже есть / где проверено: Схема, локальный inference, архив, patch updater, ручной review API. Минимальная поставка и проверка: Audit всего архива + 60/40 оценка; решения по каждому классу, source/version lineage для projections.
 
-| Разрыв из конкретного data flow | Что уже есть / где проверено | Минимальная поставка и проверка |
-|---|---|---|
-| Источник времени для week/day | `source-snapshot.js`: calendar unknown; `capacity-model.js` принимает meetings/workEndAt | Calendar adapter с полным горизонтом следующей недели, cancelled/overlap/updated_at; work_schedule + override. Union/clip meetings даёт воспроизводимые свободные окна |
-| Из текста работы в исполнимый шаг | `work-demand.js`: assignment/request/dependency candidates; claims schema v2 | Action builder + нормализация предмета/времени/actor + acceptance + human/review estimates. На пяти реальных работах получается DAG с конкретным следующим шагом |
-| Разделение моей и AI-работы | `agent-run-adapters.js` содержит normalizer; sessions metadata сохраняют state/needs_human unknown | Registry и один реальный runner adapter: spec → run events → artifact → review action. Replay событий не создаёт двойной run/review |
-| Ограниченный план и пересчёт | `day-coordinator.js`: shadow actions и capacity; полноценного week/action plan нет | Week/day planner с budget, dependencies, overflow и версиями; изменение deadline/run/calendar пересчитывает затронутые actions |
-| Привязка наблюдения к работе | `work-timeline.js` связывает редактор в основном через PR; accepted work_items уже есть | Подключить accepted worktree→work/action, local 60-сек observer; проверить 20 интервалов по реальным URL/path/AFK, unknown остаётся отдельным |
-| Доставка сигнала и его жизнь | `generate-attention.js` создаёт feed; `day-coordinator.js` пишет delivery none | Signal inbox + local UI transport + dedupe/seen/snooze/resolved. Проверить run review, конфликт срока и day_end сквозным replay |
-| Карьерный профиль и возможности | `agent/career-notes.md`: апрельские goals имеют оговорку о давности; Obsidian profile содержит отдельные факты | Profile importer + active rubric/goals + ledger + top-3 opportunities со specific action/evidence. Новая opportunity присоединяется к week plan только через принятое решение |
-| Допуск смысловых полей | Схема, локальный inference, архив, patch updater, ручной review API | Audit всего архива + 60/40 оценка; решения по каждому классу, source/version lineage для projections |
 
 ### H. Порядок выполнения и критерии старта
 
-| Пакет | Работа | Проверяемый результат |
-|---|---|---|
-| P0 | Зафиксировать входы; audit всего архива; начать 60/40; нормализовать пять реальных работ. Параллельно обследовать calendar и актуальные career sources | Error-pattern table + action DAGs + конкретный способ чтения busy intervals и profile/rubric inputs |
-| P1 | Ввести общий event/action/source-version contract; calendar/work boundaries; read-only registry/run adapter | На одной работе: вход → action DAG → AI run draft → replay waiting_review → human action с артефактом |
-| P2 | Day observer и local signal inbox; затем week/day planner | Replay одного рабочего дня даёт непротиворечивый план, интервалы и три проверяемых сигнала; человеческое время и review не превышают доступные окна |
-| P3 | Profile/ledger/opportunities, подключение к weekly plan | Три карьерных кандидата с active goal, конкретным участием, evidence и time budget; принятый кандидат появляется в discretionary плане |
-| P4 | Ограниченный пилот пяти рабочих дней после отдельного включения нужных процессов | Замер поиска контекста, выполненных/перенесённых actions, review backlog, полезных/лишних сигналов и времени обслуживания; затем изменение конкретных правил |
+- **P0**. Работа: Зафиксировать входы; audit всего архива; начать 60/40; нормализовать пять реальных работ. Параллельно обследовать calendar и актуальные career sources. Проверяемый результат: Error-pattern table + action DAGs + конкретный способ чтения busy intervals и profile/rubric inputs.
+- **P1**. Работа: Ввести SQL event/action/source-version contract; Windmill parent/child flows; рабочие границы; Python registry/run adapter. Проверяемый результат: На одной работе: вход → action DAG → AI run draft → replay waiting_review → human action с артефактом.
+- **P2**. Работа: Day observer и local signal inbox; затем week/day planner. Проверяемый результат: Replay одного рабочего дня даёт непротиворечивый план, интервалы и три проверяемых сигнала; человеческое время и review не превышают доступные окна.
+- **P3**. Работа: Profile/ledger/opportunities, подключение к weekly plan. Проверяемый результат: Три карьерных кандидата с active goal, конкретным участием, evidence и time budget; принятый кандидат появляется в discretionary плане.
+- **P4**. Работа: Ограниченный пилот пяти рабочих дней после отдельного включения нужных процессов. Проверяемый результат: Замер поиска контекста, выполненных/перенесённых actions, review backlog, полезных/лишних сигналов и времени обслуживания; затем изменение конкретных правил.
+
 
 Для старта детерминированного планирования и сигналов нужны P1–P2 на ограниченном scope; полный архив и оценка всех семантических классов могут проверяться параллельно. Смысловые рекомендации подключаются только для прошедшего оценку класса. Для карьерной подсветки добавляются актуальные goals/rubric и P3. Операции этой итерации — план и подготовка; rollout migrations, schedules, runner permissions и каналы доставки оформляются конкретными изменениями отдельно.
 
-Основания реализации: [action demands](/Users/admin/Developer/personal-os/work-demand.js), [day coordinator](/Users/admin/Developer/personal-os/day-coordinator.js), [capacity](/Users/admin/Developer/personal-os/capacity-model.js), [timeline](/Users/admin/Developer/personal-os/work-timeline.js), [run normalizer](/Users/admin/Developer/personal-os/agent-run-adapters.js), [snapshot](/Users/admin/Developer/personal-os/source-snapshot.js), [attention feed](/Users/admin/Developer/personal-os/generate-attention.js), [career notes](/Users/admin/Developer/personal-os/agent/career-notes.md), [Obsidian profile](/Users/admin/obsidian/personal/career/profile.md), [flow map](/Users/admin/Developer/personal-os/windmill/system-map.yaml).
-
+Инвентаризация существующего legacy-кода (ссылки ниже показывают текущие входы и правила; новые шаги реализуются на Python/SQL, JS-модули не становятся новым orchestration layer): [action demands](/Users/admin/Developer/personal-os/work-demand.js), [day coordinator](/Users/admin/Developer/personal-os/day-coordinator.js), [capacity](/Users/admin/Developer/personal-os/capacity-model.js), [timeline](/Users/admin/Developer/personal-os/work-timeline.js), [run normalizer](/Users/admin/Developer/personal-os/agent-run-adapters.js), [snapshot](/Users/admin/Developer/personal-os/source-snapshot.js), [attention feed](/Users/admin/Developer/personal-os/generate-attention.js), [career notes](/Users/admin/Developer/personal-os/agent/career-notes.md), [Obsidian profile](/Users/admin/obsidian/personal/career/profile.md), [flow map](/Users/admin/Developer/personal-os/windmill/system-map.yaml).
 ---
 
 
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 8e48a9f5..ea612960 100755
--- a/personal/projects/personal-os/personal-os-system-review-index.md
+++ b/personal/projects/personal-os/personal-os-system-review-index.md
@@ -28,7 +28,7 @@ updated: '2026-10-18'
 | [[work-claims-results-2026-10-12]] | Каталог 486 работ с исходными ответами локальной модели и ссылками на источники; результат архивного прохода процесса анализа. |
 | [[personal-os-windmill-system-map-2026-10-10]] | Карта системы в Windmill: 21 поток по стадиям fetch/observe/analyse/publish/attend, обзорный холст, источник `windmill/system-map.yaml`. |
 | [[personal-os-db-browser]] | Локальный браузер БД: запуск на `127.0.0.1:4317`, источник `personal_os` на `localhost:5432`, проверка read-only SQL и доступных локальных решений. |
-| [[personal-os-action-plan-2026-10-05]] | Рабочий план 18.10, A–H: аудит 486 результатов и 60/40 проверка; контракт полей; единый director; неделя/день и AI-runs; наблюдение/доставка сигналов; карьерные цели, вклад и возможности; SQL/триггеры/выходы, критические разрывы и P0–P4. Ниже сохранена история E1–E5. |
+| [[personal-os-action-plan-2026-10-05]] | Рабочий план 18.10, A–H: аудит 486 результатов и 60/40 проверка; контракт полей; Windmill flows/schedules и Python/SQL; неделя/день и AI-runs; наблюдение/доставка сигналов; карьерные цели, вклад и возможности; SQL/триггеры/выходы, критические разрывы и P0–P4. Ниже сохранена история 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]] | Единый выбранный стек и порядок поставки для утверждения. |