Kontrollierter Coding-Agent fuer Failure Reports aus lai. Der Orchestrator verwendet Aider headless als austauschbaren Coding-Kern. Git-, Gitea-, Policy- und Freigabelogik bleiben in diesem Projekt.

Warum Aider?

scriptbarer Einmal-Auftrag mit --message-file
gute Git- und Repository-Map-Unterstuetzung
Mistral ueber LiteLLM nutzbar
automatische Commits koennen deaktiviert werden
deutlich kleinerer Betriebsumfang als OpenHands

OpenHands bleibt eine moegliche spaetere Alternative fuer komplexere, mehrstufige Agentenlaeufe. Sein Headless-Modus arbeitet jedoch immer mit always-approve; deshalb muessen auch dort unsere externen Policy-Gates erhalten bleiben.

Ablauf

failure_reports(open)
	-> transaktionales Claiming (SKIP LOCKED)
	-> anonymisierter Agentenauftrag
	-> frischer Clone von lai.git
	-> Aider-Aenderung ohne Commit
	-> Pfad-, Groessen- und Sicherheitsgates
	-> Tests
	-> Commit
	-> PR oder kontrollierter Push auf main
	-> failure_reports(resolved/agent_failed)

Der Coding-Agent erhaelt keinen Zugang zur ERP- oder Kundendatenbank. Rohdaten und .env-Dateien sind ausgeschlossen. Repository-Pushes verwenden GIT_ASKPASS; Tokens werden nicht in Remote-URLs oder Prozessargumenten gespeichert. Der Orchestrator laeuft als privilegierter Containerprozess, startet Aider aber als separaten Benutzer coder. Dieser Unterprozess erhaelt nur Modell-Credentials, nicht die Failure-DB- oder Gitea-Zugangsdaten.

Die nachgelagerten Testprozesse erhalten separat konfigurierte TEST_DB_*-Zugangsdaten. Dieser Benutzer darf ausschliesslich die isolierten Testschemas bearbeiten. Fuer Laravel werden daraus DB_*, ERP_DB_* und COCKPIT_CONFIG_DATABASE gesetzt; Aider selbst sieht diese Werte nie. Produktive ERP- oder Kundenzugangsdaten duerfen hier nicht verwendet werden. Vor jedem Testlauf erstellt npm run build die Vite-Assets und initialisiert php artisan migrate:fresh --force das isolierte Laravel-Schema neu. Deshalb muessen alle TEST_DB_*-Schemas dediziert und vollstaendig entbehrlich sein.

Laravel-Tests laufen mit PHP und Composer direkt im isolierten Worker. Der Docker-Socket des Hosts wird nicht eingebunden. Abgebrochene Claims werden nach standardmaessig 90 Minuten wieder freigegeben; STALE_CLAIM_MINUTES passt dieses Intervall an. Schlaegt die isolierte Validierung fehl, erhaelt Aider standardmaessig genau einen Korrekturversuch mit redigierter Testausgabe. MAX_AGENT_ATTEMPTS ist auf 1 bis 3 begrenzt.

Schnellstart

cp .env.example .env
# FAILURE_DB_PASSWORD und bei Bedarf MISTRAL_API_KEY eintragen
# TEST_DB_PASSWORD fuer den Benutzer der isolierten Testschemas eintragen
docker compose build
docker compose run --rm automation check
docker compose run --rm automation once

Der Default AUTOMATION_MODE=dry-run claimt einen offenen Report, erzeugt den anonymisierten Auftrag und setzt ihn danach wieder auf open. Es wird weder ein Agent gestartet noch gepusht.

Fortschritt beobachten

docker compose ps automation
docker compose exec automation lai-agent check
docker compose logs -f automation

Der Worker protokolliert nur sichere Metadaten, keine Prompts, SQL-Ergebnisse, Secrets oder Modellausgaben. Fuer jeden Report erscheinen Workspace-Vorbereitung, Agentenversuch, Anzahl und Pfade geaenderter Dateien, Policy-Pruefung, jeder Validierungsbefehl, Commit, PR-URL und Cleanup. Bei laengeren Agenten- oder Testphasen wird alle 30 Sekunden Laufzeitfortschritt ausgegeben. agent_running ohne Heartbeat oder Unterprozess deutet auf einen unterbrochenen Container hin; normale Claims werden nach STALE_CLAIM_MINUTES wieder freigegeben.

PR-Modus

AUTOMATION_MODE=pr
GITEA_USERNAME=automation-bot
GITEA_TOKEN=...
MISTRAL_API_KEY=...

Der Bot benoetigt Schreibzugriff auf christian.meyer/lai und die Berechtigung, Branches sowie Pull Requests anzulegen. Jeder Lauf erstellt ai/failure-{report_id} und einen PR gegen main.

Direkter main-Modus

AUTOMATION_MODE=direct-main
ALLOW_DIRECT_MAIN=true
GITEA_TOKEN=...

Der zweite Schalter ist ein Kill-Switch. In diesem Modus sind Migrationen, Routes, Auth, Middleware, PermissionService und SQLValidatorService zusaetzlich blockiert. Branch Protection muss den Bot fuer direkte Pushes explizit zulassen. PR-Modus bleibt die empfohlene Betriebsart.

Modelle

Das Modell wird ausschliesslich ueber AGENT_MODEL gewaehlt. Devstral ist der Default und ein Coding-Agent, nicht das Chat-Modell der Laravel-Anwendung:

AGENT_MODEL=mistral/devstral-latest
MISTRAL_API_KEY=...

Codestral verwendet denselben Mistral-Zugang:

AGENT_MODEL=mistral/codestral-latest
MISTRAL_API_KEY=...

Qwen 3.5 27B ueber OpenRouter:

AGENT_MODEL=openrouter/qwen/qwen3.5-27b
OPENROUTER_API_KEY=...

Oder mit einem lokalen Ollama auf dem Docker-Host:

AGENT_MODEL=ollama_chat/qwen3.5:27b
OLLAMA_API_BASE=http://host.docker.internal:11434

Nach einer Aenderung wird der Worker neu erstellt, damit Compose die neue Umgebung uebernimmt:

docker compose up -d --force-recreate automation
docker compose exec -T automation lai-agent check

Aider waehlt das passende Edit-Format anhand des Modells. Das Chat-Modell und Coding-Modell sind bewusst getrennt. Fuer Coding-Agenten sollte ein agentisch/coding-optimiertes Modell verwendet werden. Ein Wechsel zu OpenHands oder einem anderen Backend erfordert einen neuen Adapter neben AiderAgent.

Tests

python -m venv .venv
. .venv/bin/activate
pip install ".[dev]"
ruff check src tests
pytest -q

Repositorys

Chat: https://gitea.tisinfra.de/christian.meyer/lai.git
Automatisierung: https://gitea.tisinfra.de/christian.meyer/lai_automatisierung.git