Инженер Николас Серио представил доказательство, которое раньше существовало только в виде слухов: Jira действительно тьюринг-полна. Он собрал конкретную реализацию — машину Минского на базе Atlassian Automation.
В основе модели — два бесконечных счётчика и набор команд INC и DEC с условными переходами. В Jira счётчиками выступают количества связанных задач: Bug и Task. Программный счётчик кодируется статусом одного Epic, а диспетчеризацией команд занимаются правила Automation — по одному правилу на каждое состояние.
Например, программа сложения двух чисел умещается в два правила. Первое (TODO): если есть хотя бы один связанный Bug — удалить его и перевести Epic в DEV. Если Bug'ов нет — остановиться. Второе правило (DEV): создать новый Task, привязать к Epic, вернуть Epic в TODO. Серио запустил эту схему на реальном *.atlassian.net и получил ожидаемый результат: 2+3=5, пять шагов, в PROD остаётся 0 Bug'ов и 5 Task'ов.
Дальше — интереснее. Jira-автоматизация умеет конвертировать типы задач (Convert Issue Type): Bug → Story, Story → Task. Хотя это просто синтаксический сахар поверх DEC + INC, он резко упрощает код. Серио реализовал числа Фибоначчи, используя три статуса (TODO, QA, DEV) и три счётчика (Bug, Task, Story). Правила перебирают задачи одного типа, конвертируют их в другой и инкрементируют третий. Последовательность 1, 1, 2, 3, 5, 8, 13… появляется в счётчике Task.
Ограничение есть — цепочка правил в Jira Cloud обрывается после 10 триггеров. Эту проблему решает человек: достаточно вручную изменить статус Epic, чтобы каскад пошёл заново. Для Jira Data Center настройка automation.rule.execution.timeout позволяет ослабить лимит.
Вывод: если ваши автоматизации в Jira начинают напоминать программу — так и есть. Jira тьюринг-полна, и это больше не фольклор, а доказанный факт.