Jira 是图灵完备的
Jira Is Turing-Complete

原始链接: https://seriot.ch/computation/jira.html

Nicolas Seriot 通过成功实现一台明斯基寄存器机(Minsky register machine),证明了 Jira 的自动化引擎是图灵完备的。通过将寄存器映射为关联问题的数量,并利用 Jira 的状态来表示程序计数器,Seriot 证明了 Jira 的自动化规则可以执行任何计算任务。 这一证明的基础在于利用 Jira Automation 来操作关联问题(具体为创建和删除问题类型以实现增减),从而进行逻辑运算和算术处理。状态转换充当“指令状态”,而基于 JQL(Jira 查询语言)的规则则负责处理条件分支。 为了验证这一点,Seriot 构建了一台功能性的加法机(计算 2+3=5)以及一个更复杂的斐波那契数列生成器。尽管 Jira Cloud 存在链式深度限制等实际约束,但这被视为有限的物理限制而非理论限制,类似于标准计算机的内存限制。因此,文章得出结论:Jira 的自动化语言不仅是一个任务管理工具,更是一个能够进行任意计算的功能性编程环境。

Hacker News 最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 Jira 是图灵完备的 (seriot.ch) 27 分,由 vinhnx 发布于 2 小时前 | 隐藏 | 过往 | 收藏 | 2 条评论 帮助 hyperhello 1 分钟前 | 下一条 [–] Jira 烂透了,因此它具备演变成任何其他糟糕形式的潜能。 回复 pjmlp 2 分钟前 | 上一条 [–] 所有的工作流和编排引擎都是图灵完备的,其全部目的就是为了自动化执行流程。 回复 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 加入 YC | 联系 搜索:
相关文章

原文
Jira IS Turing-Complete

Nicolas Seriot

Computation > Jira is Turing-Complete

Building a Minsky Machine in Atlassian Automation
22nd May 2026

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.

Mapping the Computational Model

A Minsky register machine needs only two unbounded counters and a finite set of labeled instructions:

  • 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 S
  • decrement register R, if R == 0 goto zero-state S, else goto nonzero-state S'

A Minsky program that adds register A into register B looks like:

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 Machine Jira
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

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.

Implementing Addition

Here is a minimal working implementation using one Epic, five linked issues, and one Automation rule per instruction state (Space Settings > Automation).

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. 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).

3. 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.

The screenshot below shows the two rules wired into the Epic's workflow.

4. Init Registers

Link 2 Bugs (A=2) and 3 Tasks (B=3) to the Epic.

5. Bootstrap the Machine.

Transition the Epic to TODO to start the cascade. 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.

Fibonacci in Three States

The reduction above suffices to prove Turing-completeness. In addition to that, Jira's automation language can simplify Minsky operations. Convert Issue Type changes an issue's type instantly: Bug → Story, Story → Task, and so on.

CONVERT is expressible as DEC + INC. It doesn't extend Jira's computational power, but it shrinks the dispatch table dramatically for any move-loop, making non-trivial programs tractable.

Fibonacci as (A, B) → (B, A+B) collapses to three states with three registers (A=Bug, B=Task, C=Story), using TODO, QA (add it to the workflow), and DEV as the three instruction states:

TODO:
    if any linked Task exists:
        CONVERT Task → Story
        INC Bug
        transition to TODO
    else:
        transition to QA

QA:
    if any linked Bug exists:
        CONVERT Bug → Task
        transition to QA
    else:
        transition to DEV

DEV:
    if any linked Story exists:
        CONVERT Story → Bug
        transition to DEV
    else:
        transition to 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 single status edit restarts the cascade.

The reduction still holds, the human just supplies the next clock tick. Jira Data Center exposes the same as automation.rule.execution.timeout and related, configurable properties.

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.

联系我们 contact @ memedata.com