Was die Fabrik heute noch nicht vollständig kann.

1. Cloud-Gateways sind experimentell

Neben den offiziellen Vendor-APIs gibt es Adapter für die Cloud-Gateways AWS Bedrock, Google Vertex AI und Azure OpenAI. Diese sind implementiert, aber noch nicht live end-to-end getestet.

• Der produktive Einsatz eines Gateways sollte erst nach einer kundenseitigen Verifikation mit echten Cloud-Zugangsdaten erfolgen.
• Die direkten Vendor-APIs (Anthropic, OpenAI, Google Gemini) sowie der on-prem-Betrieb über Ollama/vLLM sind davon nicht betroffen.

2. Parallele Läufe nur mit Feature-Flag — und nur auf einem Host

Bis v0.20 lief pro Projekt genau ein Run. Seit v0.21 gibt es eine Workflow-Ebene darüber: ein Vorhaben zerfällt in Tasks, die als eigenständige Child Runs parallel laufen — jeder in einem eigenen git-Worktree. Das ist standardmäßig abgeschaltet.

• Ohne das Feature-Flag softwarefabrik.workflow.enabled verhält sich die Plattform wie vorher: ein Lauf je Workspace.
• Mit Flag laufen höchstens drei Child Runs gleichzeitig je Workflow. Die Grenze ist bewusst niedrig: Jeder Lauf kostet Tokens, und mehr Parallelität erhöht vor allem den Integrationsaufwand.
• Die Sperre gilt seit v0.21 dem Workspace, nicht mehr dem Projekt. Zwei Agenten im selben Verzeichnis bleiben ausgeschlossen — sonst wäre keine Änderung mehr einem Lauf zurechenbar.
• Kein verteilter Worker-Pool. Alle Child Runs laufen als Prozesse auf einer Maschine.
• Merge-Konflikte und Vertragsbrüche löst ein Mensch. Beide halten den Workflow an und warten auf eine Entscheidung; ein Agent, der den Branch selbst in Einklang bringt, ist geplant, aber nicht gebaut.

3. Ausführung generierten Codes — isolierte Umgebung empfohlen

Build-Runs führen von Agenten erzeugten Code aus (z.B. mvn verify, npm run build). Solcher Code sollte grundsätzlich als nicht vertrauenswürdig behandelt werden.

• Betreibe Build-Runs auf einer isolierten bzw. vertrauenswürdigen Umgebung, nicht auf einem Host mit sensiblen Zugängen.
• Die Plattform bietet eine Container-Sandbox pro Run (execution.sandbox.variant=container, mit Netzwerk-, CPU- und Speicher-Limits). Die weitergehende Sandbox-Härtung ist in Arbeit.

4. Repo-Anbindung: Pull-Requests und CI-Rückkopplung nur für GitHub

Push, Pull-Request, CI-Statusabfrage und GitHub-Release sind gegen die GitHub-API implementiert.

• GitLab, Bitbucket und Azure DevOps sind noch nicht angebunden. Für diese Hosts greift der lokale Merge in den Base-Branch; Branch-Isolation, Quality-Gate und Korrektur-Schleife funktionieren unverändert.
• Die PR-/CI-Rückkopplung ist bewusst opt-in (git.pr-feedback.enabled, Default aus): unbeaufsichtigte periodische Remote-Kontakte sollen eine bewusste Betriebsentscheidung sein.
• Der fabrikweite GitHub-Token wird nur für Hosts der Allowlist verwendet (git.allowed-hosts, Default github.com).

5. Budget-Obergrenzen wirken je Mandant, nicht je Nutzer

Token-Verbrauch und Kosten werden je Projekt, Run, Provider, Mandant und je Seat (auslösender Nutzer) erfasst und als CSV exportiert.

• Der harte Budget-Cap greift auf Mandantenebene. Eine seat-scharfe Obergrenze gibt es nicht — die Seat-Sicht wertet aus, sie begrenzt nicht.
• Wer nutzerscharf begrenzen muss, trennt über Mandanten.

6. Eine bekannte offene CVE im eingebetteten Tomcat

CVE-2026-66299 (CVSS 7.5) betrifft tomcat-embed-* in Version 11.0.24 — den Servlet-Container, den die Plattform einbettet.

• Es gibt derzeit keinen Fix. 11.0.24 ist laut Maven Central die neueste verfügbare Version der 11.0.x-Linie; ein 11.0.25 existiert noch nicht.
• Ein Downgrade wäre schädlich: 11.0.24 schließt die schwereren CVE-2026-59083 und CVE-2026-59084 (je CVSS 9.1), die in 11.0.23 und früher offen sind.
• Der Befund ist im Scan mit Ablaufdatum 2026-11-06 hinterlegt. Danach schlägt die Prüfung bewusst wieder fehl und erzwingt eine Neubewertung — statt still zu einem Dauerzustand zu werden.
• Sichtbar wurde er erst am 2026-08-06: Der Abhängigkeits-Scan lief in der CI zuvor ohne NVD-API-Key und damit nie vollständig durch. Der Fehler ist behoben.

Betreibe die Plattform hinter einem Reverse-Proxy und nicht offen im Internet — das ist ohnehin die empfohlene Betriebsform.