obsidian-vault/personal/projects/personal-os/personal-os-data-analysis-workflow-2026-10-09.md

---

Runtime 14.10.2026: старый Asana collector заменён постоянным worker в основной personal_os. Windmill schedule каждые пять минут, live project/personal rosters каждые 15 минут, events cursors, independent retries и совместимая legacy read projection. Первый live pass перечитал все 28 проектов и нашёл 35 620 memberships; начальный refresh backlog показан отдельно в dashboard. Автоматический scheduled batch выполнил 3 000 GET и обновил 648 задач без ошибок. Контракт и проверка.

date: '2026-10-09' status: local-rlm-stand-ready tags:

• personal-os
• data-analysis
• workflow
• knowledge-graph updated: '2026-10-14'

---

Personal OS — анализ выгружаемых данных: контекст, связывание и workflow

Историческая проверка launchd до замены worker 14.10.2026: com.personalos.asana-expansion-e1 не найден в gui/501. Поэтому запись о загруженном агенте 10.10 ниже не подтверждает текущий фоновый backfill. com.personalos.work-evidence и com.personalos.db-browser загружены и работают.

Историческая сверка E1 до замены worker 14.10: 21/28 проектов по ID scan 06.10, 35 080/35 080 memberships, 11 недоступных прямых задач и 1 685 отсутствующих внешних dependency targets. Это не новый live-ID обход. Текущий план E1–E5.

Дата исходного исследования: 2026-10-09, Asia/Bishkek. Обновлено: 2026-10-14 по сохранённым результатам БД, двум resolver jobs и проверке дашборда.

Статус на 14.10.2026: локальный стенд прошёл синтетические проверки и реальные одиночные извлечения на Asana. В основной БД 486 анализов / 486 работ (480 completed), все 12 244 claims — кандидаты. Рабочая выборка и схема v2 существуют; независимый эталон качества и semantic acceptance не завершены. RLM-циклы ранних прогонов не дошли до FINAL. Отдельный resolver ворктри через Windmill прошёл две попытки, 7/7 цитат и оба input hash проверены; смысловые связи не приняты. Архивный пакет выполнен вручную, постоянный incoming-контур и graph runtime не подключены. Подробности: work-claims-results-2026-10-12 и personal-os-rlm-stand-results-2026-10-10.

Согласованный порядок: проверяемый локальный RLM на небольшом наборе связных работ → расширение на архив → подключение incoming. Подробный текущий статус и шаги — в разделе 9.

Связанные документы: personal-os-action-plan-2026-10-05, personal-os-six-layer-analysis-2026-10-05, personal-os-evidence-graph-design-2026-10-04, personal-os-system-review-index.

1. Задача

Превратить выгрузки Asana, GitHub, Mattermost, Zoom и проектные заметки в общий рабочий контекст:

• к какой работе, инициативе, компоненту или процессу относится запись;
• как она связана с другими материалами;
• что изменилось: предложение, решение, отмена, реализация, review, выпуск или открытая работа;
• как это пересекается с текущими задачами, опытом и областью Алекса;
• какие проверенные сведения должны получить планирование, career-сценарии и ретроспекция.

Связующее звено — общий слой контекста. Состояние проекта (project truth) — одна из его обновляемых проекций, наряду с историей решений, участием и обязательствами.

Текущий прототип project-evidence.js / project-truth.js с ручным реестром двух случаев помечен [УДАЛИТЬ] в project-truth-analyzer. Это решение относится к прототипу, а не к требованию понимать состояние проектов. Код этим обсуждением не удалён. Общий аналитический workflow не был запущен; содержательная сводка недели в чате была ручным анализом, а не результатом настроенного анализатора.

2. Что проверено в выгрузке Asana

Текущая E1-догрузка использует сохранённый scope от 6 октября:

• 28 проектов для полного перечисления задач: 26 по признаку follower при составлении scope и два дополнительных пилотных проекта.
• 3 244 отдельно выбранных task IDs: My Tasks, following, delegated и настроенные задачи старого project-truth.
• В остальных проектах собираются выбранные задачи и их окружение, а не весь проект.
• Внутри full-проектов код не задаёт фильтров по исполнителю, давности или завершённости. Он собирает историю событий и комментариев, рекурсивные подзадачи, связи dependencies/dependents; предусмотрена отдельная догрузка карточек внешних зависимостей.
• Ограничение 3 000 API-запросов за запуск и 600 на проект разбивает процесс на возобновляемые порции; это не фильтр смысловой релевантности.
• В 28 проектах перечислено 32 390 уникальных задач до рекурсивного обхода подзадач. Эта цифра не является размером всего собранного корпуса.
• С 10.10 запись E1 идёт в основную personal_os после восстановления и подтверждённого импорта; до этого использовалась отдельная тестовая БД. Её историческая догрузка отличается от обычного sync, где есть окно изменений 30 дней для полного обновления проектов.

В прочитанном 9 октября срезе E1 среди 31 943 загруженных основных задач:

Признак	Число задач
Есть теги	7 242
Есть custom fields	28 771
Текущий assignee — Алекс	812
Создатель — Алекс	622
Есть сохранённые события, автором которых указан Алекс	2 594

В последней группе найдено 15 811 событий. Группы пересекаются; числа нельзя складывать. Авторство события — исходный признак для отбора, а не уже проверенная классификация участия. Выгрузка ещё меняется, поэтому это датированный срез, не финальный отчёт полноты.

Среди custom fields встречаются Product Area(s), Functional Team, Objective, Priority, Reviewer. Новая выгрузка запрашивает теги, custom fields, авторов событий и участников. Алекс указал, что часть старых багов уже размечена корпоративной AI-системой; точное место хранения, происхождение и пригодность этих AI-меток отдельно не проверены.

Код уже извлекает Asana task IDs из поддерживаемых ссылок в описаниях GitHub PR. Такие ссылки следует переносить как явные связи. Утверждение «практически каждый PR связан с задачей» — наблюдение Алекса; доля покрытия отдельно не измерена.

Основания: scope E1, построение scope, обход задач, runner догрузки, связи PR → Asana.

3. Контекст и межсферная релевантность

Запись рассматривается в окружении

Для подзадачи нужны собственный текст, цепочка родителей, все memberships, существенные комментарии, зависимости и связанные материалы. Для сообщения — исходное сообщение, reply/thread, участники и связанные задачи. Короткое «перенести кнопку» может получить смысл только из родителя; отдельное «отменяем» — из предшествующего обсуждения.

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

Собственное содержание и унаследованный контекст различаются. Родитель объясняет предмет подзадачи; его исполнитель, статус или все темы не должны автоматически приписываться ребёнку. При изменении родителя проверяется, какие зависимые представления требуют обновления.

Пример: AI Chat → главное окно → toolbar

Работа в чужой продуктовой сфере может затронуть область Алекса. Обсуждение AI Chat становится релевантным через изменение точки входа в главное окно или toolbar, даже без имени Алекса и без прямого совпадения ключевых слов.

Желаемый путь:

работа над AI Chat → меняет точку входа → затрагивает toolbar → пересекается с областью Алекса

После обнаружения пути нужно определить характер пересечения: полезно знать, нужна консультация/review, есть зависимость или подтверждённое обязательство. Пересечение само по себе не назначает ответственность.

Поэтому «Алекс уже трогал эту задачу» — критерий приоритета глубокой обработки истории, но не граница обнаружения нового контекста. Неизвестные ранее области и новые сущности должны оставаться обнаружимыми.

4. Что означает «токенизирование» задачи или сообщения

Рабочее предложение — контекстное смысловое представление, а не список ключевых слов.

У каждой записи сохраняются:

1. Оригинал, source ID/URL, версия или hash, время события и получения.
2. Явное окружение: проектные memberships, родители, тред, участники, ссылки.
3. Краткое описание смысла с контекстом.
4. Структурированные утверждения: что затронуто, какое изменение предложено/принято, отношения между объектами, область и время действия.
5. Основания каждого вывода: конкретные фрагменты оригиналов; неоднозначности и альтернативы.
6. Версия метода обработки для повторного прогона.

Для примера AI Chat представление могло бы содержать функцию «AI Chat», компоненты «главное окно / toolbar», изменение «добавить точку входа», характер записи «предложение» и ссылки на текст задачи/родителя. Это пример желаемого результата, не выполненный анализ конкретной задачи.

Для поиска полезны несколько представлений:

• оригинальный текст — точный поиск и проверка;
• описание записи с контекстом — смысловой поиск;
• отдельные утверждения об изменениях — поиск по воздействиям.

Embeddings помогают находить смыслово близкие материалы. Один вектор длинной задачи может скрыть небольшое важное изменение, поэтому отдельные утверждения стоит индексировать отдельно. Смысловая близость — средство поиска кандидатов; принятую связь подтверждают исходные материалы.

5. Поэтапная обработка корпуса

Исходное предложение Алекса: рамочно разметить крупные сферы — баги браузера, документацию, onboarding, company processes; затем индивидуально обработать историю своих работ с поиском по БД; последовательно разобрать документацию; восстановить текущие работы коллег вокруг задач на себе.

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

Этап	Обработка	Результат
1. Структурная основа	Весь корпус: IDs, memberships, вложенность, участники, теги, custom fields, явные PR/task links	Связанный каталог без модельных догадок
2. Рамочная разметка	Описания проектов, разделов и родителей; готовые метки; выборочные задачи и исключения	Пересекающиеся области с границами и неизвестностями
3. Текущие задачи на Алексе	Полный контекст каждой работы и поиск по всему корпусу	Текущий scope, зависимости, открытые вопросы
4. История участия	Работы и последовательности задач/обсуждений/PR, с которыми Алекс работал	История решений, опыт, аналоги текущих проблем
5. Последовательное расширение	Например, каждая работа в документации с поиском внутри и вне раздела	Более полное покрытие выбранной области
6. Пропуски и incoming	Неотнесённые записи, выборки из других областей, новые изменения	Новые пересечения и обновление контекста

Проект Asana — исходный контейнер, а не окончательная смысловая категория. Раздельно учитываются тип работы, продуктовая область, затронутые компоненты и инициатива. Одна задача может относиться к документации, AI Chat, macOS и onboarding одновременно.

Первые группы направляют поиск, но не запрещают выход за их пределы. Необработанные материалы остаются доступными для поиска. Нельзя заранее утверждать, что «большая часть уже понята», только потому что записи получили bucket.

Для старых багов сначала используются готовые метки и тематические группы; глубокая обработка начинается с личного участия и найденных пересечений. Новая задача может впервые сделать старый баг полезным контекстом.

6. Агентский поиск и связывание

Единица глубокой обработки — связная работа или эпизод. Родитель с подзадачами может анализироваться одним пакетом, с отдельным сохранением результатов для каждого объекта. Большие работы делятся на пакеты с общей картой контекста. Сообщение хранится отдельно, но понимается внутри треда.

Для каждого пакета:

1. Прочитать исходную работу и явное окружение.
2. Выделить направления поиска: цель, компонент, аналогичная проблема, зависимость, предыдущее решение.
3. Собрать кандидатов через точные ссылки, текстовый и смысловой поиск, теги и графовые пути.
4. Оценить соответствие кандидатов, прочитать подходящие оригиналы и при необходимости уточнить поиск.
5. Сохранить обоснованные отношения, время и неизвестности.

Полезная методика — retrieve → rerank: широкий сбор кандидатов, затем более дорогая оценка ограниченного набора. Это не требует сравнивать агентом каждую задачу с каждой другой задачей. Документация Sentence Transformers.

Поиск имеет ограниченный бюджет и сохраняет нерешённые вопросы; количество расширений и условия остановки нужно определить в испытании. Повторяющиеся запросы и контекст кэшируются. Уже извлечённые связи используются в следующих проходах. Сомнительное сопоставление остаётся кандидатом, а не становится доказанным фактом из-за повторения в сводках.

Scope коллег восстанавливается параллельно, когда они встречаются в окружении: активные задачи, недавние действия, review, решения и зависимости. Историческое участие хранится отдельно от текущей ответственности. Имена и роли связываются по проверяемым источникам.

7. Архив и incoming используют один механизм

Предлагаемый цикл:

изменение → явные связи → поиск контекста → AI-разбор эпизода → сохранение изменений → обновление затронутых представлений

Agent run на каждое событие технически возможен. Практическая единица — изменившаяся задача или связный тред: несколько событий могут выражать одно изменение смысла. Технические повторы не должны повторно запускать одинаковый анализ.

• Архив: возобновляемые батчи, порядок событий, сохранённый прогресс и возможность replay.
• Incoming: очередь изменений, объединение связанных событий, обработка нового содержания.
• Общее: source IDs, версия/hash входов, версия обработки, основания выводов, обновление только затронутого контекста.

Старое событие, загруженное сегодня, не должно отменять более новое решение только из-за времени получения. Нужно различать время события и время загрузки.

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

8. Выбор графа и готовых систем остаётся открытым

После обновления плана 10 октября первоочередная проверка — локальный RLM на небольшом наборе связных работ. Сравнение Graphiti/Cognee проводится позже, если измеренные задачи хранения и поиска требуют такого компонента; развёрнутый стенд пока не содержит этих систем.

Нужно разделить три решения:

• Модель смысла: какие объекты, отношения, источники и времена мы представляем.
• Механизм обработки и поиска: что берём из готовой системы.
• Хранилища и эксплуатация: какие backend нужны выбранному механизму.

Предыдущие документы задают PostgreSQL как реестр исходных/принятых данных и допускают дополнительный перестраиваемый графовый индекс в испытании. Это не доказывает, что собственный PostgreSQL-граф уже является лучшим аналитическим решением. Конкретную архитектуру нужно оценить на данных.

Кандидат	Готовые механизмы	Вопросы испытания
Graphiti	Эпизоды-источники, извлечение и сопоставление сущностей, отношения с периодами действия, инкрементальные обновления, гибридный поиск, bulk ingestion	Asana/GitHub IDs, отмены, поздний backfill, ошибочные merge, контекст родителей, межсферные связи
Cognee	Настраиваемые pipelines и DataPoints, происхождение данных, relational/vector/graph storage, инкрементальная обработка	Использование готовых меток и структуры, межисточниковый поиск, изменение задачи, представление текущего состояния
Явные связи + обычный поиск	Существующие IDs, текстовый поиск и структурные переходы	Исходное качество, относительно которого измеряется польза готовых компонентов

По архитектуре Graphiti ближе к меняющимся отношениям во времени; Cognee — к организации и поиску разнородного корпуса. Это исследовательская оценка, не результат сравнительного прогона. Graphiti, эпизоды и bulk ingestion, архитектура Cognee, DataPoints.

Graphiti передаёт при извлечении отношений предыдущие эпизоды, типы связей и дополнительные инструкции. Это позволяет настраивать контекст извлечения, но не обеспечивает правильную сборку Asana-иерархии автоматически. Код извлечения.

Дополнительный методический ориентир — глобальный обзор областей и локальное раскрытие контекста в GraphRAG. Глобальный поиск использует сводки сообществ; локальный сочетает графовые данные с исходными текстами. Можно использовать этот принцип без обязательного внедрения GraphRAG. Обзор методов.

Рабочая гипотеза — адаптация готового механизма плюс предметные правила и сборщики. Не нужно заранее выбирать исключительно самописный контур или запускать постоянные параллельные графы.

9. Локальный RLM: текущий стенд и пошаговый план

9.1. Что развёрнуто и проверено 10 октября

Стенд находится в /Users/admin/Developer/personal-os/tools/rlm-lab; инструкция запуска — README. Это отдельное окружение для проверки RLM, без подключения рабочих источников и записи в БД Personal OS.

Компонент	Фактическое состояние
RLM	fast-rlm 0.4.3, Deno 2.9.6, Python в локальной .venv
MLX	mlx-lm 0.31.1, mlx / mlx-metal 0.31.1
Основной профиль qwen27b	mlx-community/Qwen3.8-27B-4bit, revision 10c35caafbb80f7dc6a7a432cdd11af10a6d4818; веса скачаны
Профиль сравнения coder30b	mlx-community/Qwen3-Coder-30B-A3B-Instruct-4bit, revision 6e302ea604ad9ab206367e2c501d1571023e7b6d; веса скачаны
API	http://127.0.0.1:8767/v1; при обновлении заметки health подтвердил qwen27b, backend_ready: true
9B и смешанная маршрутизация	Не подключены; конкретный checkpoint 9B ещё предстоит выбрать

Одновременно загружена одна модель; корневые и дочерние вызовы используют активный профиль. MLX закреплён на 0.31.1 после воспроизведённого сбоя генерации с 0.31.2; оба профиля прошли проверку на закреплённой версии.

Синтетическая проверка прошла для обеих моделей: реальное выполнение кода в REPL, дочерний вызов на глубине 1, ответ ребёнка 42, итог {"total":42,"label":"synthetic"}, проверка JSON Schema. Проверены офлайн-загрузка пакетов REPL, блокировка чтения вне каталога стенда, внешней сети и запуска процессов. Это подтверждает работоспособность инфраструктуры; качество поиска, смысловых связей и временного состояния на рабочих данных пока не оценивалось. Длительность этих коротких прогонов не используется для выбора победителя.

Основания: сводка проверок, манифест Qwen, манифест Coder, конфигурация.

Начальные ограничения: глубина 2, максимум 16 модельных вызовов на прогон и 8 на агента, общий бюджет completion 16 384 токена, до 2 048 токенов ответа на вызов, 300 секунд на прогон. Лимиты — исходные настройки, их достаточность проверяется на выбранных работах.

У каждого прогона сохраняются снимок входа, hash, модель и revision, настройки и версии пакетов, трасса вызовов, результат и статус. Полные запросы и ответы API также журналируются локально. .runtime и datasets/private исключены из Git. Внешняя сеть нужна для установки и скачивания весов; подготовленный REPL использует локальные пакеты и обращается только к локальному API. Сервис запускается вручную, автозапуска после перезагрузки нет.

Состояние списка задач на 14.10: экспорт рабочих данных и schema v2 реализованы, архивный батч выполнен. Остаются независимый эталон/semantic acceptance, общий поиск по корпусу, смешанные вызовы с 9B и incoming. Датированные этапы ниже сохраняют первоначальный план и не заменяют текущий статус выше.

9.1a. Дополнение 2026-10-10 (вечер): выборка и первый прогон на рабочих данных

Полные результаты обоих прогонов, ошибки и решения: personal-os-rlm-stand-results-2026-10-10.

• Выборка подготовлена: 14 связных работ из personal_os (855 задач, 10 603 stories, 195 ссылок на PR) плюс Mattermost (1 465 сообщений за 1–9 октября), 7 транскриптов Zoom, 71 строка activity_daily и 9 daily briefs. Каталог tools/rlm-lab/datasets/private/sample-2026-10-10/, экспорт scripts/rlm-sample-export.js. Состав — предложение, не утверждён.

• Первый прогон на одной работе (Duck.ai → меню приложения, контрольный случай без упоминания Алекса): шесть RLM-прогонов на Qwen27B и Coder30B не дошли до FINAL; одиночный вызов с заранее собранным контекстом на Qwen27B дал проверяемый JSON (10/10 улик по gid подтверждены, одно перепутанное авторство, завышено состояние «released»). Детали, исправления стенда и выводы: tools/rlm-lab/datasets/private/sample-2026-10-10/eval/report-2026-10-10.md.

• Исправлено в стенде: падение mlx_lm на tool-call токене (обёртка backend.py), таймауты и бюджеты вызовов подняты (config.json). Шаг 9.2.3 и 9.2.4 ниже остаются актуальными; шаг 9.2.1 выполнен в части подготовки, выбор состава за Алексом.

• Второй прогон (тот же день): одиночный вызов Qwen27B по схеме v2 (утверждения о состоянии с уликами) на 4 работах — все четыре дали валидный JSON, 80 из 80 улик существуют, роли Алекса и хронология верны. Две системные ошибки: релиз помечается подтверждённым по движению на release board или бот-упоминанию; закрытая подзадача читается как «реализовано» (CoreData в VSCode-миграции, хотя подход отменён). Эти ошибки не лечатся промптом, нужны правила в коде перед принятием. Утверждения лежат как candidate в work_claims (миграция 007). Готовые графовые продукты для этого шага не нужны. Отчёт: eval/report-v2-2026-10-10.md.

• Вечер 2026-10-10: вся система описана как потоки в локальном Windmill (скелеты, без логики); одиночное извлечение из второго прогона — поток f/analyse/work_claims_extract со статусом PROPOSED. См. personal-os-windmill-system-map-2026-10-10.

9.2. Дальнейшие шаги и условия перехода

1. Выбрать данные после развёртывания стенда. Начальный ориентир — 10–15 связных работ, а не случайные отдельные записи. Алекс выбирает состав; для каждой работы собрать оригиналы, родителей/подзадачи, memberships, существенные комментарии, PR и связанные обсуждения. Зафиксировать snapshot, IDs, версии/hash, время события и загрузки, недостающие материалы. Реальные данные в стенд пока не загружать до выбора.
2. Зафиксировать проверяемый результат и эталон. Задать схему: предмет работы, отношения, предложение/решение/отмена/реализация/выпуск, время, конкретные источники и фрагменты, неизвестности. Составить независимые ожидаемые ответы по оригиналам; разделить примеры для настройки и отложенной проверки по работам, избегая утечки соседних записей.
3. Подключить чтение и поиск на выбранном snapshot. Реализовать доступ к оригиналам и явным связям, затем текстовый поиск кандидатов; смысловой поиск и rerank добавлять по измеренным пропускам. Запустить полный цикл одной работы: чтение → поиск → дочитывание → обоснованные выводы. Ни результат модели, ни сходство текстов не заменяют источник.
4. Сравнить режимы на одинаковых данных. Базовый уровень — явные связи и обычный поиск; отдельно — модель с заранее собранным контекстом; затем RLM с Qwen27B и RLM с Coder30B. В обоих RLM-прогонах root и children используют одну модель. Зафиксировать одинаковые входы, лимиты и версии, повторы и все неудачные прогоны.
5. Расширить проверку до 60–100 связанных эпизодов. После исправления ошибок малого набора включить текущие задачи, историю участия, документацию/onboarding/processes, старые баги и сохранённые новые изменения. Применить контрольные случаи ниже, отдельно проверяя межсферные пропуски и ошибочное наследование ответственности. Это будущий этап, корпус ещё не подготовлен.
6. Проверить дешёвые дочерние вызовы 9B. Выбрать доступный MLX checkpoint, реализовать маршрутизацию и сначала поручить ограниченные задачи: выбор кандидатов или извлечение подтверждающих фрагментов. Сравнить с дочерними вызовами основной модели по качеству, времени, памяти и стоимости переключения моделей. Не считать смешанную схему готовой до этих проверок.
7. Выбрать необходимый механизм хранения и поиска. По результатам испытания решить, достаточно ли явных связей и обычного поиска или нужен готовый графовый компонент. Cognee и Graphiti остаются кандидатами для отдельного сравнения на том же эталоне; их проверка не предшествует рабочему RLM-срезу и ещё не выполнялась.
8. Расширить обработку на архив. Подготовить структурный каталог всего доступного корпуса; запускать возобновляемые порции: текущие работы → история участия → документация → другие области и пропуски. Сохранять основания, версии и прогресс; поиск не ограничивать уже назначенными категориями. До массового прогона оценить пропуски, ресурсный бюджет и правила принятия связей.
9. Подключить incoming тем же механизмом. Сначала replay сохранённых изменений, затем наблюдение за новым потоком: дедупликация, объединение событий по работе/треду, различение event time и received time, обновление зависимых представлений. После проверки согласованности архивного и инкрементального результата подключать потребителей общего контекста.

9.3. Контрольные случаи и оценка качества

Обязательные случаи:

• Подзадача без слов «toolbar», смысл которой раскрывается через родителя.
• AI Chat затрагивает главное окно/toolbar, без mention Алекса.
• AI Chat затрагивает только серверную часть; UI-ответственность не должна приписываться.
• Старый баг становится релевантным через новую работу.
• Одна задача принадлежит нескольким проектам и смысловым областям.
• Явная связь PR → Asana сохраняется без модельного сопоставления.
• Предложение позднее отменено; закрытая задача не считается доказательством реализации.
• Источник явно сообщает о выпуске хотфикса; анализ учитывает это сообщение вместе с историей, не теряет его при группировке.
• Поздний backfill не перезаписывает новое состояние старым.
• Близкие по названию работы остаются разными при разных источниках и scope.

Отдельно измерять:

• полноту найденных кандидатов и пропущенный релевантный контекст, включая межсферные пересечения;
• точность и полноту подтверждённых связей, ложные связи и merge;
• правильность временного состояния и различение участия, релевантности и ответственности;
• долю корректных неизвестностей и выводов без подтверждающего фрагмента;
• покрытие рамочной разметкой отдельно от покрытия проверенными связями;
• длительность, модельные вызовы/токены, пиковую память, повторы, сбои и ручные исправления.

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

Следующий ожидаемый результат: выбранный малый набор и рабочий проверяемый срез RLM на нём. Результат последующих испытаний: «история + новое изменение → найденный контекст → проверяемые связи/состояние», оценка массового прогона и обоснованный выбор моделей и готового компонента. Малый набор и одиночный рабочий срез получены; полный RLM-цикл, независимое качество и обработка incoming ещё не приняты. См. датированные результаты выше.

10. Открытые вопросы

• Где находятся корпоративные AI-метки, каковы их категории, история и ошибки?
• Какие действия над задачей считаются разными видами участия Алекса?
• Как подтверждать текущие области и роли, отличая их от исторического опыта?
• Какая схема контекстных пакетов сохраняет смысл при приемлемом размере?
• Какое качество покажут Qwen3.8-27B и Qwen3-Coder-30B-A3B на выбранных работах; какой checkpoint 9B пригоден для дочерних вызовов и оправдана ли смешанная маршрутизация?
• Какой механизм хранения/поиска нужен по результатам этих проверок?
• Какой бюджет поиска/обработки нужен архиву и incoming?
• Какие классы смысловых связей можно принимать автоматически после оценки, а какие требуют дополнительной проверки?
• Как обновлять зависимые представления после изменения родителей, ролей или исходных решений?

Эти вопросы остаются частью исследования. Сам факт назначения bucket, существования графового ребра или получения уверенного ответа модели не подтверждает понимание текущей работы.