Flownix
Начать
Разделы
На этой странице

Закрыть задачу в строгом режиме

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

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

Включить

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

Агент тоже умеет, если руки заняты:

в сессии агента
включи строгий режим спеки

Он вызовет set_project_policy и перепишет режим в .flownix — тем значением, которое вернул сервер, а не тем, которое просили. Они расходятся, если запись отклонена, а конфиг читается остальными скиллами как факт.

Строгий режим — первая из трёх политик спеки, и остальные две без него не работают. Что даёт каждая — в объяснении; порядок работы, который включает третья, — в руководстве по spec-first.

Что требуется для закрытия

Ровно одно из двух. Третьего варианта нет — в этом весь смысл.

Документируемое поведение изменилось

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

shell
propose_doc_delta({ doc_slug, source_node_slug, body: "<весь документ целиком>", reason })
apply_doc_delta({ revision_id })

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

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

Поведение не менялось

shell
declare_no_spec_impact({ slug, reason: "<предложение, называющее что менялось и почему это не документируемое поведение>" })

Причина — предложение, а не отписка. «n/a», «нет» и односложные ответы сервер отклоняет. Если написать причину не выходит — скорее всего, поведение всё-таки изменилось, и нужна дельта.

Как это выглядит в работе

  1. Агент выполняет задачу.
  2. Перед закрытием спрашивает себя: изменился ли контракт или поведение, описанное документацией?
  3. Да — предлагает и применяет дельту. Нет — объявляет отсутствие влияния с причиной.
  4. Только после этого статус done принимается.

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

Кому это нужно

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

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

Дальше