obsidian-vault/personal/plans/personal-os-operating-plan-2026-10-03.md

---
namespace: personal
tags:
  - personal-os
  - execution-plan
  - focus
  - work-life-balance
date: '2026-10-03T00:00:00.000Z'
status: approved-for-implementation
approved_on: '2026-10-03T00:00:00.000Z'
implementation_status: shadow-running
mission: '[[personal/projects/personal-os/personal-os-purpose]]'
updated: '2026-10-04'
---

# Personal OS — аудит и план запуска вокруг фокуса

> План реализации заменён пакетом R2: [[personal/projects/personal-os/personal-os-system-review-index]]. Ниже сохранены история и прежняя постановка; текущий порядок R0–R4, контракты и пороги приёмки находятся в R2.


> **Архитектура production v1 пока не согласована.** Выбор Node/TypeScript vs n8n/Node-RED, data flow, контуры планнера/ретроспектора, канал взаимодействия и критерии завершения собраны в [проекте архитектурного решения](/Users/admin/Developer/personal-os/planning/personal-os-architecture-decision-2026-10-04.md). Это предложение для обсуждения; оно не разрешает новые расписания, агентские запуски, миграции или доставку. Утверждённый ранее read-only shadow остаётся в своей прежней границе.

**Утверждённое решение от 2026-10-03:** сначала запустить контур управления самочувствием, фокусом и посильной нагрузкой Алекса. Его главная проблема сейчас — **рваный фокус**: одновременно идут его задачи и много агентных задач, которые неожиданно возвращаются к нему как ревью/решения. Технические источники дают факты, но само приложение на переднем плане не определяет рабочую тему. Кодинговые агенты — второй контур, ограниченный человеческим временем ревью и токенами. Этот документ заменяет прежнюю версию плана от 2026-10-03, где на первое место ошибочно поставлена техническая надёжность feed.

**Состояние выполнения на 2026-10-04:** пакеты A–C реализованы для подтверждённых источников; D работает как локальный shadow-фокус с явными `unknown`; E запущен как тихий сбор. `com.personalos.focus-shadow` работает по будням 08:00–20:00 каждые 15 минут; проверка 4 октября: 54 запуска, последний код 0, последний снимок 00:41 +06. Корпоративный Mattermost собирается отдельным read-only клиентом. Zoom: два transcript сохранены, ночной LaunchAgent включён на 02:15, первый запуск по расписанию ещё впереди. Через Balda на Monterey/Xcode 13 запущено создание пустого iPad-проекта; сборка и установка нового приложения не подтверждены. Двухдневная калибровка, ручная проверка 20 интервалов и пользовательский пилот ещё не завершены. Старый Executor, push-уведомления и запись в Asana/GitHub не включены. Миссия: [[personal/projects/personal-os/personal-os-purpose]]. Текущее состояние: [[personal/projects/personal-os/personal-os-status-2026-10]].

## 1. Системная задача и критерий пользы

В каждый момент система поддерживает состояние: **над какой рабочей темой я сейчас занят, какие агентные работы идут параллельно и ждут моего ревью, энергия/настроение (если я их указал), посильная нагрузка и граница рабочего дня, обязательства, встречи, накопившиеся изменения и цена переключения**. Рабочая тема может быть Asana-задачей, ревью PR/Tech Design/Ship Review, планированием, развитием команды, встречей или контролем агента; непосредственный кодинг — лишь один из видов работы. На основе этого система предлагает выполнимый фокус дня, защищает его, помогает вернуться после переключения, пересобирает план и сохраняет карьерные факты. Алекс может в один шаг сменить фокус, снизить нагрузку или отложить предложение.

Приоритеты строго такие: (1) хорошо себя чувствовать, (2) эффективно распределять нагрузку и фокус, (3) сохранять баланс жизни/работы, (4) выполнять и улучшать рабочие и карьерные результаты. Больший объём работы не компенсирует ухудшение первых трёх целей. ActivityWatch — наблюдение за поведением компьютера, **не датчик самочувствия и не оценка продуктивности человека**.

### P0: актуальное состояние проектов для всех агентных сценариев

Аудит к career advisor call 2026-10-04 показал сбой: обсуждённое в Zoom предложение о code-initialized Core Data models было позже отменено, но агент трактовал закрытую Asana-подзадачу и старый разговор как действующий результат. **Первый read-only project-truth analyzer для VSCode/SPM реализован и подключён к shadow** между сбором источников и focus/career/advisor выводом; рабочий JSON-only путь проверен без DB-миграции; playbook для подготовки advisor call создан, вторничная автоматизация на 09:00 включена; первый запуск ещё не проверен. Он различает предложение, решение, отмену, внедрение, проверку и открытый follow-up; хранит время, ссылку, свежесть, confidence и supersedes. При конфликте даёт `unknown` и не выдаёт неподтверждённое внедрение. Первый fixture — [[personal/projects/personal-os/project-truth-analyzer]]: Core Data code-init отменён, существующие модели сохранены под Xcode 27, cleanup открыт. Параллельная калибровка shadow-сбора продолжается; выпуск карьерных claims о проекте зависит от этой проверки.

### Сигнал раздражения из выгруженных транскриптов агентов — требование Алекса от 2026-10-04

**Источником служит выгрузка транскриптов общения Алекса с другими агентами, а не диалог с Personal OS.** Явная грубость или брань в сообщении Алекса агенту — предварительный сигнал раздражения в соответствующем рабочем интервале. Анализировать вместе с темой задачи, повторными неудачами агента и очередью ревью: это может объяснять цену работы и перегрузку. Не превращать сигнал в диагноз, оценку продуктивности или окончательный вывод о самочувствии; явная оценка Алекса имеет приоритет.

**Контракт реализации:** локально импортировать уже выгруженные транскрипты Codex/Claude/других используемых агентов, отделить сообщения Алекса от ответов агента, извлечь `irritation_signal` с временем, ссылкой на источник и confidence. В производном timeline/focus state хранить метку и ссылку на исходный транскрипт, без дублирования его текста. Проверить резкое обращение, техническую брань о коде и просто короткую команду; последние два случая не должны автоматически означать раздражение. Нынешний `session-observer.js` читает только metadata, поэтому импорт и анализ транскриптов **ещё не реализованы**, а сигнал пока `unknown`.

**Режим использования:** Personal OS пассивно анализирует выгрузки и учитывает результат при оценке нагрузки и качества работы агентов. В обычной жизни Алекс не ведёт переписку с «агентом Personal OS»; этот сигнал не запускает сообщения, вопросы или вмешательства в момент раздражения.

### Целевой цикл

1. **Понимание факта:** собирает временную линию человеческой работы и параллельных агентных задач, связывает рабочую тему с Asana/PR/встречей/worktree по доказательствам; неизвестное оставляет неизвестным.
2. **Понимание спроса и ёмкости:** определяет, что действительно требуется от Алекса, сколько времени/энергии займёт, где возникнет человеческое ревью; вычитает встречи, перерывы, переключения и окончание рабочего дня, учитывает добровольную отметку энергии/настроения.
3. **Выбор фокуса:** предлагает одну основную работу и ограниченное число обязательств, объясняет перенос/делегирование/ожидание остальных; Tech Design, Ship Review, team growth и карьерные дела не исчезают за срочным шумом.
4. **Защита и восстановление:** в фокусе обычные изменения копятся молча, при естественном переходе приходит короткая карточка «где остановился → что изменилось → что дальше». Критическое исключение имеет явное правило и ссылку.
5. **Обратная связь:** Алекс одним действием отмечает полезность/ошибку/перегрузку или меняет план; система измеряет последствия и корректирует правила. Агенты развивают систему только в пределах бюджета внимания и токенов.

### Два первичных блокера

**Блокер 1 — достоверность и смысл наблюдений.** Нужна единая модель `временной интервал человека ↔ рабочая тема ↔ конкретный объект Asana/PR/TD/Ship Review/meeting ↔ агентная задача ↔ ожидаемое ревью`. ActivityWatch даёт окна/AFK/переключения, а Asana, browser URL, VS Code/worktree, Codex/Claude, GitHub и Zoom дают смысл. Агент разбирает неоднозначные интервалы, но помечает уверенность и не строит решение на догадке. Первое доказательство: один рабочий день можно восстановить как последовательность реальных тем и агентных ожиданий без выдуманных привязок.

**Блокер 2 — решение «что надо делать» при ограниченном ресурсе.** Это отдельный анализ поверх фактов: роль и ответственность Алекса, важность для проекта/карьеры/команды, срок и цена ожидания, зависимые люди, доступные окна, энергия, перерывы, стоимость переключения, очередь агентных ревью. Выход — `сейчас / выделить окно / делегировать / ждать / перенести` с причиной и влиянием на баланс. Первое доказательство: в перегруженный день система защищает основной фокус и явно переносит низкоценное агентное ревью, не теряя настоящее обязательство.

Короткая доставка и обратная связь — следующий этап, который проверяет, что оба блокера действительно решены. Ровный сбор ActivityWatch без семантики рабочей темы не закрывает блокер 1; точная временная линия без выбора посильной работы не закрывает блокер 2.

### Что проверяем после сбора данных

Сбор событий — вход в цикл проверки, а не самостоятельная цель. **Первая проверка: можно ли восстановить человеческую рабочую тему и очередь его решений. Вторая: помогает ли предложенный выбор сохранить самочувствие и фокус, не теряя обязательств.** Ниже — гипотезы пилота; пороги уточняются по исходному замеру, а не выдаются за уже доказанный эффект.

| Гипотеза | Наблюдение и опровержение | Что меняем при ошибке |
|---|---|---|
| H1. ID/URL Asana и PR, worktree/ветка и явное состояние agent run позволяют связать большую часть важных интервалов и ожиданий без угадывания по приложению. | На 20 интервалах из разных типов работы вручную по исходным ссылкам проверяем `work_thread_id`, `actor`, `activity`, `needs_human` и свежесть; считаем долю верных `high-confidence`, долю `unknown`, ложные связи и пропущенные обязательства. Любая уверенная привязка, противоречащая источнику, опровергает правило, давшее её. | Исправить конкретный adapter/binding; снизить confidence; оставить `unknown`. Не повышать confidence только ради покрытия. |
| H2. «Рваный фокус» лучше объясняют переходы **между рабочими темами** и неожиданные agent review/approval, чем число смен приложений. | За два дня сопоставить реальные переходы, время возврата к теме и неплановые запросы с короткой добровольной оценкой «насколько рваным был день» 1–5. Если смены приложений без смены темы считаются прерываниями или оценка не согласуется с наблюдаемыми событиями, модель фрагментации неверна. | Пересмотреть правила границ темы и события прерывания; не оптимизировать счётчик окон. Субъективная оценка не заменяется ActivityWatch. |
| H3. Роли, зависимости, последствия ожидания и доступная ёмкость дают полезнее выбор «сейчас/позже», чем overdue/easiest-first. | На обычном и перегруженном дне в shadow-режиме сравнить предложение с проверенными Asana/PR/meeting обязательствами, свободным временем, перерывами и границей работы. Проверять: нет пропущенного важного действия, нет работы сверх ёмкости, есть причина переноса. Одного неверно названного срочным FYI достаточно для исправления роли. | Исправить извлечение `work_demand` или правило приоритета; явно показать неопределённость. Не повышать срочность из-за одного комментария, красного CI или даты без последствий. |
| H4. Пакетное ревью готовых agent results уменьшает неплановые обращения без накопления действительно срочных решений. | В пятидневном пилоте сравнить число обращений, минуты ревью, возраст очереди и пропущенные сроки с исходным замером. Если обращений меньше, но обязательства теряются или вечер занят ревью, гипотеза не подтверждена. | Изменить reviewer slot, WIP и правило критического исключения; не увеличивать параллельность агентов ради throughput. |
| H5. Добровольная отметка энергии/настроения улучшает посильность плана без дополнительной нагрузки. | Сравнить корректировки в дни с отметкой и `unknown`, частоту «слишком много», самочувствие и время на ввод. Если отметка не даёт пользы или раздражает, убрать запрос и оставить консервативный `unknown`. | Изменить `capacity-model.js`/момент запроса, а не выводить настроение из окна или активности. |

### Калибровка и исправление правил

1. **Тихий baseline, два рабочих дня.** Проверить свежесть каждого источника и восстановить события без уведомлений. Для Asana отдельно различать `assigned`, `mentioned`, `commented`, `blocked_by`, `requested_review`, `FYI`; для GitHub — мой PR, CI, approvals/changes requested и PR, где ожидается именно моё ревью. Отсутствующий канал обозначать `unknown`, не «нет обязательств».
2. **Выборка и эталон.** Взять 20 интервалов поперёк Asana, браузера/PR, VS Code/worktrees, agent sessions, встреч и личного контекста. Для каждого сохранить исходный ID/URL, тип источника, время наблюдения, автоматическую метку, confidence и проверенную метку. Личные проекты и статьи различать как `personal_project`, `work_research`, `leisure_or_break` или `unknown` по контексту и намерению; домен сайта сам по себе не доказывает «отвлечение». Без подтверждения Алекса не приписывать намерение или самочувствие.
3. **Разбор расхождений.** Сначала исправлять неверный/устаревший источник, затем связь объектов, затем роль и приоритет, затем момент/формат обращения. Менять одно правило за раз; сохранить в `calibration_cases` и `calibration_changes` исходный пример, исправление и результат повторного прогона. Уточнение у Алекса только на естественном переходе и лишь когда неоднозначность меняет его план; в пилоте максимум один такой вопрос в день.
4. **Shadow-план и пятидневный пилот.** На двух днях воспроизвести решения без доставки и проверить H3; после согласованного включения короткой карточки проверить H2/H4/H5 на пяти рабочих днях. Ежедневно смотреть только критические ложные срочности и пропущенные обязательства; по завершении сравнить субъективный фокус/самочувствие, неплановые обращения, review minutes, границу дня и расход токенов. Если карточки не читаются или вредят фокусу, остановить доставку и исправить правило. Отсутствие обратной связи не считать согласием.

**Аудит источников:** [[personal/plans/personal-os-source-audit-2026-10-03]] фиксирует `есть / нет / свежесть / достоверность / что требуется от Алекса / точная правка / проверка` для Asana, GitHub, браузера, worktrees и Codex/Claude/Balda. Его выводы уточняют P0.1; аудит не включал автозапуск сборщиков.

### Первый исполняемый срез — выполняется

**Пакет A — выполнен 2026-10-03.** Добавлены локальная очередь `work_demands`, статус источника и классификация прямых вопросов, ревью, назначений и неопределённостей. После одного read-only refresh очередь `fresh`: 2 прямых вопроса и 1 запрос на ревью из Asana; FYI и автоматические напоминания не названы обязанностью. Проверены 20 реальных комментариев без переноса текста в отчёт, 6 автоматических тестов проходят. Обновлён `~/context/attention.md`. Старый Executor и расписание не запускались.

**Ход 2026-10-03, 22:42 +06.** `com.personalos.focus-shadow` загружен с интервалом 15 минут: 3 октября тихий сбор продолжается до полуночи, затем — рабочие дни 08:00–20:00; два полных read-only прогона сегодня завершились без ошибок. Снимок сохраняется в `~/context/shadow.json`, `focus.json` и `shadow-history/`. GitHub: 27 моих open PR и 5 текущих review requests, оба набора точно совпали с независимым REST API; CI, head SHA, approvals и unresolved threads читаются. ActivityWatch: 254 локальных интервала; текущая тема `unknown`, потому что AFK-данные сейчас stale. DDG URL watcher загружен, но свежего URL ещё нет — не строить привязку по названию окна. Метаданные Codex/Claude и локальные worktrees читаются без текста разговоров; `needs_human` остаётся unknown без подтверждённого события. Календарь и Balda не имеют подтверждённого read-path/контракта в этом срезе. 18 тестов проходят. Два рабочих дня shadow и проверка 20 разнообразных интервалов остаются впереди; доставка карточек, Zoom, iPad и старый Executor не включены.

**Обновление 2026-10-04, 00:41 +06.** Последний полный снимок: Asana/GitHub и AW window/AFK/DDG URL `fresh`; Xcode/VS Code `stale` из-за отсутствия недавних событий. Обнаружены 78 worktrees, 40 с незавершёнными изменениями, 2157 изменённых путей и 64 коммита за 30 дней; учитываются размеры и пути без diff. Из 53 интервалов iTerm 18 привязаны к точному worktree по пути в заголовке. 65 Codex и 24 Claude сессии видны по metadata без бесед. Корпоративный Mattermost авторизован отдельным Chrome-клиентом: первый сбор 21 сообщение из 202 каналов, далее каждые 15 минут; на mm.qentra.top проверен сбор 265 сообщений из 9 каналов без фонового расписания. Outlook виден только как активность окна; чтения писем/встреч нет, доступные коннекторы отключены администратором, для Graph нужен разрешённый app/client ID. Календарь и Balda остаются `unknown`. Последний полный snapshot и 27 тестов прошли. Исторические цифры в абзаце выше относятся к 3 октября и не описывают текущую свежесть источников.



**Режим разработки:** одна активная coding-задача Personal OS за раз, один проверяемый результат на задачу, без unattended respawn; текущие Balda/Broker/Virfield уже занимают часть reviewer capacity. До достоверного учёта токенов не выдавать агенту бесконечный Ralph loop. Лимиты первого среза: одна попытка исправления после неудачной проверки, один пакет на ревью Алексу в день, целевой размер ревью до 20 минут. Фактические токены/стоимость логировать, отсутствие usage обозначать `unmetered`; численные token caps P1 согласуются отдельно. Параллельно coding-задаче можно вести read-only диагностику следующего адаптера без нового запроса к Алексу.

1. **Собрать достоверную очередь человеческих обязательств из Asana и GitHub.** В [`sync.js`](file:///Users/admin/Developer/personal-os/sync.js) и новом `work-demand.js` различить назначение, прямой запрос/вопрос, dependency, ревью и FYI с `source ID`, временем, ролью и confidence; комментарий без ответа сам по себе не равен обязательству. В [`gh-snapshot.js`](file:///Users/admin/Developer/personal-os/gh-snapshot.js) получить все мои open PR в рабочих репозиториях и полный список текущих review requests независимо от unread, а для PR — head SHA, CI failures, approvals/changes requested и unresolved review threads. Репозитории брать из явной конфигурации и подтверждённых локальных worktrees, не только из текущего hardcoded `duckduckgo/apple-browsers`. Хранить раздельные `observed_at/stale/error`; ошибка GitHub не превращается в «нет PR». **Приёмка:** на выбранных Asana examples ложный FYI не становится «ответь»; мои 19 текущих PR в `duckduckgo/apple-browsers` не теряются из-за лимита 20; проверка review queue совпадает с текущим API/UI и имеет ссылки. **Польза:** система впервые показывает, что от меня реально ждут, без общего backlog dump.
2. **Привязать текущую работу и агентные ожидания к объектам шага 1.** В [`aw-query.js`](file:///Users/admin/Developer/personal-os/aw-query.js) вычислять `Now` из свежего переднего окна и AFK; DDG URL восстанавливать через существующий watcher или явно показывать `unknown`. Новый `context-links.js` связывает точный Asana task ID/browser PR/repo-worktree-branch-head SHA; новый `session-observer.js` читает только metadata Codex/Claude, `agent-run-adapters.js` принимает подтверждённый `needs_human` или оставляет `unknown`. **Приёмка:** Asana→browser PR→worktree→agent run даёт одну человеческую тему и отдельное агентное время; личный проект/статья не становятся автоматически «плохим отвлечением»; старое событие Xcode/VS Code не побеждает текущее окно. **Польза:** меньше ручного поиска «где остановился» и ложных переключений.
3. **Собрать один локальный focus state по обязательствам и доступной ёмкости.** Новый `capacity-model.js` вычитает подтверждённые встречи, перерывы, резерв на переключение/неожиданное и reviewer slot из установленной границы дня; неизвестный календарь/энергия явно остаются неизвестными. Новый `day-coordinator.js` выбирает одну основную тему, не более трёх ближайших действий и явные переносы; `focus.json`/`focus.md` по запросу заменяют длинный статус. Никаких push и расписания на этом шаге. **Приёмка:** перегруженный fixture-день оставляет перерыв и один reviewer slot; настоящий deadline показан с причиной, FYI и готовый agent PR не прерывают фокус. **Польза:** появляется короткий ответ «что делать сейчас и почему это посильно».
4. **Калибровать без нагрузки на Алекса.** Новый локальный `scripts/run-focus-shadow.sh`/LaunchAgent запускает только read-only incremental Asana/GitHub refresh и локальную сборку timeline/решений без карточек и уведомлений; отдельные каналы помечают `fresh/stale/failed`, целевая свежесть важных обязательств в рабочее время — до 15 минут, с проверкой API затрат и задержек. Два рабочих дня shadow-сбора и 20 интервалов разных типов сравнить с ID/URL/состояниями источников; два дня воспроизвести focus-рекомендации без доставки. Исправлять по одному правилу и сохранять пример/до/после в `calibration_cases/changes`; у Алекса уточнять максимум один вопрос в день только если ответ меняет рекомендацию. **Приёмка:** ноль ложных high-confidence привязок и выдуманных `needs_human`, нет скрытого пропуска важного обязательства, неизвестное не маскируется. **Польза:** рекомендации опираются на проверенные факты, а не на названия окон.
5. **Включить ограниченный пользовательский пилот.** После отдельного согласования границы дня и канала показывать одну карточку на естественном переходе; обычные обновления копить молча. Пять рабочих дней измерять добровольную оценку самочувствия/рваного фокуса, неплановые обращения, минуты ревью, пропущенные обязательства и использование карточки. На «неверно/слишком много» исправлять следующее предложение; неиспользуемую карточку остановить. **Приёмка:** нет обычных прерываний во время focus/meeting и после границы дня; Алекс за ≤10 секунд корректирует план. **Польза:** система начинает помогать в моменте, не создавая новый поток сообщений.

**Утверждённая граница плана от 3 октября:** локальные read-only интеграции, файлы контекста, проверка на выборке и тихий автозапуск shadow-сборщика. Позже Zoom-экспорт отдельно включён и создание пустого iPad-проекта запущено; это не означает приёмку iPad-клиента или автоматического импорта новых встреч. Старый `com.personalos.readonly` и Executor остаются выключенными. Push-уведомления и запись в Asana/GitHub не включены. До пользовательского пилота нужны граница рабочего дня и канал короткой карточки.

### Передача в следующую сессию — исполняемые пакеты

**Стартовая инструкция:** «Выполни утверждённый первый срез Personal OS из этого документа. Начни с пакета A ниже; учитывай [[personal/plans/personal-os-source-audit-2026-10-03]] и миссию. Код и тихий локальный сбор разрешены в указанной границе. Не превращай это в новый раунд общего планирования. Дай один короткий отчёт о результате и проверках; не запрашивай ревью чаще одного раза в день». Разработка стартует в новой сессии; запись этого документа не запускает агентов или сервисы.

1. **Пакет A — Asana obligations.** Проверить текущее `git status` и схему без изменения существующих чужих файлов; сохранить локальные изменения. Из [`asana.js`](file:///Users/admin/Developer/personal-os/asana.js), [`sync.js`](file:///Users/admin/Developer/personal-os/sync.js) и `stories` сделать `work-demand.js` + аддитивную миграцию `migrations/003_focus_core.sql`: `role`, `requested_action`, `requester`, `evidence_gid`, `observed_at`, `confidence`, `unknown`. Отделить прямой вопрос/назначение/ревью от FYI и комментария без ответа. **Готово, когда:** на проверенной выборке прямой запрос показан со ссылкой, FYI не назван обязанностью, ошибка источника не выглядит как пустой список; есть тесты на эти три случая и краткий отчёт о реальных примерах без копирования чувствительного текста.
2. **Пакет B — GitHub obligations.** После пакета A обновить [`gh-snapshot.js`](file:///Users/admin/Developer/personal-os/gh-snapshot.js): текущие мои PR и review assignments по подтверждённым рабочим репозиториям, CI/checks, approvals/changes requested, unresolved threads, head SHA, timestamps/errors по каждому источнику. `unread notification` оставить подсказкой, не источником истины для review queue. **Готово, когда:** число моих PR и текущих запросов на ревью совпадает с прямым GitHub API на момент проверки; сценарии failed CI, новый push после approval и resolved/unresolved comment дают правильное действие или `unknown`.
3. **Пакет C — наблюдаемый контекст.** После пакета B исправить [`aw-query.js`](file:///Users/admin/Developer/personal-os/aw-query.js) и добавить `context-links.js`/`session-observer.js`/`agent-run-adapters.js`: переднее окно+AFK, точный URL/ID, локальные worktrees, metadata сессий и только подтверждённые `needs_human`. Проверить DDG watcher; при отсутствии свежего URL сохранять `browser_url_unknown`. **Готово, когда:** Asana→PR→worktree→агент соединены доказанной связью, человеческое и агентное время раздельны, старый Xcode/VS Code bucket не называется текущим фокусом.
4. **Пакет D — посильное решение.** После пакета C добавить `capacity-model.js`, `day-coordinator.js` и локальные `focus.json`/`focus.md` по запросу: одна основная тема, до трёх действий, причины переносов, встреча/перерыв/граница дня/reviewer slot; отсутствие энергии и календаря остаётся `unknown`. **Готово, когда:** обычный и перегруженный fixture-дни дают выполнимые планы, FYI/готовый agent PR не прерывают фокус, карточка занимает один экран.
5. **Пакет E — тихая проверка и пилот.** После пакета D проверить один read-only прогон, затем включить только новый `run-focus-shadow` для двух рабочих дней без уведомлений, проверить 20 интервалов и зафиксировать исправления. До пользовательского пятидневного пилота получить от Алекса границу рабочего дня и канал карточки; включить доставку только после этого. **Готово, когда:** источник/связь/роль/решение проверены по ссылкам, ноль ложных уверенных `needs_human`, измерены человеческие прерывания и reviewer minutes.

**Общие правила приёмки пакетов:** каждый пакет завершается работающим кодом, тестом фактического риска, коротким diff/артефактом и указанием оставшихся `unknown`; следующий пакет может готовиться автономно, но новые результаты к ревью Алексу не отправлять сверх одного пакета в день. Даты и числа из аудита — снимок 3 октября: в новой сессии проверить свежесть Asana/GitHub/AW, а не считать 19 PR постоянной величиной.

## 2. Что действительно есть 2026-10-03

| Слой | Проверенный факт | Граница факта |
|---|---|---|
| Asana | [`sync.js`](file:///Users/admin/Developer/personal-os/sync.js) читает задачи/комментарии в локальную PostgreSQL; разовый прогон 3 октября дал свежие данные. [`generate-status.js`](file:///Users/admin/Developer/personal-os/generate-status.js#L890) создал `~/context/status.md` (402 строки), пробный [`generate-attention.js`](file:///Users/admin/Developer/personal-os/generate-attention.js#L32) — 28-строчный список. | Фоновый `com.personalos.readonly` после остановки не загружен; разовый прогон не означает работающую Personal OS. Список не учитывает энергию, встречи, перерывы и контекст возврата. |
| ActivityWatch | Локальный `aw-server` слушает 127.0.0.1:5600. 3 октября в 14:13 UTC у bucket `window` и `afk` были свежие записи. [`aw-query.js`](file:///Users/admin/Developer/personal-os/aw-query.js#L220) считает активное время, приложения, проекты, сессии и worktrees. Расширение `activitywatch.aw-watcher-vscode` установлено и в `~/.vscode/extensions/`, и в старом `~/.cursor/extensions/`; [`README.md`](file:///Users/admin/Developer/personal-os/README.md#L106) описывает только Cursor и устарел. | Xcode bucket обновлён последний раз 1 октября, `aw-watcher-vscode` — 2 октября, DDG URL — 8 июня; отсутствие более свежего события не доказывает поломку. Нужно различить источники bucket и проверить работу именно в VS Code. `currentFocus` берёт первый bucket по приоритету xcode→vscode→ddg→window за 20 минут, а не фактически переднее окно; последний [`status.md`](file:///Users/admin/context/status.md) написал `Now: loginwindow (18m ago)`. |
| GitHub и связь с работой | [`gh-snapshot.js`](file:///Users/admin/Developer/personal-os/gh-snapshot.js) получает мои PR/CI и некоторые review requests; [`aw-projects.json`](file:///Users/admin/Developer/personal-os/aw-projects.json) умеет сопоставлять отдельные worktree/URL с проектом. Локально обнаружены 397 Codex и 59 Claude JSONL session files; последний Codex `session_meta` содержит `cwd/git`, Claude session — `cwd/gitBranch` в метаданных (проверено без чтения текста бесед). | Связь worktree ↔ ветка ↔ PR ↔ Asana task и sessions не собрана в единую историю дня. Работу агента нельзя автоматически считать человеческой активностью. Review requests зависят от unread notifications. |
| Встречи/Zoom | В старых промптах есть расписание и попытка MS365-проверки; записи бесед Zoom существуют по сообщению Алекса. | Подтверждённого текущего календарного канала и импорта этих записей в рабочий/карьерный профиль нет. Папка `~/Documents/Zoom` не указывает место всех записей. |
| Агенты | Старый Executor и Hermes-briefs выключены после инцидента. В [`executor_worker_runner.py`](file:///Users/admin/Developer/personal-os/agent/executor_worker_runner.py#L195) задано `max_turns=200`, а [`executor-runner.sh`](file:///Users/admin/Developer/personal-os/executor/executor-runner.sh#L17) допускает двух workers. В текущей Codex desktop задаче доступен read-only список задач с `active/idle/notLoaded`, но это не полный статус запросов к Алексу. | В видимом runner нет учёта токенов/денег и оценки минут ревью Алекса. Логи одного задания содержат повторные respawn без прогресса. Codex/Claude/Balda состояние `needs_human` пока нельзя достоверно собрать из одного списка или mtime; Balda/Broker/Virfield развиваются отдельно. |
| Карьера и день | [`generate-status.js`](file:///Users/admin/Developer/personal-os/generate-status.js#L731) показывает Advisor opportunities и visibility gaps; `activity_daily` хранит агрегаты времени по проектам. | Нет единого состояния для управленческой работы: PR/TD/Ship Review/team growth, баланса, энергии, встреч, ревью агентов и доказательств вклада. Карьерные сигналы оказываются внизу большого статуса; минуты кодинга не отражают менеджерский вклад. |

## 3. Почему старая версия не стала полезной

Алекс сообщил, что быстро перестал читать сгенерированные daily statuses. Точную причинную долю каждого фактора телеметрия не измеряла; ниже — **подтверждённые дефекты дизайна и вывод о вероятном эффекте**.

| Что было | Подтверждение | Почему это мешало | Что меняем в парадигме |
|---|---|---|---|
| Daily brief = большой отчёт. | В `briefs/daily/` 32 сохранившихся файла: медиана 115,5 строк, 30 из 32 длиннее 80; [`2026-05-15.md`](file:///Users/admin/Developer/personal-os/briefs/daily/2026-05-15.md) — 110 строк, с повторными просрочками и исторической trivia. [`daily-brief.md`](file:///Users/admin/Developer/personal-os/agent/prompts/daily-brief.md#L152) предписывает trivia и все разделы. | Высокая цена чтения в начале дня; сигналов больше, чем решений. Формат не был подстроен под то, открыл ли Алекс предыдущий выпуск. | Живое состояние и короткая карточка в нужный момент; подробности по запросу. Публикация не считается успехом без полезности для Алекса. |
| План дня строился от Asana-очереди и фиксированных правил. | [`daily-brief.md`](file:///Users/admin/Developer/personal-os/agent/prompts/daily-brief.md#L205) требует первым «1 Must» или самую лёгкую задачу, затем overdue/urgent; в нём нет запроса энергии и расчёта ёмкости дня. | Предлагаемый объём мог превышать доступное после встреч и перерывов; «первое лёгкое дело» могло вытеснять лучший фокус. | Сначала вместимость, энергия и фокус, затем выбор посильной работы. Перегрузка приводит к явному переносу. |
| «Фокус» выводился из приложения/времени, а не из рабочей темы. | [`aw-query.js`](file:///Users/admin/Developer/personal-os/aw-query.js#L279) сопоставляет window events с Xcode/VSCode/DDG, [`aw-projects.json`](file:///Users/admin/Developer/personal-os/aw-projects.json) в основном классифицирует приложения, URL и имена worktree; связей с Codex/Claude runs, Asana-обязательствами и ревью TD/Ship Review нет. | Asana, browser PR и Claude могут относиться к одной рабочей теме; Codex на экране может быть управлением агентом. Смена приложения ≠ смена работы, и наоборот. | Временная линия рабочих тем с объектами и агентными ожиданиями, confidence и честным `unknown`. |
| Система не знала реальный момент для вмешательства. | [`inbox-triage.md`](file:///Users/admin/Developer/personal-os/agent/prompts/inbox-triage.md#L22) проверяет `Now` из 30-минутного status; [`aw-query.js`](file:///Users/admin/Developer/personal-os/aw-query.js#L305) может выбрать старое Xcode событие или `loginwindow` как текущий фокус. | Даже верный сигнал мог появиться во время deep work или пропасть из-за ошибочной оценки фокуса. | Временная модель `focused / meeting / break / available / unknown`, с отдельной свежестью источников и ручным override. |
| Генерация не замыкала обратную связь. | [`heartbeat.sh`](file:///Users/admin/Developer/personal-os/scripts/heartbeat.sh#L140) проверяет существование файла brief, а не открытие, действие, отложение или неверность; в `schema.sql` нет принятия/полезности карточки. | Система не замечала, что документы перестали помогать, и продолжала производить их по графику. | Измерять добровольное использование и коррекции; прекращать неиспользуемые формы. |
| Автономия агентов создавала долг ревью и расход без ограничителя. | История инцидента в [[personal/projects/personal-os/executor-security-analysis]]; `max_turns=200`, `MAX_WORKERS=2`, нет ledger токенов; в [`executor/logs/1214071796247142/`](file:///Users/admin/Developer/personal-os/executor/logs/1214071796247142/) есть многократные `conflict_no_action` respawns. | Параллельные результаты и вопросы могут рвать фокус Алекса быстрее, чем он успевает проверять; повторы сжигали токены и внимание. | Планировать агентную работу как нагрузку на человека и бюджет; admission control, WIP, stop rules, пакетное ревью. |

## 4. Очерёдность правок — было → станет → проверка

### P0.1 — блокер 1: достоверная временная линия человека, рабочих тем и агентных задач

**Было:** [`aw-query.js`](file:///Users/admin/Developer/personal-os/aw-query.js#L305) считает время приложений/проектов и может назвать старое Xcode/Cursor/DDG событие или `loginwindow` «текущим фокусом». Asana, браузерные PR, VS Code, Codex/Claude, worktrees, встречи и очередь агентных ревью не соединены. Название приложения не говорит, планирует ли Алекс работу, ревьюит TD, контролирует агента или пишет код.

**Станет:** локальная `work_timeline` из интервалов `start/end`, `actor=human|agent`, `work_thread_id`, `activity=planning|asana|pr_review|td_review|ship_review|team_growth|coding|agent_supervision|meeting|break|unknown`, `context_type=work_task|work_research|personal_project|leisure_or_break|unknown`, `source`, `evidence_url/id`, `confidence` и `state` агентной задачи (`running|blocked|waiting_review|done`). Несколько приложений могут соответствовать одной рабочей теме; две параллельные агентные задачи — двум отдельным потокам. Статья и личный проект не получают автоматически ярлык «отвлечение»: возможны работа, осознанный перерыв и неизвестный контекст. Переход между темами и входящий агентный запрос на ревью отмечаются отдельно; именно их частота и время возврата характеризуют «рваный фокус». Никакой интервал с низкой уверенностью не становится основанием для срочного прерывания.

**Как привязывать:** (1) точные ID/URL Asana task и GitHub PR; (2) git branch/worktree и явная связь с PR/Asana; (3) Codex/Claude session metadata `cwd/git/branch/time`, без текста разговоров; (4) календарь/Zoom для встречи; (5) классификация агентом только оставшихся неоднозначных интервалов, со ссылкой на улики и `unknown`, когда доказательств мало. Агент не задаёт вопрос по каждому `unknown`: уточнение допускается на естественном переходе, только если ответ изменит план, в пилоте — не более одного в день. Статус `waiting_review/needs_human` берётся из явного состояния задачи/запроса на approval, **не** из mtime файла или непрочитанного чата. В текущем Codex desktop read-only список задач показывает `active/idle/notLoaded`, но это ещё не полная семантика «ждёт Алекса»; доступ к pending approvals/ответам должен быть проверен отдельным адаптером. Для Claude и Balda/Broker аналогично использовать подтверждённые состояния или `unknown`. ActivityWatch определяет *когда* человек активен/AFK и какое окно впереди, не подменяет смысл работы. Учёт токенов и человеко-минут ревью привязан к отдельным agent runs.

**Правки:** [`aw-query.js`](file:///Users/admin/Developer/personal-os/aw-query.js) — frontmost window + AFK как основа, свежесть, интервалы, исключить lock и старые bucket из `Now`; проверить установленное VS Code расширение, обновить [`README.md`](file:///Users/admin/Developer/personal-os/README.md#L106), диагностировать старый DDG URL watcher в [`DDGWatcher.swift`](file:///Users/admin/Developer/aw-watcher-ddg/Sources/AWWatcherDDG/DDGWatcher.swift) и Xcode watcher только если их данные нужны для связки. [`aw-projects.json`](file:///Users/admin/Developer/personal-os/aw-projects.json) — обновить правила рабочих тем и личного контекста. Новые `session-observer.js` (метаданные Codex/Claude), `agent-run-adapters.js` (явные состояния и запросы на human action из доступных Codex/Claude/Balda источников), `context-links.js` (worktree→branch→PR→Asana), `work-timeline.js` (нормализованный timeline и confidence), миграция `migrations/003_focus_core.sql` (`work_threads`, `work_intervals`, `agent_obligations`, `activity_bindings`, `calibration_cases`, `calibration_changes`). [`gh-snapshot.js`](file:///Users/admin/Developer/personal-os/gh-snapshot.js) — регулярный refresh моих PR, CI failures, approvals/changes requested, review comments и полного списка PR на моё ревью, не только unread notifications; [`sync.js`](file:///Users/admin/Developer/personal-os/sync.js) — Asana ownership, роли и явные requests к Алексу; у каждого источника `observed_at/ok/stale/failed`. Точные интервалы обновления определить после аудита источников и измерения задержек; старый `generate-status.js` перестать использовать как единственный источник «Now».

**Приёмка:** два рабочих дня тихого shadow-сбора, без новых сообщений Алексу. На 20 проверенных интервалах ни одна `high-confidence` привязка не противоречит исходной Asana/PR/session ссылке; неоднозначные остаются `unknown`. Fixture `Asana task → browser PR → Claude по той же задаче` показывает одну рабочую тему и отдельную работу агента; fixture с двумя агентами показывает два `waiting_review` без удвоения человеческих часов. Xcode→browser, VS Code→Asana, lock/AFK и устаревший watcher дают корректное состояние, а не ложное «сейчас кодит».

### P0.2 — блокер 2: анализ «что надо делать» при реальном фокусе и самочувствии

**Было:** даже точные Asana/PR и минуты ActivityWatch выдавались как срочность/список задач. Не определялись роль Алекса и цена ожидания, вклад в карьеру и команду, доступная энергия, размер окна до следующей встречи, цена переключения и очередь агентных ревью. Календарь/Zoom пока не подтверждены как полный источник расписания.

**Станет:** `day_state` содержит явно выбранный фокус, добровольную энергию/настроение (1–5 или `unknown`), границу рабочего дня, подтверждённые встречи, доступные окна, перерывы, задачи и зависимости, карьерные обязательства, reviewer minutes/WIP и перенесённые пункты. `work_demand` для каждого кандидата хранит: роль `owner|reviewer|advisor|manager|observer`, кто ждёт, проверяемый срок и последствия ожидания, пользу для проекта/карьеры, длительность и когнитивную тяжесть, состояние агента, source links и уверенность. Результат по кандидату — `делать сейчас / выделить окно / делегировать / ждать / перенести` с человеческим объяснением.

**Приоритетный принцип:** сначала самочувствие и законные/реальные границы дня, затем защитить основную рабочую тему, затем обязательства перед другими людьми и узкие окна, затем карьерный/командный вклад; количество просроченных дат или готовых agent PR не является порядком дня. Один и тот же PR/Asana task дедуплицируется. У задачи с сомнительной ролью — `needs_clarification`, а не императив «ответить». При низкой энергии сложное ревью можно отложить, но настоящий hard deadline явно показать вместе с вариантом делегирования/сокращения другой работы.

**Правки:** `migrations/003_focus_core.sql` добавить `day_state`, `work_demands`, `focus_feedback` и использовать `agent_obligations` из P0.1 для оценки reviewer load; новый `work-demand.js` извлекает роли/зависимости из Asana, текущих PR, TD, Ship Reviews, meeting commitments и agent outputs, сохраняет доказательство и сомнения; новый `capacity-model.js` считает рабочую ёмкость; новый `day-coordinator.js` выбирает фокус и объясняет переносы. [`agent/task-role-classifier.md`](file:///Users/admin/Developer/personal-os/agent/task-role-classifier.md) и соответствующие playbooks обновить для advisor/manager/reviewer и контроля агентов; [`agent/prompts/daily-brief.md`](file:///Users/admin/Developer/personal-os/agent/prompts/daily-brief.md) убрать автоматическое «easiest first», полный overdue dump и неконтекстный план. Минимальный локальный ввод `focus-input.js`: сменить фокус/энергию/конец работы/«сегодня легче», без обязательного дневника. Для встреч сначала проверить фактический calendar read-path; при его отсутствии `meeting_schedule_unknown`, а не время, выведенное из Asana-задачи.

**Расчёт ёмкости:** время до границы работы − подтверждённые встречи − переходы между темами − защищённые перерывы − резерв на неожиданное − согласованное время человеческого ревью. Сложность работы соотносится с *явно указанной* энергией; `unknown` даёт консервативное предложение. Если спрос выше ёмкости, система показывает **что переносит/делегирует/оставляет ждать и почему**; не превращает личное время в рабочий резерв.

**Приёмка:** на fixture-дне с двумя встречами, низкой энергией, одним PR-review, одним TD/Ship Review, тремя Asana-задачами и двумя готовыми агентными результатами система оставляет одну основную рабочую тему, один ограниченный reviewer slot, перерыв и явные переносы; не предъявляет сразу два агентных ревью. На fixture-дне без календаря не выдумывает время встречи. На fixture с прямым запросом коллеги отличает реальное обязательство от FYI. Все решения имеют ссылку и расчёт ёмкости, личное время остаётся вне плана.

### P0.3. Управлять моментом и формой обращения к Алексу

**Было:** [`scripts/heartbeat.sh`](file:///Users/admin/Developer/personal-os/scripts/heartbeat.sh#L140) выпускал daily brief по часам и inbox каждые 30 минут; [`daily-brief.md`](file:///Users/admin/Developer/personal-os/agent/prompts/daily-brief.md#L205) требует длинный фиксированный формат. Пробный [`attention.md`](file:///Users/admin/context/attention.md) короче, но всё ещё список событий без плана нагрузки и состояния фокуса.

**Станет:** один короткий `focus_state` с текущей рабочей темой (не только app), доступной ёмкостью, **не более трёх** ближайших осмысленных действий, одной причиной сменить приоритет, временем следующего перехода/перерыва, числом/минутами ожидающих агентных ревью и ссылками. Подробный контекст открывается по желанию. Во время focus/meeting обычные изменения и готовые результаты агентов остаются в локальной очереди; после перехода — одна карточка восстановления. Критическое прерывание требует подтверждённого владельца, последствий ожидания и указанного deadline; возраст комментария или красная иконка недостаточны. Старое «3 часа» из миссии — кандидат на калибровку, не автоматическое правило для всех задач.

**Правки:** новый `focus-policy.js` (классы состояний, quiet hours, исключения); `day-coordinator.js` (динамический выбор после перехода); [`generate-attention.js`](file:///Users/admin/Developer/personal-os/generate-attention.js) заменить секции «Ответить/Ревью/Текущая работа» на компактный объект `focus_state` + фоновые обязательства и связи с источниками; `agent-run-adapters.js` складывает **уже существующие** Codex/Claude/Balda результаты и запросы в одну review queue, отличая genuine approval от обычного статуса. Там, где промпты/транспорт управляются Personal OS, заменить прямые статусные пинги единым review packet с оценкой времени; внешние неперехватываемые уведомления явно показывать как пробел. [`agent/prompts/daily-brief.md`](file:///Users/admin/Developer/personal-os/agent/prompts/daily-brief.md) заменить обязательные trivia, overdue dump и «easiest first» правилом краткой карточки с capacity/reason; [`scripts/heartbeat.sh`](file:///Users/admin/Developer/personal-os/scripts/heartbeat.sh) оставить старые brief jobs выключенными, позже вызвать только согласованный новый рендер. Выходы `~/context/focus.json` и `~/context/focus.md` атомарны; iPad позже читает тот же контракт в ограниченном виде.

**Приёмка:** во время 45-минутной работы над одной темой через Asana → browser PR → Claude два законченных agent jobs и обычный комментарий не создают три прерывания; переключение приложений внутри темы не обнуляет фокус. После блока доступна **одна** карточка с исходной темой, изменениями, ссылками и посильным следующим действием; агентные ревью остаются в выделенном окне. После встречи видно, к какой теме вернуться без поиска по нескольким приложениям. После границы рабочего дня обычных рабочих сигналов нет.

### P0.4. Замкнуть цикл на ощущении пользы, а не на числе сгенерированных файлов

**Было:** файл существует → job считает успех; невозможно узнать, пригодился ли план, был ли он слишком длинным, насколько посильным оказался день. Старые brief-форматы могли копиться, даже когда Алекс перестал их читать.

**Станет:** у карточки есть необязательные одношаговые элементы управления `полезно / неверно / слишком много / отложить` и оценка энергии/самочувствия 1–5, без переписки с агентом Personal OS. Система хранит correction с причиной и меняет следующий план: неверный сигнал удаляет ложное правило, «слишком много» уменьшает объём, пропуск карточки не порождает дополнительных напоминаний. Личные оценки остаются локальными и не становятся performance-метрикой.

**Правки:** `migrations/003_focus_core.sql` для `focus_feedback`; новый `focus-feedback.js`; [`agent/prompts/weekly-review.md`](file:///Users/admin/Developer/personal-os/agent/prompts/weekly-review.md) заменить обзор backlog на оценку: самочувствие (если добровольно указано), восстановление контекста, защищённые focus/break blocks, пропущенные обязательства, reviewer load, ложные прерывания. Отчёт не чаще раза в неделю и с одним предложением изменения правила.

**Приёмка 5 рабочих дней:** каждый день можно открыть состояние за один экран; ноль обычных прерываний во время подтверждённых focus blocks, ноль рабочих push после установленной границы, ни одно критическое сообщение без ссылки/причины. Начальный и итоговый замер включают число переходов **между рабочими темами**, число неплановых обращений к Алексу от агентов, накопленные минуты ревью и короткую добровольную оценку «рваности фокуса»/самочувствия; цель — уменьшение неплановых обращений и отсутствие ухудшения самочувствия, а не максимизация активных минут. Алекс может за ≤10 секунд отметить ошибку или перегрузку; его коррекция меняет следующий расчёт. Если он снова не читает карточку, формат пересматривается, а не размножается.

### P1. Допустить кодинговых агентов только через два бюджета

**Было:** `MAX_WORKERS=2`, `max_turns=200`, повторные respawn и подробные сообщения в чат; очередь ревью Алекса и токены не учитываются в плане дня.

**Станет:** перед запуском есть **два независимых лимита**: (A) человеческий — ожидаемые минуты ревью, уже ожидающие результаты, доступный reviewer slot с учётом энергии/фокуса; (B) агентный — токены/стоимость, время, число попыток и параллельность. Ledger хранит `provider/model`, input/output/cache tokens, оценку денег по фактическому тарифу, длительность, retries, прогноз и факт минут ревью. Агентная задача получает прогноз пользы и затрат; admission разрешён, только если оба остатка достаточны. На 80% дневного/недельного лимита новые coding jobs не стартуют, на 100% текущий job завершает безопасную точку и останавливается с артефактом/блокером. После двух попыток без нового проверяемого прогресса — stop без самоперезапуска. Готовый результат сверх reviewer capacity остаётся в очереди без уведомления Алекса.

**Правки:** `migrations/004_agent_capacity.sql` (`agent_runs`, `agent_usage`, `review_queue`, лимиты, прогноз/факт); новый `agent-budget.js` как admission/stop policy; [`agent/executor_worker_runner.py`](file:///Users/admin/Developer/personal-os/agent/executor_worker_runner.py#L195) логирует usage из ResultMessage/провайдера и прерывает по budget, не выдаёт `max_turns` за успех; [`executor/executor-runner.sh`](file:///Users/admin/Developer/personal-os/executor/executor-runner.sh#L17) в будущей замене/адаптере ограничивает WIP и запрещает бесконечный respawn; правила в `agent/prompts/executor-*.md` требуют одного проверяемого артефакта и оценки времени ревью, без полного trace в чат. Balda/Broker/Virfield остаются своим параллельным проектом; Personal OS пользуется их зрелым интерфейсом после приёмки.

**Предлагаемые стартовые лимиты для пилота, не включены:** одновременно 1 coding worker; 1 результат, ожидающий Алекса; до 20 минут ревью в рабочий день; максимум 1 автоматическая повторная попытка; 30 000 суммарных input+output токенов на задачу, 60 000 в день, 120 000 в неделю (cache tokens хранить отдельно для расчёта стоимости). После 3 измеренных задач пересчитать лимиты по реальной стоимости и времени ревью; стоимость в деньгах считать по фактическому провайдеру/плану, без выдуманной цены за токен. Если провайдер не отдаёт usage, пометить `unmetered` и не запускать следующий unattended loop. В день с низкой энергией reviewer slot можно обнулить без накопления срочных запросов.

**Приёмка:** два законченных агентных результата не вызывают два одновременных запроса к Алексу; второй ждёт свободного slot. Задача с повтором без diff/test progress останавливается; ledger показывает токены, время, оценку и факт человеческого ревью. Агентная работа не съедает защищённый focus block и не делает вечер новым рабочим временем.

### Параллельно: Zoom и iPad, но по контракту P0

- **Zoom:** текущий доступ к My Notes подтверждён через отдельный headless Chrome. Два transcript сохранены с `note_id` и источником; первый запуск по расписанию 5 октября и импорт первой новой заметки ещё нужно проверить. Следующий содержательный этап — из сохранённого transcript извлечь проверяемые решения, обещания, сроки и вклад с ссылкой на фрагмент; кандидаты проходят review перед попаданием в рабочий/карьерный профиль. Повторный импорт не должен создавать дубль. См. [[personal/projects/personal-os/zoom-ai-transcript-export]].
- **iPad Desk:** установка прежнего тестового проекта на физический iPad была подтверждена; создание нового пустого проекта через Balda на Monterey/Xcode 13 запущено 4 октября. Следующая контрольная точка — собираемый проект и артефакт установки нового приложения. Первый экран читает ограниченный `focus.json` по LAN: «фокус сейчас / одно ожидание меня / свежесть / нет связи». Приёмка: на iPad виден тот же focus state, после отключения сети ясно показана устаревшая версия; нет лишних алертов.

## 5. Последовательность, зависимости, участие Алекса

1. **Сейчас — тихий сбор запущен, калибровка не завершена.** Сверить 20 интервалов на двух рабочих днях, включая iTerm, DDG URL, личную работу и агентные ожидания; отметить ошибочные привязки. До пятидневного пользовательского пилота уточнить границу рабочего дня и канал карточки.
2. **P0.1 — блокер фактов:** после аудита собрать тихую временную линию человека/агентов/рабочих тем, проверить привязки к Asana/PR/meeting/worktree и честно показать неизвестные интервалы. Проверить 20 интервалов и два дня без новых сообщений Алексу.
3. **P0.1b — проектная правда:** первый датированный `project_state` для VSCode/SPM реализован, fixture, отдельный live-прогон и полный shadow-прогон во временную папку проходят; недостающий Asana-комментарий читается напрямую в read-only режиме. Полный shadow-прогон проверен в режиме `json_only`; следующий этап — подключить дополнительные проекты. Локальная DB-история остаётся необязательным улучшением. Затем направлять advisor/career outputs через claim-gate до новых утверждений о статусе. См. [[personal/projects/personal-os/project-truth-analyzer]].
4. **P0.2 — затем блокер решений:** выбрать посильную работу из Asana, PR, TD, Ship Review, встреч, team growth и агентных ревью по роли, пользе, сроку, энергии и доступному времени; испытать перегруженный день до включения schedule.
5. **P0.3 → P0.4:** показать один короткий живой focus state, провести 5 рабочих дней измеряемого пилота с возможностью исправить перегрузку. Только после этого решать о регулярной доставке.
6. **P1 и параллельные ветки:** продолжить ограниченный coding loop с учётом review/tokens; проверить первый ночной Zoom-запуск и извлечение кандидатов из transcript; принять пустой iPad-проект и затем вывести тот же focus state на устройство. Balda/Broker/Virfield не дублировать.

**Необходимое участие Алекса в пилоте:** перед доставкой карточки — граница рабочего дня и канал; затем по желанию один короткий сигнал «полезно/неверно/слишком много» и ручная смена энергии/фокуса, когда захочется. Система не требует ежедневного ведения журнала. Внешние записи и старый автономный Executor этим планом не разрешены.