Jira is Turing-Complete

查看原文 / View Original 编辑 / Edit

Jira is Turing-Complete

Jira 是图灵完备的

Nicolas Seriot | 2026年5月22日

Engineering folklore holds that Jira (Atlassian’s project-tracking tool) is Turing-complete. Existing claims point vaguely at automation features without exhibiting a reduction. This article supplies a proof, with setup instructions and execution trace. 工程界的传说一直认为 Jira（Atlassian 的项目跟踪工具）是图灵完备的。现有的说法大多只是模糊地指向其自动化功能，而没有给出具体的归约证明。本文将提供一个证明，并附带设置说明和执行跟踪。

Mapping the Computational Model

计算模型的映射

A Minsky register machine needs only two unbounded counters and a finite set of labeled instructions: Minsky 寄存器机只需要两个无界计数器和一组有限的标记指令：

  • INC r; goto S
  • DEC r; if r == 0 goto S else goto S

Or, in plain English: increment register R, then goto some state; decrement register R, if R == 0 goto some state, else goto some other state. 或者用通俗的话说：增加寄存器 R，然后跳转到某个状态；减少寄存器 R，如果 R 为 0 则跳转到某个状态，否则跳转到另一个状态。

A Minsky program that adds register A into register B looks like: 一个将寄存器 A 加到寄存器 B 的 Minsky 程序如下：

  1. DEC A; if A == 0 goto 3 else goto 2
  2. INC B; goto 1
  3. HALT

Minsky proved this model Turing-complete (1967). Exhibiting it in Jira’s automation language therefore establishes the reduction. Here is how the model maps onto Jira: Minsky 在 1967 年证明了该模型是图灵完备的。因此，在 Jira 的自动化语言中实现它就确立了归约关系。以下是该模型映射到 Jira 的方式：

  • Minsky Machine: Register A (Count of linked issues of type Bug), Register B (Count of linked issues of type Task), Program Counter (Status of a single Epic issue), Dispatch Table (Jira Automation rules, one per instruction state), Clock (Automation-triggered transitions, or external re-triggering past chain caps).
  • Minsky 机： 寄存器 A（Bug 类型关联问题的数量），寄存器 B（Task 类型关联问题的数量），程序计数器（单个 Epic 问题的状态），分发表（Jira 自动化规则，每个指令状态对应一条），时钟（自动化触发的转换，或超出链式限制后的外部重新触发）。

The Epic’s status encodes the current instruction. Automation rules inspect the linked-issue counts and decide the next status. INC and DEC are implemented as issue creation and deletion on the appropriate linked-issue type. Conditional branching is implemented as a JQL-conditioned rule. Epic 的状态编码了当前的指令。自动化规则检查关联问题的数量并决定下一个状态。INC 和 DEC 通过在相应的关联问题类型上创建和删除问题来实现。条件分支则通过 JQL 条件规则来实现。

Implementing Addition

实现加法

Here is a minimal working implementation using one Epic, five linked issues, and one Automation rule per instruction state (Space Settings > Automation). 这是一个最小化的工作实现，使用一个 Epic、五个关联问题，以及每个指令状态对应一条自动化规则（空间设置 > 自动化）。

  1. Create Workflow: Create a Jira Workflow with statuses initial state BACKLOG, then TODO, DEV and PROD. Any state can transition to any other. Create an Epic in status BACKLOG.

  2. 创建工作流： 创建一个 Jira 工作流，包含初始状态 BACKLOG，以及 TODO、DEV 和 PROD。任何状态都可以转换到其他任何状态。创建一个处于 BACKLOG 状态的 Epic。

  3. Create Rule for TODO: DEC A; if A=0 halt, else goto DEV. Trigger: Epic status changed to TODO. If at least one linked Bug exists: delete one Bug, transition Epic to DEV. Else: transition Epic to PROD (halt).

  4. 创建 TODO 规则： DEC A；如果 A=0 则停止，否则跳转到 DEV。触发器：Epic 状态变为 TODO。如果存在至少一个关联的 Bug：删除一个 Bug，将 Epic 转换为 DEV。否则：将 Epic 转换为 PROD（停止）。

  5. Create Rule for DEV: INC B; goto TODO. Trigger: Epic status changed to DEV. Create a new Task, link it to the Epic. Transition Epic to TODO. Both rules have “Allow rule to trigger other rules” enabled.

  6. 创建 DEV 规则： INC B；跳转到 TODO。触发器：Epic 状态变为 DEV。创建一个新的 Task，并将其关联到 Epic。将 Epic 转换为 TODO。两条规则都启用了“允许规则触发其他规则”。

  7. Init Registers: Link 2 Bugs (A=2) and 3 Tasks (B=3) to the Epic.

  8. 初始化寄存器： 将 2 个 Bug (A=2) 和 3 个 Task (B=3) 关联到该 Epic。

  9. Bootstrap the Machine: Transition the Epic to TODO to start the cascade.

  10. 启动机器： 将 Epic 转换为 TODO 以启动级联。

Five transitions: (2,3) TODO → (1,3) DEV → (1,4) TODO → (0,4) DEV → (0,5) TODO → (0,5) PROD. Recorded on a real *.atlassian.net instance. The Epic lands in PROD with 0 Bugs and 5 Tasks linked. We’ve just added 2 + 3 = 5. 五次转换：(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 的加法。

Fibonacci in Two States

双状态下的斐波那契数列

The reduction above suffices to prove Turing-completeness. Jira’s automation language makes non-trivial programs tractable by using Convert Issue Type. Jira’s Convert Issue Type action changes an issue’s type instantly: Bug → Story, Story → Task, and so on. A single Convert merges DEC-on-one-register with INC-on-another into one atomic operation. 上述归约足以证明图灵完备性。Jira 的自动化语言通过使用“转换问题类型”功能，使得处理非平凡程序变得可行。Jira 的“转换问题类型”操作可以瞬间改变问题的类型：Bug → Story，Story → Task 等。单次转换将一个寄存器的 DEC 和另一个寄存器的 INC 合并为一个原子操作。

Fibonacci as (A, B) → (B, A+B) collapses to two states with three registers (A=Bug, B=Task, C=Story), using TODO and QA as the two instruction states. 斐波那契数列 (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.
  • TODO： 如果存在关联的 Bug：转换 Bug → Story，INC Task，转换到 TODO；否则：转换到 QA。
  • QA: if any linked Story exists: Convert Story → Bug, transition to QA; else: transition to TODO.
  • QA： 如果存在关联的 Story：转换 Story → Bug，转换到 QA；否则：转换到 TODO。

Initial state A=1, B=1, C=0. The sequence 1, 1, 2, 3, 5, 8, 13, … appears in B (Task count). Unlike the addition machine, the Fibonacci machine has no halt state. It runs until Jira Cloud’s chain-depth cap of 10 triggers, at which point the operator re-triggers the Epic to continue. 初始状态 A=1, B=1, C=0。序列 1, 1, 2, 3, 5, 8, 13, … 出现在 B（Task 计数）中。与加法机不同，斐波那契机没有停止状态。它会一直运行直到触发 Jira Cloud 的 10 层链式深度限制，此时操作员只需重新触发 Epic 即可继续。

Conclusion

结论

Jira’s automation language can encode a two-counter machine given unbounded issue creation and rule execution. Every physical computer is finite, so Jira Cloud’s finite quotas do not refute the construction. Under that standard convention, Jira is Turing-complete. So, if complex Jira automations feel like programs, it is because they literally are. 在拥有无限制的问题创建和规则执行能力的前提下，Jira 的自动化语言可以编码一个双计数器机器。每一台物理计算机都是有限的，因此 Jira Cloud 的有限配额并不能反驳这一构造。按照这一标准惯例，Jira 是图灵完备的。所以，如果复杂的 Jira 自动化看起来像程序，那是因为它们本质上就是程序。

← 返回新闻列表 / Back to news list