[2026-10-04] eagle: personal/projects/personal-os/personal-os-architecture-decision-2026-10-04.md personal/projects/personal-os/personal-os-best-practices-2026-10-04.md personal/projects/personal-os/personal-os-evidence-graph-design-2026-10-04.md personal/projects/personal-os/personal-os-ready-systems-and-skills-2026-10-04.md personal/projects/personal-os/personal-os-system-review-2026-10-04.md personal/projects/personal-os/personal-os-system-review-index.md personal/projects/personal-os/personal-os-work-graph-research-2026-10-04.md

2026-10-04 23:54:19 +06:00
1 parent 10ea44e75c
commit 19e87789ee
@@ -1,16 +1,12 @@
---
-status: draft-review
-revision: R2
-updated: 2026-10-04
-canonical_source: /Users/admin/Developer/personal-os/planning/personal-os-architecture-decision-2026-10-04.md
---
 # Personal OS — архитектурный проект R2

+> Дополнение 04.10: [понимание потока работ и этапы WG-0–WG-4](/Users/admin/Developer/personal-os/planning/personal-os-work-graph-research-2026-10-04.md). Приоритет проверки — покрытие корпуса, обнаружение связей, текущая ситуация и роль пользователя. Это исследовательское уточнение для согласования; выбранный PostgreSQL core сохраняется, новые модели и graph runtime не внедрены.
+
 4 октября 2026. Подготовленный вариант для утверждения Алексом. Противоречия ранних вариантов устранены; реализация и новые расписания не включены.

 ## Единственный действующий план

-[Полная спецификация R2, 21 лист и приёмка](personal-os-system-review-2026-10-04.md) и [точный контракт PostgreSQL/графа](personal-os-evidence-graph-design-2026-10-04.md). [Печатные схемы и исходники](personal-os-system-review-index.md). Ранние варианты выбора стека и независимые P0-очереди заменены этим пакетом.
+[Полная спецификация R2, 21 лист и приёмка](/Users/admin/Developer/personal-os/planning/system-review-2026-10-04/review.md) и [точный контракт PostgreSQL/графа](/Users/admin/Developer/personal-os/planning/personal-os-evidence-graph-design-2026-10-04.md). [Печатные схемы и исходники](/Users/admin/Developer/personal-os/planning/system-review-2026-10-04/README.md). Ранние варианты выбора стека и независимые P0-очереди заменены этим пакетом.

 ## Зафиксированное решение

@@ -16,7 +16,7 @@

 Это образцы отдельных частей. Проверенные источники не устанавливают, что какой-либо из этих продуктов уже решает нашу миссию целиком или лучше работает на данных Алекса.

-Дополнение 04.10: [сравнение готовых систем и навыков](personal-os-ready-systems-and-skills-2026-10-04.md) добавляет наиболее близкий целостный аналог LifeOS/PAI, проверку его Atlas/TELOS и конкретный shortlist повторного использования. V1 Letta server перемещён в archive — обновлено выше по текущему upstream.
+Дополнение 04.10: [сравнение готовых систем и навыков](/Users/admin/Developer/personal-os/planning/personal-os-ready-systems-and-skills-2026-10-04.md) рассматривает LifeOS/PAI как кандидат пользовательского слоя, проверку его Atlas/TELOS и конкретный shortlist повторного использования. V1 Letta server перемещён в archive — обновлено выше по текущему upstream.

 ## 2. Пять существенных поправок

@@ -119,3 +119,7 @@ Timefold явно разделяет [ограничения разных уро
 Для первого end-to-end eval берём уже известную цепочку Core Data: предложение → отмена → обновление project state → карьерный вклад без ложного implementation → agenda advisor. Она должна работать после нового transcript, backfill, restart и пользовательской коррекции. Затем добавляется незнакомый проект, чтобы результат не зависел от вручную заданных IDs.

 **Следующее действие реализации после принятия уточнения:** создать этот воспроизводимый fixture и прогнать через минимальный context assembler; до расширения числа агентов измерить, находится ли отмена и получается ли корректный итог.
+
+## Уточнение следующего этапа
+
+[Исследование понимания потока работ](/Users/admin/Developer/personal-os/planning/personal-os-work-graph-research-2026-10-04.md) конкретизирует ещё не доказанную часть: покрытие большого корпуса, извлечение и разрешение связей, временные состояния и приоритеты относительно роли. Следующий этап — WG-0, до сравнения оболочек.
@@ -1,12 +1,8 @@
---
-status: draft-review
-revision: R2
-updated: 2026-10-04
-canonical_source: /Users/admin/Developer/personal-os/planning/personal-os-evidence-graph-design-2026-10-04.md
---
 # Personal OS — контракт графа доказательств R2

-4 октября 2026. Целевой проект для утверждения; миграции и runtime по нему не включены. Заменяет ранний иллюстративный DDL целиком. Канонический общий план: [пакет R2](personal-os-system-review-2026-10-04.md). Это спецификация будущей миграции и API, не утверждение об уже созданных таблицах.
+> Дополнение 04.10: [понимание потока работ и этапы WG-0–WG-4](/Users/admin/Developer/personal-os/planning/personal-os-work-graph-research-2026-10-04.md). Приоритет проверки — покрытие корпуса, обнаружение связей, текущая ситуация и роль пользователя. Это исследовательское уточнение для согласования; выбранный PostgreSQL core сохраняется, новые модели и graph runtime не внедрены.
+
+4 октября 2026. Целевой проект для утверждения; миграции и runtime по нему не включены. Заменяет ранний иллюстративный DDL целиком. Канонический общий план: [пакет R2](/Users/admin/Developer/personal-os/planning/system-review-2026-10-04/review.md). Это спецификация будущей миграции и API, не утверждение об уже созданных таблицах.

 ## 1. Хранилище и граница истины

@@ -4,7 +4,7 @@

 ## Решение, которое предлагается

-**Первым сравнить LifeOS (бывший PAI) с нашим R2.** Это наиболее близкая из изученных систем по связке «миссия → цели → проекты → действия → память → улучшение». Letta — альтернативная среда исполнения агентов; Khoj — готовый интерфейс к знаниям; Dify — визуальное конструирование сценариев. Рейтинг — наша оценка применимости, а не результат сравнительного запуска.
+**Поправка после исследования большого потока работ:** первым проверить восстановление связей и приоритетов на представительном корпусе — [исследование и этапы WG-0–WG-4](/Users/admin/Developer/personal-os/planning/personal-os-work-graph-research-2026-10-04.md). LifeOS (бывший PAI) остаётся кандидатом пользовательского слоя. Letta — агентная среда; Khoj — интерфейс к знаниям; Dify — визуальные сценарии. Ни один из них здесь не доказан как готовый механизм понимания всех работ.

 Цель проверки — заменить готовым продуктом конкретные слои нашей системы. У всех кандидатов требуется доказать работу с нашими источниками, отменёнными решениями, косвенными связями и ограничениями внимания. Наличие памяти или графа само по себе этого не доказывает.

@@ -12,7 +12,7 @@

 | Система | Что уже есть | Как укладывается в Personal OS | Доработка и ограничение |
 |---|---|---|---|
-| **[LifeOS / PAI](https://github.com/danielmiessler/LifeOS)** — первый кандидат | TELOS, память Cortex, навыки, Pulse, граф Atlas; TypeScript/Bun. | Готовая основа личного контекста и пользовательского цикла. Проверить замену части собственных ролей и панели. | Сопоставить модель с PostgreSQL evidence core, подключить Zoom/Asana/GitHub, обеспечить принятие/отмену решений и ограничения planner. Полная интеграция hooks лучше всего поддержана на Claude Code. |
+| **[LifeOS / PAI](https://github.com/danielmiessler/LifeOS)** — кандидат пользовательского слоя | TELOS, память Cortex, навыки, Pulse, граф Atlas; TypeScript/Bun. | Готовая основа личного контекста и пользовательского цикла. Проверить замену части собственных ролей и панели. | Сопоставить модель с PostgreSQL evidence core, подключить Zoom/Asana/GitHub, обеспечить принятие/отмену решений и ограничения planner. Полная интеграция hooks лучше всего поддержана на Claude Code. |
 | **[Letta Code](https://github.com/letta-ai/letta-code)** — альтернатива агентной среде | Постоянные агенты, git-память MemFS, навыки, приложения, каналы и App Server. | Можно заменить собственную оболочку запуска и продолжения агента. | Память агента должна читать принятые состояния через наш API. Проверить локальный режим, ограничения tools и восстановление; собственные решения по проектам и планированию остаются необходимы. |
 | **[Khoj](https://github.com/khoj-ai/khoj)** — готовый помощник по знаниям | Поиск по документам, интерфейсы включая Obsidian, настраиваемые агенты и автоматизации; self-hosting. | Быстро получить поиск и обсуждение проектов поверх опубликованных снимков. | Произвольное подключение нашего API без fork ещё не доказано. Предметный граф, разрешение противоречий и устойчивый planner не подтверждены как готовые функции. |
 | **[Dify](https://github.com/langgenius/dify)** — визуальные сценарии | Workflow canvas, RAG, инструменты/API/MCP, сравнение промптов и наблюдение запусков. | Подходит, если приоритет — редактировать цепочки анализа и подготовки отчётов визуально. | Нужны внешний evidence API и личный UI планирования. Эксплуатация отдельной платформы; визуальная схема не заменяет семантику источников. |
@@ -41,7 +41,7 @@

 OpenClaw/Hermes уже испытаны в нашем проекте. [История неудачных подходов](/Users/admin/obsidian/personal/projects/personal-os/personal-os-failed-approaches.md) фиксирует сложность OpenClaw-bridge, несогласованные записи Asana/публикацию в Discord у Executor v1, ненадёжные cron-цепочки и дорогой расходящийся fork. Это факты нашего внедрения, не универсальная оценка продуктов. Повторный полный перенос на них пока не обоснован. Узкий worker возможен только через те же проверенные границы действий.

-Graphiti и DBOS остаются компонентами из [предыдущего исследования](personal-os-best-practices-2026-10-04.md), а не готовыми Personal OS. Выбор UI/агентной среды не должен автоматически добавлять ещё один scheduler поверх существующего владельца запусков.
+Graphiti и DBOS остаются компонентами из [предыдущего исследования](/Users/admin/Developer/personal-os/planning/personal-os-best-practices-2026-10-04.md), а не готовыми Personal OS. Выбор UI/агентной среды не должен автоматически добавлять ещё один scheduler поверх существующего владельца запусков.

 ## 2. Какие готовые навыки брать

@@ -57,7 +57,7 @@ Graphiti и DBOS остаются компонентами из [предыду

 ### Конкретные несовместимости прочитанных SKILL.md

-**Enterprise-search.** [search-strategy](https://github.com/anthropics/knowledge-work-plugins/blob/main/enterprise-search/skills/search-strategy/SKILL.md) содержит пример поиска только незавершённых задач и общую иерархию авторитетности; [knowledge-synthesis](https://github.com/anthropics/knowledge-work-plugins/blob/main/enterprise-search/skills/knowledge-synthesis/SKILL.md) использует свежесть при выборе актуального вывода. Для нас поиск должен включать закрытые/отклонённые задачи, поздние решения и контрсвидетельства; ingestion time не равен времени решения. Копии одного события не считаются независимым подтверждением. Подключённый источник не означает полноту его загрузки. Эти поправки оформляются небольшим явным diff к upstream, проверяемым на Core Data.
+**Enterprise-search.** [search-strategy](https://github.com/anthropics/knowledge-work-plugins/blob/main/enterprise-search/skills/search-strategy/SKILL.md) содержит пример поиска только незавершённых задач и общую иерархию авторитетности; [knowledge-synthesis](https://github.com/anthropics/knowledge-work-plugins/blob/main/enterprise-search/skills/knowledge-synthesis/SKILL.md) использует свежесть при выборе актуального вывода. Для нас поиск должен включать закрытые/отклонённые задачи, поздние решения и контрсвидетельства; ingestion time не равен времени решения. Копии одного события не считаются независимым подтверждением. Подключённый источник не означает полноту его загрузки. Эти поправки оформляются небольшим явным diff к upstream, проверяемым на представительном наборе разных проектов, периодов, языков и типов работы.

 **Telos/Science.** Оба прочитанных навыка требуют голосовой вызов Pulse и запись в пути `~/.claude/LIFEOS`; Telos также содержит автоматическое распараллеливание сборки dashboard. Для нас эти побочные действия требуют отдельной конфигурации и авторизации. Переносится полезная методика вместе с необходимыми workflow-файлами; готовый SKILL.md без адаптации применять нельзя. Метрики ретроспекции и изменения поведения привязываются к версии policy и результатам приёмки, а не к самооценке агента.

@@ -90,9 +90,11 @@ npx skills add supabase/agent-skills --skill supabase-postgres-best-practices

 ## 3. Следующий ограниченный этап и приёмка

-1. **Составить таблицу соответствия LifeOS ↔ R2 на закреплённой версии:** для каждого collector, canonical store, planner, review, feedback, scheduler и UI указать reuse/adapter/custom. Проверить код записи Atlas/Cortex и реально доступные расширения Pulse; рекламные обещания не засчитываются.
-2. **Подготовить один офлайн-набор проверки:** Core Data proposal→отмена→реализация без изменения; косвенно связанные проекты; неполный Zoom-source; исправление пользователя; перегруженный день. Для каждого задать обязательные источники и ожидаемые состояния.
-3. **Проверить один кандидат в изоляции после согласования установки:** один ручной запуск, одинаковые evidence packets, ограниченные инструменты. Измерить найденные основания, корректность состояний, принятие correction, действия и время обслуживания.
-4. **Принять решение о повторном использовании:** платформа принимается, если все критические fixtures проходят, дополнительная запись/рассылка без разрешения исключена технической границей, состояния экспортируются и восстанавливаются, а объём adapter меньше заменяемой разработки. Иначе забрать проверенные навыки/компоненты и сохранить существующую оболочку.
+Порядок исправлен после выявления главного пробела — понимания большого корпуса работ. Подробная спецификация: [исследование предметного графа](/Users/admin/Developer/personal-os/planning/personal-os-work-graph-research-2026-10-04.md).

-Готового подтверждения всей нашей парадигмы «из коробки» пока нет. Найдена близкая система с проверяемыми точками интеграции и конкретные готовые навыки. Следующая работа — сравнение LifeOS с контрактами R2, прежде чем продолжать собственную оболочку.
+1. **WG-0: карта покрытия и набор оценки.** Разные проекты, периоды, роли, тихие обязательства, закрытые задачи и косвенные связи; измерить пробелы источников.
+2. **WG-1–WG-2: проверить извлечение, связи и текущую ситуацию.** Сравнить компоненты на одинаковом корпусе; сохранить контракты R2 и измерить стоимость ошибок.
+3. **WG-3: доказать приоритеты относительно роли.** Оценить пользу для пользователя до выбора оболочки и полировки карьерных отчётов.
+4. **После проверки предметного слоя — сравнение UI/агентной среды.** LifeOS ↔ R2, один изолированный кандидат после согласования установки; переиспользование оправдано, если критические сценарии проходят, состояния экспортируются и адаптация проще заменяемой разработки.
+
+Следующая работа — WG-0: покрытие источников и представительский набор оценки.
@@ -1,11 +1,7 @@
---
-status: draft-review
-revision: R2
-updated: 2026-10-04
-canonical_source: /Users/admin/Developer/personal-os/planning/system-review-2026-10-04/review.md
---
 # Personal OS: проект системы R2

+> Исследовательское дополнение 04.10: [предметный граф, приоритеты и gates WG-0–WG-4](/Users/admin/Developer/personal-os/planning/personal-os-work-graph-research-2026-10-04.md). Начинать реализацию с карты покрытия и представительского набора оценки; выбор оболочки следует за проверкой понимания работ. Дополнение ещё не включено в печатные PDF R2.
+
 Редакция R2 / 4 октября 2026 / цельный план реализации для утверждения и пометок карандашом.

 ## 01. Паспорт плана
@@ -28,4 +28,8 @@ updated: 2026-10-04

 ## Готовые системы и навыки

-[[personal-os-ready-systems-and-skills-2026-10-04]] — LifeOS/PAI как первый кандидат для сравнения всей парадигмы, Letta Code/Khoj/Dify как альтернативы отдельных слоёв; готовые навыки, необходимые адаптации и приёмка. Это исследование после R2: установка и миграция не выполнялись.
+[[personal-os-ready-systems-and-skills-2026-10-04]] — LifeOS/PAI как кандидат пользовательского слоя, Letta Code/Khoj/Dify как альтернативы отдельных слоёв; готовые навыки, необходимые адаптации и приёмка. Это исследование после R2: установка и миграция не выполнялись.
+
+## Понимание большого потока работ — приоритет проверки
+
+[[personal-os-work-graph-research-2026-10-04]] — исследование Glean, Numen, Graphiti/GraphRAG, Jev и альтернатив; локальный масштаб корпуса, data flow, роль пользователя, критерии приёмки и этапы WG-0–WG-4. Первый этап теперь — карта покрытия и репрезентативный набор оценки. Сравнение LifeOS отложено до проверки предметного слоя. Это предложение для согласования, без установки моделей и запуска новых расписаний; PDF остаются R2.
@@ -0,0 +1,249 @@
+# Personal OS: понимание большого потока работ
+
+Дата: 2026-10-04. Статус: исследование и предложение архитектуры, до согласования реализации. Проверены официальные документы, статьи авторов и выбранные исходники GitHub. Репозитории не запускались. Частные данные не отправлялись исследуемым моделям; установки и расписания не создавались.
+
+## 1. Решение и изменение приоритета
+
+**Первый инженерный этап — доказать восстановление структуры работ и их значимости на представительном корпусе.** Сравнение оболочек LifeOS/Letta и улучшение карьерных отчётов идут после этого доказательства. Предыдущая рекомендация начать с сопоставления LifeOS и R2 меняется.
+
+Проблема состоит из пяти отдельных задач: полнота наблюдения; выделение объектов и событий; связывание объектов между источниками; восстановление текущей ситуации; приоритизация относительно роли, целей и доступного внимания. Один хороший классификатор не гарантирует остальные четыре результата.
+
+LifeOS шире журнала агентских действий: TELOS описывает личные цели, Atlas — активы и наблюдения. Однако прочитанные контракты не доказывают восстановление обязательств, неявных инициатив и их приоритетов из большого корпоративного архива. Обзор LifeOS остаётся полезен для пользовательского слоя. [Atlas](https://github.com/danielmiessler/LifeOS/blob/5e2f2e8c0abde612da0e99c16c0d07d4ec21b88c/LifeOS/install/LIFEOS/DOCUMENTATION/Atlas/AtlasSystem.md).
+
+**Рекомендация:** сохранить PostgreSQL как реестр доказательств и принятых состояний; построить проверяемый конвейер извлечения и связывания с заменяемыми моделями. Jev — кандидат для узких решений внутри конвейера. Graphiti — кандидат для сравнения временных связей. Glean — коммерческий образец организации корпоративного контекста; Numen — близкий открытый прототип, требующий существенной проверки.
+
+## 2. Что есть у нас фактически
+
+Агрегаты прочитаны из локальной PostgreSQL в транзакции READ ONLY 04.10.2026, 17:45 UTC. Это доступный локальный корпус, **не доказательство полноты Asana или всех источников**. Машинный срез: [corpus-inventory.json](/Users/admin/Developer/personal-os/planning/work-graph-research-2026-10-04/corpus-inventory.json).
+
+| Показатель | Наблюдение | Следствие |
+|---|---|---|
+| Задачи | 79 507; 36 756 с `completed=false`; 446 разных `project_gid` | Это большой исторический корпус. Открытый статус не означает текущую работу пользователя. Одно поле проекта не отражает все memberships задачи. |
+| Stories | 575 587 у 40 621 задачи, с 2011 по 2026 год | Здесь и обсуждения, и системные события. Отсутствие stories может означать отсутствие событий или пробел загрузки. |
+| Явные связи | 50 161 mention; 2 468 subtask; 14 dependency + 5 dependent | Уже есть полезная структура. Упоминание нельзя превращать в зависимость; малое число dependencies требует аудита collector. |
+| Подготовленность | `task_embeddings` пустая; 5 388 задач без notes | Предметный семантический индекс пока не доказан. Последний `fetched_at` задач — 03.10, что не удостоверяет полноту комментариев. |
+| Другие источники | В `zoom-recordings` один manifest; в `~/context/mattermost-client` 101 JSON-файл | Это файловые наблюдения в двух конкретных каталогах, не количество всех встреч/сообщений. Нужна сверка с upstream и другими архивами. |
+
+Текущий Zoom loader выделяет кандидатов по английским регулярным выражениям (`decision`, `commitment` и др.). Это допустимый начальный фильтр кандидатов, но его выход не заменяет полный корпус бесед: косвенная речь, отрицания и русские формулировки требуют другого анализа. См. [zoom-transcripts-load.js](/Users/admin/Developer/personal-os/scripts/zoom-transcripts-load.js).
+
+`agent/work-profile.md` содержит узкий набор эпизодов, а `career-notes.md` помечает старые карьерные сведения как неподтверждённые. Следовательно, текущую роль и цели нельзя считать уже восстановленными. Нужны датированные факты о зонах ответственности и отдельные гипотезы. Миссия Personal OS сохраняется: самочувствие, внимание и границы рабочего дня ограничивают рабочую оптимизацию.
+
+## 3. Существующие решения: что действительно подходит
+
+### 3.1. Готовые системы
+
+| Решение | Подтверждённая близость к задаче | Ограничение и вывод |
+|---|---|---|
+| **Glean** | Граф объединяет контент, людей и активность; идентичности, роли, команды и история участвуют в персонализации. | Наиболее близкий из изученных коммерческих классов. Закрытый алгоритм; соответствие нашим источникам, индивидуальному доступу и миссии не проверено. Рассматривать продукт при доступности, архитектуру использовать как ориентир. [Документация](https://docs.glean.com/security/knowledge-graph). |
+| **Numen** | Открытый граф задач, PR, документов, людей и целей; urgency, briefing, MCP; Python/FastAPI, PostgreSQL, FalkorDB, Redis. | Beta; заявленные коннекторы Linear/GH/Slack/Jira/Notion/Docs не закрывают нашу тройку Asana/Zoom/Mattermost. Ниже есть конкретные ограничения кода. Источник идей и кандидат для ограниченного сравнения, не готовая замена. [Репозиторий](https://github.com/theBstar/numen). |
+| **LifeOS / Letta / Khoj / Dify** | Личный контекст, агентная среда, поиск или сценарии соответственно. | Полезны после появления достоверного предметного слоя. Их прежний рейтинг отвечал на вопрос об оболочке, а не доказывал качество понимания работ. [Предыдущий обзор](/Users/admin/Developer/personal-os/planning/personal-os-ready-systems-and-skills-2026-10-04.md). |
+
+Отсутствие найденного готового продукта, закрывающего все требования, не доказывает отсутствие такого продукта вообще. В исследованных реализациях нет подтверждённого сочетания наших источников, временных решений, произвольных объектов, роли пользователя и приёмки качества приоритетов.
+
+### 3.2. Что обнаружено в настоящем коде Numen
+
+Проверен commit `0b5ac5f1d64e69f1dd2a8d3c9fec69fa9f7cf2ba`; это статическое чтение выбранных модулей, не интеграционный тест.
+
+| Модуль | Наблюдение | Почему существенно для нас |
+|---|---|---|
+| [link_suggester.py](https://github.com/theBstar/numen/blob/0b5ac5f1d64e69f1dd2a8d3c9fec69fa9f7cf2ba/src/llm/link_suggester.py) | Получает до 1 000 PR и до 1 000 задач; закрытые задачи исключаются. На пакет из 5 PR передаётся список задач. Предложения сохраняются pending, порог confidence — 0.4. | При нашем масштабе это ограничивает обнаружение связей с архивом и расходует контекст. Pending полезен; число confidence ещё надо калибровать. |
+| [urgency.py](https://github.com/theBstar/numen/blob/0b5ac5f1d64e69f1dd2a8d3c9fec69fa9f7cf2ba/src/inference/urgency.py) | В формуле `compute_urgency` есть частота упоминаний и давность; аргумент `person_id` сохраняется в результате, но не участвует в вычислении факторов. | Отбор доступных человеку объектов есть в [scorer.py](https://github.com/theBstar/numen/blob/0b5ac5f1d64e69f1dd2a8d3c9fec69fa9f7cf2ba/src/inference/scorer.py), однако просмотренная формула не меняет важность одной задачи в зависимости от роли. Это не наш готовый ranker. |
+| [resolution.py](https://github.com/theBstar/numen/blob/0b5ac5f1d64e69f1dd2a8d3c9fec69fa9f7cf2ba/src/graph/resolution.py) | Проверка равенства нормализованных имён вложена в условие их неравенства. Эта ветка недостижима. | Даже подходящая предметная модель не означает надёжную реализацию сопоставления. |
+
+### 3.3. Граф и поиск
+
+| Подход | Что переиспользовать | Что он не доказывает |
+|---|---|---|
+| **Graphiti** | Инкрементальное извлечение, сопоставление сущностей, временные связи, поиск. | Корректность идентичностей, отменённых решений и пользовательских приоритетов на нашем корпусе. Python и дополнительное graph storage увеличат стоимость эксплуатации. [GitHub](https://github.com/getzep/graphiti). |
+| **Microsoft GraphRAG** | Построение сообществ и обзоров большого корпуса; полезно найти крупные направления, а не только ответ на уже заданный вопрос. | Сообщество не равно проекту. FastGraphRAG использует совместную встречаемость, поэтому его ребро не означает «блокирует» или «решено». [Dataflow](https://microsoft.github.io/graphrag/index/default_dataflow/), [методы](https://microsoft.github.io/graphrag/index/methods/). |
+| **HippoRAG 2 / LightRAG** | Кандидаты для поиска связанных фрагментов через несколько переходов. | Retrieval benchmark не измеряет актуальность обязательств и качество личного плана. Personalized PageRank в HippoRAG персонализирован относительно запроса; это не модель карьерных приоритетов. [HippoRAG](https://github.com/OSU-NLP-Group/HippoRAG), [статья](https://arxiv.org/abs/2502.14802), [LightRAG](https://github.com/HKUDS/LightRAG). |
+
+Graphiti просмотрен глубже: commit `5d47d4d0182aa6350edeb435b734837a88ed9738`. В [node_operations.py](https://github.com/getzep/graphiti/blob/5d47d4d0182aa6350edeb435b734837a88ed9738/graphiti_core/utils/maintenance/node_operations.py) есть ограниченный набор кандидатов (15, cosine threshold 0.6) и последующее разрешение через LLM. Это полезная декомпозиция. Схлопывание одинаково нормализованных имён внутри эпизода требует отдельной проверки на омонимах. В [edge_operations.py](https://github.com/getzep/graphiti/blob/5d47d4d0182aa6350edeb435b734837a88ed9738/graphiti_core/utils/maintenance/edge_operations.py) дубликаты и противоречия обрабатываются отдельно, поддерживаются временные интервалы; семантическое решение всё равно принимает модель. Наличие timestamp не гарантирует верность решения.
+
+В просмотренном дереве Graphiti есть Neo4j/FalkorDB/Kuzu/Neptune drivers; PostgreSQL driver не обнаружен. Поэтому Graphiti — либо изолированный сравнительный стенд с перестраиваемым графом, либо источник адаптируемых контрактов. Второй независимый реестр принятой правды нам не нужен.
+
+LazyGraphRAG полезен как идея переноса части затрат на момент запроса. Статья Microsoft описывает исследования и интеграции; это не достаточное основание обещать готовый открытый пакет для нашего внедрения. [Источник](https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/).
+
+### 3.4. Дешёвое извлечение, классификация и сопоставление
+
+| Кандидат | Подходящая функция | Когда выбирать |
+|---|---|---|
+| **Jev / TypeSafe** | Выбор из заданных вариантов: тип сигнала, отношение пары объектов, подтверждение конкретного утверждения. | Проверить первым как API-кандидата для ограниченных решений. Нужны готовые кандидаты и вариант unknown. [Введение](https://typesafe.ai/blog/introducing-system-one-models-and-jev). |
+| **GLiNER2** | Извлечение сущностей, классификация, структур и отношений по заданной схеме; потенциально локальное исполнение. | Сравнить с API на EN/RU и реальном оборудовании. Извлечение имени ещё не определяет идентичность человека между системами. [GitHub](https://github.com/fastino-ai/GLiNER2), [статья](https://arxiv.org/abs/2507.18546). |
+| **SetFit** | Компактная классификация по размеченным примерам, включая multilingual encoders. | После стабилизации категорий и появления исправлений. Не решает открытие совершенно новых типов связей. [GitHub](https://github.com/huggingface/setfit). |
+| **Splink** | Вероятностное сопоставление структурированных записей с предварительным отбором пар. | Для людей/организаций при наличии нескольких полей; не для вывода смысла всего обсуждения. [Документация](https://moj-analytical-services.github.io/splink/). |
+| **BERTopic / Snorkel** | Обнаружение тем / получение слабых меток из нескольких правил. | Вспомогательные инструменты: поиск неразобранных направлений и bootstrap. Тематическая близость и слабая метка не становятся фактом. [BERTopic](https://github.com/MaartenGr/BERTopic), [Snorkel](https://github.com/snorkel-team/snorkel). |
+
+Эти решения — альтернативы внутри этапов. Одновременная установка всех библиотек не предлагается.
+
+## 4. Jev: конкретное место и экономика
+
+Под `jev` здесь понимается найденный официальный TypeSafe Jev. На дату проверки модель `jev-1.13.0` стоит $0.042 за миллион входных токенов, выход не тарифицируется. Основной язык обучения английский; русский надо проверять отдельно. Для воспроизводимости фиксируется версия, а не `latest`. [Модель и цена](https://docs.typesafe.ai/models).
+
+В официальном [entity alignment cookbook](https://docs.typesafe.ai/cookbooks/entity_alignment) уже есть подход «предварительно отобранная пара → разные / одинаковые / требуется проверка». Это ближе к нашей задаче, чем просьба одной модели построить весь граф. Но демонстрация на каталогах товаров не подтверждает качество на людях, задачах и косвенных договорённостях.
+
+Jev не генерирует произвольные новые объекты/объяснения. Документация отдельно предупреждает о многошаговых рассуждениях, шумном большом контексте, порядке вариантов и вычислении дат/чисел. Поэтому IDs и календарные сравнения делает код; генеративная модель или extractor выделяет неизвестные объекты; Jev оценивает короткие кандидаты. [Ограничения](https://docs.typesafe.ai/model-jaggedness/jev-1.13).
+
+**Пример стоимости, не измерение нашего корпуса:** 100 000 эпизодов × 1 500 входных токенов = 150 млн токенов, или $6.30 за один проход. Если дополнительно проверять 10 пар на эпизод по 600 токенов — ещё 600 млн, $25.20. Отдельно оплачиваются извлечение, embeddings, сложные случаи, повторы и хранение. Число stories не равно числу эпизодов и не даёт готовую смету. Реальная единица сравнения — стоимость 1 000 обработанных эпизодов **при одинаковой полноте и качестве**, плюс минуты проверки человеком.
+
+Есть официальный [TypeSafe skill](https://github.com/typesafe-ai/skills/blob/65a39f393687675ce170e6094757de20370365b9/skills/typesafe-ai/SKILL.md). Прочитан как материал для разработки; не установлен и не применён как инструкция этой сессии. Его можно использовать после выбора модели, сохранив наши контракты unknown, provenance и локальной калибровки.
+
+## 5. Предлагаемый data flow
+
+```mermaid
+flowchart TD
+  S[Asana / Mattermost / Zoom / GitHub / файлы] --> R[Исходные записи, версии, покрытие]
+  R --> D[IDs, ссылки, явные связи — код]
+  R --> E[Полные треды и эпизоды → извлечение объектов и событий]
+  D --> C[Кандидаты: точные ключи + текст + векторы + соседи]
+  E --> C
+  C --> J[Узкие решения: правила / Jev / локальная модель]
+  J --> U[Неясные и существенные случаи → углублённый разбор]
+  J --> P[Предложения связей с источниками]
+  U --> P
+  P --> V[Проверка контрактов и принятие]
+  V --> G[PostgreSQL: версии объектов, утверждения, временные связи]
+  G --> W[Направления работ, зависимости, текущая ситуация]
+  R --> O[Периодическая проверка непокрытого архива]
+  O --> C
+  W --> K[Роль + цели + обязательства → приоритеты]
+  K --> L[Planner: ёмкость дня, текущий план, ограничения]
+  L --> UI[Обзор → действие / объяснение / исправление]
+  UI --> F[Типизированная обратная связь]
+  F --> V
+  F --> EV[Retrospector: ошибки и качество policy]
+  EV --> T[Офлайн-проверка новой версии]
+  T --> V
+```
+
+### 5.1. Сбор и покрытие
+
+Единица анализа — задача с историей, тред или эпизод встречи с соседним контекстом. Сохраняются исходные реплики, speaker/source IDs, время события и загрузки, версии, диапазоны текста/таймкоды. Сводка служит навигацией; вывод проверяется по исходным фрагментам.
+
+Первый проход по **всему доступному архиву** строит недорогой индекс, явные связи и карту покрытия. Глубина разбора увеличивается для действующих работ, изменений и непонятных областей, но архив остаётся в поиске. Очередь backfill должна гарантировать продвижение по старым и малообсуждаемым данным; скорость и остаток показываются отдельно.
+
+Полнота измеряется по источнику, проекту/каналу и периоду: ожидаемые и полученные объекты, pagination, права, пропуски, удалённые/изменённые записи. «Синхронизация успешна» не означает «вся история доступна». Пропущенное окно понижает уверенность соответствующей ситуации.
+
+### 5.2. Обнаружение кандидатов без квадратичного перебора
+
+79 507 задач дают примерно 3.16 млрд неупорядоченных пар. Проверять каждую моделью неразумно. Предлагается объединение точных IDs/URL/aliases, полнотекстового поиска, multilingual embeddings, участников/временных окон и соседей графа. Временная близость — добавочный сигнал, не условие: связь может проходить через годы.
+
+Начальный бюджет — 10–30 кандидатов на объект, расширяемый при неопределённости. Он выбирается по Recall@K, а не удобству реализации. Пропущенную кандидатом связь не исправит самый сильный последующий классификатор. Для каждой пары сохраняется причина попадания в выборку.
+
+Новые направления обнаруживаются также среди объектов без хороших кандидатов: кластеризация, общие результаты/артефакты/участники, генеративная гипотеза о workstream. Кластер может содержать несколько проектов; одна задача может принадлежать нескольким направлениям. Объекты с малым числом связей остаются видимыми.
+
+### 5.3. Идентичность, отношение и событие — разные решения
+
+`same_entity`, `part_of`, `blocks`, `implements`, `discusses`, `supersedes`, `contributes_to_goal` имеют разные критерии. Общая тема даёт максимум кандидатное `related_to`. `discusses` не доказывает участие в реализации. Объединение идентичностей требует более высокой точности, чем подсказка поиску.
+
+Принятие одного `same_entity` может объединить много соседей; поэтому нельзя применять транзитивное слияние по цепочке слабых сходств. Merge/split обратимы, история исходных IDs сохраняется. Одинаковые имена без workspace/provider контекста не достаточны.
+
+Событие хранит автора высказывания, адресата обязательства, модальность, отрицание/условие, время и подтверждающие фрагменты. «Можно сделать», «поручено», «сделано», «принято», «выпущено» не взаимозаменяемы. Позднее упоминание старого решения не отменяет более раннее по дате публикации новое решение: сравнивается смысл и время события.
+
+### 5.4. Произвольные объекты и непрямые связи
+
+База R2 уже предусматривает versioned types и typed assertions. Нужна реализация discovery, не бесконтрольное создание схемы моделью. Неизвестный объект получает стабильный internal ID и `type_candidate`; имя и предполагаемый тип могут уточняться без потери истории.
+
+Пример структуры, **не факт из работы пользователя**: серия задач → изменение процесса ревью → снятие зависимости у другой команды → результат квартальной инициативы → свидетельство координационной роли. Каждый переход имеет свой источник и статус. Вывод о карьерном результате остаётся гипотезой, если известна только активность, а результат не подтверждён.
+
+Последовательность проектов выражается typed relations `enables`, `follows`, `replaces`, `depends_on`, а не порядком дат. Для циклов показывается противоречие/цикл; нельзя молча обещать корректный critical path. Файлы и сессии приложений связываются через IDs, URL и артефакты; foreground time само по себе не определяет задачу.
+
+## 6. Как получится приоритет именно для пользователя
+
+Сначала строятся независимые оценки: **значимость результата, моя ответственность, срочность, доступное действие**. После этого planner учитывает ёмкость дня и устойчивость уже принятого плана. Один непрозрачный score 0–100 скрывает слишком много разных причин.
+
+| Слой | Входы | Выход |
+|---|---|---|
+| Роль | Подтверждённые зоны ответственности, DRI/reviewer/координатор/консультант, период действия и источник | Почему эта работа относится к пользователю; неизвестность явна |
+| Значимость | Связь с подтверждённой целью, последствия задержки, зависимые результаты и люди | Обоснование важности; отсутствие данных не превращается в ноль |
+| Срочность и действие | Реальные дедлайны, обещания, ожидания других, готовность входов | Что требует действия сейчас и что действительно доступно |
+| Планирование | Время, нагрузка, фокус, отдых, уже принятые обязательства | Небольшой набор действий; остальное остаётся доступным |
+| Обратная связь | «Не моя роль», «не тот объект», «позже», «неверная связь», «неверный статус» | Исправление конкретного слоя; отложить не означает обесценить цель |
+
+Пользователь не обязан быть assignee, чтобы review/координация были его работой. Старые карьерные записи не считаются действующей ролью автоматически. В начале предлагается черновик роли с доказательствами, пользователю остаётся исправить только неопределённые существенные пункты.
+
+Hard constraints и даты вычисляет код. Модель сравнивает подходящие действия по явным критериям и сообщает контрсвидетельства. Результат сохраняется вместе с policy version и snapshot источников. Обучаемый ranker имеет смысл после накопления валидной обратной связи; лайки сводок недостаточны.
+
+Количество сообщений, свежесть и центральность графа могут помочь поиску, но не служат самостоятельным доказательством важности. Для тестирования устойчивости дублируем сообщения о второстепенной задаче: её приоритет не должен расти. Значимость тихого обязательства проверяется отдельным тестом.
+
+## 7. Контракты компонентов и изменения к R2
+
+PostgreSQL остаётся canonical store; Node.js постепенно типизируется TypeScript. Полнотекстовый индекс — исходная база; `pgvector` проверяется как замена отсутствующего семантического поиска на том же корпусе. Python добавляется только изолированным batch worker для выбранной локальной модели/Graphiti, если сравнение оправдает зависимость. n8n/Node-RED могут оркестрировать этапы, но качество классификации и графа от них не появляется.
+
+Существующие `entities`, `source_records/source_spans`, `assertions`, версии и feedback из [контракта R2](/Users/admin/Developer/personal-os/planning/personal-os-evidence-graph-design-2026-10-04.md) используются повторно. Дополнительные логические записи ниже — предложение, **не применённая миграция**:
+
+| Запись | Обязательные поля / смысл |
+|---|---|
+| `coverage_partition` + `episode` | Источник, область, период, pagination/watermark, статус полноты; исходные record/span IDs, участники, время эпизода |
+| `candidate_link` + `analysis_run` | Пара/тип, причины отбора, model/prompt/schema версии, варианты, uncertainty, стоимость, входные hashes, статус рассмотрения |
+| `workstream_membership` | Workstream/entity IDs, роль объекта, поддерживающие assertions, период, proposed/accepted; многозначное членство |
+| `role_assignment` + `priority_assessment` | Человек, scope/роль/цель/период; действие, компоненты важности, ограничения, evidence, policy/snapshot, dissent |
+| `evaluation_case` + `review_outcome` | Stratum, независимый ожидаемый результат, split, решения проверяющих, ошибки по этапам, время проверки |
+
+### Минимальные инструкции анализа
+
+**Extractor.** Вход: эпизод с соседним контекстом. Выход: объекты и утверждения с точными span IDs, актором, временем и модальностью. Сохранять отрицание, условность и противоречащие фрагменты; незаявленный результат помечать unknown. Собственные названия направления — гипотеза.
+
+**Resolver.** Вход: пара и ограниченные контекстные доказательства. Выход: same/different/unknown, либо конкретный тип отношения и evidence IDs. Раздельно оценить идентичность и связь. При несовместимых идентификаторах не объединять. Отсутствие найденного доказательства не равно доказательству отсутствия связи.
+
+**Situation builder.** Вход: история подтверждений и опровержений по направлению. Выход: текущая ситуация, незакрытые обязательства, решения по отдельным измерениям, пробелы покрытия. Для изменения статуса указать событие и предыдущее состояние; пересказ не является новым событием.
+
+**Priority proposer.** Вход: ситуация, подтверждённая роль/цели, ограничения и альтернативы. Выход: предлагаемый порядок, причины, доступное действие, что изменит порядок. Запрещено подменять результат интенсивностью обсуждения. Неизвестная ответственность выделяется отдельно.
+
+**Retrospector.** Вход: предложения, фактические выборы и результаты, исправления. Выход: ошибки этапов и предлагаемое изменение policy с тестами. Пользовательское «позже» не размечается как ошибка важности; отказ из-за перегрузки не меняет карьерную цель. Новая policy сначала проходит replay, затем согласованное включение.
+
+## 8. Приёмка: как не повторить выбор одного яркого случая
+
+### Данные оценки
+
+Начальный исследовательский набор: около 1 000 эпизодов, 300 размеченных пар и 30 историй изменения решений, плюс 20 пар реальных альтернатив для оценки приоритетов. Числа — стартовый бюджет, не статистическая гарантия. Они уточняются после распределения корпуса. Разметку объективных фактов готовит инженер по первичным источникам; модель может предложить метки, но не быть единственным судьёй. Пользователю предъявляются небольшие пакеты субъективных выборов, максимум пять за раз.
+
+Выборка сочетает случайную пропорциональную часть и целевые редкие случаи. Страты: источники и языки; проекты и периоды; открытые/закрытые/давно неактивные работы; явные/косвенные связи; исполнение/ревью/координация; тихие/многообсуждаемые обязательства. Один знакомый эпизод может быть regression case, но не центром набора.
+
+Разделение train/dev/test выполняется целыми тредами и задачами, с временным cutoff; отдельная проверка на ранее не встречавшемся проекте. Дубликаты и пересказы одной встречи не распределяются по разным split. Негативные пары включают похожие названия разных объектов и тематически близкие работы без причинной связи.
+
+### Метрики и предлагаемые gates
+
+| Уровень | Что измеряем | Начальный критерий перехода, не достигнутый результат |
+|---|---|---|
+| Покрытие и кандидаты | Полнота страниц/окон; Recall@K отдельно от последующей классификации | Весь заявленный пилотный scope загружен либо имеет явный gap; Recall@30 ≥95% на размеченных связях, включая отчёт по стратам |
+| Идентичности и отношения | False merges; precision/recall по типу; калибровка вероятностей и доля abstain | Автослияние по семантике выключено до достаточной выборки; существенные ошибочные слияния — блокирующие. Для обычных принимаемых отношений precision ≥95%, критические — отдельная ручная приёмка |
+| Ситуация и доказательства | Верный текущий статус; причинность; покрытие источниками | Все утверждения в выводе имеют проверяемые ссылки; обязательные сценарии отмен/противоречий проходят полностью; неподтверждённый outcome не принимается |
+| Приоритеты | Попарное согласие пользователя, пропущенные обязательства, устойчивость к шуму, разнообразие представленных работ | Пилот лучше согласованной простой базы; ноль пропущенных критических обязательств в контрольных сценариях; повтор сообщений не меняет порядок без нового факта |
+| Полезность и эксплуатация | Минуты review, стоимость/1 000 эпизодов, p95 задержки, replay, backlog | Пользовательский review укладывается в предложенный бюджет 10 минут/неделю; две недели shadow-пилота без необъяснимых смен плана, дубликатов и потери данных |
+
+Порог ≥95% на малой выборке не подтверждает промышленную надёжность. Отчёт включает размер выборки, доверительные интервалы, худшие страты, ошибки высокой цены и долю неизвестных. Ноль ошибок на 300 парах не доказывает 99.9% качества. Если неопределённости слишком много для review-бюджета, автоматизацию не расширяем: улучшаем сбор/кандидатов или сужаем область принятия.
+
+STaRK полезен как образец оценки поиска по тексту и связям; QMSum — как образец поиска нужных фрагментов встречи. Их готовые benchmarks не являются приёмкой наших приоритетов. [STaRK](https://github.com/snap-stanford/stark), [QMSum](https://github.com/Yale-LILY/QMSum).
+
+### Сравниваемые варианты
+
+Сначала одна общая база: явные IDs/связи + полнотекстовый/векторный отбор. На фиксированных кандидатах сравниваются Jev и доступный локальный extractor/classifier с одинаковой схемой; сложные случаи получают отдельный генеративный разбор. Graphiti сравнивается на временных историях как отдельный вариант, если простая база не проходит этот gate. GraphRAG/BERTopic проверяются на обнаружении направлений, только если остаётся измеренная проблема покрытия.
+
+Так результат различает «не найден кандидат», «неверно понята пара» и «правильный граф, неверный приоритет». Сравнение разных полных стеков одним общим баллом скрывает причину ошибок.
+
+## 9. Конкретные этапы реализации для согласования
+
+| Этап | Ограниченный результат | Связь с существующим планом |
+|---|---|---|
+| **WG-0: корпус и критерии** | Coverage manifest всех источников; воспроизводимый sampler; размеченный набор; черновик роли с датами и источниками. Сегодня выполнен только агрегированный локальный срез. | Дополняет R0 до выбора оболочки и моделей. |
+| **WG-1: базовый граф** | Полный недорогой индекс истории, явные IDs/связи, эпизоды, baseline кандидатов; измеренный Recall@K. | Проверяемый предметный срез R1/evidence core. |
+| **WG-2: связывание и состояние** | Сравнение моделей, typed proposals, versioned decisions, обратимые merge/split, replay исправлений; отчёт качества и цены. | Обязательное доказательство semantic gate R2. |
+| **WG-3: направления и приоритеты** | Workstreams, косвенные связи, role-relative объяснения и небольшой обзор действий; сравнение с простым baseline и выбором пользователя. | Условие использования графа planner/career, до полировки их отчётов. |
+| **WG-4: shadow-пилот** | Инкрементальные обновления, backfill, ретроспекция ошибок, review-бюджет, rollback и приёмка двух недель. | Gates R3–R4; включение сценариев и расписаний отдельно согласуется. |
+
+Критерий законченного предметного слоя: система воспроизводимо находит важные направления из разных источников, объясняет текущую ситуацию и свою связь с ролью пользователя, сохраняет историю исправлений, показывает пробелы и сокращает ручную сборку контекста. Красивый граф, дешёвые вызовы и успешный запуск worker сами по себе этого не подтверждают.
+
+## 10. Просмотр и взаимодействие
+
+Основной экран — до пяти направлений/действий с причинами «почему сейчас» и покрытием. Раскрытие направления показывает людей, артефакты, решения и зависимости в один-два перехода. Фильтры: время, тип связи, принятые/предложенные, неизвестные области. Полный граф доступен для исследования, но не является ежедневным рабочим экраном.
+
+Исправление начинается с конкретного объекта/связи: «другой проект», «не моя ответственность», «решение отменено», «перенести». Оно адресует нужный слой, пересчитывает затронутые выводы и остаётся в истории. Career advisor и ретроспектор читают принятый snapshot и его gaps, а не повторно собирают всю правду из сырого архива каждый раз.
+
+## 11. Статус исследования и воспроизводимость
+
+Сделано: исследование первичных источников; чтение выбранных модулей Numen/Graphiti и официального TypeSafe skill; локальный агрегированный inventory; предложение конвейера, контрактов, приёмки и поправка очередности roadmap. [Проверенные версии и SHA256 прочитанных файлов](/Users/admin/Developer/personal-os/planning/work-graph-research-2026-10-04/source-manifest.json).
+
+Не измерены: качество моделей на нашем корпусе, фактическая цена backfill, полнота всех upstream-источников, готовность Glean для нашего доступа, скорость локального inference. Предлагаемые технологии и пороги не объявляются уже выбранными или достигнутыми. Печатные схемы R2 пока не содержат это дополнение; данный текст — актуальное исследовательское уточнение для согласования.
+
+Следующий ограниченный результат: **WG-0 — карта покрытия источников и репрезентативный набор оценки, включающий неизвестные направления и тихие обязательства.**