561 lines
124 KiB
Markdown
561 lines
124 KiB
Markdown
# Personal OS — план действий E1–E5
|
||
|
||
Текущее исполнение A01–A17: [журнал исправлений](personal-os-fixes-2026-11-13.md), [независимый аудит](personal-os-repeat-audit-2026-11-13.md), [актуальная приёмка](personal-os-production-acceptance.md). На 14 ноября17:47UTC E4v186/E5v188 опубликованы, четыре расписания включены. Штатный production `0668b9d5-db8a-4843-8ac7-c69670bc78e2` прошёл за50,330с без proposal; UI/API подтвердили UUID и held при неизвестной ёмкости, все38 открытых обсуждений и29сверок/145мин сохранены. Самостоятельный опубликованный E4 `943171fa-d373-4370-a45d-a78a6fa2f531` прошёл за370мс с точным совпадением результата E5. GitHubv189 выполнил реальный сбор PR1564 с независимой сверкой HEAD/кода; новый анализ queued0/9. A17:8428/14,be3f0/8,f7277/78; полный current-method lineage доказан у5/598states. Исправление изоляции scan и допуска метода прошло342Node/248Python,18PG-сценариев и независимое ревью, но отдельная публикация claims flow и связанная активация ещё ожидают разрешения. Outlook/nativeUI/фактическая рабочая доставка и0/5реальных дней пилота остаются открытыми. Ниже сохранена история.
|
||
|
||
## Уточнение плана после независимого аудита 13 ноября
|
||
|
||
Ожидание результатов пилота не закрывает реализацию. [Аудит](personal-os-implementation-audit-2026-11-13.md) выявил 17 дефектов и ограничений. Следующая последовательность: целостность входящих и планируемых обязательств, подтверждаемое завершение и отмена → энергия, свободные окна Asana/Outlook, роли и вклад в цели → исполнение, очередь ревью и уведомления → актуальность, восстановление и исторические связи → Weekly Review и критерии приёмки по миссии → независимый повторный аудит и сквозной прогон без заранее подставленного proposal → пять реальных дней по исправленному критерию.
|
||
|
||
Для каждого пункта в аудите записаны источник дефекта и ожидаемая проверка. Реализация этих исправлений данным аудитом не выполнена. Наблюдения прежнего пилота сохраняются; их количество само по себе не доказывает готовность новой версии.
|
||
|
||
## 13.11.2026 — очередь действий из обсуждений
|
||
|
||
Ручной прогон выявил зависимость планировщика от решений и обязательств в обсуждениях. На встрече по CPM сопоставление вкладок было согласовано как опциональное для первого PR. Без транскрипта это решение ошибочно вернулось в план как открытое. Другой прогон связал обещанный апдейт с опубликованным комментарием Asana, а запросы на ревью в Mattermost — с одобренными и влитыми PR.
|
||
|
||
Штатный импорт Zoom открыл полную вкладку Transcript, проверил 20 заметок, сохранил или обновил 9 транскриптов и завершился с кодом 0. Корпоративный Mattermost требует повторного входа. По нему доступен архив до 2 ноября. Автоматическая обработка обсуждений, свежий Mattermost и охват встреч остаются отдельными проверками.
|
||
|
||
Прототип `f/analyse/discussion_actions` проверен локально на вручную собранных пакетах первоисточников. Модель извлекла обещание рекапа из Zoom, а при добавлении комментария Asana запись закрылась с прежним ID. Решение об опциональности и обещание обновить техдизайн извлечены отдельно. Архивный пример Mattermost с непроверенным адресатом не породил личного действия. Сведение дублей из двух каналов проверено синтетическим тестом с общим ID предмета. Автоматическая сборка пакетов, установление общего предмета между каналами, сохранение событий и сквозная работа Windmill ещё не проверены.
|
||
|
||
Порядок реализации:
|
||
|
||
1. Подать в Python-шаг Windmill версии транскриптов и тредов, связанные задачи, PR и последующие события. Передавать состояние покрытия источников. Неизвестную связь оставлять на проверке.
|
||
2. Извлечь из обсуждений решения и обязательства с указанием участника, ожидаемого результата, срока при наличии и буквальной цитаты. Сверить результаты с последующими источниками. Один запрос из нескольких каналов должен давать одну запись. Закрытие требует подтверждения именно обещанного результата.
|
||
3. Прогнать реальные истории в порядке событий и повторить вход. Критерии: обещанный рекап появляется один раз, публикация закрывает его, согласованный объём меняет следующее действие, а пробел покрытия виден в результате. Отдельно проверить извлечение, привязку и сверку по каждому источнику.
|
||
4. Добавить проверенные действия по текущим AoR и карьерным целям. Оценить всю очередь по матрице текущих целей и матрице важности DDG Asana. Только после проверки этой оценки подключить планы дня и недели и проверить обновление после выполнения действия.
|
||
|
||
### Обязательная приоритизация перед планированием
|
||
|
||
Статус на 13 ноября. E4 читает версионированные Daily Status и Growth Areas. Для триажа применяется Native Apps Severity Assessment Matrix DDG. Для остальных задач применяется собственная оценка Personal OS. На реальных карточках подтверждён порядок Major → Minor → Normal. E4 и E5 опубликованы в локальном Windmill. Реальный дневной план включает Next Top Priority и использует подтверждённый бюджет 90 минут по будням до 19:00 по Бишкеку. Локальная оценка также включила четыре действия из Zoom без привязки к Asana в отложенную очередь. Штатное обновление My Tasks сохранило одну карточку техдизайна со ссылками на Zoom и Mattermost. Уведомление о сверке проверено на отдельном тестовом журнале. [Текущие результаты приёмки](personal-os-production-acceptance.md)
|
||
|
||
Обновлённые правила допуска опубликованы в локальном Windmill E5. Штатный прогон опубликованной версии 180 прошёл все девять шагов. В основном плане подтверждён Next Top Priority. В плане и отложенной очереди учтены четыре действия из обсуждений без привязки к Asana. Встречи планируются в Asana и назначаются в Outlook. Локальный планировщик учитывает подтверждённые регулярные 1:1 из Asana, охват остальных встреч и сверка с Outlook остаются открытыми. На момент проверки 13 ноября зачтено 0 из 5 дней пилота. Первая сверка ожидает контрольного снимка после 19:00 по Бишкеку.
|
||
|
||
Матрица использует итоговое поле `SAM Severity` только для карточек триажа проекта `1210379416433601`. В остальных проектах одноимённые поля `Impact` и `Priority` сохраняются с исходными GID. Их смысл определяется схемой проекта. Недельные доли Project / AoR / Career / Strategy составляют 60/20/15/5.
|
||
|
||
- Сверить действующие цели, Top Priority, AoR и карьерные цели с их источниками. Получить фактические поля, шкалы и правила матрицы важности DDG Asana. Сохранять версию целей и матрицы, исходные значения и ссылки. Неизвестные поля и цели помечать как неизвестные.
|
||
- После сверки обязательств оценивать каждое действие по вкладу в действующие цели, важности DDG, сроку, ответственности, зависимостям и цене участия. Хранить оценку по каждому критерию и объяснение итогового порядка. Подтверждённые сроки и обязательства с конфликтом ёмкости должны быть видны явно.
|
||
- Планировщик дня и недели получает оценённую очередь. При изменении цели, матрицы или обязательства обновляется оценка затронутых действий до пересчёта плана. Критерий допуска — воспроизводимые сравнения на реальных задачах, включая конфликт между целью и Asana, важную задачу без срока, командный запрос и отсутствующую оценку DDG.
|
||
|
||
## Этапный план планировщика: данные, действия, исполнение, проверка
|
||
|
||
Обновлено 18.10.2026. Этот раздел задаёт порядок дальнейшей работы. Экспериментальные запуски остановлены; текущий Python-черновик `f/attend/attention_loop_e5` сохраняется как материал для проверки. Цель: система выделяет следующие действия из содержания работ, готовит ИИ-результаты и составляет выполнимый week/day plan.
|
||
|
||
Основа: [фиксированные workflows с промежуточными проверками](https://www.anthropic.com/engineering/building-effective-agents), [адресное дочитывание контекста](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents), [evals с кодовыми, модельными и человеческими проверками](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents), [планирование с зависимостями и ограничениями ресурсов](https://developers.google.com/optimization/scheduling/job_shop). Ниже — применение этих практик к Personal OS. Объёмы 60/40 и пять дней проверки — предлагаемые параметры проекта.
|
||
|
||
Рабочий data flow: **изменения Asana/GitHub/Zoom/Mattermost/локальной работы → проверенные факты → следующие действия и зависимости → оценка по текущим целям и матрице важности DDG Asana → week/day planner → ИИ-runs → проверенные артефакты → обновлённые личные действия**. Windmill управляет переходами; новые обработчики — Python/SQL.
|
||
|
||
1. **Сначала зафиксировать проверку качества.** Для всех имеющихся отчётов выполнить машинный аудит полей, ссылок, дат и противоречий. Для 60 разнородных работ я составляю эталон по первоисточникам; 40 других работ остаются отложенной проверкой. Ожидания: кто действует, что уже сделано, следующий шаг, доказанная зависимость, требуемый результат. Все обнаруженные ошибки текущих опытов входят в регрессионные случаи. Тебе передаются только неоднозначности личных решений и ответственности. **Сделать:** набор случаев, эталон и воспроизводимый eval-run с версиями входов и промптов. **Проверить:** отдельно полноту отбора, достоверность фактов, правильность действий и выполнимость плана.
|
||
|
||
2. **Разделить первоисточники, факты и предложения.** Коллекторы инкрементально берут изменения после последнего успешного cursor. Рабочий контур: открытые назначения на Алексе, адресные запросы/review, релевантные подзадачи его проектов; события завершения сохраняются для истории результатов. Факт получает `work_id, field, value, source_ref, source_revision, observed_at, acceptance`. Интерпретация модели получает статус candidate. Пространный отчёт хранится как диагностический артефакт; обработчики читают типизированные записи и адресные доказательства. **Сделать:** контракт фактов, проверку свежести объектов и точные связи task↔PR↔worktree. **Проверить:** свой PR с внешним reviewer, готовый локальный fix и чужая подзадача распознаются раздельно.
|
||
|
||
3. **Собирать достаточный контекст конкретной работы.** По изменившемуся `work_id` Python выбирает карточку, нужных предков, адресные обсуждения и точно связанные PR/worktree. Модель получает краткий указатель источников и запрашивает нужные поля/фрагменты. Каждый прочитанный фрагмент сохраняется с revision/hash; неизменившаяся работа использует прежний результат. Если нужного доказательства нет, результат содержит конкретный `needs_evidence`, который возвращается сборщику. **Сделать:** retriever, проверку точности и полноты получаемых источников, лимиты и журнал чтений. **Проверить:** network crash и P1/P2 различаются; история Git не превращается в функциональную зависимость. Размер входа измеряется вместе с качеством на эталоне.
|
||
|
||
4. **Получать действия из содержания и текущего этапа работы.** Отдельный обработчик выдаёт `action_id, work_id, actor, next_step, prerequisites, deadline, output, acceptance, human_estimate, ai_run_spec, evidence_refs`. Он учитывает существующую реализацию и явно разделяет факт, гипотезу и предлагаемое решение. Код проверяет исполнителя, даты, SHA, зависимости и наличие результатов. Смысловая проверка сверяет конкретные утверждения с источниками; её ошибки измеряются на эталоне независимо от генератора. **Сделать:** action builder и проверку утверждений. **Проверить:** неподтверждённые сроки, перепутанные task/PR и повторная реализация готового fix отклоняются; свой review request даёт внешнее ожидание.
|
||
|
||
5. **Доказать реальное исполнение одного ИИ-workflow.** Сначала один ограниченный сценарий: подготовить техническую проверку либо черновик ответа. Windmill вызывает конкретный Python-handler с `handler_version, input_refs+hashes, workdir/base_sha, output_schema, acceptance, timeout`. Run сохраняет события и реальный артефакт; повторный запуск с тем же ключом не дублирует исполнение. Человеческая проверка становится доступной после получения и проверки артефакта. **Сделать:** адаптер имеющегося исполнителя, хранилище результатов и контракт run events. **Проверить:** `run → artifact → acceptance → human review`, включая ошибку, повтор и изменение исходного SHA. Для временных сбоев использовать [retries/error handling Windmill](https://www.windmill.dev/docs/flows/error_handling).
|
||
|
||
6. **Составлять неделю и день алгоритмом ограничений.** Python-planner получает проверенный граф действий, явные приоритеты, сроки, оценки human/AI/review и бюджет из `work_schedule/day_state`. Он выбирает результаты периода и размещает их шаги: зависимости соблюдены, личные шаги не пересекаются, human+review помещаются в доступное время, ИИ учитывает свою очередь/ресурс. Дедлайн хранится отдельно от даты выполнения; ожидание коллег сохраняется отдельно от личной загрузки. Для размещения проверить Python OR-Tools CP-SAT; политику приоритетов сопоставить с эталонными решениями. **Сделать:** модель ограничений, week/day plan с версиями и объяснением выбора/переноса. **Проверить:** известные ошибки дат, исполнителей и придуманной длины дня воспроизводимо устранены.
|
||
|
||
7. **Пройти отложенные случаи и пять рабочих дней в теневом режиме.** До включения регулярного плана прогнать 40 отложенных работ с повторными попытками и replay пяти дневных снимков. Я сравниваю выводы с источниками и эталоном. Отдельно измеряются критические ошибки, пропущенные обязательства, лишние действия, цена/время и чувствительность к изменению источников. Допуск к следующему этапу: ноль наблюдённых критических ошибок, каждое обязательное действие включено либо имеет доказанный blocker, каждый существенный факт прослеживается до источника. **Сделать:** отчёт приёмки и проверку runtime. В runtime отдельно проверить очереди: текущий единственный Python worker занят также длительными сборщиками; планировщик должен получать предсказуемое время исполнения.
|
||
|
||
8. **Подключить наблюдение и карьерный отбор к принятой основе.** Для рабочего дня: `ActivityWatch + action/run events → привязка к текущему действию → фактический прогресс → signal policy → локальный inbox`; проверить завершение ИИ-run, превышение рабочего блока и блокировку следующего шага. Для карьеры: `завершённая работа + подтверждённый вклад + артефакты → evidence ledger → сопоставление с growth areas → кандидаты из текущего backlog → week planner`. **Сделать:** привязку активности, политику сигналов, профиль карьерных целей и доказательства вклада. **Проверить:** каждый сигнал и карьерная рекомендация имеют конкретное основание и действие.
|
||
|
||
## Рабочий план 18.10.2026: оценка модели и три прикладных процесса
|
||
|
||
Статус: справочная детализация контрактов по запросу Алекса от 18.10.2026. Порядок реализации и приёмки задаёт раздел «Этапный план планировщика» выше. **Формат планов и ответов — без таблиц. Обязательное ограничение: оркестрация — Windmill; новые шаги — Python и SQL. Новых JS/TypeScript-обработчиков, Node-сервисов и отдельного оркестратора не создавать.** Имена обработчиков ниже обозначают Python/SQL-шаги соответствующих Windmill flows. Новые таблицы и параметры — предлагаемые контракты. Изменение документа не включает расписаний или ИИ-исполнения.
|
||
|
||
### План поставки и чего не хватает — кратко
|
||
|
||
Все новые обработчики — Windmill flows с Python/SQL. Порядок ниже — задачи реализации; запуск процессов оформляется после их проверки.
|
||
|
||
1. **Проверить пригодность извлечённых полей.** Все 486 результатов проходят машинную проверку. Codex составляет эталон по источникам для 60 работ, исправляет найденные паттерны и проверяет метод на 40 отложенных работах. Выход: verdict по полям и классам, перечень ошибок и примеры. **Доделать:** audit flow, независимый эталон, метрики и допуск каждого класса. Это идёт параллельно с шагами на точных Asana/GitHub-фактах.
|
||
|
||
2. **Получить действия из работ.** Flow `f/analyse/work_actions` берёт открытые назначения на Алексе, адресные запросы и review, добавляет контекст текущих проверенных решений. Выход: `action_id, work_id, actor, next_action, depends_on, deadline, acceptance, human_minutes, review_minutes, evidence`. **Доделать:** нормализацию предмета и участника, извлечение next action, связи зависимостей и оценку объёма. В нынешних отчётах эти действия представлены свободным текстом, а не таким контрактом.
|
||
|
||
3. **Разделить human/AI и планировать неделю/день.** Windmill отбирает actions `status=ready`, с выполненными зависимостями, действующим назначением и текущими источниками. AI action получает зарегистрированный handler, входы и acceptance; human action — конкретное решение/выполнение/review. Week/day flows распределяют действия в заданный human budget, оставляя 30% резерва и учитывая review ИИ. Выход: weekly/day plan, human queue и AI run specs. **Доделать:** action DAG, registry handlers, planner, доступный budget времени, run lifecycle/артефакты и обратное событие `waiting_review`. Бюджет первой версии задаётся явным входом Windmill `day_budget_minutes/week_budget_minutes` вместе с рабочими границами; подключение внешнего календаря не является условием первого запуска.
|
||
|
||
4. **Наблюдать и сигналить.** `f/attend/attention_loop_e5` раз в 60 с получает ActivityWatch и подтверждённые run events, связывает их с action дневного плана. Выход: реальные интервалы работы и сигналы `run_needs_review`, `action_overrun`, `deadline_capacity_conflict`, `break_due`, `day_end`. **Доделать:** work/action binding, runner events, signal policy и локальный inbox с delivered/seen/snooze/resolved. Имеющиеся metadata сессии не являются событием «нужен ответ человека».
|
||
|
||
5. **Анализировать карьеру и находить подходящие задачи.** `f/attend/roles_importance_e4` берёт активные цели/rubric и проверенные вклады Алекса; строит требования, для которых нужны свидетельства. Затем отбирает открытые работы всего доступного корпуса по компонентам/компетенциям, проверяет 20 кандидатов по источникам и выдаёт до 3 возможностей с конкретным действием. Принятые предложения входят в discretionary часть weekly plan. **Доделать:** актуальный профиль целей/требований, attribution вкладов, competency mapping, opportunity checker и связь с planner.
|
||
|
||
6. **Соединить flows и проверить один сквозной цикл.** Выходы work context вызывают action flow; action/run changes — пересчёт плана; расписание 60 с — наблюдение; начало дня/недели — соответствующий planner. Выход: одна реальная работа проходит `источники → action DAG → AI run draft → результат → human review → следующий action`, а наблюдение выдаёт связанный с этим действием сигнал. **Доделать:** parent/child flow wiring, SQL идемпотентность и единые IDs/версии входов. Затем — пятидневный ограниченный пилот.
|
||
|
||
**Критический минимум для трёх сценариев:** для планирования — action contract, бюджет времени и workflow run contract; для сигналов — наблюдение с work/action ID и доставка; для карьеры — активные цели/rubric и attribution. Общая недостающая часть — передача проверенных фактов в конкретные действия и связь результатов запусков обратно с планом. Детальные входы, SQL, параметры, ограничения и проверки — A–H ниже.
|
||
|
||
### A. Общий data flow и оркестрация в Windmill
|
||
|
||
```text
|
||
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:
|
||
|
||
```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.
|
||
|
||
**Критические входы для старта:** явные day/week budget и рабочие границы; `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 выше — следующие добавочные части, реализуемые 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](/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 живых списков проектов перечитаны, обнаружено
|
||
35 620 memberships. Очередь изменений, связанные объекты и фоновая сверка
|
||
продолжаются и показаны отдельно. Legacy read projection и общий writer lock
|
||
реализованы; старый collector архивирован. [Контракт и проверка runtime](asana-coverage-pilot/expansion-2026-10-06.md#постоянный-worker--14102026).
|
||
|
||
Историческая сверка до этого rollout дала 21/28 по ID scan 06.10, 35 080
|
||
memberships, 11 недоступных direct tasks и 1 685 внешних dependency targets.
|
||
Эти числа не являются текущим live freshness отчётом.
|
||
|
||
Основание: [исследование шести уровней](personal-os-six-layer-analysis-2026-10-05.md), [архитектурные контракты](personal-os-architecture-decision-2026-10-04.md), [контракт данных R2](personal-os-evidence-graph-design-2026-10-04.md). Этот документ конкретизирует порядок исполнения. Предложения о технологиях не означают, что они уже установлены или выбраны по результатам испытаний.
|
||
|
||
## Предыдущая итерация: загрузка источников и обновление выводов
|
||
|
||
**Дополнение 15.10.2026 — инкрементальное обновление выводов включено.**
|
||
`f/analyse/work_claims_extract` опубликован в рабочем Windmill и запускается
|
||
каждые пять минут, по одной задаче за проход без пересечения запусков.
|
||
Миграции 011 и 012 применены к `personal_os`, runner и браузер перезапущены.
|
||
Существующий пилот сохраняется: изменения источников приводят к отдельным
|
||
правкам выводов с прежними ID, версиями и защитой ручных решений. Неизменившийся
|
||
вход не вызывает модель. В браузере доступны цитаты, история и ручная проверка.
|
||
Начальная очередь ещё обрабатывается; слишком большие пакеты блокируются явно.
|
||
[Поведение, проверка и включение](work-claim-updates-2026-10-15.md).
|
||
|
||
Алекс валидирует смысловую точность пилотных выводов агентов. Автоматическое
|
||
обновление поддерживает их актуальность, но не заменяет эту валидацию и не
|
||
означает завершения E2 или автоматической публикации принятых выводов.
|
||
|
||
**Дополнение 14.10.2026 — work items и контекст дизайнов реализованы и перенесены в основную БД.**
|
||
Каждый локальный ворктри без принятой связи должен получать отдельный устойчивый
|
||
work item на дашборде для ручного либо агентского резолва: привязать существующую
|
||
работу/задачу, учитывать локально, исключить с причиной либо подготовить и завести
|
||
задачу Asana. Повторный сбор сохраняет item и принятое решение. В контекст работы
|
||
добавляются tech-design задачи Asana, опубликованные документы и их драфты
|
||
Obsidian, включая драфты без Asana ID; смысловые совпадения проходят резолв.
|
||
Порядок, действия и критерии приёмки — в [текущем плане GitHub и рабочих
|
||
ситуаций](github-work-situations-2026-10-14.md#work-items-и-tech-designs).
|
||
Проверены устойчивые items, сохранение решений, цепочки дизайнов, отдельный
|
||
вызов локальной модели из Windmill и безопасное создание задачи из черновика.
|
||
Пользователь разрешил основной перенос; все 17 таблиц перенесены с совпадением
|
||
полных хешей. Windmill и дашборд переключены на `personal_os`.
|
||
|
||
**Контур E1 — проверяемая загрузка Asana-проектов.** Пилот трёх проектов завершён; по его результату [расширен scope](asana-coverage-pilot/expansion-2026-10-06.md) и включён постоянный worker, описанный в начале документа. Полный ID-обход завершён для 28 проектов: 26 текущих подписок и два проверенных пилота. Задачи из остальных проектов, напрямую связанные с пользователем, грузятся адресно. Критерий полноты — доступный состав выбранных проектов, все принадлежности задач, доступная история и дерево подзадач с явными пробелами и воспроизводимым отчётом; очередь worker продолжает сверку.
|
||
|
||
Начальный порядок: Apple Team Meta Project → Apple Feature Flags Registry → Scheduled Rotations. Meta Project даёт разные типы объектов и известные примеры потерь; остальные проверяют переносимость решения. Размер полных проектов пока не измерен, поэтому длительность массовой выгрузки определяется после дешёвого обхода IDs.
|
||
|
||
В исходном рабочем зеркале были пропуски задач, комментариев и связей. Тестовый E1 backfill теперь сверен с независимым ID-обходом всех трёх пилотов; [отчёт](asana-coverage-pilot/README.md). Это не означает полноту всех источников, рабочего зеркала или готовность персонального ранжирования.
|
||
|
||
### Кто что делает
|
||
|
||
| Участник | Ответственность | Когда нужен |
|
||
|---|---|---|
|
||
| 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](https://developers.asana.com/reference/gettasksforproject), [Search](https://developers.asana.com/reference/searchtasksforworkspace), [Pagination](https://developers.asana.com/docs/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 минут в неделю после настройки, его достижение измеряется. Расписание постоянной работы утверждается по итогам ручного/ограниченного пилота вместе с конкретными полномочиями и бюджетом.
|
||
|
||
## Зависимости и независимая подготовка
|
||
|
||
```mermaid
|
||
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](asana-coverage-pilot/README.md) | 6 тестов, независимый полный ID-обход SDK и source/local diff |
|
||
| E1.2 | in_progress — схема и writer проверены на тестовой БД | Совместимый projection для старых читателей |
|
||
| E1.3 | complete — три проекта загружены в отдельную тестовую БД | 7658 уникальных задач с потомками и 125 970 stories |
|
||
| E1.4 | verified для трёх пилотов — [итоговые отчёты](asana-coverage-pilot/README.md) | 4618/4618 исходных memberships; известных потерь и неполных разделов нет |
|
||
| E1 expansion | постоянный worker запущен — [runtime и проверка](asana-coverage-pilot/expansion-2026-10-06.md#постоянный-worker--14102026) | Живые списки 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 не означает пустую очередь или актуальность всех связанных объектов.
|