Tesserae → контекстный движок — поэтапная дорожная карта

<!-- translations:start -->

English · 한국어 · 中文 · 日本語 · Русский · Español · Français · Deutsch

<!-- translations:end --> Производная от MD0. Превращает порядок построения из 7 шагов в последовательные фазы с зависимостями, конкретным охватом и критериями приёмки.

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

Статус на v0.5.0 (2026-06-06): Фазы 0–6 поставлены. Спина движка (P0 оркестратор конвейера, P1 супервизор-демон, P2 живой монитор сессий) находится в tesserae/engine/; инфраструктура инкрементной компиляции P3 приземлилась, но остаётся с флагом OFF/экспериментальной; P4 самосовершенствование персистентно через сайдкар node_memory (числовая уверенность повторяемости, supersede включён по умолчанию); P5 настоящие эмбеддинги по умолчанию поставлены (Трек B); а P6 — контекстный компилятор по запросу — это флагманская функция v0.5.0. Фаза 7 (объединение serve + watch + deploy + тесты жизненного цикла) остаётся открытой. Статус по фазам отмечен ниже по тексту. См. примечания к выпуску v0.5.0.

Форма зависимостей

P0 Оркестратор конвейера (извлечь цепочку refresh в код)
        │
P1 Супервизор-демон (цикл) ────────────────────┐
        │                                      │
   ┌────┴─────────────── Трек A ───────┐   ┌── Трек B (параллелизуемый) ──┐
   P2 Живой монитор сессий             │   P5 Настоящие эмбеддинги по умолч.
   P3 Инкрементная/потоковая компиляция│   P6 Контекстный компилятор по запросу
   P4 Персистентность самосовершенств. ┘   (P6 зависит от P5)
        │                                      │
        └──────────────► P7 Объединение serve+watch+deploy ◄──┘

Трек A (реальновременное поглощение) и Трек B (вывод для агентов) могут идти параллельно, как только приземлится P1. P7 их сводит.

Фаза 0 — Оркестратор конвейера (фундамент снижения рисков) ✅ Поставлено в v0.5.0

Поставлено в v0.5.0 — tesserae/engine/pipeline.py (спина движка, слито в фазах 1–3).

Цель: Вынести конвейер refresh из markdown слэш-команды в первоклассный внутрипроцессный оркестратор, который вызывают и демон, и CLI, и MCP.

• Почему сейчас: Каждая последующая фаза нуждается в одном общем кодовом пути для ingest → compile → project → publish. Сегодня эта последовательность существует только как проза в навыке. Ничто иное нельзя автоматизировать, пока она не станет вызываемой.
• Охват: Новый tesserae/engine/pipeline.py (объект Pipeline, оборачивающий текущую цепочку sessions discover --import → compile → obsidian-sync). Маршрутизировать подкоманды cli.py через него. Начать декомпозицию диспетчера-бога project_main на ~2000 строк в таблицу команд (механически, без изменения поведения).
• Поставки: Pipeline.run(steps, changed_only=…); CLI делегирует ему; юнит-тесты на упорядочивание шагов + распространение сбоев.
• Приёмка: tesserae refresh существует как код (не навык) и побайтово воспроизводит markdown-цепочку на демо-корпусе.
• Риск: Низкий. Чистый рефакторинг; существующие тесты охраняют поведение.
• Закрываемые находки аудита: «refresh живёт в навыке», «cli диспетчер-бог».

Фаза 1 — Супервизор-демон (цикл движка) ✅ Поставлено в v0.5.0

Поставлено в v0.5.0 — tesserae/engine/daemon.py (спина движка, фазы 1–3).

Цель: Управляемый долгоживущий процесс, владеющий одним циклом событий и управляющий Pipeline по триггерам, с настоящей обработкой жизненного цикла.

• Почему сейчас: Это хребет. Самая большая единственная брешь аудита. Всё «непрерывное/автономное» висит на нём.
• Охват: Новый tesserae/engine/daemon.py — цикл событий, очередь триггеров, дебаунс/коалесцирование, изящное завершение по SIGTERM/SIGINT, pidfile, структурированное логирование. Точка входа CLI tesserae engine / tesserae daemon. Заменить голую смерть KeyboardInterrupt в watch.py/vault_watch.py, сложив их как источники триггеров, питающие очередь.
• Поставки: Демон, работающий бесконечно, коалесцирующий всплески в один прогон конвейера, чисто завершающийся; пример unit-файла launchd/systemd.
• Приёмка: Правка исходного файла → демон коалесцирует и запускает один compile(changed_only) в окне дебаунса; SIGTERM выходит с 0 без потоков- сирот; переживает исключение конвейера, не умирая.
• Риск: Средний — корректность параллелизма/завершения. Смягчить однопоточным ядром asyncio + явным надзором за задачами.
• Закрываемые находки аудита: «нет демона», «непрерывность = sleep-поллер», смерть наблюдателя по KeyboardInterrupt, нет обработки сигналов.

Фаза 2 — Живой монитор сессий (Столп 1) ✅ Поставлено в v0.5.0

Поставлено в v0.5.0 — tesserae/engine/session_tail.py (спина движка, фазы 1–3).

Цель: Тейлить живые транскрипты харнеса и поглощать ходы по мере выполнения сессий, заменяя постфактумный sessions discover --import.

• Почему сейчас: Нужен цикл P1 для питания. Доставляет столп «мониторинг сессий».
• Охват: Новый источник триггеров тейла сессий (наблюдать за событиями дозаписи JSONL ~/.claude / ~/.codex) → ставить в очередь. Инкрементное извлечение на уровне хода в session_graph*.py, чтобы новый ход не инвалидировал кэш всей сессии. Индексированное/дописываемое хранилище для harness_sessions (списать glob с полным пересканированием).
• Поставки: Демон поглощает ходы сессии в течение секунд после их записи; test_session_tailer.py.
• Приёмка: Запуск живой сессии агента в наблюдаемом проекте → новые находки появляются в графе без всякой ручной команды; измеренная доля попаданий в кэш на уровне хода > переизвлечение всей сессии.
• Риск: Средний — форматы JSONL различаются между харнесами; чтение неполных строк.
• Закрываемые находки аудита: постфактумное сканирование сессий, инвалидация кэша всей сессии, плоское glob-хранилище.

Фаза 3 — Инкрементная/потоковая компиляция через порт GraphStore ⚙️ Инфраструктура поставлена в v0.5.0 (флаг OFF/экспериментальный)

Инфраструктура поставлена в v0.5.0 (сайдкар происхождения, поверхность удаления GraphStore, персистентный async-рантайм url_resolver), но флаг incremental_compile остаётся OFF/экспериментальным из-за пробелов мульти-владельца/жизненного цикла продюсера/cap-fallback. Байтовая эквивалентность для покрытых путей доказана. v0.5.0 также исправил две реальные ошибки компиляции, найденные здесь: идемпотентность changed-only и контракт внедрённого хранилища.

Цель: Заменить хрупкий патч выселения графа changed_only спроектированным инкрементным слоем, текущим через ports/graph_store.py.

• Почему сейчас: Непрерывное поглощение (P2) делает текущий обходной путь reload-strip-evict-merge обязательством корректности (задокументированная ловушка «2400→1700 узлов»). Самосовершенствование (P4) нуждается в poузловых upsert.
• Охват: Сделать так, чтобы самостоятельный конвейер тёк через GraphStore (сегодня он обходит порты прямо к JSON). Поузловой upsert/delete с происхождением + временными метками свежести. Сводить персистентность к одному источнику истины (аудит: JSON-артефакт vs SQLite vs Kuzu). Исправить asyncio.run-на-вызов в url_resolver.py (постоянная async-среда).
• Поставки: Инкрементная компиляция, корректно добавляющая/обновляющая/ удаляющая только изменённые узлы; поузловые first_seen_at/last_updated_at.
• Приёмка: Правка 21 файла обновляет ровно затронутые узлы (без коллапса); побайтово идентичный паритет полной компиляции сохранён как золотой тест.
• Риск: Высокий — затрагивает ядро модели данных. Закрыть за фича-флагом; диффить против вывода полной компиляции до доверия.
• Закрываемые находки аудита: хрупкий changed_only, обход портов, asyncio-на-вызов, три формата персистентности, нет поузловой свежести.

Фаза 4 — Активация и персистентность самосовершенствования (Столп: самосовершенствование) ✅ Поставлено в v0.5.0

Поставлено в v0.5.0 через сайдкар node_memory (tesserae/memory/): включённый по умолчанию supersede с детерминированным вердиктом и подавлением ниже по потоку, а также числовая уверенность повторяемости, отображаемая в выводе (частота между сессиями → TemporalFactProjector).

Цель: Сделать так, чтобы база знаний действительно эволюционировала на месте, по умолчанию включённой, персистируемой во время компиляции.

• Почему сейчас: Зависит от поузловых upsert P3. Закрывает самый непротестированный срез.
• Охват: Персистить оценки затухания при компиляции (memory/decay.py больше не только во время запроса); инкрементировать access_count/last_accessed_at при чтениях MCP. Supersede, включённый по умолчанию с нисходящим подавлением устаревшего контента (не просто дозапись рёбер). Добавить разрешение противоречий (повысить детекцию lint.py до прохода с арбитражем уверенности). Усиление повторяющихся инсайтов (межсессионная частота → числовая уверенность). Подключить путь применения дрейфа схемы и руководство обратной связи в извлечение (детерминированный путь сейчас его игнорирует). Генерация кандидатов supersede на основе эмбеддингов (списать лексический Жаккар).
• Поставки: Каждый проход работает в конвейере по умолчанию и записывает обратно; новый набор tests/, покрывающий decay/supersede/feedback/drift/contradiction.
• Приёмка: Повторное утверждение факта между сессиями поднимает его уверенность; замещённый факт перестаёт появляться в выводе контекста; оценки затухания персистируют и сдвигаются между прогонами; набор самосовершенствования зелёный (сейчас ноль тестов).
• Риск: Средний — изменения поведения вывода извлечения; охранять золотыми фикстурами.
• Закрываемые находки аудита: вся таблица Столпа 2.

Фаза 5 — Настоящие эмбеддинги по умолчанию (фундамент Трека B) ✅ Поставлено в v0.5.0

Поставлено в v0.5.0 (Трек B): настоящий по умолчанию Model2VecBackend, громко падающий active_embedding_backend (без тихого даунгрейда до blake2b), флаг семантического бэкенда в embedding_status и косинусный порог, позволяющий лейну эмбеддингов допускать кандидатов.

Цель: Перестать отгружать детерминированное псевдо-эмбеддинг хеш-бакетами как лейн «семантики» по умолчанию.

• Почему сейчас: Контекстный компилятор P6 хорош лишь настолько, насколько хороша выборка. Независим от демона — можно начать, как только приземлится P0.
• Охват: Отгрузить настоящий бэкенд эмбеддингов по умолчанию (или сделать так, чтобы auto громко падал вместо тихого понижения до blake2b в retrieval/hybrid.py). Позволить лейну эмбеддингов генерировать кандидатов (а не только переранжировать), когда эмбеддинги станут настоящими.
• Поставки: Установка по умолчанию даёт настоящую семантическую выборку или явное, видимое предупреждение «работаю на хеш-заглушке».
• Приёмка: Перефразированные/синонимичные запросы выводят релевантные узлы, которые BM25 упускает; качество выборки измерено на малом размеченном наборе против хеш-базлайна.
• Риск: Средний — вес зависимостей / офлайн-установка. Предложить многоуровневое значение по умолчанию.
• Закрываемые находки аудита: хеш-бакет по умолчанию, ворота кандидатов лейна эмбеддингов.

Фаза 6 — Контекстный компилятор по запросу (Столп 3) ✅ Поставлено в v0.5.0 (флагманская функция)

Поставлено в v0.5.0 как флагманская функция. Чистый конвейер compile_context в tesserae/context_compiler.py возвращает in-memory ContextBundle из ContextCitation (запрос/сиды → PPR + гибридный поиск → ограниченная по глубине k-hop окрестность → сборка тел вики → опциональный LLM-синтез с мягким фолбэком → контроль бюджета). Доступно как MCP-инструмент compile_context и CLI-подкоманда tesserae context; у node_context появился ранжированный путь use_ppr; поставляются тематические срезы экспорта llms.txt.

Цель: Флагманская фича — «дай мне контекст по X» → подогнанный, цитируемый, готовый для агента документ.

• Почему сейчас: Зависит от P5 (качество выборки). Выигрывает от P4 (более чистая база). Ключевое ценностное предложение продукта.
• Охват: Новый tesserae/context_compiler.py: запрос/семена → PPR + гибридный поиск → ранжированный обход k-переходной окрестности → сборка тел wiki → опциональный LLM-синтез → один ограниченный markdown-документ с цитатами + контролем бюджета. Выставить как MCP compile_context(query|seeds, depth, budget) и CLI tesserae context …. Сделать agent_harness ограниченным по теме; маршрутизировать node_context через PPR; ограниченные по теме срезы экспорта llms.txt.
• Поставки: Инструмент, возвращающий загружаемый, цитируемый контекстный пакет для любого запроса; тесты, утверждающие форму пакета + целостность цитат.
• Приёмка: compile_context("X") возвращает связный многоузловой документ, все цитаты которого разрешаются; брифинг харнеса перегенерируется по теме, а не жёстко зашитыми топ-12.
• Риск: Средний — качество синтеза; сохранять детерминированный режим сборки без LLM.
• Закрываемые находки аудита: «генерация документов по запросу не существует», синтез с охватом по запросу, статический харнес, неранжированный node_context, экспорты всего корпуса.

Фаза 7 — Объединение serve + watch + deploy + тесты жизненного цикла ⏳ Открыто (после v0.5.0)

Открыто на момент v0.5.0. Фаза сведения остаётся следующей вехой; демон (P1) и сторона вывода (P6), которые она объединяет, теперь оба на месте.

Цель: Один управляемый процесс обслуживает сайт, перекомпилирует при изменении и непрерывно публикует; слой жизненного цикла получает покрытие тестами.

• Почему сейчас: Конвергенция. Нужны P1 (демон) и сторона вывода (P6), чтобы стоило непрерывно публиковать.
• Охват: Сложить serve.py (блокирующий TCPServer) и deploy.py (ручной git push) в демон, чтобы serve + watch + publish делили один супервизор. Непрерывная/дебаунсированная публикация. Добавить отсутствующие тесты test_watch/test_serve/жизненного цикла демона. Удалить устаревший мёртвый модуль frontend.py. Подключить строково-типизированный TODO-цикл review_workflow.py к реальному пути применения.
• Поставки: tesserae engine --serve --publish гоняет полный цикл; набор тестов жизненного цикла; мёртвый код удалён.
• Приёмка: Правка исходника распространяется на живо-обслуживаемую страницу и (опционально) опубликованный деплой без ручных команд; тесты жизненного цикла зелёные.
• Риск: Низкий–средний — в основном интеграция.
• Закрываемые находки аудита: разделение serve/watch/deploy, ручной deploy, устаревший frontend.py, заглушка цикла обзора, отсутствующие тесты жизненного цикла.

Сводка по упорядочиванию

Минимально жизнеспособный движок: P0 + P1 + P2 + P3 — работающий демон, который наблюдает за живыми сессиями и инкрементно компилирует. Дифференцированный продукт: добавить P5 + P6 (контекст для агентов по запросу). Отполированный: P4 + P7.