30 lines
6.1 KiB
Markdown
30 lines
6.1 KiB
Markdown
# 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|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. Сделать один read-only вертикальный срез для VSCode/SPM: события → доказательства → актуальная проекция; проверить этот конфликт и событие закрытия с последующим reopening PR.
|
||
2. Ввести gate для advisor brief и карьерного профиля: статус проекта берётся из проекции, claims о внедрении без доказательства отклоняются.
|
||
3. После приёмки расширить на остальные активные проекты и подключить `project_state` к `work_timeline` и `work_demand`. Shadow-калибровка и Zoom/iPad идут параллельно, без дополнительных уведомлений.
|