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

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

Текущий план R2: personal/projects/personal-os/personal-os-system-review-index. Целевая архитектура и порядок реализации ниже заменены R2; исторические решения и описание прототипа сохранены для происхождения требований.

Статус на 2026-10-04: работает только прототип сборщика по двум проектам. ID источников вручную выбрал и внёс Codex; система не обнаруживает проекты и связи сама. fresh означает доступность настроенных источников, а не полную правду о проекте. Обзор briefs/project-truth/current.md написан вручную. Расписание проектного Codex-агента personal-os-project-truth-agent остановлено после создания без разрешения; самостоятельных запусков не было. Вторничная подготовка advisor call остаётся активной по прежнему поручению пользователя, её первый запуск не проверен. PostgreSQL-миграция подготовлена, но не применена.

Фактический data flow прототипа

project-truth-projects.json содержит вручную заданные внешние ID: для VSCode/SPM — Asana parent/две задачи/комментарий, конкретный Zoom note и timestamp, PR #7080, путь к Obsidian-заметке; для CPM — Asana parent и PR #6844/#6951/#7037. Прямые подзадачи CPM подтягиваются из Asana автоматически. Другие проекты, новые PR, комментарии и Zoom-решения автоматически не открываются.

Asana mirror/API, GitHub API, локальный Zoom JSON и Obsidian-заметка → project-evidence.js создаёт датированные события → project-truth.js выбирает последнее событие для каждого указанного предмета и отмечает ограниченные конфликты → source-snapshot.js пишет ~/context/projects.json → focus получает краткую проекцию. Advisor playbook читает этот снимок и проверяет первоисточники. Это детерминированный код, не LLM-анализ проекта. briefs/project-truth/current.md — ручной пример, не выход запущенного агента.

Целевая архитектура (не реализована)

1. Обнаружение: адаптеры перечисляют активные проекты и новые записи из Asana, GitHub, Zoom, Obsidian и задач агентов. В обычной работе никто не вписывает ID каждой задачи/PR/встречи вручную; конфиг содержит только подключения и правила доступа.
2. Связывание: система создаёт стабильную внутреннюю идентичность проекта и связывает материалы сначала по явным URL/ID, затем предлагает смысловые совпадения с доказательством. Неоднозначные материалы остаются несвязанными; название само по себе не подтверждает связь.
3. Журнал доказательств: сохраняются source ID/URL, время события и получения, фрагмент или hash, тип факта, область действия и история изменений. Более позднее решение может отменить раннее; старые факты не удаляются.
4. Анализ агентом: LLM получает пакет одного проекта, ищет поздние противоречия и возвращает структурированные утверждения по отдельным измерениям: proposal, decision/cancellation, implementation, local verification, merge, release, measured impact, open work. У каждого утверждения — evidence IDs, дата, scope, confidence и open questions.
5. Проверка и публикация: код проверяет существование ссылок, свежесть, порядок событий и допустимость переходов. completed не доказывает implemented; merged не доказывает released или эффект. При пробеле или конфликте публикуется unknown/conflict. Версионированный project_state становится единственным входом focus, career и других агентских сценариев.

Первый запуск агентского шага — вручную на VSCode/SPM и CPM с проверкой результата человеком. Расписание и запись во внешние рабочие системы не входят в этот пилот и требуют отдельного решения.

Зачем

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 закрыта; комментарий 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.

Текущий охват и следующий шаг

VSCode/SPM: вручную связаны четыре источника; Core Data code-init отменён, cleanup открыт, PR #7080 Draft. CPM: текущий Asana parent + 19 прямых подзадач и выбранные PR; Zoom-решения, релиз и измеренный эффект не установлены. Следующий инженерный шаг — автоматическое обнаружение проектов и доказуемое связывание новых материалов. Ручной реестр остаётся тестовым fixture до замены. Первый запуск advisor automation 2026-10-06 ещё не проверен.

Исправление прототипа: конкретные этапы

1. Сделано 4 октября: README, Obsidian и playbook исправлены: расписание проектного агента остановлено, current.md ручной, охват частичный. Приёмка: ни один документ не утверждает, что агент уже работает.
2. Добавить discovery и entity linking: перечисление проектов/задач, PR и Zoom notes; явные связи и очередь неподтверждённых кандидатов. Приёмка: новая подзадача и PR появляются без ручной правки JSON; чужой PR не приписывается проекту по похожему названию.
3. Сделать версионированные evidence packets без DB-миграции в пилоте. Приёмка: по каждому выводу видны событие, дата и первоисточник; история отмены не пропадает.
4. Запустить вручную LLM-анализ одного проекта со структурированным JSON-результатом и валидатором. Приёмка: VSCode/SPM показывает proposal → cancellation, не implemented; CPM merged PRs не становятся release/impact.
5. После проверки на двух проектах подключить валидированный project_state к advisor/focus и отдельно решить, нужен ли регулярный запуск. Приёмка: устаревший или конфликтный вывод становится unknown с причиной; первый advisor brief проходит сверку с источниками.