obsidian-vault/personal/projects/personal-os/project-truth-analyzer.md

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 закрыта; комментарий Alex от 2026-09-30 объясняет, что Xcode 27 / Swift 6.4 swiftbuild компилирует существующие Core Data модели в SPM, поэтому конверсия больше не нужна. Открыта cleanup task 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 — отдельная работа по сборке браузера как Swift package; 2026-10-02 его закрыли и вновь открыли, сейчас он Draft. Его нельзя использовать как доказательство реализации code-initialized models. Закрытый PR #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 идут параллельно, без дополнительных уведомлений.