Блог о context engineering, структуризации информации для LLM и AI-разработкеhttps://ctxt.dev/https://ctxt.dev/posts/ru/ai-agents-need-permission-boundaries/https://ctxt.dev/posts/ru/ai-agents-need-permission-boundaries/Большинство agent runtimes добавляют роли. punk исходит из другой идеи: доверие строится на boundaries, durable state и proof.Wed, 08 Apr 2026 00:00:00 GMT## Проблема Большинство agent tools путают orchestration с reliability. Они добавляют новые роли, новых агентов, новые coordinator surfaces и больше shell theater. Демо выглядит убедительнее. Саму систему доверять легче не становится. Пока основную часть работы писал человек, это было терпимо. Оператор всё ещё держал реальную модель задачи в голове, мог восстановить intent по diff и докомпенсировать слабый процесс собственным judgment. Но как только генерация кода стала дешёвой, быстрой и постоянной, эта страховка перестала масштабироваться. Теперь bottleneck - не generation. Bottleneck - trust. Именно поэтому самые интересные agent runtimes сегодня - не те, у которых больше personalities. Интересны те, которые делают planning, execution и verification разными типами authority. В этом и состоит ставка [specpunk](https://github.com/heurema/specpunk), который сейчас переформатируется в `punk`. Проект прямо говорит, что это design reset, а не полировка уже запущенного продукта. Он собирается заново вокруг более жёсткой формы: one CLI, one vocabulary, one runtime и три canonical modes - `plot`, `cut`, `gate`. И это важно потому, что эти modes - не style presets. Это permission boundaries. ## Контекст У многих agent systems базовая интуиция до сих пор одна и та же: лучшее software delivery получится, если добавить больше orchestration surfaces. Обычно схема выглядит знакомо: - один агент планирует - второй имплементирует - третий ревьюит - shell координирует - chat transcript становится историей работы Такой pipeline действительно может производить полезный output. Но он так же легко производит confidence theater. Coordination - не то же самое, что ground truth. Если runtime не может ответить на четыре простых вопроса, это ещё не trust system: 1. Что именно было approved? 2. Что реально запускалось? 3. Какое состояние authoritative сейчас? 4. Какой proof существует для финального decision? Количество агентов не отвечает на эти вопросы. Количество ролей тоже. Формально красивый shell - тоже нет. В лучшем случае эти вещи улучшают throughput и ergonomics. В худшем - просто умножают ambiguity. В этом и ловушка. Agent runtime оптимизирует видимую активность, а не enforceable structure. Если убрать theater, то trustworthy agent work требует более простого набора примитивов, чем обычно показывают такие инструменты: - approved intent - bounded execution - durable work state - clear decision surface - proof-bearing artifacts Этот список важнее любого model roster. Агент может быть очень сильным и при этом совершенно ненадёжным, если ему разрешено планировать, менять код и валидировать собственный результат внутри одной размытой поверхности. Проблема тут не только в bad code. Проблема в unfalsifiable process. Человек-оператор не должен восстанавливать truth по prompts, shell chatter и commit residue. У runtime уже должен быть на это явный ответ. Именно здесь `punk` стартует с более сильной идеи, чем многие agent systems: > Важнее shape of the runtime, чем число агентов внутри него. ## Решение `specpunk` интересен не потому, что координирует каких-то особенных агентов. Он интересен тем, что пытается зафиксировать правильную форму runtime. В docs у проекта есть canonical object chain: ```text Project -> Goal -> Feature -> Contract -> Task -> Run -> Receipt -> DecisionObject -> Proofpack ``` Это уже совершенно другой product claim, чем "мы управляем для вас swarm of coding agents". Центр системы здесь не агент. Центр - artifact chain. Такой выбор сразу меняет архитектурные последствия. Runtime пытается сохранить continuity между попытками, retries, verification steps и дальнейшей inspectability. `Feature` переживает одну implementation pass. `Contract` явный. `Run` - это одна конкретная попытка. `DecisionObject` пишет только `gate`. `Proofpack` становится финальным audit bundle. Это architecture for reliability, а не architecture for chat. Самая сильная идея текущего `punk` design - это split между двумя слоями: - correctness substrate - operator shell Substrate владеет durable truth: - project identity - goal intake - contract - scope - workspace isolation - run state - decision objects - proof artifacts - ledger Shell владеет ergonomics: - `punk init` - `punk start` - `punk go --fallback-staged` - summaries - blocked / recovery UX - generated repo-local guidance На словах это кажется очевидным, но большинство agent systems начинают размывать эту границу почти сразу. Shell постепенно превращается в скрытый policy engine. Safety semantics утекают в prompts. Формат ответа начинает притворяться state. В итоге уже невозможно понять, какое поведение реально enforced by the runtime, а какое просто предлагается интерфейсом. `punk` пытается остановить этот drift заранее. Правило в architecture docs простое и важное: shell может композиционно собирать substrate operations, но не имеет права становиться second source of truth. Именно такие правила удерживают инструмент честным по мере роста. ### `plot`, `cut`, `gate` как реальные boundaries Три canonical modes легко неправильно прочитать, если привык к agent UIs. `plot`, `cut` и `gate` нужны не для того, чтобы система выглядела cinematic. Они разделяют authority. - `plot` shape'ит work, inspect'ит repo, draft/refine'ит contracts - `cut` выполняет bounded changes в isolated VCS context - `gate` проверяет result, пишет final decision и выпускает proof Docs прямо говорят: это hard permission boundaries, а не tone presets. Это серьёзный architectural choice. Очень многие agent failures появляются как раз тогда, когда planning, mutation и self-verification сливаются в один conversation loop. Одна и та же поверхность интерпретирует intent, меняет код, судит собственный результат и рассказывает историю успеха. Даже если финальный ответ звучит аккуратно, trust boundary там слабая, потому что authority merged at runtime level. `punk` движется в обратную сторону. Только `gate` пишет final `DecisionObject`. Только approved contracts должны попадать в `cut`. Event log и derived views хранят runtime truth, а не shell summary. Вот как выглядят permission boundaries на практике: не "agent A planner, agent B reviewer", а реальные boundaries authority и ownership artifacts. ### Durable work state важнее, чем chat history Ещё одна сильная линия в дизайне - work ledger. Большинство agent sessions оставляют после себя плохую форму памяти: - shell logs - chat transcripts - commits - иногда branch name - иногда PR Этого хватает ровно до первого block, failure, supersession или handoff. После этого все задают одни и те же вопросы: какой contract активен, какой был последний run, verification blocked or escalated, и что делать дальше? Если единственный ответ - "почитай последние экраны терминала", runtime слабый. `punk` толкает систему к `WorkLedgerView`, который должен отвечать на эти вопросы напрямую. Это правильное направление. Agents действительно нужен контекст, чтобы действовать. Но операторам нужен durable work state, чтобы работу продолжать. И здесь снова повторяется тот же паттерн: inference заменяется explicit structure. ## Инсайт Важно не перепутать этот тезис с отказом от ergonomics. В `punk` docs есть ещё одна сильная идея: one-face operator shell. Нормальный пользователь должен уметь дать plain goal и получить в ответ один concise progress or blocker summary плюс один obvious next step. Это хороший UX. Но ценность такого shell определяется тем, что находится под ним. Чистый shell полезен только тогда, когда underneath already exists a substrate that knows what is authoritative. Иначе one-face UX превращается в просто более красивый способ скрыть ambiguity. Поэтому split между substrate и shell так важен. `punk` не отвергает ergonomics. Он не позволяет ergonomics притворяться truth. Самое интересное в `punk` - не то, что он когда-нибудь сможет orchestration multiple models, councils или skill improvement through eval loops. Интересен порядок операций. До любых higher-level features проект сначала пытается зафиксировать runtime shape: - one vocabulary - explicit artifact chain - bounded modes - durable state - proof before acceptance Это правильный порядок. Если shape выбран неверно, все последующие фичи унаследуют ambiguity. Councils превратятся в opinion aggregators вместо structured advisory mechanisms. Skills станут prompt folklore вместо evidence-backed overlays. Shell UX станет theater вместо control. Если же shape выбран правильно, у всех следующих слоёв появляется что-то твёрдое, к чему можно attach'иться. Именно поэтому за `punk` интересно следить уже сейчас, даже в стадии rebuild. Проект делает architectural claim, который стоило бы делать явно куда большему числу agent tools: > Надёжность приходит не от новых agent personalities. Она приходит от чётких > boundaries между intent, execution, verification и proof. Больше агентов не создаёт ground truth. Больше ролей не создаёт safety. Если planning, execution и verification не разделены hard boundaries, runtime масштабирует не trust, а ambiguity. В этом и состоит настоящий смысл этого design reset. ## Источники - [specpunk on GitHub](https://github.com/heurema/specpunk) - [punk Vision](https://github.com/heurema/specpunk/blob/main/docs/product/VISION.md) - [punk Architecture](https://github.com/heurema/specpunk/blob/main/docs/product/ARCHITECTURE.md) - [punk CLI](https://github.com/heurema/specpunk/blob/main/docs/product/CLI.md) - [Specpunk Identity and Layering](https://github.com/heurema/specpunk/blob/main/docs/research/2026-04-03-specpunk-identity-and-layering.md) - [Specpunk One-Face Operator Shell](https://github.com/heurema/specpunk/blob/main/docs/research/2026-04-03-specpunk-one-face-operator-shell.md) - [Specpunk Work Ledger](https://github.com/heurema/specpunk/blob/main/docs/research/2026-04-03-specpunk-work-ledger.md)https://ctxt.dev/posts/ru/signum-leanstral-improvements/https://ctxt.dev/posts/ru/signum-leanstral-improvements/Изучение Leanstral от Mistral -- агента для доказательства теорем на Lean 4 -- привело к конкретным улучшениям Signum, пайплайна мультимодельного код-ревью.Tue, 17 Mar 2026 00:00:00 GMTУтренний дайджест принёс [Leanstral](https://mistral.ai/news/leanstral) -- open-source агент от Mistral для формальной верификации на Lean 4. Mixture-of-experts модель (119B параметров, 6.5B активных на токен), которая на бенчмарке FLTEval для доказательства теорем набирает 80% от Claude Opus при доле его стоимости. Lean 4 мне не нужен. Но архитектура агента оказалась полезной: параллельный поиск доказательств, структурированная обратная связь, верификация как отдельный шаг. Три паттерна хорошо перенеслись на мой пайплайн кодового аудита. Ещё три улучшения родились в той же дизайн-сессии. **Что такое Signum.** [Signum](https://github.com/heurema/signum) -- плагин для Claude Code, который превращает запросы на фичи в верифицируемые артефакты. Четыре фазы: Contractor пишет контракт (спецификация + критерии приёмки), Engineer реализует, три независимые AI-модели проводят аудит (Claude -- семантика, Codex -- безопасность, Gemini -- производительность), Synthesizer выносит вердикт. Пайплайн итеративный: если аудит находит проблемы, Engineer получает repair brief и пробует снова. Результат -- proofpack: self-contained пакет с контрактом, диффом, находками ревью и решением. ## Три паттерна из Leanstral Leanstral работает через [MCP-сервер](https://github.com/oOo0oOo/lean-lsp-mcp), который подключает агента к Language Server Protocol Lean 4. Пять фаз -- найти пробелы в доказательстве, извлечь подцели, найти леммы в библиотеке, подставить тактику, проверить диагностику -- структурированный цикл generate-verify. Три элемента легли на Signum: **1. Верификация до ревью.** Lean проверяет не "компилируется ли доказательство", а "проходит ли оно type-check под ядром". В Signum аналог -- policy scanner: детерминистический grep на дифф, который запускается *до* LLM-ревьюеров, ловя security и unsafe паттерны при нулевой стоимости токенов. **2. Параллельные попытки.** Lean-тул `multi_attempt` подставляет несколько тактик на одну позицию и сравнивает результирующие goal states. В Signum -- параллельные repair lanes: два Engineer-агента в изолированных git worktrees с разными стратегиями фикса. **3. Типизированные диагностики.** Lean LSP возвращает структурированные объекты ошибок (файл, строка, сообщение, severity), а не raw text. В Signum механик теперь выдаёт hybrid формат с типизированными findings вместо flat "regressions: true/false". ## Policy Scanner Самое дешёвое улучшение. Между механиком (lint, typecheck, tests) и мультимодельным код-ревью появился bash-скрипт, который сканирует unified diff на известные опасные паттерны. 195 строк, ноль LLM-токенов. Сканирует только addition lines. 12 паттернов в трёх категориях: - **Security** (блокирует пайплайн): `eval`, subprocess с `shell=True`, `innerHTML`, SQL конкатенация, weak crypto - **Unsafe** (флаг для ревью): `TODO`/`FIXME`/`HACK`, debug-вывод - **Dependency** (флаг для ревью): новые записи в пакетных менеджерах -- но только если файл действительно manifest (`package.json`, `Cargo.toml` и т.д.), а не README или тестовая фикстура Три дизайн-решения пришли из "arbiter panel" -- независимого опроса Codex (GPT) и Gemini с последующим сравнением ответов (все три модели -- Claude, Codex, Gemini -- согласились по каждому): 1. **Fail-closed** при отсутствии входных данных. Нет диффа -- ошибка, а не "ноль находок". 2. **Фильтрация по имени файла** для dependency паттернов. Без неё любая JSON key-value пара в любом файле даёт false positive. 3. **Curated sinks** вместо широких regex. Короткий список опасных вызовов (`subprocess.call`, `child_process.spawn`) лучше, чем generic паттерн, который ловит безобидный `db.query()`. ## Типизированные диагностики До этого изменения отчёт механика был flat: lint прошёл или нет, тесты прошли или нет, регрессии да или нет. Engineer в repair mode получал это как blob и угадывал, какой файл и строку чинить. Теперь механик выдаёт hybrid формат: summary по каждой проверке всегда + per-file findings когда runner поддерживает structured output. У каждого finding поле `origin` -- `"structured"` для JSON (ruff, eslint), `"stable_text"` для парсабельного текста (tsc, mypy), `"none"` для summary only. Гейтинг по summary; findings -- подсказки для инженера, не source of truth. Отступление о ловле багов собственным пайплайном: Claude Opus нашёл критическую проблему на первом же ревью этой фичи. `|| true` после command substitution маскировал exit code, делая возвращаемое значение всегда нулевым. Regression detection была мертва для всех восьми поддерживаемых runners. Один токен. Iterative repair починил за один проход -- именно та конвергенция, для которой система создана. ## Параллельные repair lanes Самое сложное изменение. Раньше repair loop был последовательным: одна попытка Engineer, аудит, следующая попытка. Теперь спавнятся два Engineer'а параллельно, каждый в изолированном git worktree: - **Lane A**: "Почини минимальными точечными изменениями. Только помеченные строки." - **Lane B**: "Почини корневую причину. Можно затронуть больше файлов." Оба получают один repair brief. После завершения пайплайн прогоняет легковесные проверки (lint, typecheck, тесты, скрытые валидационные сценарии) на каждом lane, скорит их, и отправляет только победителя через полное трёхмодельное ревью. Если у победителя серьёзные находки -- ревью получает и второй lane. Тот же принцип, что у Lean `multi_attempt`: исследуй пространство решений параллельно, выбери лучшего, верифицируй один раз. ## Ещё три изменения Эти пришли из той же дизайн-сессии, но не связаны с Leanstral напрямую: **Dynamic strategy injection.** Contractor теперь классифицирует тип задачи (bugfix, feature, refactor, security) через keyword scan и генерирует strategy hint в контракте. Engineer читает как процесс-гайд: "сначала воспроизведи баг тестом" для багфиксов, "найди все вхождения паттерна, а не только одно" для security фиксов. Информативное -- не блокирует пайплайн. **Context retrieval для ревьюеров.** Новый pre-review шаг собирает: git history (последний коммит per file), ссылки на issues (парсятся из goal), project.intent.md. Всё инжектится только в Claude ревьюер -- Codex и Gemini остаются изолированными (goal + diff only), сохраняя ценность как независимые валидаторы. Цель -- снизить false positives, дав семантическому ревьюеру контекст "почему код такой". **Approval UX.** Мелкий фикс: отображение контракта при утверждении теперь в markdown вместо фрагментированного bash-вывода. Goal не обрезается, таблица компактная, warnings сгруппированы. ## Что я вынес Каждая фича прошла через полный пайплайн: дизайн-панель, контракт, реализация, трёхмодельный аудит, iterative repair. Из шести прогонов только один прошёл с первой попытки (самое простое изменение). Остальные потребовали 2-3 итерации. Паттерн: первый проход Engineer'а проходит все acceptance criteria, но код-ревью находит реальные баги -- маскировка exit code, race condition на shared paths, отсутствующие field mappings. Iterative loop чинит их за 1-2 прохода. В этой выборке из шести изменений система вела себя как задумано: не gatekeeping checkpoint, а convergence loop. Вся сессия: 7 коммитов, ~1900 строк, 5 дизайн-панелей, 15+ раундов мультимодельного ревью. Начало -- одна строка из утреннего дайджеста.https://ctxt.dev/posts/ru/signum-iterative-verification/https://ctxt.dev/posts/ru/signum-iterative-verification/Верификация AI-кода как цикл, а не гейт. Итеративный аудит, самокритика контрактов и общий контекст между задачами в Signum v4.6.Sun, 15 Mar 2026 00:00:00 GMTПервая версия Signum работала в один проход: CONTRACT → EXECUTE → AUDIT → PACK. Если аудит находил проблему — блок. Человек разбирается. Это честный процесс, но ограниченный. Представьте код-ревью, где ревьюер может только комментировать, а автор не может ничего исправить. Финдинг уходит обратно в очередь, контекст теряется, цикл начинается заново. Signum v4.6 закрывает этот разрыв: пайплайн теперь зацикливается на трёх уровнях — код, контракт и проектный контекст — прежде чем собрать финальный proofpack. ## Проблема: one-shot верификация В [предыдущих постах](/posts/ru/signum-contract-first-ai-dev) я разбирал контракт как точку истины и [proofpack как артефакт верификации](/posts/ru/signum-proofpack-ai-proof). Архитектура работала: спецификация → ослеплённая реализация → мультимодельный аудит → proof artifact. Но в продакшн-использовании проявился паттерн. Большинство находок аудита в наших ранних прогонах — не архитектурные проблемы. Это пропущенный edge case в обработке ошибок. Забытый `null` check. Тест, который не покрывает один из acceptance criteria. Вещи, которые инженер-агент мог бы исправить за секунды — если бы получил шанс. Вместо этого Signum ставил `AUTO_BLOCK`, человек смотрел на находку, перезапускал пайплайн. Полная пересборка контракта, полная реализация, полный аудит — для бага, который чинится одной строкой. ## Цикл 1: код — итеративный аудит Signum v4.6 добавляет цикл ремонта, связывающий AUDIT и EXECUTE. Когда аудит находит MAJOR или CRITICAL проблемы, вместо блокировки инженер возвращается чинить: ``` AUDIT → findings → re-enter EXECUTE (repair) → AUDIT → ... → PACK ``` После первого прохода аудита (механик + Claude + Codex + Gemini), если есть actionable находки, инженер-агент получает `repair_brief.json`: ```json { "iteration": 1, "findings": [ { "id": "F-1", "severity": "MAJOR", "file": "src/api/tokens.py", "line": 42, "description": "Missing error response when rate limit storage is unavailable", "source": "codex" } ] } ``` Важно: `repair_brief.json` содержит только наблюдаемые симптомы дефектов из видимых критериев и детерминированных проверок. Провалы holdout-сценариев описываются как поведенческие наблюдения ("функция возвращает 200 вместо ожидаемого 429") без раскрытия скрытых критериев приёмки. Data-level blinding из оригинального контракта сохраняется — инженер никогда не видит raw holdout text. Инженер чинит. Полный аудит перезапускается — не на diff от ремонта, а на всю реализацию от начала. Затем PACK собирает финальный proofpack, как и раньше. Ключевые решения: **Best-of-N, не last-of-N.** Пайплайн хранит артефакты каждой итерации в `.signum/iterations/NN/`. Если итерация 3 хуже итерации 2 (ремонт сломал что-то другое), Signum откатывается к лучшему кандидату. Не слепая вера в то, что последний ремонт — лучший. **Diff progression.** На первом проходе ревьюеры видят полный патч. На проходе 2+ — полный патч плюс дельту итерации с инструкцией фокусироваться на том, что изменилось в ремонте. Это экономит токены и снижает шум. Если дельта >80% от полного патча — fallback на полный diff (ремонт слишком большой, чтобы рассматривать инкрементально). **Early stop.** Если две итерации подряд не улучшают результат — остановка. Максимум 20 итераций (настраивается через `SIGNUM_AUDIT_MAX_ITERATIONS`). На практике сходимость за 2-3 прохода. **Finding fingerprints.** Каждая находка получает отпечаток на основе файла, диапазона строк и типа проблемы. Между итерациями Signum классифицирует каждый финдинг как resolved, persisting или new. Синтезатор использует это для оценки реального прогресса — не просто "меньше находок", а "какие конкретно проблемы исправлены и какие появились". **Фильтрация галлюцинаций.** Если ревьюер ссылается на строку, которой нет в diff, или на файл вне scope — находка отбрасывается. Это тот же механизм, что описан в [посте об экосистеме](/posts/ru/heurema-ecosystem): каждый AI-финдинг валидируется против реального diff перед попаданием в repair loop. ## Цикл 2: контракт — самокритика Цикл кода чинит реализацию. Но что если проблема выше — в самом контракте? Идеальная реализация ошибочной спецификации — всё ещё провал. Для задач среднего и высокого риска контрактор теперь запускает 4-проходную самокритику перед тем, как показать контракт человеку: 1. **Ambiguity review** — сканирует goal, acceptance criteria и scope на неоднозначные формулировки 2. **Missing-input review** — проверяет недостающие предусловия, записывает решения по уточнениям 3. **Contradiction review** — ищет противоречия между целью, scope и уровнем риска 4. **Coverage review** — реконструирует цель из критериев приёмки, проверяет покрытие, документирует происхождение допущений Максимум 2 раунда авторевизии. Если после второго раунда вердикт `"no-go"` — эскалация к человеку. Задачи низкого риска пропускают все 4 прохода. Результат записывается в контракт: ```json { "readinessForPlanning": { "verdict": "go", "summary": "All ambiguities resolved. AC3 coverage gap closed in round 1." }, "ambiguityCandidates": [...], "contradictionsFound": [], "clarificationDecisions": [...] } ``` Человек видит и вердикт, и весь путь к нему. Не "контрактор решил, что контракт хороший" — а какие проблемы были найдены и как устранены. ## Цикл 3: проект — общий контекст между контрактами Цикл кода итерирует внутри одной задачи. Цикл контракта итерирует внутри одной спецификации. Но предыдущие версии Signum работали с контрактами изолированно. Каждая задача — отдельная вселенная. В реальном проекте задачи связаны: трогают одни файлы, зависят от одних решений, используют одну терминологию. Три новых слоя: **Project intent.** Файл `project.intent.md` в корне проекта — цель, возможности, non-goals, персоны. Контрактор читает его перед генерацией контракта. Non-goals проекта становятся ограничениями scope контракта. Для средне- и высокорискованных задач отсутствие intent — блокирующий вопрос. **Glossary.** `project.glossary.json` определяет канонические термины и запрещённые синонимы. `glossary_check` сканирует контракт на использование алиасов, `terminology_consistency_check` ловит расползание синонимов между активными контрактами. Оба — WARN, не блок. **Cross-contract coherence.** `overlap_check` находит пересечения inScope между активными контрактами (два контракта трогают один файл — конфликт?). `assumption_check` ищет противоречия в допущениях между связанными контрактами. `adr_check` предупреждает, когда релевантные ADR существуют, но не упоминаются в контракте. Плюс **upstream staleness detection**: контрактор хэширует содержимое `project.intent.md` и глоссария при создании контракта. Если upstream-файлы изменились к моменту выполнения — предупреждение (или блок, если настроено `stalenessPolicy: "block"`). ## Архитектура v4.6.1: checks как отдельные скрипты Бонус последнего рефакторинга: 6 inline-проверок, которые жили внутри оркестратора, вынесены в отдельные testable-скрипты в `lib/`: ``` lib/glossary-check.sh — сканирование запрещённых синонимов lib/terminology-check.sh — расползание терминов между контрактами lib/overlap-check.sh — пересечение inScope lib/assumption-check.sh — противоречия в допущениях lib/adr-check.sh — проверка релевантных ADR lib/staleness-check.sh — устаревание upstream-артефактов ``` Все скрипты: JSON stdout, stderr для диагностики, exit 0 для любого результата проверки (non-zero только для инфраструктурных ошибок). Оркестратор вызывает скрипты и сам решает, блокировать или предупредить. Разделение ответственности: скрипт проверяет, оркестратор решает. ## Что это меняет Signum v3 отвечал на вопрос "корректно ли это?" одним да/нет. v4.6 отвечает на вопрос "можно ли это сделать корректным?" — и если да, делает. В наших ранних прогонах заметная доля задач, которые v3 блокировал с AUTO_BLOCK, v4.6 доводит до AUTO_OK за 2-3 итерации без участия человека. Задачи, которые всё ещё блокируются — как правило реальные проблемы спецификации или архитектуры, то есть именно то, что и должно эскалироваться к человеку. Верификация — не гейт в конце пайплайна. Это цикл. Тот же принцип, что и в человеческом код-ревью: находка → исправление → перепроверка. Разница в том, что AI может пройти этот цикл за секунды, а не за дни. ## Ссылки - [signum на GitHub](https://github.com/heurema/signum) - [Контракт — это контекст](/posts/ru/signum-contract-first-ai-dev) — первый пост серии - [AI пишет код. Где доказательства?](/posts/ru/signum-proofpack-ai-proof) — второй пост серии - [skill7.dev/development/signum](https://skill7.dev/development/signum) - [emporium — маркетплейс плагинов](https://github.com/heurema/emporium)https://ctxt.dev/posts/ru/sentinel-environment-security-audit/https://ctxt.dev/posts/ru/sentinel-environment-security-audit/Мы тщательно проектируем промпты и инструменты, но почти не проверяем среду, в которой агент реально работает. Sentinel делает это измеримым.Wed, 11 Mar 2026 00:00:00 GMTМы много говорим о промптах, инструментах и оценках. Но почти никто не аудирует среду, в которой AI-агент реально работает. Агент видит ваши `.env` файлы. Ваши `.mcp.json` с токенами. Ваш `settings.json` с `"permissions": "allow"`. Ваши плагины, хуки, конфиги. Всё это - операционный контекст, и он напрямую влияет на то, что агент может сделать. Если API-ключ лежит в plaintext - агент его прочитает. Если `PreToolUse` хук не настроен - любая Bash-команда выполнится без фильтрации. Если `.claudeignore` отсутствует - агент прочитает любой файл в проекте. Это не гипотетические риски. Это конфигурация по умолчанию. ## Поверхность атаки, которую никто не измеряет Проведите мысленный аудит своей рабочей станции: **Секреты.** Сколько `.env` файлов в ваших проектах? Они в `.gitignore`? Есть ли секреты в истории git? Когда вы запускаете Claude Code, shell уже содержит `ANTHROPIC_API_KEY`, `AWS_SECRET_ACCESS_KEY`, `GITHUB_TOKEN` - агент может выполнить `printenv` и увидеть всё. **MCP-серверы.** Откройте `.mcp.json`. Токены прямо в JSON? Версии серверов не зафиксированы? Нет `allowedTools` для ограничения доступных инструментов? Каждый MCP-сервер - это child process, наследующий все переменные окружения. **Хуки.** Есть ли `PreToolUse` хук, фильтрующий опасные Bash-команды? А для субагентов? Claude Code не наследует хуки родительского процесса в субагентах - это задокументированный баг, а не фича. **Доверие.** Есть `.claudeignore`? Режим разрешений - `default` или `acceptEdits`? Сколько плагинов установлено и какие из них имеют `hooks`? Каждый из этих вопросов бинарный: да или нет, безопасно или нет. Их можно проверить детерминированно, без LLM, без интерпретации. ## Среда как контекст В контекстной инженерии мы превращаем неявное в явное. Промпты, инструкции, инструменты - всё становится структурированным контекстом, который формирует поведение агента. Но среда выполнения - это тоже контекст. Когда агент запускается в shell с `direnv`-загруженными секретами, он получает доступ к ним не потому что вы так спроектировали, а потому что никто это не проверил. Когда MCP-сервер запускается без `allowedTools`, агент получает доступ ко всем инструментам не потому что это нужно, а потому что это поведение по умолчанию. Security posture рабочей станции - это implicit context. И пока он неявный, им нельзя управлять. ## Sentinel: детерминированный аудит [Sentinel](https://github.com/heurema/sentinel) - плагин для Claude Code, запускающий 18 проверок в шести категориях: | Категория | Проверок | Что ищет | | --------- | -------- | ------------------------------------------------------------------------------------------- | | secrets | 5 | Plaintext-ключи, `.env` без `.gitignore`, секреты в git history, runtime env vars, dotfiles | | mcp | 3 | Токены в `.mcp.json`, отсутствие `allowedTools`, непинованные версии серверов | | plugins | 3 | Дрифт реестра, утечка scope, непроверенные плагины | | hooks | 2 | Отсутствие `PreToolUse` гарда, пробел в хуках субагентов | | trust | 3 | Нет `.claudeignore`, широкие разрешения, поверхность для инъекций | | config | 2 | Небезопасные значения по умолчанию, устаревшие сессии | Каждая проверка - отдельный POSIX sh скрипт, выдающий JSON. Никакого LLM. Никакой эвристики. `grep` находит plaintext-токен в `.mcp.json` или не находит. `stat` проверяет права доступа: 600 или нет. Результат воспроизводим. ``` LOAD → VALIDATE → PLAN → RUN → NORMALIZE → ASSESS → PERSIST → RENDER ``` На выходе - JSON-отчёт и терминальный scorecard: ``` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ sentinel audit - run_20260311T120000Z ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Category Score Checks secrets 40/100 ██░░░░░░░░ 2/5 pass mcp 67/100 ██████░░░░ 2/3 pass plugins 100/100 ██████████ 3/3 pass hooks 0/100 ░░░░░░░░░░ 0/2 pass trust 60/100 ██████░░░░ 2/3 pass config 50/100 █████░░░░░ 1/2 pass Total: 47/100 Verdict: FAIL Reliability: 1.00 (18/18 checks ran) ``` Два независимых показателя: **score** (0-100) - security posture, **reliability** (0.0-1.0) - сколько проверок реально выполнилось. Score 95 при reliability 0.4 не заслуживает доверия. ## Что я обнаружил Первый запуск sentinel на моей рабочей станции показал 47 из 100. Реальные находки: - 8 plaintext `.env` файлов с API-ключами в 4 рабочих контекстах - `ANTHROPIC_API_KEY`, `OPENAI_API_KEY` и ещё 12 секретов доступны через `printenv` в текущем shell - 3 MCP-сервера с токенами в `.mcp.json` - Ни одного `PreToolUse` хука - любая Bash-команда выполняется без фильтрации - Отсутствует `.claudeignore` в нескольких проектах Ни одна из этих проблем не была случайностью. Это результат стандартной настройки: поставил Claude Code, добавил MCP-серверы, начал работать. Безопасность среды - не то, о чём думаешь при установке. ## Remediation: не только находить, но и чинить `/sentinel-fix <run_id>` проходит по каждому FAIL/WARN finding и показывает: 1. **Что** - описание проблемы с redacted evidence 2. **Почему** - объяснение риска 3. **Как** - конкретная команда для исправления Команды берутся из реестра проверок, не генерируются LLM. `sentinel-fix` никогда не выполняет команды автоматически, только предлагает. Risk badge для каждого действия: `safe`, `caution`, `dangerous`. После исправления можно запустить `/sentinel-diff` для сравнения отчётов. Каждая находка имеет стабильный `finding_id` (SHA-256 от `check_id|category|evidence_paths`), что позволяет отслеживать: новые проблемы, решённые проблемы, изменения статуса. ## Что это значит для контекстной инженерии Мы тратим усилия на то, чтобы агент получил правильный системный промпт, правильные инструменты, правильную документацию. Но среда выполнения - это такой же контекст, только неуправляемый. Plaintext-секрет в `.env` - не проблема безопасности в вакууме. Это implicit context, определяющий, что агент _может_ сделать, помимо того, что ему _положено_ делать. Security audit для AI-рабочей станции - не паранойя. Это та же практика, что и проверка зависимостей, линтинг, CI-пайплайн. Просто пока для нового класса рисков не было инструмента. ## Установка ```bash claude plugin add heurema/sentinel ``` Затем: ``` /sentinel # полный аудит /sentinel --deep # аудит + объяснение рисков от LLM /sentinel-fix <run_id> # пошаговое исправление /sentinel-diff # сравнение с предыдущим аудитом ``` ## Ссылки - [sentinel на GitHub](https://github.com/heurema/sentinel) - [skill7.dev/devtools/sentinel](https://skill7.dev/devtools/sentinel) - [Контракт - это контекст: Signum](/posts/ru/signum-contract-first-ai-dev) - верификация AI-кода - [11 плагинов, один маркетплейс: экосистема heurema](/posts/ru/heurema-ecosystem)https://ctxt.dev/posts/ru/skillpulse-telemetry-for-ai-skills/https://ctxt.dev/posts/ru/skillpulse-telemetry-for-ai-skills/PostToolUse хук, который логирует каждую активацию скилла в локальный JSONL. Ни один существующий инструмент не отслеживает, выполнила ли модель инструкции скилла.Wed, 11 Mar 2026 00:00:00 GMTВы устанавливаете 16 скиллов. Видите, как они срабатывают. Но вот вопрос, который никто не задает: **модель действительно им следует?** Я проверил каждый инструмент телеметрии в экосистеме Claude Code -- встроенный OTel, claude_telemetry, claude-code-otel, даже метрики платформы skills.sh. Ни один из них не отслеживает adherence. Они говорят, что скилл загрузился, но не то, выполнила ли модель его инструкции. Поэтому я сделал skillpulse. ## Разрыв Встроенный OpenTelemetry Claude Code (через `CLAUDE_CODE_ENABLE_TELEMETRY=1`) захватывает общие метрики: длительность сессии, токены, стоимость, вызовы инструментов. С `OTEL_LOG_TOOL_DETAILS=1` он даже записывает `skill_name` в события tool result. Но это сигнал загрузки, а не следования. Разница принципиальна. Скилл может успешно загрузиться и быть полностью проигнорирован моделью. Без отслеживания adherence вы оптимизируете вслепую. | Инструмент | Отслеживает загрузку | Отслеживает следование | | ---------------- | :------------------: | :--------------------: | | Встроенный OTel | Да | Нет | | claude_telemetry | Нет | Нет | | claude-code-otel | Нет | Нет | | skills.sh | Только установки | Нет | | **skillpulse** | **Да** | **Да (planned)** | ## Как это работает Skillpulse -- это `PostToolUse` хук, который срабатывает на каждый вызов `Skill` tool. Он пишет одну строку JSONL на активацию: ```json { "skill_id": "signum:signum", "timestamp": "2026-03-11T08:48:18Z", "session_id": "20260311_114818_93074", "loaded": true, "followed": null, "plugin_name": "skillpulse" } ``` Реализация -- 60 строк bash. Несколько проектных решений: **2-секундный watchdog.** PostToolUse хуки выполняются синхронно -- зависший хук блокирует всю сессию. Skillpulse запускает self-kill watchdog, который отправляет SIGKILL через 2 секунды. На практике хук завершается за <50ms. **Фильтр только Skill.** PostToolUse срабатывает на каждый вызов инструмента -- Read, Write, Bash, все подряд. Skillpulse проверяет `tool_name == "Skill"` и немедленно выходит для всего остального. Нулевой overhead на не-скилловых вызовах. **Append-only JSONL.** Никакой базы данных, ротации, конфигурации. Один файл в `~/.local/share/emporium/activation.jsonl`. Переживает крэши, легко инспектировать, тривиально бэкапить. ## Что я узнал из 4 записей Да, четырех. Skillpulse был создан 4 марта и потом... не установлен. Классика. Я исправил это сегодня. Но даже 4 записи рассказали кое-что полезное: ``` Skill Acts Sess Load% Age ----------------------------------------------------- herald:news-digest 2 2 100% 7d arbiter 1 1 100% 7d signum:signum 1 1 100% 7d ``` Три скилла покрывают все активации. У меня установлено 16. Это 81% dormancy rate. Большинство моих скиллов -- мертвый груз, потребляющий контекстные токены. ## Агрегатор 90-строчный Python скрипт читает JSONL и выдает per-skill статистику: ```bash python3 scripts/aggregate.py # таблица python3 scripts/aggregate.py --json # для пайплайнов ``` Никаких зависимостей. Читает timestamps, группирует по skill_id, вычисляет частоту, уникальные сессии, loaded rate и дней с последней активации. ## Куда это ведет Skillpulse -- это Phase 1 более крупного пайплайна, который я называю EvoSkill -- скиллы, которые улучшают себя на основе данных использования. Пайплайн: ``` skillpulse (лог) | aggregator (статистика) | bench (тест на задачах) | evolver (предлагает улучшения) ``` Поле `followed` сейчас null -- для его заполнения нужен tool-pattern fingerprinting, определяющий, выполнила ли модель ожидаемое поведение скилла. Это сложная часть, и я намеренно откладываю ее, пока не наберется достаточно данных активации для валидации подхода. Вещи, которые я осознанно пропускаю на текущем масштабе (<20 сессий/неделю, 16 скиллов): - **Hotelling T-squared drift detection** -- нужно 50+ траекторий на скилл - **Bayesian calibration** -- нужны размеченные outcome-данные - **Hierarchical routing** -- актуально при 50+ скиллах - **Automated gates** -- human review пока мой gate Исследования, на которых это основано: [EvoSkill](https://arxiv.org/abs/2603.02766), [AutoSkill](https://arxiv.org/abs/2603.01145) и [ASI drift framework](https://arxiv.org/abs/2601.04170). ## Попробуйте ```bash claude mcp add-json skillpulse '{"source": {"source": "url", "url": "https://github.com/heurema/skillpulse.git"}}' ``` Код: [github.com/heurema/skillpulse](https://github.com/heurema/skillpulse) Все данные остаются локально. MIT лицензия. Нулевые зависимости -- только bash и jq.https://ctxt.dev/posts/ru/delve-adversarial-research-verification/https://ctxt.dev/posts/ru/delve-adversarial-research-verification/Почему AI research-агенты дают ложную уверенность и как delve меняет доверительную модель через claim-level верификацию.Tue, 10 Mar 2026 00:00:00 GMTВы спросили AI research-агента — получили уверенный 2000-словный ответ с цитатами. Два источника не существуют. Три "факта" противоречат друг другу. Синтез звучит авторитетно, но построен на непроверенных утверждениях. Это не редкий случай. Это архитектурная особенность текущих систем. ## Проблема Research-агенты оптимизированы под связность, не под корректность. Они собирают источники, строят синтез — но никогда не проверяют, держатся ли конкретные утверждения при проверке. Модель отказа выглядит так: правдоподобно звучащий отчёт, где 20-30% фактических утверждений неверны или не поддаются верификации. Это хуже, чем отсутствие исследования. Потому что создаёт ложную уверенность. Проблема не в "галлюцинациях источников" — это симптом. Проблема в том, что агент никогда не ставил под сомнение свои промежуточные выводы. Каждое утверждение в синтезе принималось как данность из предыдущего шага. Цепочка рассуждений без единой точки разрыва. ## Контекст Ландшафт уже плотный. OpenAI Deep Research, Perplexity, Exa. Из открытых: node-deepresearch, deep-research (dzhng), gpt-researcher, WebResearcher, storm, WebAgent — семь проектов только в ближайших аналогах. Все они закрывают одно: retrieval + synthesis. Найти релевантные источники, создать связный отчёт. Это сложно и они делают это хорошо. Чего нет ни у одного: claim-level adversarial verification. Извлечь атомарные утверждения из синтеза и независимо оспорить каждое. Это пробел. Не маркетинговый тезис — буквально отсутствующий шаг в каждом из семи проектов, которые мы разбирали. ## Решение: delve [delve](https://github.com/heurema/delve) — плагин для Claude Code. Пятистадийный пайплайн: ``` SCAN → DECOMPOSE → DIVE → VERIFY → SYNTHESIZE ``` ``` /delve "WebSocket vs SSE для real-time приложений" --depth deep ``` **SCAN** — предварительная разведка: источники, временной охват, первичные противоречия. Определяет, что именно нужно раскопать. **DECOMPOSE** — разбивает вопрос на суб-топики. Для "WebSocket vs SSE" это может быть: latency под нагрузкой, proxy compatibility, browser support, server resource model, reconnect behaviour. Каждый суб-топик получает отдельную нить исследования. **DIVE** — параллельные подагенты (2-6 в зависимости от `--depth`) исследуют каждый суб-топик независимо. Каждый агент трекает `original_sources` — первоисточники, не репосты и пересказы. Это предотвращает press-release amplification: ситуацию, когда один маркетинговый пресс-релиз цитируется через 12 промежуточных статей, создавая иллюзию множества независимых источников. **VERIFY** — дифференцирующий шаг. Из черновика синтеза извлекаются атомарные утверждения: ``` claim_1: "SSE не поддерживает бинарные данные" claim_2: "WebSocket требует дополнительной логики для reconnect" claim_3: "HTTP/2 устраняет лимит 6 соединений для SSE" ``` Для каждого утверждения запускается независимый fact-checker. Результат — три статуса: `verified`, `partially-verified`, `unverified`. Итоговый синтез явно маркирует каждое утверждение своим статусом. **SYNTHESIZE** — финальный отчёт со встроенными метаданными доверия. Не просто "вот ответ", а "вот ответ и вот что из него держится при проверке". ## Как выглядит вывод ```markdown ## Вывод WebSocket предпочтительнее для bidirectional протоколов и бинарных данных. SSE проще в реализации для server-push сценариев. ## Верификация утверждений ✓ verified SSE использует обычные HTTP-соединения, упрощая proxy-конфигурацию ✓ verified WebSocket требует явной логики reconnect на клиенте ~ partial HTTP/2 мультиплексирование снимает лимит соединений SSE [зависит от сервера] ✗ unverified SSE не поддерживает бинарные данные [спецификация допускает через base64] ## Источники 4 independent · 1 amplified chain detected ``` "Amplified chain detected" — это `original_sources` tracking в действии: delve нашёл источник, который цитируется через несколько промежуточных публикаций как будто это независимые данные. ## Инфраструктурные детали **Resume support.** Состояние сохраняется в `~/.cache/delve/runs/`. Прерванный на DIVE run восстанавливается с того же места — полезно при `--depth deep`, где полный прогон может занять 15-20 минут. **Sensitivity routing.** По умолчанию delve может использовать несколько провайдеров для ускорения. Для конфиденциальных запросов: `--providers claude` — всё остаётся внутри одного провайдера. **Depth levels.** `--depth quick` (2 подагента, ~5 минут) / `--depth standard` (4, ~10 минут) / `--depth deep` (6, ~20 минут). VERIFY всегда включён — только масштаб меняется. ## Инсайт Ключевое дизайн-решение: не "больше контекста", а "принудительное оспаривание каждого утверждения". Retrieval — нерешённая проблема. Верификация — другая нерешённая проблема. Шаг VERIFY добавляет 40-60% к общему времени. Это осознанный выбор: платишь временем за принципиально другую доверительную модель. Честное ограничение: верификация настолько хороша, насколько хороши источники верификатора. Для cutting-edge исследований, нишевых технических областей или актуальных событий часть утверждений останется `unverified` — не потому что неверна, а потому что независимые источники недоступны. Модель качества делает это явным, а не скрывает под "уверенным синтезом". Именно это и есть полезное свойство: `unverified` — это сигнал, не провал. Он говорит "здесь нужно копать руками". ## Установка ```bash claude plugin marketplace add heurema/emporium claude plugin install delve@emporium ``` Затем: ``` /delve "ваш вопрос" --depth standard ``` ## Обратная связь Delve в активной разработке. Если верификатор выносит некорректный вердикт, пайплайн застревает на стадии или resume не подхватывает прерванный run — можно сообщить прямо из Claude Code. Установите [Reporter](https://github.com/heurema/reporter): ```bash claude plugin install reporter@emporium ``` Затем: `/report bug` или `/report feature` или `/report question` Reporter автоматически определяет, что вы работаете с продуктом heurema, прикрепляет контекст среды и показывает предпросмотр перед отправкой. ## Ссылки - [delve на GitHub](https://github.com/heurema/delve) - [skill7.dev/plugins/delve](https://skill7.dev/plugins/delve) - [Архитектура: docs/how-it-works.md](https://github.com/heurema/delve/blob/main/docs/how-it-works.md) - [reporter — отчёты из Claude Code](https://github.com/heurema/reporter) #context-engineering #claude-code #deep-research #verification #agentshttps://ctxt.dev/posts/ru/from-plugin-to-product/https://ctxt.dev/posts/ru/from-plugin-to-product/Локальный новостной плагин для AI-агентов работал, пока не перестал. Решение - другая модель данных, язык и surface.Tue, 10 Mar 2026 00:00:00 GMTHerald был Python-плагином, который собирал RSS-ленты и Hacker News, кластеризовал статьи по похожести заголовков и генерировал Markdown-дайджесты. Работал локально, не требовал API-ключей и делал ровно то, для чего создавался. Потом мы попытались использовать его для реальной работы. ## Что сломалось Базовое допущение Herald - статьи как primary unit. Собираешь статьи, дедуплицируешь по URL, кластеризуешь по похожести заголовков, скоришь по весу источника и свежести, проецируешь Markdown-дайджест. Работает для разработчика, читающего утренние новости. Не работает когда: - Агенту нужно знать, являются ли "Coinbase листит TOKEN" и "TOKEN теперь доступен на Coinbase" одним и тем же фактом реального мира - Нужны уровни уверенности, а не просто скоры - сколько независимых источников подтверждают событие? - Система должна обновляться при появлении новых evidence, а не только по крону - Downstream-автоматизации нужны типизированные поля (`assets: ["BTC"]`, `event_type: "listing"`) вместо парсинга Markdown Фундаментальная проблема: Herald моделировал контент. Мир, который он пытался представить, содержал события. ## Статьи vs События В Herald главным объектом была `Story` - кластер статей с похожими заголовками: ``` Story: "Python 3.14 Released" - Статья с HN (score: 342) - Статья из блога Simon Willison - Статья с Python.org ``` Кластер был результатом. Статьи - атомами. В Sift главный объект - `Event` - структурированный факт-паттерн с provenance: ```json { "event_id": "evt_2026030801", "title": "Bitcoin ETF daily inflow hits $1.2B record", "event_type": "market_milestone", "assets": ["BTC"], "topics": ["etf", "institutional"], "importance_score": 0.87, "confidence_score": 0.93, "source_cluster_size": 7, "published_at": "2026-03-08T14:22:00Z" } ``` Событие - это truth. Статьи, поддерживающие его - evidence. Различие важно потому что: 1. **События обновляемы.** Когда новая статья подтверждает или опровергает событие, confidence score меняется. Story в Herald замораживались после кластеризации. 2. **У событий типизированные метаданные.** `assets`, `topics`, `event_type` - queryable поля, а не bag-of-words из заголовков. 3. **События разделяют importance и confidence.** Слух о Bitcoin ETF approval - high-importance, но low-confidence. Herald не мог это выразить - story либо попадала в дайджест, либо нет. ## JSON как truth, Markdown как projection Output Herald - Markdown-файл. Это и был продукт. Агенты читают Markdown, люди читают Markdown, готово. Sift инвертирует это. Каноническая запись - типизированное JSON-событие. Всё остальное - проекция: - Человеческий дайджест? Markdown-рендер топ-событий за временное окно. - Контекст для агента? Тот же JSON, отфильтрованный по asset и topic. - WebSocket-стрим? Push-нотификации при upsert события. - `llms.txt`? Статический срез для LLM-friendly discovery. Это не теоретическая чистота. Это операционно: когда API возвращает событие, браузерный workspace и CLI оба рендерят из одной записи. Нет "браузерной версии" и "агентской версии" truth. ## Python в Go Herald - ~1200 строк Python. Sift - ~7000 строк Go. Переписывание не ради бенчмарков. Три причины смены языка: 1. **Single binary deployment.** Sift Pro - hosted-сервис на Linux-ноде. `go build` дает один бинарник. Без virtualenv, без pip, без runtime. Systemd unit-файл тривиален. 2. **Shared pipeline.** Одни и те же Go-пакеты (`internal/pipeline`, `internal/event`, `internal/ingest`) работают и в локальном `sift` CLI, и в hosted `siftd` сервере. В Python шаринг кода между CLI и async web server означал борьбу с import paths и event loops. 3. **Concurrency для real-time.** Hosted-режим Sift запускает scheduler, HTTP API и WebSocket broadcaster в одном процессе. Goroutines и channels делают это straightforward. Asyncio Python мог бы, но cognitive overhead выше для маленькой команды. Trade-off: type system Go ловит раньше, но замедляет rapid prototyping. Первая версия Herald была за день. V0 Sift занял неделю. ## Local Free + Hosted Pro Herald - local-only by design. Sift сохраняет локальный tier и добавляет hosted. **Sift Free** (локальный CLI): - SQLite-хранилище в `~/.sift/` - Пользовательское расписание sync - Та же event model, те же digest projections - Полное владение данными **Sift Pro** ($5/мес): - Hosted Postgres store с 30-дневным retention - Автономный sync каждые 5 минут - Аутентифицированный REST API (`/v1/events`, `/v1/digests`) - WebSocket-стрим для real-time обновлений - Zitadel-backed аккаунты Split важен потому что free tier - реальный продукт, а не урезанный teaser. Разработчик, которому нужна локальная крипто-аналитика - получает её. Разработчик, которому нужна always-on event delivery для агентов - платит за hosted runtime. ## Что на самом деле нужно агентам Глубокий урок перехода от Herald к Sift - о том, что агентам нужно от новостной системы. Herald давал агентам Markdown. Это было human-readable, что казалось фичей. Но агентам не нужна проза. Им нужны: - **Типизированные записи** для фильтрации без парсинга natural language - **Сигналы уверенности** для принятия решений о действиях - **Стабильные ID** для ссылок на события между сессиями - **Push-доставка** без поллинга - **Provenance** для трассировки claim к источникам Это задача context engineering. Вопрос не "какой текст скормить модели". А "какой структурированный контекст нужен агенту для принятия решения". Markdown-дайджест Herald был человеческой проекцией, притворяющейся агентским контекстом. JSON-события Sift - агентский контекст, у которого есть человеческая проекция. ## Правило provenance Один принцип из манифеста Sift повлиял на больше дизайн-решений, чем любой другой: no claim without provenance. Каждое событие отслеживает, какие источники внесли вклад. Поле `source_cluster_size` говорит, сколько независимых источников подтвердили событие. `confidence_score` вычисляется из source agreement, а не из предположения языковой модели. Это значит Sift может честно сказать: "7 источников сообщили об этом ETF milestone, confidence 0.93" vs "1 блог упомянул этот слух, confidence 0.41". Herald не мог их различить - оба появились бы как stories с разными скорами, но scoring не разделял importance и evidence quality. Практический эффект: downstream-агенты могут выставлять пороги. "Действуй только по событиям с confidence > 0.8 и source_cluster_size > 3". Это policy, которую автоматизация может enforce. "Действуй по stories со score > 50" - это guess. ## Что осталось прежним Не всё изменилось. Ключевой инсайт Herald выжил: кластеризация связанных репортов в единый unit - самая ценная трансформация в news pipeline. Неважно как называть - story или event - deduplication-by-meaning превращает 45 статей в 27 actionable items. Формула скоринга изменилась, принцип нет: source weight важен, recency важен, cross-source confirmation важен. И local-first инстинкт выжил. Sift Pro существует потому что некоторым пользователям нужен, а не потому что local-first был неправильным. Free CLI доказывает, что data model работает без cloud dependency. ## Попробуй Sift доступен на [skill7.dev/sift](https://skill7.dev/sift). Локальный CLI open source. Herald остается доступным как Claude Code плагин для разработчиков, которым нужна configurable, multi-topic news intelligence без аккаунтов и подписок. ## Источники - [Sift на skill7.dev](https://skill7.dev/sift) - [Herald v2: Local-First News Intelligence for AI Agents](/posts/en/herald-v2-local-news-intelligence) - [Herald on GitHub](https://github.com/heurema/herald)https://ctxt.dev/posts/ru/spec-gated-delivery/https://ctxt.dev/posts/ru/spec-gated-delivery/AI удешевил код. Он не удешевил доверие. Решение - не лучшие ревьюеры, а перенос gate с PR diff на утвержденный intent.Fri, 06 Mar 2026 00:00:00 GMTAI сделал написание кода массово доступным. Доверие к коду дешевле не стало. Стандартный пайплайн сегодня: issue или промпт, AI пишет код, AI или человек ревьюит PR, merge. Это всегда было несовершенным, но масштабировалось, пока люди писали каждую строку и ревьюер мог восстановить intent. Ломается, когда большая часть diff сгенерирована за секунды, а ревьюеру приходится reverse-engineer-ить intent из результата. Bottleneck сместился. Генерация дешева. Верификация - нет. ## Ловушка PR Review PR review - поздний, дорогой, вероятностный checkpoint. К моменту, когда ты смотришь на diff, код существует, тесты существуют, commit message существует. Ты pattern-match-ишь "выглядит ли это правильно" - а не сверяешь со спецификацией того, что "правильно" означает. Три failure mode компаундятся: 1. **Issue - это не спецификация.** "Add rate limiting" имеет десять валидных реализаций. Ревьюер сравнивает diff с ментальной моделью, а не с shared artifact. 2. **AI ревьюит AI без ground truth - это circular.** Три модели на одном diff дают три мнения. Они ловят баги и стилевые проблемы. Но без формализованной спецификации для проверки они сравнивают diff со своими assumptions - не с верифицированным intent. Multi-model review становится полезным, когда он привязан к конкретной спецификации (что Signum делает в audit-фазе), а не когда заменяет её. 3. **Слабые evidence переживают merge.** После закрытия PR что остается? Review comments, approval checkmarks, linked issues, CI logs. У некоторых команд артефакты богаче - test reports, CODEOWNERS traces, provenance attestations. Но даже в зрелых пайплайнах редко есть единый machine-readable артефакт, связывающий изменение с pre-approved, верифицированным intent с holdout-результатами. ## Сдвиг Primary trust artifact должен быть не diff. А утвержденная спецификация. Primary gate должен быть не "выглядит ли это правильно для ревьюера". А "проходит ли это deterministic checks против утвержденного intent". Primary evidence должен быть не review comments. А signed conformance artifact. ``` Утвержденный intent -> blinded execution -> deterministic verification -> signed evidence -> решение ``` Это не теория. Это операционный паттерн. Кирпичики существуют: typed specs, deterministic test runners, holdout test sets, attestation primitives (DSSE, in-toto, SLSA). Некоторые команды собрали части этого internally. Но нет стандартного открытого стека, который объединяет spec gating, holdout governance и signed conformance evidence в единый delivery pipeline. ## Что проверяет Spec Gate Spec gate не доказывает, что код корректен в общем случае. Это формальная верификация - другая задача. Он доказывает что-то более узкое и практичное: - Какой контракт был утвержден, кем, когда - Какой commit был проверен против него - Какие deterministic checks были запущены и их результаты - Какие holdout checks (невидимые для implementing agent) прошли или нет - Что evidence bundle не был подменен после факта Trust model зависит от того, кто контролирует verifier, кто запечатывает holdouts, и может ли implementing agent влиять на evidence chain. В случае Signum: holdouts запечатываются при утверждении контракта, engineer agent получает отфильтрованный контракт, и proofpack хеширован против оригинала. Это не делает его tamper-proof во всех threat models, но поднимает планку выше "CI runner сказал pass". Это proof of conformance + proof of process. Не proof of correctness. Что явно не доказывается: - Что спецификация идеальна - Что holdout checks покрывают все edge cases - Что нет неизвестных классов дефектов - Что LLM-judged checks равны формальной верификации Проговаривать это важно. В момент, когда заявляешь больше, чем доставляешь - продаешь snake oil. ## Holdouts: ключевой механизм Самая мощная идея в spec-gated delivery - holdout criteria: acceptance checks, которые implementing agent никогда не видит. Ты пишешь десять acceptance criteria. Три помечаются holdout. Агент получает семь. Реализует, пишет тесты, проходит всё, что видит. Затем CI запускает holdout checks на готовом коде. Если агент забыл обработать сброс счетчика по истечении окна или пропустил edge case с пустым вводом, holdout ловит это - не потому что ревьюер заметил, а потому что критерий существовал до начала реализации. Важно: holdout criteria должны быть следствиями visible contract, а не тайно добавленными требованиями. Если visible spec говорит "rate limit POST /api/tokens at 5/min", holdout, проверяющий сброс счетчика после окна - валидная деривация. Holdout, добавляющий новый endpoint - нет, это undisclosed requirement. Разница между "ревьюер нашел баг" и "автор спецификации предвидел failure mode". ## Честные границы У spec-gated delivery реальные ограничения: - **Качество спецификации - потолок.** Плохие спецификации порождают ложную уверенность. Spec gate, пропускающий слабый контракт, хуже отсутствия gate, потому что создает иллюзию верификации. - **Не всё детерминированно проверяемо.** UX, производительность под реальной нагрузкой, security posture - требуют человеческого суждения или специализированного тулинга. Система должна честно маркировать каждый критерий как `deterministic`, `heuristic` или `manual`. - **Holdouts требуют domain expertise.** Ценность holdout пропорциональна тому, насколько хорошо он предвидит failure modes. Это человеческий навык. Moat не в AI code generation. Не в AI review. А в verification and evidence layer: spec quality gates, holdout governance, deterministic verifier mapping, signed conformance artifacts и policy engines, разделяющие доказанное от предполагаемого. ## Почему сейчас Три зрелых потока сошлись: 1. **AI coding стал mass-market.** Copilot, Claude Code, Cursor - команды генерируют больше кода, чем могут ревьюить. 2. **Contract-driven workflows вышли на рынок.** Kiro, Spec Kit, amp - идея, что спецификации должны предшествовать реализации, уже не академична. 3. **Attestation infrastructure зреет.** SLSA, Sigstore, in-toto дают полезные примитивы для signed provenance. Key management и verifier trust остаются сложными проблемами, но building blocks существуют для команд, готовых инвестировать. Но нет стандартного открытого стека, собирающего spec gating, holdout governance и signed evidence в единый delivery pipeline, где gate - спецификация, а не diff. ## Что меняется Когда spec-gated delivery работает, code review перестает быть primary truth и становится вторичным аудитом. PR по-прежнему полезен - для knowledge sharing, обнаружения пробелов в спецификации, менторинга. Но решение о доверии сдвигается раньше: к моменту утверждения спецификации и запечатывания holdouts. Это главный сдвиг. Не "лучший AI review". Не "больше ревьюеров". Другая trust model целиком. Формула: ``` Утвержденный intent -> blinded execution -> deterministic verification -> signed evidence -> human/CI решение ``` Если evidence artifact говорит, что код соответствует утвержденной спецификации, включая holdout criteria, которые агент не мог видеть, и attestation chain цел - это более сильный сигнал, чем любое количество review comments. ## Попробуй Мы встроили это в [Signum](https://github.com/heurema/signum), плагин для Claude Code. Spec quality gate, holdout scenarios, multi-model audit, signed proofpack. Ранний и opinionated. ```bash claude plugin marketplace add heurema/emporium claude plugin install signum@emporium /signum "описание задачи" ``` Интересен не инструмент. Интересен вопрос: если бы ты мог гейтить каждое AI-сгенерированное изменение на pre-approved, детерминированно верифицированной спецификации - ставил бы ты PR review в центр trust model? ## Источники - [SLSA - Supply-chain Levels for Software Artifacts](https://slsa.dev/) - фреймворк целостности software supply chain - [in-toto - A framework for securing the software supply chain](https://in-toto.io/) - [Signum on GitHub](https://github.com/heurema/signum) - [The Contract Is the Context](/posts/en/signum-contract-first-ai-dev) - предыдущий пост о contract-first pipeline Signum - [skill7.dev/development/signum](https://skill7.dev/development/signum)https://ctxt.dev/posts/ru/signum-proofpack-ai-proof/https://ctxt.dev/posts/ru/signum-proofpack-ai-proof/Proofpack связывает контракт, реализацию и аудит в верифицируемую цепочку. Proof artifacts - недостающий примитив AI-кодогенерации.Thu, 05 Mar 2026 00:00:00 GMTAI сгенерировал функцию за секунды. Три модели провели ревью. Все сказали "выглядит хорошо". Вопрос: где артефакт, который это подтверждает? Не "модель одобрила" - где машиночитаемое свидетельство того, _что_ было проверено, _против чего_, и _с каким результатом_? В software supply chain такой артефакт называется attestation. Для AI-сгенерированного кода его не существует. ## Proofpack: что внутри Вот как выглядит `proofpack.json` после прогона [Signum](https://github.com/heurema/signum): ```json { "schemaVersion": "4.0", "createdAt": "2026-03-04T14:23:07Z", "runId": "signum-2026-03-04-a7f3c1", "decision": "AUTO_OK", "confidence": { "overall": 87 }, "auditChain": { "contractSha256": "e3b0c44298fc1c14...", "approvedAt": "2026-03-04T14:01:12Z", "baseCommit": "8a4f2dc" }, "contract": { "sha256": "a1b2c3d4...", "fullSha256": "f5e6d7c8...", "status": "present" }, "diff": { "sha256": "9f8e7d6c...", "sizeBytes": 4820, "status": "present" }, "checks": { "mechanic": { "status": "present" }, "holdout": { "status": "present" }, "reviews": { "claude": { "status": "present" }, "codex": { "status": "present" }, "gemini": { "status": "present" } } } } ``` Два хэша для контракта - `sha256` (редактированная версия без holdout-критериев) и `fullSha256` (оригинал). Базовый коммит зафиксирован до начала реализации. Три независимых ревью. Holdout-результаты - отдельно, потому что инженер их не видел. CI гейтит на этом: ```bash DECISION=$(jq -r '.decision' .signum/proofpack.json) if [ "$DECISION" != "AUTO_OK" ]; then echo "Signum: $DECISION - блокирую merge" exit 1 fi ``` Не нужно парсить логи трёх моделей. Один файл, одно поле, детерминированный гейт. ## Сломанное настоящее Индустрия AI code review сейчас работает на одном уровне - diff. Модель смотрит на патч и говорит, что думает. Проблема не в качестве моделей, а в отсутствии определения "корректно". CodeRabbit в своих собственных замерах[^1] показывает 46% полезных комментариев. Copilot Code Review в тесте на 117 файлах с известными уязвимостями не нашёл ни одной security-проблемы[^2]. Это не обвинение конкретных инструментов - это следствие архитектуры: ревью без контракта ограничено тем, что ревьюер считает "разумным". Проблема глубже. Даже если модель находит баг, результат - комментарий в PR. Не машиночитаемый артефакт, не цепочка верификации, не что-то, на чём CI может строить гейт. Между "модель оставила комментарий" и "код верифицирован" - пропасть. ## Четыре слоя: как собирается proofpack [В предыдущем посте](/posts/ru/signum-contract-first-ai-dev) я разбирал контракт как точку истины. Здесь - как четыре слоя вместе создают верифицируемый артефакт. **CONTRACT.** Спецификация формализуется до начала реализации. Оценивается по 6 измерениям (A-F). Codex и Gemini валидируют на пробелы. Генерируются holdout-сценарии - скрытые критерии приёмки, которые инженер не увидит. **EXECUTE.** Инженер работает с `contract-engineer.json`, из которого holdout-критерии физически удалены - не спрятаны инструкцией, а убраны из файла. Baseline (lint, typecheck, имена тестов) зафиксирован до первой строки кода. **AUDIT.** Механик - детерминированные проверки без LLM: линтер, тайпчекер, новые провалы тестов по имени (не по exit code). Затем Claude, Codex и Gemini проверяют diff независимо, параллельно, не видя оценок друг друга. Holdout-критерии запускаются против результата. Синтезатор агрегирует: детерминированная политика + confidence score. **PACK.** Все артефакты встраиваются в `proofpack.json`. SHA-256 связывает: одобренный контракт → временная метка → базовый коммит → diff → результаты аудита. Это не лог - это attestation. Ключевые решения: - **Ослепление на уровне данных**, не инструкций. Инженер не может вывести holdout-критерии из контекста или структуры файла. - **Мультимодельный аудит**: 3 вендора, 3 независимые оценки. Не одна модель проверяет саму себя. - **Воспроизводимые артефакты** для человека и CI, а не доверие к суждению модели. Proofpack существует как файл, его можно проверить, архивировать, подвергнуть аудиту. ## Модель угроз: что proofpack защищает и что нет **Защищает:** - Реализация не соответствует спецификации → holdout-критерии поймают - Rubber-stamp ревью (одна модель проверяет саму себя) → 3 независимых ревьюера - Нет аудиторского следа → SHA-256 цепочка с временными метками - Оптимизация под известные тесты → data-level blinding **Не защищает:** - Плохая спецификация. Garbage in - verified garbage out. Гейт качества (A-F) снижает риск, но не устраняет. - Сговор моделей. Теоретически возможен. 3 вендора (Anthropic, OpenAI, Google) смягчают, но не исключают. - Формальная корректность. Proofpack - это целостность процесса, не математическое доказательство. SLSA тоже не доказывает отсутствие багов - доказывает, что билд не был подменён. - Злонамеренный автор спецификации. Если человек намеренно прячет требования, система не поможет. Точнее: proofpack - не proof of correctness, а proof of process. Разница принципиальная. ## Смежные работы | Фреймворк | Что делает | Пробел | | -------------------------------- | --------------------------------- | ------------------------------------------------- | | [SLSA](https://slsa.dev) | Attestation провенанса сборки | Не знает про AI-кодогенерацию | | [in-toto](https://in-toto.io) | Layout цепочки поставок ПО | Только этап сборки, нет spec → code | | [Sigstore](https://sigstore.dev) | Подпись кода + transparency log | Идентичность, не корректность | | CodeRabbit | AI-ревью diff | Нет контракта, holdouts, proof artifact | | Copilot Code Review | AI-ревью PR | Diff-уровень, одна модель | | Qodo | AI-тестирование + compliance | Ближе, но без мультимодельного аудита и proofpack | | GitHub Spec Kit | Спецификация как вход для Copilot | Spec → code, но без цикла верификации | Что действительно ново: цепочка из четырёх слоёв - от спецификации через ослеплённое выполнение и состязательный аудит до tamper-evident артефакта. Ни один существующий инструмент не соединяет все четыре. ## Proof artifacts - недостающий примитив Индустрия software supply chain потратила годы на то, чтобы билды стали верифицируемыми. SLSA, in-toto, Sigstore - всё это про одно: не доверяй, верифицируй, и оставляй артефакт для аудита. AI-кодогенерация пока обходится без этого. Модель пишет код, другая модель оставляет комментарий в PR, человек нажимает merge. Ничего машиночитаемого не остаётся. Proofpack - одна реализация; паттерн важнее инструмента. [^1]: CodeRabbit, "How We Measure Review Quality", 2025. Self-reported metric из их блога. [^2]: Исследование Copilot Code Review на проекте с 117 файлами, содержащими известные уязвимости (SQL injection, XSS, command injection). Ни одна из уязвимостей не была отмечена. Результат зависит от конфигурации и выборки. ## Ссылки - [signum на GitHub](https://github.com/heurema/signum) - [Контракт - это контекст](/posts/ru/signum-contract-first-ai-dev) - предыдущий пост - [SLSA specification](https://slsa.dev/spec/v1.0/) - [in-toto framework](https://in-toto.io) - [Sigstore](https://sigstore.dev)https://ctxt.dev/posts/ru/herald-v2-local-news-intelligence/https://ctxt.dev/posts/ru/herald-v2-local-news-intelligence/Как я собрал 4-стадийный пайплайн новостей, который кластеризует статьи в истории по схожести заголовков - stdlib Python + SQLite.Wed, 04 Mar 2026 00:00:00 GMTЯ хотел, чтобы мой AI-агент знал, что происходит в технологиях - без облачных API, платных тарифов и утечки данных. Поэтому я сделал Herald: плагин для Claude Code, который собирает RSS и Hacker News, кластеризует связанные статьи в истории, скорит их и генерирует ранжированный Markdown-дайджест. v2 - полная переписка с нуля. Вот как это работает. ## Пайплайн Четыре стадии, каждая - отдельный Python-модуль: ``` RSS/Atom feeds ─┐ ├─→ articles ─→ stories (clustered) ─→ scored brief HN Algolia API ─┘ ``` **Collect** забирает данные через адаптеры (RSS, HN Algolia, опционально Tavily). Каждый источник изолирован - падение одного не блокирует остальные. **Ingest** дедуплицирует через каноникализацию URL (убирает трекинг-параметры, нормализует хосты, сортирует query params), делает UPSERT в SQLite, трекает кросс-источниковые упоминания и назначает топики по ключевым словам. **Cluster** группирует статьи в истории по схожести заголовков. Самая интересная часть - подробнее ниже. **Project** генерирует Markdown-дайджест с YAML frontmatter, истории сгруппированы по типу (release, research, tutorial, opinion, news), отсортированы по скору. ## Кластеризация: основной алгоритм Наивный подход - точное совпадение заголовков - пропускает очевидные группы. "Python 3.14 Released" и "Python 3.14 released with great new features" - одна история. Но "Python 3.13 Released" и "Python 3.14 Released" - нет. Я использую `difflib.SequenceMatcher` для схожести заголовков с 4 защитными фильтрами. Заголовки сначала нормализуются - приводятся к нижнему регистру, убираются префиксы "Show HN:", трейлинг `[pdf]`/`(video)`, лишние пробелы: ```python def _can_merge(article_title, story, db, cfg): # Guard 1: схожесть заголовка выше порога (default 0.65) ratio = SequenceMatcher(None, norm_a, norm_s).ratio() if ratio < cfg.threshold: return False # Guard 2: статьи в пределах временного окна if abs(article_collected - story_last_updated) > max_gap: return False # Guard 3: оба заголовка должны быть достаточно длинными if len(words_a) < cfg.min_title_words: return False # Guard 4: конфликт версий/номеров nums_a = set(re.findall(r"\d+(?:\.\d+)*", norm_a)) nums_s = set(re.findall(r"\d+(?:\.\d+)*", norm_s)) if nums_a and nums_s and nums_a != nums_s: return False return True ``` Guard 4 - ключевой инсайт. Без него SequenceMatcher радостно мерджит "Python 3.13 Released" (ratio 0.88) с "Python 3.14 Released". Конфликт номеров версий ловит это - разные версии значат разные истории. ### Переизбрание канонической статьи У каждой истории есть каноническая статья - та, чей заголовок показывается в дайджесте. Когда статья с более высоким скором присоединяется к истории, она заменяет каноническую - но только если обгоняет текущую на настраиваемую дельту (гистерезис). Это предотвращает постоянные переключения при близких скорах. ```python canonical_delta = cfg.canonical_delta # default 0.1 if article_score > current_canonical_score + canonical_delta: new_canonical = article_id ``` ## Скоринг Два уровня: статьи и истории. Скор статьи комбинирует вес источника, очки HN (линейно масштабированные, cap 3.0), плотность ключевых слов и буст для релизов: ```python def article_score_base(source_weight, points, keyword_density, is_release): return ( source_weight + min(points / 500, 3.0) + keyword_density * 0.2 + (0.2 if is_release else 0.0) ) ``` Скор истории - максимальный скор статьи плюс покрытие (логарифм количества источников) и бонус momentum за свежую активность: ```python def story_score(max_article_score, source_count, has_recent): coverage = math.log(max(source_count, 1)) * 0.3 momentum = 0.2 if has_recent else 0.0 return max_article_score + coverage + momentum ``` Истории, покрытые несколькими источниками, ранжируются выше. История из HN + RSS + блог более значима, чем из одного фида. ## Модель данных SQLite с 8 таблицами. Ключевые связи: ``` sources → articles → mentions (cross-source tracking) → article_topics → story_articles → stories → story_topics ``` Каноникализация URL выполняется перед INSERT - убирает `utm_*`, `fbclid`, `ref`, нормализует `www.`, сортирует query params, апгрейдит HTTP на HTTPS. Две статьи из разных источников на один URL дедуплицируются при ingest, второй источник записывается как упоминание. ## Как выглядит результат ```markdown --- generated_at: 2026-03-04T12:48:51Z story_count: 25 period_hours: 24 --- ## News ### MacBook Pro with M5 Pro and M5 Max 2.11 · 1 source - [MacBook Pro with M5 Pro and M5 Max](https://apple.com/newsroom/...) ### TikTok will not introduce end-to-end encryption 1.06 · 1 source - [TikTok will not introduce...](https://bbc.com/news/articles/...) ``` Истории сгруппированы по типу, отсортированы по скору. Каждая история показывает свои статьи со ссылками на оригинальные источники. ## Интерфейс плагина Herald - плагин для Claude Code. Семь slash-команд, один хук: ``` /news-init → создаёт ~/.herald/ с конфигом + SQLite DB /news-add <url> → автоматически находит RSS, добавляет в конфиг /news-run → запускает полный пайплайн /news-digest → выводит последний дайджест с гайдом по анализу /news-status → количество статей/историй + время последнего запуска ``` Хук `SessionStart` проверяет наличие свежего дайджеста (< 24ч) и подсказывает агенту прочитать его. Агент видит "Fresh news digest available" при старте сессии - никаких ручных триггеров. ## Дизайн-решения **stdlib вместо зависимостей.** Алгоритм кластеризации использует `difflib.SequenceMatcher` - без numpy, sklearn, embedding-моделей. Для новостных заголовков (короткие строки, один язык) посимвольная схожесть работает достаточно хорошо и за микросекунды. **SQLite вместо файлов.** v1 использовал JSONL и flat-file дедупликацию. v2 - SQLite с foreign keys, FTS5 для полнотекстового поиска и WAL mode. Один файл, ACID-транзакции, `ON CONFLICT` для идемпотентных UPSERT. **Монотонные таймстампы.** Когда поздно пришедшая старая статья присоединяется к истории, `last_updated` не должен регрессировать. Фикс: `max(current_last_updated, article_collected_at)`. Нашёл этот баг при [мультимодельном код-ревью](https://github.com/heurema/signum), где Claude, Codex и Gemini независимо аудитили один diff. **Изоляция пайплайна.** Каждый адаптер collect работает в своём try/except. Таймаут одного RSS-фида не блокирует HN. Статус пайплайна записывается в таблицу `pipeline_runs` (включая ошибки) - всегда знаешь, что произошло. ## Цифры - 174 теста, 0.7с на M-series Mac - ~1200 строк Python в 10 модулях - 0 внешних AI API вызовов - Реальный E2E тест: 2 источника (HN + RSS) → 45 статей → 27 историй → скоринг + дайджест за 3 секунды ## Попробуй ```bash claude plugin marketplace add heurema/emporium claude plugin install herald@emporium /news-init /news-run ``` Исходники: [github.com/heurema/herald](https://github.com/heurema/herald) Нашёл баг? Все плагины heurema поставляются с [Reporter](https://github.com/heurema/reporter) - файлишь issue не выходя из Claude Code: ``` claude plugin install reporter@emporium /report bug ``` Reporter автоматически определяет продукт, собирает контекст окружения и отправляет через `gh` CLI.https://ctxt.dev/posts/ru/signum-contract-first-ai-dev/https://ctxt.dev/posts/ru/signum-contract-first-ai-dev/Почему прогнать AI-код через ещё больше AI-ревьюеров не решает проблему надёжности — и что меняет подход contract-first.Tue, 03 Mar 2026 00:00:00 GMTМожно прогнать AI-diff через три модели и всё равно не иметь точки истины. Они скажут что выглядит "разумно", а не что корректно. Модель отказа не в "плохом коде". Она в нефальсифицируемом намерении: требование так и не стало чем-то, что можно запустить. Вы одобрили реализацию, удовлетворяющую вашим допущениям. Граничные случаи, которые вы не потрудились специфицировать, не были пойманы — потому что ловить было не против чего. Два месяца спустя приходит баг-репорт. Это проблема контекстной инженерии. ## Недостающий слой контекста У каждого процесса верификации нужно две вещи: артефакт, который проверяется, и стандарт, относительно которого он проверяется. Современное код-ревью сильно с первым и слабо со вторым. "Стандарт" живёт в голове ревьюера — восстановленный из описания задачи, комментариев и окружающего кода. Неявный, неполный, ни с кем не разделённый. Контекстная инженерия — это превращение неявного контекста в явный. Для верификации это означает: стандарт должен существовать _до_ начала реализации, а не после. Контракт — это контекст. Без него всякое ревью — это интерпретация. ## Signum: контракт как точка истины [Signum](https://github.com/heurema/signum) — плагин для Claude Code, реализующий четырёхфазный пайплайн: ``` CONTRACT → EXECUTE → AUDIT → PACK ``` **CONTRACT** идёт первым. Вы описываете задачу на естественном языке. Агент-контрактор (Claude Sonnet) формализует её в `contract.json`: ```json { "goal": "Добавить rate limiting на POST /api/tokens — макс. 5 запросов в минуту на IP", "acceptanceCriteria": [ { "id": "AC1", "description": "Запросы сверх лимита возвращают 429 с заголовком Retry-After", "verify": "pytest tests/test_rate_limit.py -k test_429_response", "holdout": false }, { "id": "AC2", "description": "Счётчик rate limit сбрасывается после истечения окна", "verify": "pytest tests/test_rate_limit.py -k test_window_reset", "holdout": true } ], "inScope": ["src/api/tokens.py", "tests/test_rate_limit.py"], "riskLevel": "medium" } ``` Спецификация оценивается по шкале A–F по шести измерениям (тестируемость, покрытие негативных сценариев, ясность, область, полнота, граничные случаи). Оценка D — жёсткая остановка: пайплайн не продолжается, пока спецификация не станет верифицируемой. **EXECUTE**: Агент-инженер получает `contract-engineer.json` — контракт с физически удалёнными критериями `holdout: true`. Он реализует против видимой спецификации. Оптимизировать под то, чего не видишь, невозможно. **AUDIT**: Механик (детерминированный, без LLM) запускает lint, typecheck и тесты относительно pre-реализационного baseline. Затем Claude, Codex и Gemini независимо проверяют diff параллельно. Holdout-критерии — `AC2` в примере выше — запускаются против готового результата. Если инженер забыл сбросить счётчик после истечения окна, это поймается здесь, автоматически, против критерия, который он никогда не видел. **PACK**: `proofpack.json` — SHA-256 контракта, временная метка одобрения, базовый коммит, diff, результаты аудита. CI строит гейты на нём. ## Что блокирует Signum До начала реализации Signum отклоняет: - Критерии приёмки без команды `verify` (нельзя проверить = не критерий) - Размытую область ("измени auth-модуль" без конкретных файлов) - Рискованные допущения, выявленные внешними валидаторами (Codex + Gemini проверяют спецификацию на пробелы) - Спецификации с оценкой ниже D — недостаточные граничные случаи, покрытие негативных сценариев, ясность После реализации AUTO_BLOCK при: - Нарушениях политики (слишком много изменённых файлов, запрещённые bash-паттерны в diff) - Регрессиях инвариантов репозитория (если `pytest -q` проходил до — должен проходить после) - Провале holdout-сценариев ## Инварианты на уровне репозитория: постоянный контракт Контракты уровня задачи покрывают то, что вы строите сейчас. `repo-contract.json` — то, что должно выполняться всегда: ```json { "invariants": [ { "id": "I-1", "description": "All tests pass", "verify": "pytest -q", "severity": "critical" }, { "id": "I-2", "description": "No type errors", "verify": "mypy src/", "severity": "critical" } ], "owner": "human" } ``` Signum фиксирует baseline до EXECUTE, перезапускает после. Любая регрессия — AUTO_BLOCK, вне зависимости от результатов уровня задачи. Поле `"owner": "human"` объявляет этот файл человеческим артефактом. AI enforces; человек определяет. ## Цепочка аудита При одобрении пользователем Signum хэширует `contract.json` (SHA-256) и фиксирует временную метку. До запуска инженера записывается базовый коммит. Итоговый proofpack связывает: одобренный контракт → базовый коммит → diff реализации → результаты аудита. Нельзя задним числом заменить контракт и заявить, что proofpack был построен против него. Это важно по мере того, как AI-сгенерированный код всё чаще требует провенанса. Не "AI написал это" — "AI реализовал это против _этого_ контракта, валидированного до реализации, с _этими_ результатами аудита." ## Установка ```bash # Добавить маркетплейс (один раз) claude plugin marketplace add heurema/emporium # Установить Signum claude plugin install signum@emporium # Опционально: внешние CLI для мультимодельного аудита # https://github.com/openai/codex # https://github.com/google-gemini/gemini-cli ``` Затем: ``` /signum "добавить rate limiting на API endpoint" ``` Signum оценивает спецификацию, показывает контракт на одобрение, запускает инженера с удалёнными holdouts, проводит аудит с нескольких сторон и создаёт `proofpack.json`. ## Статус **Работает сейчас:** четырёхфазный пайплайн, гейт качества спецификации, holdout-сценарии, инварианты репозитория, цепочка аудита, proofpack. **Требует:** Claude Code v2.1+, `git`, `jq`, `python3`. Мультимодельный аудит дополнительно требует [Codex CLI](https://github.com/openai/codex) и [Gemini CLI](https://github.com/google-gemini/gemini-cli) — Signum деградирует корректно при отсутствии любого из них. **В процессе изменений:** схемы артефактов (proofpack, contract) будут меняться. Суждение контрактора о качестве holdout улучшается с использованием. Мы запускаем Signum на собственной разработке Signum. v3 — первая версия, на которую мы готовы ставить в своих проектах. ## Обратная связь Signum молодой и активно разрабатывается. Если он блокирует некорректно, упускает граничный случай или оценка спецификации кажется неправильной — можно сообщить прямо из Claude Code, без переключения контекста. Установите [Reporter](https://github.com/heurema/reporter): ```bash claude plugin install reporter@emporium ``` Затем: `/report bug` или `/report feature` или `/report question` Reporter автоматически определяет, что вы работаете с продуктом heurema, прикрепляет контекст среды (ОС, оболочка, версия Claude Code), показывает предпросмотр перед отправкой и падает обратно на буфер обмена, если `gh` недоступен. ## Ссылки - [signum на GitHub](https://github.com/heurema/signum) - [skill7.dev/development/signum](https://skill7.dev/development/signum) - [emporium — маркетплейс плагинов](https://github.com/heurema/emporium) - [reporter — отчёты из Claude Code](https://github.com/heurema/reporter) - [11 плагинов, один маркетплейс: построение экосистемы AI-инструментов](/posts/ru/heurema-ecosystem)https://ctxt.dev/posts/ru/heurema-ecosystem/https://ctxt.dev/posts/ru/heurema-ecosystem/Как я построил экосистему плагинов для Claude Code — от разрозненных скриптов до полного жизненного цикла со скаффолдингом, quality gates, мульти-AI ревью и установкой одной командой.Mon, 02 Mar 2026 00:00:00 GMT## Проблема Инструменты для AI-агентов разбросаны. Сниппет в CLAUDE.md тут, bash-скрипт там, команда скопирована из чужого репо без версии, без тестов, без возможности проверить, что она делает то, что заявлено. Каждый инструмент живёт изолированно. Нет жизненного цикла: создать, протестировать, опубликовать, найти, установить. Нет доверия: вставляешь skill из интернета и надеешься, что он не нагаллюцинирует свой путь через кодовую базу. Я раз за разом упирался в одну и ту же стену: создавал полезную команду для Claude Code, потом нуждался в ней в другом проекте. Копипаст. Дрифт. Через два месяца — три несовместимые копии. Корневая проблема не в каком-то конкретном инструменте, а в отсутствии инфраструктуры вокруг них. ## Контекст У Claude Code есть система плагинов. Манифест `plugin.json`, структура каталогов `.claude-plugin/`, регистрация в маркетплейсе через `marketplace.json`. Примитивы на месте: skills, commands, hooks, agents, MCP-серверы. Anthropic построил рантайм. Не хватает инструментального слоя поверх. Этот разрыв знаком из каждой экосистемы: npm существовал до create-react-app. PyPI существовал до cookiecutter. Пакетный менеджер появляется первым, developer experience — позже. Claude Code сейчас в этой фазе «позже». [heurema](https://github.com/heurema) — попытка заполнить этот разрыв. Философия: «Craft, not conjuring» — ремесло, а не колдовство. Стандартная библиотека вместо зависимостей, quality gates перед публикацией, никакой магии. Каждый плагин проходит `ruff + mypy --strict + pytest` перед выпуском. Если его нельзя протестировать — он не выходит. ## Решение — Экосистема ### Маркетплейс: emporium [emporium](https://github.com/heurema/emporium) — единая точка входа. Одна команда для добавления маркетплейса, одна команда на плагин: ```bash # Добавить маркетплейс (один раз) claude plugin marketplace add heurema/emporium # Установить любой плагин claude plugin install signum@emporium claude plugin install herald@emporium claude plugin install arbiter@emporium ``` Под капотом — `marketplace.json`, маппящий имена плагинов на их GitHub-репо. Никакого сервера реестра, никакой аутентификации, никакого билд-степа. Git-репо от начала до конца. Сейчас 11 плагинов в четырёх категориях: pipeline разработки, продуктивность, торговые сигналы и креативные инструменты. ### Pipeline разработки Четыре плагина покрывают полный цикл от «у меня есть задача» до «отревьюено, протестировано, отправлено». **[signum](https://github.com/heurema/signum)** — Evidence-driven pipeline разработки. Берёт описание задачи и прогоняет через четыре фазы: CONTRACT (фиксация скоупа) -> EXECUTE (реализация с repair loop) -> AUDIT (параллельный мульти-модельный ревью) -> PACK (генерация артефактов). Самая интересная часть — фаза аудита: Claude Opus, Codex и Gemini ревьюят diff независимо. Критические находки от любой модели блокируют мерж. Важные находки требуют согласия 2+ моделей. Каждая AI-находка валидируется против реального diff — если модель ссылается на строку, которой не существует, находка отбрасывается как галлюцинация. ```bash /signum"Добавить rate limiting к API-эндпоинту" ``` **[arbiter](https://github.com/heurema/arbiter)** — Мульти-AI оркестратор. Маршрутизирует задачи в Codex CLI и Gemini CLI изнутри Claude Code. Режим `panel` запускает оба параллельно и форматирует сравнение бок о бок. Режим `quorum` проводит формальное двухраундовое голосование (APPROVE/BLOCK/NEEDS_INFO) с детерминированной политикой и adversarial tiebreaker. Режим `diverge` — самый необычный: три независимые реализации в изолированных git worktrees с разными стратегическими подсказками (minimal, refactor, redesign), представленные как анонимизированная матрица решений. ```bash /arbiter panel "WebSockets или SSE для real-time обновлений?" /arbiter quorum "Безопасно ли запускать эту миграцию в продакшене?" /arbiter diverge "Реализовать слой кэширования" ``` **[anvil](https://github.com/heurema/anvil)** — Dev/test-тулкит для плагинов. Скаффолдит новые плагины из шаблонов, запускает 6-уровневую валидацию (schema, structure, hooks, conventions, consistency, install docs), тестирует хуки с фикстурами. Включает AI-агента для код-ревью, который проверяет по чеклисту из 21 пункта и возвращает APPROVE или REQUEST CHANGES. ```bash /anvil:new my-plugin /anvil:check ./my-plugin /anvil:test ./my-plugin ``` **[forge](https://github.com/heurema/forge)** — Менеджер жизненного цикла плагинов. Где anvil фокусируется на dev/test, forge управляет полным циклом: скаффолдинг из Jinja2-шаблонов, верификация quality gates, регистрация и в workspace registry, и в маркетплейсе emporium. Пять команд, покрывающих путь от `forge-new` до `forge-register`. ```bash /forge-new awesome-plugin /forge-verify /forge-register ``` ### Продуктивность **[herald](https://github.com/heurema/herald)** — Ежедневный новостной дайджест. Ноль API-ключей, полностью локальный. Настраивает RSS-фиды по теме (ai-engineering, rust, devops, security и т.д.), забирает из RSS + Hacker News, прогоняет 3-уровневую дедупликацию (хеш URL, нормализация, схожесть заголовков), скорит по релевантности ключевых слов и доставляет топ-10 историй прямо в Claude Code. SessionStart-хук уведомляет, когда свежий дайджест готов. ```bash /news init ai-engineering /news digest ``` **[reporter](https://github.com/heurema/reporter)** — Репортер багов и фич. Автоматически определяет, с каким heurema-продуктом вы работаете (через git remote, plugin.json или pyproject.toml), проводит через сфокусированный шаблон issue, молча прикрепляет контекст окружения (OS, shell, версия Claude Code) и отправляет через `gh` CLI. Если `gh` недоступен — копирует тело issue в буфер обмена и выводит GitHub URL. ```bash /report bug /report feature ``` ### Торговые сигналы **[oracle](https://github.com/forgequant/oracle)** — Сигналы волатильности опционов. Забирает данные с Deribit (API-ключи не нужны для публичных данных) и вычисляет: risk reversal (перекос IV), put/call ratio, DVOL-модификатор, соотношение срочной структуры. На выходе — взвешенный direction score с формулой уверенности, которая деградирует при высокой волатильности или backwardation. Кэширует снапшоты с затуханием свежести. ```bash /deribit --asset BTC ``` **[sentinel](https://github.com/forgequant/sentinel)** — Агрегатор сентимента. Четыре независимых источника в унифицированном формате сигнала: индекс Fear & Greed (с z-score за 30 дней и перцентилем за 90 дней), сканер новостей CryptoPanic + RSS, предсказательные рынки Polymarket и social intelligence LunarCrush. Первые три работают без API-ключей; LunarCrush — опциональный premium-апгрейд. ```bash /feargreed /polymarket /news-scanner ``` ### Креативные инструменты **[genesis](https://github.com/heurema/genesis)** — Меметический алгоритм для стартап-идей. Три AI-персоны (генератор, критик, арбитр) проводят эволюционные раунды: GENERATE -> CRITIQUE -> SELECT -> REFINE. Восемь измерений скоринга с четырьмя стратегиями (bootstrapper, growth, moat, uniform). Жёсткие ограничения (бюджет, сроки, навыки, solo-mode) отсекают нежизнеспособные идеи до затратного этапа refinement. Свежие variate-инъекции на раунде 2+ предотвращают конвергенцию. ```bash /genesis "Инструменты продуктивности для разработчиков" --rounds 3 --strategy bootstrapper ``` **[glyph](https://github.com/heurema/glyph)** — Генератор демо-GIF для терминала. Описываешь, что хочешь показать в демо, и он генерирует синтетическую asciicast-запись с реалистичным таймингом набора — никакие реальные команды не выполняются. Встроенный PII-аудит блокирует вывод, содержащий домашние пути, email, API-ключи или секреты. Seeded RNG для воспроизводимости. Темы: Monokai по умолчанию и amber retro CRT. ```bash /glyph "Показать установку плагина и запуск первой команды" ``` ### Справочник **[teams-field-guide](https://github.com/heurema/teams-field-guide)** — Полевое руководство по мульти-агентным системам Claude Code. Семь паттернов оркестрации, конфигурация кастомных агентов, оптимизация стоимости через распределение моделей, известные баги с воркараундами и покрытие 26+ проектов экосистемы. Не плагин в традиционном смысле — это документация, распространяемая как плагин ради дискавери. ### Quality Gates Каждый плагин в экосистеме проходит одни и те же гейты: - **ruff** — линтинг и форматирование - **mypy --strict** — полная типизация - **pytest** — покрытие тестами - **forge verify** — pre-publish quality gate (структура, манифест, конвенции) - **anvil check** — 6-уровневая валидация с JSON-отчётом - **signum audit** — adversarial мульти-модельный ревью для нетривиальных изменений Pipeline forge -> anvil -> signum означает, что плагин валидируется на трёх уровнях до попадания в маркетплейс: соответствие жизненному циклу, структурная корректность и качество кода под adversarial ревью. ## Инсайт Экосистемы плагинов дают compound-эффект. herald доставляет новости, которые информируют торговые решения с сигналами oracle и sentinel. reporter фиксирует баги, найденные в ходе ревью signum. forge скаффолдит новые плагины, которые anvil валидирует. Каждый инструмент делает остальные полезнее. Настоящий moat — не в отдельном плагине. Он в жизненном цикле: `forge-new` -> разработка -> `anvil:check` -> `forge-verify` -> `forge-register` -> доступен в emporium. Любой отдельный инструмент можно повторить. Pipeline, связывающий их, скопировать сложнее, потому что он кодирует решения о качестве, доверии и дистрибуции. У open source AI-тулинга проблема с доверием. Любой может опубликовать skill, который заявляет «оптимизирует вашу кодовую базу». Правда ли? Тестировался ли он? Проходит ли проверку типов? Ревью автоматизировано или «на вайбах»? Ответ для большинства инструментов сегодня: неизвестно. Ставка за heurema в том, что инфраструктура доверия — quality gates, adversarial review, верифицированные манифесты — важнее любого отдельного умного промпта. Одиннадцать плагинов, один маркетплейс, ноль API-ключей для основных инструментов. Это точка старта, а не финиша. ## Источники - [emporium — Маркетплейс плагинов](https://github.com/heurema/emporium) - [signum — Pipeline разработки](https://github.com/heurema/signum) - [arbiter — Мульти-AI оркестратор](https://github.com/heurema/arbiter) - [anvil — Dev-тулкит для плагинов](https://github.com/heurema/anvil) - [forge — Менеджер жизненного цикла](https://github.com/heurema/forge) - [herald — Новостной дайджест](https://github.com/heurema/herald) - [reporter — Репортер багов/фич](https://github.com/heurema/reporter) - [oracle — Сигналы волатильности опционов](https://github.com/forgequant/oracle) - [sentinel — Стек сентимента](https://github.com/forgequant/sentinel) - [genesis — Меметическая идеация](https://github.com/heurema/genesis) - [glyph — Демо-GIF для терминала](https://github.com/heurema/glyph) - [teams-field-guide — Гайд по мульти-агентам](https://github.com/heurema/teams-field-guide) - [skill7.dev — Каталог плагинов](https://skill7.dev)https://ctxt.dev/posts/ru/skillsbench-agent-skills/https://ctxt.dev/posts/ru/skillsbench-agent-skills/Разбираем SkillsBench — первый систематический бенчмарк для Agent Skills. 7308 траекторий, критический анализ, и почему skills — это context engineering для агентов.Mon, 23 Feb 2026 00:00:00 GMT## Проблема Все, кто работает с агентами, пишут Agent Skills — CLAUDE.md, .cursorrules, системные промпты с инструкциями. Кто-то 50 строк, кто-то 500. Кто-то добавляет примеры, кто-то обходится текстом. До февраля 2026 года не было ни одной работы, которая систематически измерила бы, работают ли они вообще. SkillsBench (Li et al., arXiv:2602.12670) — первая попытка. 84 задачи, 11 доменов, 7308 траекторий. Главный вопрос: скиллы помогают, мешают, или бесполезны? ## Контекст Дизайн бенчмарка: три условия для каждой задачи — без скиллов, с кураторскими скиллами (написанными людьми), и с самосгенерированными скиллами (написанными самой моделью). Семь конфигураций агент-модель: Claude Code, Gemini CLI, Codex CLI с разными моделями. Заголовок пейпера: правильные скиллы дают +16.2 процентных пункта. Звучит убедительно. Но наш trust assessment после разбора: **6/10 (MEDIUM-LOW)**. Вот почему. ## Решение ### Что надёжно (высокий консенсус) **1. В этом бенчмарке самосгенерированные скиллы бесполезны.** Среднее: -1.3pp. Это самый робастный результат в пейпере — подтверждён независимо всеми методами анализа. Модели не могут писать себе эффективные процедурные инструкции. Они могут описать задачу, но не создать руководство, которое улучшит их собственное выполнение. Данные совпадают с подходом human-curated skills. Не автогенерация, не рефлексия — человек должен написать, как именно решать задачу. **2. 2-3 скилла лучше, чем 4 и больше.** Корреляционная зависимость, но Codex CLI подтвердил независимо: context dilution реальна. Больше скиллов — больше шума, конфликтующие инструкции, агент начинает игнорировать контекст вместо того, чтобы его использовать. **3. Detailed > Comprehensive.** Краткие пошаговые инструкции с одним рабочим примером — лучше исчерпывающей документации. Comprehensive скиллы (полное покрытие всех кейсов) активно вредят: -2.9pp. Это контринтуитивно, но объяснимо: длинный контекст с большим количеством условий снижает фокус на главном. **4. Зависимость от домена.** Healthcare: +51.9pp. Software Engineering: +4.5pp. Чем слабее покрытие домена в pretrained knowledge модели, тем больше выигрыш от скиллов. В хорошо изученных областях скиллы почти не помогают. ### Почему headline +16.2pp — не для вас **Selection bias**: бенчмарк использует только top-25% скиллов из экосистемы — те, что получили ≥9/12 баллов при среднем по экосистеме 6.2/12. Если у вас средние скиллы (а у большинства именно такие), реалистичная оценка: +5-10pp, не +16. **Harness confounding**: Claude Code обучен на Agent Skills спецификации. Нельзя разделить "скилл действительно помог" и "модель обучена следовать этому формату". +23.3pp у Claude может быть на 50%+ эффектом тренировки, а не качества скилла. **Нет бейзлайнов**: никто не сравнил скиллы с RAG, few-shot примерами, обычной документацией того же объёма или length-matched контролем. Непонятно, работают ли скиллы _сами по себе_ или любой дополнительный контекст той же длины дал бы похожий результат. **Ecological validity**: контейнер, только терминал, одна сессия. Реальные workflow — multi-agent, multi-session, часто с IDE. Неизвестно, переносятся ли результаты. ### Наш эксперимент Проверили один из вопросов пейпера на практике: sonnet+skills vs opus на code review. Задача: ревью коммита argus P3 (b094d77), 925 строк, Python/Bash/MD, 12 файлов изменено. ``` Sonnet + code-review skill Opus (raw) Findings total 7 13 Critical (всего) 3 1 Security-critical 2 0 Convention violations 1 0 Cost ~$0.15 ~$0.70 ``` Ключевой результат: sonnet+skills нашёл 2 критических path traversal уязвимости (pool_dir, case_id), которые opus пропустил. Оба нашли общий race condition (PID write after mkdir). Sonnet дополнительно поймал нарушение CLAUDE.md конвенции — осведомлённость из скилла. Opus нашёл больше breadth: DRY-нарушения, missing session log, release ownership. Но пропустил security-critical баги. Вывод: sonnet+skills достаточен для quality gates на code review. 5x дешевле, лучше фокус на безопасности. Opus остаётся для архитектурных решений и финальной синтетизации. ## Инсайт Skills — это context engineering для агентов. Не магия, не автоматизация, не документация. Инженерия контекста. Те же принципы, которые работают для RAG и prompt design, работают здесь: - Структура важнее объёма (Detailed > Comprehensive — как релевантный чанк важнее большого документа) - 2-3 фокусных источника лучше свалки (context dilution — реальная проблема и в retrieval) - Human curation незаменима (модели не могут структурировать свой контекст — так же, как плохой chunking убивает RAG) - Domain targeting: там, где у модели меньше претренировочных знаний, больше выигрыш от внешнего контекста Пейпер — важная первая работа. Scale серьёзный: 7308 траекторий — это данные. Но к headline numbers нужно относиться критично. Реальный вывод: правильно написанные скиллы помогают, плохо написанные — вредят. Как и любой контекст. ## Источники - [SkillsBench — Li et al., arXiv:2602.12670](https://arxiv.org/abs/2602.12670) - [Anthropic Sonnet 4.6](https://www.anthropic.com/news/claude-sonnet-4-6) - [Anthropic Opus 4.6](https://www.anthropic.com/claude/opus)https://ctxt.dev/posts/ru/git-not-for-agents/https://ctxt.dev/posts/ru/git-not-for-agents/Почему git ломает AI-агентов и как jj решает каждую из этих проблемThu, 19 Feb 2026 00:00:00 GMT## Проблема Git создавался для людей. Интерактивный rebase, staging area, detached HEAD — всё это предполагает человека за терминалом, который понимает контекст и может принять решение. AI-агент — не человек. Он не может ответить на вопрос `rebase --continue`. Не может выбрать файлы в `git add -i`. Не может осмысленно разрешить merge-конфликт в середине длинной операции. Реальные инциденты: Claude Code потерял 4 дня работы из-за `reset --hard` (issue #11237). Codex уничтожил 9 файлов одной командой (issue #8643). Copilot сдаётся при ошибке pre-commit hook вместо того чтобы исправить проблему. ## Контекст Проблема глубже чем кажется. Git — это не просто неудобный инструмент для агентов. Это инструмент с фундаментально неправильными абстракциями для автоматизации. Staging area. Для человека — удобная промежуточная зона. Для агента — лишний шаг, который ничего не даёт и создаёт состояние "частично добавлено". Деструктивные команды без подтверждения. `git checkout .` уничтожает все незакоммиченные изменения. Без вопросов. Человек знает что делает. Агент выполняет команду из привычного паттерна — и теряет работу. Конфликты блокируют workflow. Когда два параллельных агента работают в одном репозитории, merge-конфликты останавливают обоих. Ни один не может продолжить пока конфликт не разрешён. Хуки ломают автоматизацию. Pre-commit hook с линтером? Агент получает ошибку, не может закоммитить, и часто не понимает как исправить проблему в рамках hook-скрипта. ## Решение jj (Jujutsu) — VCS нового поколения от Google. Работает поверх git-бэкенда (colocated mode), но с радикально другой моделью. **Рабочая копия = коммит.** Каждое сохранение файла — уже в истории. Потерять незакоммиченную работу невозможно в принципе. ```bash # В git: забыл закоммитить → reset --hard → работа потеряна # В jj: рабочая копия — это коммит. Всегда. jj log # видим все изменения, включая текущие ``` **Operation log — полная история операций.** Каждое действие в jj записывается. Откатить любую операцию на любую глубину — одна команда. ```bash jj op log # история всех операций jj undo # откатить последнюю jj op restore <id> # откатить на любую точку ``` **Конфликты — это данные, а не блокировка.** jj записывает конфликт прямо в коммит. Работа продолжается. Конфликт разрешается когда удобно, а не когда git заставляет. **Нет staging area.** Нет `git add`. Все изменения автоматически в текущем коммите. Один шаг вместо двух. **Всё неинтерактивное.** Никаких промптов, никакого `--continue`, никаких редакторов. Каждая команда — атомарная операция с предсказуемым результатом. **Workspaces для параллельных агентов.** `jj workspace add` создаёт изолированное рабочее пространство с общим графом коммитов. Два агента работают параллельно без конфликтов. ```bash jj workspace add ../agent-workspace-2 # Два агента, два workspace, один репозиторий # Каждый видит коммиты другого, но не мешает ``` **Colocated mode — нулевой риск.** `jj git init --colocate` на любом существующем git-репозитории. Git и jj работают бок о бок. Команда продолжает использовать git, агенты используют jj. ## Инсайт Инструменты разработки создавались для человеческого удобства. Интерактивность, гибкость, визуальная обратная связь — всё это мешает автоматизации. Для AI-агентов нужны другие свойства: атомарность операций, полный undo, предсказуемость без диалога, безопасность при параллельной работе. jj покрывает 7 из 11 свойств идеальной VCS для агентов. Оставшиеся четыре (semantic diff, content-addressing, agent metadata, sandbox-first) пока не реализованы ни в одном инструменте. Не нужно ждать идеального решения. `jj git init --colocate` — одна команда, и каждый git-репозиторий становится безопаснее для агентов уже сегодня. ## Источники - [Jujutsu VCS](https://jj-vcs.github.io/jj/) - [Claude Code Issue #11237](https://github.com/anthropics/claude-code/issues/11237) - [Codex Issue #8643](https://github.com/openai/codex/issues/8643) - [agentic-jujutsu](https://github.com/agentic-jujutsu)https://ctxt.dev/posts/ru/agent-friendly-web/https://ctxt.dev/posts/ru/agent-friendly-web/Как формат подачи контента определяет, увидит ли его AI-агент. Данные исследований, реальные стандарты и что делать прямо сейчас.Wed, 18 Feb 2026 00:00:00 GMT## Проблема AI-агенты стали новыми читателями веба. GPTBot вырос на 305% за год. AI-краулеры генерируют трафик, сопоставимый с Google. Но большинство сайтов построены так, как будто их единственные клиенты — люди с браузерами. Результат: на бенчмарке WebArena лучший GPT-4-агент решает 14.4% задач на реальных сайтах. Люди — 78%. Агенты захлёбываются в HTML, теряются в JavaScript-рендеринге и не могут извлечь структуру из визуального шума. Это не проблема моделей. Это проблема контента. ## Контекст Один и тот же блог-пост — 16,180 токенов в HTML и 3,150 в Markdown. Разница в 5 раз. Для агента, который платит за каждый токен и имеет ограниченное контекстное окно, это разница между «вижу» и «не влезает». Но дело не только в размере. Исследование HtmlRAG (WWW 2025) показало неожиданное: HTML с семантическими тегами (`<h2>`, `<table>`, `<code>`) превосходит plain text в RAG-системах. Конверсия в чистый текст уничтожает структурную информацию, которая помогает модели ориентироваться. Не «больше текста», а «правильная структура». Ещё один сюрприз: формат подачи меняет точность модели до 40%. GPT-3.5 предпочитает JSON, GPT-4 — Markdown. Универсального «лучшего» формата нет — есть формат, подходящий конкретной модели и задаче. Это буквально context engineering. Те же принципы, которые мы применяем к промптам — структура важнее объёма, формат влияет на результат, семантика побеждает сырые данные — теперь нужно применять к веб-контенту. И мир это осознал. За 2025 год стандартизация агентного веба взорвалась: IETF создал рабочую группу AIPREF для стандартизации AI-предпочтений в HTTP-заголовках. W3C запустил три Community Group по агентным протоколам. Linux Foundation учредил Agentic AI Foundation с участием AWS, Anthropic, Google, Microsoft и OpenAI. ## Решение ### Accessibility = Agent-friendliness Самая неожиданная находка. Агенты, работающие через accessibility tree (семантический HTML, ARIA-метки), успешно выполняют ~85% задач. Агенты на основе скриншотов — ~50%. Одни и те же вложения дают двойной эффект: сайт становится доступнее для людей с ограниченными возможностями и одновременно читабельнее для AI-агентов. Семантические теги `<nav>`, `<main>`, `<article>`, `<aside>` — не формальность, а навигация для машин. ### Что реально влияет на цитируемость в AI-ответах SE Ranking проанализировал 129,000 доменов. Результаты: **Работает:** - Ссылочный профиль — сильнейший предиктор. 32K+ referring domains = 2× цитат - Свежесть — обновление в последние 3 месяца даёт 1.7× больше цитат - Скорость — FCP < 0.4с: +87% цитат - Длина — статьи от 2900 слов: 5.1 цитаты vs 3.2 для коротких - Статистика в тексте: +22%. Ссылки на источники: +37% **Не работает:** - FAQ Schema — почти нулевой или отрицательный эффект - llms.txt — ни один крупный AI-провайдер не подтвердил чтение (на август 2025) - Keyword-оптимизированные URL — нерелевантно 87% цитат ChatGPT совпадают с топ-10 Bing. Перплексити и ChatGPT пересекаются только в 11% — платформы черпают из разных источников. Единой стратегии нет. ### Стек agent-friendly сайта в 2026 **Минимум (сделать сегодня):** - Schema.org/JSON-LD (`BlogPosting`) — подтверждённый эффект: +73% выбора в AI Overviews - Семантический HTML + ARIA — accessibility = agent-friendliness - Cloudflare Markdown for Agents — один переключатель в Dashboard - robots.txt — явно разрешить GPTBot, ClaudeBot, PerplexityBot - Явные даты `datePublished` / `dateModified` — LLM системно предпочитают «свежий» контент **Средний горизонт:** - NLWeb + Cloudflare AutoRAG — `/ask` и `/mcp` endpoint без кода - Content negotiation (`Accept: text/markdown`) — агенты уже запрашивают - MCP-сервер для сайта — через Cloudflare AI Index или вручную **Следить:** - WebMCP (`navigator.modelContext`) — Google/Microsoft пушат в W3C. Позволяет сайтам публиковать «инструменты» для агентов через браузерный API. Early Preview в Chrome 146 - IETF AIPREF — официальный стандарт AI-предпочтений в HTTP-заголовках. Дедлайн: август 2026 - AGENTS.md — открытый формат инструкций для AI-агентов в репозиториях. 60K+ проектов, донирован в Linux Foundation ### Инструменты для подготовки контента Агентам нужен чистый контент. Целая индустрия выросла вокруг конверсии: - **Firecrawl** — любой URL в Markdown/JSON, MCP-сервер, интеграция с Claude - **Jina Reader** — `r.jina.ai/{URL}` → Markdown, нулевая конфигурация - **Crawl4AI** — open-source Python-краулер для RAG-пайплайнов Для мониторинга AI-видимости: Otterly.ai (6 платформ), Profound ($20M seed), бесплатный LLM Clicks AI Readiness Checker. ## Инсайт Agent-friendly веб — это не отдельная дисциплина. Это context engineering, вывернутый наружу. Когда мы пишем промпт, мы структурируем контекст для одной модели. Когда мы делаем сайт agent-friendly, мы структурируем контент для тысяч моделей и агентов одновременно. Принципы те же: структура важнее объёма, семантика важнее визуала, формат определяет качество ответа. Историческая ирония: семантический веб (RDF, OWL, Schema.org) пытался это сделать 20 лет назад. Не было клиента, который бы это ценил. Теперь клиент появился — LLM. И создатель Schema.org R.V. Guha строит NLWeb, замыкая круг. Веб перестраивается. Не через революцию — через content negotiation, HTTP-заголовки и /.well-known файлы. Тихо, на уровне протоколов. Те, кто структурирует контент сейчас, получат трафик. Остальные станут невидимыми для нового класса читателей. ## Источники - [WebArena — ICLR 2024](https://arxiv.org/abs/2307.13854) - [HtmlRAG — WWW 2025](https://arxiv.org/abs/2411.02959) - [Does Prompt Formatting Have Any Impact on LLM Performance?](https://arxiv.org/abs/2411.10541) - [Accessibility & AI Agents](https://www.accessibility.works/blog/do-accessible-websites-perform-better-for-ai-agents/) - [SE Ranking: Top 20 Factors Influencing ChatGPT Citations](https://www.searchenginejournal.com/new-data-top-factors-influencing-chatgpt-citations/561954/) - [Seer Interactive: 87% of ChatGPT Citations Match Bing](https://www.seerinteractive.com/insights/87-percent-of-searchgpt-citations-match-bings-top-results) - [BrightEdge: Structured Data in AI Search](https://www.brightedge.com/blog/structured-data-ai-search-era) - [Cloudflare: GPTBot +305%](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/) - [WebMCP — W3C](https://webmcp.link/) - [IETF AIPREF WG](https://datatracker.ietf.org/wg/aipref/about/) - [AAIF — Linux Foundation](https://aaif.io/) - [Build the Web for Agents, Not Agents for the Web](https://arxiv.org/abs/2506.10953)https://ctxt.dev/posts/ru/model-selection-agents/https://ctxt.dev/posts/ru/model-selection-agents/Исследование выбора моделей Claude для мультиагентных команд. Почему Opus может быть дешевле Sonnet, а Haiku опасен для агентных задач.Wed, 18 Feb 2026 00:00:00 GMT## Проблема Запускаешь команду из трёх агентов. Одному даёшь opus, другому sonnet, третьему haiku. Почему именно так? Потому что "opus — умный, haiku — дешёвый". Интуиция вместо данных. Мы собрали бенчмарки, изучили паттерны маршрутизации в реальных системах и нашли несколько контринтуитивных результатов. Главный: выбор модели — это не вопрос "умнее/дешевле". Это вопрос контекста задачи. ## Контекст Когда работаешь с одной моделью, выбор не стоит. Когда запускаешь пять параллельных агентов — каждый неправильный выбор умножается. Opus на задаче "посчитай файлы в директории" — выброшенные деньги. Haiku на задаче "спланируй архитектуру" — выброшенное время и токены на переделку. Проблема усугубляется тем, что бенчмарки не отражают агентную реальность. SWE-bench измеряет решение GitHub-issues, но не измеряет надёжность вызова инструментов в цикле из 50 шагов. А именно там модели ломаются по-разному. Мы провели исследование по трём направлениям: бенчмарки Anthropic, паттерны маршрутизации в существующих системах (oh-my-claudecode, claude-flow, RouteLLM), и практические failure modes каждой модели в агентных workflow. ## Решение ### Sonnet 4.6 ≈ Opus 4.6 на большинстве агентных задач Это главный сюрприз из бенчмарков. На задачах, релевантных для кодинг-агентов, разница минимальна: ``` OSWorld (управление десктопом): Sonnet 72.5% vs Opus 72.7% SWE-bench (GitHub issues): Sonnet 79.6% vs Opus 80.8% TAU-bench retail (агентные): Sonnet 91.7% vs Opus 91.9% GDPVal (офисные задачи, Elo): Sonnet 1633 vs Opus 1606 ``` Sonnet даже обгоняет Opus на GDPVal и MCP Atlas (оркестрация инструментов: 61.3% vs 59.5%). Opus лидирует убедительно только на глубоком рассуждении: GPQA Diamond 91.3% vs 74.1%, ARC-AGI-2 68.8% vs 58.3%. ### Opus может быть дешевле Sonnet Самый контринтуитивный результат. Opus использует на 48-76% меньше токенов, чем Sonnet на сложных задачах. Там, где Sonnet генерирует 500 токенов, Opus решает ту же задачу за ~120. При ценах $25 (Opus output) vs $15 (Sonnet output) за миллион токенов: если Opus тратит вдвое меньше токенов, итоговая стоимость примерно одинакова. А с учётом того, что Opus чаще решает с первой попытки (без retry-циклов), на сложных задачах он может выходить дешевле. Это работает только для задач, требующих рассуждения: архитектура, ревью, планирование. На механических задачах Opus просто дороже без выгоды. ### Haiku опасен для агентных задач У Haiku 4.5 есть подтверждённый баг (GitHub issue #10029): модель входит в бесконечные циклы вызовов инструментов. Вызывает `read_file` на тот же файл снова и снова, игнорируя feedback "этот инструмент уже вызван". Модель не обновляет внутреннее состояние на основе результатов. Дополнительные проблемы: - First-try tool success: 87% у Haiku vs 94% у Sonnet - Деградация после 75 ходов в разговоре - Нет adaptive thinking (не может динамически увеличить глубину рассуждения) - Планирование в 3-4 раза менее детальное, чем у Sonnet Haiku безопасен ровно для одного класса задач: stateless одношаговые операции. Посчитать строки, найти файл, отформатировать текст. Всё, что требует состояния между вызовами инструментов — Sonnet minimum. ### Статическая маршрутизация побеждает oh-my-claudecode, claude-flow, и практически все production-системы используют один и тот же паттерн: модель назначается по роли агента, а не по анализу каждого запроса. ``` Haiku → retrieval, formatting (механика) Sonnet → implementation, research, debugging (объём) Opus → architecture, review, planning (суждение) ``` Существуют динамические роутеры (RouteLLM, Martian, Not Diamond), которые анализируют каждый запрос и выбирают модель. Они снижают стоимость на 40-85% при сохранении 95% качества. Но требуют training data и инфраструктуру. Для агентных команд из 3-5 участников static routing проще и достаточен. Интересная находка из проекта Anthropic по созданию C-компилятора (16 агентов, 100K строк кода, ~2000 сессий): они использовали Opus для всех 16 агентов. Без model routing вообще. Специализация была по функции (лексер, парсер, оптимизация), а не по модели. ### Три правила для выбора Задача требует суждения (корректность, trade-offs, архитектура)? **Opus.** Задача требует объёма (чтение, написание, код, исследование)? **Sonnet.** Задача чисто механическая и одношаговая? **Haiku.** При сомнении — **Sonnet**. Haiku провалится молча, Opus будет overkill. Sonnet покрывает ~90% агентных задач с лучшим соотношением цены и надёжности. ## Инсайт Выбор модели — это задача context engineering. Не "какая модель умнее", а "какой контекст получит этот агент и что от него требуется". Исследование AgentIF (Tsinghua, EMNLP 2025) показало: даже лучшие модели выполняют менее 30% сложных агентных инструкций безошибочно. Разница между Sonnet и Opus на этом фоне — шум. Что действительно определяет результат — качество декомпозиции задачи, чёткость промпта и правильные границы ответственности агента. Модель — это ресурс. Как CPU time или память. Её нужно аллоцировать по потребности задачи, а не по престижу названия. ## Источники - [Anthropic Sonnet 4.6](https://www.anthropic.com/news/claude-sonnet-4-6) - [Anthropic Opus 4.6](https://www.anthropic.com/claude/opus) - [Haiku tool loop bug — GitHub #10029](https://github.com/anthropics/claude-code/issues/10029) - [RouteLLM — LMSYS](https://lmsys.org/blog/2024-07-01-routellm/) - [oh-my-claudecode agents](https://github.com/Yeachan-Heo/oh-my-claudecode/blob/main/AGENTS.md) - [Anthropic C-compiler case study](https://www.anthropic.com/engineering/building-c-compiler) - [AgentIF benchmark — Tsinghua](https://keg.cs.tsinghua.edu.cn/persons/xubin/papers/AgentIF.pdf)https://ctxt.dev/posts/ru/gastown-cheatsheet/https://ctxt.dev/posts/ru/gastown-cheatsheet/Справочник по Gas Town — системе параллельного управления 20-30 Claude Code агентами. Команды, концепции, воркфлоу.Sat, 24 Jan 2026 00:00:00 GMTGas Town — оркестратор от Steve Yegge для параллельного управления десятками Claude Code агентов. Построен на Git worktrees и Beads для сохранения состояния между перезапусками. ## Терминология (Mad Max universe) | Термин | Что это | Аналог | | -------------- | ----------------------------------------------------------------- | ------------ | | **Mayor** 🎩 | Главный координатор. Говоришь ему что строить — он раздаёт работу | PM/Tech Lead | | **Polecat** 🦨 | Воркер-агент. Появляется, делает задачу, исчезает | Junior Dev | | **Rig** 🏗️ | Контейнер проекта. Оборачивает git repo + управляет агентами | Project | | **Crew** 👤 | Твоё персональное рабочее пространство внутри Rig | Workspace | | **Convoy** 🚚 | Пачка задач (beads), назначенных агентам | Sprint/Batch | | **Town** 🏘️ | Корневая директория (~gt/) со всеми проектами | Monorepo | | **Hook** 🪝 | Git worktree для персистентного хранения состояния агента | State Store | | **Refinery** | Координатор merge-операций | CI/CD | | **Witness** | Мониторит проблемы, фиксит issues | QA | | **Deacon** | Maintenance операции | DevOps | ## Установка ```bash # Prerequisites brew install go@1.23 git sqlite3 tmux # Beads (task tracking) # следуй инструкциям https://github.com/steveyegge/beads # Gas Town brew tap steveyegge/gastown && brew install gt # Инициализация gt install ~/gt --git cd ~/gt # Добавить проект gt rig add myproject https://github.com/you/repo.git # Создать workspace gt crew add yourname --rig myproject # Запустить Mayor gt mayor attach ``` ## Ключевые команды ### Workspace ```bash gt install <path> # Инициализация Town gt rig add <name> <repo> # Добавить проект gt rig list # Список проектов gt crew add <name> --rig <rig> # Создать Crew ``` ### Агенты ```bash gt agents # Активные агенты gt mayor attach # Запустить Mayor сессию gt mayor start --agent auggie # Mayor с конкретным runtime gt prime # Восстановление контекста (внутри сессии) gt sling <bead-id> <rig> # Назначить задачу агенту gt sling <id> <rig> --agent cursor # С конкретным runtime ``` ### Convoy (пачки задач) ```bash gt convoy create <name> [issues] # Создать convoy gt convoy list # Список convoys gt convoy show [id] # Детали convoy gt convoy add <convoy-id> <issue-id...> # Добавить issues ``` ### Конфигурация ```bash gt config show # Текущие настройки gt config agent set <name> "<cmd>" # Добавить агента gt config default-agent <name> # Default runtime ``` ### Beads интеграция ```bash bd formula list # Список формул bd cook <formula> # Выполнить формулу bd mol pour <formula> # Создать trackable instance bd mol list # Активные instances ``` ## Воркфлоу ### Через Mayor (рекомендуется) ```bash gt mayor attach # Описываешь Mayor'у что хочешь построить # Он создаёт convoy, раздаёт работу Polecats # Следишь через gt convoy list ``` Mayor абстрагирует сложность. Ты говоришь с одним "экспертом", он управляет армией. ### Manual режим ```bash # Создать convoy gt convoy create feature-x issue-1 issue-2 # Назначить работу gt sling issue-1 myproject gt sling issue-2 myproject # Мониторить gt convoy show gt agents ``` ## Поддерживаемые runtimes Встроенные: `claude`, `gemini`, `codex`, `cursor`, `auggie`, `amp` Настройка в `settings/config.json` каждого rig. Для Codex добавить в `~/.codex/config.toml`: ```toml project_doc_fallback_filenames = ["CLAUDE.md"] ``` ## Предупреждения ### Стоимость Ожидай 10x стоимость токенов vs обычная Claude Code сессия. 60 минут ≈ $100. ### YOLO mode Gas Town работает автономно: - Пушит branches в GitHub - Создаёт PR - Может мержить PR даже с failing tests ### Безопасность Для production codebases нужны guard rails. Держи force-push наготове. ## Архитектурные принципы ### GUPP (Git Up, Pull, Push) Детерминированные handoffs через git, не LLM-решения о переходах фаз. ### External State Beads хранит task tracking вне context window агента. Нет pollution от role prompts. ### Git Isolation Каждый агент = свой Git worktree. Нет shared-state corruption от крашей. ### Parallel Execution Задачи выполняются параллельно через 20-30 инстансов, не последовательные фазы. ## Известные проблемы - Auto-merge broken tests в main - Непредсказуемое удаление кода ("murderous Deacon") - Требуются force pushes для recovery - Высокий token burn rate Gas Town — мощный, но сырой. Подходит для новых проектов с правильными safeguards, не для established repositories. ## Источники - [Gas Town GitHub](https://github.com/steveyegge/gastown) - [Steve Yegge — Welcome to Gas Town](https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04) - [DoltHub — A Day in Gas Town](https://www.dolthub.com/blog/2026-01-15-a-day-in-gas-town/) - [GasTown and the Two Kinds of Multi-Agent](https://paddo.dev/blog/gastown-two-kinds-of-multi-agent/)https://ctxt.dev/posts/ru/evoidea-memetic-algorithm/https://ctxt.dev/posts/ru/evoidea-memetic-algorithm/Как применить эволюционный подход к генерации стартап-идей с помощью AI-агентовFri, 23 Jan 2026 00:00:00 GMT## Проблема Брейншторминг стартап-идей хаотичен. Идеи теряются, забываются. Нет систематического способа оценить и сравнить их. Трудно улучшать слабые места, не теряя того, что работает. Ограничения — бюджет, сроки, навыки — часто игнорируются. Обычно это выглядит так: записал 20 идей на салфетке, выбрал "самую интересную" интуитивно, через неделю понял, что она не учитывает твои реальные ресурсы. ## Контекст Меметические алгоритмы — это эволюционные алгоритмы для идей. Как генетические алгоритмы работают с генами, меметические работают с мемами — единицами культурной информации. Принцип простой: 1. **Генерация** — создаём разнообразную популяцию идей 2. **Критика** — оцениваем каждую по нескольким критериям 3. **Отбор** — лучшие выживают, слабые в архив 4. **Улучшение** — дорабатываем победителей, устраняя слабые места LLM отлично подходят для каждого этапа. Они могут генерировать идеи, критиковать их по заданным критериям, и предлагать улучшения. Осталось связать это в цикл. ## Решение [Evoidea](https://github.com/t3chn/evoidea) — это Claude Code skill + Rust CLI, реализующий меметический цикл: ``` GENERATE → CRITIQUE → SELECT → REFINE → repeat ``` Запуск через Claude Code: ```bash /evoidea "Build developer productivity tools" --rounds 3 --population 6 ``` С ограничениями: ```bash /evoidea "SaaS for freelancers" --budget 1000 --timeline 4 --solo --no crypto,hardware ``` Каждая идея оценивается по 8 критериям: - feasibility (реализуемость) - speed_to_value (скорость до первой ценности) - differentiation (отличие от конкурентов) - market_size (размер рынка) - distribution (каналы дистрибуции) - moats (защита от копирования) - risk (риски) - clarity (понятность) Ограничения работают как жёсткие фильтры — идея, нарушающая хотя бы одно, получает score = 0 и статус "eliminated". На выходе — структурированный JSON с полной историей эволюции: ``` runs/<run_id>/ ├── config.json # параметры запуска ├── state.json # популяция + оценки ├── history.ndjson # лог событий └── final.json # победитель + причина остановки ``` Можно экспортировать победителя в формат landing page: ```bash evoidea export --run-id run-20260123-181141 ``` ## Инсайт Эволюционный подход к идеям работает, потому что устраняет две главные проблемы брейншторма: **Привязанность к первой идее.** Когда ты сам придумал идею, ты её защищаешь. Алгоритм безэмоционален — слабая идея уходит в архив, сильная развивается. **Игнорирование ограничений.** Легко мечтать о стартапе на $10M, когда у тебя бюджет $500 и 4 недели. Жёсткие фильтры возвращают в реальность до того, как потратишь время на проработку нежизнеспособной идеи. Context engineering здесь в том, что LLM получает не просто "придумай идею", а полный контекст: текущую популяцию, историю оценок, критерии, ограничения. Это позволяет модели принимать осмысленные решения на каждом этапе. ## Источники - [Evoidea на GitHub](https://github.com/t3chn/evoidea) - [Memetic Algorithms](https://en.wikipedia.org/wiki/Memetic_algorithm)https://ctxt.dev/posts/ru/loadout-skill-manager/https://ctxt.dev/posts/ru/loadout-skill-manager/Как решить проблему дрейфа skills в AI-агентах. Manifest + lock + symlinks — паттерн из пакетных менеджеров для управления контекстом.Thu, 22 Jan 2026 00:00:00 GMT**Disclaimer**: Loadout — это мой эксперимент, а не готовое production-решение. Проект находится в ранней стадии разработки. ## Проблема Скиллы для AI-агентов дрейфуют. Типичный сценарий: есть центральный репозиторий со skills для Codex CLI или Claude Code. Начинаешь новый проект — копируешь нужные skills в `.codex/skills/`. Через месяц работы они неузнаваемы: локальные правки, адаптации под проект, исправления багов. Проблемы накапливаются: - Улучшения не возвращаются в источник - Разные проекты расходятся - Нет способа обновить skill без потери локальных изменений - Каждый клиент (Codex vs Claude) — своя структура и UX Это та же проблема, которую решают npm, cargo и poetry для кода. Только для skills её никто не решал. ## Контекст Почему это важно для context engineering? Skills — это исполняемый контекст. Не просто текст для модели, а инструкции, которые агент выполняет автономно. Качество skills напрямую влияет на качество работы агента. Когда skills дрейфуют: - Теряется консистентность между проектами - Невозможно воспроизвести результат ("у меня работало") - Улучшения изолируются вместо распространения Пакетные менеджеры решили эту проблему для кода десятилетия назад. Паттерн manifest + lock обеспечивает: - Декларативность: что хотим vs что имеем - Воспроизводимость: pinned версии - Обновляемость: upgrade без потери контроля ## Решение ### Manifest + Lock Loadout использует знакомый паттерн: **Manifest** (`loadout.json`) — что хотим: ```json { "schema_version": 1, "primary_source": "primary", "sources": { "primary": { "url": "https://github.com/acme/skills", "ref": "main" } }, "targets": { "codex": { "skills": ["pdf-processing", "code-review"] }, "claude": { "skills": ["pdf-processing"] } } } ``` **Lock** (`loadout.lock.json`) — что имеем (pinned): ```json { "schema_version": 1, "sources": { "primary": { "pinned_sha": "0123456789abc..." } } } ``` Оба файла коммитятся в git. Воспроизводимость гарантирована. ### Symlinks вместо копий Ключевое решение — не копировать skills, а создавать symlinks: ``` .codex/skills/_loadout__pdf-processing → .codex/.loadout/sources/primary/codex/pdf-processing ``` Почему это важно: - Правишь skill в проекте → правишь в клоне source repo - `git push` из клона → улучшения возвращаются в источник - Нет дрейфа: один источник правды Source repo клонируется в `.codex/.loadout/sources/` (gitignored). Symlinks — managed, с префиксом `_loadout__` для изоляции от ручных skills. ### Multi-source с trust gate Можно подключать сторонние источники: ```bash loadout source add contrib --url https://github.com/community/skills --ref main loadout source trust contrib --yes # Явное подтверждение loadout add --target codex contrib:special-formatter ``` Новые sources по умолчанию untrusted. Операции блокируются с ошибкой `SOURCE_UNTRUSTED` до явного подтверждения. Supply-chain safety из коробки. ### Agent-first UX Loadout спроектирован для агентов, не для людей: - JSON output по умолчанию (машиночитаемо) - Нет интерактивных промптов (все inputs через args) - Идемпотентные операции (запуск дважды = запуск один раз) - Стабильные error codes (`SKILL_NOT_FOUND`, `SOURCE_UNTRUSTED`) - Детерминистический поиск (лексический scoring, не LLM) ```bash # Поиск skills loadout suggest --target codex --query "pdf" --limit 10 # Добавление loadout add --target codex pdf-processing image-processing # Статус loadout status --target codex ``` Агент вызывает CLI, парсит JSON, показывает пользователю отформатированный результат. Протокол описан в Agent Playbook. ## Инсайт Dependency management — решённая проблема. npm, cargo, poetry работают десятилетиями. Паттерн manifest + lock + resolver универсален. Skills для AI-агентов — те же dependencies. Они влияют на поведение системы, должны версионироваться и обновляться контролируемо. Loadout не изобретает новое. Он применяет проверенный паттерн к новой области: управление контекстом для AI-агентов. Интересный момент: symlinks вместо копий. В отличие от классических пакетных менеджеров, skills часто нужно дорабатывать на месте. Symlink позволяет редактировать и сразу пушить улучшения обратно в source. Это не баг — это фича. Когда смотришь на проблему дрейфа skills как на проблему dependency management, решение становится очевидным. Manifest декларирует intent. Lock фиксирует state. Symlinks обеспечивают flow улучшений в обе стороны. ## Источники - [Loadout на GitHub](https://github.com/t3chn/loadout)https://ctxt.dev/posts/ru/claude-code-architecture/https://ctxt.dev/posts/ru/claude-code-architecture/Разбор архитектуры Claude Code по материалам выступления основателя PromptLayer. Почему while-loop, Bash и управление контекстом важнее сложных workflow.Sat, 27 Dec 2025 00:00:00 GMT## Проблема Кодинг-агенты долго оставались игрушкой. Сложные DAG-схемы, где разработчик прописывал каждый переход: "если пользователь хочет X — иди сюда, если Y — туда". Системы получались жёсткими и хрупкими. Claude Code работает иначе. Джаред Зонерайх из PromptLayer разобрал архитектуру на недавней конференции AI Engineer. Оказалось, что под капотом — не граф решений, а простой цикл. ## Контекст Почему сложные схемы проваливались? Разработчики пытались программировать поведение агента императивно. Каждый edge-case требовал нового условия. Каждое условие — потенциальная точка отказа. Современные модели достаточно умны, чтобы справляться с неопределённостью. Они могут исследовать, ошибаться и исправляться. Жёсткие схемы мешают этому. Философия Claude Code: дайте модели инструменты и отойдите в сторону. ## Решение ### Цикл вместо графа Архитектура Claude Code — это `while`-цикл: ```python while has_tool_calls(response): results = execute_tools(response.tool_calls) response = model.generate(results) ``` Пока есть вызовы инструментов — выполняем их, передаём результат модели, повторяем. Никаких предопределённых путей. ### Bash как универсальный адаптер Один из ключевых инструментов — обычный Bash. Почему это работает: - Для Bash существует огромное количество обучающих данных - Модель может написать Python-скрипт, запустить его через Bash, получить результат и удалить файл - Вместо создания сотен специфических инструментов — один универсальный адаптер Агент пробует подходы и исправляет ошибки на лету. Bash даёт ему эту гибкость. ### Контекст — главный враг Чем больше контекста в промпте, тем хуже работает модель. Claude Code решает это несколькими способами: **Субагенты.** Для специфических задач (чтение документации, запуск тестов) создаются отдельные агенты с чистым контекстом. Они возвращают только результат, не загрязняя основную ветку. **Diff вместо перезаписи.** Агент не переписывает файл целиком, а создаёт изменения. Экономия токенов и снижение вероятности ошибок. **To-do списки.** Модель ведёт структурированный план действий. Это помогает не сбиваться с пути и возобновлять работу после сбоев. ### Skills для кастомизации Skills — расширяемые системные промпты для специфических задач. Обновление документации в вашем стиле, глубокое исследование репозитория, специфичные для команды процессы. Это позволяет адаптировать агента без перегрузки основного контекста. ## Инсайт Три принципа, которые объясняют работу современных кодинг-агентов: **Доверие модели.** Не пытайтесь запрограммировать каждый случай. Модели справляются с исследованием и исправлением собственных ошибок. **Простота архитектуры.** Zen of Python ("простое лучше сложного") работает и для агентов. Цикл вместо графа. **Управление контекстом.** Эффективная работа с памятью модели важнее количества инструментов. Субагенты, diff, to-do списки — всё это про контекст. Мы переходим от копирования кода из чата к headless-агентам, которые сами создают PR и чинят баги. Не потому что модели стали умнее — а потому что мы научились правильно доставлять им контекст. ## Источники - [AI Engineer Conference — Jared Zoneraich (PromptLayer)](https://www.youtube.com/watch?v=example) - [Claude Code Documentation](https://docs.anthropic.com/claude-code)https://ctxt.dev/posts/ru/semantic-catalog-enterprise/https://ctxt.dev/posts/ru/semantic-catalog-enterprise/Почему Text-to-SQL и прямой маппинг REST API не работают, и как семантический граф бизнес-сущностей решает проблему доставки контекста в enterprise.Thu, 25 Dec 2025 00:00:00 GMT## Проблема Text-to-SQL казался элегантным решением. Агент понимает вопрос, генерирует SQL, получает данные. На практике — проблемы с безопасностью, ошибки синтаксиса, падение production. Прямой маппинг REST API в инструменты MCP не лучше. Агенты путаются в избыточных параметрах и сложных цепочках вызовов. Чем больше эндпоинтов, тем хуже результат. Обе стратегии объединяет одно: они дают агенту доступ к "сырым" данным и надеются, что он разберётся. ## Контекст Когда команды работают с крупными компаниями, простые методы перестают работать. Не потому что модели недостаточно умны — GPT-4 и Claude справляются с логикой. Проблема в том, как мы доставляем контекст. Агент видит таблицы базы данных. Он не понимает, что `customer_id` связан с `order_id`, который связан с `product_sku`. Он не знает бизнес-логику: какие транзакции считаются подозрительными, как связаны возвраты и фрод. Мы даём ему ингредиенты и просим приготовить блюдо. Но он не знает рецепта и не понимает, как эти ингредиенты сочетаются. ## Решение Команды, добившиеся успеха в enterprise, используют другой подход — **семантический каталог**. ### Граф бизнес-сущностей Вместо таблиц — бизнес-объекты. Вместо foreign keys — смысловые связи. ```python # Пример семантического каталога catalog = SemanticCatalog() catalog.add_entity("Customer", { "attributes": ["name", "email", "risk_score"], "relations": { "orders": "Order", "support_tickets": "Ticket" } }) catalog.add_entity("Order", { "attributes": ["amount", "status", "timestamp"], "relations": { "customer": "Customer", "items": "Product" } }) ``` Агент теперь понимает структуру бизнеса, а не схему базы данных. ### Протокол MCP и возможность исследования Семантический каталог превращается в MCP-эндпоинт через проекты вроде Enrich MCP. Модель может "общаться" с данными на одном языке. Ключевое отличие: агент не получает готовый ответ. Он может **исследовать иерархию данных**: 1. Получить список заказов за период 2. Найти аномалии по сумме 3. Перейти к данным о пользователе 4. Проверить связанные атрибуты (история, возвраты, риск-скор) 5. Сделать вывод Агент сам навигирует по данным, пока не найдёт решение. ### Единая поверхность контекста Вместо разделения на память, векторный поиск и структурированные данные — **единый интерфейс**. Агент выбирает лучший способ навигации в зависимости от задачи: - Поиск по вектору для неструктурированных данных - Поиск по ключу для точных запросов - Обход графа для исследования связей Метафора: не давай повару нарезанные ингредиенты по одному. Пусти его на профессионально организованную кухню. Всё подписано, разложено по категориям, логически связано. Повар сам решает, какой нож взять и в каком холодильнике искать нужный продукт. ## Инсайт Проблема enterprise AI — не в интеллекте модели. Современные модели достаточно умны. Проблема в **доставке контекста**. Мы даём агенту доступ к данным, но не даём понимания структуры. Мы показываем таблицы, но не показываем связи. Семантический каталог — это инженерная проработка контекста. Не RAG, не prompt engineering, а полноценная система, которая позволяет агенту самостоятельно извлекать нужные фрагменты данных в реальном времени. Результат: выход за рамки простого поиска по документам к системам, способным решать аналитические бизнес-задачи. ## Источники - [MCP Protocol](https://modelcontextprotocol.io/) - [Enrich MCP](https://github.com/anthropics/anthropic-cookbook/tree/main/misc/enrich_mcp)https://ctxt.dev/posts/ru/hello-world/https://ctxt.dev/posts/ru/hello-world/Введение в context engineering — инженерный подход к работе с LLM. Почему промпты перестают работать и что с этим делать.Sat, 20 Dec 2025 00:00:00 GMT## Проблема Промпты перестали работать стабильно. Один и тот же промпт даёт разные результаты в зависимости от контекста. Добавление деталей в инструкции только ухудшает ситуацию. Модель "забывает" важное или фокусируется не на том. ## Контекст Prompt engineering фокусируется на формулировке запроса. Но модель принимает решения на основе всего контекста: системного промпта, истории диалога, документов, примеров. Context engineering — это инженерный подход к организации всей этой информации: - Что включить в контекст - В каком порядке - Как структурировать Это похоже на разницу между "написать хорошее письмо" и "построить систему коммуникации". ## Решение Вместо улучшения промпта — структурируем контекст. **Инструкции** — краткие, без повторений. Модель не нуждается в многословных объяснениях. **Данные** — релевантные, с метаданными. Не просто текст, а структура: что это, откуда, зачем. **Примеры** — конкретные, не абстрактные. Один хороший пример лучше страницы объяснений. **Constraints** — явные ограничения. Что делать нельзя так же важно, как что делать нужно. Порядок важен: модель "забывает" середину длинного контекста. Критичную информацию — в начало и конец. ## Инсайт Context engineering — это не про LLM. Это про организацию информации. Те же принципы работают для людей: структура помогает понять. Разница в том, что у LLM нет "здравого смысла" для восполнения пробелов. Всё должно быть явным. Этот блог — исследование того, как структурировать контекст. Практика, не теория. ## Источники - [Anthropic: Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) - [Anthropic: Prompt Caching](https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching)