Personal OS — порядок запуска и конкретный P0

Статус: план для согласования. Код, внешний доступ и автозапуск этим документом не меняются. Этот документ заменяет выводы черновика planning/agent-system-priority-plan-2026-10-03.md о якобы запущенном расписании и готовом безопасном iPad-фиде.

Что нужно Алексу сейчас

Один короткий, достоверный список новых обязательств и блокеров с причиной, ссылкой и временем проверки источника. Система сама собирает и проверяет данные, запоминает вклад для карьеры и улучшает себя через ограниченные агентные циклы. Алекс видит только решение, требующее его участия; ежедневное планирование за него не навязывается. Основание: personal-os-purpose — пропущенные комментарии, отложенные карьерные задачи и потеря контекста после переключений.

Порядок работ

P0 — надёжный рабочий сигнал. Довести существующие Asana/GitHub → локальное зеркало → attention до состояния, где каждый срочный пункт подтверждён источником, сбои видны, повторения и исторический шум убраны. После согласования конкретных правок ниже включить ограниченный автоматический запуск. Результат для Алекса: меньше ручных проверок Asana/GitHub и меньше пропущенных ответов.
Параллельно — автономная разработка. Codex/Claude берут небольшую согласованную задачу, работают в отдельном worktree, собирают/проверяют, исправляют ошибки, возвращают diff, результат проверки и точный блокер. Первый пакет — качество attention и импорт Zoom. Balda/Broker/Virfield уже развиваются отдельно и не являются условием запуска P0.
Параллельно — существующие Zoom-записи. Найти фактический источник записей в доступном Zoom-аккаунте (пустой ~/Documents/Zoom ничего не доказывает), импортировать одну существующую беседу: обязательства и решения в рабочий профиль, подтверждённый вклад в карьерный. Каждый факт со ссылкой на встречу и фрагмент; затем идемпотентный импорт новых записей. Результат: обещания и доказательства вклада не приходится вспоминать вручную.
Параллельно — iPad Desk. Агент берёт тот же ограниченный feed, показывает пункты, свежесть источников и отсутствие связи. Физическая установка приложения на iPad уже подтверждена Алексом; задача — реализовать и доставить полезный экран через имеющийся Mac Monterey/Xcode 13 и подтверждённый путь установки. При необходимости Codex CLI на Mac или управление сборкой по SSH. Результат: рабочий интерфейс без новой ручной процедуры для Алекса.

P0: факты текущего состояния

Факт	Подтверждение	Последствие
Однократная синхронизация и генерация `attention.md/json` прошли 3 октября: 4 комментария, 4 запроса на ревью, 2 блокера PR, 5 текущих задач.	`generate-attention.js`, локальный `~/context/attention.md`	Данные доступны; это один успешный прогон, а не доказательство надёжного фонового режима.
Новый `com.personalos.readonly` не загружен в `launchd`; установленный plist переименован в `.disabled` после требования остановить изменения.	Проверка `launchctl print gui/501/com.personalos.readonly` 3 октября: service not found; `run-readonly.sh`	Автономного обновления сейчас нет. Запуск — отдельный согласуемый шаг после исправлений.
Старый `status.md` маркирует 20 самых старых просрочек как красные сигналы; комментарии берёт из всех активных задач за 7 дней, даже если не доказано, что ответ нужен.	`getOverdueTasks`, `getUnreadComments`, `renderSignals`	Красная очередь содержит исторический шум и чужие обсуждения.
Пробный `attention` сужает задачи до моих, но объявляет комментарии «Ответить» по признаку «после него нет моего ответа». Отсутствие ответа не доказывает потребность отвечать; один и тот же объект может попасть в две секции.	`buildAttention`, `renderMarkdown`	Алекс снова вынужден вручную проверять достоверность очереди.
GitHub review requests выбираются из непрочитанных participating notifications; ошибки запросов превращаются в пустые массивы. Общая метка свежести берётся только из Asana.	`gh-snapshot.js`, `getGithubSnapshot`, `buildAttention`	Прочитанный запрос или сбой GitHub может исчезнуть из очереди без предупреждения.
«Защита» iPad-фида сейчас — regex только по `title/detail`, а выдача ограничена пятью элементами на секцию без числа скрытых.	`safeItem`, `MAX_ITEMS`	Фид ещё нельзя считать безопасным для iPad или полным.

P0: точные изменения — что на что

№	Было → станет	Конкретная правка	Как это улучшит день
1	Общая дата Asana и тихая пустота GitHub → статус каждого источника: `ok/failed/stale`, `fetched_at`, ошибка без секретов.	В `sync.js` и `gh-snapshot.js` сохранять результат каждого источника; в `generate-attention.js` добавлять `sources`. При сбое оставить последний успешный снимок с пометкой «устарел», не писать «нет сигналов». Файлы обновлять атомарно.	Пустой экран больше не означает ложное «всё спокойно».
2	«Любой чужой комментарий без моего ответа = ответить» → `нужен ответ / нужна проверка / FYI` с явным правилом.	Считать кандидатом прямое назначение, явное упоминание или комментарий на собственной активной задаче; исключать ботов/широкие AOR-потоки. Для `нужен ответ` требовать конкретный запрос/вопрос, отсутствие более позднего ответа и ссылку на комментарий. Неуверенный текст — в «проверить», без срочного пуша. Реализовать в запросах `generate-status.js`/`generate-attention.js` и общем классификаторе.	Реально ожидающие люди видны; шум не вынуждает открывать каждую задачу.
3	Древние просрочки первыми, фиксированные `slice(0,5)`, дубли → ранжированная очередь событий.	Срок сам по себе не делает пункт срочным. Поднимать свежие обращения и блокеры, затем ближайшие сроки активных приоритетов; старые просрочки — отдельная уборка. Дедупликация по `source+object_id`, устойчивый `signal_id`, `new_since`, `acknowledged`, `dismissed`, счётчик остальных. `ack/dismiss` только в локальной БД.	В коротком списке видно, что изменилось с прошлого просмотра; один пункт не занимает два места.
4	GitHub только через unread notifications → текущие назначения и реальные блокеры PR.	Запрашивать открытые PR с `review-requested:@me` и проверять текущего reviewer; отдельно `CHANGES_REQUESTED`, failing CI и неразрешённые review threads у моих PR. Исторические Executor PR исключать по идентификатору/происхождению, а не только по префиксу заголовка. Ошибку API показывать в статусе источника.	Прочитанный запрос на ревью не исчезает, а старый PR не выглядит новой проблемой.
5	Один raw `attention.json` с regex → два явных выхода: локальный полный и минимальный iPad.	Типизированный feed: `signal_id`, `source`, `source_updated_at`, `detected_at`, `kind`, `urgency`, `reason`, `evidence_url`, `state`; iPad получает только разрешённые поля после allowlist и проверки чувствительности до передачи. Локальный feed не уходит в облачную модель/Mattermost по умолчанию. Агент разработки не получает Asana PAT.	iPad показывает полезный контекст, а рабочие детали остаются в разрешённой границе.

Как это работает после P0

Локальный сборщик читает Asana/GitHub, сохраняет последний успешный снимок и отдельный статус каждого источника. Внешних записей нет.
Детерминированный классификатор сравнивает новый снимок с предыдущим, выдаёт сигналы с причиной и ссылкой; отделяет «требует действия» от «проверить».
Локальная очередь убирает дубли, помнит просмотренное/отклонённое и показывает первые пять по важности плюс число остальных; устаревший источник помечается.
Obsidian/локальный экран читают полный feed; iPad получает только проверенный минимальный feed. Агент анализирует разрешённый снимок и приносит конкретные улучшения, не пишет в Asana/GitHub без отдельного решения Алекса.

Порядок внедрения и критерий приёмки P0

Сначала исправить статус источников и границу данных. Проверка: отключённый GitHub отображается как failed/stale; в iPad feed нет запрещённых полей; Asana PAT доступен только процессу синхронизации.
Затем исправить правила комментариев, просрочек и GitHub. Проверка на сохранённых случаях от 3 октября: чужой AOR-комментарий не «срочный ответ»; комментарий с последующим ответом не появляется; прямой неотвеченный запрос появляется со ссылкой; старая просрочка не вытесняет новый блокер; прочитанный review request остаётся до снятия назначения.
Затем включить локальную очередь и короткий экран. Проверка: одна задача — один сигнал; видны новые пункты и число скрытых; ack/dismiss переживает обновление; файлы никогда не бывают частично записаны.
После согласования включить ограниченный фоновой запуск в рабочее время и наблюдать пять рабочих дней. Приёмка: источник обновляется не реже чем раз в 40 минут, пока Mac бодрствует и сеть доступна; каждый срочный пункт имеет актуальное подтверждение; сбой виден; Алекс один раз отмечает ложные срочные сигналы, чтобы внести их в правила.

От Алекса сейчас: согласовать состав P0 и границу данных. Дальше агенты делают изменения, проверяют и показывают результат с diff; к Алексу возвращаются только при смене границ или необходимости внешнего действия. Старый Executor, Hermes и новая запись во внешние рабочие системы этим планом не запускаются.

Связанные материалы

personal-os-purpose — зачем существует система.
personal-os-v2-plan — прежний широкий проектный черновик.
generate-status.js, generate-attention.js, gh-snapshot.js — текущая реализация.

16 KiB Executable File Raw Blame History Unescape Escape