diff --git a/personal/projects/personal-os/personal-os-architecture-decision-2026-10-04.md b/personal/projects/personal-os/personal-os-architecture-decision-2026-10-04.md index 7255c814..81fc990a 100755 --- a/personal/projects/personal-os/personal-os-architecture-decision-2026-10-04.md +++ b/personal/projects/personal-os/personal-os-architecture-decision-2026-10-04.md @@ -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-очереди заменены этим пакетом. ## Зафиксированное решение diff --git a/personal/projects/personal-os/personal-os-best-practices-2026-10-04.md b/personal/projects/personal-os/personal-os-best-practices-2026-10-04.md index 3608fd1b..465c8e3e 100755 --- a/personal/projects/personal-os/personal-os-best-practices-2026-10-04.md +++ b/personal/projects/personal-os/personal-os-best-practices-2026-10-04.md @@ -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, до сравнения оболочек. diff --git a/personal/projects/personal-os/personal-os-evidence-graph-design-2026-10-04.md b/personal/projects/personal-os/personal-os-evidence-graph-design-2026-10-04.md index 136862c7..14db0abc 100755 --- a/personal/projects/personal-os/personal-os-evidence-graph-design-2026-10-04.md +++ b/personal/projects/personal-os/personal-os-evidence-graph-design-2026-10-04.md @@ -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. Хранилище и граница истины diff --git a/personal/projects/personal-os/personal-os-ready-systems-and-skills-2026-10-04.md b/personal/projects/personal-os/personal-os-ready-systems-and-skills-2026-10-04.md index 5103d882..9f74bf83 100755 --- a/personal/projects/personal-os/personal-os-ready-systems-and-skills-2026-10-04.md +++ b/personal/projects/personal-os/personal-os-ready-systems-and-skills-2026-10-04.md @@ -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: покрытие источников и представительский набор оценки. diff --git a/personal/projects/personal-os/personal-os-system-review-2026-10-04.md b/personal/projects/personal-os/personal-os-system-review-2026-10-04.md index ae7cff0d..292305e4 100755 --- a/personal/projects/personal-os/personal-os-system-review-2026-10-04.md +++ b/personal/projects/personal-os/personal-os-system-review-2026-10-04.md @@ -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. Паспорт плана diff --git a/personal/projects/personal-os/personal-os-system-review-index.md b/personal/projects/personal-os/personal-os-system-review-index.md index 43d6fd10..00673a1f 100755 --- a/personal/projects/personal-os/personal-os-system-review-index.md +++ b/personal/projects/personal-os/personal-os-system-review-index.md @@ -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. diff --git a/personal/projects/personal-os/personal-os-work-graph-research-2026-10-04.md b/personal/projects/personal-os/personal-os-work-graph-research-2026-10-04.md new file mode 100644 index 00000000..26b52d66 --- /dev/null +++ b/personal/projects/personal-os/personal-os-work-graph-research-2026-10-04.md @@ -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 — карта покрытия источников и репрезентативный набор оценки, включающий неизвестные направления и тихие обязательства.**