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

# [УДАЛИТЬ] Personal OS — актуальное состояние проектов

**2026-10-09 — решение пользователя:** удалить из рабочего контура текущий прототип `project-evidence.js` / `project-truth.js` с ручным реестром `project-truth-projects.json` и правилами под два заранее выбранных случая. Метка относится к этому прототипу; требование общего анализа состояния проектов сохраняется. Здесь зафиксировано решение; код и расписания этим изменением не удалены и не отключены. Описание и этапы доработки ниже сохранены как история, а не действующий план развития этого прототипа.

> **Текущий план 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](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.

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

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 проходит сверку с источниками.