From be7cbbf8d3dd5e7731505c001b1b36c6aa8973bf Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Fri, 9 Oct 2026 23:55:46 +0600 Subject: [PATCH] [2026-10-09] eagle: personal/projects/personal-os/personal-os-data-analysis-workflow-2026-10-09.md --- ...al-os-data-analysis-workflow-2026-10-09.md | 226 ++++++++++++++++++ 1 file changed, 226 insertions(+) create mode 100644 personal/projects/personal-os/personal-os-data-analysis-workflow-2026-10-09.md diff --git a/personal/projects/personal-os/personal-os-data-analysis-workflow-2026-10-09.md b/personal/projects/personal-os/personal-os-data-analysis-workflow-2026-10-09.md new file mode 100644 index 00000000..bc1e4b53 --- /dev/null +++ b/personal/projects/personal-os/personal-os-data-analysis-workflow-2026-10-09.md @@ -0,0 +1,226 @@ +--- +date: '2026-10-09' +status: research-proposal +tags: + - personal-os + - data-analysis + - workflow + - knowledge-graph +--- +# Personal OS — анализ выгружаемых данных: контекст, связывание и workflow + +Дата: 2026-10-09, Asia/Bishkek. Сводка исследования и обсуждения с Алексом. + +**Статус:** направление обработки обсуждено; конкретный graph runtime, модели и workflow ещё не выбраны по результатам испытаний. Описанные ниже этапы — предложение, а не отчёт о работающих агентах. Сохранение этой заметки не запускает обработку, не меняет сборщики и расписания. + +Связанные документы: [[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 уникальных задач **до** рекурсивного обхода подзадач. Эта цифра не является размером всего собранного корпуса. +- Запись E1 идёт в отдельную тестовую БД. Её историческая догрузка отличается от обычного 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](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-scope-2026-10-06-v3.json), [построение scope](/Users/admin/Developer/personal-os/scripts/asana-expansion-scope.js), [обход задач](/Users/admin/Developer/personal-os/asana-coverage-backfill.js), [runner догрузки](/Users/admin/Developer/personal-os/scripts/asana-expansion-launch-agent.js), [связи PR → Asana](/Users/admin/Developer/personal-os/gh-snapshot.js). + +## 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](https://www.sbert.net/examples/sentence_transformer/applications/retrieve_rerank/README.html). + +Поиск имеет ограниченный бюджет и сохраняет нерешённые вопросы; количество расширений и условия остановки нужно определить в испытании. Повторяющиеся запросы и контекст кэшируются. Уже извлечённые связи используются в следующих проходах. Сомнительное сопоставление остаётся кандидатом, а не становится доказанным фактом из-за повторения в сводках. + +Scope коллег восстанавливается параллельно, когда они встречаются в окружении: активные задачи, недавние действия, review, решения и зависимости. Историческое участие хранится отдельно от текущей ответственности. Имена и роли связываются по проверяемым источникам. + +## 7. Архив и incoming используют один механизм + +Предлагаемый цикл: + +`изменение → явные связи → поиск контекста → AI-разбор эпизода → сохранение изменений → обновление затронутых представлений` + +Agent run на каждое событие технически возможен. Практическая единица — изменившаяся задача или связный тред: несколько событий могут выражать одно изменение смысла. Технические повторы не должны повторно запускать одинаковый анализ. + +- **Архив:** возобновляемые батчи, порядок событий, сохранённый прогресс и возможность replay. +- **Incoming:** очередь изменений, объединение связанных событий, обработка нового содержания. +- **Общее:** source IDs, версия/hash входов, версия обработки, основания выводов, обновление только затронутого контекста. + +Старое событие, загруженное сегодня, не должно отменять более новое решение только из-за времени получения. Нужно различать время события и время загрузки. + +Планировщик, career-сценарии и ретроспекция должны читать общие версии контекста с источниками и неизвестностями. Требования к этим потребителям сохраняются; их работа не считается запущенной по факту существования этого плана. + +## 8. Выбор графа и готовых систем остаётся открытым + +Нужно разделить три решения: + +- **Модель смысла:** какие объекты, отношения, источники и времена мы представляем. +- **Механизм обработки и поиска:** что берём из готовой системы. +- **Хранилища и эксплуатация:** какие backend нужны выбранному механизму. + +Предыдущие документы задают PostgreSQL как реестр исходных/принятых данных и допускают дополнительный перестраиваемый графовый индекс в испытании. Это не доказывает, что собственный PostgreSQL-граф уже является лучшим аналитическим решением. Конкретную архитектуру нужно оценить на данных. + +| Кандидат | Готовые механизмы | Вопросы испытания | +|---|---|---| +| Graphiti | Эпизоды-источники, извлечение и сопоставление сущностей, отношения с периодами действия, инкрементальные обновления, гибридный поиск, bulk ingestion | Asana/GitHub IDs, отмены, поздний backfill, ошибочные merge, контекст родителей, межсферные связи | +| Cognee | Настраиваемые pipelines и DataPoints, происхождение данных, relational/vector/graph storage, инкрементальная обработка | Использование готовых меток и структуры, межисточниковый поиск, изменение задачи, представление текущего состояния | +| Явные связи + обычный поиск | Существующие IDs, текстовый поиск и структурные переходы | Исходное качество, относительно которого измеряется польза готовых компонентов | + +По архитектуре Graphiti ближе к меняющимся отношениям во времени; Cognee — к организации и поиску разнородного корпуса. Это исследовательская оценка, **не результат сравнительного прогона**. [Graphiti](https://github.com/getzep/graphiti), [эпизоды и bulk ingestion](https://help.getzep.com/graphiti/core-concepts/adding-episodes), [архитектура Cognee](https://docs.cognee.ai/core-concepts/architecture), [DataPoints](https://docs.cognee.ai/core-concepts/building-blocks/datapoints). + +Graphiti передаёт при извлечении отношений предыдущие эпизоды, типы связей и дополнительные инструкции. Это позволяет настраивать контекст извлечения, но не обеспечивает правильную сборку Asana-иерархии автоматически. [Код извлечения](https://github.com/getzep/graphiti/blob/main/graphiti_core/utils/maintenance/edge_operations.py). + +Дополнительный методический ориентир — глобальный обзор областей и локальное раскрытие контекста в GraphRAG. Глобальный поиск использует сводки сообществ; локальный сочетает графовые данные с исходными текстами. Можно использовать этот принцип без обязательного внедрения GraphRAG. [Обзор методов](https://microsoft.github.io/graphrag/query/overview/). + +Рабочая гипотеза — адаптация готового механизма плюс предметные правила и сборщики. Не нужно заранее выбирать исключительно самописный контур или запускать постоянные параллельные графы. + +## 9. Ближайшее проверяемое испытание + +В рамках E2–E3 подготовить 60–100 связанных эпизодов: текущие задачи Алекса, история участия, документация/onboarding/processes, старые размеченные баги и новый поток. Сопоставить явные связи/обычный поиск с Cognee и Graphiti на одинаковом корпусе. + +Обязательные случаи: + +- Подзадача без слов «toolbar», смысл которой раскрывается через родителя. +- AI Chat затрагивает главное окно/toolbar, без mention Алекса. +- AI Chat затрагивает только серверную часть; UI-ответственность не должна приписываться. +- Старый баг становится релевантным через новую работу. +- Одна задача принадлежит нескольким проектам и смысловым областям. +- Явная связь PR → Asana сохраняется без модельного сопоставления. +- Предложение позднее отменено; закрытая задача не считается доказательством реализации. +- Источник явно сообщает о выпуске хотфикса; анализ учитывает это сообщение вместе с историей, не теряет его при группировке. +- Поздний backfill не перезаписывает новое состояние старым. +- Близкие по названию работы остаются разными при разных источниках и scope. + +Отдельно измерять: + +- покрытие рамочной разметкой и покрытие проверенными связями; +- найденный релевантный контекст и пропущенные межсферные пересечения; +- ложные связи/merge и правильность временного состояния; +- долю корректных неизвестностей; +- стоимость, длительность, повторы обработки и ручные исправления. + +Предварительные модельные выводы не служат независимым эталоном для оценки той же модели. Проверка человеком сосредоточена на важных неоднозначностях и контрольных примерах, а не на ручном разборе всех десятков тысяч задач. + +**Результат испытания:** работающий срез «история + новое изменение → найденный контекст → проверяемые связи/состояние», оценка массового прогона и обоснованный выбор готового компонента. + +## 10. Открытые вопросы + +- Где находятся корпоративные AI-метки, каковы их категории, история и ошибки? +- Какие действия над задачей считаются разными видами участия Алекса? +- Как подтверждать текущие области и роли, отличая их от исторического опыта? +- Какая схема контекстных пакетов сохраняет смысл при приемлемом размере? +- Какие backend и модели выиграют на нашем наборе? +- Какой бюджет поиска/обработки нужен архиву и incoming? +- Какие классы смысловых связей можно принимать автоматически после оценки, а какие требуют дополнительной проверки? +- Как обновлять зависимые представления после изменения родителей, ролей или исходных решений? + +Эти вопросы остаются частью исследования. Сам факт назначения bucket, существования графового ребра или получения уверенного ответа модели не подтверждает понимание текущей работы.