# Personal OS — актуальное состояние проектов

Статус: **запланированный P0-слой, не реализован** · 2026-10-04

## Зачем

Focus, дневной план, подготовка к career advisor call и карьерная память должны читать одно проверенное состояние каждого проекта. Сейчас эти сценарии независимо собирают фрагменты из Asana, GitHub, Zoom и Obsidian и могут принять закрытую альтернативу за реализованную работу.

## Контракт

- Локальный read-only сбор событий по каждому проекту: Asana parent/subtasks и комментарии, GitHub PR/commit/review, Zoom решения, текущая проектная заметка. Связывать точными ID/URL и временем. Сырой транскрипт не дублировать.
- Сохранять `project_id`, `work_item_id`, `claim`, `state` (`proposed|approved|cancelled|implemented|verified|released|conflict|unknown`), `event_time`, `observed_at`, `source_ref`, `scope`, `supersedes`, `confidence`, `open_questions`. Состояние задачи в Asana и состояние технического решения — разные поля.
- При конфликте проверять последовательность: предложение → явное решение/отмена → код и PR → проверка сборки. Более поздний явный комментарий об отмене перевешивает раннее предложение и checkbox `completed`; событие закрытия PR не доказывает текущий статус — нужно проверить последующее reopening; Draft PR не доказывает merge или внедрение. Если подтверждения недостаточно, выводить `unknown/conflict` со ссылками, без уверенной формулировки.
- Публиковать краткий `project_state`: цель, принятые и отменённые решения, реально внедрённое и проверенное, открытые пункты, кто/что ждёт Алекса, свежесть и ссылки. Пересчитывать при новых событиях и периодически. Производные агенты используют этот снимок и проверяют его свежесть, прежде чем утверждать текущий статус.
- Карьерный факт отделять от результата реализации: предложение, исследование и корректный отказ после новых данных могут быть вкладом; внедрение заявлять только по подтверждённому коду/проверке. Подготовка к звонку и другие brief-сценарии должны ссылаться на `project_state` и блокировать противоречащие ему claims.

## Первая приёмка: VSCode/SPM migration

1. Zoom Apple Weekly 2026-09-29: Alex представил **предложение** о code-initialized Core Data models, не результат внедрения.
2. [Asana subtask 1218854852229979](https://app.asana.com/0/0/1218854852229979) закрыта; комментарий Alex от 2026-09-30 объясняет, что Xcode 27 / Swift 6.4 swiftbuild компилирует существующие Core Data модели в SPM, поэтому конверсия больше не нужна. Открыта [cleanup task 1218987523298563](https://app.asana.com/0/0/1218987523298563) для удаления runtime test hacks.
3. [[work/projects/vscode-migration/vscode-migration]] помечает модели в коде **Cancelled** 2026-10-01. Существующие `.xcdatamodeld` и codegen classes остаются ресурсами пакета; `.momd` читается из `Bundle.module`, сборка проверена на Xcode 27.2. См. [[work/projects/vscode-migration/findings]].
4. [GitHub PR #7080](https://github.com/duckduckgo/apple-browsers/pull/7080) — отдельная работа по сборке браузера как Swift package; 2026-10-02 его закрыли и вновь открыли, сейчас он Draft. Его нельзя использовать как доказательство реализации code-initialized models. Закрытый [PR #6976](https://github.com/duckduckgo/apple-browsers/pull/6976) касается AssetCatalogPlugin.
5. Итоговый статус для всех потребителей: **code-initialized Core Data models — cancelled; действующие модели сохранены и совместимы с Xcode 27 build system; cleanup test hacks — open**. Карьерный факт: Alex исследовал и представил альтернативу, затем изменил решение на основании новой возможности toolchain.

## Порядок реализации

1. **Реестр и схема.** Добавить `migrations/004_project_truth.sql` с `project_events`, `project_states` и свежестью источников; завести явную карту VSCode/SPM → Asana parent/subtasks, GitHub repo/PR, Zoom note ID, Obsidian project note. Событие хранит отдельные поля для состояния задачи и состояния технического решения.
2. **Read-only сбор.** В `project-evidence.js` читать Asana tasks/stories из локального mirror, текущий статус связанных PR из GitHub, сохранённые Zoom JSON и проектную заметку. Писать датированные события с точными ссылками и `observed_at`; дубли убирать по source ID. Недоступный источник помечать stale/failed, не считать его пустым.
3. **Сверка.** В `project-truth.js` строить `project_state` по последовательности proposal → later decision/cancellation → actual code/PR → verification. Явная отмена перекрывает предложение; Asana completed не означает implemented; GitHub close → reopen даёт текущий Draft. Неразрешённое противоречие — `conflict` со ссылками.
4. **Подключение потребителей.** Включить `project_state` в `source-snapshot.js` и локальный `~/context/projects.json` (0600). `day-coordinator.js` и advisor/career prompts читают эту проекцию; утверждения «внедрено/выпущено» без evidence и свежего статуса блокируются. Интеграция остаётся без записи в Asana/GitHub и без уведомлений.
5. **Приёмка.** `node --test test/project-truth.test.js`: Zoom proposal 29 сентября → отмена 30 сентября/1 октября → существующие `.xcdatamodeld` в SPM → PR #7080 close/reopen/Draft → cleanup open. Дополнительно проверить stale source и конфликт; выполнить один тихий shadow-прогон. Только после этого расширять карту на другие проекты. Shadow-калибровка и Zoom/iPad идут параллельно.