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

namespace, tags, date, status, mission

namespace	tags	date	status	mission
personal	personal-os execution-plan focus work-life-balance	2026-10-03	proposed-for-approval	personal/projects/personal-os/personal-os-purpose

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

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

Выполнение: этот документ описывает правки, но не включает автозапуск, старый Executor или запись в 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 — наблюдение за поведением компьютера, не датчик самочувствия и не оценка продуктивности человека.

Целевой цикл

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; аудит не включал автозапуск сборщиков.

Первый исполняемый срез — запуск после согласования

Режим разработки: одна активная 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 и новом work-demand.js различить назначение, прямой запрос/вопрос, dependency, ревью и FYI с source ID, временем, ролью и confidence; комментарий без ответа сам по себе не равен обязательству. В 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 вычислять 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 секунд корректирует план. Польза: система начинает помогать в моменте, не создавая новый поток сообщений.

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

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

Слой	Проверенный факт	Граница факта
Asana	sync.js читает задачи/комментарии в локальную PostgreSQL; разовый прогон 3 октября дал свежие данные. generate-status.js создал ~/context/status.md (402 строки), пробный generate-attention.js — 28-строчный список.	Фоновый com.personalos.readonly после остановки не загружен; разовый прогон не означает работающую Personal OS. Список не учитывает энергию, встречи, перерывы и контекст возврата.
ActivityWatch	Локальный aw-server слушает 127.0.0.1:5600. 3 октября в 14:13 UTC у bucket window и afk были свежие записи. aw-query.js считает активное время, приложения, проекты, сессии и worktrees. Расширение activitywatch.aw-watcher-vscode установлено и в ~/.vscode/extensions/, и в старом ~/.cursor/extensions/; README.md описывает только Cursor и устарел.	Xcode bucket обновлён последний раз 1 октября, aw-watcher-vscode — 2 октября, DDG URL — 8 июня; отсутствие более свежего события не доказывает поломку. Нужно различить источники bucket и проверить работу именно в VS Code. currentFocus берёт первый bucket по приоритету xcode→vscode→ddg→window за 20 минут, а не фактически переднее окно; последний status.md написал Now: loginwindow (18m ago).
GitHub и связь с работой	gh-snapshot.js получает мои PR/CI и некоторые review requests; 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 задано max_turns=200, а executor-runner.sh допускает двух workers. В текущей Codex desktop задаче доступен read-only список задач с active/idle/notLoaded, но это не полный статус запросов к Алексу.	В видимом runner нет учёта токенов/денег и оценки минут ревью Алекса. Логи одного задания содержат повторные respawn без прогресса. Codex/Claude/Balda состояние needs_human пока нельзя достоверно собрать из одного списка или mtime; Balda/Broker/Virfield развиваются отдельно.
Карьера и день	generate-status.js показывает 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 — 110 строк, с повторными просрочками и исторической trivia. daily-brief.md предписывает trivia и все разделы.	Высокая цена чтения в начале дня; сигналов больше, чем решений. Формат не был подстроен под то, открыл ли Алекс предыдущий выпуск.	Живое состояние и короткая карточка в нужный момент; подробности по запросу. Публикация не считается успехом без полезности для Алекса.
План дня строился от Asana-очереди и фиксированных правил.	daily-brief.md требует первым «1 Must» или самую лёгкую задачу, затем overdue/urgent; в нём нет запроса энергии и расчёта ёмкости дня.	Предлагаемый объём мог превышать доступное после встреч и перерывов; «первое лёгкое дело» могло вытеснять лучший фокус.	Сначала вместимость, энергия и фокус, затем выбор посильной работы. Перегрузка приводит к явному переносу.
«Фокус» выводился из приложения/времени, а не из рабочей темы.	aw-query.js сопоставляет window events с Xcode/VSCode/DDG, aw-projects.json в основном классифицирует приложения, URL и имена worktree; связей с Codex/Claude runs, Asana-обязательствами и ревью TD/Ship Review нет.	Asana, browser PR и Claude могут относиться к одной рабочей теме; Codex на экране может быть управлением агентом. Смена приложения ≠ смена работы, и наоборот.	Временная линия рабочих тем с объектами и агентными ожиданиями, confidence и честным unknown.
Система не знала реальный момент для вмешательства.	inbox-triage.md проверяет Now из 30-минутного status; aw-query.js может выбрать старое Xcode событие или loginwindow как текущий фокус.	Даже верный сигнал мог появиться во время deep work или пропасть из-за ошибочной оценки фокуса.	Временная модель focused / meeting / break / available / unknown, с отдельной свежестью источников и ручным override.
Генерация не замыкала обратную связь.	heartbeat.sh проверяет существование файла brief, а не открытие, действие, отложение или неверность; в schema.sql нет принятия/полезности карточки.	Система не замечала, что документы перестали помогать, и продолжала производить их по графику.	Измерять добровольное использование и коррекции; прекращать неиспользуемые формы.
Автономия агентов создавала долг ревью и расход без ограничителя.	История инцидента в personal/projects/personal-os/executor-security-analysis; max_turns=200, MAX_WORKERS=2, нет ledger токенов; в executor/logs/1214071796247142/ есть многократные conflict_no_action respawns.	Параллельные результаты и вопросы могут рвать фокус Алекса быстрее, чем он успевает проверять; повторы сжигали токены и внимание.	Планировать агентную работу как нагрузку на человека и бюджет; admission control, WIP, stop rules, пакетное ревью.

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

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

Было: aw-query.js считает время приложений/проектов и может назвать старое 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 — frontmost window + AFK как основа, свежесть, интервалы, исключить lock и старые bucket из Now; проверить установленное VS Code расширение, обновить README.md, диагностировать старый DDG URL watcher в DDGWatcher.swift и Xcode watcher только если их данные нужны для связки. 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 — регулярный refresh моих PR, CI failures, approvals/changes requested, review comments и полного списка PR на моё ревью, не только unread notifications; 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 и соответствующие playbooks обновить для advisor/manager/reviewer и контроля агентов; 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 выпускал daily brief по часам и inbox каждые 30 минут; daily-brief.md требует длинный фиксированный формат. Пробный attention.md короче, но всё ещё список событий без плана нагрузки и состояния фокуса.

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

Правки: новый focus-policy.js (классы состояний, quiet hours, исключения); day-coordinator.js (динамический выбор после перехода); 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 заменить обязательные trivia, overdue dump и «easiest first» правилом краткой карточки с capacity/reason; 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. Система хранит correction с причиной и меняет следующий план: неверный сигнал удаляет ложное правило, «слишком много» уменьшает объём, пропуск карточки не порождает дополнительных напоминаний. Личные оценки остаются локальными и не становятся performance-метрикой.

Правки: migrations/003_focus_core.sql для focus_feedback; новый focus-feedback.js; 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 логирует usage из ResultMessage/провайдера и прерывает по budget, не выдаёт max_turns за успех; executor/executor-runner.sh в будущей замене/адаптере ограничивает 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: существующие записи найти через фактический источник учётной записи; импортировать одну прошлую встречу в meeting_context с участниками, решениями, обещаниями, сроками и ссылкой/фрагментом. Обязательства попадают в рабочий контекст, подтверждённый вклад — в карьерный; это влияет на план после встречи, а не создаёт ещё один длинный brief. Затем идемпотентный импорт новых. Новый адаптер zoom-import.js и миграция meeting_context; метод доступа выбирается после проверки аккаунта, старую заметку personal/projects/personal-os/zoom-ai-transcript-export считать вариантами, не доказанным текущим доступом. Приёмка: одна существующая встреча даёт проверяемое обязательство и/или факт вклада со ссылкой, повторный импорт не создаёт дубль.
• iPad Desk: установка на физический iPad уже подтверждена. Передать агенту ограниченное приложение «фокус сейчас / вместимость дня / когда вернуться / одно ожидание меня / свежесть», читающее focus.json по LAN с минимальными полями. iPad — пассивный интерфейс того же контура; не проект по повторной проверке установки. Приёмка: на iPad виден тот же focus state, после отключения сети ясно показана устаревшая версия; нет лишних алертов.

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

1. Сейчас — утверждена миссия, план предложен. Отдельная read-only задача аудирует, какие источники реально доступны и чего не хватает Asana/GitHub/browser/worktree/agent adapters. По её результату уточнить конкретные правки P0.1 и показать Алексу изменения до включения сборщиков. Границы рабочего дня, начальные лимиты reviewer/tokens и канал карточки согласовать перед пилотом; добровольная энергия/настроение не обязательны.
2. P0.1 — блокер фактов: после аудита собрать тихую временную линию человека/агентов/рабочих тем, проверить привязки к Asana/PR/meeting/worktree и честно показать неизвестные интервалы. Проверить 20 интервалов и два дня без новых сообщений Алексу.
3. P0.2 — затем блокер решений: выбрать посильную работу из Asana, PR, TD, Ship Review, встреч, team growth и агентных ревью по роли, пользе, сроку, энергии и доступному времени; испытать перегруженный день до включения schedule.
4. P0.3 → P0.4: показать один короткий живой focus state, провести 5 рабочих дней измеряемого пилота с возможностью исправить перегрузку. Только после этого решать о регулярной доставке.
5. P1 и параллельные ветки: включить ограниченный coding loop с учётом review/tokens; импортировать Zoom; отдать тот же focus state на iPad. Balda/Broker/Virfield не дублировать.

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