Аудит реализации Personal OS 13 ноября 2026

Вердикт: Personal OS ещё не готова к полной приёмке. Ожидание пяти дней пилота не является единственным оставшимся этапом. Работают отдельные сборщики, доказательства действий, локальный UI и ограниченное ранжирование. Общий процесс теряет обязательства, не закрывает большинство типов выполненных действий и не обеспечивает главные цели нагрузки и фокуса.

Основание — действующая миссия: самочувствие → посильная нагрузка и непрерывный фокус → граница рабочего дня → рабочие и карьерные результаты. Аудит охватил сбор, анализ, организацию действий, E4/E5, исполнение, UI, историю, уведомления и приёмку. Три независимых субагента проверили приоритизацию, обработку обсуждений и эксплуатацию; результаты сверены с кодом и рабочими состояниями.

Срез рабочего дерева: ветка windmill-system-map, HEAD 38cfd9c5e64f19f7997a0d01ff0619a78da21596, с существующими незакоммиченными изменениями. Проверялось фактическое дерево, а не только этот коммит. Рабочие состояния прочитаны около 18:00–18:10 по Бишкеку. Код, расписания, очереди и внешние источники в рамках аудита не изменялись. Изменения этого аудита ограничены документацией.

Что подтверждено на действующей системе

E5 01a1d470-7d26-e29e-8d8e-516b00c03661 завершился успешно. Проверка через wmill job get --workspace personal_os --json подтвердила Next TP и действия без Asana. Вход содержал заранее подготовленные packet, proposal, role_profile, priority_policy, refresh_sources=false. Это реальное исполнение опубликованного flow на сохранённом входе; оно не проверяло самостоятельный сбор и модельное получение действий с нуля.
В Windmill включены два расписания: Asana и work_claims_extract. E4/E5/Weekly Review собственного расписания там не имеют. Дневной UI обновляет LaunchAgent через run-focus-shadow.sh → локальный acceptance-plan.py, использующий Python-модули E4/E5. Это отдельный рабочий путь.
API плана на 17:55 по Бишкеку: 2 действия — CPM 1‑Must и Next TP; 8 в отложенной очереди; 30 минут действий и 20 минут резерва при сокращении оставшегося дня. В очереди обсуждений: 8 открытых и 3 на проверке.
Пилот: 18 наблюдений, 1 день с ограниченным планом, 0 принятых дней. Вечерняя сверка в момент чтения ещё не открыта. Реальная доставка вечернего уведомления этим аудитом не проверена.
Asana, корпоративный Mattermost, GitHub в focus-shadow и ActivityWatch имеют свежие наблюдения. Старый вывод «Mattermost требует входа» больше не описывает этот срез. При этом SQL-зеркало GitHub имеет последний fetched_at 18 октября: два потребителя читают разные по свежести представления.
В PostgreSQL 12 548 work_claim_entities имеют статус candidate, ручных work_claim_reviews — 0. Историческая таблица work_claims отдельно содержит 12 244 candidates; эти числа нельзя складывать как уникальные утверждения.
По последнему job на каждую work_id, выбранному через DISTINCT ON (work_id) ORDER BY created_at DESC: blocked 261, succeeded 72, superseded 56. Среди последних блокировок: 199 отказов соединения с моделью, 43 слишком больших пакета, 13 ошибок буквальной цитаты. Все исторические blocked-запуски — 2003 записи по 287 работам; это не 2003 одновременно заблокированные работы.
В day_state и focus_feedback нет записей. Текущий focus сообщает capacity=unknown, agent_review_queue=unknown, delivery=none. В reviews.json два черновика Next TP ожидают ревью.

Дефекты с приоритетом P1

P1 означает необходимость исправления до заявления о полном рабочем процессе. Это не утверждение об аварии или потере исходных данных.

A01. Адресные запросы Mattermost теряются до анализа. scripts/build-discussion-packets.js:128 допускает обсуждение при участии пользователя либо при упоминании с единственной ссылкой на PR. Изолированный запуск настоящего сборщика: «@alex please publish the recap» без ответа пользователя дал 0 пакетов; после «OK» — 1; прямое PR-ревью — 1. Входящий запрос не должен зависеть от предварительного ручного ответа. Исправление: сохранять адресные запросы всех поддерживаемых типов как кандидаты, отдельно проверяя адресата и действие. Приёмка: рекап, решение, документ и встреча проходят без ответа пользователя; FYI не становится обязательством.

A02. Подтверждённые действия теряются перед E4. scripts/acceptance-plan-input.js:36 пропускает из обсуждений лишь update_design/update_pr/publish_recap; review_pr/implement исключены. Asana-ветка пропускает ответы и follow-up, но не общий список назначенных работ и всех запросов review/unblock. В рабочей очереди есть открытое обещание финального ревью PR #8095 (0bc386e44b46ac076f72fcdd); в свежем GitHub review_requests его нет, в двух пунктах плана и восьми отложенных — тоже нет. Модельная ветка propose_actions.py:119 дополнительно выбирает максимум шесть работ по старой эвристике до E4. Исправление: полная каноническая очередь перед ранжированием; любое исключение получает причину, ограничение размера применяется после оценки либо с доказанным покрытием. Приёмка: PR #8095 и все поддерживаемые категории доходят до E4, удержания или отложенного списка.

A03. Большинство действий не имеет пути к подтверждённому завершению. discussion_actions.py:161 требует verified_completions. Штатный build-discussion-packets.js:33 и :178 создаёт их лишь для review и Next TP. Для publish_recap/update_design/update_pr/implement такого адаптера нет. На изолированном входе опубликованный рекап с точной цитатой и модельным fulfilled остаётся open с completion_needs_verified_artifact. Положительный тест вручную подставляет подтверждение и не проверяет производство этого подтверждения. UI не даёт общего решения «принять/отклонить/отменить/закрыть» для обсуждённого обязательства. Исправление: проверяемый результат для каждого типа и ручное разрешение неопределённости с журналом. Приёмка: опубликованный рекап закрывается, посторонний комментарий не закрывает, изменение/отмена распространяется в план.

A04. Самочувствие не влияет на штатный план с явным бюджетом. acceptance-plan.py:114 использует подтверждённые минуты, не применяя energy/lighter_today. Воспроизведение настоящего main с изолированными чтениями/записями: энергия 1 и облегчённый день дали те же 15 минут выбранной работы и 27 минут резерва, что энергия 5; даже focus_minutes=0 не изменил результат при explicit 90. Ограничение отдельных shadow-подсказок в day-coordinator.js:24 не передаётся этому плану. Исправление: единый контракт текущей ёмкости с пользовательским снижением нагрузки и пересчётом. Приёмка: добровольный сигнал низкой энергии уменьшает допустимую нагрузку; «перенести/слишком много» влияет на ту очередь, которую показывает My Tasks.

A05. Сумма свободных минут подменяет доступные окна. acceptance-plan.py:16 вычитает встречи из общей суммы; day_constraints.py:247 проверяет лишь суммарный бюджет. Воспроизведение: день 14:00–16:00, встреча 14:20–15:40 → два окна по 20 минут, но допускается непрерывное действие на 25 минут при 30% резерве. Встречи читаются лишь по шаблону регулярного 1:1 в Asana (source-snapshot.js:23); Outlook даёт только оконную активность. Исправление: сохранять интервалы и минимальный непрерывный размер действия, различать дробимые задачи, подтверждать охват встреч Asana/Outlook. Приёмка: 25-минутное неделимое действие не помещается в два отдельных 20-минутных окна. Неизвестные встречи не объявляются отсутствующими. Apple Calendar не является требуемым источником.

A06. E4 частично оценивает цели и ответственность. priority_input.py:23 связывает задачи с целью только по самой задаче и непосредственному родителю. Подзадача второго уровня в воспроизведении теряет AoR. Карьерные направления загружаются, но штатные действия не получают обоснованных career goal_matches; доли 60/20/15/5 сохранены в политике и не регулируют недельную очередь. Роли записываются, но не определяют порядок участия. SAM корректно ограничена Native Apps по GID; общей матрицей всех задач её считать нельзя, отсутствие универсальной шкалы в Asana не требует выдумывать её. Числовой DDG Severity Value намеренно не заменяет SAM category — само по себе это не дефект. Исправление: наследование по проверенному графу, связь с актуальными целями и ролью, отдельная политика для небаговых задач, недельная проверка перекосов.

A07. Конфликт обязательного срока и важности не решён явно. rank.py:55 принимает hard_deadline из входного действия, но штатная выборка этот признак не выводит из авторитетного обязательства. В сортировке SAM major/minor стоит раньше обязательного срока; воспроизведение поставило Major без срока перед hard-today и 1‑Must. Такое исключение может быть верным для инцидента, но сейчас оно применяется без оценки конфликта и без явного решения о переносе обещания. Исправление: различать срок задачи и подтверждённое обязательство, показывать невозможность выполнить оба, использовать утверждённое правило эскалации. Приёмка: конфликт инцидента, сегодняшнего обещания и 1‑Must виден, проигравшее обязательство не исчезает молча.

A08. Готовые результаты агентов не создают доставляемый запрос ревью. day-coordinator.js:37 возвращает unknown/none, observe-acceptance-pilot.py:203 лишь записывает draft_reviews. Подключённый notifier обслуживает вечернюю сверку, не готовый артефакт. Два waiting_review сейчас требуют самостоятельного открытия UI. Общего worker-пути от ai_preparations E5 до исполнения и повторной проверки также нет в flow; отдельная подготовка Next TP запускается CLI. Исправление: результат → очередь человеческого ревью с бюджетом → уведомление в разрешённое окно → решение → обновление плана. Приёмка: артефакт обнаруживается без ручного опроса, уведомление не дублируется и не прерывает защищённый фокус, отклонение запускает управляемую переработку.

A09. План того же дня может выглядеть актуальным после отказа пересчёта. db-browser.js:925 проверяет дату и рабочую границу, но не возраст/ошибку последнего обновления. run-focus-shadow.sh:44 оставляет предыдущий файл при ошибке; endpoint изменения ёмкости возвращает saved=true/plan=null. Аналогично вход доверяет строке fresh в shadow без повторной проверки возраста. Это подтверждено кодом, production outage не создавался. Исправление: версия и срок действия входов/плана, явный degraded и запрет выдавать старое как текущее после существенного изменения. Приёмка: ошибка API после утреннего успеха отражается днём в UI вместе с последним достоверным временем.

A10. Зачёт пяти дней не доказывает достижение миссии. observe-acceptance-pilot.py:75 принимает день при формальной готовности, подтверждении ёмкости и нулевых missed/false_closures/after_hours. Состояния источников, достаточность наблюдений, переключения и review_minutes не являются критериями успеха. Изолированно зачтён день с двумя снимками без данных активности; отдельно — с 1440 минутами ревью, 1440 переключениями и ошибками источников. Это дефект критерия, не результат реального рабочего дня. Исправление: учитывать покрытие, явные пропуски измерений, добровольную оценку посильности и сравнение с исходным уровнем нагрузки. Порог улучшения требует согласования; выдуманный числовой KPI не подставляется. До исправления пять формально зачтённых дней недостаточны для выпуска.

Дефекты P2 и ограничения эксплуатации

A11. Zoom не обновляет уже известные заметки. zoom-browser-sync.js:95 и :145 пропускает импортированные датированные ID до чтения содержимого. Сейчас известных ID — 19. Поздний полный транскрипт, исправление речи и автора не попадают в систему. Исправление: повторное чтение недавних/изменившихся заметок по версии. Отдельно подтвердить охват Owned/Shared и пагинации; успешный запуск не доказывает полноты всех встреч.

A12. Перепривязка к Asana меняет ID обязательства. ID зависит от work_id (discussion_actions.py:185), reconciliation ограничен одной work_id (publish-discussion-actions.py:44). Изолированная публикация одного обещания сначала unlinked, затем linked дала две карточки с одинаковым источником. В рабочем срезе такой точный дубль не найден. Исправление: каноническое действие независимо от проектной привязки, перенос/alias со всей историей. Два близких CPM design-action не объявляются доказанным дублем: их цитаты описывают разный по широте объём.

A13. Work History теряет историческую связь с проектом. work-history.js:52 ищет коммит по текущим PR/HEAD, игнорирует tree.work_ids и PR из архивного снимка. Два изолированных случая вернули repo-группу вместо известной Asana-задачи. Исправление: использовать подтверждённую связь на дату события; смена HEAD/закрытие PR не переписывает историю.

A14. Отклонённый Next TP draft не перерабатывается. priority-handoff.py:60 возвращает прежний артефакт по хешу источника и метода, включая rejected. Причина отказа не становится новым входом. Подтверждено на временной SQLite. Исправление: новая ревизия с feedback, ограниченными повторами и предыдущим решением в контексте. Старые waiting_review также не должны оставаться активными после замены новой ревизией.

A15. Пропущенная вечерняя точка не восстанавливается. observe-acceptance-pilot.py:145 проверяет только сегодняшний план. Пятничный день без финального снимка при запуске в понедельник не становится доступным к сверке. Исправление: отдельный статус неполного дня с восстановлением по имеющимся свидетельствам и честным незачётом при недостатке данных.

A16. Next TP имеет узкий механизм обнаружения и слабую проверку автора закрытия. build-discussion-packets.js:154 зависит от вручную проверенной связи Zoom с career advisor, реестра TP и ограниченного поиска. В :46 допускается created OR assigned, затем :180 обе ветки маркируются автором alex. Назначение задачи не доказывает публикацию треда этим человеком. Приёмка: другой автор и последующее назначение не закрывают обещание; новая встреча/кандидат не требуют ручного дописывания кейса в код.

A17. Анализ и проектная правда остаются разрозненными. Последний claim job blocked у 261 работы, все сущности candidates; обсуждения не входят в тот же lifecycle claims. SQL GitHub старый, shadow свежий. При этом source-snapshot.js:201 продолжает вызывать прежний project-evidence с ручным реестром двух проектов, несмотря на пометку README об удалении этого прототипа из рабочего контура. Исправление: единые версии/состояния источников и принятия, обработка заблокированных работ по причине, общий контракт проектного состояния. Не требуется включать неподтверждённые claims в план ради увеличения охвата.

Соответствие GTD и практикам руководства

Сопоставление использует пять шагов GTD, выбор действия и Weekly Review. Это оценка пригодности процесса, а не требование реализовать каждый термин GTD в интерфейсе.

Capture — частично. Сохраняются источники, версии и часть открытых циклов. Теряются адресные запросы; свежий импорт не равен полному охвату.
Clarify — частично. Есть проверка цитаты и автора. Шесть типов действий не охватывают решения, сбор информации, организацию встречи и общий следующий физический шаг. «Открыть задачу и сверить следующий шаг» полезно как уточнение, но не заменяет исполнение всего 1‑Must.
Organize — частично. Есть My Tasks и отдельные ожидания E5. Нет единого устойчивого Waiting For с ответственным и датой проверки; Someday/Maybe и отменённое не имеют полноценного обзора. Статус optional сохранён в данных, но исключён из обычных open/closed списков. Есть карточки needs_review без действия для разрешения.
Reflect — не замкнуто. Дневник приёмки не выполняет обзор всех проектов, ожиданий, отложенного и ближайших обязательств. Старые weekly-prompts существуют, но рабочий Weekly Review с результатом и обновлением очередей не подтверждён. Windmill retrospector остаётся stub.
Engage — частично. Есть объяснимая часть порядка и предел времени. Текущий выбор не учитывает полный набор действий, энергию, непрерывные окна и фактический человеческий WIP.

Horizons of Focus связывает следующие действия, проекты, сферы ответственности и более высокие цели. Здесь миссия описана, но её верхние ограничения не проходят до решения E5; career/AoR присутствуют в профиле без полного влияния на выбор. Недельные доли времени не являются матрицей важности задач.

DRI и DACI полезны для различения владельца результата, исполнителя следующего шага, участника и принимающего решение. Сейчас преобладает executor; помощь команде, делегирование, принятие решения и адресаты рекапа не образуют общего рабочего контура. Leadership-результат следует подтверждать решением, эффектом и обратной связью, а не количеством комментариев или временем кодинга.

Kanban требует явного начала/завершения и контроля незавершённой работы. Ограничение «до трёх действий» не ограничивает уже запущенные человеческие и агентные работы. Нужны наблюдаемые состояния работы, лимит текущего участия и время ожидания ревью. Защита фокуса должна применять эти ограничения до запуска очередной подготовки, а не после накопления результатов.

Проверки и пределы результата

Python: priority_assessment — 3, daily_planner — 26, acceptance_pilot — 2, discussion_actions — 7; все прошли. Команды: python3 -B -m unittest discover -s test -p 'test_priority_assessment.py' и аналогично для следующих двух файлов; python3 test/test_discussion_actions.py -v.
Node: discussion-context/work-claim-updates/mattermost-client/zoom-browser-ingest — 33 прошли, 10 DB-интеграций пропущены; zoom-browser-sync — 3; day-coordinator/work-history/local-work-progress — 11; work-demand — 6. Запуск через node --test соответствующих test/*.test.js. Повторный запуск day-coordinator не посчитан второй раз.
Всего 91 уникальный выполненный тест прошёл, 10 пропущены. bash -n scripts/run-focus-shadow.sh прошёл. Пограничные воспроизведения A01–A05, A10, A12–A15 выполнены отдельно на временных входах, SQLite или подменённых внешних чтениях. Они не были добавлены как постоянные тесты в рамках read-only аудита.
Реальные проверки: GET локального UI API, READ ONLY PostgreSQL, чтение файлов и завершённого Windmill job, список Windmill schedules. Модельные ответы для синтетических lifecycle-кейсов заданы явно; это проверка кода обработки, не новое измерение качества LLM.
Полный новый цикл live capture → inference → действие → реальный результат → закрытие здесь не запускался. Outlook invitation parity, реальная доставка вечернего уведомления, пять рабочих дней, восстановление всей системы из backup и полноценная проверка безопасности не приняты этим аудитом. В коде UI подтверждены loopback, CSP и проверки Origin/header для POST; это не заменяет security-аудит.

Очередность исправления и повторная приёмка

Целостность очереди: A01–A03, A11–A12, A16. Сквозные кейсы всех типов, входящий запрос без предварительного ответа, completion/cancellation/reopen, перенос между проектами без дубля. Отдельный регрессионный кейс PR #8095.
Соответствие миссии: A04–A07. Единый пользовательский ввод энергии/режима/границ, полные окна Asana/Outlook, роли и граф целей, конфликт срочности/обещаний, недельное внимание AoR/Career/Strategy.
Исполнение и обратная связь: A08, A14. Общая очередь запусков/результатов/ревью, бюджет человеческого участия, доставка, повтор с учётом отказа. Каждый артефакт имеет текущую ревизию, источник и проверяемый результат.
Доверие и восстановление: A09, A13, A15, A17. Актуальность входов, наблюдаемость деградации, устойчивые исторические связи, восстановление пропущенных снимков и blocked-работ.
GTD Reflect и приёмка: Weekly Review изменяет действующие списки, а критерии A10 измеряют миссию. Затем повторный независимый аудит, сквозной прогон без заранее подставленного proposal и пять реальных дней по исправленному критерию. Исторические наблюдения сохраняются, но не повышаются автоматически до доказательства готовности новой версии.

Этот порядок является результатом аудита. Исправления реализации, публикации и перезапуски в рамках данного поручения не выполнялись.

33 KiB Raw Blame History Unescape Escape