Антипаттерны

Обзор

Антипаттерны — это повторяющиеся ошибки проектирования workflow, которые приводят к сломанным, неэффективным или неподдерживаемым workflow. Перед планированием правки Workflow Management Flow (WMF) предлагает полный аудит исходного workflow по этому каталогу, запускает его с вашего согласия и даёт выбрать, какие подтверждённые исправления войдут в объём работы.

Используйте moira/software-development-flow как каноничный пример правильных паттернов workflow.

Состояние и выводы

Кругооборот данных

Директива говорит агенту собрать данные, затем inputSchema просит агента вернуть эти же данные как структурированный вывод. Агент работает как оператор ввода данных, копируя из вывода инструмента в поля схемы.

Обнаружение: inputSchema повторяет структуру данных, которые агенту было поручено собрать.

❌ Directive: "Get project info from package.json"
   inputSchema: { project_name: string, version: string, description: string }
   // Агент копирует данные из файла в поля схемы — бессмысленный кругооборот

✅ Use expression node to extract data, or capture agent's ANALYSIS in inputSchema
   inputSchema: { architecture_assessment: string, risks_identified: string[] }

Декоративные outputs

inputSchema требует done, success, status, result_code, номер прохода или evidence, который не читает ни одна следующая нода. Успешный переход уже означает выполнение completion condition; JSON Schema не делает повторное подтверждение полезным.

Обнаружение: у output нет reader, он не влияет на condition и не входит в обязательный пользовательский результат.

❌ inputSchema: { done: boolean, status: string, result_code: string }
   // Все маршруты всё равно продолжаются по success connection

✅ inputSchema: {}
   // Перед переходом нода проверяет свой completion condition

✅ inputSchema: { issues_count: integer }
   // Condition-нода использует число для выбора review или repair

Состояние без потребителя

У каждого output и глобальной переменной должны быть writer, named reader и наблюдаемое влияние на route, отрендеренную инструкцию или обязательный результат. Состояние, которое никто не читает, всё равно приходится производить и держать верным каждому, кто его касается, а когда оно протухнет, этого никто не поймает. Значения без полной трассировки нужно удалять.

Дублирующийся источник истины

Одно и то же подробное содержимое живёт сразу в файле, в выводе ноды, во втором поле и в отрендеренной директиве. Любая копия может разойтись с остальными, и читатель не может определить, какая из них актуальна.

Обнаружение: значение, которое следующая нода могла бы получить чтением по стабильному пути, дополнительно проносится через контекст workflow или повторяется внутри другого артефакта.

❌ review.md содержит замечания, review_summary несёт их же,
   а директива исправления интерполирует и то и другое

✅ review.md содержит замечания; рецензент возвращает issues_count для маршрутизации;
   владелец исправления читает файл

Дублирование контекста

Копирование информации, уже имеющейся в контексте агента, в переменные workflow. Избыточно и раздувает контекст.

Обнаружение: inputSchema, захватывающая данные, которые агент уже имеет в контексте разговора (например, списки директорий, информация о проекте из предыдущего анализа).

❌ variable: project_structure = "<output of tree command>"
   // Агент уже имеет это в контексте; повторное хранение тратит токены

✅ Let agent re-read current data when needed. Store only stable references (paths, IDs).

Динамические данные в переменных workflow

Хранение динамических данных, генерируемых в ходе выполнения workflow (содержимое файлов, ответы API, HTML-вывод, результаты извлечения) в переменных workflow. Эти переменные внедряются в каждую директиву через шаблоны, раздувая контекст потенциально неограниченным содержимым.

Обнаружение: Переменные, получающие динамический контент через inputSchema во время выполнения, особенно контент >1KB или контент, растущий неограниченно.

Область применения: Этот антипаттерн относится к данным, передаваемым между шагами workflow — НЕ к статической конфигурации, хранящейся как значение default в variableRegistry. См. паттерн Статическая конфигурация workflow для понимания различия.

❌ inputSchema: { html_content: string }
   Next directive: "Publish {{step.html_content}}"
   // Целая HTML-страница хранится в переменной, внедряется в каждую последующую директиву

❌ inputSchema: { extraction_results: object }
   Next directive: "Analyze {{extraction_results}}"
   // Потенциально большие данные извлечения передаются туда-обратно через переменные

✅ Directive: "Save HTML to {{workspace_path}}/report.html"
   inputSchema: { file_path: string }
   Next directive: "Publish file at {{step.file_path}}"
   // В переменной хранится только путь, агент читает файл по необходимости

Исключение: Статический инструктивный контент, хранящийся как значение default в variableRegistry (правила, стандарты, чек-листы), — это правильный паттерн, а не злоупотребление переменными. Они намеренно размещены, чтобы агент видел их на каждом соответствующем шаге. См. Статическая конфигурация workflow.

Дублирующие синонимы

Два имени несут одно каноническое значение — mode рядом с operating_mode, plan_path рядом с current_plan_file, — поэтому каждый писатель обязан помнить об обоих, а читатель не может понять, какое из них используют маршруты. Синониму нужен доказанный внешний контракт совместимости, а не предпочтение более короткого имени.

Преждевременно авторитетные производные данные

Число или сводка, выведенные из того, что ещё может измениться, используются для маршрутизации или показываются пользователю как окончательные. Длина плана до его согласования, число замечаний до завершения файла ревью и общее количество пунктов до подтверждения списка — все они предварительны.

❌ показать пользователю число шагов, пока план ещё может быть пересмотрен
✅ вывести и показать число после того, как источник зафиксирован

Движок и переменные

Повторная реализация workflow-движка

Workflow строит собственный runtime из step run IDs, phases, handoff-протоколов, locks, hashes, manifests, ledgers или transaction/deduplication-слоёв без доказанного требования. Moira уже сохраняет текущую ноду, завершение шага и переход графа.

Обнаружение: новое управляющее значение дублирует execution state движка и не имеет отдельного наблюдаемого назначения.

❌ создавать pass IDs и phase state, чтобы помнить активную ноду графа
✅ полагаться на execution record и connections графа

Добавляйте управляющий механизм только после доказательства, что модель движка не покрывает конкретное требование. Нода lock — законное исключение, когда реальная конкурентность или владение этого требуют; декоративный протокол блокировок — нет.

State machine механической валидации

Workflow повторяет официальный validator через validation_passed, массивы ошибок, счётчики, reset expressions и limit-ветки. Это дублирует платформу и может разойтись с её поведением.

❌ change → validation node → validation flags/counters → repair → reset → validation
✅ change and run the official validator in the same node; complete only after it succeeds

Отдельная validation-нода нужна только когда валидация сама является наблюдаемым этапом процесса, требуемым пользователем, а не деталью создания валидного артефакта.

Необъявленная переменная / Неявное продвижение

Ссылка на переменную по голому имени, которая не объявлена в variableRegistry workflow, или ожидание, что локальный вывод узла станет глобальной переменной за счёт совпадения имён. Глобальные переменные должны объявляться явно; узел записывает глобальную переменную только когда указывает её имя в inputSchema.globalInputs.

Обнаружение: Шаблонная ссылка по голому имени (не локальная node-id.name и не системная переменная вроде executionId), для которой нет соответствующей записи в variableRegistry. Или workflow, который полагается на продвижение возвращаемого ключа узла в глобальную переменную по совпадению имён.

❌ Директива ссылается на переменную по голому имени, не объявленную в variableRegistry
   // Нет записи в реестре → значение undefined во время выполнения

❌ Узел возвращает ключ и ожидает, что он станет глобальным из-за совпадения имени
   // Неявного продвижения нет — значение остаётся локальным выводом узла

✅ Объявляйте каждую глобальную переменную в variableRegistry
   Узел записывает глобальную переменную только через inputSchema.globalInputs (указав имя)
   Ссылайтесь на локальные выводы узла как node-id.name

Объявленная переменная без default

{{var}} рендерится как [[UNDEFINED_VARIABLE]] во время выполнения, хотя var объявлена в variableRegistry; выражение вроде var = var + 1 даёт NaN.

Обнаружение: Объявление в variableRegistry без default, где переменная не инициализирована в start initialData и не записывается ни одним вышестоящим узлом через globalInputs.

❌ variableRegistry: { validation_round: { type: "number" } }   // нет default
   Directive: "Pass {{validation_round}} ..."  // рендерится [[UNDEFINED_VARIABLE]]
   Expression: validation_round = validation_round + 1  // NaN

✅ variableRegistry: { validation_round: { type: "number", default: 0 } }
   // Счётчик начинается с реального значения; инкременты и шаблоны разрешаются

Задавайте default каждому счётчику и флагу. Валидатор выдаёт предупреждение «объявлена без default», когда переменная, на которую ссылаются, не имеет default и нигде не записывается выше по потоку.

Ручное управление индексами агентом

Агент вручную отслеживает индексы массивов, счётчики или пагинацию через inputSchema. Подвержено ошибкам и ломается при повторе.

Обнаружение: inputSchema с полями вроде current_index, next_item_number или значениями счётчиков, которые агент должен вычислять.

❌ inputSchema: { current_index: number, next_item: string }
   // Агент выполняет арифметику, подвержен ошибкам

✅ Expression node: current_index = current_index + 1
   Directive: "Process {{items[current_index]}}"
   // Движок workflow обрабатывает арифметику детерминированно

Шаблон в данных

{{name}}, который агент записывает в данные, возвращаемые через step(), рендерится как [[UNDEFINED_VARIABLE]], когда это значение позже интерполируется в директиву.

Обнаружение: Возвращаемые значения inputSchema, содержащие синтаксис шаблона {{...}} по голому имени.

❌ step() returns: { summary: "Report for {{project_name}}" }
   Next directive: "Publish {{summary}}"  // {{project_name}} рендерится [[UNDEFINED_VARIABLE]]

✅ step() returns: { summary: "Report for acme-api" }
   // Подставленные значения данных считаются литеральным текстом, не парсятся как шаблоны

Никогда не записывайте голый {{...}} в данные step(); шаблоны принадлежат только статическим полям узла (directive, completionCondition, message). Движок считает подставленные значения данных литеральными.

Внедрение шаблона (SSTI)

Недоверенный ввод, содержащий синтаксис шаблона, интерполированный в директиву, может попытаться выгрузить набор переменных ({{context.variables}}), выполнить хелпер each/if или обойти область видимости другого узла через node-id.field.

Обнаружение: Директива интерполирует переменную, значение которой исходит из недоверенного ввода, способного содержать синтаксис {{...}}.

❌ Directive: "Summarize the user's note: {{user_note}}"
   где user_note = "{{context.variables}}"   // попытка выгрузить все переменные

✅ Интерполированные ЗНАЧЕНИЯ литеральны — движок нейтрализует синтаксис фигурных скобок,
   исходящий из подставленных данных, поэтому {{context.variables}} в user_note рендерится как
   обычный текст. Не отражайте недоверенный синтаксис шаблона в директивах; предпочитайте явные
   именованные переменные полным выгрузкам {{context.variables}}.

Интерполированные значения никогда не парсятся повторно как шаблоны. Шаблоны живут в статических полях, контролируемых автором.

Модификация SystemReminder

Системное соображение. systemReminder статичен и применяется ко ВСЕМ шагам. Инструкции для конкретных шагов должны быть в директивах узлов, а не в systemReminder.

Загрузка файла через контент

Передача всего JSON workflow через параметры MCP-инструмента для больших workflow. Упирается в лимиты размера.

Обнаружение: manage({ action: "create", workflow: <large JSON> }) с workflow >50KB.

❌ manage({ action: "create", workflow: <50KB JSON> })
   // Может упереться в лимиты размера параметров

✅ token({ action: "upload" }) → HTTP PUT with file content
   // Загрузка по токену обрабатывает любой размер

Скрытый рантайм во временных инструментах

Одноразовый скрипт, генератор или промежуточный формат, написанный ради одной правки, становится необъявленной зависимостью: workflow работает только там, где этот инструмент есть, и в определении об этом ничего не сказано. Делайте правку официальным CLI или API, а артефактом записи оставляйте сам JSON workflow.

Форма графа и маршруты

Неявные циклы исправлений

Директива говорит «исправляй пока не будет готово» без явной структуры цикла в графе. Агент повторяет попытки внутренне без контроля workflow.

Обнаружение: Слова вроде «retry», «keep trying», «fix until» в директиве без соответствующего условного узла, создающего цикл в графе.

❌ Directive: "Keep fixing tests until they all pass"
   // Нет структуры графа, агент зацикливается внутренне без контроля workflow

✅ [fix] → [run-tests] → condition(passed?) → [fix] / [next]
   // Явный цикл в графе с видимостью каждой итерации для workflow

Ложный выбор

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

❌ спросить «быстро или тщательно?» и в обоих случаях перейти в ту же ноду
✅ развести ответы по разным ответственностям либо не спрашивать

Расхождение схемы и маршрутов

Схема допускает ответ, с которым граф ничего не может сделать: значение enum без соответствующего маршрута, обратная связь, которую ветка отказа читает, но схема оставляет необязательной, или поле ошибки, которое никто не потребляет.

Обнаружение: значение или член enum в inputSchema, для которого нет исхода, либо условное поле, требуемое маршрутом, но не обязательное по схеме на этой ветке.

❌ enum ["yes", "no", "later"] при connections только true/false
✅ у каждого допустимого ответа есть достижимый исход, а маршрут, потребляющий обратную связь,
   требует её на той ветке, которая её порождает

Процедурная фрагментация

Отдельный agent turn ради создания каталога, копирования известного значения, переименования отчёта, сборки prompt из известных файлов или записи результата прошлого шага добавляет координацию без новой интеллектуальной работы. Каждый передаточный ход — ещё и место, где работу можно исказить в пересказе, не добавив суждения, а собственный отчёт владельца становится сведениями из вторых рук. Владелец содержательной операции сам создаёт свои артефакты.

Абстракция без переиспользования

Subgraph, дочерний workflow, адаптер или протокол вводятся, чтобы спрятать локальную сложность, а не ради независимого переиспользуемого контракта. Сложность остаётся, но теперь она разнесена по двум определениям со связкой между ними.

Потерянная условность

Объединение нод делает безусловной работу, которая раньше пропускалась: браузерную проверку, которая шла только для изменений интерфейса, интеграционный набор, который запускался лишь для затронутой области, шаг, который пользователь мог пропустить. Объединение обязано сохранять применимость, порядок, поведение при отказе и пропуске.

Ревью и исправление

Цикл ревью через InputSchema вместо файлов

Обратная связь при ревью передаётся через текстовые поля inputSchema вместо персистентных файлов. Агент теряет контекст между итерациями.

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

❌ Review node → inputSchema: { feedback: string } → Fix node reads feedback from input
   // Обратная связь эфемерна, теряется при повторе

✅ Review node writes review.md → Fix node reads review.md
   // Результаты сохраняются между итерациями и повторами

Положительная формулировка контракта — в Ревью субагентом.

Управляющая алгебра вокруг review-loop

Обычный review-loop превращается во вторую state machine с pass IDs, счётчиками, замороженными наборами замечаний, status codes, reset-ветками и лимитами, хотя у этих значений нет отдельного продуктового требования.

Обнаружение: для управления ревью используется больше состояния, чем для создания и проверки самого артефакта.

❌ review → pass-id/counter/frozen-findings/status/limit machinery → fix → review
✅ change → review { issues_count } → issues_count == 0 ? next : fix → review

Добавляйте лимиты и эскалацию только при реальном требовании к retry policy, а не механически к каждому review-loop.

Неизменный или неограниченный повтор

Цикл повторяется, когда нового нет ничего: тот же артефакт, тот же вход, то же внешнее состояние и ни одной новой диагностической гипотезы. Если исправление не может изменить или воспроизвести замечание, правильное поведение — сообщить об этом владельцу или пользователю. Счётчики, добавленные только ради видимости ограниченности, эту проблему не решают: они лишь ограничивают число одинаковых попыток.

Смешение валидации и исправления

Одна нода и диагностирует, и чинит, поэтому исправление никто не подтверждает независимо, а отчёт описывает состояние до изменения. Держите валидатор отдельно, отдайте изменение владельцу исправления и верните изменённый артефакт тому же валидатору.

Повтор нерелевантных проверок

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

Рецензент проектирует машинерию

Рецензент вместо доказательства дефекта предлагает новые поля, протоколы, циклы и слои абстракции ради надёжности, которой никто не требовал. Результат работы рецензента — воспроизводимые находки по согласованному артефакту.

От рецензента требуют найти замечание

Ноль блокирующих замечаний — валидный результат ревью. Рецензент, обязанный что-то вернуть, ищет, пока не найдёт предпочтение в наименовании или гипотетическую будущую потребность, и цикл исправления начинает крутиться вокруг не-дефектов.

Рецензент без модели движка

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

Валидация и стоимость

Неверный порядок стоимости и размножение валидации

Дорогие или зависящие от окружения проверки идут раньше дешёвых детерминированных, поэтому отсутствующая предпосылка обнаруживается после долгого прогона; либо полный набор повторяется из-за небольшого позднего изменения, доказательства по которому уже дают точечные проверки.

❌ полный прогон браузера и интеграции → и только потом выясняется, что артефакт не проходит схему
✅ идентичность и доступ → дешёвые структурные проверки → runtime → дорогие проверки → ревью

Изменение после финального гейта

Финальный артефакт меняется после гейта, доказательства которого этим и обесцениваются: правка после одобрившего ревью, план, отредактированный после приёмки. Любое изменение происходит до зависящих от него гейтов, либо запуск возвращается к самому раннему гейту, чьи доказательства устарели.

Фиксированная оценка семантического качества

Архитектуру, полноту, тестируемость или сохранность семантики сводят к пороговому числу, и проходной балл считают разрешением принять регресс в другом месте. Обязательные гарантии — жёсткие гейты; диагностика стоимости остаётся отдельной и не компенсирует потерянное поведение.

Тот же дефект приходит в виде минимума: число источников, альтернатив, записей о решениях, тест-кейсов. Требование от выдуманного порога отличает происхождение числа. Порог, заданный внешним обязательством, выражает требование, и его нарушение видно снаружи прогона. Порог, придуманный внутри флоу, не различает два состояния результата: разница между семью источниками и восемью ничего не говорит о том, отвечает ли исследование на свой вопрос, а достигается добавлением восьмого.

Признак: спросите, что означало бы соседнее значение. Если ничего — число подменяет чтение, которого никто не выполнил.

Объём работ и полномочия

Несанкционированные побочные эффекты

Публикация, удаление, перезапись, переключение внешнего контекста или другое внешнее изменение, выполненное потому, что инструмент это позволяет. Доступность инструмента не является разрешением — им является задача пользователя или явное согласование. Разные решения пользователя обязаны приводить к наблюдаемо разным маршрутам или запросам.

Массовая правка без трассировки ответственностей

Концепт удаляют или переименовывают по всему workflow, прочитав план, а не граф. Он молча уносит с собой свои маршруты, артефакты и условия пропуска, и потеря всплывает позже запуском, который заканчивается не там. До изменения исследуйте его определения, все использования, входящие и исходящие связи, артефакты, маршруты отказа и пропуска и любой внешний контракт, который от него зависит.

Проектная политика, возведённая в универсальную

Одна VCS, CI, структура каталогов, названия команд, интерфейс, тестовый фреймворк или политика документации конкретного проекта зашиваются в общий workflow, который затем всюду промахивается. Общий workflow выясняет применимые локальные правила, а не утверждает их.

Планирование правки вслепую к дефектам источника

Правку планируют только под запрошенное изменение, пока источник уже несёт дефекты, которых никто не искал. План аккуратно чинит одно, а workflow продолжает падать по причинам, видимым всё это время, и всплывает это позже как «несвязанная» поломка.

Увидеть эти дефекты позволяет аудит полного источника по этому каталогу. Запускать ли аудит и какие его находки войдут в объём работы — решение пользователя: это его время и его объём, а не шаг, который workflow делает сам.

Механический план реализации

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

Полезный план фиксирует результат, scope, контракты, инварианты, зависимости, критерии приёмки, поведенческие проверки и существенные риски. Известные ноды и файлы — точки входа, а не исчерпывающий allowlist, если внешний контракт явно не требует обратного.

План, который несёт сам результат

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

Там, где результат — код, план и результат лежат в разных средах, и высота держится сама. Там, где результат — проза (документация, задания субагентам, свод правил, аналитика), они делят одну среду, и ничто не разделяет их по построению. Тогда ревью плана рецензирует результат, ревью результата читает тот же текст второй раз, и ни один гейт не судил шаг, который должен был его произвести.

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

Порядок изложения принят за порядок работы

Присланный человеком чеклист трактуется как очередь, и флоу запрещает исполнителю его переупорядочивать. Список, написанный человеком, — запись хода мысли: условие, от которого зависит первый пункт, часто осознаётся на третьем и там же записывается, а замечание, управляющее всей работой, попадает в середину и выглядит очередным пунктом.

Содержание и полнота принадлежат автору списка — переписывать пункт, выбрасывать его или дописывать незаказанную работу по-прежнему нельзя. Очередь принадлежит исполнителю: он единственный видит, что второй пункт не начать, пока третий не произвёл нужное.

Признак: один запрет, покрывающий обе вещи сразу, — чаще всего через слово renumber, которое читается и как «не переписывай пункты», и как «не вычисляй очередь».

Обязательная избыточность каждого пункта плана

Правило требует, чтобы каждый пункт безусловно повторял все нюансы и дублировал все сквозные действия, потому что исполнитель может получить пункт в одиночку.

Проблема настоящая, безусловный ответ — нет. Пункт разрастается, пока не начинает нести результат (пункт выше), а повторённый текст становится вторым источником правды и расходится. Назовите, что нужно исполнителю в изоляции, и оставьте дублирование на суждение по каждому пункту.

Инструкции и контекст

Вынесение критических инструкций в файлы

Перемещение важных инструкций и стандартов агента из значения default в variableRegistry во внешние файлы с ожиданием, что агент будет читать их каждый раз. Это создаёт риск галлюцинаций и добавляет лишний ввод-вывод.

Обнаружение: Директива говорит «прочитай правила из файла X» для контента, который должен быть стабильно доступен. Инструкции, критичные для поведения агента, хранятся вне workflow.

❌ Directive: "Read planning standards from ./standards.md before creating plan"
   // Агент может пропустить чтение, вспомнить из обучающих данных или прочитать выборочно
   // Дополнительная операция ввода-вывода на каждом шаге, требующем этих правил

✅ Declare as a variableRegistry default: planning_standards = "1. Each step must... 2. Tests built-in..."
   Directive: "Create plan following {{planning_standards}}"
   // Движок workflow гарантирует доставку; нет ввода-вывода; нет риска галлюцинаций

Этот антипаттерн относится к инструкциям, которые агент ДОЛЖЕН следовать постоянно. Вынесение допустимо для больших справочных данных, которые агенту нужны лишь изредка (например, датасет на 100KB).

Справочник без адреса

Свод критериев, переживающий шаг, — правила планирования, инженерные принципы, контракт ревью — существует только текстом, отрендеренным в директивы нод, и потому нигде не имеет адреса.

Читателю, которому нужна одна секция, приходит весь свод, заново при каждом визите, хотя с начала запуска в нём ничего не менялось. Хуже другое: читателю вне контекста запуска текст не доставить вообще — субагент не видит директиву родителя, поэтому родитель начинает копировать свод в промпт, и одни и те же критерии оказываются в двух расходящихся местах.

Дефект — отсутствие адреса, повторная доставка лишь симптом. Решение — справочник, который запуск пишет себе сам: источник остаётся в реестре, запуск записывает его один раз, а читатели обращаются по пути.

Принудительное перечитывание вслепую

Директива приказывает тому же агенту заново открыть файл, который он только что написал и держит в контексте, или ведёт состояние вида file_loaded, чтобы угадать, что агент помнит. Назовите канонический путь и позвольте агенту прочитать файл, когда содержимое отсутствует, неточно, изменилось или нужно дословно. С независимым рецензентом иначе: он сам изучает свои первоисточники.

Строительные леса под прежние возможности

Церемония, оставшаяся только потому, что она требовалась прежним моделям: фиксированное число поисков, рецепты имён файлов, обязательные шаблоны плана, предписанные последовательности инструментов и микрошаги, разнесённые по ходам. Каждому из этого нужен действующий контракт или воспроизведённый сбой.

Директива как строевая команда

Директива расписывает последовательность действий, которую исполнитель вывел бы из цели сам, либо повышает голос, чтобы правило запомнилось, — капс, значки, MANDATORY, NEVER, CRITICAL, FIX IT, NO REPORTS, — и обычно делает и то и другое.

Громкость не добавляет исполнимости. Нет состояния мира, в котором «сделай это ДЕЙСТВИТЕЛЬНО критично» выполнено или нарушено, поэтому такое требование нельзя ни принять, ни отвергнуть, и исполнитель исполняет форму вместо того, чтобы судить о работе. Шаги дают сбой с другой стороны: они верны только для случая, который представлял автор, и исполнитель, встретивший другой, либо идёт по ним к неверному результату, либо перестаёт читать директиву всерьёз.

Признак, две половины. Уберите капс и значки: если правило перестало чего-либо требовать, требования и не было — был тон. Либо прочитайте шаги и спросите, пришёл ли бы к ним исполнитель, держащий цель, сам: директива, построенная как «ШАГ 1 … ШАГ 2 …», может быть тихой и всё равно оставаться строевой командой.

Связанное

• Минимальный граф — форма, которую эти ошибки искажают
• Ревью субагентом — контракт ревью и исправления
• Цикл валидации — ограниченная проверка вокруг ноды
• Статическая конфигурация workflow — когда default реестра уместен