cibseven-devflows

在本地 CIB seven 引擎上以 BPMN 流程运行你的开发者工作流，并通过 MCP 服务器从 Claude Code 等 AI 编码代理驱动它们。

0.1.0 版本附带一个工作流：仓库的发布仪式。运行质量门禁、询问人类、打标签、发布。本仓库就是通过在自己身上运行该流程来发布自己的 v0.1.0 的。

为什么

发布版本是一个中间包含人类决策的流程。通常这个流程存在于某人的头脑和终端回滚缓冲区中。没有任何东西记录门禁是否运行、是否有人批准、或者发布了什么。

流程引擎正是解决这类问题的合适工具。CIB seven 保存状态、保存历史，并且知道如何等待人类。你的机器仍然执行工作，AI 代理可以启动一次运行并观察它，但它不能跳过审批，因为审批是流程中的一个步骤，而不是提示词中的一句承诺。

Related MCP server: jt-mcp-server

架构

flowchart LR
    agent["Claude Code<br/>(any MCP client)"] -- stdio --> mcpserver["devflows-mcp"]
    mcpserver -- REST --> engine["CIB seven engine<br/>Docker, H2, localhost:8080"]
    human["You, in the web UI"] -- approve --> engine
    engine -- fetchAndLock --> worker["devflows-worker"]
    worker -- shell --> repo["your repository<br/>pytest, ruff, git, gh"]

引擎从不运行 shell 命令，也从不触碰你的仓库。它分发工作；你机器上的 worker 轮询获取并执行。这是标准的 Camunda 7 外部任务模式，也正是让流程驱动开发者机器变得安全的原因。

发布流程

flowchart LR
    start((start)) --> gates["Run gates<br/><i>devflows.gates</i>"]
    gates --> q1{Gates passed?}
    q1 -- no --> failed((Gates failed))
    q1 -- yes --> approve["Approve release<br/><i>user task</i>"]
    approve --> q2{Approved?}
    q2 -- stop --> rejected((Release rejected))
    q2 -- ship --> tag["Tag<br/><i>devflows.tag</i>"]
    tag --> publish["Publish<br/><i>devflows.publish</i>"]
    publish --> released((Released))

三个带主题名称的矩形是外部任务。"Approve release" 是一个 BPMN 用户任务，因此它会等待，能在引擎重启后存活，并且可以通过 Web UI 或 approve_gate MCP 工具来应答。

dry_run=true 会真实运行门禁，但不改变任何其他东西：不打标签、不推送、不发布。

快速开始

docker compose -f engine/docker-compose.yml up -d

uv sync

uv run pytest -m "not integration" && uv run ruff check .

部署流程（每个引擎一次）：

curl -s -X POST http://localhost:8080/engine-rest/deployment/create -F "deployment-name=cibseven-devflows" -F "release.bpmn=@processes/release.bpmn"

启动 worker 并让它在其自己的终端中保持运行：

uv run devflows-worker

启动本仓库的试运行发布。将 repo_path 替换为本仓库的绝对路径。即使在 Windows 上也使用正斜杠（C:/Users/you/repos/cibseven-devflows）：它们有效，并且能让你免于与 shell 的反斜杠转义作斗争。

curl -s -X POST http://localhost:8080/engine-rest/process-definition/key/devflows-release/start -H "Content-Type: application/json" -d '{"variables":{"repo_path":{"value":"ABSOLUTE/PATH/TO/cibseven-devflows","type":"String"},"version":{"value":"0.2.0","type":"String"},"dry_run":{"value":true,"type":"Boolean"}}}'

然后以 demo / demo 在 http://localhost:8080/webapp/#/seven/auth/tasks 批准它：筛选 My Group Tasks，认领 Approve release，勾选 approve，提交。

实际上，你通过 MCP 服务器而不是 curl 来启动运行。完整演示请参阅 docs/DEMO.md。

devflows.yaml

每个仓库在其根目录的 devflows.yaml 中描述自己的发布：

gates:
  - name: tests
    run: uv run pytest -q
  - name: lint
    run: uv run ruff check .

tag:
  format: "v{version}"

publish:
  run: gh release create v{version} --generate-notes

未知的顶层键会被忽略，因此较新版本的 devflows 可以添加步骤而不会破坏旧文件。

MCP 工具

devflows-mcp 通过 stdio 使用 MCP 协议，可从任何 MCP 客户端使用。

每个工具都返回一个带有 ok 标志的字典，当 ok 为 false 时还包含一个 error 字符串。没有工具会抛出异常，因为调用方是一个必须向人类解释失败原因的语言模型。

从 Claude Code 使用

plugin/ 是一个围绕同一服务器的 Claude Code 插件：

• plugin/.mcp.json 使用 uv run 启动 devflows-mcp。

• plugin/skills/release-with-devflows/SKILL.md 告诉代理何时使用引擎以及按什么顺序调用工具，包括在批准之前必须停下来询问的规则。

• plugin/commands/release.md 提供 /devflows:release <version> [--real]。

要将服务器直接接入任何其他 MCP 客户端：

{
  "mcpServers": {
    "cibseven-devflows": {
      "command": "uv",
      "args": ["run", "devflows-mcp"]
    }
  }
}

配置

安全

这个项目有两件事是刻意为之的，两者都假设它运行在你自己的机器上：

• 引擎没有身份验证。 localhost:8080 上的 REST API 接受任何能访问到它的请求。不要将该端口暴露给你无法控制的网络。

• worker 会运行 shell 命令。 这些命令来自你要求它发布的仓库的 devflows.yaml，它们以你的身份在该仓库中运行，并且与你手动输入的命令相同。只将它指向你信任的仓库。

没有云服务、没有遥测、除了 gh 已有的 GitHub 凭据外也不需要任何账户。

仓库结构

要求

• Docker Desktop，用于引擎

• Python 3.12 和 uv

• 已认证的 git 和 gh，用于打标签和发布步骤

• 如果你想编辑 BPMN 图，需要 Camunda Modeler 5.x（可选）。将 processes/release.bpmn 作为 Camunda 7 图打开。

许可证

Apache License 2.0。参见 LICENSE。