[2026-10-18] eagle: personal/projects/personal-os/personal-os-action-plan-2026-10-05.md personal/projects/personal-os/personal-os-data-analysis-workflow-2026-10-09.md personal/projects/personal-os/personal-os-system-review-index.md

2026-10-18 18:45:40 +06:00
1 parent 6ab147c1ce
commit e7137a5555
@@ -1,5 +1,207 @@
 # Personal OS — план действий E1–E5

+## Рабочий план 18.10.2026: оценка модели и три прикладных процесса
+
+Статус: план реализации по запросу Алекса от 18.10.2026. Этот раздел задаёт ближайшие работы вместо общих формулировок E2–E5 ниже. Новые имена обработчиков, таблиц и параметры далее — предлагаемые контракты, а не существующий runtime. Изменение документа не включает расписаний или ИИ-исполнения.
+
+### A. Общий data flow и управляющий процесс
+
+```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
+      ├─ 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
+                          → weekly_plan / career_brief
+```
+
+Единица планирования — конкретное действие, единица ИИ-исполнения — 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 сохраняют своих владельцев; директор не дублирует их опрос.
+
+Состояния дня: `off`, `available`, `focus`, `meeting`, `break`. При старте рабочей недели строится week plan, при старте дня — day plan. Изменения источников объединяются по работе за 60 с и обновляют кандидатов; во время focus новый обычный план публикуется как предложение на границе блока. Явная правка пользователя применяется сразу. Новые ИИ-runs и обычные сигналы выдаются только внутри рабочего интервала. Уже работающий run может завершиться и сохранить результат; его review поступает в ближайшее рабочее окно.
+
+Все часы — `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, а не при записи плана.
+
+Контракт `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.
+
+`off` определяется рабочими границами; `meeting` — текущим busy interval; `break` — AFK ≥5 мин; `focus` — явным focus block с наблюдаемым соответствием work/action; иначе `available` либо наблюдение unknown. Intended focus и наблюдаемая активность хранятся раздельно. Пять переключений и overrun считаются только по интервалам с установленным work/action. Резерв 30% и время review вычитаются один раз: review включён в human workload, прежний фиксированный reviewer reserve поверх него не добавляется.
+
+### B. Как оценить локальную модель без ручного чтения 400 отчётов
+
+1. Зафиксировать 486 архивных результатов, исходные `records.json`, фактически переданные модели пакеты, hashes и версии метода. Последующие обновления оценивать отдельно: старый ответ сравнивается с его входом, а не с сегодняшней Asana.
+2. Проверить весь массив скриптом: схема/enum, даты, дубли, все evidence IDs, точные цитаты, assignment/author по IDs, противоречия между summary/claims/timeline. Отдельно посчитать долю случаев, где оригинал содержал факт, но подготовка пакета обрезала/исключила его.
+3. Построить группы риска по всем работам: отмены, реализации, релизы, роли, источники без цитат, крупные деревья, тонкие входы. Автоматический флаг — кандидат для разбора, не готовый смысловой вердикт.
+4. Codex проверяет по оригиналам 100 работ: 60 calibration и 40 holdout, фиксированный seed `20261018`, разделение по проектам. В обеих группах представлены открытые/завершённые, разные роли и размеры. Из calibration 30 выбираются случайно со стратификацией, 30 — по группам риска. Holdout не используется для правок метода; при нехватке независимых проектов фактический размер уменьшается и публикуется. Проекты/работы с ранее разобранными ошибками остаются calibration.
+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` с указанием пробела | Отдельная оценка; отказ не скрывает пропуск, если ответ был в доступном источнике |
+
+Это предлагаемые пороги первого допуска. Польза и допуск оцениваются отдельно по полю и потребителю: полезный поисковый компонент не разрешает автоматически признавать ответственность или релиз. Основную разметку и разбор выполняет Codex; чтение Алекcом всего каталога не является этапом плана. Личные цели и выбор приоритетов отражаются отдельной явной пользовательской настройкой, а не объявляются фактом моделью.
+
+Машинная сверка 18.10.2026 по 486 сохранённым result files: 466 объектов ответа, 20 результатов другого вида; 2482 state claims, из них 24 с enum `completed/closed`; 92 кандидата на смешение assignment и состояния. Эти числа описывают структуру, а не семантическую точность.
+
+### 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 остаётся сравнительным материалом |
+
+`work_claim_entities` даёт текущие версии claims; архивный `result_json` даёт subject/components для первого индекса. При изменении источников индекс и резюме перестраиваются с новым source revision. Старые subject/components не маскируются как актуальные. Свободные `statement` и `alex`-JSON не являются прямым входом планировщика: следующий явный шаг — выделение действий и actor relations из оригиналов и проверенных фактов.
+
+**Общий контракт действия** `work_actions`: `id`, `work_id`, `task_gid`, `subject_key`, `actor_id`, `actor_kind=human|ai`, `kind`, `handler_id`, `status=proposed|ready|running|blocked|waiting_review|done|cancelled`, `depends_on[]`, `deadline_at`, `human_minutes`, `ai_wall_minutes`, `review_minutes`, `estimate_basis`, `acceptance`, `source_refs[]`, `source_revision`, `verified_at`, `career_goal_ids[]`, `priority_pin`. Ответственный, действие и срок имеют собственные основания. Неизвестная оценка порождает отдельный ограниченный шаг уточнения на 15 минут, а не выдуманную длительность всей работы.
+
+### D. Процесс 1 — неделя/день, мои приоритеты и ИИ-workflow runs
+
+**Вход:** текущие открытые 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 |
+
+Предлагаемая очередность ready actions: ближайший жёсткий deadline/отрицательный slack → явный priority_pin → адресное обязательство/разблокирование коллег → source priority → career relevance внутри оставшегося класса. Карьерный вес не перемещает несрочную возможность выше обязательного срока. Если обязательства не помещаются, план сохраняет overflow с требуемым решением, а не увеличивает рабочий день.
+
+Пример запроса к **предлагаемому** action contract:
+
+```sql
+SELECT * FROM work_actions a
+WHERE a.actor_id = :alex AND a.status = 'ready'
+  AND a.verified_at IS NOT NULL AND a.source_revision = (SELECT s.revision FROM work_current s WHERE s.work_id=a.work_id)
+  AND (a.deadline_at < :week_end OR a.priority_pin OR a.id = ANY(:carry_over))
+  AND NOT EXISTS (SELECT 1 FROM action_dependencies d LEFT JOIN work_actions p ON p.id=d.requires_id
+                  WHERE d.action_id=a.id AND (p.id IS NULL OR p.status <> 'done'));
+```
+
+Eligibility проверяет текущую версию своей работы. Вторая выборка добавляет принятые career opportunities в пределах выделенного бюджета; этот SQL не отсекает их случайно по отсутствию deadline.
+
+**Контракт ИИ-run:** `run_id`, `action_id`, `handler_id/version`, `work_id`, `repo/workdir`, `base_sha`, `input_refs+hashes`, `acceptance`, `capabilities`, `output_schema`, `budget/timeout`, `needs_human`, `artifact_refs`, `last_event_at`. Lifecycle: `draft → queued → running → waiting_input|waiting_review|succeeded|failed|cancelled`. Повторные events идемпотентны по `(run_id,event_seq)`; waiting_input и waiting_review сохраняют конкретный вопрос/артефакт. Источник статуса — adapter runner, а не mtime сессии.
+
+Начальный registry handlers: `context_packet` (read-only пакет источников), `investigate_issue` (repro + вывод с evidence), `implement_patch` (локальный diff и проверки по точной спецификации), `review_diff` (замечания с местами и основаниями), `prepare_brief` (сводка из проверенных facts). Записи registry задают capabilities, acceptance и output contract. Для `implement_patch` нужен отдельный execution scope; в этом плане создаются спецификации, не запускается старый Executor.
+
+Пример 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. Исторические резюме сами эти три входа не заменяют.
+
+### E. Процесс 2 — наблюдать рабочий день и доставлять сигналы
+
+```text
+ActivityWatch window/AFK/editor/browser + accepted worktree bindings + run events
+ → day_observer раз в 60 с
+ → activity_intervals(work_id, action_id, start, end, confidence, evidence)
+ → сравнение с day_plan, календарём и рабочими границами
+ → signal_policy
+ → local_signal_inbox → UI delivery + seen/snooze/resolved
+```
+
+`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`; один сигнал на дату | На границе рабочего дня | Сохранить незавершённое и ближайшее продолжение для следующего дня |
+
+Параметры 90 с, 5/15 мин, 50 мин, 1.5×/+15 мин — proposed defaults для пятидневного пилота, не измеренные личные нормы. Focus/review/break boundaries фиксируются отдельным day state. Обычные action/run/context signals при focus ожидают его границы; day_end и наступление work boundaries обслуживаются таймером.
+
+Signal contract: `signal_id`, `kind`, `work/action/run_id`, `source_revision`, `evidence`, `proposed_action`, `created_at`, `expires_at`, `dedupe_key`, `status=pending|delivered|seen|snoozed|resolved`, `delivery_target=local_ui`. Dedupe `(kind, object_id, source_revision)`; напоминание одной причины не чаще 30 мин; до 3 обычных карточек в день, остальные объединяются в digest. Deadline conflict и day_end не теряются из-за лимита и объединяются по причине. После разрешения/смены версии старый сигнал снимается; повтор доставки не создаёт новый.
+
+**Критические входы для старта:** пригодная привязка наблюдаемого интервала к work/action; частый local observer; политика времени/дедупликации; видимый local inbox с подтверждением доставки. Канал первого пилота — локальный экран. Интеграции чатов/почты в этот запуск не входят.
+
+### F. Процесс 3 — карьерный путь и подсветка подходящих задач
+
+```text
+актуальный профиль/цели + rubric + feedback с источниками
+ → career_profile(version, valid_from, goals, competencies, evidence_requirements)
+ + work_facts / actor relations / contribution history
+ → contribution_ledger → evidence_by_goal → gap map
+ + текущие открытые работы всего доступного корпуса
+ → opportunity_retrieval(top 20) → source_check → top 3 opportunities
+ → weekly_plan discretionary actions + career_brief
+```
+
+1. `import_career_profile` запускается при изменении профиля, rubric или feedback. Сохраняет `goal_id`, `status=proposed|active|retired`, `valid_from/to`, `target`, `rubric_item_ids`, `evidence_requirements`, источник и дату подтверждения. Исторические EP2→EP3/Advisor тезисы апреля 2026 получают исторический интервал. Текущий профиль восстанавливается по свежим личным решениям и адресному feedback; выбор новых целей остаётся личным решением, не задачей угадывания модели.
+2. `build_contributions` после принятого факта выбирает actor relations `actor_id=Alex`, дату внутри review period, состояния `implemented|approved|released` **либо** документированное действие `proposed|decided|reviewed|investigated`. Последние хранятся с собственным типом, например исследование отменённой альтернативы, а не выдаются за доставленную реализацию. Выход: `contribution_id, action, result, role, date, evidence_refs, work_id, competency_ids`; измеренный impact имеет собственное свидетельство.
+3. `career_gap_map` перед week plan и после profile/contribution change группирует evidence по действующим rubric items; показывает покрытые требования, неподтверждённые требования и необходимые виды действий. Система анализирует траекторию по датированной последовательности вкладов, а не по числу закрытых задач.
+4. `find_opportunities` перед week plan берёт открытые работы **всего доступного корпуса**, включая чужие. Отбор: пересечение `component_ids/competency_ids` с active goals, присутствие подходящего вида участия (review, tech-design, исследование, координация), актуальные источники. Начальная FTS/relations выборка до 20; source checker проверяет конкретное возможное действие и отсутствие запрета/занятости роли; итог до 3. Модельная близость остаётся основанием кандидата, подтверждение возможности — источниками.
+5. `career_to_plan` передаёт **принятые** возможности как proposed human/AI actions с goal ID и объяснением. Предлагаемый бюджет: до 10% планируемого discretionary human time после обязательств; при нехватке времени — 0. Выбор предложения сохраняется решением; рекомендация не назначает Алексу чужую работу.
+6. `career_brief` по запросу и перед подтверждённой advisor-встречей собирает до 3 пунктов: подтверждённый вклад, пробел/изменение траектории, конкретная возможность или вопрос. Событие встречи берётся из календаря; существующая Tuesday-подготовка при переходе должна читать тот же packet, а не получать второго владельца расписания.
+
+Пример proposed отбора возможностей:
+
+```sql
+SELECT w.work_id FROM work_search_index w
+JOIN work_current t USING(work_id)
+WHERE t.completed = false AND t.source_fresh = true
+  AND (w.component_ids && :goal_components OR w.competency_ids && :goal_competencies)
+ORDER BY ts_rank_cd(w.search_text, websearch_to_tsquery('simple', :goal_query)) DESC, w.work_id
+LIMIT 20;
+```
+
+После SQL source checker выдаёт `opportunity(goal_id, work_id, specific_action, participation_kind, evidence, human_minutes, expires_at)`. Поисковый балл не является баллом «вероятность повышения».
+
+**Критические входы для старта:** датированные active goals/rubric и актуальный feedback; проверенная attribution вкладов; нормализованные компетенции и источник конкретной возможности участия. Закрытая задача на Алексе служит входом для исследования вклада, не готовым evidence для каждого требования rubric.
+
+### 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.
+
+| Разрыв из конкретного 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, полезных/лишних сигналов и времени обслуживания; затем изменение конкретных правил |
+
+Для старта детерминированного планирования и сигналов нужны 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).
+
+---
+
+
 Текущий runtime 14.10.2026: Asana collector заменён постоянным worker в основной
 `personal_os`, с Windmill schedule каждые пять минут, live roster scans каждые
 15 минут и events cursors. Все 28 живых списков проектов перечитаны, обнаружено
@@ -13,7 +215,7 @@ memberships, 11 недоступных direct tasks и 1 685 внешних depe

 Основание: [исследование шести уровней](/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). Этот документ конкретизирует порядок исполнения. Предложения о технологиях не означают, что они уже установлены или выбраны по результатам испытаний.

-## Что делаем сейчас
+## Предыдущая итерация: загрузка источников и обновление выводов

 **Дополнение 14.10.2026 — work items и контекст дизайнов реализованы и перенесены в основную БД.**
 Каждый локальный ворктри без принятой связи должен получать отдельный устойчивый
@@ -29,7 +231,7 @@ Obsidian, включая драфты без Asana ID; смысловые сов
 Пользователь разрешил основной перенос; все 17 таблиц перенесены с совпадением
 полных хешей. Windmill и дашборд переключены на `personal_os`.

-**Текущая итерация — E1: сделать проверяемой загрузку Asana-проектов.** Пилот трёх проектов завершён; по его результату [расширен scope](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md). Полный ID-обход завершён для 28 проектов: 26 текущих подписок и два проверенных пилота. Задачи из остальных проектов, напрямую связанные с пользователем, грузятся адресно. В конце должны быть видны полный доступный состав выбранных проектов, все принадлежности задач, доступная история и дерево подзадач. Для каждого пробела будет причина, для каждого запуска — воспроизводимый отчёт.
+**Итерация E1: проверяемая загрузка Asana-проектов (история).** Пилот трёх проектов завершён; по его результату [расширен scope](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md). Полный ID-обход завершён для 28 проектов: 26 текущих подписок и два проверенных пилота. Задачи из остальных проектов, напрямую связанные с пользователем, грузятся адресно. В конце должны быть видны полный доступный состав выбранных проектов, все принадлежности задач, доступная история и дерево подзадач. Для каждого пробела будет причина, для каждого запуска — воспроизводимый отчёт.

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

@@ -43,6 +43,8 @@ updated: '2026-10-18'

 ### 0.2. Дальнейшие этапы плана: что делать с результатом и для чего

+**План от 18.10.2026 с операционными контрактами:** [[personal-os-action-plan-2026-10-05#Рабочий план 18.10.2026: оценка модели и три прикладных процесса|оценка всего массива, назначение каждого поля, week/day planner и ИИ-runs, мониторинг/сигналы, карьерный процесс]]. Условия, SQL, обработчики, триггеры, выходы и критические пробелы заданы в разделах A–H этого плана. Это новая конкретизация, а не описание исходного замысла каждого поля задним числом.
+
 | Шаг | Какие записи взять | Что сделать | Для какого результата |
 |---|---|---|---|
 | Проверка смысла, E2 | Контрольные примеры разных работ, состояний и видов участия из каталога | Codex сопоставляет выводы с оригиналами: решения, отмены, результаты, время, роль Алекса и важные пропуски. Алекс разрешает до пяти подготовленных неоднозначностей за подход | Независимый эталон, перечень ошибок анализатора и проверка исправлений на других работах |
@@ -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]] | Текущая очередь E1–E5: ближайшие пакеты, поставки, проверки и зависимости. |
+| [[personal-os-action-plan-2026-10-05]] | Рабочий план 18.10, A–H: аудит 486 результатов и 60/40 проверка; контракт полей; единый director; неделя/день и 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]] | Единый выбранный стек и порядок поставки для утверждения. |