Jira 是图灵完备的

# Jira 是图灵完备的 来源：https://seriot.ch/computation/jira.html ### Nicolas Seriot #### 计算理论 (https://seriot.ch/computation/index.html)\> Jira 是图灵完备的 *在 Atlassian Automation 中构建明斯基机* *2026 年 5 月 22 日* 工程界传闻 (https://news.ycombinator.com/item?id=17689446) 认为 Jira (https://www.atlassian.com/software/jira)（Atlassian 的项目跟踪工具）是图灵完备的 (https://esolangs.org/wiki/Turing-complete) 。现有的说法模糊地指向自动化功能，但没有展示出归约。本文提供一个证明，包含设置说明和执行跟踪。 ### 映射计算模型 明斯基寄存器机 (https://esolangs.org/wiki/Minsky_machine) 只需要两个无界计数器和一组带标签的有限指令： - `INC r; goto S` - `DEC r; if r == 0 goto S else goto S` 或者用通俗的话说： - *递增寄存器 R，然后跳转到某个状态* - *递减寄存器 R，如果 R == 0 则跳转到某个状态，否则跳转到另一个状态* 一个将寄存器 A 加到寄存器 B 的明斯基程序如下： `` 1. DEC A; if A == 0 goto 3 else goto 2 2. INC B; goto 1 3. HALT `` 明斯基 (https://en.wikipedia.org/wiki/Marvin_Minsky) 证明了该模型是图灵完备的（1967 年）。因此在 Jira 的自动化语言中展示该模型，就建立了归约。以下是模型如何映射到 Jira： 明斯基机 | Jira --- | --- 寄存器 A | 类型为 **Bug** 的关联问题数量 寄存器 B | 类型为 **Task** 的关联问题数量 程序计数器 | 单个 **Epic** 问题的状态 调度表 | Jira 自动化规则，每条指令状态对应一条规则 时钟 | 自动化触发的转换，或链上限后的外部重新触发 Epic 的状态编码当前指令。自动化规则 (https://support.atlassian.com/cloud-automation/docs/create-and-edit-jira-automation-rules/) 检查关联问题数量并决定下一个状态。`INC` 和 `DEC` 通过在相应关联问题类型上创建或删除问题来实现。条件分支通过基于 JQL 条件的规则 (https://support.atlassian.com/cloud-automation/docs/jira-automation-conditions/) 来实现。 ### 实现加法 以下是一个最小工作实现，使用一个 Epic、五个关联问题和每条指令状态对应一条自动化规则（空间设置 > 自动化）。 **1. 创建工作流** 创建一个 Jira 工作流，状态为初始状态 `BACKLOG`，然后是 `TODO`、`DEV` 和 `PROD`。任意状态都可以转换到其他任何状态。 创建一个状态为 `BACKLOG` 的 Epic。 **2. 为 TODO 创建规则** `DEC A; if A=0 halt, else goto DEV。` - 触发器：Epic 状态更改为 `TODO`。 - 如果至少存在一个关联 Bug：删除一个 Bug，将 Epic 转换为 `DEV`。 - 否则：将 Epic 转换为 `PROD`（停止）。 **3. 为 DEV 创建规则** `INC B; goto TODO。` - 触发器：Epic 状态更改为 `DEV`。 - 创建一个新的 Task，关联到该 Epic。 - 将 Epic 转换为 `TODO`。 两条规则都启用了“允许规则触发其他规则”。 下面的截图显示了这两条规则如何连接到 Epic 的工作流中。 [](https://seriot.ch/resources/jira_tc/addition_rules.png) **4. 初始化寄存器** 关联 2 个 Bug（A=2）和 3 个 Task（B=3）到该 Epic。 **5. 启动机器。** 将 Epic 转换为 `TODO` 来触发级联。五次转换： `` (2,3) TODO → (1,3) DEV → (1,4) TODO → (0,4) DEV → (0,5) TODO → (0,5) PROD `` *记录在真实的 `*.atlassian.net` 实例上。* Epic 最终状态为 `PROD`，关联了 0 个 Bug 和 5 个 Task。我们刚刚计算出了 2 + 3 = 5。 ### 两个状态下的斐波那契 上述的归约足以证明图灵完备性。Jira 的自动化语言通过使用“转换问题类型”使得非平凡程序易于处理。 Jira 的“转换问题类型”操作能立即更改问题的类型：Bug → Story，Story → Task，等等。一次转换将对一个寄存器的 DEC 和对另一个寄存器的 INC 合并为一个原子操作。它并没有扩展 Jira 的计算能力（一次转换可以表示为 DEC + INC），但大大减少了任何移动循环的调度表。 斐波那契序列 `(A, B) → (B, A+B)` 可以简化为两个状态，使用三个寄存器（A=Bug，B=Task，C=Story），并使用 `TODO` 和 `QA`（将其添加到工作流中）作为两个指令状态： `` TODO: if any linked Bug exists: Convert Bug → Story INC Task transition to TODO else: transition to QA QA: if any linked Story exists: Convert Story → Bug transition to QA else: transition to TODO `` 初始状态 A=1，B=1，C=0。序列 1, 1, 2, 3, 5, 8, 13, ... 出现在 B（Task 数量）中。 与加法机器不同，斐波那契机器没有停止状态。它一直运行直到 Jira Cloud 的链深度上限（10 个触发器），届时操作员重新触发 Epic 以继续。单次状态编辑即可重新启动级联。该归约仍然有效，只是由人来提供下一个时钟滴答。Jira Data Center 暴露了相同的 `automation.rule.execution.timeout` 及相关可配置属性。 ### 结论 给定无限的问题创建和规则执行，Jira 的自动化语言可以编码一个双计数器机器。每台物理计算机都是有限的，因此 Jira Cloud 的有限配额并不否定该构造。按照这一标准约定，Jira 是图灵完备的。 所以，如果复杂的 Jira 自动化感觉像程序，那是因为它们本质上就是程序。