workflow-ai 1.1.0 → 1.3.0

package/src/skills/decompose-plan/knowledge/atomicity-checklist.md

@@ -1,139 +0,0 @@
-# Чеклист атомарности тикета
-
-Каждый тикет проходит проверку атомарности **до** создания. Если тикет не атомарен — разбей его.
-
-## Определение
-
-**Атомарный тикет** — тикет, который решает ровно одну задачу, изменяет минимальный набор файлов и может быть выполнен за одну сессию без переключения контекста.
-
-## Чеклист (все проверки обязательны)
-
-### Проверка 1: Одна задача
-
-- [ ] Можно описать суть тикета **одним предложением** без «и», «а также», «плюс»?
-- [ ] Тикет содержит **один** глагол действия (реализовать / исправить / добавить / перенести)?
-
-**Если нет** → разбей по глаголам: каждое действие = отдельный тикет.
-
-### Проверка 2: Один объект изменения
-
-- [ ] Тикет затрагивает **один** логический модуль (один файл или группу тесно связанных файлов одной подсистемы)?
-- [ ] Изменения НЕ затрагивают несвязанные подсистемы (например, UI + backend + config одновременно)?
-
-**Если нет** → разбей по модулям: каждый модуль = отдельный тикет с зависимостями.
-
-> **⚠️ Один файл ≠ один объект.** Файл может содержать несколько независимых логических блоков (test suites, классы, обработчики). Если правки в файле затрагивают **разные, независимые блоки** с разными целями — каждый блок может быть отдельным объектом изменения. Критерий: могут ли правки блока A быть применены и проверены без правок блока B? Если да — это разные объекты.
-
-### Проверка 3: Один результат
-
-- [ ] У тикета ровно **один** измеримый критерий готовности (или несколько, но все проверяют одно и то же)?
-- [ ] Критерий готовности проверяется за одно действие (один тест, одна команда, один визуальный осмотр)?
-
-**Если DoD содержит несвязанные критерии** → каждый независимый критерий = отдельный тикет.
-
-### Проверка 4: Нет скрытых подзадач
-
-- [ ] В «Деталях задачи» **нет** нумерованного списка из 2+ шагов, где шаги независимы друг от друга?
-- [ ] Каждый шаг требует предыдущий (цепочка), а не является самостоятельной работой (параллель)?
-
-**Если шаги независимы** → каждый независимый шаг = отдельный тикет.
-
-### Проверка 5: Оценка размера
-
-- [ ] Ожидаемый объём изменений < 200 строк кода?
-- [ ] Ожидаемое время выполнения ≤ 2 часа? Превышение допускается только при доказанной неделимости задачи.
-- [ ] **Число пунктов DoD ≤ 7** (hard-порог машинной проверки `verify-atomicity.js`). Рекомендуемая цель — ≤ 5 (мягкий WARN-порог); 6–7 пунктов допустимы, но считаются предупреждением. **8 и более — FAIL: тикет будет отклонён пайплайном, декомпозиция уйдёт на повторную попытку.**
-
-**Если больше** → ищи границу разбиения: по файлам, по этапам, по подсистемам, **или по группам DoD-пунктов** (каждая независимая группа критериев = отдельный тикет с собственным DoD).
-
-> **⚠️ Evidence для Проверки 5 — обязательно указывать фактическое число пунктов DoD.** Формулировка «DoD содержит N пунктов» с явной цифрой — обязательный элемент evidence-строки. Голый PASS без числа не валиден: именно по этому инварианту падает `verify-atomicity.js`, а не по объёму строк кода или времени выполнения, которые агент оценивает на глаз.
-
-> **⚠️ Пороги в этой проверке и в `verify-atomicity.js` — связанная пара.** Пороги ≤ 5 (WARN), ≤ 7 (FAIL), > 7 (FAIL) должны совпадать с константами `DOD_THRESHOLD_WARN` / `DOD_THRESHOLD_FAIL` в `scripts/verify-atomicity.js`. Если один файл правится — второй обязан быть синхронизирован в той же правке.
-
-### Проверка 6: Независимая верификация
-
-- [ ] Результат тикета можно проверить **независимо** от других тикетов того же плана?
-- [ ] Не нужно ждать завершения других тикетов, чтобы убедиться что этот сделан правильно?
-
-**Если нет** → это часть более крупной задачи. Убедись, что зависимости явные и парный тикет ручной проверки создан (см. `workflows/decompose.md` шаг 2 → «Парные тикеты ручной проверки»).
-
-### Проверка 7: Один исполнитель (executor-атомарность)
-
-- [ ] Все пункты DoD выполнимы **одним типом тикета** из `config.yaml → task_types` (тот же префикс, что назначен создаваемому тикету)?
-- [ ] Ни один пункт DoD не требует действия, относящегося к ответственности другого типа тикета или к действиям стейкхолдера (git-операции, мерж, деплой, релизные решения)?
-
-**Если нет** → разбей по исполнителю: каждый тип работы = отдельный тикет со своим префиксом, связанный через `dependencies`.
-
-**Критерий проверки:** для каждого пункта DoD задай вопрос — «Если бы этот пункт был единственной задачей, какой тип из `config.yaml → task_types` был бы выбран маршрутизацией на шаге 4 workflow?» Если ответы расходятся между пунктами DoD одного тикета — тикет не executor-атомарен.
-
-**Признаки нарушения:**
-- Пункт DoD описывает действие, для которого в `config.yaml` существует отдельный, более точный тип тикета, чем назначенный текущему.
-- Пункт DoD описывает действие, которое по проектным правилам выполняет стейкхолдер или внешняя стадия пайплайна, а не агент-исполнитель тикета (git-коммиты, пуши, мержи, релизы, ручные ревью).
-- Пункт DoD ссылается на успешное завершение другого тикета того же плана как на условие закрытия текущего (это зависимость, а не критерий готовности).
-
-**Почему это отдельная проверка, а не часть «Одного результата»:** разные пункты DoD могут проверять «одно и то же» семантически, но выполняться разными исполнителями в разных сессиях/стадиях. Кросс-исполнительская зависимость делает тикет невыполнимым за одну сессию — даже если смысловое ядро одно.
-
-**Граничный случай:** если проектный тип тикета явно включает сопутствующее действие в ответственность исполнителя (например, тесты как часть реализации), такой DoD-пункт остаётся внутри одного тикета. Источник правды — описание типа в `config.yaml` и проектный README. Если описание типа неоднозначно — трактуй в пользу разбиения.
-
-## Правило по умолчанию: при сомнении — разбивай
-
-Если после прохождения чеклиста остаётся сомнение в атомарности — **разбивай тикет**.
-
-Лишний тикет стоит дёшево: один файл, одна зависимость. Слитый тикет с несколькими задачами стоит дорого: риск частичного выполнения, неясный DoD, сложная верификация, блокировка всей задачи из-за одного подшага.
-
-**Критерий «достаточно мелкий»:** тикет, который агент может выполнить линейно, без необходимости принимать стратегические решения о следующем шаге внутри тикета.
-
-**⛔ Антипаттерн «сжатие вместо разбиения».** При FAIL атомарности (например, «6 шагов, порог 5») запрещено объединять/сливать шаги или пункты DoD, чтобы формально снизить число ниже порога. Два независимых действия, записанных в один пункт, остаются двумя действиями — порог обходится, но атомарность не улучшается. Единственная допустимая реакция на FAIL — разбиение тикета на 2+, каждый из которых проходит все 7 проверок самостоятельно.
-
-## Паттерны разбиения
-
-| Сигнал неатомарности | Стратегия разбиения |
-|----------------------|---------------------|
-| «Реализовать X и Y» | Тикет на X + тикет на Y |
-| «Изменить A.ts, B.ts, C.ts» (несвязанные) | Тикет на каждый модуль |
-| DoD с 3+ несвязанными пунктами | Тикет на каждый пункт |
-| «Добавить функцию + написать тесты + обновить docs» | Прогоняй Проверку 7 по `config.yaml → task_types`: если реализация и тестирование — разные типы, разбей по исполнителю |
-| «Провести рефакторинг модуля» (> 5 файлов) | По подсистемам или по этапам (extract → rename → cleanup) |
-| Список шагов, где шаги 1-3 независимы | 3 тикета без зависимостей |
-| DoD-пункты требуют разных типов из `config.yaml → task_types` | По типу исполнителя — парные тикеты с `dependencies` |
-| Пункт DoD описывает git-операцию (commit, merge, push, release) | Удалить из DoD — это действие стейкхолдера, не исполнителя |
-
-## Граничные случаи
-
-| Случай | Решение |
-|--------|---------|
-| Функция + unit-тест к ней | Определяется Проверкой 7: если в `config.yaml → task_types` реализация и тестирование — один тип, то **один** тикет; если разные (например, есть отдельный QA-тип) — **два** тикета с `dependencies` |
-| Функция + интеграционный тест в отдельном окружении | **Два** тикета (разные executor, разное окружение) |
-| Правка одной строки в 3 файлах | **Один** тикет (если правка семантически едина) |
-| «Обновить все импорты после переименования» | **Один** тикет (механическая операция, один контекст) |
-| Обновление нескольких независимых test suites в одном файле | **Несколько** тикетов, если suites тестируют разные аспекты и правки в каждой suite независимы |
-
-## Пример разбиения задачи плана на тикеты
-
-**Задача плана:** «Ручная проверка исправлений дефекта A и дефекта B: продуктовые сценарии»
-
-Задача содержит 5 TC:
-- TC 1-2 — проверка дефекта A (валидация входных данных)
-- TC 3-4 — проверка дефекта B (поведение после удаления сущности)
-- TC 5 — smoke базовых операций
-
-**Прогон чеклиста для задачи «как есть»:**
-
-| Проверка | Результат | Причина |
-|----------|-----------|---------|
-| 1. Одна задача | **FAIL** | Проверяет два независимых дефекта |
-| 2. Один объект | **FAIL** | Дефект A = валидация, дефект B = удаление — разные подсистемы |
-| 3. Один результат | **FAIL** | TC 1-2 и TC 3-4 — несвязанные критерии |
-| 4. Нет скрытых подзадач | **FAIL** | TC 1-2 независимы от TC 3-4 |
-| 5. Размер | PASS | |
-| 6. Независимая верификация | **FAIL** | TC 1-2 зависят от fix-A, TC 3-4 от fix-B |
-| 7. Один исполнитель | PASS | Все три TC-группы — один тип (ручная проверка) по `config.yaml` |
-
-→ Решение: **РАЗБИТЬ на 3 тикета:**
-1. Ручная проверка дефекта A (TC 1 + TC 2) — `dependencies: [fix-A]`
-2. Ручная проверка дефекта B (TC 3 + TC 4) — `dependencies: [fix-B]`
-3. Smoke базовых операций (TC 5) — `dependencies: [fix-A, fix-B]`
-
-Каждый результирующий тикет проходит чеклист → все 7 проверок PASS.
-
-<!-- РАСШИРЕНИЕ: добавляй паттерны и граничные случаи ниже -->

package/src/skills/decompose-plan/knowledge/capabilities.md

@@ -1,68 +0,0 @@
-# Назначение required_capabilities при декомпозиции
-
-Каждый тикет может требовать от агента-исполнителя определённых возможностей
-(capabilities). Пайплайн фильтрует список кандидатов-агентов по этому полю:
-агент, не покрывающий все `required_capabilities` тикета, не может быть
-выбран. Если ни один совместимый агент не найден — тикет блокируется.
-
-## Когда задавать required_capabilities
-
-Разбирая каждый тикет, сформулируй по описанию Definition of Done, что
-агенту физически нужно сделать для выполнения задачи. Задай вопросы:
-
-1. Требуется ли читать или интерпретировать изображения, скриншоты,
-   визуальный вывод (UI, графики, диаграммы, фото)?
-2. Требуется ли поиск актуальной внешней информации — документация,
-   стандарты, версии, бенчмарки?
-3. Требуется ли работа с очень большим объёмом контекста — анализ
-   кодовой базы целиком, многосотенные файлы одновременно?
-4. Требуется ли другая возможность, декларированная в конфигурации
-   проекта (`agents.*.capabilities` в pipeline-конфиге)?
-
-Если ответ «да» хотя бы на один вопрос — добавь соответствующий ключ в
-`required_capabilities` тикета. Если ни один критерий не срабатывает —
-оставь список пустым.
-
-## Принцип минимальности
-
-Список `required_capabilities` должен быть минимальным и точным:
-
-- **Не добавляй capability «на всякий случай».** Каждый лишний ключ
-  сокращает множество совместимых агентов и повышает риск блокировки
-  тикета по причине `no_capable_agent`.
-- **Не пропускай capability, если она действительно нужна.** Тикет,
-  отданный несовместимому агенту, провалится на стадии review, и
-  неудача потратит слот из списка кандидатов.
-
-## Источник допустимых значений
-
-Перечень капабилити-ключей определяется конфигурацией проекта —
-`agents.*.capabilities` в pipeline-конфиге. **Реестр ключей замкнутый:** capability существует только если она перечислена в `agents.*.capabilities` хотя бы у одного агента. Ключи, отсутствующие в реестре, — **несуществующие**, и тикет с таким ключом физически не может быть исполнен (блокируется по `no_capable_agent`).
-
-### ⛔ Обязательная процедура перед заполнением `required_capabilities`
-
-**Выполняется один раз в начале декомпозиции плана**, до создания первого тикета:
-
-1. **Прочитай** `.workflow/config/pipeline.yaml` (или аналогичный pipeline-конфиг проекта — путь см. в SKILL.md / конфигурации).
-2. **Выпиши** union всех значений `agents.*.capabilities` в явный список. Это **единственный допустимый словарь** для поля `required_capabilities` на всю декомпозицию. Зафиксируй список текстом в рассуждении перед шагом 9.1 — без фиксации шаг считается невыполненным.
-3. При назначении `required_capabilities` каждому тикету **сверяйся только с этим выписанным списком**. Любой ключ, которого в списке нет, — изобретённый.
-
-### ⛔ Антипаттерн: изобретение ключей по предметной области
-
-Типичная ошибка: агент назначает capability, описывающую **предметную область задачи** (язык программирования, тип проекта, фреймворк, подсистему), а не возможность агента-исполнителя.
-
-**Критерий различения:**
-- Capability — свойство **агента** («агент умеет X»). Пример: `multimodal` — агент умеет читать изображения.
-- Предметная область — свойство **задачи** («задача про X»). Пример: «задача про TypeScript-код» — это описание задачи, а не требование к агенту.
-
-Если ты хочешь выразить «задача предметной области Y» — это **не capability**. Это просто описание задачи; оно уже содержится в `title`, `description`, `context.files`. Не дублируй его в `required_capabilities`.
-
-**Правило:** прежде чем записать ключ в `required_capabilities`, спроси себя: «Этот ключ есть в union'е, который я выписал из pipeline.yaml?» Если нет — **не записывай**, даже если он «хорошо описывает задачу».
-
-### Классы изобретений (для распознавания, не как запрет)
-
-Закрытого списка изобретённых ключей не существует — статус ключа определяется только его наличием/отсутствием в union'е реестра **текущего проекта**. Один и тот же ключ может быть валидным в одном проекте и изобретённым в другом. Всё решает сверка со словарём из пункта «Обязательная процедура».
-
-Классы-маркеры, по которым стоит насторожиться и **перепроверить словарь**, прежде чем записывать ключ: имена языков программирования, имена платформ/типов проектов, имена подсистем или аспектов (локализация, стилизация, тестирование). Эти имена описывают задачу, а не способность агента, и в подавляющем большинстве проектов в реестре отсутствуют — но если в конкретном проекте такой ключ всё же задекларирован у агентов, он валиден. Решающий критерий — строго словарь, а не класс имени.
-
-Если реестр проекта не содержит ключа, подходящего по смыслу, — поле `required_capabilities` для такого тикета остаётся пустым или содержит только ключи из словаря.

package/src/skills/decompose-plan/knowledge/human-task-rules.md

@@ -1,82 +0,0 @@
-# Правила создания HUMAN-тикетов
-
-Справочник по определению, когда задача требует участия человека, и как правильно оформить HUMAN-тикет.
-
-## Когда задача = HUMAN
-
-HUMAN-тикет создаётся только при выполнении **обоих** условий:
-1. Агент физически не может выполнить задачу (нет инструмента, доступа, прав).
-2. Задача подпадает под один из критериев таблицы ниже (HUMAN-семантика).
-
-Недоступность агенту без HUMAN-семантики → задача **не HUMAN**, а «вне scope декомпозиции» (тикет не создаётся, действие за стейкхолдером вне пайплайна). См. `workflows/decompose.md` шаг 3.
-
-| Критерий | Примеры |
-|----------|---------|
-| Требует аутентификации в приватных сервисах | Вход в CRM, аналитику, платёжные системы |
-| Физические действия | Подпись документа, отправка физического письма |
-| Требует принятия бизнес-решения | Утверждение бюджета, согласование стратегии |
-| Доступ к приватным данным | Персональные данные клиентов, NDA-защищённые материалы |
-| Оплата/финансовые транзакции | Подключение billing, оплата подписок |
-
-**Что НЕ HUMAN (типичные ошибки маршрутизации):**
-
-| Ошибочно | Правильная категория |
-|----------|----------------------|
-| Git-операции проекта (commit, push, merge, tag, release) | Вне scope декомпозиции — стейкхолдер выполняет вне пайплайна |
-| Запуск CI/CD, триггер деплоя через стандартные инструменты | Вне scope декомпозиции |
-| Прогон существующей команды (тест, линт, билд), которую агент может выполнить сам | Автономная → тип по маршрутизации шага 4 |
-| Создание тикета на «ручной коммит после выполнения всех IMPL» | Вне scope — коммит не является задачей плана |
-
-## Обязательные поля HUMAN-тикета
-
-| Поле | Требование |
-|------|-----------|
-| `type` | `human` (из `config.yaml` → `task_types.human`) |
-| `prefix` | `HUMAN` (из `config.yaml` → `task_types.human.prefix`) |
-| `executor_type` | `human` |
-| Пошаговые инструкции | Явные шаги: что именно должен сделать человек |
-| Формат результата | В каком формате ожидается результат |
-| DoD-критерий | Обязательно: «Результаты внесены непосредственно в файл тикета» |
-
-## Пример HUMAN-тикета
-
-```yaml
-id: HUMAN-010
-title: "Настроить трекинг конкурентов в аналитике"
-type: human
-executor_type: human
-```
-
-```markdown
-## Детали задачи
-
-### Инструкции для человека
-
-1. Войти в панель аналитики
-2. Перейти в раздел «Трекинг конкурентов»
-3. Добавить домены конкурентов из предшествующего тикета
-4. Настроить еженедельный отчёт
-5. Вставить ссылку на дашборд в результат этого тикета
-
-### Формат результата
-
-- Ссылка на настроенный дашборд
-- Скриншот конфигурации
-```
-
-## Антипаттерны
-
-| Антипаттерн | Почему плохо | Как правильно |
-|-------------|-------------|---------------|
-| `ADMIN` для задач с `executor_type: human` | Нарушает семантику, затрудняет фильтрацию | Используй `HUMAN` |
-| Условный HUMAN-тикет «на всякий случай» | Висит в backlog вечно, засоряет доску | Создаётся только при реальной необходимости |
-| HUMAN-тикет без пошаговых инструкций | Человек не понимает что делать | Всегда: шаги, формат, DoD |
-| Группировка agent + human работы в один тикет | Невозможно определить executor_type | Разбить на 2 тикета с зависимостью |
-
-## Гибридные задачи
-
-Если задача частично автоматизируема:
-1. **Тикет A** (`executor_type: agent`) — автономная часть
-2. **Тикет B** (`executor_type: human`, `dependencies: [A]`) — ручная часть
-
-<!-- РАСШИРЕНИЕ: добавляй новые критерии определения HUMAN-задач ниже -->

package/src/skills/decompose-plan/knowledge/scope-guard-checklist.md

@@ -1,73 +0,0 @@
-# Scope-guard: чеклист проверки перед созданием тикета
-
-Каждый тикет проходит scope-guard **до** создания. Тикеты вне scope не создаются — они записываются в «Рекомендации для следующего плана».
-
-## Чеклист (все 4 проверки — обязательны)
-
-### Проверка 1: Принадлежность к scope плана
-
-- [ ] Задача входит в секцию «Включено в scope» плана?
-- [ ] Задача НЕ входит в секцию «Исключено из scope»?
-
-**Если нет** → не создавать тикет, записать в рекомендации.
-
-### Проверка 2: Связь с задачами плана
-
-- [ ] Задача является декомпозицией конкретного пункта плана?
-- [ ] `parent_plan` заполнен и указывает на текущий план?
-
-**Если задача не привязана к пункту плана** → она вне scope.
-
-### Проверка 3: Критерии успеха
-
-- [ ] Задача необходима для достижения хотя бы одного критерия успеха текущего плана?
-
-**Если задача не влияет ни на один критерий успеха** → она вне scope.
-
-### Проверка 4: Горизонт плана
-
-- [ ] Задача реализуема в рамках горизонта текущего плана?
-- [ ] Если есть `date_after` — дата внутри горизонта плана?
-
-**Если задача за горизонтом** → записать в рекомендации для следующего плана.
-
-### Проверка 5: Не дублирует функцию пайплайна
-
-- [ ] Задача НЕ является стандартной функцией пайплайна (отчёт по плану, перемещение тикетов между статусами, ревью результатов)?
-
-**Если задача дублирует пайплайн** → не создавать тикет. Пайплайн выполнит это автоматически.
-
-Примеры задач, которые выполняет пайплайн, а не тикеты:
-- Создание отчёта по завершении плана (скил отчётности запускается пайплайном)
-- Перемещение тикетов между папками (скрипты `move-ticket.js`, `move-to-ready.js`)
-- Ревью завершённых тикетов (скил ревью запускается пайплайном)
-- Анализ отчётов (скил анализа запускается пайплайном)
-
-**Почему:** если задача пайплайна становится тикетом, она попадает к неподходящему исполнителю (другой скил, другой контекст), что приводит к потере данных при агрегации.
-
-## Что НЕ является тикетом текущего плана
-
-| Ситуация | Почему | Куда направить |
-|----------|--------|----------------|
-| Работа из «Исключено из scope» | Явно исключена | Рекомендации |
-| Follow-up после завершения плана | Это следующий этап | Рекомендации |
-| DoD другого тикета: «создать тикеты для...» | Это рекомендация, не инструкция | Рекомендации |
-| Условие `date_after` за горизонтом | Не успеть в текущем плане | Рекомендации |
-| Создание отчёта / ревью / перемещение тикетов | Стандартная функция пайплайна | Пайплайн (автоматически) |
-
-## Формат записи рекомендации
-
-```markdown
-### Рекомендации для следующего плана (вне scope)
-- [описание задачи] — причина: [почему это следующий этап]
-```
-
-## Граничные случаи
-
-| Случай | Решение |
-|--------|---------|
-| Задача на границе scope (частично входит) | Создать тикет только на часть, входящую в scope |
-| Задача в scope, но с зависимостью вне scope | Создать тикет, зависимость — в conditions |
-| Задача в scope, но горизонт под вопросом | Создать тикет, но priority: 4 (low) |
-
-<!-- РАСШИРЕНИЕ: добавляй новые проверки scope ниже -->

package/src/skills/decompose-plan/scripts/check-atomicity-limit.js

@@ -1,47 +0,0 @@
-#!/usr/bin/env node
-/**
- * check-atomicity-limit.js
- *
- * Проверяет счётчик atomicity_check_attempts без инкремента.
- * Возвращает status: "passed" если counter < max, "failed" если >= max.
- *
- * Используется как stage перед verify-atomicity для защиты от бесконечного цикла.
- * В отличие от update-counter, НЕ инкрементирует счётчик — только читает.
- *
- * Формат промпта от runner'а:
- *   Counters:
- *     atomicity_check_attempts: N
- *
- * Если counter = 0, секция Counters может отсутствовать (runner не выводит нули).
- *
- * Usage: node check-atomicity-limit.js <prompt>
- *   prompt — текст промпта (от runner'а)
- *   ИЛИ если первый аргумент --file, второй аргумент — путь к файлу с промптом
- */
-
-let prompt = '';
-
-if (process.argv[2] === '--file' && process.argv[3]) {
-  // Чтение из файла (для тестирования)
-  const fs = await import('fs');
-  const filePath = process.argv[3];
-  prompt = fs.readFileSync(filePath, 'utf-8');
-} else {
-  prompt = process.argv[2] || '';
-}
-
-// Ищем atomicity_check_attempts в промпте
-// Формат: "atomicity_check_attempts: N" (с возможным отступом)
-const match = prompt.match(/atomicity_check_attempts:\s*(\d+)/i);
-const counterValue = match ? parseInt(match[1], 10) : 0;
-
-const MAX_ATTEMPTS = 3;
-const status = counterValue >= MAX_ATTEMPTS ? 'failed' : 'passed';
-
-console.log(`---RESULT---
-status: ${status}
-atomicity_check_attempts: ${counterValue}
-max_attempts: ${MAX_ATTEMPTS}
----RESULT---`);
-
-process.exit(0);