cibseven-devflows

Запускайте свои рабочие процессы разработчика как BPMN-процессы на локальном движке CIB seven и управляйте ими из ИИ-агентов кодирования, таких как Claude Code, через MCP-сервер.

Версия 0.1.0 включает один рабочий процесс: ритуал релиза репозитория. Запустите проверки качества, спросите человека, создайте тег, опубликуйте. Этот репозиторий выпустил собственный v0.1.0, запустив этот процесс на самом себе.

Зачем

Выпуск релиза — это процесс с человеческим решением в середине. Обычно этот процесс живёт в чьей-то голове и в прокрутке терминала. Ничто не фиксирует, что проверки выполнялись, что человек одобрил, или что было опубликовано.

Процессный движок — именно тот инструмент для такой задачи. CIB seven хранит состояние, хранит историю и умеет ждать человека. Ваша машина по-прежнему выполняет работу, а ИИ-агент может запустить процесс и наблюдать за ним, но не может пропустить одобрение, потому что одобрение — это шаг в процессе, а не обещание в промпте.

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-команды и не касается вашего репозитория. Он раздаёт работу; воркер на вашей машине опрашивает его и выполняет её. Это стандартный паттерн внешних задач 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, поэтому она ждёт, переживает перезапуск движка, и на неё можно ответить либо в веб-интерфейсе, либо через MCP-инструмент approve_gate.

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"

Запустите воркер и оставьте его работать в отдельном терминале:

uv run devflows-worker

Запустите пробный релиз этого репозитория. Замените repo_path на абсолютный путь к этому репозиторию. Используйте прямые слэши даже в Windows (C:/Users/you/repos/cibseven-devflows): они работают и избавляют вас от борьбы с вашей оболочкой из-за экранирования обратных слэшей.

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"}}}'

Затем одобрите его на http://localhost:8080/webapp/#/seven/auth/tasks под demo / demo: отфильтруйте 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 общается по MCP через stdio и работает с любым MCP-клиентом.

Каждый инструмент возвращает словарь с флагом ok и строкой error, когда ok равно false. Ни один инструмент не вызывает исключений, потому что вызывающая сторона — языковая модель, которая должна объяснить сбой человеку.

Использование из Claude Code

plugin/ — это плагин Claude Code вокруг того же сервера:

• plugin/.mcp.json запускает devflows-mcp с помощью uv run.

• 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"]
    }
  }
}

Конфигурация

Безопасность

Две вещи в этом проекте сделаны намеренно, и обе предполагают, что он работает на вашей собственной машине:

• У движка нет аутентификации. REST API на localhost:8080 принимает всё, что может до него добраться. Не открывайте этот порт для сети, которую вы не контролируете.

• Воркер выполняет shell-команды. Они берутся из devflows.yaml репозитория, который вы попросили выпустить, они выполняются от вашего имени, в этом репозитории, и это те же команды, которые вы бы ввели. Направляйте его только на репозитории, которым вы доверяете.

Нет облачного сервиса, нет телеметрии и нет учётной записи, кроме учётных данных GitHub, которые уже есть у gh.

Структура репозитория

Требования

• Docker Desktop, для движка

• Python 3.12 и uv

• git и аутентифицированный gh для шагов создания тега и публикации

• Camunda Modeler 5.x, если вы хотите редактировать диаграмму BPMN (необязательно). Откройте processes/release.bpmn как диаграмму Camunda 7.

Лицензия

Apache License 2.0. См. LICENSE.