From 5dd53b27b511180447ddb5d88b508a3c590b0d7c Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Sun, 4 Oct 2026 22:23:08 +0600 Subject: [PATCH] [2026-10-04] eagle: personal/projects/personal-os/personal-os-best-practices-2026-10-04.md personal/projects/personal-os/personal-os-system-review-index.md --- .../personal-os-best-practices-2026-10-04.md | 124 ++++++++++++++++++ .../personal-os-system-review-index.md | 4 + 2 files changed, 128 insertions(+) create mode 100644 personal/projects/personal-os/personal-os-best-practices-2026-10-04.md diff --git a/personal/projects/personal-os/personal-os-best-practices-2026-10-04.md b/personal/projects/personal-os/personal-os-best-practices-2026-10-04.md new file mode 100644 index 00000000..6fa382fe --- /dev/null +++ b/personal/projects/personal-os/personal-os-best-practices-2026-10-04.md @@ -0,0 +1,124 @@ +--- +status: research-proposal +updated: 2026-10-04 +canonical_source: /Users/admin/Developer/personal-os/planning/personal-os-best-practices-2026-10-04.md +--- +# Personal OS — внешнее сравнение и конкретные поправки к R2 + +Дата проверки: 2026-10-04. База сравнения: миссия Personal OS, system-review R2, graph-design R2, проекты промптов и текущий package.json. Изучены официальные документы и публичные репозитории; продукты не устанавливались и сравнительный benchmark на наших данных не запускался. Ниже — инженерные выводы для нашего случая, а не рейтинг универсально «лучшей системы». + +**Главное:** у R2 сильная модель происхождения и времени, но недостаточно специфицированы поиск решающих свидетельств, цена человеческого review, устойчивость планирования, возобновление длинного процесса и полный жизненный цикл памяти. Код дополнительно отстаёт от собственного плана: общий граф, semantic runner и пользовательский цикл ещё не внедрены. Эти два вида отставания различаются. + +## 1. Какие системы полезны как образцы + +| Класс и первичные источники | Практика, которую стоит перенять | Применимость к Personal OS | +|---|---|---| +| [Graphiti](https://github.com/getzep/graphiti), [код search recipes](https://github.com/getzep/graphiti/blob/main/graphiti_core/search/search_config_recipes.py) | Temporal facts с provenance; несколько способов retrieval и reranking. | Модель времени у нас уже заложена. Недостаёт измеримого retrieval и сборки контекста. Библиотека требует дополнительного runtime/backend; её установка не заменяет наши правила принятия истины. | +| [Letta memory blocks](https://docs.letta.com/v1-sdk/memory/memory-blocks), [Khoj](https://github.com/khoj-ai/khoj) | Ограниченные блоки памяти, общая память для ролей; персональный поиск/агенты/автоматизации как доступный пользовательский продукт. | Нужен один короткий контекст для каждого сценария и удобный вход пользователя. Общая изменяемая память Letta имеет риск перезаписи; у нас blocks должны быть read-only проекциями принятых версий. | +| [DBOS TypeScript](https://github.com/dbos-inc/dbos-transact-ts), [Temporal](https://docs.temporal.io/workflow-execution), [LangGraph interrupts](https://docs.langchain.com/oss/javascript/langgraph/interrupts) | Сохранение исполнения между шагами, ожидание человеческого решения, восстановление после сбоя. | DBOS — первый кандидат для ограниченной проверки совместимости с Node/TS + PostgreSQL. Temporal — полезный эталон гарантий, но отдельный сервис увеличивает эксплуатацию. LangGraph — кандидат для сложной логики агента, не ещё одна обязательная очередь поверх всего. | +| [Timefold: replanning](https://docs.timefold.ai/timefold-solver/latest/responding-to-change/non-disruptive-replanning), [Sunsama daily planning](https://help.sunsama.com/docs/usage-guides/daily-planning/) | Закрепление уже принятого плана, цена изменений, ограниченный дневной объём, начало/завершение дня. | Заимствуем поведение и ограничения; вводить Java solver или подписку для первого среза не требуется. | +| [Screenpipe](https://github.com/screenpipe/screenpipe/blob/main/README.md), [Mem0 deletion](https://docs.mem0.ai/core-concepts/memory-operations/delete) | Доступ к личному контексту по приложениям/типам/времени; явные операции удаления памяти. | Перенимаем contract доступа и забывания. Полная запись экрана не нужна для нашей миссии по умолчанию; остаётся точечный сбор ActivityWatch/сессий/разрешённых источников. | + +Это образцы отдельных частей. Проверенные источники не устанавливают, что какой-либо из этих продуктов уже решает нашу миссию целиком или лучше работает на данных Алекса. + +## 2. Пять существенных поправок + +### A. P0 — поиск доказательств и сборка контекста + +**Что уже есть:** identifiers, full-text, bounded traversal, immutable packets, source spans, lineage. **Чего не хватает:** контракт выбора содержимого packet, отдельная проверка retrieval recall и обязательный поиск опровержений. Иначе поздняя отмена может существовать в БД, но не попасть к аналитику — прежняя ошибка Core Data повторится. + +Graphiti содержит разные search recipes; [Anthropic context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) описывает ограниченность контекста, адресную подгрузку и сжатие истории. Наш вывод: нужен context assembler как функция evidence core, а не новая БД или постоянно работающий агент. + +**Конкретное решение для плана:** + +1. Packet содержит пять секций: подтверждённые цели/ограничения пользователя; текущее состояние scope; релевантные новые события; отмены/конфликты/контрсвидетельства; адреса дополнительных источников с coverage. Для секций задаются лимиты и hash версии. +2. Retrieval выполняет exact IDs → text search → bounded graph paths → отдельный запрос поздних решений/отмен → rerank/dedup. Vector search добавляется только после сравнения с этим baseline. Scope/time/permissions фильтруются до ranking. +3. Context assembler записывает, какие records включены/исключены и почему; обязательное контрсвидетельство не вытесняется общим лимитом top-k. Если необходимое основание не помещается, возвращается gap или запускается bounded follow-up packet; текущий вывод остаётся unknown. +4. Project/career summaries являются materialized views с input revision IDs. Новое решение делает summary stale; автоматическое переиспользование stale summary запрещено. Цели/предпочтения — versioned user state; поведение человека не переписывает их автоматически. +5. Возобновление работы использует маленькую карточку: где остановился, последний принятый результат, нерешённый вопрос, следующий шаг и ссылки. Это производная истории; она не становится новым доказательством самой себя. + +**Приёмка BP-A, R2→R3:** отмена спрятана среди нерелевантных похожих документов; находится при разных формулировках и позднем backfill. На наборе с размеченными обязательными источниками измеряются recall retrieval, recall контрсвидетельств, citation correctness и итоговый статус раздельно. Фиксированные критические случаи требуют полного набора решающих evidence; top-k hit по одному удобному источнику недостаточен. + +### B. P0 — автономность без бесконечного человеческого review + +**Что уже есть:** manual semantic acceptance в пилоте, reviewer budget, scoped feedback. **Недосмотр:** blanket review всех смысловых claims может сделать Алекса главным обработчиком очереди, а accepted-only consumers — почти бесполезными. Сам budget предотвращает перерасход, но не определяет, как выбирать полезное ревью. + +[LangGraph interrupts](https://docs.langchain.com/oss/javascript/langgraph/interrupts) даёт сохраняемую паузу и возобновление; предупреждает о повторном исполнении кода при resume. Это механизм, а выбор того, что стоит показывать человеку, должен определяться нашим продуктом. + +**Конкретное решение:** сохраняем независимые поля `evidence_kind = observed/reported/inferred` и `review_status`. Достоверно извлечённая цитата «на встрече сказано X» не равна утверждению «X внедрено». Точные API facts принимает код; смысловые candidates в пилоте принимаются человеком. Непринятые candidates доступны в раскрываемом разделе и для дальнейшего поиска, но не меняют обязательства/факт внедрения/решение о внешнем действии. + +Review queue группирует связанные candidates по решению, показывает evidence и цену ошибки; порядок: ближайшее реально зависящее решение → последствия ошибки → цена проверки. Нет запроса, если ответ не меняет предстоящего действия. При исчерпании бюджета остается unknown и безопасный доступный план. Автоматическое принятие разрешается по одному оценённому классу и policy version; confidence модели не служит порогом доверия. + +`review_requests` хранит target/input hash/policy version, варианты ответа, expires_at, state pending/answered/expired/superseded. Resume проверяет актуальность основания и полномочий; новая отмена делает старый approve неприменимым. Повторный ответ не дублирует публикацию. Это расширение существующих job/feedback contracts, а не отдельная система правды. + +**Приёмка BP-B, R3:** поток из 100 candidates укладывается в согласованный лимит reviewer minutes; проверяется, что важный вопрос показан, а остальные не порождают поток уведомлений. Restart во время ожидания сохраняет запрос. Ответ после изменения evidence не принимает старый claim. Качество измеряется одновременно по ошибкам, полезному покрытию и нагрузке: «всё unknown» не проходит. + +### C. P0 — планнер управляет посильным и устойчивым планом + +**Что уже есть:** constraints, вместимость, current focus, перерывы, end-of-day, defer и reviewer load. **Недосмотр:** слова «важность / цена переключения» ещё не задают алгоритм; при каждом событии LLM может менять рекомендацию. Личный отдых указан в миссии, но модель в основном наполнена рабочими demands. + +Timefold явно разделяет [ограничения разных уровней](https://docs.timefold.ai/timefold-solver/latest/constraints-and-score/overview), [непомещающуюся работу](https://docs.timefold.ai/timefold-solver/latest/domain-modeling/common-patterns) и [цену перепланирования](https://docs.timefold.ai/timefold-solver/latest/responding-to-change/non-disruptive-replanning). Sunsama включает [дневной объём и shutdown](https://help.sunsama.com/docs/usage-guides/daily-planning/). Наше решение переносит эти принципы в небольшой детерминированный planner. + +**Конкретное решение:** обязательные ограничения имеют лексикографический приоритет над score полезности. Время отдыха, личные блоки, встречи, конец дня и уже принятый focus block — реальные planning objects. После их вычитания выбираются доступные действия; непомещающиеся получают `unassigned` с причиной и последствием. Deadline сам по себе не снимает ограничение вместимости. + +Начатое/подтверждённое действие закреплено до конца блока или команды пользователя. Новое обычное событие обновляет очередь, но не переключает фокус. За пределами закреплённого окна смена рекомендации требует выигрыша над explicit switching cost; сравнение причин хранится в decision. Критический override имеет отдельное принятое правило. + +Оценка длительности — диапазон с источником и наблюдаемой ошибкой; calibration по типам работ, не по foreground app time. План резервирует место на неопределённость; точный buffer выбирается в pilot policy. Reviewer debt включается как оставшиеся человеческие минуты, а не число готовых агентных файлов. + +**Приёмка BP-C, R1 основа / R4 расширение:** 10 несущественных событий не меняют закреплённый фокус; overload оставляет часть задач unassigned без нарушения границы дня; личный блок не вытесняется накопленными рабочими score. Длительности сравниваются с подтверждёнными исходами; unknown interval не записывается как нулевая работа. В UI виден путь «почему эта задача / почему сейчас / что перенесено». + +### D. P0 — возобновляемое исполнение и ранняя проверка готовой библиотеки + +**Что уже есть:** outbox, idempotency, lease fencing, retry, catch-up, code versions. **Недосмотр:** R2 фактически планирует свой небольшой workflow engine, но не задаёт историю шагов, ожидание review, правила code upgrade и ambiguous external outcome. Job lease не равен сохранению всего процесса. + +[DBOS workflows](https://docs.dbos.dev/typescript/tutorials/workflow-tutorial) сохраняют выполненные шаги; [steps](https://docs.dbos.dev/typescript/tutorials/step-tutorial) могут повторяться при сбое. [Версионирование workflow](https://docs.dbos.dev/typescript/tutorials/upgrading-workflows) требует отдельной дисциплины. [Temporal](https://docs.temporal.io/workflow-execution) — другой пример history/replay. Эти гарантии не означают однократный внешний эффект на произвольном сервисе. + +**Конкретное решение для порядка реализации:** до custom lease/checkpoint engine выполнить короткую техническую проверку DBOS на fixtures. Recommendation: TypeScript + PostgreSQL остаются, launchd отвечает за жизненный цикл процесса; library отвечает за workflow/queue. Проверяются local deployment, schema isolation, recovery, version upgrade, bounded concurrency, ожидание человека, traces и rollback. Пока эта проверка не пройдена, DBOS — кандидат, а не принятая новая зависимость. + +Интерфейс `WorkflowRuntime` фиксируется независимо от кандидата: start/get/cancel/resume, stage result, workflow/code/policy version, immutable packet reference. Domain tables остаются нашим контрактом. Состояние lease/step хранит один владелец, а `job_runs` проецирует наблюдаемый результат — без двух конкурирующих очередей. + +Для будущих внешних действий adapter хранит operation key, approval scope/version, provider receipt, verify query и результат succeeded/failed/unknown. После timeout с неизвестным эффектом выполняется reconciliation, а не слепой повтор. Отмена workflow не обещает отменить уже сделанную внешнюю запись. На replay LLM-результат читается из сохранённого шага; повторный inference — новая явно учтённая попытка. + +**Приёмка BP-D, R1 spike / R3 runtime:** остановка процесса между fetch/analysis/review/publish; restart и resume; истёкший worker; новая версия кода при старом pending run; revoke policy перед commit; provider timeout после возможного успеха. Результат — сохранённый verdict по каждому случаю. Установка библиотеки и новый scheduler здесь не выполнялись. + +### E. P0/P1 — проверка реальной пользы и жизненный цикл личной памяти + +**Что уже есть:** AC01–16, holdout, provenance, privacy classes, restore. **Недосмотр:** нет операционного eval-набора и отдельных метрик поиска/вывода/плана; хорошие цифры можно получить, оставив всё unknown. SC3 измеряет часть пользы, но почти не измеряет время обслуживания самой OS. Append-only история без forget contract конфликтует с управляемой личной памятью. + +[LongMemEval](https://github.com/xiaowu0162/LongMemEval) проверяет извлечение, несколько сессий, обновления знания, время и abstention. [Anthropic evals](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) разделяет итоговое состояние, траекторию и повторяемость; предлагает начинать с небольшого набора реальных случаев. Наши рабочие кейсы остаются основным holdout, публичный benchmark — дополнительной проверкой класса способности. + +**P0 eval design:** 30–50 фиксированных случаев до prompt tuning, отдельные development/holdout sets. Сюжеты: proposal→отмена, идентичные названия, косвенная связь, цепь сессий, неполный источник, отсутствующий ответ, overload, false urgency, удалённые данные. Записывать retrieval recall, precision/recall принятых claims, долю actionable случаев с полезным ответом, unknown rate, plan violations, число переключений/прерываний и reviewer minutes. Для критических nondeterministic cases — три повторных прогона и все результаты, без выбора удачного. Эти количества — предложенная стартовая конфигурация, не доказательство production-качества. + +Каждое исправление пользователя становится replay case с исходным input, ожидаемым поведением и scope коррекции. Ретро предлагает одну проверяемую гипотезу, сравнивает с фиксированным baseline и учитывает meeting load/coverage. Пять дней pilot дают предварительный продуктовый verdict, не причинное доказательство карьерного роста. Новая полезная метрика: ручные минуты на поиск контекста + обслуживание OS + ревью агентов в сравнении с baseline; не требовать длинного ежедневного отчёта. + +**P1 память и доступ:** [Screenpipe](https://github.com/screenpipe/screenpipe/blob/main/README.md) показывает фильтры по приложениям/типам/времени и enforcement вне prompt; [Mem0](https://docs.mem0.ai/core-concepts/memory-operations/delete) — явное удаление выбранной памяти. Наш контракт: `access_policy_version` проверяется до retrieval, при resume и delivery; «забыть» покрывает raw spans, summaries, embeddings, exports/cache и производные claims. Tombstone/source delete, истечение retention и явное erase — разные события. Историческая публикация после erase показывает redacted/missing evidence, а не восстанавливает удалённый текст. + +Для backups нужен срок хранения и журнал erase, применяемый при restore до открытия API; UI раскрывает, какие offline/exported копии нельзя отозвать автоматически. Append-only сохраняет историю решений, но допускает санкционированное удаление содержимого; физическое удаление выполняется только после отдельного подтверждения. Текущая работа ничего не удаляет. + +**Приёмка BP-E:** balanced replay не проходит со стратегией «всё unknown»; запрещённый record отсутствует уже в retrieved packet. Erase test проверяет поиск, summary, граф, кеш и restore; содержимое не возникает снова. Сохранённый evidence без разрешения на чтение не считается открываемым доказательством для данного consumer. + +## 3. Что в R2 уже соответствует практикам + +| Сильная сторона плана | Что сохраняем | +|---|---| +| Evidence и время | Source spans, valid/system time, lineage, late events, конфликт вместо ложной уверенности. | +| Границы системы | Один PostgreSQL truth store, клиенты как проекции, роли без обязательных микросервисов, инструменты ограничены runner-ом. | +| Явные статусы | Proposal, decision, implementation, merge, release и impact раздельны; closed task не доказывает внедрение. | +| Контроль внимания | Scoped feedback, delivery gates, ручные цели/энергия, reviewer budget, защищённая граница дня. | +| Последовательность | Первый Mac-срез и iPad отдельно; измеримая приёмка, shadow, restore и rollback. | + +Оценка «заложено в плане» не означает «работает». Переход на Neo4j, векторную БД, n8n или полную Swift-перепись не исправляет BP-A–E автоматически. Заимствуем проверяемое поведение; новую зависимость выбираем по нашему fixture и эксплуатационной цене. + +## 4. Конкретный diff roadmap для согласования + +| Этап R2-плана | Уточнённый результат | +|---|---| +| R0 | Принять BP-A–E как дополнение к контрактам; отдельно зафиксировать budget/review/data retention. | +| R1 | Вертикальный срез остаётся первым; добавить policy стабильного фокуса, overload/unassigned, minimum replay fixtures и bounded DBOS compatibility spike до собственного workflow engine. | +| R2 | К графу добавить context assembler, summary invalidation, permission-aware retrieval, модель целей/личных блоков и erase design до накопления большого архива. | +| R3 | К runner/prompts добавить durable review_requests, поэтапное принятие классов, retrieval+semantic eval и saved step results. | +| R4 | Закрыть BP-C/E: стабильность плана, суммарная человеческая нагрузка, counterexample replay, memory erase/restore и bounded change experiments. | + +Для первого end-to-end eval берём уже известную цепочку Core Data: предложение → отмена → обновление project state → карьерный вклад без ложного implementation → agenda advisor. Она должна работать после нового transcript, backfill, restart и пользовательской коррекции. Затем добавляется незнакомый проект, чтобы результат не зависел от вручную заданных IDs. + +**Следующее действие реализации после принятия уточнения:** создать этот воспроизводимый fixture и прогнать через минимальный context assembler; до расширения числа агентов измерить, находится ли отмена и получается ли корректный итог. diff --git a/personal/projects/personal-os/personal-os-system-review-index.md b/personal/projects/personal-os/personal-os-system-review-index.md index 79a39ae1..93e1c4ed 100755 --- a/personal/projects/personal-os/personal-os-system-review-index.md +++ b/personal/projects/personal-os/personal-os-system-review-index.md @@ -20,3 +20,7 @@ updated: 2026-10-04 Канонические источники — [пакет в репозитории](/Users/admin/Developer/personal-os/planning/system-review-2026-10-04/README.md). Копии Obsidian и PDF опубликованы в редакции R2. Исторические очереди P0 и Swift-перепись заменены этапами R0–R4; история сохранена с явной отметкой. Пометки: лист / объект / R / AC / SC. Начать просмотр с A3 02, затем 08 и 07; приёмка — A4 18–20. + +## Внешнее сравнение после R2 + +[[personal-os-best-practices-2026-10-04]] — изученные официальные документы и GitHub, пять конкретных уточнений архитектуры, проверки и diff roadmap. Предложение после R2; напечатанные PDF остаются R2. Зависимости, агенты и расписания не включались.