obsidian-vault/personal/projects/personal-os/personal-os-implementation-audit-2026-11-13.md

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

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

Основание — действующая [миссия](/Users/admin/obsidian/personal/projects/personal-os/personal-os-purpose.md): самочувствие → посильная нагрузка и непрерывный фокус → граница рабочего дня → рабочие и карьерные результаты. Аудит охватил сбор, анализ, организацию действий, 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](https://gettingthingsdone.com/what-is-gtd/), [выбор действия](https://gettingthingsdone.com/2023/01/choosing-what-to-do/) и [Weekly Review](https://gettingthingsdone.com/wp-content/uploads/2014/10/Weekly_Review_Checklist.pdf). Это оценка пригодности процесса, а не требование реализовать каждый термин 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](https://gettingthingsdone.com/wp-content/uploads/2014/10/2016-Horizons-of-Focus.pdf) связывает следующие действия, проекты, сферы ответственности и более высокие цели. Здесь миссия описана, но её верхние ограничения не проходят до решения E5; career/AoR присутствуют в профиле без полного влияния на выбор. Недельные доли времени не являются матрицей важности задач.

[DRI](https://handbook.gitlab.com/handbook/people-group/directly-responsible-individuals/) и [DACI](https://www.atlassian.com/team-playbook/plays/daci) полезны для различения владельца результата, исполнителя следующего шага, участника и принимающего решение. Сейчас преобладает executor; помощь команде, делегирование, принятие решения и адресаты рекапа не образуют общего рабочего контура. Leadership-результат следует подтверждать решением, эффектом и обратной связью, а не количеством комментариев или временем кодинга.

[Kanban](https://kanbanguides.org/the-kanban-guide) требует явного начала/завершения и контроля незавершённой работы. Ограничение «до трёх действий» не ограничивает уже запущенные человеческие и агентные работы. Нужны наблюдаемые состояния работы, лимит текущего участия и время ожидания ревью. Защита фокуса должна применять эти ограничения до запуска очередной подготовки, а не после накопления результатов.

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

- 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-аудит.

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

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

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