76 KiB
Executable File
Personal OS: от потока событий к рабочей картине и управлению вниманием
5 октября 2026. Исследование, выборочная проверка Asana и проект реализации. Реализация предложенных изменений не запускалась.
Порядок исполнения: детальный план действий E1–E5, включая пять пакетов ближайшей итерации, владельцев, зависимости и приёмку. Первый пакет — E1.1: воспроизведение потерь и независимый coverage report.
Решение и границы
Следующий этап — восстановить проверяемое покрытие нескольких проектов и на этом корпусе испытать построение рабочего графа. Покупка корпоративного продукта больше не является первым пунктом плана. Условия: личный доступ к существующим системам компании, открытые компоненты, локальная эксплуатация, отсутствие обязательных изменений процессов компании.
Задача состоит из шести разных преобразований: наблюдать → классифицировать → связать → определить отношение ко мне → оценить важность → распределить внимание. Ответ «поставить knowledge graph» покрывает лишь часть третьего преобразования. Ответ «подключить LifeOS» относится преимущественно к шестому.
Подходящие открытые механизмы существуют. Самый предметный найденный пример — Cognee Company Brain: объединение таблиц сотрудников, задач и протоколов в общую модель людей, команд и проектов. Graphiti предлагает другой акцент: изменение связей во времени. Это основания для ограниченного испытания готовых механизмов. Они не доказывают, что готовая система уже понимает обязанности, полномочия и карьерные цели конкретного человека.
Предлагаемая сборка: существующие Node/TypeScript-сборщики и PostgreSQL; готовый Python-компонент извлечения/графа после сравнения; собственные проверяемые правила ответственности и персонального ранжирования; привычный интерфейс с небольшими порциями обратной связи. Это адаптация готовых механизмов, без разработки своей языковой модели. Решение о конкретном graph runtime ещё не принято.
Этот документ заменяет очередность из обзора покупки и адаптации и уточняет план R2. Старые PDF показывают R2 до этого исследования. Новые компоненты, расписания и автономные полномочия этим документом не включаются.
1. Что проверено в нашей системе
1.1. Сверка с живой Asana
Прочитаны первые страницы трёх проектов через доступный Asana API; задачи сравнивались по GID с локальной PostgreSQL. Фильтр «только мои» не применялся. Это ограниченные, неслучайные выборки, не проценты полноты проектов или компании. Все три запроса достигли заданного лимита.
| Проект | Получено из API | Найдено локально | Что доказано |
|---|---|---|---|
| Scheduled Rotations | 200 | 0 | Эти 200 объектов отсутствуют. Другие задачи проекта локально есть. |
| Apple Feature Flags Registry | 200 | 11 | 189 объектов этой страницы отсутствуют. |
| Apple Team Meta Project | 40 | 39 | Задачи этой страницы в основном есть; принадлежности проектам представлены неполно. |
У 39 найденных задач Meta Project принадлежность этому проекту есть в raw_json, но лишь у 13 — в основном поле project_gid. Во всём локальном корпусе 14 356 задач имеют несколько memberships. Нормализованная модель сохраняет только один проект. Это прямой дефект для анализа пересечений направлений.
Дополнительно сравнены шесть задач с описаниями, комментариями и доступными подзадачами:
- У двух платформенных задач feature flag описания совпали, комментариев нет в обоих источниках. Пустая история комментариев здесь корректна.
- У закрытой Apple Weekly Team Meeting от 31.01.2023 API возвращает два комментария, локально их нет. Исторический контекст принятия ответственности потерян.
- У Apple Team Retrospectives API вернул 10 подзадач; локальных связей
subtaskдля этого контейнера нет. Это минимум десять доступных детей, не доказательство полного размера дерева. - Apple Release Train Visual Overview отсутствует локально. Его описание ссылается на изображение процесса; содержимое изображения в этом аудите не анализировалось.
- README о принятии технических решений указывает на Apple Diary Messages и еженедельные встречи как места обсуждения. Одних задач и их комментариев недостаточно даже для описанного командой процесса.
У совпавших задач статусы completed в выборке совпали. Найдено одно расхождение assignee, причина не установлена. Это проверка полей выбранных объектов, не подтверждение актуальности всего зеркала.
Доказательства: выборки проектов, сопоставление с БД, шесть подробных объектов, результат сравнения. Файлы содержат рабочие данные и предназначены для локальной документации.
1.2. Причины и риски в коде
| Место | Наблюдение | Последствие |
|---|---|---|
asana.js: поля и normalizeTask |
Нет запрашиваемых custom_fields, followers, parent, due_at; берётся первый membership |
Теряются явные приоритеты, участие, иерархия, точное время срока и несколько контекстов одной задачи. В raw-корпусе эти три первых поля также отсутствуют. |
db.js: task upsert |
Старый ненулевой project_gid сохраняется через COALESCE |
Даже единственная нормализованная принадлежность может устареть после перемещения задачи. |
asana.js: обнаружение и full sync |
Проекты ищутся по участию пользователя; full sync ограничен изменениями за 30 дней; watch-list пуст | «Полная синхронизация» не означает историческую полноту и не обнаруживает все соседние направления. |
sync.js: stories |
Закрытая задача без story cursor не попадает в обычную очередь первоначального чтения | История принятия решений по завершённой работе может никогда не загрузиться. |
asana.js: stories |
После чтения применяется фильтр по времени создания | Редактирование старого комментария не гарантирует обновления; удаление не превращается в tombstone. |
Дополнительные ограничения, обнаруженные статическим чтением: following разбит на недельные интервалы без полного обхода страниц внутри интервала; delegated и список детей ограничены одной страницей; курсор поиска двигается на lastModified + 1 ms, что требует проверки одинаковых timestamps; watermark конца загрузки допускает гонку с изменениями во время чтения. Это риски к воспроизведению, а не уже измеренное число потерянных объектов.
Связи dependencies/dependents собираются для узкой очереди недавних незавершённых my/delegated-задач с лимитом 50. Разворачивание подзадач привязано к двум bug-проектам и короткому временному окну. Ошибка получения связей может выглядеть как пустой результат. Рёбра добавляются без полноценного жизненного цикла удаления. raw_json перезаписывается, поэтому сам по себе не является неизменяемым архивом наблюдений.
В БД 53 project cursor, из них 30 обновлялись в последние семь дней на момент среза. Максимальный timestamp — 03.10.2026 18:35 UTC. Это сведения о записанных результатах, а не проверка состояния процесса сейчас. Ранее подсчитанные 79 507 задач и 575 587 stories показывают объём корпуса, но не его полноту.
1.3. Существующее понимание работы
work-demand.js рассматривает ограниченную выборку открытых assigned/following-задач и недавние комментарии; роли определяются по assignee и текстовым признакам запроса. Более поздний ответ пользователя может подавить старый запрос, хотя ответ ещё не доказывает разрешение вопроса. day-coordinator.js обрезает список до лимита действий; полноценной матрицы важности там нет. Текущий agent/work-profile.md слишком узок и историчен для модели всех обязанностей.
Итого: уже есть сбор, поиск отдельных запросов и ограничение количества действий. Нет доказанного полного покрытия, восстановленной структуры компании, актуальной модели областей ответственности и измеренного персонального ранжирования.
2. Уровень 1 — наблюдать работу компании через доступные источники
Вход и необходимый результат
Вход — доступные пользователю Asana, Mattermost, Zoom и GitHub. Результат — воспроизводимый архив наблюдений плюс карта покрытия: какой проект, тип объекта и период просмотрены, когда, с какими ошибками и ограничениями доступа. Отсутствие объекта в непроверенном разделе не означает отсутствия работы.
Для каждого источника нужны отдельные контракты. Asana: задачи, все memberships/sections, люди, проекты/команды, поля, истории, дети, зависимости, релевантные сообщения/статусные обновления и вложения. Mattermost: канал, сообщение, тред, ответ, редакция, удаление, автор. Zoom: встреча, участники, фрагменты с таймкодами, качество транскрипции и атрибуции говорящего. GitHub: issue, PR, review, comment, commit, состояние merge/release как разные события. Полнота последних трёх источников этим аудитом не проверена.
Порядок обработки
- Обнаружить доступные разделы и сохранить каталог. Человек выбирает область пробного аудита по названиям; API выдаёт IDs, внутренние IDs создаёт код.
- Полностью обойти выбранные проекты с пагинацией, включая закрытые задачи и детей. Записать проверяемый manifest объектов и недоступных полей.
- Сохранить версии исходных наблюдений с source ID, временем источника, временем получения и content hash. Отдельно вычислять изменения.
- Продолжить инкрементальное чтение с перекрытием окна, дедупликацией и контрольной сверкой. Ошибки и потерю доступа хранить явно.
- Расширять охват: сначала дешёвые метаданные соседних направлений, затем содержимое по связям и отдельная выборка «пока не связанных» областей.
Пятый шаг нужен против замкнутого круга: если читать только известные интересы пользователя, новое направление никогда не станет известным. При этом нельзя обещать восстановить весь исторический журнал: API может уже не отдавать удалённые или прежние версии. Такие промежутки отмечаются как недоступные.
Что взять готовым
Airweave полезен моделью Asana-объектов и набором полей: tasks, projects, sections, comments, files. В прочитанном модуле поля богаче наших. Однако tasks обходятся с пагинацией, а проекты, секции и комментарии в выбранных путях читаются одиночными запросами; generate_entities не использует переданный cursor. Это основание проверить границы, прежде чем заменять работающий сборщик. MIT. Проверенный модуль.
Onyx — готовая оболочка поиска и ответов по корпоративным документам. Его Asana-коннектор превращает задачу в текстовый документ; один project остаётся metadata, дубликаты task GID между проектами подавляются. Это удобный сравнительный вариант поиска, но такой формат не заменяет полный реестр memberships и типизированных связей. Код коннектора.
Рекомендация: сначала исправить наш Asana adapter и формат покрытия; заимствовать проверенные поля и паттерны обхода. Перенос всей загрузки на Airweave сейчас добавит миграцию до доказательства её преимущества. Коннекторы Mattermost/Zoom всё равно требуют сверки с нашими конкретными способами доступа.
Приёмка уровня: на выбранных полностью пройденных проектах каждый доступный upstream ID присутствует либо имеет объяснённый отказ; повторный обход идемпотентен; обработаны перемещение между проектами, редактирование, закрытие, удаление/утрата доступа и более одной страницы детей/истории.
3. Уровень 2 — классифицировать смысл событий
Классификация должна быть многомерной
Одно сообщение может одновременно содержать отмену решения, новый запрос и ссылку на будущую работу. Единственная метка «важно/неважно» уничтожит эту структуру. Для каждого фрагмента нужны независимые поля:
| Ось | Примеры значений |
|---|---|
| Что произошло | Изменение поля, запрос, обещание, предложение, решение, вопрос, результат, социальный ответ, автоматическое уведомление |
| Объекты и участники | Люди, задача, компонент, проект, файл, встреча, ссылка на артефакт |
| Модальность и состояние | Утверждается, предполагается, отклонено, отменено, условно, завершено по словам автора |
| Время и область | Когда действует, до какого срока, какая платформа/команда/версия |
| Основание и уверенность | Точный фрагмент, контекст треда, способ извлечения, версия модели, неоднозначность |
Вход классификатора — небольшой связный эпизод: исходное сообщение, родитель, существенные ответы и метаданные. Zoom режется по обсуждаемым вопросам с таймкодами; граница токенов сама по себе не является границей решения. Сначала используются явные API-поля и URL, затем модель извлекает недостающее. Противоречия сохраняются для следующего уровня.
Подходящие реализации
GLiNER2 объединяет извлечение сущностей, классификацию и структурированные связи; в текущем репозитории есть multilingual GLiNER2.5. Это предметный кандидат для дешёвого локального первого прохода смешанных русско-английских данных. Поддержка языка ещё не доказывает качество на наших тредах, аббревиатурах и отрицаниях. Репозиторий, извлечение отношений, статья.
SetFit подходит после появления небольшого набора наших примеров для устойчивых категорий, например «запрос review / решение / автоматическое уведомление». Snorkel позволяет согласовать слабые метки от правил и метаданных. Слабая метка не становится эталоном; конфликт правил и редкие классы требуют отдельной проверки. SetFit, Snorkel.
Jev уместен как сравнительный вариант выбора из ограниченных кандидатов: тип события или наиболее вероятная сущность из подготовленного списка. Это закрытый API, поэтому он не является базовым решением при требовании открытого локального стека. Ограничения многошагового рассуждения и чувствительность к постановке задачи описывает сам поставщик. Цена входных токенов не учитывает автоматически стоимость retrieval, повторов и проверки. Модели, ограничения, entity alignment.
Сложные эпизоды — конфликт версий, неявный адресат, отмена предыдущего решения — передаются более сильной модели через заменяемый интерфейс. Локальный или внешний inference выбирается отдельно; открытый код обвязки не означает открытость подключённой модели. До испытания нельзя назвать оптимальную модель или обещать стоимость обработки всего архива.
Собственная часть и проверка
Наши схемы категорий, контекст эпизода, признаки эскалации и правила хранения результата остаются предметной настройкой. «Шум» уходит в дешёвый индекс и редкую контрольную выборку, а не удаляется: короткое «отменяем» может иметь больше значения, чем длинный отчёт.
Приёмка измеряет recall редких обязательств/отмен, precision извлечённых фактов и отдельно качество по языкам, типам источника и длине треда. Средняя accuracy непригодна при преобладании уведомлений. Сравнение: правила без модели → GLiNER2 → добавление сложного анализатора. Нужно измерить прирост каждого перехода.
4. Уровень 3 — построить виртуальную структуру компании и работы
Три наложенных графа
Организационный: компания, подразделение, команда, человек, назначенная роль и период её действия. Рабочий: направление, инициатива, проект, задача, решение, артефакт, инцидент, встреча и последовательность работ. Компетенций и сотрудничества: темы, подтверждённый опыт, повторяющиеся взаимодействия, зависимость от эксперта. Эти слои связаны, но отношения в них различны.
Частота совместных упоминаний помогает найти сообщество. Она не доказывает подчинённость, ответственность или блокировку. Проект Asana может быть контейнером повторяющихся встреч; одно направление может состоять из задач нескольких проектов. Один человек одновременно несёт несколько ролей в разных областях.
Неизвестный объект не должен исчезать из-за отсутствия класса в схеме. Его можно сохранить как временный тип с исходным названием; повторяющиеся случаи образуют предложение расширить словарь. Произвольные типы получают стабильные IDs и общие поля доказательства/времени, а специфические атрибуты — версионированную схему.
Как именно появляются связи
- Явные связи: source ID, URL, memberships, assignee, parent, dependency, review request. Их извлекает код, сохраняя источник и его версию.
- Кандидаты: точные aliases, лексический поиск и embeddings дают объединённый короткий список. Совпадение строки — кандидат на идентичность; общий предмет — кандидат на отношение.
- Проверка: модель получает пару/небольшой набор объектов, контекст и допустимые типы связи. Она возвращает утверждение с цитатой либо
unknown, включая отрицательные свидетельства. - Согласование: валидатор проверяет типы, даты, идентичность и конфликты. Неоднозначное слияние людей не проходит автоматически; явная ссылка может быть принята без модели.
- Публикация: принятый граф строится из утверждений определённой версии. Исправление или отмена пересчитывает зависимые представления; исходные свидетельства сохраняются.
Для людей ключ — provider/workspace/user ID; email и подтверждённые aliases связывают учётные записи между источниками. Внутренний UUID выдаёт программа. Равные имена разных людей не являются основанием для merge. Объединение и разделение сущностей должны быть обратимыми.
Связь хранит не только A → B, но и relation_type, valid_from/to, observed_at, source fragment, статус принятия, версию метода и область действия. Отмена членства закрывает связь человека с командой, а не узел команды. Различаются время события и время, когда система о нём узнала.
Готовые механизмы и их реальные границы
Cognee — первый кандидат для испытания общего рабочего графа. Его Company Brain multi-source demo объединяет HR/project DB, JSON tickets и документы встреч через одну модель. Есть UI графа и MCP-доступ. Это почти прямой образец нашего третьего уровня, а не абстрактный чат с файлами. Apache 2.0. Проверенный пример.
Но в модели примера человек, команда и проект идентифицируются по name; у человека простое поле роли и одна команда. Для нас нужны исходные идентификаторы, несколько scoped roles и история. Это ограничения конкретного примера, не доказательство невозможности настройки Cognee. Модель примера. Другой пример organisational hierarchy получает уже структурированные people/company JSON: его нельзя выдавать за доказательство автоматического восстановления оргструктуры из шума.
Graphiti — альтернативный кандидат, если решающими оказываются временные отношения. Готовые механизмы добавления эпизодов, поиска, разрешения сущностей и изменения отношений сокращают объём нашего кода. Однако LLM-разрешение совпадений требует проверки ложных слияний; выбранные backend-драйверы означают дополнительное graph storage. Это не встроенная возможность нашего PostgreSQL. Репозиторий, проверенные ранее версии.
GraphRAG и BERTopic — помощь для обнаружения направлений. Кластеры/сообщества и их сводки позволяют заметить повторяющуюся тему за пределами назначенных задач. Полученный кластер первоначально называется «кандидат направления»; его название, границы и участники ещё не являются организационным фактом. GraphRAG полезен для обзорных вопросов о большом корпусе; он не заменяет модель текущих обязанностей. GraphRAG, варианты индексации, BERTopic.
Splink/исследования entity matching полезны для неоднозначных карточек людей и объектов: сравнение нескольких признаков, блокировка кандидатов, вероятность совпадения. Они не определяют смысл рабочей зависимости. Splink, Ditto. Словари W3C ORG и PROV дают готовые идеи для ролей с областью/временем и происхождения утверждений; заимствование словаря не требует перехода на RDF. ORG, PROV-O.
Конкретные примеры приёмки из аудита
Две задачи webExtensionStateRestorationGate относятся к разным платформам. Правильный результат: две задачи, одна связанная техническая тема/инициатива и отдельные назначения. В описаниях есть срок 28.10.2026 и условие проверки удаления после стабильного исправления. Это повод сохранить будущую условную обязанность, а не автоматически объявить задачу самой срочной сегодня.
Retrospectives — контейнер серии встреч: нужна связь экземпляров с серией, датами, участниками и решениями. Release Train Visual Overview — артефакт процесса; для его связи с релизными событиями потребуется прочитать саму схему. Старый протокол показывает ответственность тогда; он не назначает человека текущим DRI спустя годы.
Просмотр графа: Cytoscape.js даёт готовый движок интерактивного графа. Наши экраны должны показывать выбранное направление, связи в один-два перехода, слой отношений, временной срез и доказательство по клику. Обзор всей компании агрегируется до направлений; неопределённость и непокрытые разделы видимы. Obsidian/Canvas — читаемая проекция и место заметок. Cytoscape.js.
5. Уровень 4 — найти пользователя в этой структуре
Что нужно моделировать отдельно
| Категория | Основание | Что разрешено заключать |
|---|---|---|
| Прямая обязанность | Актуальное назначение, принятый запрос, действующая ротация, подтверждённая зона ответственности | Работа требует действия или контроля пользователя. |
| Пересекающаяся ответственность | Зависимость от его области, обязательное согласование, влияние на поддерживаемый компонент | Проверить участие и последствия; это не автоматическое назначение исполнителем. |
| Смежная компетенция | Подтверждённый опыт и техническое пересечение | Пользователь может быть полезен; наличие опыта не создаёт обязанности. |
| Карьерная возможность | Актуальная цель пользователя плюс возможность получить нужный опыт/влияние | Предложить выбор с затратами и пользой, не заносить молча в обязательства. |
| Контекст или неопределённость | Соседняя тема, слабая связь, неполные данные | Дайджест/дополнительная проверка; не создавать срочную задачу. |
Роль — отдельное назначение человека в определённой области на определённое время, с источником полномочий. Должность не описывает все реальные обязанности. Автор PR, участник встречи, assignee, reviewer, владелец компонента и человек, который разово помог, — разные отношения.
Алгоритм персонализации
Сначала формируется профиль из явных текущих назначений, ротаций, источников целей и проверенного опыта. Затем для каждого рабочего объекта ищутся типизированные пути к профилю: задача → блокирует → обязательство пользователя; изменение → затрагивает → компонент → зона ответственности; инициатива → требует компетенцию → подтверждённая цель развития.
Для каждого пути сохраняются срок действия, подтверждение и контрсвидетельства. Простая близость на графе недостаточна: соседство по встрече не равно долгу. «Мы сделаем» без определённого адресата остаётся неразрешённым обязательством команды. Назначение давно завершённой задачи служит историей опыта, а не текущей нагрузкой.
LLM готовит предложения о профиле. Короткое подтверждение пользователем требуется при изменении его целей, границ ответственности или неоднозначной идентичности. Повторно подтверждать каждое явное API-назначение не нужно. Исправление сохраняется как правило ограниченной области; один ответ не должен переписывать весь профиль.
Что реально придётся настроить самим
Cognee/Graphiti могут хранить и находить эти отношения. ORG помогает задать схему. Но смысл «это входит в мои обязанности», предпочтения развития и полномочия конкретной команды должен задаваться нашими политиками и подтверждёнными источниками. Ни один изученный компонент не показал готовую проверенную персонализацию этого уровня на наших данных.
Исследование оценки expert finding показывает риск: если эталон строится только из предложенных системой кандидатов, качество завышается в пользу легко находимых буквальных совпадений. Поэтому оценивать нужно и независимо отобранные работы, где пользователь не упомянут, но его область затронута. Упоминания, экспертиза, ответственность и карьерное желание размечаются раздельно. On the Biased Assessment of Expert Finding Systems.
Приёмка: система объясняет категорию конкретным путём и источниками; не назначает обязанности по частоте сообщений; различает людей с одинаковыми именами; умеет сказать «не знаю»; обнаруживает косвенное влияние без прямого mention пользователя.
6. Уровень 5 — отобрать интересующее и ранжировать важность
Важность — несколько осей, а не один непрозрачный score
После определения отношения к пользователю для каждой кандидатной работы вычисляются:
| Ось | Проверяемый вопрос |
|---|---|
| Значимость | Какое обязательство, цель, риск или результат затронуты? |
| Срочность | Что ухудшится от задержки, к какой дате и на каком основании? |
| Ответственность и возможность повлиять | Нужен именно пользователь? Он исполнитель, согласующий, консультант или наблюдатель? |
| Готовность и цена | Есть ли входные данные, сколько внимания нужно, кого это разблокирует? |
| Уверенность | Какая неизвестность способна изменить порядок и сколько стоит её прояснить? |
Из этих осей строится понятная матрица «влияние × срочность», а рядом показывается тип участия. Жёсткие обязательства и подтверждённые критические риски учитываются раньше необязательных возможностей. Карьерный рост получает отдельный защищённый бюджет, если это соответствует текущим целям; он не должен навсегда проигрывать потоку мелких срочных запросов.
Число комментариев, свежесть сообщения и тематическая близость могут помочь retrieval, но не являются доказательством важности. Молчаливый проект с близким сроком может быть важнее шумного треда. Система должна показывать причину подъёма: например, появился запрос обязательного review, изменился срок, подтверждена блокировка. Простое повторение старой темы не меняет приоритет.
Готовая техника и собственная политика
Первый вариант — прозрачные правила, несколько очередей и объяснимое сравнение верхних кандидатов. Очереди: обязательства, пересечения/консультации, стратегические возможности, контекст. Внутри каждой — приоритет и готовность; между ними — ограничения внимания следующего уровня.
Learning-to-rank имеет смысл после накопления пользовательских сравнений. LightGBM предоставляет lambdarank и rank_xendcg; его готовые алгоритмы обучают порядок по признакам и предпочтениям. Они не создают цели пользователя и не решают отсутствие меток. Сначала объяснимый baseline, затем проверка прироста на отложенных периодах/проектах. LightGBM parameters.
Обратная связь должна различать «не моя область», «важно, но позже», «зависимость неверна», «уже решено», «сейчас нет сил». Игнорирование карточки не равно отрицательной метке важности. Пять коротких сравнений полезнее требования вручную разметить тысячи сообщений.
Приёмка: измеряются пропуски существенных обязательств, качество верхних рекомендаций, объяснимость и устойчивость порядка при добавлении шума. Отдельно проверяется разнообразие: система не должна снова рассказывать один удобный эпизод вместо всей существенной работы. Для карьерного обзора единица охвата — направления и результаты за период, а не число похожих примеров.
7. Уровень 6 — балансировать внимание и учиться на результате
Вход и поведение
Вход — ранжированные работы, календарь, текущий фокус, заявленное самочувствие, границы рабочего дня и цели баланса. Отсутствие событий ActivityWatch не доказывает свободное время; активное приложение не доказывает намерение или эффективность.
Планировщик учитывает доступные окна, длительность и неопределённость работы, подготовку к встречам, перерывы, предел незавершённых действий и стоимость переключения. Выход — одно следующее действие и небольшой резерв. Новые рекомендации собираются до перехода между задачами; исключения требуют подтверждённой срочности.
В существующем capacity-model.js уже есть данные о встречах и конце дня, но расчёт суммы встреч требует проверки пересечений интервалов и обрезки к доступному окну. Это конкретная недоработка до заявления о корректной ёмкости дня. Ограничить список тремя действиями недостаточно для балансировки нагрузки.
Что взять готовым
Super Productivity — открытый кандидат для интерфейса задач, timeboxing и контекста текущей работы. Его plugin API предоставляет задачи, текущий контекст и события task update/complete. Это реальная точка подключения Personal OS; интеграцию с нашим графом нужно написать. Задачи источника отображаются как проекции с исходными IDs, без появления второго независимого списка обязательств. MIT. Продукт, проверенный plugin API.
OR-Tools решает ограничения расписания и зависимостей. Он полезен, если простой планировщик не справляется с несколькими окнами, предшествованиями и ресурсами. Функция предпочтений, цена переключения и предел нагрузки остаются нашими. На первом этапе достаточно детерминированного планирования с проверяемыми ограничениями. Scheduling, код.
LifeOS-подходы к личным целям и ретроспекции могут дать структуру профиля/обзоров. Они не заменяют предыдущие уровни. Начинать с новой оболочки личных заметок сейчас не устраняет потери в Asana и неизвестные рабочие связи.
Ретроспектор и улучшение
Ретроспектор сравнивает предсказанную значимость и длительность с фактом: работа состоялась, была отложена из-за внешней блокировки, потребовала больше времени, стала ненужной, дала результат. Отдельно проверяет, сколько внимания съела сама система. Исправления направляются в нужный слой: extractor, связь, профиль, ранжирование или capacity.
Переобучение/изменение правил проходит через версии, повторную оценку на фиксированном наборе и откат. Оно не включается автоматически от каждого клика. Исследования прерываний дают основание измерять стресс и цену переключений, а не только скорость выполнения; конкретные числа из лабораторного эксперимента нельзя переносить на пользователя с ADHD. The Cost of Interrupted Work: More Speed and Stress.
Приёмка: план не нарушает заявленные границы дня, не ставит перекрывающиеся встречи дважды, сохраняет текущий фокус при несущественных обновлениях, объясняет перестановку и позволяет отменить её одним действием.
8. Что добавлено к исходным шести шагам
Временная правда и неопределённость
Обсуждение, предложение, принятое решение, реализация и подтверждённый результат — разные состояния. Последнее сообщение не всегда авторитетнее предыдущего: нужна роль автора, область действия и явная связь отмены/уточнения. При конфликте вывод обязан сохранять альтернативы. Текущая правда формируется как версия принятых утверждений с указанием времени, покрытия и открытых вопросов.
Обнаружение неизвестного
Нужен контролируемый обзор соседних и пока не связанных проектов. Иначе персонализация превращается в повторение уже известного, а карьерные возможности исчезают до этапа ранжирования. Обзор должен включать тихие проекты, закрытые решения, темы без mention пользователя и редкие события высокой значимости. Архив читается поэтапно; новые события получают приоритет обслуживания перед массовым backfill.
Коррекция и распространение исправлений
Исправление «эти люди разные» меняет identity mapping и производные роли/приоритеты. Исправление «это больше не моя область» меняет scoped role с датой окончания. Для этого нужен lineage: какой вывод зависит от какого утверждения. Все сценарии — подготовка встреч, карьерный обзор, дневной план — получают одну опубликованную версию графа, а не повторно собирают свою несовместимую картину.
Проверка качества и права доступа
Набор оценки формируется независимо от любимых примеров модели. Он разделяется по времени и проектам; отдельно измеряются извлечение, retrieval кандидатов, связывание, текущий статус, личная релевантность и ранжирование. Потеря прав доступа помечается как ограничение наблюдения, а не как завершение работы. Данные компании остаются в разрешённом контуре; публичное исследование компонентов не означает разрешения отправлять рабочий архив во внешние модели.
Эксплуатация
Для каждой операции нужны watermark, версия, idempotency key, повторы с ограничением, очередь ошибок и стоимость. Кэш анализа привязан к hash содержимого и версии схемы/модели. Переанализируются изменившиеся эпизоды и их зависимые выводы, а не весь граф. Повторные модельные попытки не считаются независимыми свидетельствами. Начальный масштаб не требует Kafka или нескольких оркестраторов: достаточно очереди задач и checkpoint в существующем хранилище, пока измерения не докажут обратное.
9. Конкретная архитектура для нашего сетапа
Что сохраняется и что добавляется
Проверена PostgreSQL 17.9; уже установлены pg_trgm 1.6 и vector 0.8.2. Сборщики работают на Node. Host: Apple M4 Max, 64 GiB RAM. Это позволяет рассматривать локальный extraction worker, но скорость и расход памяти выбранной модели ещё не измерены. Срез возможностей.
| Часть | Предложение | Статус |
|---|---|---|
| Ingestion | Исправить существующие adapters Node, постепенно типизировать контракты | Код есть; выявленные дефекты не исправлены этим исследованием. |
| Канонические данные | PostgreSQL: объекты, источники, версии наблюдений, claims, coverage, принятые роли/связи | Часть зеркала есть; целевой контракт R2 требует реализации. |
| Извлечение и linking | Изолированный Python worker; GLiNER2 и один выбранный graph engine | Кандидаты, не установлены и не измерены. |
| Retrieval и представления | Exact IDs + FTS/trigram + pgvector при доказанном приросте; scoped graph UI/Obsidian | Расширения есть; весь путь не реализован. |
| Политика и внимание | Проверяемые правила роли/важности, planner/retrospector поверх опубликованного контекста | Имеются ранние модули; целевая семантика отсутствует. |
Python здесь — adapter для готовых библиотек. Уход с Node целиком не обоснован. n8n/Node-RED могут запускать шаги, но не дают нужной семантики графа или ответственности; новый оркестратор пока добавляет эксплуатационную работу. Существующий механизм запуска должен иметь одного владельца каждого pipeline. Частоты backfill/incremental/пересмотра профиля выбираются по результатам измерений; новое расписание сейчас не установлено.
Если выбранный Cognee/Graphiti backend требует отдельного graph storage, его проверяют в изолированном эксперименте как перестраиваемый индекс. Принятые утверждения, версии и права остаются в PostgreSQL. Если сохранить эту границу без громоздкой двойной синхронизации не получится, это аргумент против кандидата, а не повод незаметно создать два источника истины.
LightRAG и HippoRAG полезны как варианты retrieval по связям. Но retrieval не заменяет принятие фактов. У LightRAG вариант PostgreSQL graph storage требует Apache AGE, которого наличие pgvector не обеспечивает. Поэтому «всё уже есть в нашей БД» было бы неверным выводом. LightRAG PostgreSQL example, HippoRAG.
Data flow
flowchart TD
A[Asana / Mattermost / Zoom / GitHub] --> B[Adapters: coverage, версии, source IDs]
B --> R[(Исходные наблюдения и PostgreSQL)]
R --> C[Эпизоды: правила + извлечение + сложный анализ]
C --> D[Кандидаты сущностей и типизированных связей]
D --> E[Проверка идентичности, времени, противоречий]
E --> G[Опубликованный граф работ и структуры]
G --> P[Актуальные роли, компетенции, цели пользователя]
P --> Q[Релевантность, важность, срочность, готовность]
Q --> F[План внимания с ограничениями]
F --> U[Одно действие / обзор / подготовка встречи]
U --> X[Обратная связь и фактический результат]
X --> E
X --> P
X --> Q
X --> F
G --> V[Проверяемые обзоры проектов и карьеры]
На границе extraction нужен результат вида subject_ref, relation_type, object_ref/value, evidence_span, valid_time, modality, method_version. На границе relevance — категория участия и доказанный путь к текущей роли/цели. На границе attention — выбранное действие, временное окно, причина выбора и условия пересмотра. Эти контракты позволяют заменить модель без переписывания остальных слоёв.
Агент извлечения не имеет полномочий назначить пользователю цель или создать обязательство в Asana. Агент графа предлагает связи; acceptance layer проверяет ограничения. Анализатор роли связывает работы с подтверждённым профилем. Ranker объясняет порядок. Planner распределяет посильный объём. Retrospector предлагает исправления конкретного слоя. Пользователь исправляет смысл, а не обслуживает вручную реестр IDs.
10. Как выбирать компоненты без ещё одного бесконечного обзора
| Вариант испытания | Что проверяет | Решение по результату |
|---|---|---|
| A. Наш PG + явные связи + лексический поиск | Сколько решается исправленным сбором и правилами без LLM-графа | Обязательная исходная линия качества/стоимости. |
| B. Cognee с нашей схемой IDs и ролей | Извлечение общих объектов из задач, таблиц и обсуждений; переносимость результатов | Первый кандидат ускорения уровней 2–3. |
| C. Graphiti на тех же эпизодах | Изменение отношений во времени, отмены и многозвенные связи | Альтернатива B при доказанном преимуществе; постоянный двойной граф не предлагается. |
GLiNER2 сравнивается с правилами внутри extraction; он не является четвёртой полной платформой. Onyx имеет смысл испытать отдельно, если нужен готовый интерфейс поиска по корпусу. Его основной код MIT, каталог ee имеет отдельную лицензию. Найденный публичный KnowledgeGraphTool в проверенной версии содержит NotImplementedError; название функции в продукте само по себе не доказывает наличие пригодного нам graph API. Проверенный файл.
Numen близок по предметной модели персонального рабочего контекста, но ранее прочитанный код показал ограничения linker/scoring, а подходящих готовых Asana/Zoom/Mattermost adapters не найдено. Использовать как источник схем/идей, а не объявлять готовым основанием без проверки. Glean/Rovo/Asana Dash остаются примерами корпоративного класса; они не соответствуют исходному условию открытой личной установки без организационного внедрения.
Исследовательские ориентиры для испытаний: STaRK проверяет retrieval, требующий и текста, и отношений; QMSum — поиск и сводки по конкретным вопросам к встречам; retrieve→rerank разделяет полноту получения кандидатов и качество их порядка. Эти наборы не измеряют личную важность, для которой нужен свой небольшой эталон. STaRK, QMSum, Sentence Transformers retrieve/rerank.
11. Пять конкретных этапов реализации и приёмки
Пороги ниже — предлагаемые gates эксперимента, не заявленная достигнутая точность и не отраслевой стандарт. Результаты публикуются с размером выборки; ноль ошибок на малом наборе не доказывает нулевой риск на архиве.
Этап 1. Доказать покрытие трёх выбранных проектов
Поставка: отчёт source coverage; нормализация всех memberships; исторический обход задач/stories/детей; checkpoint и явные ошибки; regression fixtures из найденных пропусков. Изменения прежде всего в asana.js, sync.js, db.js и новой миграции отношений, без запуска массового анализа.
Готово: upstream manifest и локальный manifest сходятся на полном согласованном срезе трёх проектов; причины каждого пропуска известны; изменения/закрытия/перемещения отражаются при повторном чтении. Десять детей Retrospectives и два комментария старой встречи служат конкретными проверками, но не всем набором приёмки.
Этап 2. Подготовить предметный эталон и исходный граф
Поставка: 60–100 связных эпизодов для начальной проверки, стратифицированных по проектам, периоду, типу участия и состоянию решения; явные ID-связи; схема ролей/времени; отдельный отложенный набор. Начальную разметку делает анализатор с доказательствами; пользователь проверяет небольшие порции существенных неоднозначностей.
Готово: представлены прямые обязанности, косвенное влияние, тихие важные события, карьерные возможности и нерелевантный шум; есть независимые случаи без mention пользователя; известны пределы доступа. Случаи выбранного ранее «интересного эпизода» не доминируют в эталоне.
Этап 3. Выбрать механизм извлечения и связей
Поставка: A/B/C-прогоны на одинаковом корпусе; оценка ложных слияний, пропущенных связей, отмен и срока действия; время, RAM, стоимость inference и минуты проверки. Сначала пробный ограниченный объём, затем увеличение при приемлемом качестве.
Готово: ни одного ошибочного слияния человека/задачи в обязательном adversarial-наборе; все принятые модельные связи имеют доступное доказательство; известен прирост над правилами и издержки. Если компонент даёт красивый граф, но ухудшает проверяемость или не экспортирует результат, он не проходит. Отчёт выбирает один механизм либо фиксирует, что исходный вариант пока выгоднее.
Этап 4. Проверить модель роли и матрицу важности
Поставка: актуальные scoped roles и цели со сроком подтверждения; категории участия; объяснения верхних кандидатов; двухнедельное наблюдение рекомендаций без автоматического изменения рабочих систем.
Готово: критические обязательства обязательного тестового набора не потеряны; пользователь может понять и исправить причину рекомендации; разные направления представлены соразмерно значимости. Оценка top-k и пропусков проводится по независимой выборке работ, а не только показанным карточкам.
Этап 5. Подключить внимание и ретроспекцию
Поставка: план с календарными ограничениями и текущим фокусом; единый контекст для ежедневных действий и карьерных обзоров; обратная связь с lineage; replay/rollback; эксплуатационные метрики и документация запуска.
Готово: соблюдаются границы дня и правила переключения; исправление факта доходит до всех зависимых обзоров; ошибки источника не маскируются; планировщик не наращивает обязательства из карьерных возможностей. Предлагаемый начальный бюджет ручного обслуживания — до 10 минут в неделю после настройки; превышение требует упрощения системы, а не расширения обязанностей пользователя. Это целевой критерий, пока не измеренный.
12. Что считается завершённой системой
Завершение определяется совокупностью: доказанное покрытие согласованной области источников; проверяемые текущие связи и роли; полезный персональный порядок с контролем пропусков; посильный план; воспроизводимое исправление и эксплуатация после перезапуска/ошибки. Полная цифровая копия всей компании не требуется: область наблюдения и её ограничения должны быть честно видны.
Производственная готовность требует не только хороших ответов на примерах. Нужны идемпотентный replay, восстановление из резервной копии, контролируемая смена схемы/модели, обнаружение деградации источников, сохранение границ доступа и возможность откатить ошибочное объединение. Автономные записи в корпоративные системы — отдельная будущая возможность с явно утверждёнными полномочиями; они не нужны, чтобы доказать полезность понимания и планирования.
Сделано в этом исследовании: чтение текущего кода и миссии, выборочная сверка Asana, проверка конкретных файлов открытых реализаций, разбор каждого уровня и исправление очередности документации. Manifest проверенных файлов и SHA256. Чтение исходников — статический аудит; чужие demos не исполнялись.
Ещё не сделано: исправления сборщика, полный обход выбранных проектов, модельные прогоны, выбор победителя, измерение ранжирования и запуск контура внимания. Следующий результат реализации — согласованный upstream/local manifest трёх проектов и исправленное сохранение всех memberships.