cibseven-devflows

Führen Sie Ihre Entwickler-Workflows als BPMN-Prozesse auf einer lokalen CIB seven-Engine aus und steuern Sie sie über einen MCP-Server aus KI-Coding-Agenten wie Claude Code.

Version 0.1.0 enthält einen Workflow: das Release-Ritual eines Repository. Führen Sie die Qualitäts-Gates aus, fragen Sie einen Menschen, taggen Sie, veröffentlichen Sie. Dieses Repository hat sein eigenes v0.1.0 erstellt, indem es diesen Prozess auf sich selbst ausgeführt hat.

Warum

Ein Release zu schneiden ist ein Prozess mit einer menschlichen Entscheidung in der Mitte. Normalerweise lebt dieser Prozess im Kopf von jemandem und in einem Terminal-Scrollback. Nichts hält fest, dass die Gates gelaufen sind, dass eine Person zugestimmt hat oder was veröffentlicht wurde.

Eine Prozess-Engine ist genau das richtige Werkzeug für diese Art von Problem. CIB seven hält den Zustand, hält den Verlauf und weiß, wie man auf einen Menschen wartet. Ihre Maschine erledigt weiterhin die Arbeit, und ein KI-Agent kann einen Lauf starten und beobachten, aber er kann die Freigabe nicht überspringen, weil die Freigabe ein Schritt im Prozess ist und kein Versprechen in einem Prompt.

Related MCP server: jt-mcp-server

Architektur

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

Die Engine führt nie einen Shell-Befehl aus und berührt nie Ihr Repository. Sie gibt Arbeit aus; der Worker auf Ihrem Rechner pollt danach und erledigt sie. Das ist das Standard-External-Task-Muster von Camunda 7, und genau das macht es sicher, einen Prozess ein Entwickler-Rechner steuern zu lassen.

Der Release-Prozess

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

Die drei Rechtecke mit einem Themennamen sind External Tasks. „Approve release“ ist eine BPMN-Benutzeraufgabe, wartet also, übersteht einen Engine-Neustart und kann entweder in der Web-UI oder über das MCP-Tool approve_gate beantwortet werden.

dry_run=true führt die Gates real aus und ändert sonst nichts: kein Tag, kein Push, kein Release.

Schnellstart

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

uv sync

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

Prozess bereitstellen (einmal pro Engine):

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

Worker starten und in einem eigenen Terminal laufen lassen:

uv run devflows-worker

Starten Sie ein Trocken-Release dieses Repository. Ersetzen Sie repo_path durch den absoluten Pfad dieses Repository. Verwenden Sie auch unter Windows Schrägstriche (C:/Users/you/repos/cibseven-devflows): Sie funktionieren und ersparen Ihnen den Kampf mit Ihrem Shell um Backslash-Escaping.

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

Dann bestätigen Sie es unter http://localhost:8080/webapp/#/seven/auth/tasks als demo / demo: Filter My Group Tasks, Approve release beanspruchen, approve ankreuzen, absenden.

In der Praxis starten Sie Läufe über den MCP-Server statt über curl. Siehe docs/DEMO.md für den vollständigen Walkthrough.

devflows.yaml

Jedes Repository beschreibt sein eigenes Release in einer devflows.yaml im Stammverzeichnis:

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

Unbekannte Top-Level-Schlüssel werden ignoriert, sodass eine neuere Version von devflows Schritte hinzufügen kann, ohne eine ältere Datei zu brechen.

Die MCP-Tools

devflows-mcp spricht MCP über stdio und funktioniert mit jedem MCP-Client.

Jedes Tool gibt ein Wörterbuch mit einem ok-Flag zurück und einen error-String, wenn ok falsch ist. Kein Tool wirft eine Exception, denn der Aufrufer ist ein Sprachmodell, das den Fehler einem Menschen erklären muss.

Verwendung mit Claude Code

plugin/ ist ein Claude-Code-Plugin um denselben Server:

• plugin/.mcp.json startet devflows-mcp mit uv run.

• plugin/skills/release-with-devflows/SKILL.md sagt dem Agenten, wann er die Engine verwenden soll und in welcher Reihenfolge er die Tools aufrufen soll, einschließlich der Regel, dass er vor der Freigabe anhalten und fragen muss.

• plugin/commands/release.md stellt /devflows:release <version> [--real] bereit.

Um den Server direkt in einen anderen MCP-Client einzubinden:

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

Konfiguration

Sicherheit

Zwei Dinge an diesem Projekt sind beabsichtigt, und beide setzen voraus, dass es auf Ihrem eigenen Rechner läuft:

• Die Engine hat keine Authentifizierung. Die REST-API auf localhost:8080 akzeptiert alles, was sie erreichen kann. Setzen Sie diesen Port nicht einem Netzwerk aus, das Sie nicht kontrollieren.

• Der Worker führt Shell-Befehle aus. Sie stammen aus der devflows.yaml des Repository, das Sie freigeben möchten, sie laufen als Sie, in diesem Repository, und es sind dieselben Befehle, die Sie tippen würden. Richten Sie ihn nur auf Repositorys, denen Sie vertrauen.

Es gibt keinen Cloud-Dienst, keine Telemetrie und kein Konto über die GitHub-Anmeldedaten hinaus, die gh bereits hat.

Repository-Struktur

Anforderungen

• Docker Desktop, für die Engine

• Python 3.12 und uv

• git und authentifiziertes gh, für die Tag- und Publish-Schritte

• Camunda Modeler 5.x, wenn Sie das BPMN-Diagramm bearbeiten möchten (optional). Öffnen Sie processes/release.bpmn als Camunda 7-Diagramm.

Lizenz

Apache License 2.0. Siehe LICENSE.