News-Archiv: Versionen vor 0.40.

Patch: Ein sauberer Lauf ist ein bestandener Lauf

Ein Patch-Release ohne neue Funktionen und ohne Migration. Unter der Quality-Gate-Policy strict galten die Pflichtkategorien Security und Architektur nur dann als geprüft, wenn ein Reviewer darin einen Befund meldete. Ein Lauf ganz ohne Befunde endete deshalb in ERROR, im blockierenden Modus sogar mit einer Korrekturschleife für null Findings. Jetzt gibt jeder Reviewer an, was er tatsächlich prüft; ist er gelaufen, gilt die Kategorie als abgedeckt. Fehlt ein Reviewer oder bricht er ab, bleibt es bei ERROR.

Dazu kommen Präzisierungen in Handbüchern und Release-Notes, unter anderem zu minAcAbdeckung, die bei abgeschaltetem Gate nicht geprüft wird.

Spec-Pflicht, die sich nachweisen lässt

Mit 0.39.0 ist die Roadmap zu Spec-Driven Development abgeschlossen. Die letzte Stufe richtet sich an regulierte Umgebungen: Dort reicht es nicht, Specs zu haben — man muss zeigen können, dass gegen eine freigegebene Fassung gebaut und abgenommen wurde.

Spec-Pflicht per Policy

• Eine Policy kann verlangen, dass jeder Build gegen eine freigegebene Spec läuft und jede schreibende Workflow-Aufgabe an eine gebunden ist.
• Eine Mindestabdeckung der Akzeptanzkriterien durch Tests lässt das Quality Gate blockieren, wenn sie unterschritten wird.
• Die Compliance-Profile EU AI Act und BAIT/MaRisk/DORA setzen die Spec-Pflicht.
• Ablehnungen stehen jetzt dauerhaft in der Audit-Kette — bisher wurden sie mit der Ablehnung zurückgerollt.

Unabhängig prüfbar

• Der Audit-Export (Schema 2.1) enthält die signierten Spec-Fassungen samt Freigabe.
• Der Offline-Verifier 1.1.0 prüft Hash und Signatur jeder Fassung und ob jeder Run wirklich gegen sie gebunden war — ältere Exporte bleiben prüfbar, und der bisherige Verifier akzeptiert die neuen.
• Neue Kennzahlen: AC-Abdeckung, Spec-Drift, Anteil der Starts mit freigegebener Spec.

Policy-Pflicht, signierter Export und Kennzahlen gehören zum Tier Enterprise; die übrigen SDD-Funktionen zu Professional.

Die Fabrik prüft gegen die Spec — und schreibt sie mit

Zwei Stufen der SDD-Roadmap in einem Release: Das Quality Gate prüft jetzt, ob das Gebaute die Anforderungen erfüllt, und die Fabrik hilft, Anforderungen überhaupt erst sauber aufzuschreiben.

Conformance: belegt jeder Test, was verlangt war?

• Der neue Reviewer spec-conformance prüft ohne Agent-CLI, ob jedes gebundene Akzeptanzkriterium in mindestens einem Test referenziert ist — per Testname, Annotation @Spec("AC-…") oder Kommentar, für Java, TypeScript/JavaScript und Python.
• Er meldet Tests mit unbekannten Kriterien und geänderte Dateien, die keiner Anforderung zugeordnet sind.
• Im Modus „streng“ ist er Pflicht und blockiert das Gate; im Modus „leicht“ berät er.

Spec-Drift: was eine Änderung veralten lässt

• Wird eine neue Spec-Fassung freigegeben, vergleicht die Fabrik sie Kriterium für Kriterium mit der vorherigen und schreibt das Ergebnis in die Audit-Kette.
• Geplante Aufgaben und Workflow-Tasks, die an entfernte oder geänderte Kriterien gebunden sind, werden als veraltet markiert.
• Verträge mit Akzeptanzkriterien werden strukturell verglichen; ein Bruch macht verknüpfte Specs prüfbedürftig.

Specs im Dialog

• Ein Spec-Run macht aus einer Idee einen Spec-Entwurf mit Zielen, Nicht-Zielen, Akzeptanzkriterien und Randfällen — und stellt Rückfragen, die du in der Oberfläche beantwortest. Danach läuft er mit deinen Antworten weiter.
• Reverse-Spec leitet für ein importiertes Repository einen Entwurf aus Code und Tests ab, mit ausdrücklich gekennzeichneten Annahmen.
• Freigeben bleibt immer eine menschliche Entscheidung.

Vom Akzeptanzkriterium bis zum Commit nachvollziehbar

0.35.0 hat die Specs eingeführt. 0.36.0 verbindet sie mit allem, was danach passiert — damit sich zu jeder Änderung sagen lässt, welche Anforderung sie erfüllen soll.

Spuren in Commit, Kette und Trace

• Commits und Pull Requests der Fabrik tragen Spec: SPEC-012 und Implements: AC-012-03.
• Welche freigegebene Spec-Fassung ein Lauf verwendet hat, steht signiert in der Audit-Kette und im Warum-Trace.

Jeder Agent kennt die Kriterien

• Die Akzeptanzkriterien des Auftrags stehen im Auftrag selbst — für Claude, Codex, Gemini und alle anderen Adapter gleich.
• Ein Spec-Index in AGENTS.md zeigt allen Agenten, welche Specs es gibt.

Parallele Agenten, eine Wahrheit

• Workflow-Tasks binden eine Spec-Fassung; parallele Teilaufgaben arbeiten gegen dieselbe, auch wenn zwischendurch eine neue freigegeben wird.
• Im Modus „streng“ wird ein Plan nur freigegeben, wenn jede schreibende Aufgabe an eine freigegebene Spec gebunden ist. Der Spec-Modus lässt sich jetzt schon im Projekt-Assistenten wählen.
• Freigegebene Akzeptanzkriterien erscheinen automatisch als Vertrag in der Contract Registry.

Nicht nur guter Code — der richtige

Bisher prüfte das Quality Gate, ob Code gut ist. Ob er das tut, was gemeint war, wusste es nicht: Akzeptanzkriterien standen als Freitext im Plan und erreichten die Reviewer nie. Mit 0.35.0 beginnt Spec-Driven Development.

Specs als gemeinsame Wahrheit

• Anforderungen werden zur Produkt-Spec: Ziel, Nicht-Ziele und Akzeptanzkriterien mit IDs (etwa AC-012-03), formuliert bevorzugt in EARS.
• Jede Fassung ist versioniert und unveränderlich. Eine Freigabe durch Maintainer macht sie verbindlich und steht signiert in der Audit-Kette.
• Agenten sehen die Spec im Workspace unter specs/; was sie daran ändern, wird ein neuer Entwurf — freigeben kann nur ein Mensch.

Vom Plan bis ins Quality Gate

• Plan-Runs nennen je Aufgabe Spec und Akzeptanzkriterien; das Backlog führt die IDs.
• Im Modus „streng“ startet ein Build nur gegen eine freigegebene Spec.
• Alle Reviewer bekommen die Akzeptanzkriterien des Auftrags mit — erstmals prüft das Gate gegen das, was verlangt war.

Opt-in per Feature-Flag, für Professional und Enterprise. Auf der Demo ist es eingeschaltet. Was folgt — Rückverfolgung bis in Commits, ein Conformance-Reviewer, Spec-Drift und Specs im Dialog — steht in der Roadmap.

Gezielt öffnen, konsequent absichern, ehrlich rechnen

Bisher erreichte kein Agentenlauf irgendeinen MCP-Server — das war Absicht. Mit 0.34.0 lässt sich das gezielt öffnen, ohne die Kontrolle abzugeben. Und ein genauer Blick auf die eigene Absicherung hat zwei Lücken gefunden, die jetzt geschlossen sind.

MCP-Gateway: freigegebene Werkzeuge, jeder Aufruf signiert

• Ein eigener Gateway-Prozess stellt Agenten nur lesende Werkzeuge ausdrücklich freigegebener MCP-Server bereit — zunächst bei der Ausführung mit Claude Code.
• Server werden vermessen und mit Prüfsummen festgeschrieben; weicht ein Server später ab, steht das in der Audit-Kette. Jeder Werkzeugaufruf ist signiert protokolliert.
• Standard bleibt aus: Wer den Gateway nicht einschaltet, merkt keinen Unterschied.

Zwei Sicherheitslücken geschlossen

• Importierte Repos: Claude Code führt im Headless-Modus die Hooks aus .claude/settings.json eines Projekts aus — ohne Rückfrage. Die Fabrik startet die CLI jetzt so, dass Projekt-Settings und Hooks nicht greifen, und vermerkt solche Einträge in der Audit-Kette.
• Workflow-Ebene (Feature-Flag, Standard aus): Freigaben und Starts prüfen jetzt Rolle und Mandant; fremde Workflows sind „nicht gefunden“.

Ehrliche Zahlen

• Claude-Läufe wurden mit 0 EUR bewertet, weil die Fabrik ein Feld las, das die CLI gar nicht liefert. Jetzt zählen alle Modelle samt Subagenten und die Cache-Schreib-Tokens; die Kostenschätzung der CLI erscheint als Gegenprobe im Warum-Trace.
• Die Planfreigabe zählt in der Kennzahl „Eingriffe“ mit und hat ein eigenes Aufwandsfeld.
• Robuster Agentenprozess: stderr getrennt, begrenzte Ausgabe, das letzte JSON-Ergebnis zählt.

Patch: Abhängigkeiten auf dem neuesten Stand

Ein reines Wartungsrelease ohne neue Funktionen und ohne Migration: Jackson 3 auf 3.2.4 und Hibernate ORM auf 7.4.13 (Patchlinie 7.4). Alle übrigen Abhängigkeiten und Build-Plugins sind auf dem neuesten stabilen Stand; Spring Boot bleibt auf 4.1.1, weil 4.2 bisher nur als Milestone vorliegt.

Die Claude-Anbindung sagt, was wirklich passiert ist

Ein genauer Blick auf die Anbindung an Claude Code hat vier Stellen gefunden, an denen die Fabrik Erfolg meldete, ohne ihn belegt zu haben. Alle vier sind behoben.

Kein stilles „bestanden“ mehr

• Reviews: Ein Review, das mit Fehler endet oder kein erkennbares Ergebnis liefert (Anmeldefehler, Rate-Limit, Freitext), galt bisher als „ohne Befund“. Jetzt ist es ein Fehler, und das Quality Gate behandelt es so.
• Quality Gate: Es prüfte einen leeren Diff, weil die Arbeit eines Runs vor dem Gate schon committet war. Jetzt prüft es den Branch-Diff des Runs, kumulativ über alle Korrekturschleifen, samt Architekturvorgaben und Definition of Done.
• Abbrechen: „Run abbrechen“ setzte nur den Status. Jetzt beendet es den Agentenprozess samt Kindprozessen; Timeouts ebenso.
• Build-Runs: Ohne Freigaben schrieb Claude Code headless keine Dateien. Builds laufen jetzt mit einem festen Permission-Vertrag und einer engen Werkzeugliste, Reviews technisch read-only.

Ehrlich bei Abo und Kosten

Der Abo-Modus ist als das beschrieben, was er ist: persönliche Nutzung durch den Abo-Inhaber auf dem eigenen Rechner. Die Ankündigung „mehrere Nutzer mit eigenem Abo auf einem Server“ ist gestrichen und der vorbereitete Code entfernt. Kosten von Abo-Läufen sind in Warum-Trace, Mandanten- und Seat-Sicht sowie CSV als Schätzung zum API-Tarif gekennzeichnet.

Aktuelle Modelle

Preistabelle und Modell-IDs folgen der offiziellen Übersicht (Stand 19.10.2026): Opus 5.5 plant, Sonnet 5.5 baut, Haiku 5.5 reviewt, sofern Team oder Routing nichts anderes festlegen. Fable 5.1 ist wählbar, aber nie Voreinstellung. Dazu ein Abhängigkeits-Sweep (u. a. Flyway 13, Jackson 3.2.3, Tomcat 11.0.27).

Ein Nachweis, den man nachprüfen kann, ohne der Fabrik zu glauben

Die Fabrik führt seit Langem eine signierte, lückenlos verkettete Audit-Kette und kann sie exportieren. Nur: Wer den Export prüfte, bekam vor allem das Urteil der Fabrik über sich selbst — Felder wie „intakt“ und „Kette in Ordnung“. Nachrechnen ließ sich das nicht, und weil die Kette über alle Mandanten läuft, war aus einem Projekt-Export nicht zu beweisen, dass nichts weggelassen wurde.

Der Export beweist jetzt selbst

Er enthält die Einträge des Projekts vollständig und nachrechenbar, dazu für alle anderen Einträge im Zeitraum nur Hash und Signatur — genug, um Lücken zu erkennen, ohne fremde Mandanten offenzulegen. Hinzu kommen der signierte Ketten-Kopf, die Policy-Version, die für einen Run tatsächlich galt, und je Run ein signiertes Verzeichnis seiner Ereignisse.

Und ein Werkzeug, das man nicht von der Fabrik bezieht

Der Offline-Verifier prüft all das ohne Zugang zur Fabrik: rund tausend Zeilen Java, nur mit dem JDK, reproduzierbar gebaut, samt Quelltext zum Download. Vertrauen entsteht über den Fingerabdruck des Signaturschlüssels, den man auf einem zweiten Weg bestätigen lässt — ohne ihn endet die Prüfung nie mit „bewiesen“.

Ein unabhängiger Sicherheits-Review hat vor der Auslieferung zwei Wege gefunden, Ereignisse eines Runs unbemerkt zu verstecken oder umzuhängen. Beide sind geschlossen; die signierten Ereignisverzeichnisse sind die Antwort darauf.

Kein Agentenlauf erreicht mehr einen MCP-Server, den niemand freigegeben hat

Agent-CLIs wie Claude Code, Codex oder Gemini laden MCP-Server aus vielen Quellen: aus dem Heimatverzeichnis des Nutzers, aus Plugins, aus einer .mcp.json im Repository. Bis v0.30 liefen sie mit dem HOME des Betriebsnutzers — jeder Lauf sah dessen Server, Hooks, Git-, SSH- und Cloud-Zugänge. Und ein kurzer Test mit Claude Code 2.1.283 zeigte: Im nicht-interaktiven Modus startet eine .mcp.json im Workspace ohne Rückfrage. Ein importiertes Repository konnte so beim ersten Lauf Befehle auf dem Host ausführen.

Der Nullzustand

Jeder CLI-Aufruf bekommt jetzt ein frisches, leeres HOME. Hinein kommt nur die Anmeldedatei des jeweiligen Adapters, als Kopie; erneuerte Tokens gehen nach dem Lauf an das Original zurück. Claude Code läuft zusätzlich mit einer leeren, erzwungenen MCP-Konfiguration. Plugins sind standardmäßig gesperrt und werden per Policy freigegeben. Und was im Workspace an Agent-Konfiguration liegt, wird vor und nach jeder Ausführung erfasst und in der Audit-Kette festgehalten.

Nachweis statt Annahme

Ob eine CLI-Version sich daran hält, sagt keine Konfigurationsdatei und kein mcp list. Deshalb gibt es den Canary: Er platziert Marker-Server in einer nachgestellten Host-Umgebung, prüft mit einem Lauf ohne Isolation, dass sie wirklich geladen würden — sonst hat der Test nichts bewiesen —, und mit einem Lauf über den echten Adapter-Pfad, dass keiner startet. Das Ergebnis wird signiert und je CLI-Version festgehalten.

In den regulierten Profilen (BAIT/MaRisk/DORA, BSI/VS-NfD) ist dieser Nachweis Pflicht. Bis ein Administrator ihn für die installierte Version erzeugt hat, läuft dort nur der Mock — bewusst: Eine unbekannte CLI-Version gilt als nicht isoliert, bis das Gegenteil gezeigt ist.

Und darunter

Spring Boot 4.1.1 mit Tomcat 11.0.26: Die bis November befristet akzeptierte Tomcat-Schwachstelle ist damit behoben, drei neu veröffentlichte kritische gleich mit. Beim Sprung fiel auf, dass eine Bibliothek, die die Fabrik direkt nutzt, bisher nur zufällig über den Migrationsbaukasten mitkam — sie steht jetzt ausdrücklich im Build.

Eine Lücke, die man nicht schließt, sondern zerlegt

Die hartnäckigste der vier Messlücken heißt „menschliche aktive Arbeitszeit“. Die Fabrik sieht, wie lange etwas wartete — nicht, ob jemand daran arbeitete. Drei Wege wären denkbar, und keiner davon ist eine Messung: Wartezeit als Arbeitszeit auszugeben wäre schlicht falsch beschriftet; Menschen zu instrumentieren wäre Überwachung — und ein offener Browser-Tab ist trotzdem keine Arbeit; jemanden zu fragen ist Selbstauskunft.

Die Lücke bleibt deshalb stehen. Was sich aus ihr herauslösen ließ, steht jetzt aber getrennt daneben.

Was gemessen wird

Eingriffe und Entscheiderzahl. Wie oft musste ein Mensch überhaupt entscheiden, und wie viele Personen waren beteiligt? Beides steht bereits in den Freigabeentscheidungen. Das beantwortet die eigentlich interessante Frage — wie viel menschliche Beteiligung ein Vorhaben braucht — ohne vorzugeben, Arbeitszeit zu messen.

Was erfragt wird — und als solches gekennzeichnet ist

An der Freigabe steht ein freiwilliges Aufwandsfeld. Das ist eine Selbstauskunft, keine Messung, und wird nie mit abgeleiteten Werten verrechnet. Daneben steht immer die Aufwandsabdeckung: „45 min (aus 3/12)“ macht sichtbar, dass neun Entscheidungen keine Angabe haben. Ohne diese Quote würde die Summe als Gesamtaufwand gelesen — also genau die Verwechslung, gegen die die Lücke überhaupt formuliert wurde.

Und ein Test, der zwei alte Ausfälle nachträglich unmöglich macht

Zweimal hat dieselbe Fehlerklasse zugeschlagen: eine Migration, die eine Spalte anders benennt oder anders typisiert als das Datenmodell. Einmal kostete das die Demo einen Deploy und einen Rückbau. Kein Test konnte das sehen — die Testsuite baut ihr Schema aus demselben Datenmodell und findet deshalb per Konstruktion keine Abweichung zu den Migrationen. Aufgefallen ist es nur beim Startversuch, dem langsamsten und spätesten Schritt.

Jetzt prüfen zwei Tests genau das: einer die Namen in Sekunden, einer Typen und Längen gegen eine echte Datenbank. Beide sind gegen eine absichtlich eingebaute Abweichung geprüft — ein Test, der nicht scheitern kann, wäre wertlos.

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 große 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.