Was sich an der Fabrik getan hat.

Ehrliche Meldungen rund um den Projektordner

Nachlese zur Sicherung aus 0.52.5, gefunden in einer ausführlichen Probe: „Erneut versuchen“ machte aus einem Plan-Lauf einen Bau-Lauf — behoben. Ein Unterordner mit eigenem Git-Repository ließ jeden Lauf scheitern; solche Ordner lässt die Fabrik jetzt aus und nennt sie. Eigene Änderungen an PROJECT_NOTES.md und an Dateien unter .claude/ gehen nicht mehr still verloren: Die Fabrik sichert sie vor dem Neuschreiben und nennt den Befehl zum Zurückholen. Die Laufseite zeigt jetzt, was ein Lauf nicht übernommen hat und wie man es zurückholt; die angezeigten Befehle tun genau das, was daneben steht.

Plan-Läufe löschen keine eigene Arbeit mehr

Wer im Projektordner etwas änderte, während ein Plan- oder Spec-Lauf auf die Freigabe wartete, konnte diese Änderungen verlieren: Der Lauf räumte den Ordner am Ende hart auf. Jetzt sichert die Fabrik den Stand vor dem Agenten und stellt ihn danach wieder her; verworfen wird nur, was der Agent außerhalb der erlaubten Ordner hinterlassen hat — und auch das bleibt als Sicherung im Repository abrufbar. Der Fehler bestand seit 0.13.0. Außerdem neu: Liegen beim Start eines Laufs ungespeicherte Änderungen im Projektordner, übernimmt die Fabrik sie weiterhin in einen Commit, sagt das aber im Protokoll und auf der Laufseite.

Zusammenführen und Pull-Requests nur mit Lizenz

Mock-Läufe bleiben ohne Lizenz möglich — zum Ausprobieren. Die Übergabe-Funktionen der Fabrik gibt es dagegen nur mit gültiger Lizenz: Zusammenführen, Push und Pull-Request sowie die Meilenstein-Freigabe. Ohne Lizenz endet ein Mock-Lauf sauber, das Ergebnis bleibt auf seinem eigenen Zweig, und die Laufseite sagt das deutlich. Für Läufe mit echten KI-Agenten ändert sich nichts; ein erreichtes Tageslimit hält ihr Zusammenführen nicht auf.

Ohne Lizenz direkt ausprobieren

Wer noch keine Lizenz hat, kann jetzt sofort loslegen: Schnellstart, Projektseite und „Neuer Lauf“ sagen vor dem Klick, dass der Durchgang mit dem Mock läuft und kein echter Code entsteht, und starten ihn dann. Bisher endete der Klick in einer Fehlerseite. Die Ersteinrichtung bietet „Erst ohne KI-Agent ausprobieren (Mock)“ an, und ein abgelehnter Start führt zurück zum Formular, ohne ein leeres Projekt zu hinterlassen.

Mock-Läufe ohne Lizenz

Läufe mit dem Mock brauchen keine Lizenz mehr, auch nicht im Startpaket: Du kannst die Fabrik direkt nach der Installation ausprobieren, ohne etwas anzufordern. Mock-Läufe zählen nicht gegen das Tageslimit. Für echte KI-Agenten gilt die Lizenz unverändert; in einem Mock-Lauf überspringt das Quality Gate die Reviewer, die ein KI-Programm starten würden — der Mock ruft kein KI-Modell auf. Das von Hand ausgelöste Quality Gate startet solche Reviewer nur noch mit aktuell gültiger Lizenz.

Freigabe und Abbruch klar getrennt

Auf der Laufseite steht die Freigabe jetzt als eigener, abgesetzter Block mit ihren freiwilligen Feldern und dem Knopf „Freigeben und fortsetzen“. Der Abbruch steht getrennt darunter, mit eigenem, eindeutig beschriftetem Feld. Bisher standen beide Felder so nah beieinander, dass unklar war, welches zu welchem Knopf gehört.

Leichterer Einstieg mit Spring Boot

Der Schnellstart für Web-Anwendungen mit Java nutzt jetzt eine eingebettete Datenbank, die ohne Server auskommt und die Daten nach dem Neustart behält. Bei Projekten mit getrenntem Backend und Frontend findet die Build-Prüfung den Ordner backend/ selbst und zeigt den passenden Startbefehl. Der Assistent nennt die Zielplattformen verständlich und zeigt nach dem Anlegen den nächsten Schritt. Gradle lässt sich unter Einrichtung → Werkzeuge installieren.

Versionswechsel unter Windows per Skript

Windows bekommt uebernehmen.ps1: Es übernimmt beim Versionswechsel Einstellungen, Datenbank und Arbeitskopien, mit denselben Sicherungen wie das Linux-Skript. start.ps1 startet jetzt auch auf einer frischen Installation unter Windows PowerShell 5.1, liest Pfade mit Umlauten richtig und hinterlässt keine Einstellungen mehr im PowerShell-Fenster. Beide Umzugsskripte prüfen den Bestand zusätzlich mit einer Prüfsumme über Dateinamen und Größen.

Versionswechsel nimmt die Arbeitskopien mit

Beim Wechsel auf eine neue Version zieht uebernehmen.sh die Arbeitskopien jetzt in den neuen Ordner um, statt im Ordner der alten Version weiterzuarbeiten. Die Fabrik passt beim ersten Start alle gespeicherten Pfade an und meldet im Startprotokoll, ob der Umzug gelungen ist. Danach kann der alte Ordner gelöscht werden. Wer die Arbeitskopien am alten Ort lassen will, nutzt --workspaces-belassen.

API-Schlüssel wechseln leicht gemacht

Die Einrichtung hat in „Einfach“ eine eigene Karte „API-Schlüssel“. Die Seite sagt je Anbieter klar „Schlüssel wechseln“ oder „Schlüssel eintragen“ und weist darauf hin, wenn ein Schlüssel aus einer Umgebungsvariable des Rechners Vorrang hat. Scheitert ein Lauf wegen des Schlüssels, führt ein Link auf der Laufseite direkt dorthin.

Schnellstart für Spring Boot repariert

Der Schnellstart legt jetzt Java-Version, Datenbank, Architektur und Paketname selbst fest, statt unausgefüllte Platzhalter in den Auftrag zu schreiben. Ein Spring-Boot-Projekt mit Thymeleaf entsteht in einem Ordner, damit die Build-Prüfung es findet. Die Ergebnisseite zeigt den Startbefehl auch bei neu angelegten Projekten und nennt für Spring Boot mit Gradle bootRun. Das Startpaket enthält eine neue Spring-Boot-Anleitung.

Website und Doku neu geordnet

Vier Wege ab der Startseite — Produkt, Demo, Installieren, Preise — mit neuer Navigation, Mobil-Menü und einheitlichem Bezugsweg („Startpaket auf Anfrage“); neue Seite „Begriffe und Hilfe“. In der App zeigen Nutzermenü und Footer wieder die richtige Build-Zeit statt „1980“.

Community-Lizenz: Uhrabweichung toleriert

Beim Live-Test der Community-Lizenz verwarf die Fabrik ein frisch ausgestelltes Lease, weil die Uhr des Rechners eine Sekunde hinter dem Lizenzserver lag. Jetzt sind bis zu fünf Minuten Abweichung erlaubt — das betraf auch Aktivierung und Erneuerung gekaufter Lizenzen. Geprüft gegen den echten Lizenzserver: anfordern, Lauf starten, erneuern.

Community-Lizenz direkt in der Fabrik anfordern

• Community-Lizenz: Unter Einrichtung → Lizenz holt sich die Fabrik die kostenlose Lizenz selbst — nur E-Mail-Adresse, kein Konto. 10 Läufe am Tag, 3 Agenten gleichzeitig, bis zu 3 Rechner je E-Mail, Erneuerung alle 30 Tage online.
• Öffentliche Demo: Gesperrte Aktionen zeigen eine klare Meldung statt der Anmeldeseite.

Folgepunkte aus der 0.50-Abnahme

• Dashboard in „Einfach“ ohne NVD-Warnung; Laufseite: „Abbrechen“ abgesetzt, der Grund ist eingeklappt.
• Öffentliche Demo: Einstellungen, Integrationen, Nutzer, Lizenz und Regeln nur lesbar.
• Academy: „Teil-Lauf“ statt „Child Run“.

Sicherheitskorrektur für die öffentliche Demo

Auf demo.softwarefabrik.io ist jeder Besucher automatisch Administrator. Die mit 0.50.0 neue Einrichtung (Systemprüfung, Ersteinrichtung, Import-Ordner und Git-Hosts) ist dort jetzt gesperrt und wird nicht verlinkt — sonst hätten Besucher Server-Verzeichnisse als Import-Ordner freigeben können. Einzelplatz- und Team-Installationen sind nicht betroffen.

Einfacher bedienen, Teil 4: Barrierefreiheit, Orientierung, Handbuch neu

Der letzte Block aus dem Usability-Plan. 0.50.0 ist die erste Auslieferung seit 0.47.0 und enthält auch alles aus 0.48.0 und 0.49.0.

• Barrierefreiheit: alle Tabellenköpfe mit scope, Beschriftungen für die letzten Eingabefelder ohne, der Menüknopf auf schmalen Bildschirmen ist ein echter Knopf (Tastatur, Escape schließt); Code-Ansichten, Hinweisleiste und Budgetbalken passen sich dem Dunkelmodus an.
• Orientierung: Brotkrumen (Projekte › Projekt › Lauf › Logs) statt verschiedener Zurück-Links; neue Seite „Begriffe erklärt“ im Nutzermenü — die Wörter der Fabrik in einfacher Sprache.
• Handbuch neu: Das Benutzerhandbuch folgt dem geführten Weg — Ersteinrichtung, Schnellstart, Laufseite, Ergebnis, Projektseite; ein eigenes Kapitel für „Einfach“ und „Experte“, alles Weitere im Experten-Kapitel. Das Administrationshandbuch spricht durchgehend von „Einrichtung“.

Einfacher bedienen, Teil 3: Einrichtung, Systemprüfung, Hintergrundlauf

Nicht separat ausgeliefert, enthalten in 0.50.0.

• Systemprüfung: eine Seite zeigt, ob die Fabrik für einen echten Lauf bereit ist — Agent-Programme, Anmeldung, git, Docker, Build-Werkzeuge, Import-Ordner, Git-Hosts, Lizenz, Workspace; je Zeile Befund, Erklärung und nächster Schritt.
• Ersteinrichtung in drei Schritten: KI-Agent und Abo oder API-Schlüssel wählen (der Schlüssel wird sofort geprüft), offene Punkte der Systemprüfung beheben, in den Schnellstart. Ohne Lizenzschritt.
• Einrichtung statt Verwaltung: in „Einfach“ vier Karten (KI-Zugang, Werkzeuge & System, Sicherheit, Kosten) im Nutzermenü; Betrieb und Nachweise für Administratoren eingeklappt.
• Ein Ort je Thema: Leitplanken in drei Stufen — Vorsichtig, Ausgewogen, Schnell; Freigabe als eine von drei Optionen (vor der Ausführung, vor dem Merge, nie).
• Entwirrt: eine Seite je Agent; Import-Ordner und Git-Hosts in der Oberfläche statt per Umgebungsvariable; Einstellungen mit KI-Zugang als Tabelle und lesbaren Funktionsschaltern.
• Läufe im Hintergrund: Läufe arbeiten in kurzen Schritten im Hintergrund, die Seite aktualisiert sich selbst. „Pausieren“ hält an der nächsten Schrittgrenze an, „Fortsetzen“ macht dort weiter. Nach einem Neustart werden unterbrochene Läufe als „durch Neustart unterbrochen“ beendet; der Arbeitsstand bleibt auf dem Lauf-Branch.
• Lizenz: Dashboard und Einrichtung nennen nur noch „Lizenz importieren“; das Versprechen „Community starten“ ist entfernt.

Einfacher bedienen, Teil 2: der geführte Weg

Nicht separat ausgeliefert, enthalten in 0.50.0.

• Bauen in einem Schritt: Im Schnellstart legt „Bauen“ das Projekt an und startet sofort den ersten Lauf; eine Zeile über dem Knopf nennt die erwarteten Kosten.
• Bestehendes Projekt im Schnellstart: Ordner oder Git-Adresse und „Was soll geändert werden?“ genügen — importieren, Sprache und Build-Werkzeug erkennen, ersten Lauf starten.
• Einfache Laufseite: Fortschrittsbalken, Ursache bei Fehlern ganz oben, „Erneut versuchen“ mit „Was soll anders sein?“, Freigabe mit einem Knopf; „Build nicht geprüft“ ist eine Warnung.
• Live-Status: Lauf- und Projektseite aktualisieren sich selbst.
• Projektseite neu: Beschreibung, „Nächster Auftrag“ mit „Bauen“, bisherige Läufe und letztes Ergebnis oben; technische Einstellungen gesammelt darunter.
• Ergebnis erreichbar: als ZIP herunterladen, konkreter Startbefehl aus der echten Projektdatei, „Weiter verbessern“ und „Vorschläge machen lassen“.
• Behoben: Gleichzeitige Aktionen konnten an der Audit-Kette mit einem Datenbankfehler scheitern; die Kette wird jetzt bis zum Abschluss gesperrt.

Einfacher bedienen, Teil 1

Der erste Block aus dem Usability-Plan: weniger Stolpersteine, klarere Sprache, und das Fundament für einen Einfach- und einen Experten-Modus.

• Ein Einstieg: „Neues Projekt“ führt direkt in den Schnellstart; leere Seiten zeigen den nächsten Schritt.
• Klare Begriffe: „Lauf“ statt „Run“, deutsche Statusnamen, durchgehend „du“, Seitentitel passend zu den Kacheln.
• Rückmeldungen: Erfolg, Warnung und Fehler sehen unterschiedlich aus; Löschen und Verwerfen fragen nach; Knöpfe lösen nicht doppelt aus.
• Auf dem Handy nutzbar: alle Seiten, Tabellen scrollen seitlich.
• Einfach | Experte: ein Umschalter je Nutzer in der Kopfzeile — die Seiten werden ab 0.48 schrittweise vereinfacht.

Steuerung in der Oberfläche und Rückmeldungen aus dem Testbetrieb

Was für einen Lauf gilt, steht jetzt an einer Stelle — und die Bedienung folgt dem, was Tester als schwierig erlebt haben.

• Leitplanken je Projekt: Quality-Gate, Freigaben, Vier-Augen-Prinzip, Guardrails, Sandbox, Adapter, Budgets und mehr — je Wert mit Herkunft. Einstellbar global, je Mandant und je Projekt; tiefere Ebenen verschärfen nur. Jeder Lauf hält fest, was für ihn galt.
• Agenten, die wirken: Modell, Werkzeuge (Lesen, Git, Bauen und testen, Dateien ändern) und Richtlinie je Agent bestimmen den Aufruf; die Team-Reihenfolge entscheidet, wer plant und wer baut. Agenten und Teams ab MAINTAINER, mit Vorschau „das bekommt der Agent“.
• Laufseite: nur Knöpfe, die gehen; „Was jetzt?“; eine Ergebnis-Karte mit geänderten Dateien und „Selbst ausprobieren“; keine Sackgassen-Fehlerseiten mehr.
• Schnellstart: Name, Art, Beschreibung — die Fabrik legt Projekt und ersten Lauf an.
• Installation und Versionswechsel: install-softwarefabrik.sh prüft und installiert alle Voraussetzungen mit Prüfbericht; uebernehmen.sh übernimmt Einstellungen, Datenbank und Arbeitskopien der alten Version.
• Deutsche Umlaute in allen Meldungen und deutsche Statusnamen.

Praxisreife, Block 2: viele Stacks, Werkzeuge aus der Fabrik

Das Build-Gate baut und testet jetzt weit mehr als Java und .NET — und fehlende Toolchains installiert die Fabrik selbst.

• Neue Projektprofile: Gradle, Python (pip, uv, Poetry), Node.js (npm, pnpm, Yarn), Go, Rust und CMake — erkannt an ihren Projektdateien, mit eigenen Build- und Testschritten.
• Werkzeuge verwaltet die Fabrik: Unter Verwaltung → Werkzeuge installiert sie JDK, Maven, .NET SDK, Node.js, Go und uv ohne Administratorrechte, aus den offiziellen Quellen, mit Prüfsumme. Agent und Build-Gate nutzen dieselbe Toolchain.
• Build-Container je Projekt: eigenes Image, CPUs, Speicher und Zeitlimit — innerhalb der Grenzen des Betreibers; Maven-Image passend zur JDK-Version im pom; gehärtete Container.
• Reviewer sprachneutral: Testdateien nach Profil, Importe ohne Manifest-Eintrag als Hinweis, ehrliche Aussage, wo Regeln nicht greifen; Linter des Projekts (ruff, lint/typecheck) als Prüfschritte.
• Praxis-Suite: sieben öffentliche Referenzprojekte, gegen die jedes Release Import, Profil-Erkennung und Gate-Probelauf beweist.

Praxisreife, Block 1: ehrliches Gate, Projektprofile, Import mit Vorschau

Bestehende Projekte importieren und vor dem ersten bezahlten Lauf wissen, ob die Fabrik sie bauen kann.

• Nicht geprüft ist nicht bestanden: Findet das Build-Gate keinen Build, heißt das Ergebnis „nicht geprüft“ und der Lauf hält vor dem Merge. Je Projekt stattdessen „Lauf scheitern lassen“ oder „Projekt hat bewusst keinen Build“. Eine Freigabe gilt nur für das Build-Ergebnis, zu dem sie erteilt wurde.
• Projektprofile: Jeder Stack ist ein Profil aus Daten — Erkennung, Build-Schritte, erlaubte Agent-Befehle, Testmuster. Maven und .NET sind mitgeliefert; weitere Ökosysteme folgen ohne Änderungen am Gate.
• Import als eigener Schritt: Repository sofort übernehmen (ohne Bauartefakte), Vorschau mit Profilen und gefundener Agent-Konfiguration, Profil bestätigen, Probelauf des Gates als Ausgangslage.
• Sicherheit: Import-URLs bestehen dieselbe Richtlinie wie Push-Remotes; Pfade auf .git umgehen die Import-Freigabe nicht mehr.

Abo-Läufe überstehen das Usage-Limit

Wer Claude Code oder Codex im Abo nutzt, verliert keinen Lauf mehr an das 5-Stunden- oder Wochenlimit.

• Pause statt Abbruch: Erreicht der Agent das Kontingent, geht der Lauf auf PAUSED und setzt nach dem gemeldeten Reset automatisch fort — mit demselben Auftrag, auch in der Korrekturschleife und nach einem Neustart der Fabrik.
• Du behältst die Kontrolle: „Fortsetzen“ zieht den Start vor, „Abbrechen“ wirkt jederzeit. Budget und Attestierungspflicht werden vor der Fortsetzung erneut geprüft; nach fünf Pausen scheitert der Lauf wie bisher.
• Nachvollziehbar: Pause, Fortsetzung und Ablehnung werden attestiert. Im API-Key-Modus ändert sich nichts.

Sicherheits-Patch für importierte Projekte, Testpaket mit Anleitungen

Ein Patch-Release für alle, die bestehende Repositorys in die Fabrik holen.

• Agent-Konfiguration bleibt, wie sie war: Was ein Lauf unter .claude/, in .mcp.json oder in der Konfiguration anderer Agent-CLIs ändert, setzt die Fabrik vor dem Commit zurück — auch wenn der Agent selbst committet hat. So kann sich ein Agent für spätere Läufe keine Rechte ins Repo schreiben.
• Projektkontext mit Vorprüfung: Bringt .claude/ eines Repos Prozess-Env, Helper-Befehle, zusätzliche Verzeichnisse, bypassPermissions oder MCP-Freischaltungen mit, läuft der Lauf ohne Projektkontext und sagt, warum.
• Aider liest keine Repo-Konfiguration mehr: Liegen .env oder .aider.*-Dateien im Repo, startet Aider nicht, statt darüber Befehle auszuführen.
• Login-Seite repariert: Skripte und Favicon laden wieder.
• Testpaket mit HTML-Anleitungen für Installation und den ersten Test mit eigenem Projekt; Claude Fable 5.2 in der Modelltabelle.

Der Security-Review hat weitere Punkte für fremde Repositorys gefunden; sie folgen mit 0.42.4 (Details im CHANGELOG).

MonoGame-Vorlage, Container ohne root, CSP-Fixes

Ein Patch-Release für .NET-Spiele und drei Fehler, die man im Alltag merkt.

• MonoGame im Wizard: neue Vorlage für Spiele (DesktopGL, WindowsDX, Android, iOS) aus den offiziellen MonoGame-Vorlagen, ohne Backend oder mit .NET-Backend; getrennte, testbare Spiellogik und Content-Pipeline.
• Container als dein Nutzer: Build- und Scan-Container laufen als Besitzer des Workspaces statt als root; bin/, obj/ und target/ gehören danach dir. Root-eigener Altbestand wird einmalig korrigiert.
• Blockierte Skripte repariert: Die Browser-Benachrichtigung der Laufseite, die Rückfrage vor dem Löschen eines Schlüssels und das sofortige Speichern von Rolle und Mandant scheiterten an der Content-Security-Policy. Ein Test verhindert neue Inline-Skripte.
• Kleinigkeiten: Der Erstimport meldet nicht mehr „Workspace wiederverwendet“; der Wizard rät von .NET 8 und 9 für neue Projekte ab (Support-Ende 10.11.2026).

Besserer .NET-Support und Testversion mit Ablaufdatum

Bestehende C#- und MonoGame-Projekte laufen jetzt mit weniger Handarbeit durch die Fabrik.

• Passendes SDK in der Sandbox: Die Fabrik liest die .NET-Version aus global.json bzw. dem höchsten TargetFramework und baut im passenden Image (z. B. net9.0 → sdk:9.0). Bisher lief jedes Projekt fest mit .NET 8.
• Agent darf dotnet aufrufen: Er baut und testet C#-Projekte während der Arbeit selbst, statt Fehler erst über Build-Gate und Korrekturschleife zu erfahren.
• Wizard: Die .NET-Vorlagen schlagen .NET 10 (LTS) vor, 9 und 8 bleiben wählbar; der Hilfetext nennt das Support-Ende (8 und 9 enden am 10.11.2026).
• Testversion: Ein Build ohne Lizenzdatei mit festem Ablaufdatum, die Fußzeile zeigt, bis wann er gilt.

Tester-Paket: Lizenzdatei, Kostentransparenz, .NET

Alles, damit jemand die Fabrik auf dem eigenen Rechner mit einem bestehenden Repo und einem eigenen API-Key testen kann.

• Lizenz als Datei: Der Lizenz-Admin stellt eine Aktivierungsdatei aus, die Fabrik bindet sie beim Import an den Rechner (ein Gerät je Lizenz, optional mit Euro-Limit pro Monat). Die ausgelieferte JAR hat Lizenzpflicht, die sich nicht per Einstellung abschalten lässt; für Air-Gap gibt es Standalone-Zertifikate.
• Kosten vollständig und sichtbar: KI-Zusammenführung und Reviews zählen jetzt mit. Die Laufseite zeigt die Kosten live, Laufliste und Projektseite den Monatsstand mit Budgetbalken. Vor jedem Start steht eine Schätzung; der USD→EUR-Faktor ist eine Einstellung.
• .NET in der Sandbox: C#-Projekte bauen auch in der Container-Sandbox, mit Abdeckung über coverlet; je Projekt lässt sich ein eigener Build-Befehl setzen.
• Ergebnis übernehmen: Die Projektseite zeigt die Git-Befehle, mit denen du den Branch eines Laufs in dein Original-Repo holst. Der Import meldet große Repos und fehlendes git-lfs.
• Startpaket: Start-Skripte prüfen Java 25, Docker, git und die CLI; eine Kurzanleitung führt in zehn Schritten durch den Test mit dem eigenen Repo.

Build-Gate für .NET

Die Validierung baute bisher nur Maven-Projekte; C#-Repos liefen ohne Build-Prüfung durch.

• .NET erkannt: Solution (.sln/.slnx) oder einzelne Projektdatei im Build-Verzeichnis. Das Gate führt dotnet tool restore, dotnet build und bei Testprojekten dotnet test aus; Build-Fehler speisen die Korrekturschleife.
• MonoGame: mit einem echten DesktopGL-Projekt samt Content-Builder mgcb geprüft. WindowsDX-Projekte brauchen Windows.
• Ehrlich statt geraten: Mehrere Solutions oder die aktive Container-Sandbox (noch ohne .NET-Image) melden eine Warnung, statt still zu bestehen.

Bestehende Claude-Code-Projekte übernehmen

Wer schon mit Claude Code arbeitet, kann sein Repo jetzt mit allem, was es mitbringt, in der Fabrik weiterentwickeln.

• Claude-Code-Projektkontext je Projekt: Eingeschaltet gelten in Fabrik-Läufen CLAUDE.md, Subagents, Skills, Commands und .claude/settings.json des Repos. Hooks und .mcp.json bleiben aus; empirisch mit Claude Code 2.1.310 geprüft. Standard: aus, nur für eigene, vertrauenswürdige Repos.
• Nichts mehr überschrieben: Eine eigene CLAUDE.md ersetzt die Fabrik nicht mehr, und ihre eigenen Subagents und Skills überschreiben gleichnamige Dateien des Projekts nicht. Sie landen auch nicht mehr in Commits und Pull-Requests.
• Sonstiges: Session-Cookie mit SameSite=Lax und optionalem Secure-Flag, DB-Passwort mindestens 16 Zeichen, Start-Skripte prüfen nur die CLI des gewählten Adapters.

Die Schritt-für-Schritt-Anleitung steht im Benutzerhandbuch.

Patch: Quality Gate ohne Review-CLIs

Ein Fehler-Patch ohne Migration. War aider oder claude nicht installiert, meldete die Fabrik das als Timeout, und das Quality Gate endete mit ERROR statt die beiden Reviewer zu überspringen. Jetzt gelten sie als SKIPPED; ein Mock-Lauf über Docker Compose endet mit Quality Gate PASSED.

Patch: Freigaben, Git-Autor, Compose

Ein Fehler-Patch ohne Migration.

• Freigegebene Runs laufen weiter. Seit 0.30.0 blieb ein Run nach „Freigeben und fortsetzen“ in WAITING_FOR_APPROVAL stehen, obwohl die Freigabe im Audit stand: Der Statuswechsel wurde nicht gespeichert. Ein neuer Test prüft jetzt genau den Weg, den die Oberfläche nimmt.
• Git-Autor: Name und E-Mail aus den Einstellungen gelten jetzt für alle Commits der Fabrik.
• Default-Modell für Kimi und Aider lässt sich in den Einstellungen setzen; wirkungslose Felder (Token-Caps, Codex-/Gemini-Modell) sind entfernt.
• Docker Compose: Das App-Image bringt git und wget mit. Ein Mock-Lauf läuft damit bis zum Abschluss, und der Healthcheck meldet „healthy“. Für echte Agentenläufe bleibt der native Einzelplatz-Start der offizielle Weg.
• Lizenzmodell beschreibt nur noch, was technisch gilt: Mandanten, Rollen, SSO und Audit-Kette sind in allen Stufen enthalten.

Patch: Gespeicherte Keys für alle Agenten-CLIs

Ein Fehler-Patch ohne Migration, Fortsetzung von 0.41.1: Auch Codex, Gemini, Kimi und Aider lasen ihren Key bisher nur aus der Umgebung des Fabrik-Prozesses. Im Auth-Modus api-key setzen sie jetzt den unter Integrationen gespeicherten Key ein, wenn die Umgebung keinen trägt — Codex OPENAI_API_KEY, Gemini GEMINI_API_KEY, Kimi KIMI_API_KEY, Aider je nach Modell einen der drei großen Anbieter. Die Umgebung hat Vorrang, im Abo-Modus werden Keys weiter entfernt.

Patch: Anthropic-Key aus der UI erreicht die Claude-CLI

Ein Fehler-Patch ohne Migration.

• Anthropic-Key aus den Integrationen: Claude Code las den Key bisher nur aus der Umgebung des Fabrik-Prozesses; ein unter Integrationen gespeicherter Key diente nur dem Schlüsseltest und der KI-Zusammenführung. Im Auth-Modus api-key setzt die Fabrik ihn jetzt für Runs und Reviews ein, wenn die Umgebung keinen ANTHROPIC_API_KEY trägt. Die Umgebung hat weiter Vorrang, im Abo-Modus wird der Key wie bisher entfernt.
• Lizenz-Statusseite: Die Knöpfe zu Lizenzmodell und Enterprise führten ins Leere (404).

Artefakt-Evolution: Steuerdateien weiterentwickeln, ohne Ergänzungen zu verlieren

Bisher schrieb jeder Run die sechs Steuerartefakte (PROJECT.md, INSTRUCTIONS.md, AGENTS.md, WORKFLOW.md, DEFINITION_OF_DONE.md, README.md) aus der Projektdefinition neu — eine Regel, die du oder ein Agent direkt in AGENTS.md ergänzt hatte, war danach weg. 0.41.0 versioniert diese Dateien und führt Änderungen kontrolliert zusammen (ADR-0028).

Drift-Schutz und Artefakt-Evolution

• Drift-Schutz: Eine im Workspace geänderte Steuerdatei überschreibt die Fabrik nicht mehr. Sie sichert sie als unveränderlichen Snapshot, und der Agent arbeitet mit der geänderten Fassung. Unter Projekt → Artefakte stehen alle Versionen mit Herkunft und SHA-256; jede lässt sich wiederherstellen.
• Drei-Wege-Vergleich je Abschnitt: Artefakt-Evolution vergleicht die zuletzt geschriebene, die Workspace- und die neu generierte Fassung. Was nur du geändert hast, bleibt; was nur das Template geändert hat, kommt; was beide unterschiedlich geändert haben, ist ein Konflikt.
• Vorschau und Freigabe: Die Vorschau zeigt Diff, Konflikte und Widersprüche zwischen den Dateien. Die Freigabe (MAINTAINER oder höher) übernimmt alle Dateien als Satz — transaktional: Hash-Prüfung gegen zwischenzeitliche Änderungen, atomares Schreiben, Commit nur dieser Dateien, Rückkehr zum vorherigen Stand bei einem Fehler. Hängende Übernahmen räumt die Recovery beim Start auf. Kritische Konflikte blockieren die Freigabe.
• Modi: off (Standard, bisheriges Verhalten), protect (nur Drift-Schutz), approval (der Run legt bei Drift ein Update zur Freigabe an) und auto-safe (eindeutige Updates ohne Konflikt übernimmt der Run direkt).
• KI-Zusammenführung nur als geprüfter Vorschlag: Auf Wunsch schlägt ein Modell (Standard Claude Opus 5.5) eine Zusammenführung der Konflikte vor — direkt über die Anthropic-API, wenn ein API-Key hinterlegt ist (offizielles Java-SDK), sonst über die Claude-CLI mit Abo. Ein deterministischer Validator verwirft Vorschläge, die fremde Abschnitte berühren, Secrets, Hooks, MCP-Server oder Rechte einführen oder Sicherheitsregeln streichen. Die KI schreibt nie selbst.

Self-Development und Monorepos

• Bestehende Repos übernehmen: Folgt eine Datei nicht der Fabrik-Struktur, schlägt die Analyse vor, die Workspace-Fassung als Ausgangsfassung zu übernehmen. Danach kommen nur echte Template-Änderungen an. So kann die Fabrik auch ihr eigenes Repository als Zielprojekt bearbeiten.
• Build-Verzeichnis je Projekt: Liegt die pom.xml nicht im Root (z. B. unter app/), ruft das Build-Gate mvn -B -f app/pom.xml verify auf. Ohne Build-Verzeichnis warnt ein übersprungener Build jetzt, wenn Poms in Unterverzeichnissen liegen.
• Gemini-Abo-Modus: Der Gemini-Adapter läuft wie Codex und Kimi auch mit dem Abo-Login („Login with Google“, SOFTWAREFABRIK_GEMINI_AUTH_MODE=subscription).

Sicherheit und Fehlerbehebungen

• Build-Gate ohne Geheimnisse der Fabrik. Im lokalen Sandbox-Modus erbte mvn verify — also vom Agenten geschriebener Code samt Tests — die ganze Umgebung der Fabrik. Jetzt entfernt die Fabrik SOFTWAREFABRIK_*, SPRING_DATASOURCE_* und Variablen mit Passwort, Secret, Token, API-Key oder Credential im Namen. Ein Workspace, der das Arbeitsverzeichnis der laufenden Fabrik enthält, wird nicht gebaut.
• Agenten lesen AGENTS.md zuverlässig. Die CLAUDE.md der Fabrik importiert die Datei jetzt per @AGENTS.md, und der Run-Auftrag aller neun Adapter nennt PROJECT.md, INSTRUCTIONS.md, AGENTS.md und MEMORY.md ausdrücklich. Bisher lud Claude Code die nur erwähnte Datei nicht.
• Workspace bekam die älteste Artefaktversion. Wurde ein Projekt mehrfach generiert oder in der UI bearbeitet, standen AGENTS.md, WORKFLOW.md, DEFINITION_OF_DONE.md und README.md im Workspace auf Version 1. Behoben.

Migrationen V67–V69.

Upgrade-Hinweis: Die Artefakt-Evolution ist standardmäßig aus (artifact-evolution.mode=off); du aktivierst sie unter Einstellungen → Steuerartefakte, global oder pro Projekt. Für Monorepos trägst du auf der Projektseite das Build-Verzeichnis ein.

Patch: Repo-Import nur aus freigegebenen Verzeichnissen

Ein Sicherheits-Patch ohne neue Funktionen und ohne Migration. Beim Import eines bestehenden Repositorys aus einem lokalen Pfad kopiert die Fabrik das Verzeichnis in den Workspace, wo der Agent es liest. Zwei Lücken sind geschlossen:

• Symlinks der Quelle werden nicht mehr mitkopiert. Bisher holte ein Link im Repository den Inhalt einer fremden Datei in den Workspace. Übersprungene Einträge nennt das Lauf-Protokoll.
• Lokale Quellen nur aus freigegebenen Verzeichnissen. Bisher konnte jeder, der ein Import-Projekt anlegt, ein beliebiges Verzeichnis des Servers übernehmen lassen. Neu legt der Betreiber die erlaubten Verzeichnisse fest (SOFTWAREFABRIK_IMPORT_ALLOWED_ROOTS); ohne Eintrag ist der lokale Import aus. Git-URLs sind nicht betroffen.

Upgrade-Hinweis: Wer lokale Pfade importiert, trägt das Verzeichnis vor dem Update ein.

GitHub Spec Kit trifft auf die Governance der Fabrik

Viele Teams schreiben ihre Anforderungen inzwischen mit GitHub Spec Kit. 0.40.0 macht diese Specs in der Fabrik nutzbar, ohne dass jemand sie umschreiben muss — und erlaubt Projekte, die vollständig im Spec-Kit-Layout arbeiten. Freigabe durch Menschen, Bindung an freigegebene Fassungen und Audit-Kette bleiben dabei unverändert.

Spec-Kit-Brücke: Import und Export

• Die Spec-Übersicht erkennt Spec-Kit-Specs im Workspace (specs/<NNN>-<slug>/spec.md, Vorlage v1.2.2). Eine Vorschau zeigt vor dem Import, welche Spec-Kit-ID welche AC-ID bekommt.
• Der Import legt immer einen Entwurf an, nie eine Freigabe. Die Spec-Kit-ID bleibt als Alias am Kriterium ([FR-003]), Herkunft und Prüfsumme stehen in der Audit-Kette.
• Jede Fassung lässt sich im Spec-Kit-Format exportieren; Export und erneuter Import behalten AC-IDs und Kriterientexte.
• Der Reviewer spec-conformance wertet einen Test, der FR-003 nennt, wie einen Verweis auf die AC-ID.

Projekte im Spec-Kit-Layout

• Jedes Projekt hat ein Spec-Format: FABRIK (Standard) oder SPEC_KIT. Der Assistent schlägt SPEC_KIT vor, wenn ein importiertes Repository schon Spec-Kit-Dateien enthält.
• Im Spec-Kit-Layout schreibt jeder Lauf die Spec-Kit-Vorlagen, erzeugt die Constitution aus den Engineering Guardrails und legt jede Spec als specs/<NNN>-<slug>/spec.md ab. Änderungen daran übernimmt die Fabrik als neuen Entwurf.
• Spec- und Plan-Runs arbeiten nach den Spec-Kit-Vorlagen; Rückfragen als [NEEDS CLARIFICATION] werden offene Fragen in der Spec-Oberfläche.
• Spec Kit selbst wird weder installiert noch ausgeführt. Skripte, Erweiterungen und .claude/commands/ im Workspace blockieren unter dem MCP-Standardverbot das Quality Gate.

Sicherheit: keine Symlinks im Workspace

Ein Security-Review fand, dass ein Agent einen Pfad im Workspace durch einen symbolischen Link nach außen ersetzen konnte, den der nächste Lauf dann beschrieben hätte. Die Fabrik liest und schreibt im Workspace jetzt an keiner Stelle mehr durch einen Symlink — das gilt für alle Dateien, die sie anlegt, auch AGENTS.md, CLAUDE.md und die Skill-Dateien. Ein Treffer bricht den Lauf mit Grund ab und steht in der Audit-Kette.

Migration V66 (eine Spalte). Alle Spec-Funktionen bleiben an die SDD-Freischaltung gebunden.