Was sich an der Fabrik getan hat.

Was nach der Auslieferung passiert — jedenfalls die Hälfte davon

Von den vier Messlücken hieß eine „entkommene Defekte und Rollbacks“, mit der Begründung: Die Fabrik endet beim Merge und erfährt nicht, was danach kommt. Für die Rollback-Hälfte stimmt das nicht. Ein git revert steht in derselben Historie, die die Fabrik beim nächsten Lauf ohnehin wieder vor sich hat. Was fehlte, war der Anker — der Merge-Commit, auf den sich ein Revert beziehen kann.

Den hält die Fabrik jetzt fest, und beim nächsten Lauf sieht sie nach, was aus dem letzten wurde. Die Übersicht zeigt eine Rollback-Quote.

Warum das keine Defekt-Kennzahl ist

Gemessen wird der Revert, nicht der Defekt. Ein Revert-Commit ist eine Tatsache in der Historie. „Ein späterer Commit berührte dieselbe Datei“ wäre eine Vermutung — das kann ebenso gut das nächste Feature sein. Von der alten Lücke bleibt deshalb nur die erste Hälfte stehen: entkommene Defekte. Sauber ginge die nur über eine Ticketsystem-Anbindung, die es nicht gibt.

Die Quote ist eine Untergrenze, und sie heißt auch so. Wer eine Änderung von Hand rückwärts anwendet und ohne die Revert-Zeile committet, taucht nicht auf. Dafür gibt es einen eigenen Test — als festgehaltene Grenze, nicht als Fehler. Eine Zahl, die sich als vollzählig ausgibt, wäre hier schlimmer als eine, die ihre Grenze nennt.

Im Nenner stehen nur prüfbare Auslieferungen. Ein Merge ohne festgehaltenen Commit lässt sich nicht nachschlagen; ihn als „nicht zurückgenommen“ zu zählen hieße, die Quote durch fehlende Daten zu verbessern.

Damit sind von den ursprünglich vier Lücken noch drei offen: menschliche aktive Arbeitszeit, entkommene Defekte und der Vergleich zur manuellen Umsetzung.

Eine der vier Lücken ist keine mehr

Im letzten Release standen vier Messgrößen als benannte Lücke neben den Zahlen. Eine davon war die Testabdeckungsänderung, und die Begründung lautete: gespeichert wird eine Zusammenfassung der Build-Ausgabe, keine Abdeckungszahl.

Das stimmte — war aber kein Grund, sondern eine fehlende Zeile. Der Abdeckungsbericht liegt ohnehin im Arbeitsverzeichnis; er musste nur gelesen werden, statt ihn aus Logzeilen zu raten. Die Fabrik tut das jetzt nach jedem Build, in drei Formaten — JaCoCo für Java, Cobertura für .NET und Python, Istanbul für Node. Die Reihenfolge steht fest, damit die Kennzahl nicht davon abhängt, welche Datei das Dateisystem zuerst nennt.

Drei Entscheidungen, die man sehen sollte

Kein Bericht heißt nicht null Prozent. Die Spalten sind bewusst leer lassbar. Ein Projekt ohne Abdeckungsbericht hat keine Abdeckung von 0 % — man weiß es schlicht nicht. Ein Standardwert von 0 hätte genau die Verwechslung ins Datenschema geschrieben, gegen die diese Kennzahlen ansonsten antreten.

Die Änderung steht in Prozentpunkten, nicht in Prozent. Von 80 % auf 84 % sind vier Prozentpunkte und fünf Prozent — die Verwechslung macht aus einer kleinen Verbesserung eine große. Und sie erscheint erst ab der zweiten Messung: Eine Änderung gegenüber nichts ist keine Änderung.

Der Bericht wird ohne XML-Parser gelesen. Er stammt aus Code, den Agenten erzeugt haben, und ist damit nicht vertrauenswürdig. Ein Parser wäre hier eine Angriffsfläche direkt im Eingabepfad; die benötigten Werte lassen sich ohne einen lesen.

Bleiben drei Lücken: menschliche aktive Arbeitszeit, entkommene Defekte und Rollbacks, Vergleich zur manuellen Umsetzung. Sie stehen weiterhin als Lücke da, nicht als Zahl.

Kennzahlen — und die vier Fragen, die wir nicht beantworten

Die Fabrik misst jetzt, was sie tut: Wie lange ein Vorhaben bis zum Abschluss brauchte, wie viele Aufgaben ihr Qualitätstor im ersten Anlauf bestanden, wie oft nachgebessert und umgeplant wurde, was ein Vorhaben und was ein einzelner Lauf kostet, und wie häufig Merges in Konflikte liefen — aufgeschlüsselt nach Konfliktart.

Nichts davon wird eigens mitgeschrieben. Alle Werte leiten sich aus Daten ab, die ohnehin entstehen. Eine Kennzahl in einer eigenen Tabelle weicht früher oder später von dem ab, was sie beschreiben soll.

Interessanter ist, was fehlt

Die Roadmap nennt neun Messgrößen. Vier davon kann die Plattform nicht ehrlich beantworten — und sie stehen jetzt als benannte Lücke neben den Zahlen, nicht im Kleingedruckten:

• Menschliche aktive Arbeitszeit. Die Plattform sieht, wie lange etwas wartete — nicht, ob jemand daran arbeitete. Beides gleichzusetzen wäre die eleganteste Art, sich selbst zu betrügen. Die Wartezeit wird deshalb getrennt und anders benannt ausgewiesen.
• Testabdeckungsänderung. Gespeichert wird eine Zusammenfassung der Build-Ausgabe, keine Abdeckungszahl.
• Entkommene Defekte und Rollbacks. Das braucht Rückmeldung aus dem Betrieb nach der Auslieferung — die Plattform endet beim Merge.
• Vergleich zur manuellen Umsetzung. Diese Referenzgruppe existiert im System nicht. Ein Vergleich wäre eine Behauptung über Arbeit, die nie hier stattfand.

Eine Kennzahl, die anders heißt als das, was sie misst, ist schlimmer als eine fehlende — sie wird geglaubt.

Aus demselben Grund steht in der Übersicht ein Strich, wo andere eine Null zeigen würden: Ein Vorhaben ohne einen einzigen Merge hat keine Konfliktquote von 0 % — es hat gar keine. Wer das gleichsetzt, liest aus einer leeren Stichprobe ein gutes Ergebnis heraus.

Arbeit, die von selbst weiterläuft — und ein Ausfall, der nicht schweigt

Bis hierher starteten parallele Aufgaben nur auf Knopfdruck. Wurde eine Aufgabe dadurch frei, dass ihre Vorgängerin fertig wurde, passierte nichts, bis jemand erneut klickte. Und startete man die Anwendung neu, nahm niemand die laufende Arbeit wieder auf.

• Jede Instanz meldet sich an und schlägt. Ohne Herzschlag lässt sich „ausgefallen“ nicht von „beschäftigt“ unterscheiden — und ohne diese Unterscheidung wäre jedes Freigeben einer hängenden Aufgabe ein Ratespiel mit der Möglichkeit, dass zwei Prozesse dieselbe anfassen.
• Anspruch vor Seitenwirkung. Eine Aufgabe wird beansprucht, bevor Arbeitsverzeichnis und Lauf entstehen. Zwei Prozesse können nicht beide gewinnen.
• Ein Ausfall führt nie zu stillem Erfolg. Hatte die Aufgabe noch nicht angefangen, ist nichts geschehen — sie wird neu vergeben. Lief sie bereits, gilt sie als gescheitert: Das Arbeitsverzeichnis kann in unbekanntem Zustand sein, und ein stilles Wiederholen wäre genau das, was die Plattform verhindern soll. Der Weg zurück führt über das begründete Neuplanen aus v0.24.
• Automatischer Versand — standardmäßig abgeschaltet. Läufe selbsttätig zu starten kostet Tokens; das schaltet man bewusst ein.

Was wir nicht gebaut haben: den Betrieb über mehrere Maschinen. Die Roadmap knüpft ihn an eine Bedingung — messbaren Bedarf — und die ist nicht erfüllt. Ein Pool über mehrere Rechner brächte Zugangsdaten und Dateizugriff auf weitere Hosts: Angriffsfläche für eine Last, die es noch nicht gibt. Die Koordinationsschicht ist die Voraussetzung dafür und bis dahin für sich nützlich.

„Merge-Konflikt“ ist keine Diagnose

Zwei konkurrierende Migrationsnummern, eine doppelt hinzugefügte Abhängigkeit und ein echter logischer Widerspruch sehen für Git gleich aus — und verlangen doch völlig verschiedene Reaktionen. Solange eine Plattform sie nicht unterscheidet, kann sie weder sinnvoll eskalieren noch später automatisch auflösen. Ein Agent, der nur „löse den Konflikt“ hört, rät.

• Sieben Konfliktarten, geprüft von der teuersten zur harmlosesten. Eine Migrationskollision, die nebenbei einen Formatierungskonflikt enthält, bleibt eine Migrationskollision — die umgekehrte Einordnung lüde zum Überschreiben ein.
• Analyse ohne Nebenwirkung. Der Merge wird im Objektspeicher durchgerechnet, ohne das Arbeitsverzeichnis anzufassen. Es muss währenddessen einen definierten Stand behalten — sonst wäre hinterher nicht mehr klar, welcher gilt.
• Rebase nur, wo er hilft. Ein Rebase beseitigt Konflikte, die daher rühren, dass ein Branch alt ist. Bei einem inhaltlichen Widerspruch verschiebt er sie nur — deshalb wird er dort gar nicht erst versucht, obwohl er technisch liefe. Ein Versuch ohne neue Information ist der blinde Retry, den die Plattform seit v0.24 verbietet.
• Eskalation mit vollem Kontext. Wer einen Konflikt entscheiden soll, hat den Vorgang nicht verfolgt. Statt „Konflikt in 3 Dateien“ nennt der Bericht Branch, Aufgabe, Konfliktart, was schon versucht wurde, warum der Rebase nicht half, die beteiligten Vertragsfassungen und die Folge jeder Entscheidung.

Eine Grenze, die wir bewusst benennen: Zwei Branches, die V99__a.sql und V99__b.sql anlegen, mergt Git konfliktfrei — verschiedene Dateinamen. Genau deshalb ist die Nummernkollision so tückisch: Sie fällt erst beim Ausrollen auf. Die Einordnung greift nur, wenn Git überhaupt einen Konflikt meldet.

Außerdem: Der Chat-Assistent sprach auf den englischen Seiten Deutsch und blieb im hellen Farbmodus dunkel. Beides behoben — er folgt jetzt Sprache und Farbmodus der Seite.

Ein KI-Chatbot auf dieser Website — und Pläne, die sich erklären

Neu auf softwarefabrik.io: Unten rechts sitzt jetzt ein KI-Assistent. Er beantwortet Fragen zur Plattform aus den öffentlichen Website-Inhalten und der Projektdokumentation — Architektur, Sicherheit, Betrieb, Änderungshistorie. Er kennt bewusst nicht die Betriebs-Runbooks, die Security-Reviews und die Roadmap: Ein Bot, der aus einem Planungsdokument zitiert, macht daraus für den Leser eine Zusage.

Das Widget lädt beim Aufruf jeder Seite ein Skript des Anbieters TrustChat und übermittelt dabei die IP-Adresse — auch dann, wenn der Chat nicht geöffnet wird. Die Datenschutzerklärung beschreibt das in Abschnitt 6.

Unter der Haube: Pläne, die sich erklären

Seit v0.21 zerfällt ein Vorhaben in Tasks, die parallel laufen. Was passiert, wenn sich die Grundlage während der Arbeit ändert? Bis hierher konnte man einen Task einfach neu starten. v0.24 verbietet das.

• Kein blinder Retry. Ein erneuter Lauf ist nur zulässig, wenn eine neue Eingabe vorliegt: eine geänderte Vertragsfassung, ein Merge-Konflikt, ein roter Build, ein Reviewer-Befund. Einen Task umsortieren oder anders zuschneiden zählt ausdrücklich nicht — das ordnet Arbeit um, liefert dem Agenten aber nichts, was er beim letzten Versuch nicht hatte. Wiederholung ohne neue Information kostet nur Tokens und erzeugt dasselbe Ergebnis.
• Jede Planänderung wird begründet, nicht nur gezählt. Die Versionsnummer sagt, welcher Plan gilt. Gefragt wird aber warum dieser — meist Wochen später, wenn sich niemand mehr erinnert. Deshalb ist die Begründung Pflichtfeld, und die Änderung wird über die signierte Audit-Kette attestiert.
• Tasks lassen sich aufteilen und zusammenführen. Beim Aufteilen erben die Teile die Schreibbereiche nicht — erbten sie dieselben, könnten sie nie parallel laufen und das Aufteilen wäre sinnlos.
• Der Warum-Trace zeigt die Planhistorie, nicht nur die aktuelle Nummer.

Verträge: wogegen ein Agent gearbeitet hat — und was das bricht

v0.22 ließ mehrere Agenten parallel schreiben. Dabei bleibt eine Klasse von Fehlern übrig, die keine Einzelprüfung findet: Ein Vertragsbruch liegt zwischen zwei Komponenten, nicht in einer. Der Build des Anbieters ist grün, der des Konsumenten auch — erst zusammen brechen sie. v0.23 macht die gemeinsame Grundlage deshalb explizit.

• Verträge sind versioniert und unveränderlich. Jede Fassung hat eine Nummer und einen Content-Hash. Ließe sich eine Fassung nachträglich ändern, verwiese der Nachweis eines Laufs auf einen Inhalt, der seither ein anderer sein könnte — der Nachweis wäre wertlos.
• Jeder Lauf weist nach, wogegen er gearbeitet hat. Die Bindung entsteht beim Start, nicht bei der Planung: Beim Planen steht noch nicht fest, wann der Task läuft, eine frühere Bindung wäre eine Wette.
• Eine neue Fassung entwertet laufende Arbeit — sichtbar. Wer an eine abgelöste Fassung gebunden ist, wird als veraltet markiert und kann nicht mehr gemergt werden. Geprüft wird zweimal: vor dem Einreihen und vor dem Merge, denn ein Vertrag kann sich ändern, während der Eintrag in der Warteschlange steht.
• Brüche werden benannt, nicht verhindert. Entfernte Pfade, Operationen, Felder und Schemata werden erkannt — und neue Pflichtfelder, denn formal wird nur „verschärft", tatsächlich brechen bestehende Aufrufer. Blockiert wird trotzdem nicht: Eine brechende Änderung ist manchmal genau das Ziel. Blockieren würde die Registry zum Flaschenhals machen und Leute dazu bringen, an ihr vorbei zu arbeiten.
• Unveränderter Inhalt erzeugt keine neue Version. Keine Optimierung, sondern eine Regel — ein Speicherklick ohne Änderung darf keine laufende Arbeit entwerten.

v0.23.1 behebt einen Startfehler der ersten Fassung: Eine Spalte war als CHAR statt VARCHAR angelegt, was die Schema-Validierung gegen PostgreSQL abbrechen ließ. Aufgefallen ist er erst beim Ausrollen — die Testsuite läuft gegen H2 und erzeugt das Schema selbst, prüft die Migration also nie gegen das Mapping. Der Boot-Smoke gegen echtes PostgreSQL ist die einzige Stufe, die solche Fehler sieht.

Dazu ein Konsistenz-Durchgang durch Doku und Website: Mehrere Seiten trugen aktuelle Versionsnummern über veraltetem Inhalt — die Architekturseite listete 21 statt 29 Module, und die Grenzen-Seite behauptete noch, parallele Ausführung sei zurückgestellt. Beides korrigiert.

Parallel schreiben — und danach beweisen, dass es zusammenpasst

v0.21 ließ mehrere Agenten analysieren. v0.22 lässt sie Code ändern. Das ist der schwierigere Teil: Zwei Agenten, die gleichzeitig schreiben, erzeugen Ergebnisse, die niemandem mehr zurechenbar sind. Die Antwort besteht aus zwei Hälften — einer Besitzregel davor und einer Prüfung danach.

• Besitz statt Vertrauen. Jeder schreibende Task erklärt seine Schreibbereiche. Überschneiden sie sich mit denen eines laufenden Tasks, startet er gar nicht erst. Die Prüfung liegt vor der Ausführung, nicht danach — ein Agent, der erst arbeitet und dann abgebrochen wird, hat Geld gekostet und nichts geliefert.
• Build-Konfiguration und Migrationen sind immer exklusiv, auch unangemeldet. Dort kollidieren zwei gleichzeitige Änderungen fast sicher — man denke an zwei Agenten, die dieselbe Migrationsnummer vergeben.
• Besitzansprüche laufen ab. Ein abgestürzter Agentenprozess würde den Workflow sonst dauerhaft blockieren. Leases haben eine Laufzeit und einen Herzschlag; verwaiste werden erkannt und freigegeben.
• Merges laufen nacheinander, in Planreihenfolge. Jeder Merge verändert den Stand, gegen den der nächste gemergt wird — und die Reihenfolge darf nicht davon abhängen, wer zufällig zuerst fertig wurde, sonst ist das Ergebnis nicht reproduzierbar.
• Ein zweites Gate über dem Ganzen. Das Gate je Lauf prüft eine Änderung für sich. Erst das Integration Gate prüft, ob sie zusammen funktionieren — drei einzeln grüne Änderungen können gemeinsam brechen. Ein Workflow gilt nur über dieses Urteil als abgeschlossen.
• Ein Merge-Konflikt hält an, statt zu scheitern. Er ist kein technischer Fehler, sondern eine Entscheidung: erneut versuchen oder Branch verwerfen. Ein verworfener Branch macht das Gate rot — ein Workflow, dessen Arbeit teilweise liegen blieb, gilt nicht als erfolgreich.

Auch diese Ebene bleibt hinter dem Feature-Flag abgeschaltet. Die Konfliktauflösung ist bewusst noch menschlich — ein Agent, der den Branch selbst in Einklang bringt, kommt später.

Parallele Agentenläufe: die Workflow-Ebene

Bisher lief pro Projekt genau ein Agent. v0.21 führt eine Ebene darüber ein: ein Vorhaben zerfällt in Tasks mit Abhängigkeiten, mehrere Analyse-Läufe laufen parallel, ein Synthese-Schritt führt sie zusammen.

• Ein Schreiber je Arbeitsverzeichnis. Parallelität entsteht durch mehr Worktrees, nicht durch mehr Agenten im selben Verzeichnis. Nur so bleibt jede Änderung genau einem Lauf zurechenbar — Voraussetzung für Warum-Trace und Attestierung.
• Die Synthese darf nicht glätten. Ihr Auftrag fordert Widersprüche zwischen den Analysen ausdrücklich ein und ordnet sie den Quellen zu. Eine harmonisierende Zusammenfassung würde genau das vernichten, wofür man mehrere unabhängige Analysen laufen lässt.
• Budget greift vorher. Die Obergrenze wird vor dem Start des nächsten Laufs geprüft, nicht erst auf der Rechnung.
• Planfreigabe bleibt beim Menschen. Agenten planen, aber kein Lauf startet ohne Zustimmung.

Die Ebene ist standardmäßig abgeschaltet. Ohne das Feature-Flag verhält sich die Plattform exakt wie bisher — ein Lauf je Projekt.

Kimi-Adapter, Buildnummer, Doku-Sweep — und ein Scan, der endlich lief

v0.20 bringt einen zehnten Execution-Adapter, macht jede laufende Instanz einer konkreten Änderung zuordenbar und räumt die Dokumentation auf. Der lehrreichste Teil war ein Fehler in der eigenen Pipeline:

• Kimi-Adapter (Moonshot AI): zehnter Adapter, mit beiden Auth-Wegen — API-Key über die Moonshot Open Platform oder Abo über eine „Kimi for Coding“-Mitgliedschaft. Im Abo-Modus strippt die Fabrik die Key-Variablen aktiv, damit die CLI nicht stillschweigend den kostenpflichtigen Pfad wählt.
• Buildnummer in der UI: neben der Version steht jetzt die PR-Nummer samt Kurz-Commit — jede laufende Instanz ist damit einer konkreten Änderung zuordenbar.
• Abhängigkeits-Scan lief ohne API-Key. Das Repo-Secret war gesetzt, wurde aber nur als Wächter benutzt und nie an Maven übergeben. Der Scan lief deshalb unauthentifiziert über den öffentlichen Feed und nie sauber durch — unsichtbar, weil der Job als „advisory“ konfiguriert ist. Behoben. Der erste vollständige Lauf meldete prompt drei CVEs: zwei sind gefixt (jackson-databind, log4j-api), eine ist ohne Upstream-Fix und mit Ablaufdatum dokumentiert — nachzulesen unter Known Limitations.
• Dokumentation auf Stand: Handbücher von 0.12 auf 0.20, neues Administrationshandbuch für Mandanten, RBAC, Policy-as-Code, Compliance-Profile und Attestierung; dazu korrigierte Zahlen auf allen Feature-Seiten.
• UI-Korrekturen: Teamansicht zeigt Agentennamen statt roher UUIDs, Agentenübersicht hat eine Kurzbeschreibung, neue Sicht für Teamzugehörigkeiten je Agent.

Vendor-neutrale Guardrails, Skill-Bibliothek, Routinen & mehr

Nach einer Analyse des Open-Source-Projekts Paperclip AI zieht v0.19 vier Bausteine ein — plus eine modellunabhängige Verhaltens-Policy:

• Engineering Guardrails: eine vendor-neutrale Policy (Correctness & Reviewability vor Tempo) fließt bei jedem Run in den Kontext jedes Coding-Agents (Claude, Codex, Gemini, lokale Modelle) und wird als kanonische AGENTS.md ins Repo projiziert.
• Skill-Bibliothek: mandanten-scoped, versioniert, signiert — Katalog → installieren/forken, statt Filesystem-Scan.
• Routinen: geplante/wiederkehrende Runs per Cron (nächtlicher Dependency-Scan, wöchentlicher Doku-Refresh).
• Segregation of Duties (Freigeber ≠ Auslöser) und Kostenattribution pro Provider im Analytics-Bereich.

Sicherheitspatch: Härtung der Repo-Remote-Kopplung

Ein adversarialer Re-Review der v0.18 fand drei Befunde in der neuen Remote-Sync-Schicht — alle geschlossen:

• Remote-URL als Vertrauensgrenze: Projekt-Remote-URLs werden zentral validiert (Host-Allowlist, Schema-Whitelist) — der geteilte GitHub-Token verlässt nie einen fremden Host.
• Git-Transport gehärtet: nur noch benötigte Protokolle, kein Remote-Helper-Missbrauch.
• Branch-Isolation: die Merge-Konflikt-Korrektur bleibt strikt auf dem Run-Branch.

Repo-Realität: PR-/CI-Rückkopplung, Remote-Sync, Multi-Version

Der iterative SDLC-Loop wird an die reale Welt des Git-Repos gekoppelt:

• PR-/CI-Rückkopplung: ein Build-Run schließt jetzt erst, wenn der Pull-Request gemergt und die CI grün ist — rote CI löst automatisch eine Korrektur-Runde aus.
• Remote-Sync & Konflikte: der Stand wird vor jedem Run mit dem Remote abgeglichen; Merge-Konflikte gehen in die Korrektur- Schleife statt abzubrechen.
• Multi-Version: Meilensteine gruppieren Backlog-Items zu Iterationen und geben sie als Release frei (Per-Projekt-Changelog + Git-Tag + GitHub-Release); Backlog-Items können voneinander abhängen.

Sicherheitspatch: Governance-Härtung nach internem Re-Review

Ein adversarialer Multi-Agent-Re-Review der v0.17 fand vier Multi-Tenant-Befunde — alle geschlossen:

• Globaler Policy-Floor: eine Mandanten-Policy kann die Betreiber-Baseline (EU AI Act / BAIT / VS-NfD) jetzt nur noch verschärfen, nicht mehr unterlaufen.
• Betreiber-Flächen abgedichtet: die Mandanten-Verwaltung und die Budget-Obergrenzen sind konsequent dem Plattform-Betreiber vorbehalten.

Patch: Tomcat-Sicherheitsupdate

Der eingebettete Tomcat wurde auf 11.0.23 angehoben (CVE-2026-55276, CVE-2026-53434, CVE-2026-53404 — von Apache als niedrig eingestuft, vorsorglich dennoch sofort gepatcht).

Enterprise-Härtung: volle Mandanten-Isolation, Container-Sandbox für Build & Scans

v0.17 schließt die nach v0.16 offen gebliebenen Härtungs-Arbeitspakete:

• Volle Mandanten-Isolation: getrennte aktive Governance-Policy pro Mandant, Audit-Ereignisse mandanten-attribuiert als Teil der signierten Hash-Kette, tenant-gescopte Datenbank-Queries statt In-Memory-Filter. Betreiber-Flächen (Attestierung, Kosten, Policy, Export) zeigen Mandanten-Nutzern nur die eigene Sicht.
• Container-Sandbox für Build & Scans: der Build des generierten Codes und die trivy-Scans laufen bei aktiver Container-Variante im ephemeren Container (read-only, Ressourcen-Limits, nur der Workspace gemountet) — mit echten Docker-Isolationstests.
• Schlüssel-Rotation: Ed25519-Signierschlüssel sind rotierbar; Alt-Attestate bleiben über den Key-Ring verifizierbar.
• Kosten je Nutzer (Seat): jeder Run speichert den auslösenden Nutzer — Verbrauch ist jetzt pro Seat auswertbar, zusätzlich zur Mandanten-Sicht.

Patch: alle Befunde eines adversarialen Multi-Agent-Re-Reviews behoben

Ein interner Re-Review von v0.16 (Security + Architektur mit Opus 4.8, adversarial gegengeprüft) fand fünf Restlücken — alle in diesem Patch geschlossen:

• Pflichtfreigabe der Validierung erzwungen: regulierte Profile (BAIT/MaRisk/DORA, BSI-VS-NfD) stoppen jetzt real vor dem Merge zur Vier-Augen-Freigabe — vorher signiert, aber nicht durchgesetzt.
• Zwei IDOR-Schreiblücken geschlossen: Prompt-Artefakte und per-Projekt-Budgets waren per fremder Projekt-ID beschreibbar; jetzt Mandanten-Wall + Rollen-Guard.
• Attestierungs-Integrität: die real durchgesetzte Policy-Version wird zur Ausführungszeit attestiert; Pflicht-Attestierung erzwingt echte Signatur (kein stiller No-Op) und einen dauerhaften Key.
• Fail-closed: mehrdeutige Gate-Konfiguration blockt (statt still auf „beratend" herabzustufen).

Sicherheits- & Ehrlichkeits-Härtung vor der Testuser-Übergabe

Konsolidierung aus einem internen 5-Pass-Review (Security, Architektur, Doku, Onboarding): Governance wird real durchgesetzt, Autorisierung abgedichtet, die Grenzen ehrlich benannt.

• Governance erzwungen: die aktive, signierte Policy-as-Code macht Gate-Schärfe, Pflicht-Freigaben und Pflicht-Attestierung real wirksam (strengster Wert gewinnt) — Compliance-Profile wie EU-AI-Act wirken jetzt tatsächlich, statt nur dekorativ zu sein.
• Autorisierung & Isolation: rollenbasierte Absicherung aller schreibenden Endpoints, geschlossene IDOR-Lücken, OIDC-Login über stabilen Subject-Claim, Betreiber-Flächen gegen Cross-Mandanten-Einsicht abschirmbar.
• Audit-Härtung: signierter Ketten-Kopf erkennt das Abschneiden der neuesten Audit-Einträge; der unsignierte Modus wird klar als „nicht manipulationssicher" gekennzeichnet.
• Ehrlichkeit & Onboarding: Cloud-Gateways als experimentell markiert, aktuelle Modell-Defaults (Opus 4.8 / Sonnet 5), Einzelplatz-Default „manuelle Freigabe vor Merge", Mock-Adapter-Hinweis und eine neue „Known Limitations"-Seite.

Vom Trichter zum souveränen Produkt: Multi-Tenancy, Attestierung & Supply-Chain

Der grosse Enterprise-/Souveränitäts-Ausbau (Roadmap P0–P4): Team-Betrieb mit harter Mandanten-Isolation, kryptografische Nachweisbarkeit jeder KI-gestützten Entscheidung und Supply-Chain-Integrität für den generierten Code.

• Betriebsmodus & Modell-Backend: Einzelplatz-Abo vs. Team-API-Pool; OpenAI-kompatibler Adapter (vLLM/Ollama), Gateways (Bedrock/Vertex/Azure) (experimentell), erzwungene Per-Projekt-Modell-Policy.
• Multi-Tenancy & RBAC: harte Mandanten-Isolation, Rollen (Viewer→Admin), SSO-Föderation (OIDC), Per-Mandant-Kostenattribution + Monatsbudgets (Grundlagen; volle Mehrmandanten-Fähigkeit folgt).
• Provenance & Attestierung: signierte, manipulationssichere Audit-Hash-Kette (Ed25519), reproduzierbarer „Warum"-Trace pro Run, versionierte + signierte Policy-as-Code, Compliance-Profile (EU-AI-Act, BAIT/MaRisk/DORA, BSI/VS-NfD), Regulator-Audit-Export.
• Supply-Chain-Integrität: SBOM pro Build (CycloneDX), signierte Artefakte, Dependency-/Lizenz-Scan als blockierender Gate-Output in der Korrekturschleife.

Branch & Pull-Request, Selbstkorrektur, Quality-Gate & Auto-Loop

Der SDLC-Loop wird produktionsreif: jeder Build-Run auf eigenem Branch, optional Push + Pull-Request zu GitHub, automatische Korrektur bei rotem Build und ein Quality-Gate in der Pipeline.

• Branch pro Build-Run (sdlc/run-…): Erfolg → Merge in den Base, Misserfolg → Arbeit bleibt isoliert, Base bleibt sauber.
• Push + Pull-Request (GitHub): mit Remote-URL am Projekt und GitHub-Token öffnet ein erfolgreicher Build-Run automatisch einen PR.
• Automatische Korrektur-Schleife: bei rotem Build wird das Feedback eingespeist und erneut gebaut (begrenzt).
• Quality-Gate in der Pipeline (aus/beratend/blockierend) und Auto-Folgevorschläge, die den Loop selbst schließen.
• Wizard: .NET 10 (LTS) als Default (9/8 weiter wählbar).

Iterativer SDLC: persistenter Workspace, Memory & Roadmap-Pläne

Die Fabrik wird vom Projekt-Starter zum Lifecycle-Manager: Folge-Runs arbeiten auf dem bestehenden Code weiter, lernen mit und planen die nächsten Schritte.

• Persistenter Workspace + Re-Run: ein Folge-Run baut auf dem Code des vorherigen Runs auf (statt leerem Start) — echte Weiterentwicklung über Versionen.
• Echter Repo-Import: ein bestehendes Repository (lokaler Pfad oder Git-URL) wird übernommen und dann über die Fabrik weiterentwickelt.
• Project-Memory: kuratierte Learnings/Entscheidungen pro Projekt, die vor jedem Run als MEMORY.md einfließen und danach zurückgelernt werden.
• Roadmap/Pläne als Backlog: ein Plan-Run schlägt nächste Schritte als plans/*.md vor; im Backlog-Auswahlmenü aktivierst du einen Plan, und ein Build-Run setzt ihn auf dem bestehenden Code um.

Quarkus-Backend & ausführliches Benutzerhandbuch

Der Wizard kennt jetzt Quarkus als Backend, und es gibt ein umfangreiches Benutzerhandbuch (DE + EN) für den Einzelplatz.

• Quarkus als Backend-Stack (Java) neben Spring Boot — Quarkus REST + Hibernate ORM Panache, Maven/Gradle, optional Native-Image. Kombinierbar mit den Java-Frontends und den agnostischen SPA-/Client-Frontends.
• Benutzerhandbuch: Einzelplatz-Setup (Claude-Abo / Codex-Abo / API-Keys), Projektdefinition mit Beispielen, Run-Lebenszyklus und eine ehrliche Einordnung, was die Fabrik heute beim weiteren SDLC (Weiterentwicklung über Versionen) leistet — und was noch fehlt.
• Politur: echte Umlaute im deutschen Wizard-UI; saubere Cache-Header (keine veralteten Seiten nach Updates).

Stack-Wizard (Plattform × Backend × Frontend) & Codex-Abo

Zwei große Bausteine: der Projekt-Assistent kombiniert jetzt Stacks frei, und OpenAI Codex läuft — wie Claude — über dein Abo statt über einen API-Key.

Projekt-Wizard: Zielplattform × Backend × Frontend(s)

• Drei orthogonale Dimensionen statt einer Template-Wahl: zuerst die Zielplattform(en) Web/Mobile/Desktop (Mehrfachauswahl), dann ein Backend (0..1), dann Frontend-Stacks (0..N). Damit lassen sich Full-Stack- und Multi-Target-Produkte ausdrücken — ein Backend mit Web-Frontend und Mobile-App.
• Kompatibilitäts-Filter + Coverage-Warnung: server-rendered Frontends sind sprachgebunden (Vaadin/Thymeleaf → Java, Blazor/WPF → .NET), SPA/Mobile/Desktop-Clients sind runtime-agnostisch via REST. Fehlt für eine Plattform ein Frontend, wird gewarnt.
• Mehrteiliger Objective-Prompt: Backend-Basis + Frontend-Basen + Integrations-Snippets (SPA-REST, server-rendered, gemeinsamer API-Contract, Monorepo-Layout). Katalog: 17 Templates, 12 Frontends.

OpenAI Codex über ChatGPT-Abo

• Codex-Abo-Modus analog zum Claude-Abo: SOFTWAREFABRIK_CODEX_AUTH_MODE=subscription lässt Codex über den ChatGPT-Plus/Pro-Login (codex login) laufen; OPENAI_API_KEY wird im Abo-Modus aus dem Subprozess gestrippt, optional CODEX_HOME gesetzt. In der Einstellungen-UI umschaltbar.

Windows-nativer Einzelplatz-Betrieb & Boot-Härtung

Der Claude-Abo-Modus läuft jetzt nativ unter Windows — ohne WSL-Umweg — plus zwei Boot-Fixes und ein neues Pflicht-Gate gegen Start-Regressionen.

Claude-Abo nativ unter Windows (ohne WSL)

• OS-bewusste Env-Allowlist: unter Windows werden USERPROFILE, APPDATA, LOCALAPPDATA, SYSTEMROOT, COMSPEC, PATHEXT … durchgereicht und case-insensitiv abgeglichen — sonst fände claude sein %USERPROFILE%\.claude nicht. Das ANTHROPIC_API_KEY-Stripping im Abo-Modus ist ebenfalls case-insensitiv. Unix/WSL-Verhalten unverändert.
• OS-bewusster claude-Default: liegt claude.cmd auf dem PATH (npm-Installer), wird es explizit benannt; sonst bleibt das blanke claude, das Windows selbst zu claude.exe auflöst. Explizit konfigurierte Befehle bleiben unangetastet.
• Auf einer echten Windows-10-Maschine end-to-end verifiziert: nativer Abo-Run über das Max-Abo, gesetzter Dummy-API-Key wurde korrekt gestrippt.

Boot-Härtung & Fixes

• Boot-Crash in allen Nicht-demo-Profilen behoben (local/container/prod): ein disabled FilterRegistrationBean mit null-Filter ließ den Tomcat-Start seit Spring Boot 4.0.7 abstürzen. Suppression-Bean an @Profile("demo") gebunden.
• /teams/{id}-500 behoben: LazyInitializationException auf team.members beim Rendern der Detailseite — die Members werden jetzt per @EntityGraph geladen.
• Boot-Smoke als Pflicht-Gate: neuer CI-Job startet die App via docker compose im container-Profil gegen echtes Postgres und wartet auf /actuator/health=UP — fängt Boot-Zeit-Regressionen, die MOCK-basierte Tests nicht sehen.

Einzelplatz-Lizenz: 30-Tage-Lease mit Refresh

• Community-Lease von 7 auf 30 Tage angehoben; Lease-Refresh best-effort bei jedem App-Start. Ist der Lizenzserver nicht erreichbar, läuft die Fabrik mit vorhandener Lease + 30 Tage Grace weiter — der Start wird nicht blockiert. Air-Gap-Modus unverändert.

Härtung & Qualität: Coverage, ArchUnit, Aufräumung

0.9.1 ist ein reines Qualitäts-Release auf Basis von 0.9.0 — keine neuen Features, dafür mehr Sicherheit durch Tests und festgezurrte Architektur.

• Mehr Test-Coverage: gezielter Issuer-Sicherheitstest im LicenseVerifier (die Issuer-Validierung war zuvor ungetestet) und testbares CSV-Escaping im Analytics-Export. Branch-Coverage 0.815 bei einem Gate von ≥0.80.
• Erweiterte ArchUnit-Regeln: hexagonale Ports-and-Adapters-Regeln plus ein Freeze-Ratchet gegen Modul-Zyklen und web→repository-Quergriffe — Architekturverstöße brechen den CI-Lauf.
• Doku- und DRY-Aufräumung: package-info-Dateien, Doku-Korrekturen und entdoppelter Code.

Claude-Abo-Auth & Prometheus-Observability

Zwei Verbesserungen für angenehmeren Einzelplatz-Betrieb und bessere Wartbarkeit.

• Claude-Abo statt API-Key: Coding-Runs laufen wahlweise über dein Claude-Max/Pro-Abo statt über einen separaten ANTHROPIC_API_KEY — umschaltbar per SOFTWAREFABRIK_CLAUDECODE_AUTH_MODE=subscription. Komplette Anleitung: Einzelplatz mit Claude-Abo. Bring-Your-Own-Subscription für mehrere Pro-Nutzer ist vorbereitet.
• Prometheus-Metriken (Observability Ebene 1): Scrape-Endpoint /actuator/prometheus für JVM-, HTTP- und DB-Pool-Metriken als Basis für Grafana & Alerting. Auf ROLE_ADMIN beschränkt, per HTTP-Basic gescraped, mit gemeinsamem application-Label.

Beides ist test-abgedeckt und ändert bestehende API-Key-Setups nicht.

Wizard-Polish: Stepper, Objective-Vorschau, Validierung

Reines UX-Update für den Projekt-Assistenten. Vier sichtbare Verbesserungen, die den Wizard von "funktioniert" auf "fühlt sich rund an" heben.

• Progress-Stepper: Visueller Indikator 1→2→3→4 oben auf jedem Schritt; erledigte Schritte sind Links zurück.
• Objective-Vorschau in Schritt 4: collapsible Karte mit dem fertig komponierten Initial-Objective-Prompt.
• Server-seitige Pflichtfeld-Validierung: fehlende Felder führen zu Redirect mit Fehlerliste, schon eingegebene Werte bleiben erhalten.
• Versions-Cache-Empty-State: "Versionen werden nachgeladen..." + Link zur Admin-Cache-Seite, statt eines stumm leeren Feldes.

Wizard-Kostenschätzung, Inline-Diffs, Browser-Notifications

Zwei vertagte Bausteine geschlossen: der Wizard zeigt schon vor dem ersten Run, was er grob kostet, und die Approval-View zeigt einen echten Diff der Workspace-Änderungen statt blinden "Approve/Reject"-Knöpfen.

Wizard Schritt 4 — Kosten-Schätzung (Phase 4.5)

• WizardCostEstimator verbindet PromptComposer, TokenEstimator (JTokkit) und ModelPricingProperties. Lokale EUR-Schätzung, kein LLM-Call.
• Default claude-sonnet-4-6, Output-Annahme 1.5x Input. Unbekannte Modelle zeigen "keine Preistabelle hinterlegt".

Inline-Diffs vor Approval (Phase 7.5b)

• GitService.diffSeit() shellt git diff --no-color <sha> aus dem Workspace, gekappt bei 256 KB.
• Bei WAITING_FOR_APPROVAL blendet die Detail-View den Diff seit dem frühesten Checkpoint des Runs als collapsible Karte ein.

Browser-Notifications (Phase 7.5a)

• LogStreamService emittiert ein status-SSE-Event pro Poll-Zyklus bei Statuswechsel.
• Notifications feuern bei COMPLETED, FAILED, TIMEOUT, CANCELLED, NEEDS_CORRECTION, WAITING_FOR_APPROVAL.

Run-Templates, Container-Sandbox, Live-Token-Stream

Drei ausstehende Bausteine aus dem Sicherheits- und Wiederverwendungs-Block.

Run-Templates (Phase 7.5)

• Aus einem abgeschlossenen Run lässt sich ein RunTemplate speichern (Adapter, Team, Ziel). Beim nächsten Quick-Start ist es der bevorzugte Vorschlag.
• Audit-Events RUN_TEMPLATE_CREATED/UPDATED/DELETED.

Container-Sandbox pro Run (Phase 8, ADR-0011 B)

• ContainerProcessSandbox startet jeden Agent in einem ephemerem Docker/Podman-Container mit --cpus 2 --memory 4g --pids-limit 512 --read-only --network=none.
• Workspace per Bindmount auf /workspace; alles andere unsichtbar.
• Auswahl per Setting execution.sandbox.variant=container; Fallback auf Local mit Log-Warnung, wenn Docker fehlt.

Live-Token-Stream + lokale Schätzung (Phase 9, ADR-0013)

• ClaudeStreamJsonParser liest --output-format=stream-json zeilenweise, emittiert pro Event ein typisiertes ExecutionEvent.Usage.
• TokenEstimator (mit com.knuddels:jtokkit:1.1.0) liefert lokale Schätzungen vor Run-Start.

Conductor: Modell-Routing, Plugin-Sync und Repo-Import

Die Plattform hört auf, ein Wrapper um Claude Code zu sein, und wird zum Conductor des gesamten Setups.

Modell-Routing pro Agent-Rolle (Phase 5)

• Default-Mapping: Architect & Documentation → claude-opus-4-7; Developer/QA/Merge-Release → claude-sonnet-4-6; Reviewer/Security → claude-haiku-4-5.
• AgentDefinition bekommt nullable preferredModel-Feld (V14). Claude-Code-Adapter hängt es als --model-Flag an. Drift-Erkennung emittiert ein OUTPUT-Event bei Modell-Abweichung.

Plugin- und Skills-Sync (Phase 6)

• Modul conductor scannt ~/.claude/plugins/ und ~/.claude/skills/ mit Path-Traversal-Schutz.
• Vor jedem Run schreibt die Plattform .claude/settings.local.json und .claude/agents/<rolle>.md pro Team-Mitglied ins Workspace.

Repo-Import-Template (Phase 7, teilweise)

• Sechstes Wizard-Template existing-repo-import: statt ein neues Skeleton anzulegen, weist es Claude Code an, ein vorhandenes Repo zu inspizieren und einen IMPORT_REPORT.md zu schreiben.

Project-Memory via PROJECT_NOTES.md

Das freeText-Feld der ProjectDefinition wird beim Run-Start automatisch als PROJECT_NOTES.md in den Workspace-Root geschrieben.

Polyglott: der Wizard deckt jetzt fünf Stacks ab

Drei neue Wizard-Templates für die häufigsten Backend-Stacks der Solo-Entwickler: dotnet-backend (ASP.NET Core), python-fastapi und node-express. Beweis, dass die Phase-4.5-Architektur (Templates als Code-as-Data plus Snippets) wirklich tragfähig für weitere Familien ist.

Settings, Wizard, Versions-Cache

Vier große Feature-Pakete: Settings-UI unter /einstellungen, Projekt-Assistent unter /wizard mit zwei Templates, täglicher Versions-Cache aus Maven Central / npm / GitHub, Quick-Start in der Run-Liste. Plus pgJDBC 42.7.11 (CVE-Fix) und Postgres-Loopback-Pinning.

Token, Kosten, Live-Logs: aus Black-Box wird Cockpit

Großer Frontend-Sprung: Dashboard mit 14-Tage-Token- und Kostenkurven, eigene Analytics-Seite (Tokens, Kosten, Budget, Adapter-Vergleich), Live-Logs per Server-Sent-Events sowie Pause/Resume und Batch-Cancel für Runs. Dazu Run-Metrics-Schema (Migration V7), Modell-Preistabelle und Monatsbudget pro Projekt mit Soft-Schwelle und optionalem Hard-Block (V8).

Review-Schicht und Quality-Gate: aus „schreibt Code" wird „prüft Code"

Zweite Säule der Plattform: eine read-only Review-Schicht mit aggregierendem Quality-Gate. aider-review und claude-review laufen read-only; security, architecture-reviewer und hallucination-review arbeiten als statische Heuristiken. Konfigurierbare Policy (strict/lenient), Sonderregeln für SECURITY/HIGH und ARCHITECTURE/CRITICAL, Quality-Gate-UI und ein Demo-Profil für demo.softwarefabrik.io.

Vier Adapter statt einem: Codex, Gemini und Aider sind dazugekommen

Neue Adapter-Registry: pro Run wählbar, welcher Agent arbeitet. Dazu OpenAI Codex (codex exec), Google Gemini (gemini -p) und Aider (konfigurierbares Modell-Backend). Mock bleibt der DEMO-Default — ohne Lizenz, ohne externe Tools. Alle Vendor-Adapter sind ab Community aktiv; neue /changelog-Seite, Adapter-ID in der Run-Tabelle (V3).

Erste produktiv lauffähige Version

Start als lokale Control Plane für AI-gestützte Softwareentwicklung — mit Claude Code als initialem Entwicklungsagenten, Lease-basiertem Lizenz-Stack (Keycloak + Spring-Boot-License-Service) und barrierearmer Thymeleaf-UI. Projektidee-Wizard mit Markdown-Generator, Run-Lebenszyklus mit Phasen und Audit-Log, Workspace-Anlage mit Git-Init und Build-Gate (mvn verify), Approval-Policies und Air-Gap-fähiges Lease-System mit COMMUNITY/PROFESSIONAL/ENTERPRISE.