obsidian-vault/personal/projects/personal-os/personal-os-work-graph-research-2026-10-04.md

Personal OS: понимание большого потока работ

Дата: 2026-10-04. Статус: исследование и предложение архитектуры, до согласования реализации. Проверены официальные документы, статьи авторов и выбранные исходники GitHub. Репозитории не запускались. Частные данные не отправлялись исследуемым моделям; установки и расписания не создавались.

1. Решение и изменение приоритета

Первый инженерный этап — доказать восстановление структуры работ и их значимости на представительном корпусе. Сравнение оболочек LifeOS/Letta и улучшение карьерных отчётов идут после этого доказательства. Предыдущая рекомендация начать с сопоставления LifeOS и R2 меняется.

Проблема состоит из пяти отдельных задач: полнота наблюдения; выделение объектов и событий; связывание объектов между источниками; восстановление текущей ситуации; приоритизация относительно роли, целей и доступного внимания. Один хороший классификатор не гарантирует остальные четыре результата.

LifeOS шире журнала агентских действий: TELOS описывает личные цели, Atlas — активы и наблюдения. Однако прочитанные контракты не доказывают восстановление обязательств, неявных инициатив и их приоритетов из большого корпоративного архива. Обзор LifeOS остаётся полезен для пользовательского слоя. Atlas.

Рекомендация: сохранить PostgreSQL как реестр доказательств и принятых состояний; построить проверяемый конвейер извлечения и связывания с заменяемыми моделями. Jev — кандидат для узких решений внутри конвейера. Graphiti — кандидат для сравнения временных связей. Glean — коммерческий образец организации корпоративного контекста; Numen — близкий открытый прототип, требующий существенной проверки.

2. Что есть у нас фактически

Агрегаты прочитаны из локальной PostgreSQL в транзакции READ ONLY 04.10.2026, 17:45 UTC. Это доступный локальный корпус, не доказательство полноты Asana или всех источников. Машинный срез: 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.

agent/work-profile.md содержит узкий набор эпизодов, а career-notes.md помечает старые карьерные сведения как неподтверждённые. Следовательно, текущую роль и цели нельзя считать уже восстановленными. Нужны датированные факты о зонах ответственности и отдельные гипотезы. Миссия Personal OS сохраняется: самочувствие, внимание и границы рабочего дня ограничивают рабочую оптимизацию.

3. Существующие решения: что действительно подходит

3.1. Готовые системы

Решение	Подтверждённая близость к задаче	Ограничение и вывод
Glean	Граф объединяет контент, людей и активность; идентичности, роли, команды и история участвуют в персонализации.	Наиболее близкий из изученных коммерческих классов. Закрытый алгоритм; соответствие нашим источникам, индивидуальному доступу и миссии не проверено. Рассматривать продукт при доступности, архитектуру использовать как ориентир. Документация.
Numen	Открытый граф задач, PR, документов, людей и целей; urgency, briefing, MCP; Python/FastAPI, PostgreSQL, FalkorDB, Redis.	Beta; заявленные коннекторы Linear/GH/Slack/Jira/Notion/Docs не закрывают нашу тройку Asana/Zoom/Mattermost. Ниже есть конкретные ограничения кода. Источник идей и кандидат для ограниченного сравнения, не готовая замена. Репозиторий.
LifeOS / Letta / Khoj / Dify	Личный контекст, агентная среда, поиск или сценарии соответственно.	Полезны после появления достоверного предметного слоя. Их прежний рейтинг отвечал на вопрос об оболочке, а не доказывал качество понимания работ. Предыдущий обзор.

Отсутствие найденного готового продукта, закрывающего все требования, не доказывает отсутствие такого продукта вообще. В исследованных реализациях нет подтверждённого сочетания наших источников, временных решений, произвольных объектов, роли пользователя и приёмки качества приоритетов.

3.2. Что обнаружено в настоящем коде Numen

Проверен commit 0b5ac5f1d64e69f1dd2a8d3c9fec69fa9f7cf2ba; это статическое чтение выбранных модулей, не интеграционный тест.

Модуль	Наблюдение	Почему существенно для нас
link_suggester.py	Получает до 1 000 PR и до 1 000 задач; закрытые задачи исключаются. На пакет из 5 PR передаётся список задач. Предложения сохраняются pending, порог confidence — 0.4.	При нашем масштабе это ограничивает обнаружение связей с архивом и расходует контекст. Pending полезен; число confidence ещё надо калибровать.
urgency.py	В формуле compute_urgency есть частота упоминаний и давность; аргумент person_id сохраняется в результате, но не участвует в вычислении факторов.	Отбор доступных человеку объектов есть в scorer.py, однако просмотренная формула не меняет важность одной задачи в зависимости от роли. Это не наш готовый ranker.
resolution.py	Проверка равенства нормализованных имён вложена в условие их неравенства. Эта ветка недостижима.	Даже подходящая предметная модель не означает надёжную реализацию сопоставления.

3.3. Граф и поиск

Подход	Что переиспользовать	Что он не доказывает
Graphiti	Инкрементальное извлечение, сопоставление сущностей, временные связи, поиск.	Корректность идентичностей, отменённых решений и пользовательских приоритетов на нашем корпусе. Python и дополнительное graph storage увеличат стоимость эксплуатации. GitHub.
Microsoft GraphRAG	Построение сообществ и обзоров большого корпуса; полезно найти крупные направления, а не только ответ на уже заданный вопрос.	Сообщество не равно проекту. FastGraphRAG использует совместную встречаемость, поэтому его ребро не означает «блокирует» или «решено». Dataflow, методы.
HippoRAG 2 / LightRAG	Кандидаты для поиска связанных фрагментов через несколько переходов.	Retrieval benchmark не измеряет актуальность обязательств и качество личного плана. Personalized PageRank в HippoRAG персонализирован относительно запроса; это не модель карьерных приоритетов. HippoRAG, статья, LightRAG.

Graphiti просмотрен глубже: commit 5d47d4d0182aa6350edeb435b734837a88ed9738. В node_operations.py есть ограниченный набор кандидатов (15, cosine threshold 0.6) и последующее разрешение через LLM. Это полезная декомпозиция. Схлопывание одинаково нормализованных имён внутри эпизода требует отдельной проверки на омонимах. В edge_operations.py дубликаты и противоречия обрабатываются отдельно, поддерживаются временные интервалы; семантическое решение всё равно принимает модель. Наличие timestamp не гарантирует верность решения.

В просмотренном дереве Graphiti есть Neo4j/FalkorDB/Kuzu/Neptune drivers; PostgreSQL driver не обнаружен. Поэтому Graphiti — либо изолированный сравнительный стенд с перестраиваемым графом, либо источник адаптируемых контрактов. Второй независимый реестр принятой правды нам не нужен.

LazyGraphRAG полезен как идея переноса части затрат на момент запроса. Статья Microsoft описывает исследования и интеграции; это не достаточное основание обещать готовый открытый пакет для нашего внедрения. Источник.

3.4. Дешёвое извлечение, классификация и сопоставление

Кандидат	Подходящая функция	Когда выбирать
Jev / TypeSafe	Выбор из заданных вариантов: тип сигнала, отношение пары объектов, подтверждение конкретного утверждения.	Проверить первым как API-кандидата для ограниченных решений. Нужны готовые кандидаты и вариант unknown. Введение.
GLiNER2	Извлечение сущностей, классификация, структур и отношений по заданной схеме; потенциально локальное исполнение.	Сравнить с API на EN/RU и реальном оборудовании. Извлечение имени ещё не определяет идентичность человека между системами. GitHub, статья.
SetFit	Компактная классификация по размеченным примерам, включая multilingual encoders.	После стабилизации категорий и появления исправлений. Не решает открытие совершенно новых типов связей. GitHub.
Splink	Вероятностное сопоставление структурированных записей с предварительным отбором пар.	Для людей/организаций при наличии нескольких полей; не для вывода смысла всего обсуждения. Документация.
BERTopic / Snorkel	Обнаружение тем / получение слабых меток из нескольких правил.	Вспомогательные инструменты: поиск неразобранных направлений и bootstrap. Тематическая близость и слабая метка не становятся фактом. BERTopic, Snorkel.

Эти решения — альтернативы внутри этапов. Одновременная установка всех библиотек не предлагается.

4. Jev: конкретное место и экономика

Под jev здесь понимается найденный официальный TypeSafe Jev. На дату проверки модель jev-1.13.0 стоит $0.042 за миллион входных токенов, выход не тарифицируется. Основной язык обучения английский; русский надо проверять отдельно. Для воспроизводимости фиксируется версия, а не latest. Модель и цена.

В официальном entity alignment cookbook уже есть подход «предварительно отобранная пара → разные / одинаковые / требуется проверка». Это ближе к нашей задаче, чем просьба одной модели построить весь граф. Но демонстрация на каталогах товаров не подтверждает качество на людях, задачах и косвенных договорённостях.

Jev не генерирует произвольные новые объекты/объяснения. Документация отдельно предупреждает о многошаговых рассуждениях, шумном большом контексте, порядке вариантов и вычислении дат/чисел. Поэтому IDs и календарные сравнения делает код; генеративная модель или extractor выделяет неизвестные объекты; Jev оценивает короткие кандидаты. Ограничения.

Пример стоимости, не измерение нашего корпуса: 100 000 эпизодов × 1 500 входных токенов = 150 млн токенов, или $6.30 за один проход. Если дополнительно проверять 10 пар на эпизод по 600 токенов — ещё 600 млн, $25.20. Отдельно оплачиваются извлечение, embeddings, сложные случаи, повторы и хранение. Число stories не равно числу эпизодов и не даёт готовую смету. Реальная единица сравнения — стоимость 1 000 обработанных эпизодов при одинаковой полноте и качестве, плюс минуты проверки человеком.

Есть официальный TypeSafe skill. Прочитан как материал для разработки; не установлен и не применён как инструкция этой сессии. Его можно использовать после выбора модели, сохранив наши контракты unknown, provenance и локальной калибровки.

5. Предлагаемый data flow

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 используются повторно. Дополнительные логические записи ниже — предложение, не применённая миграция:

Запись	Обязательные поля / смысл
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, 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 прочитанных файлов.

Не измерены: качество моделей на нашем корпусе, фактическая цена backfill, полнота всех upstream-источников, готовность Glean для нашего доступа, скорость локального inference. Предлагаемые технологии и пороги не объявляются уже выбранными или достигнутыми. Печатные схемы R2 пока не содержат это дополнение; данный текст — актуальное исследовательское уточнение для согласования.

Следующий ограниченный результат: WG-0 — карта покрытия источников и репрезентативный набор оценки, включающий неизвестные направления и тихие обязательства.