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

Personal OS — план действий E1–E5

Этапный план планировщика: данные, действия, исполнение, проверка

Обновлено 18.10.2026. Этот раздел задаёт порядок дальнейшей работы. Экспериментальные запуски остановлены; текущий Python-черновик f/attend/attention_loop_e5 сохраняется как материал для проверки. Цель: система выделяет следующие действия из содержания работ, готовит ИИ-результаты и составляет выполнимый week/day plan.

Основа: фиксированные workflows с промежуточными проверками, адресное дочитывание контекста, evals с кодовыми, модельными и человеческими проверками, планирование с зависимостями и ограничениями ресурсов. Ниже — применение этих практик к 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.

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. Порядок реализации и приёмки задаёт раздел «Этапный план планировщика» выше. Формат планов и ответов — без таблиц. Обязательное ограничение: оркестрация — 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

Asana / GitHub / Mattermost / Zoom / заметки
  → versioned source records
  → проверка извлечения + нормализация предметов, действий, участников и времени
  → work_facts + work_actions + work_relations + work_search_index
  → 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
                          → weekly_plan / career_brief

Единица планирования — конкретное действие, единица ИИ-исполнения — run с проверяемым результатом, единица наблюдения — временной интервал, единица карьерного анализа — вклад/возможность, связанная с актуальной целью. work_id связывает их с корневой работой; task_gid, action_id, run_id сохраняют конкретный объект.

Управление выполняют 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 поступает в ближайшее рабочее окно.

Все часы — Asia/Bishkek; work_start, work_end, рабочие дни и исключения читает work_schedule, дневная правка — day_state. Время начала/конца не выводится из первого/последнего открытия приложения.

Триггеры нового плана: 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.

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. Начальный критерий для holdout: 0 обнаруженных случаев «отмена = реализация» и «чужой вклад = вклад Алекса». Что показывается в результате: Конкретные regression cases; ноль на выборке не объявляется гарантией на весь корпус.
• Поиск контекста. Начальный критерий для holdout: recall@20 ≥90% на 40 запросах. Что показывается в результате: Найденные/пропущенные материалы и выигрыш относительно поиска без модельных полей.
• Отказ при нехватке данных. Начальный критерий для holdout: insufficient_source с указанием пробела. Что показывается в результате: Отдельная оценка; отказ не скрывает пропуск, если ответ был в доступном источнике.

Это предлагаемые пороги первого допуска. Польза и допуск оцениваются отдельно по полю и потребителю: полезный поисковый компонент не разрешает автоматически признавать ответственность или релиз. Основную разметку и разбор выполняет Codex; чтение Алекcом всего каталога не является этапом плана. Личные цели и выбор приоритетов отражаются отдельной явной пользовательской настройкой, а не объявляются фактом моделью.

Машинная сверка 18.10.2026 по 486 сохранённым result files: 466 объектов ответа, 20 результатов другого вида; 2482 state claims, из них 24 с enum completed/closed; 92 кандидата на смешение assignment и состояния. Эти числа описывают структуру, а не семантическую точность.

C. Куда идут существующие поля

• 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 при 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 — отдельное действие.
• 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:

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.

Критические входы для старта: явные day/week budget и рабочие границы; work_actions с конкретным next action/acceptance/оценкой; registry/run adapter с реальным lifecycle. Исторические резюме сами эти три входа не заменяют.

E. Процесс 2 — наблюдать рабочий день и доставлять сигналы

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 — карьерный путь и подсветка подходящих задач

актуальный профиль/цели + 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 отбора возможностей:

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 выше — следующие добавочные части, реализуемые SQL-миграциями и Python/SQL-шагами Windmill. Наличие старой executor-таблицы не доказывает выполнение нового run contract.

• Бюджет времени для 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.
• Привязка наблюдения к работе. Что уже есть / где проверено: 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; нормализовать пять реальных работ. Параллельно определить входные 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 плане.
• P4. Работа: Ограниченный пилот пяти рабочих дней после отдельного включения нужных процессов. Проверяемый результат: Замер поиска контекста, выполненных/перенесённых actions, review backlog, полезных/лишних сигналов и времени обслуживания; затем изменение конкретных правил.

Для старта детерминированного планирования и сигналов нужны P1–P2 на ограниченном scope; полный архив и оценка всех семантических классов могут проверяться параллельно. Смысловые рекомендации подключаются только для прошедшего оценку класса. Для карьерной подсветки добавляются актуальные goals/rubric и P3. Операции этой итерации — план и подготовка; rollout migrations, schedules, runner permissions и каналы доставки оформляются конкретными изменениями отдельно.

Инвентаризация существующего legacy-кода (ссылки ниже показывают текущие входы и правила; новые шаги реализуются на Python/SQL, JS-модули не становятся новым orchestration layer): action demands, day coordinator, capacity, timeline, run normalizer, snapshot, attention feed, career notes, Obsidian profile, flow map.

Текущий runtime 14.10.2026: Asana collector заменён постоянным worker в основной personal_os, с Windmill schedule каждые пять минут, live roster scans каждые 15 минут и events cursors. Все 28 живых списков проектов перечитаны, обнаружено 35 620 memberships. Очередь изменений, связанные объекты и фоновая сверка продолжаются и показаны отдельно. Legacy read projection и общий writer lock реализованы; старый collector архивирован. Контракт и проверка runtime.

Историческая сверка до этого rollout дала 21/28 по ID scan 06.10, 35 080 memberships, 11 недоступных direct tasks и 1 685 внешних dependency targets. Эти числа не являются текущим live freshness отчётом.

Основание: исследование шести уровней, архитектурные контракты, контракт данных R2. Этот документ конкретизирует порядок исполнения. Предложения о технологиях не означают, что они уже установлены или выбраны по результатам испытаний.

Предыдущая итерация: загрузка источников и обновление выводов

Дополнение 14.10.2026 — work items и контекст дизайнов реализованы и перенесены в основную БД. Каждый локальный ворктри без принятой связи должен получать отдельный устойчивый work item на дашборде для ручного либо агентского резолва: привязать существующую работу/задачу, учитывать локально, исключить с причиной либо подготовить и завести задачу Asana. Повторный сбор сохраняет item и принятое решение. В контекст работы добавляются tech-design задачи Asana, опубликованные документы и их драфты Obsidian, включая драфты без Asana ID; смысловые совпадения проходят резолв. Порядок, действия и критерии приёмки — в текущем плане GitHub и рабочих ситуаций. Проверены устойчивые items, сохранение решений, цепочки дизайнов, отдельный вызов локальной модели из Windmill и безопасное создание задачи из черновика. Пользователь разрешил основной перенос; все 17 таблиц перенесены с совпадением полных хешей. Windmill и дашборд переключены на personal_os.

Итерация E1: проверяемая загрузка Asana-проектов (история). Пилот трёх проектов завершён; по его результату расширен scope. Полный ID-обход завершён для 28 проектов: 26 текущих подписок и два проверенных пилота. Задачи из остальных проектов, напрямую связанные с пользователем, грузятся адресно. В конце должны быть видны полный доступный состав выбранных проектов, все принадлежности задач, доступная история и дерево подзадач. Для каждого пробела будет причина, для каждого запуска — воспроизводимый отчёт.

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

В исходном рабочем зеркале были пропуски задач, комментариев и связей. Тестовый E1 backfill теперь сверен с независимым ID-обходом всех трёх пилотов; отчёт. Это не означает полноту всех источников, рабочего зеркала или готовность персонального ранжирования.

Кто что делает

Участник	Ответственность	Когда нужен
Codex	Подготовка изменений и проверок, технические решения, сверки, отчёты, актуализация документации	Каждый пакет работ
Алекс	Смысл неоднозначных обязанностей, актуальные карьерные цели, выбор между существенными личными приоритетами	E2/E4, по коротким подготовленным карточкам
Алекс	Подтверждение применения миграции рабочей БД после предъявления конкретного изменения, проверки и восстановления	Перед E1.5, согласно пользовательскому правилу о миграциях
Алекс	Границы обработки частных данных и расхода на модели, если выбранный эксперимент требует внешнего inference	Перед соответствующим прогоном E3; после подготовки конкретного предложения

Выбор имён таблиц, технических ключей, тестовых объектов и алгоритма обхода — работа Codex. Алекс не составляет вручную реестр IDs и не размечает весь архив. Новые агентские запуски, расписания и запись в корпоративные системы — отдельные решения, они не следуют из создания этого плана.

E1. Пять пакетов ближайшей реализации

E1.1. Зафиксировать область и воспроизвести потери

Действие: подготовить независимый способ проверки сборщика до изменения его поведения.

Работа	Конкретный результат
Зафиксировать исходное состояние	Релевантный diff, версии схемы/SDK, список читателей project_gid, владельцы текущих запусков. Чужие незавершённые изменения остаются учтёнными в исходном состоянии.
Описать область пилота	Три проекта с названиями и проверенными source IDs; типы объектов; поля; правила рекурсивного обхода и пределы доступа. IDs читаются из API/сохранённой выборки.
Воспроизвести известные потери	Fixtures нескольких memberships, закрытой встречи, детей Retrospectives, пропавших задач и частичного API-ответа.
Проверить договор с Asana SDK	Реальная форма ответа и next_page; больше одной страницы; поддерживаемые параметры endpoint. Тестируется установленная версия библиотеки.
Собрать исходный отчёт	Объекты source/local, missing IDs, несовпадающие поля, непроверенные разделы; без заявления о полноте на основании лимитированной страницы.

Предлагаемые артефакты: test/asana-coverage.test.js, test/fixtures/asana-coverage/, scripts/asana-coverage-audit.js, planning/asana-coverage-pilot/README.md. Это новые планируемые файлы, сейчас их наличие не заявляется. Частные подробные ответы остаются в разрешённом локальном хранилище; в переносимые fixtures попадают минимизированные данные без секретов.

Приёмка: тесты воспроизводят потери текущего кода; auditor не вызывает тот же нормализатор для формирования эталона и результата. На странице с next_page отчёт никогда не ставит complete.

Твой результат: одна таблица «что именно теряем и чем проверим исправление». Никакой ручной настройки источников от тебя на этом шаге не требуется.

E1.2. Сохранить все связи и различать полный/частичный ответ

Действие: подготовить новую модель хранения Asana, совместимую с текущими читателями.

Изменение	Правило
Множественная принадлежность	Отдельные связи task–project–section; одна задача может иметь несколько проектов. Пользовательская секция My Tasks хранится отдельно от секции проекта.
Обновление связи	Полный ответ о memberships заменяет текущий набор в транзакции; отсутствующее в частичном ответе поле означает «не загружено». Пустой полный список означает реальное отсутствие memberships на момент наблюдения.
Версии наблюдений	Source ID, fetched/observed time, source modified time, content hash, набор реально прочитанных полей, ссылка на исходный ответ. Снимки с тем же содержимым повторно не размножаются.
Состояние сбора	Run/project/object-type, начало/окончание, страница/checkpoint, счётчики, ошибки, completeness и причина ограничения. Отсутствие доступа отличается от пустого раздела.
Совместимость	project_gid временно остаётся совместимым скалярным представлением; граф и новый auditor читают все memberships. Старые source priority и possibly_deleted не используются как доказательство текущей ответственности или удаления объекта.

Дорабатываются db.js, shape нормализованной задачи и версия схемы. Новая миграция использует существующий контракт source records/relations, насколько он уже реализован; если это ещё только проект R2, минимальные Asana-таблицы служат adapter storage с явным mapping в R2. Создание второго независимого реестра истины недопустимо.

Миграция подготовлена в migrations/005_asana_coverage.sql и применена только к отдельной тестовой БД. Применение к рабочей БД входит в E1.5.

Критические проверки: два проекта у одной задачи; перенос секции; снятие membership; полный пустой список; ответ без поля; повтор одного payload; более старый source snapshot после нового; rollback транзакции при ошибке. Устаревший снимок сохраняется как наблюдение, но не перезаписывает более свежее текущее состояние. При равном timestamp и конфликтующем содержимом требуется повторная сверка, а не произвольный победитель.

Приёмка: все memberships восстановлены из доступного raw для пилота; неполные ответы не стирают поля; историческое состояние не выдаётся за актуальное. Полнота raw отдельно проверяется по source API.

E1.3. Сделать полный обход и устойчивое продолжение

Действие: реализовать отдельный scoped backfill и сверку, не подменяя ими весь текущий рабочий цикл.

Часть	Что меняется
Задачи проекта	Обход /projects/{gid}/tasks по реальным offset-токенам; получение нужных полей; явная проверка включения старых закрытых задач. Исторический обход не ограничен изменениями последних 30 дней.
Подзадачи	Полный обход страниц и рекурсия по детям; visited set по source ID; защита от циклов; checkpoint очереди. Достижение лимита означает partial, а не успешную полноту.
Stories	Начальная загрузка доступной истории открытых и закрытых задач. Режим полного чтения игнорирует старый story cursor; при повторной сверке замечает редакции уже известных комментариев.
Зависимости и поля	Все страницы доступных dependencies/dependents; parent, followers, custom fields, due_at и project metadata. Ошибка возвращается как ошибка раздела, а не пустой список связей.
Продолжение и ошибки	Run-start watermark, повторяемые записи, checkpoint только после сохранения данных, ограниченные retries с Retry-After/backoff, возобновление после остановки. Просроченный offset приводит к безопасному переобходу раздела с дедупликацией.

Полный первичный обход не строится на task search. По официальной документации поиск не поддерживает обычную offset-пагинацию и имеет задержку индексации; общий проектный endpoint поддерживает offset и отдельный фильтр завершённых задач. Параметр modified_since, который текущий код передаёт проектному endpoint, не перечислен в его текущем контракте: считать его рабочим инкрементальным фильтром без проверки нельзя. Project tasks, Search, Pagination.

На первом scoped пилоте повторная сверка небольших проектов может читать полный список IDs/метаданных и обновлять изменившееся. Более дешёвый инкрементальный механизм выбирается по проверенному API-контракту и измеренному объёму. Search остаётся способом обнаружения кандидатов, но не сертификатом полноты.

Граница обхода: все задачи с membership в трёх проектах и их доступные потомки. Внешние зависимости загружаются как ссылки/минимальные карточки; весь соседний проект не обходится рекурсивно автоматически. Messages, status updates и содержимое вложений получают отдельные строки coverage. Их неподдерживаемый импорт обозначается как gap, не скрывается общим complete.

Исчезновение из полного списка означает «не наблюдается в этом контейнере». Оно может быть переносом, удалением или изменением доступа. Удаление объекта нельзя вывести из одного отсутствия в проекте; окончание известной связи и неизвестный статус самого объекта хранятся раздельно.

Артефакт: scripts/asana-project-backfill.js с выбранным scope, checkpoint/resume, бюджетом и явной целевой БД. Read-only ID-обход — scripts/asana-coverage-scan-ids.js; независимая сверка тестовой БД — scripts/asana-coverage-verify.js. Режим dry-run перечисляет только ID. Пробный полный backfill Meta Project запущен на отдельной тестовой БД; итоговая сверка ещё не готова.

Приёмка: более одной страницы задач/stories/детей, глубина дерева больше одного уровня, повторные страницы, одинаковые timestamps, 403/429/5xx, обрыв процесса, expired offset, редактирование старого комментария и отсутствие поля проходят проверку.

E1.4. Сверить полный доступный срез

Действие: прогнать новые пути на тестовом контуре с разрешённым чтением исходных систем и предъявить доказательства покрытия.

Порядок загрузки: сначала Meta Project до полной сверки, затем Feature Flags Registry, затем Scheduled Rotations. После первого проекта корректируется оценка числа API-запросов и времени. Лимит запросов/времени у каждого запуска явный; исчерпание сохраняет очередь и статус partial для продолжения.

Проверка	Условие приёмки
Состав	Разность source/local множеств IDs пуста для доступного согласованного среза. Каждый исключённый объект имеет объяснение.
Поля	Все memberships, completion, assignee, выбранные timestamps/поля совпадают на стабилизированной проверяемой версии.
Истории и дерево	Для доступных выбранных задач совпадают story IDs и parent–child связи; известные потерянные комментарии и дети присутствуют.
Повтор и восстановление	Повтор не создаёт дублей; остановка и продолжение дают тот же результат, что непрерывный обход; частичный сбой не двигает успешный watermark всего проекта.
Состояния	Отсутствие доступа, отсутствие в контейнере, неполная загрузка, устаревшая проверка и подтверждённая пустота различимы в отчёте.

Asana не обещает единый транзакционный snapshot на всё время длительного обхода. Поэтому manifest содержит интервал наблюдения. Изменившиеся во время чтения объекты повторно проверяются; подвижные расхождения остаются отмеченными, а не маскируются заявлением «100% на одну секунду».

Эталон проверяет обход и сохранение раздельно: сохранённые ответы API до нормализации сравниваются с БД; пагинация проверяется контрактными fixtures и повторным независимым перечислением IDs. Количество строк, выданное одним и тем же ошибочным загрузчиком, не является независимым подтверждением полноты.

Поставка: coverage-before.json, coverage-after.json, список расхождений с причинами, отчёт о повторе/возобновлении, короткая Markdown-таблица для Алекса. Во всех файлах — run ID, scope, время, версия кода и схемы. Статистика относится к трём проектам, не ко всей компании.

Приёмка E1.4: нет необъяснённых потерь в проверенной доступной области; оставшиеся gaps явно разделены по типам содержимого. Неполный источник не повышает общий статус до полной рабочей картины.

E1.5. Подключить исправленный путь к рабочему зеркалу

Действие: подготовить и выполнить контролируемое применение после проверки на тестовом контуре.

До подтверждения применения рабочей миграции предъявляются конкретный SQL/diff, backup/restore-проверка, влияние на читателей, ожидаемые блокировки и порядок возврата к предыдущему collector. Это требование пользовательской инструкции о миграциях; оно не блокирует подготовку кода, fixtures и тестового результата.

Сначала устраняется конкуренция старого writer с backfill: единый lease/lock на затрагиваемый scope или согласованное короткое окно применения. После миграции legacy writer не должен перезаписывать более свежие данные или новые связи. Откат приложения сохраняет новые данные; удаление таблиц не является стандартным способом отката.

После применения — один ручной scoped backfill и повторная сверка. Интеграция в существующий collector сохраняет явное разделение initial backfill / reconciliation / incremental. Изменение частоты запусков, новый launchd job и вызовы моделей не входят в этот пакет. Текущие потребители проходят целевую регрессию: My Tasks sections, work-demand, project-truth и day-coordinator в затронутых путях.

Готовность E1: доступный корпус трёх проектов восстановлен в рабочем зеркале, все memberships доступны новым читателям, проверяемые истории/дети загружены, ошибки видимы, повтор и восстановление проверены. Сохраняется список непокрытых Messages/вложений/исторических версий, если источники их ещё не предоставляют.

Твой результат: можно открыть проект и получить честный ответ «что мы о нём загрузили, что изменилось и что ещё не видим». Интерпретации ответственности и приоритетов на этом этапе ещё не объявляются готовыми.

E2. Получить общий корпус и эталон смысла

Зависимость: первые реальные эпизоды готовятся после сверки Meta Project; окончательная оценка компонентов начинается после E1.4 и проверки необходимых дополнительных источников.

Пакет	Работа	Готовый результат
E2.1 Другие источники	Выборочно сверить Zoom, Mattermost и GitHub с их локальными экспортами. Для начала — по три подходящих объекта каждого вида; расширять только по найденным проблемам. Проверить полный transcript/тред/review, авторов, время и ссылку.	Coverage matrix по всем четырём источникам; целевые задачи исправления пробелов.
E2.2 Эпизоды	Собрать 60–100 связных примеров разных проектов, периодов и состояний; включить тихие обязательства и случаи без упоминания пользователя.	Версионированный dataset с source spans, а не россыпью случайных сообщений.
E2.3 Явный граф	Source IDs, все memberships, parent/dependency/PR links, участники; alias mapping разных аккаунтов при подтверждении.	Исходный граф без модельных догадок и схема неизвестных типов.
E2.4 Эталон	Для каждого примера задать ожидаемые объекты, допустимые связи, время, состояние и отношение к пользователю.	Независимая разметка; tuning и holdout отделены по проектам/времени.
E2.5 Обзор	Показать несколько направлений с источниками и gaps; отдельно проверить модели формальной структуры, работ и компетенций.	Первый проверяемый экран/HTML-отчёт рабочего контекста, ещё без дневного планирования.

Загрузка missing Messages/статусных обновлений или расшифровка схем включается в E2, если без них выбранный эпизод неразрешим. Остальные пробелы отмечаются. Расширение корпуса не превращается в бесконечное предварительное требование собрать всю компанию.

Предварительную разметку готовит Codex по источникам. Алекс проверяет максимум пять неоднозначных карточек за один подход: «какая ответственность / какое решение / на чём основано». Непроверенная модельная разметка остаётся черновиком; её нельзя использовать как независимую истину для оценки той же модели.

Приёмка: есть разные направления и типы участия; ни один удобный кейс не определяет вывод; источник отвечает за свои факты; набор позволяет отдельно измерить классификацию, связывание и текущий статус. Неизвестность из-за отсутствующего источника считается корректным допустимым ответом, если она названа.

E3. Выбрать готовые механизмы по результатам

Зависимость: E2 даёт воспроизводимый корпус и согласованные правила обработки частных данных.

Пакет	Эксперимент	Решение
E3.1 Исходный вариант	Явные связи + PostgreSQL lexical retrieval + правила	Зафиксировать исходное качество, время, ручную нагрузку.
E3.2 Дешёвое извлечение	Добавить GLiNER2 на том же корпусе; неоднозначное оставить неизвестным	Определить, какие категории извлекаются локально достаточно хорошо.
E3.3 Граф	Cognee с source IDs/временными ролями против Graphiti на одинаковых эпизодах	Выбрать один механизм или сохранить исходный вариант, если прирост не оправдывает обслуживание.
E3.4 Трудные случаи	Проверить отмены, отрицания, неявный адресат, непрямую связь и состояние во времени	Определить узкую область более сильного анализатора и его допустимые данные/бюджет.
E3.5 Решение	Сравнить ошибки, стоимость, экспорт, replay и сложность поддержки	Один decision record: компонент, backend, модели, версии, основания выбора и нерешённые ограничения.

Перед скачиванием моделей/установкой сервисов составляется конкретная конфигурация: лицензии, размер, RAM, место на диске, разрешённые источники, ожидаемый объём прогона. Jev участвует только как отдельно допустимый закрытый сравнительный вариант. Отдельный graph backend — перестраиваемый индекс; PostgreSQL остаётся реестром принятых утверждений.

Метрики разделяются: recall кандидатов, precision/recall связей по классам, ложные merge, правильность отмен и времени, доля корректного unknown, latency, RAM, стоимость и минуты проверки. Сравнение не сводится к среднему качеству ответа или внешнему виду графа. Для обязательных негативных fixtures требуются отсутствие ложных merge и доказательство каждой принятой модельной связи; на holdout публикуются фактические числа и объём выборки.

Приёмка: выбранный компонент сокращает собственный код при измеримом приемлемом качестве и переносимом результате. В архитектуру добавляются только выигравшие механизмы. Сам эксперимент не включает постоянного фонового LLM-потока.

E4. Проверить твою роль и персональные приоритеты

Зависимость: рабочая структура и источник каждого утверждения проходят E3.

Пакет	Что делает Codex	Что проверяет Алекс
E4.1 Профиль	Собирает текущие области, назначения, ротации, подтверждённый опыт и исторические цели с датами	Устаревшие области, реальные границы ответственности, актуальность целей
E4.2 Отношение	Делит работы на прямые обязанности, пересечения, смежные компетенции, карьерные возможности и контекст	Несколько пограничных примеров с источниками
E4.3 Важность	Строит объяснимую матрицу влияния/срочности с готовностью и ценой участия	Пять подготовленных сравнений важных кандидатов за подход
E4.4 Наблюдение	В течение двух рабочих недель фиксирует рекомендации и фактические изменения без автозаписи в рабочие системы	Короткие поправки «не моё / позже / решено / важно по другой причине»
E4.5 Калибровка	Проверяет пропуски по независимо выбранным работам и исправляет конкретные правила	Принимает или отклоняет смысловые изменения профиля

Каждая рекомендация показывает путь связи с пользователем, источники, срок действия и неизвестность, которая способна поменять порядок. Наличие компетенции не становится обязанностью; карьерная возможность не превращается в принятое обязательство без выбора пользователя.

Приёмка: обязательные критические случаи не потеряны; качество top-k измерено; объяснения короткие и проверяемые; есть охват нескольких направлений; случайный шум не перестраивает приоритеты. Если качество слабое, исправляется конкретный предыдущий слой, а не добавляется ещё одна модель поверх ошибочного графа.

E5. Замкнуть планирование, ретроспекцию и эксплуатацию

Зависимость: понятны актуальные обязанности и качество ранжирования по E4.

Пакет	Поставка	Проверка
E5.1 Ёмкость дня	Календарные окна, конец дня, перерывы, текущий фокус и заявленное состояние	Объединение пересекающихся встреч, отсечение прошедшего времени, неизвестная занятость без выдуманной доступности
E5.2 План	Одно следующее действие, небольшой резерв, причина выбора и условия пересмотра	Сроки/зависимости соблюдены; несрочные обновления не прерывают фокус
E5.3 Исправления	Один feedback endpoint/формат с указанием затронутого факта, роли, приоритета или нагрузки	Исправление пересчитывает зависимые обзоры и сохраняет историю
E5.4 Ретроспектор	План–факт, причины переноса, реальные результаты, цена обслуживания самой системы	Игнорирование не трактуется как неважность; улучшения проходят replay и проверку версии
E5.5 Эксплуатация	Backup/restore, crash recovery, отсутствие дублей, мониторинг coverage, rollback модели/правил	Проверены восстановление и деградация источников; выбранные пользовательские сценарии читают один snapshot

Первый UI — минимальный локальный экран или готовый клиент с adapter, выбранный по трудоёмкости. Полировка iPad и сложная визуализация всей компании не блокируют приёмку понимания работ. Super Productivity рассматривается как готовый UI; OR-Tools подключается только при измеренной необходимости более сложного планирования.

Приёмка: система уменьшает ручной поиск контекста и удержание обязательств в голове; соблюдает границы дня; полезна на реальных рабочих неделях; исправления доходят до карьерного обзора и подготовки встреч. Целевой бюджет регулярного обслуживания — до 10 минут в неделю после настройки, его достижение измеряется. Расписание постоянной работы утверждается по итогам ручного/ограниченного пилота вместе с конкретными полномочиями и бюджетом.

Зависимости и независимая подготовка

flowchart LR
  A[E1.1 Область и воспроизведение] --> B[E1.2 Хранение]
  A --> C[E1.3 Обход и продолжение]
  B --> D[E1.4 Полная сверка]
  C --> D
  D --> E[E1.5 Рабочее зеркало]
  D --> F[E2 Корпус и эталон]
  F --> G[E3 Выбор механизмов]
  G --> H[E4 Роль и важность]
  H --> I[E5 План и ретро]

После фиксации контракта E1.1 независимы подготовка схемы хранения и adapter/tests. Во время backfill можно готовить формат эпизода и проверять покрытие Zoom/Mattermost/GitHub. Смысловые выводы о качестве системы требуют уже сверенного корпуса. Совместные изменения asana.js, sync.js, db.js должен интегрировать один владелец, чтобы избежать несовместимых вариантов записи.

Это карта допустимой параллельной работы, а не сообщение о запущенных агентах. Создание новых задач/агентов не выполнено этим планированием.

Как принимать результаты без длинных отчётов

Каждый пакет заканчивается карточкой одного формата:

Поле	Содержание
Что теперь работает	Один конкретный проверяемый результат
Доказательство	Файл/отчёт, scope, числа проверок и оставшиеся gaps
Что ещё не сделано	Только ограничение, существенное для текущего вывода
Решение Алекса	Конкретный выбор с подготовленными вариантами, только если от него зависит следующий шаг
Следующее действие	Один пакет с ID из этого плана

Статусы пакетов: planned, in_progress, verified, blocked. verified ставится после описанной приёмки; сохранение документа не закрывает реализацию. При блокировке фиксируется конкретная причина и продолжается независимая подготовка. Часы/даты окончания backfill оцениваются после E1.1 по фактическому числу объектов и ограничениям API; фиктивного календарного обещания сейчас нет.

Рабочая очередь на выходе из планирования

Пакет	Статус	Следующий проверяемый результат
E1.1	verified — отчёт и fixtures	6 тестов, независимый полный ID-обход SDK и source/local diff
E1.2	in_progress — схема и writer проверены на тестовой БД	Совместимый projection для старых читателей
E1.3	complete — три проекта загружены в отдельную тестовую БД	7658 уникальных задач с потомками и 125 970 stories
E1.4	verified для трёх пилотов — итоговые отчёты	4618/4618 исходных memberships; известных потерь и неполных разделов нет
E1 expansion	постоянный worker запущен — runtime и проверка	Живые списки 28/28 проектов сверены; очередь изменений и фоновые refresh видны отдельно. 21/28 относится к историческому backfill
E1.5	worker/projection/lock реализованы и проверены; начальная очередь догоняется	Windmill schedule 5 минут, живые cursors, независимые retries, E1 и совместимая legacy read projection; старый collector заменён
E2–E3	E2 in_progress, E3 planned	486 работ с кандидатами модели; независимый эталон, semantic acceptance и сравнение graph-механизмов ещё не приняты
E4–E5	planned	Проверенные личные приоритеты и посильный контур внимания

Текущий runtime E1: постоянный worker вместо checkpoint-only backfill. Он автоматически догоняет изменения и продолжает сверки; полнота оценивается по живым source cursors и queue gaps. Успешный batch не означает пустую очередь или актуальность всех связанных объектов.