Разбор корпуса закладок: что взять из чужой обвязки

Дата: 2026-08-11 · Решение: #237 · Заметка исследования, не контракт.

Владелец три года складывал в Sortula ссылки по AI-обвязке. Здесь разобрано, что из накопленного является настоящим пробелом TAUSIK, а что — пересказом чужого README. Заметка нужна, чтобы следующий читатель не разбирал корпус заново и, главное, не завёл повторно то, что здесь уже отвергнуто.

Что разбиралось

284 записи из категорий AI/ML (194), программирование, кибербезопасность, DevOps, базы данных, полезные сервисы. Пользовательских комментариев в корпусе нет ни одного — сигналом служит не аннотация, а то, вокруг чего владелец ходит кругами. Частоты тегов: llm 70, инструменты 40, автоматизация 31, ai агенты 31, claude code 19, mcp 19, rag 9.

Корпус нарезан по ключевым словам на пять срезов и роздан трём агентам. Нарезка оказалась неверной: главные источники — Agent Plugins, loopx, ECC — попали не в те файлы. Агенты это обнаружили и пошли в первоисточники: читали спецификацию целиком, changelog протокола, README через API. Ошибка нарезки случайно дала результат лучше задуманного, и отсюда правило на будущее: разбирать чужое решение по спецификации и коду, а не по LLM-сводке о нём.

Ландшафт: три лагеря, одна общая дыра

Лагерь	Кто	Чего нет
Дистрибуция контента	сотни тысяч звёзд, десятки скиллов и агентов	криптографии, провенанса, гейтов
Управление длинным циклом	квоты, auto-wake, handoff, вопрос владельцу	верификации; evidence = журнал
Верификация	TAUSIK практически один	драйвера цикла

Все три лагеря упираются в одну недостающую деталь — петлю «история → поведение». У TAUSIK для неё лучшее сырьё в классе (1208 закрытий с исходом плюс 22 хука, видящих каждый вызов) и худшая реализация: никакой.

Замечание о честности. В ходе разбора была взята назад формулировка «1208 задач — это протокол траекторий агента». Это не траектории: пошаговых state → action → observation у нас нет, а 1208 примеров от одного человека на одном проекте — на три порядка меньше масштаба, при котором такие данные чему-то учат. Актив реален в другом качестве: это outcome-размеченный корпус для тюнинга обвязки, а не модели.

Что проверено кодом, а не принято на веру

Проверка своего кода оказалась продуктивнее чтения чужого. Каждая строка ниже — основание для заведённой задачи:

• .mcp.json везёт ${CLAUDE_PROJECT_DIR:-.} в command; Agent Plugins это запрещает, разрешая ${PLUGIN_ROOT} только в args/env/cwd.
• tests/test_mcp_integration.py:119 пинит protocolVersion: "2024-11-05".
• knowledge_write.py в докстринге сам трекает export-of-the-shared-store-must-scrub-or-stay-local — это наш долг, а не находка снаружи, и он блокирует S3-бэкап.
• tool_output_truncation_nudge.py называет себя в докстринге coaching signal, not a censor: про раздутый вывод мы говорим, но ничего не делаем.
• Дедупа повторных чтений нет ни в одном из 22 хуков.
• eval_memory_retrieval.py честный — закоммиченный вопросный набор, top-K, попадание по началу токена, — но даёт одно бинарное число без recall@k.
• find_dedupe_candidates уже существует: детектор противоречий — его вариант с другим предикатом, а не новый механизм.
• skill_spec_conformance.py валидирует канон agentskills.io — тот самый, на который прямо ссылается §7.1 спецификации Agent Plugins.

Ключевые выводы по чужим решениям

Agent Plugins — не конкурент. Первая редакция спецификации — только формат пакета: подписей нет, целостности нет, дистрибуции нет, containment прямо не песочница, авторизация оставлена клиенту. Всё, чем ценна наша цепочка, стандарт явно отдаёт клиентам. Мы — этаж над ним, а не рядом с ним.

MCP 2026-07-28 сегодня ничего не ломает, обратная совместимость встроена в ревизию. Но tools/list становится кэшируемым (ttlMs, cacheScope), а мы меняем состав списка под scope активной задачи — клиент покажет поверхность, которой уже нет, и покажет молча.

A2A пересечений не даёт. Их Task — единица обмена между агентами, наш — единица дисциплины внутри одного. Совпадение имён, не понятий. Заимствовать нечего; задача не заводится до появления внешнего потребителя.

Обоснование «база не покидает машину» подорвано тремя сценариями из среза безопасности: стилер, целящийся в машины разработчиков; общий аккаунт команды на VPS; побег из гостевой VM. Отказ от скраббера обоснован и остаётся, но отказ от скраббера ≠ отказ от детектора.

Что отвергнуто и почему

Отвергать так же полезно, как заводить. Ниже — чтобы не заводили повторно.

Отвергнуто	Причина
Готовые системы памяти с эмбеддингами и облачной синхронизацией	Против двух принятых решений: эмбеддинги отвергнуты в пользу FTS5-гибрида, бэкап не покидает машину
Обмен знаниями между агентами	Уже есть: cq_publish / cq_query
Markdown-граф знаний в репозитории	Уже есть: проекция tausik/ + sync
Циклы «план → применение → сверка» против деградации контекста	Уже есть: жизненный цикл задачи + чекпоинты
Поиск по коду для агентов	Уже есть: codebase-rag на FTS5-гибриде
Методологии «спека до кода»	Уже есть: QG-0 + spec_* + скиллы. Полезны как подтверждение курса
Мультиагентная оркестрация	TAUSIK сознательно однопользовательский; примитивы claim/lease уже есть. Вопрос уровня 2.0
Рантаймы, модели, прокси, агрегаторы API	Мы слой НАД рантаймами; кросс-IDE это уже покрывает
Замена SQLite на FST	Наш корпус не статичен — приём не применим
Догонять по числу скиллов	Бессмысленно: у лидера их сотни при нулевой криптографии. Наша ниша противоположна

Куда это легло

• 1.9 (тема «работает у чужих») — четыре задачи только по теме тихой деградации у пользователя.
• 1.10 release-110-proof-outward — семь задач: доказать наружу то, что сегодня держится на слове.
• Исследования research-with-a-death-date — четыре гипотезы, у каждой порог провала объявлен до работы. Причина строгости: модель риска закрытия была опровергнута бэктестом (AUC 0.4820) уже после вложенного релиза. Второй такой заход недопустим.

Побочный результат, важнее части находок

Планировать по строке Calibration в status нельзя: она считается на окне n=10 и за один день 11 августа показала и «calibrated 1.06», и «overestimating 0.63». Планировать надо по блоку Per-tier в metrics: на 502 закрытиях actual/budget = 0.63, и чем крупнее задача, тем сильнее переоценка (substantial 0.49, deep 0.33). Ловушка в том, что волатильная строка стоит на видном месте, а надёжный агрегат спрятан. Записано конвенцией #384.

Смотрите также

• Решение #235 — заимствование у внешней реализации SENAR и правило атрибуции.
• Решение #237 — развод 1.9 и 1.10.
• Конвенция #384 — планирование по агрегату.