[2026-10-18] eagle: personal/projects/personal-os/personal-os-action-plan-2026-10-05.md

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

@@ -4,6 +4,24 @@
 
 Статус: план реализации по запросу Алекса от 18.10.2026. Этот раздел задаёт ближайшие работы вместо общих формулировок E2–E5 ниже. **Формат планов и ответов — без таблиц. Обязательное ограничение: оркестрация — Windmill; новые шаги — Python и SQL. Новых JS/TypeScript-обработчиков, Node-сервисов и отдельного оркестратора не создавать.** Имена обработчиков ниже обозначают Python/SQL-шаги соответствующих Windmill flows. Новые таблицы и параметры — предлагаемые контракты. Изменение документа не включает расписаний или ИИ-исполнения.
 
+### План поставки и чего не хватает — кратко
+
+Все новые обработчики — Windmill flows с Python/SQL. Порядок ниже — задачи реализации; запуск процессов оформляется после их проверки.
+
+1. **Проверить пригодность извлечённых полей.** Все 486 результатов проходят машинную проверку. Codex составляет эталон по источникам для 60 работ, исправляет найденные паттерны и проверяет метод на 40 отложенных работах. Выход: verdict по полям и классам, перечень ошибок и примеры. **Доделать:** audit flow, независимый эталон, метрики и допуск каждого класса. Это идёт параллельно с шагами на точных Asana/GitHub-фактах.
+
+2. **Получить действия из работ.** Flow `f/analyse/work_actions` берёт открытые назначения на Алексе, адресные запросы и review, добавляет контекст текущих проверенных решений. Выход: `action_id, work_id, actor, next_action, depends_on, deadline, acceptance, human_minutes, review_minutes, evidence`. **Доделать:** нормализацию предмета и участника, извлечение next action, связи зависимостей и оценку объёма. В нынешних отчётах эти действия представлены свободным текстом, а не таким контрактом.
+
+3. **Разделить human/AI и планировать неделю/день.** Windmill отбирает actions `status=ready`, с выполненными зависимостями, действующим назначением и текущими источниками. AI action получает зарегистрированный handler, входы и acceptance; human action — конкретное решение/выполнение/review. Week/day flows распределяют действия в заданный human budget, оставляя 30% резерва и учитывая review ИИ. Выход: weekly/day plan, human queue и AI run specs. **Доделать:** action DAG, registry handlers, planner, доступный budget времени, run lifecycle/артефакты и обратное событие `waiting_review`. Бюджет первой версии задаётся явным входом Windmill `day_budget_minutes/week_budget_minutes` вместе с рабочими границами; подключение внешнего календаря не является условием первого запуска.
+
+4. **Наблюдать и сигналить.** `f/attend/attention_loop_e5` раз в 60 с получает ActivityWatch и подтверждённые run events, связывает их с action дневного плана. Выход: реальные интервалы работы и сигналы `run_needs_review`, `action_overrun`, `deadline_capacity_conflict`, `break_due`, `day_end`. **Доделать:** work/action binding, runner events, signal policy и локальный inbox с delivered/seen/snooze/resolved. Имеющиеся metadata сессии не являются событием «нужен ответ человека».
+
+5. **Анализировать карьеру и находить подходящие задачи.** `f/attend/roles_importance_e4` берёт активные цели/rubric и проверенные вклады Алекса; строит требования, для которых нужны свидетельства. Затем отбирает открытые работы всего доступного корпуса по компонентам/компетенциям, проверяет 20 кандидатов по источникам и выдаёт до 3 возможностей с конкретным действием. Принятые предложения входят в discretionary часть weekly plan. **Доделать:** актуальный профиль целей/требований, attribution вкладов, competency mapping, opportunity checker и связь с planner.
+
+6. **Соединить flows и проверить один сквозной цикл.** Выходы work context вызывают action flow; action/run changes — пересчёт плана; расписание 60 с — наблюдение; начало дня/недели — соответствующий planner. Выход: одна реальная работа проходит `источники → action DAG → AI run draft → результат → human review → следующий action`, а наблюдение выдаёт связанный с этим действием сигнал. **Доделать:** parent/child flow wiring, SQL идемпотентность и единые IDs/версии входов. Затем — пятидневный ограниченный пилот.
+
+**Критический минимум для трёх сценариев:** для планирования — action contract, бюджет времени и workflow run contract; для сигналов — наблюдение с work/action ID и доставка; для карьеры — активные цели/rubric и attribution. Общая недостающая часть — передача проверенных фактов в конкретные действия и связь результатов запусков обратно с планом. Детальные входы, SQL, параметры, ограничения и проверки — A–H ниже.
+
 ### A. Общий data flow и оркестрация в Windmill
 
 ```text
@@ -38,7 +56,7 @@ Asana / GitHub / Mattermost / Zoom / заметки
 
 Все часы — `Asia/Bishkek`; `work_start`, `work_end`, рабочие дни и исключения читает `work_schedule`, дневная правка — `day_state`. Время начала/конца не выводится из первого/последнего открытия приложения.
 
-Триггеры нового плана: `week_start` — work_start первого рабочего дня локальной недели; `day_start` — work_start текущего рабочего дня; окна review — явные блоки day_plan. `calendar_changed` перечитывается раз в 5 мин на горизонт до конца следующей рабочей недели. `career_brief` готовится за 60 мин до подтверждённой advisor-встречи либо по явному запросу. Эти параметры включаются при rollout, а не при записи плана.
+Триггеры нового плана: `week_start` — work_start первого рабочего дня локальной недели; `day_start` — work_start текущего рабочего дня; окна review — явные блоки day_plan. Изменение day/week budget или рабочих границ вызывает пересчёт. Calendar adapter — возможное дальнейшее дополнение к источникам доступного времени; его синхронизация оформляется отдельным шагом после выбора конкретного источника. `career_brief` готовится за 60 мин до подтверждённой advisor-встречи либо по явному запросу. Эти параметры включаются при rollout, а не при записи плана.
 
 Контракт `work_current(work_id, revision, completed, source_fresh)` — предлагаемая нормализованная проекция; revision связывает версии источников и принятых facts своей работы. `action_dependencies(action_id, requires_id)` — нормализованные `depends_on`; отсутствующий prerequisite блокирует ready. Для планируемых действий Asana/GitHub/requests/calendar требуется проверка их объектов не старше 15 мин; свежесть cursor проекта не заменяет свежесть карточки. Исторические facts привязаны к версии/дате события. Run adapter при running пишет heartbeat не реже 60 с; через 120 с без heartbeat статус становится unknown/recovery, а не done. Перед исполнением spec ещё раз сверяет input hashes и base SHA.
 
@@ -86,7 +104,7 @@ Asana / GitHub / Mattermost / Zoom / заметки
 
 - **`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.
+- **`compute_capacity` при budget/day change**. Точный отбор и операция: Для v1 взять явный доступный бюджет дня и рабочие границы. После подключения конкретного источника busy intervals объединять их и пересекать с рабочими границами, вычитая перерывы. Выделить 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 — отдельное действие.
@@ -114,7 +132,7 @@ Eligibility проверяет текущую версию своей работ
 
 Пример DAG для задачи с воспроизводимым багом: AI `context_packet` → AI `investigate_issue` → human «выбрать вариант», 15 мин → AI `implement_patch` → human «проверить diff и тесты», 20 мин. Время двух human steps — выделенные timeboxes примера; готовность багфикса определяется acceptance, а не истечением времени. Один local-model inference одновременно разделяет очередь с обновлением claims; draft runs нельзя запускать сверх доступного human review budget.
 
-**Критические входы для старта:** readable calendar busy intervals + рабочие границы; `work_actions` с конкретным next action/acceptance/оценкой; registry/run adapter с реальным lifecycle. Исторические резюме сами эти три входа не заменяют.
+**Критические входы для старта:** явные day/week budget и рабочие границы; `work_actions` с конкретным next action/acceptance/оценкой; registry/run adapter с реальным lifecycle. Исторические резюме сами эти три входа не заменяют.
 
 ### E. Процесс 2 — наблюдать рабочий день и доставлять сигналы
 
@@ -181,7 +199,7 @@ LIMIT 20;
 
 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 даёт воспроизводимые свободные окна.
+- **Бюджет времени для week/day**. Что уже есть / где проверено: `source-snapshot.js`: calendar unknown; `capacity-model.js` принимает meetings/workEndAt. Минимальная поставка и проверка: Windmill resource с day/week budget, рабочими границами и дневным override. Проверка: human work + review помещаются в заданный бюджет с резервом. Calendar adapter — отдельное последующее дополнение.
 - **Из текста работы в исполнимый шаг**. Что уже есть / где проверено: `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.
@@ -193,7 +211,7 @@ Read-only сверка 18.10: в основной БД есть `work_claim_*`,
 
 ### H. Порядок выполнения и критерии старта
 
-- **P0**. Работа: Зафиксировать входы; audit всего архива; начать 60/40; нормализовать пять реальных работ. Параллельно обследовать calendar и актуальные career sources. Проверяемый результат: Error-pattern table + action DAGs + конкретный способ чтения busy intervals и profile/rubric inputs.
+- **P0**. Работа: Зафиксировать входы; audit всего архива; начать 60/40; нормализовать пять реальных работ. Параллельно определить входные day/week budget и актуальные career sources. Проверяемый результат: Error-pattern table + action DAGs + контракт ввода day/week budget и 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 плане.