> Уточнение 05.10: [сначала испытать готовые системы](/Users/admin/Developer/personal-os/planning/personal-os-buy-adapt-build-2026-10-05.md). Asana Dash, Glean, Onyx, Rovo и Work IQ расширяют выбор. R2 — требования и условный вариант собственной реализации; объём собственного кода определяется после сравнения продуктов. Установки и испытания ещё не выполнены.
> Актуальное уточнение 05.10: [шесть уровней Personal OS](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md). Условия: личный доступ, открытые компоненты, без изменения систем компании. Очередность: покрытие проектов → эталон и явные связи → испытание Cognee/Graphiti → роли и важность → внимание и ретроспекция. Исследование выявило потери Asana; исправления и модельные прогоны ещё не выполнены. Корпоративный shortlist больше не определяет первый этап.
> Дополнение 04.10: [понимание потока работ и этапы WG-0–WG-4](/Users/admin/Developer/personal-os/planning/personal-os-work-graph-research-2026-10-04.md). Приоритет проверки — покрытие корпуса, обнаружение связей, текущая ситуация и роль пользователя. Это исследовательское уточнение для согласования; выбранный PostgreSQL core сохраняется, новые модели и graph runtime не внедрены.
4 октября 2026. Подготовленный вариант для утверждения Алексом. Противоречия ранних вариантов устранены; реализация и новые расписания не включены.
## Единственный действующий план
## Действующий план и исследовательское уточнение
[Полная спецификация R2, 21 лист и приёмка](/Users/admin/Developer/personal-os/planning/system-review-2026-10-04/review.md) и [точный контракт PostgreSQL/графа](/Users/admin/Developer/personal-os/planning/personal-os-evidence-graph-design-2026-10-04.md). [Печатные схемы и исходники](/Users/admin/Developer/personal-os/planning/system-review-2026-10-04/README.md). Ранние варианты выбора стека и независимые P0-очереди заменены этим пакетом.
[Полная спецификация R2, 21 лист и приёмка](/Users/admin/Developer/personal-os/planning/system-review-2026-10-04/review.md) и [точный контракт PostgreSQL/графа](/Users/admin/Developer/personal-os/planning/personal-os-evidence-graph-design-2026-10-04.md). [Печатные схемы и исходники](/Users/admin/Developer/personal-os/planning/system-review-2026-10-04/README.md). Контракты R2 сохраняются с уточнениями [шести уровней](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md); очередность E1–E5 ниже заменяет прежнее начало с UI.
## Зафиксированное решение
| Область | Решение |
|---|---|
| Стек | Node с постепенным TypeScript, PostgreSQL, локальный launchd dispatcher; Swift только нативные watchers/iPad. n8n/Node-RED и полная Swift-перепись не входят в выпуск. |
| Стек | Node с постепенным TypeScript, PostgreSQL, локальный dispatcher; Python worker допустим для выбранного готового компонента после E3. Swift — нативные watchers/iPad. n8n/Node-RED и полная Swift-перепись не обоснованы. |
| Истина | Versioned records/spans → typed assertions → review/resolution → atomic publication. Проекты, PR, файлы, сессии, произвольные типы, косвенные пути и карьера связаны в одной БД. JSON/Obsidian — проекции. |
| Агентный контур | Изолированный worker с immutable packet, read capabilities и JSON output; кандидат → структурная и смысловая проверка → publisher. Source refresh принадлежит collector. |
| Взаимодействие | Первый клиент — локальная карточка на Mac; один следующий шаг, почему, свежесть, scoped correction. iPad над тем же API принимается отдельно. |
@@ -28,15 +28,15 @@
## Порядок реализации
| Этап | Конкретный выход и приёмка |
| Этап | Конкретный результат и gate |
|---|---|
| R0 | Принятый пакет и пользовательские границы данных, дня, доставки, бюджета. |
| R1 | Общий manifest над текущим mirror, capacity/request fixes, scoped feedback, простой локальный экран; AC01/08–11. |
| R2 | Discovery + общий граф + lineage + projections + graph UI; AC02–07. |
| E1. Покрытие | Полный согласованный срез трёх проектов; upstream/local manifest; все memberships, stories и дети; проверка повторного обхода. |
| E2. Эталон и явный граф | 60–100 разнообразных эпизодов для начала; source IDs, временные роли, независимый holdout; без доминирования одного кейса. |
| E3. Выбор механизма | Сравнение правил/PG, Cognee и Graphiti на одном корпусе; ошибки связывания, отмены, стоимость и ручная нагрузка. Один выбранный механизм. |
| E4. Роли и важность | Проверенный профиль, объяснимые категории участия и порядок; двухнедельное наблюдение рекомендаций без автоматических внешних изменений. |
| E5. Контур внимания | Ограничения дня, текущий фокус, scoped feedback, единый контекст аналитиков, replay/restore и эксплуатационная приёмка SC1–SC8. |
После R0 UI fixtures, adapters и holdout готовятся параллельно по одному contract version. iPad не блокирует Mac pilot. Gate failures остаются в shadow. Полный список success criteria/проверок и владельцев — разделы 18–20 общего пакета.
Adapters и holdout используют одну версию контракта. UI fixtures допустимы как независимая подготовка, но не заменяют gates покрытия и понимания работ. iPad не блокирует Mac pilot. Gate failures остаются в shadow. Полный список success criteria/проверок и владельцев — разделы 18–20 общего пакета.
Для первого end-to-end eval берём уже известную цепочку Core Data: предложение → отмена → обновление project state → карьерный вклад без ложного implementation → agenda advisor. Она должна работать после нового transcript, backfill, restart и пользовательской коррекции. Затем добавляется незнакомый проект, чтобы результат не зависел от вручную заданных IDs.
Для end-to-end eval нужен независимый набор по нескольким направлениям: тихие обязательства, косвенная ответственность, отменённые решения, платформенные варианты одной темы, последовательности встреч и неизвестность из-за неполного источника. Один ранее найденный эпизод не определяет ни эталон, ни вывод о карьерном вкладе.
**Следующее действие реализации после принятия уточнения:** создать этот воспроизводимый fixture и прогнать через минимальный context assembler; до расширения числа агентов измерить, находится ли отмена и получается ли корректный итог.
**Следующее действие реализации:** доказать покрытие выбранных проектов и сохранить все memberships; затем сравнить компоненты на разнообразном эталоне. Подробный алгоритм и приёмка — [шесть уровней Personal OS](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md).
# Personal OS: каталог готовых систем — справочный обзор
05.10.2026. Дополнение, исправляющее преждевременный вывод предыдущего исследования. Проверены публичные первичные источники; продукты не подключались к частным данным, испытаний ещё не было.
## Решение
## Актуальное решение
**Готовые системы этого класса существуют. Следующий выбор — использовать продукт, адаптировать готовую платформу или собрать недостающие части. Собственная реализация всего конвейера пока не обоснована.**
Предыдущий обзор хорошо разобрал несколько компонентов, но недостаточно охватил готовые продукты. Отсутствие доказанного соответствия нашим требованиям было ошибочно превращено в рекомендацию проектировать собственный предметный слой. Исправление: одинаковые сценарии проверки применяются сначала к доступным готовым системам. Архитектура R2 остаётся контрольным описанием требований и запасным вариантом собственной реализации; несовпадение продукта с нашим стеком само по себе не причина отказа.
**Очередность и выбор кандидатов заменены [разбором шести уровней](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md).** Требования пользователя: открытая система на личном сетапе без изменения систем компании. Первый этап — устранить подтверждённые пробелы Asana; следующий — сравнить готовые механизмы графа на одном корпусе. Корпоративные продукты ниже остаются справочными примерами класса, а не первыми кандидатами внедрения.
## 1. Готовые продукты для сравнения
Порядок отражает предполагаемую применимость к нашей среде, а не измеренное качество.
Порядок сохранён как история обзора; актуальные кандидаты и границы переиспользования перечислены в новом исследовании.
| Кандидат | Подтверждённые функции | Что ещё требуется проверить |
|---|---|---|
| **Asana Dash + AI Teammates / Work Graph** | Asana заявляет приоритизацию, выявление заблокированной работы и следующих действий из встреч, Slack и почты. Основа уже содержит задачи, проекты, цели, людей и зависимости. | Доступность в нашем workspace; поддержка именно наших Zoom-данных и Mattermost; способность восстановить связи из старого архива, а не только использовать заведённые вручную. Первый кандидат для проверки доступности, поскольку основной корпус уже в Asana. |
| **Glean** | Корпоративный граф людей/контента/активности, персонализация; Asana tasks/comments/projects; Zoom cloud transcripts, участники и ссылки на записи. | Организационный доступ и стоимость; Mattermost; полнота истории; извлечение косвенных обязательств и качество личного ранжирования. Серьёзный кандидат готового продукта, не просто архитектурный пример. |
| **Onyx** | Открытая платформа поиска, чата и агентов; гибридный поиск и заявленный knowledge graph; в официальном каталоге есть Asana tasks/comments и GitHub. Можно развернуть самостоятельно. | Что доступно в community и enterprise редакциях; полнота Asana connector; импорт Zoom/Mattermost; достаточно ли настройки агента для наших сценариев или нужен отдельный предметный слой. Основной открытый кандидат для сравнения. |
| **Asana Dash + AI Teammates / Work Graph** | Asana заявляет приоритизацию, выявление заблокированной работы и следующих действий из встреч, Slack и почты. Основа уже содержит задачи, проекты, цели, людей и зависимости. | Доступность в нашем workspace; поддержка именно наших Zoom-данных и Mattermost; способность восстановить связи из старого архива, а не только использовать заведённые вручную. Закрытый корпоративный вариант; не соответствует текущему требованию открытой личной установки. |
| **Glean** | Корпоративный граф людей/контента/активности, персонализация; Asana tasks/comments/projects; Zoom cloud transcripts, участники и ссылки на записи. | Организационный доступ и стоимость; Mattermost; полнота истории; извлечение косвенных обязательств и качество личного ранжирования. Архитектурный ориентир; за пределами текущего открытого личного сетапа. |
| **Onyx** | Открытая платформа поиска, чата и агентов; гибридный поиск и заявленный knowledge graph; в официальном каталоге есть Asana tasks/comments и GitHub. Можно развернуть самостоятельно. | Что доступно в community и enterprise редакциях; полнота Asana connector; импорт Zoom/Mattermost; достаточно ли настройки агента для наших сценариев или нужен отдельный предметный слой. Кандидат готового поиска; полноценный рабочий граф требует отдельной проверки. |
| **Atlassian Rovo / Teamwork Graph** | Граф типизированных направленных связей, включая выводимые связи; связаны пользователи, задачи, проекты, цели, PR; есть Asana connector. | Стоимость и смысл добавления Atlassian в нашу среду; подключение остальных источников; доступность нужных graph API и качество извлечения из разговоров. При наличии организационного доступа может обойтись дешевле собственной платформы. |
| **Microsoft 365 Copilot / Work IQ** | Контекст людей, проектов, знаний и работы для Copilot/агентов; Asana connector индексирует задачи, комментарии и вложения. | Зависимость от Microsoft 365 и доступа администратора; коннектор не индексирует Asana custom fields, Goals и Portfolios — существенный пробел для наших приоритетов. При существующем M365 доступе достоин испытания. |
@@ -26,7 +24,7 @@ Asana: [продукт и Work Graph](https://asana.com/product/ai), [описа
Glean: [граф](https://docs.glean.com/security/knowledge-graph), [Asana indexing и tools](https://docs.glean.com/connectors/native/asana/home), [Zoom V2](https://www.glean.com/connectors/zoom). Новый Asana setup разделяет indexing и MCP tools; нельзя переносить старое описание read-only indexing на права всех подключаемых инструментов.
Onyx: [поиск](https://onyx.app/search), [репозиторий](https://github.com/onyx-dot-app/onyx), [официальный индекс документации](https://docs.onyx.app/llms.txt). Отдельные страницы документации при проверке не открылись; содержимое коннектора и лицензионные границы глубоко не проверены. Наличие пункта в каталоге не засчитывается как успешная интеграция.
Onyx: [поиск](https://onyx.app/search), [репозиторий](https://github.com/onyx-dot-app/onyx), [официальный индекс документации](https://docs.onyx.app/llms.txt). При последующей проверке прочитаны коннектор и лицензия: основной код MIT, ee — отдельная лицензия; task превращается в поисковый документ. Подробности и ограничения graph tool отражены в новом исследовании.
Atlassian: [отношения, включая inferred](https://developer.atlassian.com/platform/teamwork-graph/relationships/), [коннекторы и admin prerequisites](https://support.atlassian.com/rovo/docs/manage-rovo-connectors/). Документация описывает канонические, поведенческие, логические и выводимые связи. Это существенно ближе к задаче, чем просто общий векторный поиск, однако полнота вывода рабочих обязательств ещё не доказана.
| Решение | Как сокращает собственную разработку | Граница |
|---|---|---|
| [Airweave](https://github.com/airweave-ai/airweave) | Готовые sync/index/retrieval и API/MCP; README перечисляет Asana, GitHub и Zoom. | Инфраструктура контекста, не готовая личная приоритизация; поддерживаемые объекты и история коннекторов ещё не проверены. |
| [Airweave](https://github.com/airweave-ai/airweave) | Готовые sync/index/retrieval и API/MCP; README перечисляет Asana, GitHub и Zoom. | Инфраструктура контекста, не готовая личная приоритизация; выбранный Asana-модуль затем проверен статически; найдены ограничения обхода страниц, описанные в новом исследовании. |
| [Cognee](https://github.com/topoteretes/cognee) | Открытая платформа памяти и графовой организации данных. | Кандидат готового предметного компонента; соответствие временным состояниям работ требует проверки. |
| [Graphiti](https://github.com/getzep/graphiti) | Инкрементальные сущности, отношения и время. | Исследование исходников уже есть; ранжирование по роли добавляется отдельно, если не закрыто верхним продуктом. |
| [Numen](https://github.com/theBstar/numen) | Уже объединяет предметные объекты и предлагает срочность/briefing. | Beta с обнаруженными ограничениями; сравнивать как прототип, не назначать базой по одному README. |
Список расширен, но не объявляется исчерпывающей картой рынка. Глубина проверки различается: у Numen/Graphiti читались выбранные исходники; новые коммерческие продукты изучены по документации; запусков и сопоставимых benchmark нет.
## 3. Порядок выбора: продукт → адаптация → собственный код
## 3. Действующий порядок проверки
1.**Проверить доступность кандидатов.** Asana Dash в существующей среде; Onyx как открытый вариант; Glean при доступном корпоративном подключении. Rovo и Work IQ поднимаются в приоритете, если соответствующие среды уже доступны. Зафиксировать стоимость, права, поддерживаемые данные, глубину истории и способ экспорта результата.
2.**Сравнить два доступных варианта на одном небольшом корпусе.** Первый smoke test: 3 разных направления работы и 10–20 вопросов с проверенными ответами. Включить тихое обязательство, косвенную связь, отменённое решение, ответственность пользователя без assignee и неизвестность из-за отсутствующего источника. Большой набор WG-0 нужен для следующего gate, а не как условие начала проверки продукта.
3.**Записать конкретные пробелы и способ их закрытия.** Различать отсутствие источника, плохое извлечение, потерянную связь, неверное состояние и неверный приоритет. Для каждого — настройка продукта, небольшой adapter, готовый компонент или собственный модуль; оценить обслуживание и переносимость.
4.**Выбрать минимальный достаточный вариант.** Если продукт проходит — использовать его. Если проходит с ограниченной адаптацией — дополнить его. Если испытанные варианты имеют критические неустранимые ограничения или неприемлемую стоимость — реализовать только обоснованные части по R2.
1.Доказать покрытие выбранных Asana-проектов и восстановить все memberships, истории и детей.
2.Подготовить небольшой независимый эталон по разным направлениям и ролям.
3.Сравнить исходный PG-вариант с Cognee и Graphiti на одном корпусе; выбрать механизм по качеству, стоимости и переносимости.
4.Проверить личные роли/важность, затем контур внимания и обратной связи.
Готовый продукт не обязан показывать внутренний граф, если он устойчиво отвечает на нужные вопросы с доказательствами. Но для дальнейших агентских сценариев необходимо проверить API/экспорт принятых состояний или другой способ повторного использования результата без постоянного нового анализа архива. Если требуется редактирование и экспорт самого графа, это отдельный критерий приёмки.
**Следующий результат — таблица фактической доступности Asana Dash, Onyx и Glean с выбором двух вариантов для сравнительного испытания.** Установки, подключения частных источников и запуск испытаний этим исследованием ещё не выполнены.
Подробные поставки и критерии: [этапы реализации](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md#11-пять-конкретных-этапов-реализации-и-приёмки). Следующий результат — согласованный upstream/local manifest трёх проектов и исправленное сохранение всех memberships. Исследование не запускало установок, моделей или новых расписаний.
> Уточнение 05.10: [сначала испытать готовые системы](/Users/admin/Developer/personal-os/planning/personal-os-buy-adapt-build-2026-10-05.md). Asana Dash, Glean, Onyx, Rovo и Work IQ расширяют выбор. R2 — требования и условный вариант собственной реализации; объём собственного кода определяется после сравнения продуктов. Установки и испытания ещё не выполнены.
> Актуальное уточнение 05.10: [шесть уровней Personal OS](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md). Условия: личный доступ, открытые компоненты, без изменения систем компании. Очередность: покрытие проектов → эталон и явные связи → испытание Cognee/Graphiti → роли и важность → внимание и ретроспекция. Исследование выявило потери Asana; исправления и модельные прогоны ещё не выполнены. Корпоративный shortlist больше не определяет первый этап.
> Дополнение 04.10: [понимание потока работ и этапы WG-0–WG-4](/Users/admin/Developer/personal-os/planning/personal-os-work-graph-research-2026-10-04.md). Приоритет проверки — покрытие корпуса, обнаружение связей, текущая ситуация и роль пользователя. Это исследовательское уточнение для согласования; выбранный PostgreSQL core сохраняется, новые модели и graph runtime не внедрены.
@@ -8,7 +8,7 @@
## 1. Хранилище и граница истины
PostgreSQL — единственная каноническая БД. Raw payload хранится локально по content hash, с защищённым locator в БД. JSON, Obsidian и экраны — версионированные проекции. Таблицы существующего Asana mirror временно остаются adapter storage. Отдельную graph DB, Neo4j, Graphiti runtime и векторную БД в этот выпуск не вводим. Начальный поиск: exact identifiers, PostgreSQL full-text/trigram и bounded recursive queries. Embeddings подключаются только при измеренном улучшении retrieval на holdout; они не устанавливают факт связи.
PostgreSQL — единственная каноническая БД. Raw payload хранится локально по content hash, с защищённым locator в БД. JSON, Obsidian и экраны — версионированные проекции. Таблицы существующего Asana mirror временно остаются adapter storage. Отдельная graph DB в рабочем контуре пока не выбрана. В E3 сравниваются Cognee и Graphiti: дополнительное хранилище допустимо в изолированном испытании как перестраиваемый индекс, если экспорт и согласование с канонической PostgreSQL проходят приёмку. Это заменяет прежний безусловный запрет на проверку готового graph runtime. Начальный поиск: exact identifiers, PostgreSQL full-text/trigram и bounded recursive queries. Embeddings подключаются только при измеренном улучшении retrieval на holdout; они не устанавливают факт связи.
Source-owned поле и интерпретация различаются: GitHub определяет merge конкретного PR, Asana — назначение задачи, Алекс — намерение/цель. Фраза на встрече свидетельствует о сказанном и может обосновать decision; она сама не доказывает release. Статусы proposal/decision/implementation/verification/merge/release/impact независимы.
> Уточнение 05.10: [сначала испытать готовые системы](/Users/admin/Developer/personal-os/planning/personal-os-buy-adapt-build-2026-10-05.md). Asana Dash, Glean, Onyx, Rovo и Work IQ расширяют выбор. R2 — требования и условный вариант собственной реализации; объём собственного кода определяется после сравнения продуктов. Установки и испытания ещё не выполнены.
> Актуальное уточнение 05.10: [шесть уровней Personal OS](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md). Условия: личный доступ, открытые компоненты, без изменения систем компании. Очередность: покрытие проектов → эталон и явные связи → испытание Cognee/Graphiti → роли и важность → внимание и ретроспекция. Исследование выявило потери Asana; исправления и модельные прогоны ещё не выполнены. Корпоративный shortlist больше не определяет первый этап.
Проверено 2026-10-04. Статус: исследование и предложение выбора, не утверждённая миграция. Прочитаны официальные README, инструкции установки, отдельные архитектурные контракты и реальные SKILL.md. Продукты и навыки не устанавливались; агенты и расписания не запускались. Поисковый CLI skills использован только для каталога; его cache находится в /private/tmp.
# Personal OS: от потока событий к рабочей картине и управлению вниманием
5 октября 2026. Исследование, выборочная проверка Asana и проект реализации. **Реализация предложенных изменений не запускалась.**
## Решение и границы
**Следующий этап — восстановить проверяемое покрытие нескольких проектов и на этом корпусе испытать построение рабочего графа.** Покупка корпоративного продукта больше не является первым пунктом плана. Условия: личный доступ к существующим системам компании, открытые компоненты, локальная эксплуатация, отсутствие обязательных изменений процессов компании.
Задача состоит из шести разных преобразований: наблюдать → классифицировать → связать → определить отношение ко мне → оценить важность → распределить внимание. Ответ «поставить knowledge graph» покрывает лишь часть третьего преобразования. Ответ «подключить LifeOS» относится преимущественно к шестому.
Подходящие открытые механизмы существуют. Самый предметный найденный пример — Cognee Company Brain: объединение таблиц сотрудников, задач и протоколов в общую модель людей, команд и проектов. Graphiti предлагает другой акцент: изменение связей во времени. Это основания для ограниченного испытания готовых механизмов. Они не доказывают, что готовая система уже понимает обязанности, полномочия и карьерные цели конкретного человека.
**Предлагаемая сборка:** существующие Node/TypeScript-сборщики и PostgreSQL; готовый Python-компонент извлечения/графа после сравнения; собственные проверяемые правила ответственности и персонального ранжирования; привычный интерфейс с небольшими порциями обратной связи. Это адаптация готовых механизмов, без разработки своей языковой модели. Решение о конкретном graph runtime ещё не принято.
Этот документ заменяет очередность из [обзора покупки и адаптации](/Users/admin/Developer/personal-os/planning/personal-os-buy-adapt-build-2026-10-05.md) и уточняет [план R2](/Users/admin/Developer/personal-os/planning/system-review-2026-10-04/review.md). Старые 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, причина не установлена. Это проверка полей выбранных объектов, не подтверждение актуальности всего зеркала.
Доказательства: [выборки проектов](/Users/admin/Developer/personal-os/planning/six-layer-analysis-2026-10-05/asana-project-samples.json), [сопоставление с БД](/Users/admin/Developer/personal-os/planning/six-layer-analysis-2026-10-05/asana-mirror-comparison.json), [шесть подробных объектов](/Users/admin/Developer/personal-os/planning/six-layer-analysis-2026-10-05/asana-detail-samples-expanded.json), [результат сравнения](/Users/admin/Developer/personal-os/planning/six-layer-analysis-2026-10-05/asana-detail-comparison.json). Файлы содержат рабочие данные и предназначены для локальной документации.
### 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 как разные события. Полнота последних трёх источников этим аудитом не проверена.
### Порядок обработки
1. Обнаружить доступные разделы и сохранить каталог. Человек выбирает область пробного аудита по названиям; API выдаёт IDs, внутренние IDs создаёт код.
2. Полностью обойти выбранные проекты с пагинацией, включая закрытые задачи и детей. Записать проверяемый manifest объектов и недоступных полей.
3. Сохранить версии исходных наблюдений с source ID, временем источника, временем получения и content hash. Отдельно вычислять изменения.
4. Продолжить инкрементальное чтение с перекрытием окна, дедупликацией и контрольной сверкой. Ошибки и потерю доступа хранить явно.
5. Расширять охват: сначала дешёвые метаданные соседних направлений, затем содержимое по связям и отдельная выборка «пока не связанных» областей.
Пятый шаг нужен против замкнутого круга: если читать только известные интересы пользователя, новое направление никогда не станет известным. При этом нельзя обещать восстановить весь исторический журнал: API может уже не отдавать удалённые или прежние версии. Такие промежутки отмечаются как недоступные.
### Что взять готовым
**Airweave** полезен моделью Asana-объектов и набором полей: tasks, projects, sections, comments, files. В прочитанном модуле поля богаче наших. Однако tasks обходятся с пагинацией, а проекты, секции и комментарии в выбранных путях читаются одиночными запросами; `generate_entities` не использует переданный cursor. Это основание проверить границы, прежде чем заменять работающий сборщик. MIT. [Проверенный модуль](https://github.com/airweave-ai/airweave/blob/1ebe1af2dbfb90f3334410721e69997e4f02b320/backend/airweave/platform/sources/asana.py).
**Onyx** — готовая оболочка поиска и ответов по корпоративным документам. Его Asana-коннектор превращает задачу в текстовый документ; один project остаётся metadata, дубликаты task GID между проектами подавляются. Это удобный сравнительный вариант поиска, но такой формат не заменяет полный реестр memberships и типизированных связей. [Код коннектора](https://github.com/onyx-dot-app/onyx/blob/b6f4250472f452aebb56a3788d746af64767d0a1/backend/onyx/connectors/asana/asana_api.py).
**Рекомендация:** сначала исправить наш Asana adapter и формат покрытия; заимствовать проверенные поля и паттерны обхода. Перенос всей загрузки на Airweave сейчас добавит миграцию до доказательства её преимущества. Коннекторы Mattermost/Zoom всё равно требуют сверки с нашими конкретными способами доступа.
**Приёмка уровня:** на выбранных полностью пройденных проектах каждый доступный upstream ID присутствует либо имеет объяснённый отказ; повторный обход идемпотентен; обработаны перемещение между проектами, редактирование, закрытие, удаление/утрата доступа и более одной страницы детей/истории.
## 3. Уровень 2 — классифицировать смысл событий
### Классификация должна быть многомерной
Одно сообщение может одновременно содержать отмену решения, новый запрос и ссылку на будущую работу. Единственная метка «важно/неважно» уничтожит эту структуру. Для каждого фрагмента нужны независимые поля:
| Ось | Примеры значений |
|---|---|
| Что произошло | Изменение поля, запрос, обещание, предложение, решение, вопрос, результат, социальный ответ, автоматическое уведомление |
| Объекты и участники | Люди, задача, компонент, проект, файл, встреча, ссылка на артефакт |
| Модальность и состояние | Утверждается, предполагается, отклонено, отменено, условно, завершено по словам автора |
| Время и область | Когда действует, до какого срока, какая платформа/команда/версия |
| Основание и уверенность | Точный фрагмент, контекст треда, способ извлечения, версия модели, неоднозначность |
Вход классификатора — небольшой связный эпизод: исходное сообщение, родитель, существенные ответы и метаданные. Zoom режется по обсуждаемым вопросам с таймкодами; граница токенов сама по себе не является границей решения. Сначала используются явные API-поля и URL, затем модель извлекает недостающее. Противоречия сохраняются для следующего уровня.
### Подходящие реализации
**GLiNER2** объединяет извлечение сущностей, классификацию и структурированные связи; в текущем репозитории есть multilingual GLiNER2.5. Это предметный кандидат для дешёвого локального первого прохода смешанных русско-английских данных. Поддержка языка ещё не доказывает качество на наших тредах, аббревиатурах и отрицаниях. [Репозиторий](https://github.com/fastino-ai/GLiNER2), [извлечение отношений](https://github.com/fastino-ai/GLiNER2/blob/main/tutorial/6-relation_extraction.md), [статья](https://arxiv.org/abs/2507.18546).
**SetFit** подходит после появления небольшого набора наших примеров для устойчивых категорий, например «запрос review / решение / автоматическое уведомление». **Snorkel** позволяет согласовать слабые метки от правил и метаданных. Слабая метка не становится эталоном; конфликт правил и редкие классы требуют отдельной проверки. [SetFit](https://github.com/huggingface/setfit), [Snorkel](https://github.com/snorkel-team/snorkel).
**Jev** уместен как сравнительный вариант выбора из ограниченных кандидатов: тип события или наиболее вероятная сущность из подготовленного списка. Это закрытый API, поэтому он не является базовым решением при требовании открытого локального стека. Ограничения многошагового рассуждения и чувствительность к постановке задачи описывает сам поставщик. Цена входных токенов не учитывает автоматически стоимость retrieval, повторов и проверки. [Модели](https://docs.typesafe.ai/models), [ограничения](https://docs.typesafe.ai/model-jaggedness/jev-1.13), [entity alignment](https://docs.typesafe.ai/cookbooks/entity_alignment).
Сложные эпизоды — конфликт версий, неявный адресат, отмена предыдущего решения — передаются более сильной модели через заменяемый интерфейс. Локальный или внешний inference выбирается отдельно; открытый код обвязки не означает открытость подключённой модели. До испытания нельзя назвать оптимальную модель или обещать стоимость обработки всего архива.
### Собственная часть и проверка
Наши схемы категорий, контекст эпизода, признаки эскалации и правила хранения результата остаются предметной настройкой. «Шум» уходит в дешёвый индекс и редкую контрольную выборку, а не удаляется: короткое «отменяем» может иметь больше значения, чем длинный отчёт.
Приёмка измеряет recall редких обязательств/отмен, precision извлечённых фактов и отдельно качество по языкам, типам источника и длине треда. Средняя accuracy непригодна при преобладании уведомлений. Сравнение: правила без модели → GLiNER2 → добавление сложного анализатора. Нужно измерить прирост каждого перехода.
## 4. Уровень 3 — построить виртуальную структуру компании и работы
### Три наложенных графа
**Организационный:** компания, подразделение, команда, человек, назначенная роль и период её действия. **Рабочий:** направление, инициатива, проект, задача, решение, артефакт, инцидент, встреча и последовательность работ. **Компетенций и сотрудничества:** темы, подтверждённый опыт, повторяющиеся взаимодействия, зависимость от эксперта. Эти слои связаны, но отношения в них различны.
Частота совместных упоминаний помогает найти сообщество. Она не доказывает подчинённость, ответственность или блокировку. Проект Asana может быть контейнером повторяющихся встреч; одно направление может состоять из задач нескольких проектов. Один человек одновременно несёт несколько ролей в разных областях.
Неизвестный объект не должен исчезать из-за отсутствия класса в схеме. Его можно сохранить как временный тип с исходным названием; повторяющиеся случаи образуют предложение расширить словарь. Произвольные типы получают стабильные IDs и общие поля доказательства/времени, а специфические атрибуты — версионированную схему.
### Как именно появляются связи
1.**Явные связи:** source ID, URL, memberships, assignee, parent, dependency, review request. Их извлекает код, сохраняя источник и его версию.
2.**Кандидаты:** точные aliases, лексический поиск и embeddings дают объединённый короткий список. Совпадение строки — кандидат на идентичность; общий предмет — кандидат на отношение.
3.**Проверка:** модель получает пару/небольшой набор объектов, контекст и допустимые типы связи. Она возвращает утверждение с цитатой либо `unknown`, включая отрицательные свидетельства.
4.**Согласование:** валидатор проверяет типы, даты, идентичность и конфликты. Неоднозначное слияние людей не проходит автоматически; явная ссылка может быть принята без модели.
5.**Публикация:** принятый граф строится из утверждений определённой версии. Исправление или отмена пересчитывает зависимые представления; исходные свидетельства сохраняются.
Для людей ключ — 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. [Проверенный пример](https://github.com/topoteretes/cognee/blob/b32d8afc59e1064d9291b9828a8a147be9cc8bab/examples/demos/company_brain/multi_source/README.md).
Но в модели примера человек, команда и проект идентифицируются по `name`; у человека простое поле роли и одна команда. Для нас нужны исходные идентификаторы, несколько scoped roles и история. Это ограничения конкретного примера, не доказательство невозможности настройки Cognee. [Модель примера](https://github.com/topoteretes/cognee/blob/b32d8afc59e1064d9291b9828a8a147be9cc8bab/examples/demos/company_brain/multi_source/models.py). Другой пример organisational hierarchy получает уже структурированные people/company JSON: его нельзя выдавать за доказательство автоматического восстановления оргструктуры из шума.
**Graphiti — альтернативный кандидат, если решающими оказываются временные отношения.** Готовые механизмы добавления эпизодов, поиска, разрешения сущностей и изменения отношений сокращают объём нашего кода. Однако LLM-разрешение совпадений требует проверки ложных слияний; выбранные backend-драйверы означают дополнительное graph storage. Это не встроенная возможность нашего PostgreSQL. [Репозиторий](https://github.com/getzep/graphiti), [проверенные ранее версии](/Users/admin/Developer/personal-os/planning/work-graph-research-2026-10-04/source-manifest.json).
**GraphRAG и BERTopic — помощь для обнаружения направлений.** Кластеры/сообщества и их сводки позволяют заметить повторяющуюся тему за пределами назначенных задач. Полученный кластер первоначально называется «кандидат направления»; его название, границы и участники ещё не являются организационным фактом. GraphRAG полезен для обзорных вопросов о большом корпусе; он не заменяет модель текущих обязанностей. [GraphRAG](https://arxiv.org/abs/2404.16130), [варианты индексации](https://microsoft.github.io/graphrag/index/methods/), [BERTopic](https://github.com/MaartenGr/BERTopic).
**Splink/исследования entity matching** полезны для неоднозначных карточек людей и объектов: сравнение нескольких признаков, блокировка кандидатов, вероятность совпадения. Они не определяют смысл рабочей зависимости. [Splink](https://moj-analytical-services.github.io/splink/), [Ditto](https://github.com/megagonlabs/ditto). Словари W3C ORG и PROV дают готовые идеи для ролей с областью/временем и происхождения утверждений; заимствование словаря не требует перехода на RDF. [ORG](https://www.w3.org/TR/vocab-org/), [PROV-O](https://www.w3.org/TR/prov-o/).
### Конкретные примеры приёмки из аудита
Две задачи `webExtensionStateRestorationGate` относятся к разным платформам. Правильный результат: две задачи, одна связанная техническая тема/инициатива и отдельные назначения. В описаниях есть срок 28.10.2026 и условие проверки удаления после стабильного исправления. Это повод сохранить будущую условную обязанность, а не автоматически объявить задачу самой срочной сегодня.
Retrospectives — контейнер серии встреч: нужна связь экземпляров с серией, датами, участниками и решениями. Release Train Visual Overview — артефакт процесса; для его связи с релизными событиями потребуется прочитать саму схему. Старый протокол показывает ответственность тогда; он не назначает человека текущим DRI спустя годы.
**Просмотр графа:** Cytoscape.js даёт готовый движок интерактивного графа. Наши экраны должны показывать выбранное направление, связи в один-два перехода, слой отношений, временной срез и доказательство по клику. Обзор всей компании агрегируется до направлений; неопределённость и непокрытые разделы видимы. Obsidian/Canvas — читаемая проекция и место заметок. [Cytoscape.js](https://github.com/cytoscape/cytoscape.js).
## 5. Уровень 4 — найти пользователя в этой структуре
### Что нужно моделировать отдельно
| Категория | Основание | Что разрешено заключать |
|---|---|---|
| Прямая обязанность | Актуальное назначение, принятый запрос, действующая ротация, подтверждённая зона ответственности | Работа требует действия или контроля пользователя. |
| Пересекающаяся ответственность | Зависимость от его области, обязательное согласование, влияние на поддерживаемый компонент | Проверить участие и последствия; это не автоматическое назначение исполнителем. |
| Смежная компетенция | Подтверждённый опыт и техническое пересечение | Пользователь может быть полезен; наличие опыта не создаёт обязанности. |
| Карьерная возможность | Актуальная цель пользователя плюс возможность получить нужный опыт/влияние | Предложить выбор с затратами и пользой, не заносить молча в обязательства. |
| Контекст или неопределённость | Соседняя тема, слабая связь, неполные данные | Дайджест/дополнительная проверка; не создавать срочную задачу. |
Роль — отдельное назначение человека в определённой области на определённое время, с источником полномочий. Должность не описывает все реальные обязанности. Автор PR, участник встречи, assignee, reviewer, владелец компонента и человек, который разово помог, — разные отношения.
### Алгоритм персонализации
Сначала формируется профиль из явных текущих назначений, ротаций, источников целей и проверенного опыта. Затем для каждого рабочего объекта ищутся **типизированные пути** к профилю: `задача → блокирует → обязательство пользователя`; `изменение → затрагивает → компонент → зона ответственности`; `инициатива → требует компетенцию → подтверждённая цель развития`.
Для каждого пути сохраняются срок действия, подтверждение и контрсвидетельства. Простая близость на графе недостаточна: соседство по встрече не равно долгу. «Мы сделаем» без определённого адресата остаётся неразрешённым обязательством команды. Назначение давно завершённой задачи служит историей опыта, а не текущей нагрузкой.
LLM готовит предложения о профиле. Короткое подтверждение пользователем требуется при изменении его целей, границ ответственности или неоднозначной идентичности. Повторно подтверждать каждое явное API-назначение не нужно. Исправление сохраняется как правило ограниченной области; один ответ не должен переписывать весь профиль.
### Что реально придётся настроить самим
Cognee/Graphiti могут хранить и находить эти отношения. ORG помогает задать схему. Но смысл «это входит в мои обязанности», предпочтения развития и полномочия конкретной команды должен задаваться нашими политиками и подтверждёнными источниками. Ни один изученный компонент не показал готовую проверенную персонализацию этого уровня на наших данных.
Исследование оценки expert finding показывает риск: если эталон строится только из предложенных системой кандидатов, качество завышается в пользу легко находимых буквальных совпадений. Поэтому оценивать нужно и независимо отобранные работы, где пользователь не упомянут, но его область затронута. Упоминания, экспертиза, ответственность и карьерное желание размечаются раздельно. [On the Biased Assessment of Expert Finding Systems](https://arxiv.org/abs/2410.05018).
**Приёмка:** система объясняет категорию конкретным путём и источниками; не назначает обязанности по частоте сообщений; различает людей с одинаковыми именами; умеет сказать «не знаю»; обнаруживает косвенное влияние без прямого mention пользователя.
## 6. Уровень 5 — отобрать интересующее и ранжировать важность
### Важность — несколько осей, а не один непрозрачный score
После определения отношения к пользователю для каждой кандидатной работы вычисляются:
| Ось | Проверяемый вопрос |
|---|---|
| Значимость | Какое обязательство, цель, риск или результат затронуты? |
| Срочность | Что ухудшится от задержки, к какой дате и на каком основании? |
| Ответственность и возможность повлиять | Нужен именно пользователь? Он исполнитель, согласующий, консультант или наблюдатель? |
| Готовность и цена | Есть ли входные данные, сколько внимания нужно, кого это разблокирует? |
| Уверенность | Какая неизвестность способна изменить порядок и сколько стоит её прояснить? |
Из этих осей строится понятная матрица «влияние × срочность», а рядом показывается тип участия. Жёсткие обязательства и подтверждённые критические риски учитываются раньше необязательных возможностей. Карьерный рост получает отдельный защищённый бюджет, если это соответствует текущим целям; он не должен навсегда проигрывать потоку мелких срочных запросов.
Число комментариев, свежесть сообщения и тематическая близость могут помочь retrieval, но не являются доказательством важности. Молчаливый проект с близким сроком может быть важнее шумного треда. Система должна показывать причину подъёма: например, появился запрос обязательного review, изменился срок, подтверждена блокировка. Простое повторение старой темы не меняет приоритет.
### Готовая техника и собственная политика
Первый вариант — прозрачные правила, несколько очередей и объяснимое сравнение верхних кандидатов. Очереди: обязательства, пересечения/консультации, стратегические возможности, контекст. Внутри каждой — приоритет и готовность; между ними — ограничения внимания следующего уровня.
**Learning-to-rank** имеет смысл после накопления пользовательских сравнений. LightGBM предоставляет `lambdarank` и `rank_xendcg`; его готовые алгоритмы обучают порядок по признакам и предпочтениям. Они не создают цели пользователя и не решают отсутствие меток. Сначала объяснимый baseline, затем проверка прироста на отложенных периодах/проектах. [LightGBM parameters](https://lightgbm.readthedocs.io/en/latest/Parameters.html).
Обратная связь должна различать «не моя область», «важно, но позже», «зависимость неверна», «уже решено», «сейчас нет сил». Игнорирование карточки не равно отрицательной метке важности. Пять коротких сравнений полезнее требования вручную разметить тысячи сообщений.
**Приёмка:** измеряются пропуски существенных обязательств, качество верхних рекомендаций, объяснимость и устойчивость порядка при добавлении шума. Отдельно проверяется разнообразие: система не должна снова рассказывать один удобный эпизод вместо всей существенной работы. Для карьерного обзора единица охвата — направления и результаты за период, а не число похожих примеров.
## 7. Уровень 6 — балансировать внимание и учиться на результате
### Вход и поведение
Вход — ранжированные работы, календарь, текущий фокус, заявленное самочувствие, границы рабочего дня и цели баланса. Отсутствие событий ActivityWatch не доказывает свободное время; активное приложение не доказывает намерение или эффективность.
Планировщик учитывает доступные окна, длительность и неопределённость работы, подготовку к встречам, перерывы, предел незавершённых действий и стоимость переключения. Выход — одно следующее действие и небольшой резерв. Новые рекомендации собираются до перехода между задачами; исключения требуют подтверждённой срочности.
В существующем `capacity-model.js` уже есть данные о встречах и конце дня, но расчёт суммы встреч требует проверки пересечений интервалов и обрезки к доступному окну. Это конкретная недоработка до заявления о корректной ёмкости дня. Ограничить список тремя действиями недостаточно для балансировки нагрузки.
### Что взять готовым
**Super Productivity** — открытый кандидат для интерфейса задач, timeboxing и контекста текущей работы. Его plugin API предоставляет задачи, текущий контекст и события task update/complete. Это реальная точка подключения Personal OS; интеграцию с нашим графом нужно написать. Задачи источника отображаются как проекции с исходными IDs, без появления второго независимого списка обязательств. MIT. [Продукт](https://github.com/super-productivity/super-productivity), [проверенный plugin API](https://github.com/super-productivity/super-productivity/blob/ca58d42dcac9b4d185444d59c528046d93486aae/packages/plugin-api/README.md).
**OR-Tools** решает ограничения расписания и зависимостей. Он полезен, если простой планировщик не справляется с несколькими окнами, предшествованиями и ресурсами. Функция предпочтений, цена переключения и предел нагрузки остаются нашими. На первом этапе достаточно детерминированного планирования с проверяемыми ограничениями. [Scheduling](https://developers.google.com/optimization/scheduling), [код](https://github.com/google/or-tools).
LifeOS-подходы к личным целям и ретроспекции могут дать структуру профиля/обзоров. Они не заменяют предыдущие уровни. Начинать с новой оболочки личных заметок сейчас не устраняет потери в Asana и неизвестные рабочие связи.
### Ретроспектор и улучшение
Ретроспектор сравнивает предсказанную значимость и длительность с фактом: работа состоялась, была отложена из-за внешней блокировки, потребовала больше времени, стала ненужной, дала результат. Отдельно проверяет, сколько внимания съела сама система. Исправления направляются в нужный слой: extractor, связь, профиль, ранжирование или capacity.
Переобучение/изменение правил проходит через версии, повторную оценку на фиксированном наборе и откат. Оно не включается автоматически от каждого клика. Исследования прерываний дают основание измерять стресс и цену переключений, а не только скорость выполнения; конкретные числа из лабораторного эксперимента нельзя переносить на пользователя с ADHD. [The Cost of Interrupted Work: More Speed and Stress](https://ics.uci.edu/~gmark/chi08-mark.pdf).
**Приёмка:** план не нарушает заявленные границы дня, не ставит перекрывающиеся встречи дважды, сохраняет текущий фокус при несущественных обновлениях, объясняет перестановку и позволяет отменить её одним действием.
## 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, но скорость и расход памяти выбранной модели ещё не измерены. [Срез возможностей](/Users/admin/Developer/personal-os/planning/six-layer-analysis-2026-10-05/local-capabilities.json).
| Часть | Предложение | Статус |
|---|---|---|
| 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](https://github.com/HKUDS/LightRAG/blob/main/examples/lightrag_gemini_postgres_demo.py), [HippoRAG](https://github.com/OSU-NLP-Group/HippoRAG).
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. [Проверенный файл](https://github.com/onyx-dot-app/onyx/blob/b6f4250472f452aebb56a3788d746af64767d0a1/backend/onyx/tools/tool_implementations/knowledge_graph/knowledge_graph_tool.py).
Numen близок по предметной модели персонального рабочего контекста, но ранее прочитанный код показал ограничения linker/scoring, а подходящих готовых Asana/Zoom/Mattermost adapters не найдено. Использовать как источник схем/идей, а не объявлять готовым основанием без проверки. Glean/Rovo/Asana Dash остаются примерами корпоративного класса; они не соответствуют исходному условию открытой личной установки без организационного внедрения.
Исследовательские ориентиры для испытаний: **STaRK** проверяет retrieval, требующий и текста, и отношений; **QMSum** — поиск и сводки по конкретным вопросам к встречам; retrieve→rerank разделяет полноту получения кандидатов и качество их порядка. Эти наборы не измеряют личную важность, для которой нужен свой небольшой эталон. [STaRK](https://github.com/snap-stanford/stark), [QMSum](https://github.com/Yale-LILY/QMSum), [Sentence Transformers retrieve/rerank](https://www.sbert.net/examples/sentence_transformer/applications/retrieve_rerank/README.html).
## 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](/Users/admin/Developer/personal-os/planning/six-layer-analysis-2026-10-05/source-manifest.json). Чтение исходников — статический аудит; чужие demos не исполнялись.
**Ещё не сделано:** исправления сборщика, полный обход выбранных проектов, модельные прогоны, выбор победителя, измерение ранжирования и запуск контура внимания. Следующий результат реализации — **согласованный upstream/local manifest трёх проектов и исправленное сохранение всех memberships**.
> Уточнение 05.10: [сначала испытать готовые системы](/Users/admin/Developer/personal-os/planning/personal-os-buy-adapt-build-2026-10-05.md). Asana Dash, Glean, Onyx, Rovo и Work IQ расширяют выбор. R2 — требования и условный вариант собственной реализации; объём собственного кода определяется после сравнения продуктов. Установки и испытания ещё не выполнены.
> Актуальное уточнение 05.10: [шесть уровней Personal OS](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md). Условия: личный доступ, открытые компоненты, без изменения систем компании. Очередность: покрытие проектов → эталон и явные связи → испытание Cognee/Graphiti → роли и важность → внимание и ретроспекция. Исследование выявило потери Asana; исправления и модельные прогоны ещё не выполнены. Корпоративный shortlist больше не определяет первый этап.
> Исследовательское дополнение 04.10: [предметный граф, приоритеты и gates WG-0–WG-4](/Users/admin/Developer/personal-os/planning/personal-os-work-graph-research-2026-10-04.md). Начинать реализацию с карты покрытия и представительского набора оценки; выбор оболочки следует за проверкой понимания работ. Дополнение ещё не включено в печатные PDF R2.
@@ -400,24 +400,24 @@ Baseline собирается без длинного опроса: коротк
| AC15 | 20 activity intervals + 2 shadow days → ручная сверка источников/unknown; критерии ложных связей соблюдены. |
| AC16 | 5 pilot days + 10 reliability days + restore + iPad test → SC1-SC8 и отдельный UI verdict. |
Gate G1 - AC01/08-11 для первого вертикального среза. G2 - AC02-07 для графа. G3 - AC04-07/12-14 для агентного слоя. G4 - AC15-16 и SC1-SC8 на pilot/reliability. Неуспех gate оставляет функцию в shadow и фиксирует причину; новая дата сама по себе не закрывает приёмку.
Историческая группировка проверок R2 (не текущая очередность E1–E5): Gate G1 - AC01/08-11 для первого вертикального среза. G2 - AC02-07 для графа. G3 - AC04-07/12-14 для агентного слоя. G4 - AC15-16 и SC1-SC8 на pilot/reliability. Неуспех gate оставляет функцию в shadow и фиксирует причину; новая дата сама по себе не закрывает приёмку.
<!-- page -->
## 20. Исполняемый порядок и решение о выпуске
| Этап | Результат, зависимости и gate |
| Этап | Конкретный результат и gate |
|---|---|
| R0. Утверждение пакета | Принять эту архитектуру целиком, границы данных/доставки и budget policy. Технические контракты внутри пакета уже состыкованы. Выход - versioned decision record. |
| R1. Первый полезный вертикальный срез | Общий snapshot/manifest + исправленные capacity/demands + scoped feedback + простой локальный экран на fixture/live shadow. AC01/08-11. Пользователь сразу может проверить «почему» и исправить карточку. |
| R2. Общая память | Discovery, versioned evidence graph, typed exact links, project/sequence/career projections и graph UI. AC02-07; fixtures перестают быть ручным runtime registry. |
| R3. Подключение аналитиков | Read-only packets, семь prompt contracts, capability runner, manual review/eval, advisor preflight, event-driven project/career analysis. AC04-07/12-14. Новые schedules включаются только после принятого gate. |
| R4. Замкнутый Personal OS | Календарь или явная ручная занятость, planner, presence/delivery, ретро и change-review; 2 shadow days/20 intervals, 5 pilot days, 10 reliability days, restore и client acceptance. SC1-SC8. |
| E1. Покрытие | Полный согласованный срез трёх проектов; upstream/local manifest; все memberships, stories и дети; проверка повторного обхода. |
| E2. Эталон и явный граф | 60–100 разнообразных эпизодов для начала; source IDs, временные роли, независимый holdout; без доминирования одного кейса. |
| E3. Выбор механизма | Сравнение правил/PG, Cognee и Graphiti на одном корпусе; ошибки связывания, отмены, стоимость и ручная нагрузка. Один выбранный механизм. |
| E4. Роли и важность | Проверенный профиль, объяснимые категории участия и порядок; двухнедельное наблюдение рекомендаций без автоматических внешних изменений. |
| E5. Контур внимания | Ограничения дня, текущий фокус, scoped feedback, единый контекст аналитиков, replay/restore и эксплуатационная приёмка SC1–SC8. |
После R0 параллельно готовятся UI fixtures, source adapters и holdout dataset. Они используют одну версию source/evidence/publication contract. iPad build/install proof идёт отдельно и не блокирует первый Mac pilot. Agent execution transport подключается после своей приёмки; аналитика проектов работает без Balda.
Очередность E1–E5 уточнена исследованием 05.10; полные критерии каждого этапа приведены в разборе шести уровней. Source adapters и holdout dataset готовятся по общему контракту; UI fixtures могут готовиться независимо. Они используют одну версию source/evidence/publication contract. iPad build/install proof идёт отдельно и не блокирует первый Mac pilot. Agent execution transport подключается после своей приёмки; аналитика проектов работает без Balda.
| Что утверждает Алекс | Подготовленный вариант |
|---|---|
| Архитектура и порядок | Node/TypeScript + PostgreSQL + launchd; роли и контракты разделов 03-16; R1 → R2 → R3 → R4. |
| Архитектура и порядок | Node/TypeScript + PostgreSQL; Python adapter для готового компонента по результатам E3; роли и контракты разделов 03–16; E1 → E2 → E3 → E4 → E5. |
| Доставка и автономность | Первый пилот - локальная карточка; read-only analyst jobs; внешние записи и новые кодинговые jobs требуют принятого отдельного scope. |
| Личные ограничения | Граница рабочего дня, разрешённые окна, классы данных для моделей и актуальные карьерные цели. Исторические цели доступны как датированные кандидаты. |
| Бюджет и приёмка | SC1-SC8; cost/token/reviewer caps; максимальная нагрузка на человека. Пока cap не установлен, автоматический LLM dispatch закрыт. |
**Сначала читать [[personal-os-six-layer-analysis-2026-10-05]].** Он определяет текущие ограничения и очередность E1–E5; ниже — контракты и исторические исследования R2. Выборочный аудит уже подтвердил пропуски Asana; исправления кода ещё предстоят.
Архитектурные противоречия устранены в плане: одна PostgreSQL-модель, immutable evidence и типизированные claims, semantic acceptance, единая публикация, scoped feedback, один владелец каждого collector и последовательные gates реализации. Runtime по этому плану ещё не внедрён; новые запуски и расписания не включались.
@@ -34,6 +36,14 @@ updated: 2026-10-04
[[personal-os-work-graph-research-2026-10-04]] — исследование Glean, Numen, Graphiti/GraphRAG, Jev и альтернатив; локальный масштаб корпуса, data flow, роль пользователя, критерии приёмки и этапы WG-0–WG-4. Первый этап теперь — карта покрытия и репрезентативный набор оценки. Сравнение LifeOS отложено до проверки предметного слоя. Это предложение для согласования, без установки моделей и запуска новых расписаний; PDF остаются R2.
## Выбор готового продукта — уточнение 05.10
## Действующая очередность — 05.10
[[personal-os-buy-adapt-build-2026-10-05]] — расширенный shortlist Asana Dash, Glean, Onyx, Rovo и Work IQ. Сначала проверка доступности и сравнение двух продуктов; собственная разработка только для доказанных пробелов. Дополняет и корректирует прежний вывод исследования графа.
[[personal-os-six-layer-analysis-2026-10-05]] — актуальный подробный разбор: сверка трёх Asana-проектов, подтверждённые потери сборщика, открытые механизмы по каждому уровню, собственная логика ответственности и важности, data flow, E1–E5 и приёмка. Условия: личный сетап без изменения систем компании.
1. Полнота выбранных проектов и все memberships.
2. Разнообразный эталон и явный граф.
3. Сравнение правил/PG, Cognee и Graphiti.
4. Проверка роли пользователя и матрицы важности.
5. План внимания, ретроспекция и эксплуатационная приёмка.
[[personal-os-buy-adapt-build-2026-10-05]] сохранён как справочный обзор; корпоративный shortlist больше не определяет первый этап. Исследование завершено, дефекты сборщика ещё не исправлены, модели не испытывались. Печатные PDF остаются R2 и не содержат этого уточнения.
**Сначала испытать готовые системы на одинаковых сценариях понимания работ.** Дополнение 05.10: [готовый продукт, адаптация или собственная сборка](/Users/admin/Developer/personal-os/planning/personal-os-buy-adapt-build-2026-10-05.md). Прежний обзор недостаточно охватывал готовые продукты: добавлены Asana Dash, Onyx, Rovo и Work IQ; Glean рассматривается как кандидат использования. Представительный корпус нужен для сравнения всех вариантов, не только собственного кода.
**Актуальная постановка и очередность:** [шесть уровней Personal OS](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md). Сначала доказать покрытие выбранных проектов, затем сравнить готовые открытые механизмы извлечения/графа на общем корпусе. Личный доступ без изменения систем компании исключает корпоративное внедрение как первый этап. Ниже сохранено исходное исследование компонентов и контрактов.
Проблема состоит из пяти отдельных задач: полнота наблюдения; выделение объектов и событий; связывание объектов между источниками; восстановление текущей ситуации; приоритизация относительно роли, целей и доступного внимания. Один хороший классификатор не гарантирует остальные четыре результата.
@@ -224,7 +224,7 @@ STaRK полезен как образец оценки поиска по тек
## 9. Этапы проверки и условной реализации для согласования
Сначала применяется выбор продукта из [дополнения 05.10](/Users/admin/Developer/personal-os/planning/personal-os-buy-adapt-build-2026-10-05.md). WG-0 обслуживает сравнение продуктов и компонентов; WG-1–WG-4 описывают необходимые результаты, которые может обеспечить готовый продукт. Это не поручение реализовать каждый модуль самостоятельно.
Текущие поставки и gates определяет [разбор шести уровней](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md). WG-0–WG-4 ниже остаются декомпозицией требований: готовые компоненты используются там, где проходят общий эталон; корпоративный shortlist не является условием начала.
| Этап | Ограниченный результат | Связь с существующим планом |
|---|---|---|
@@ -248,4 +248,4 @@ STaRK полезен как образец оценки поиска по тек
Не измерены: качество моделей на нашем корпусе, фактическая цена backfill, полнота всех upstream-источников, готовность Glean для нашего доступа, скорость локального inference. Предлагаемые технологии и пороги не объявляются уже выбранными или достигнутыми. Печатные схемы R2 пока не содержат это дополнение; данный текст — актуальное исследовательское уточнение для согласования.
Следующий ограниченный результат: **проверить доступность Asana Dash, Onyx и Glean и выбрать два варианта для сравнительного испытания; небольшой общий набор сценариев подготовить в WG-0.**
Следующий ограниченный результат: **согласованный upstream/local manifest трёх Asana-проектов и исправленное сохранение всех memberships**, по новому разбору шести уровней.
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Alexey Martemyanov committed