Häufige Fragen.

Was ist die Agentic Software Factory?

Eine lokale Webanwendung, mit der du AI-gestützte Softwareentwicklung strukturiert anstößt, überwachst und nachvollziehst. Sie verbindet Projekt-Erfassung (mit oder ohne Wizard), automatische Erzeugung von Markdown-Spezifikationen, Lauf-Orchestrierung gegen Coding-CLIs (Claude Code, Codex, Gemini, Kimi, Aider), Live-Logs, Git-Disziplin und ein automatisches Quality Gate. Das Ziel ist nicht „magic AI-coding mit einem Klick“, sondern reproduzierbare, geprüfte Resultate, die du an dein Team weiterreichen kannst.

Für wen ist die Plattform gedacht?

Primär für Softwarearchitekten, Lead Developer, technische Projektleiter und kleine Teams, die AI-gestützte Entwicklung kontrollierter und reproduzierbarer durchführen wollen — typischerweise im Mittelstand, in regulierten Umfeldern oder bei Beratungen, die Code-Resultate auch dokumentieren müssen. Sie ist nicht als Massen-Consumer-Produkt gedacht und richtet sich nicht an Hobbyisten, die schnell mal ein Skript generieren wollen — dafür ist Claude Code direkt schneller.

Was ist der Hauptunterschied zu Claude Code direkt in der Shell?

Bei direkter Shell-Nutzung musst du Projekt-Definition, Leitplanken, Freigaben, Git-Disziplin und Statusüberwachung manuell organisieren. Die Software Factory macht genau diese Aspekte sichtbar und wiederverwendbar — du startest nicht einen Coding-Lauf, du orchestrierst eine Sequenz aus Plan, Implement, Review und Validate, kriegst Live-Logs und am Ende ein Quality-Gate-Verdict. Das ist nicht ein anderer Coding-Modus, das ist ein anderer Abstraktionsgrad.

Wie starte ich am besten?

Ohne Installation: die Demo mit geführter Tour. Selbst installiert: das Einzelplatz-Startpaket anfragen, dann der Schnellstart (10 Minuten, Mock-Adapter, ohne KI-Kosten). Danach echte Läufe einrichten und das Tutorial mit Claude Code durchspielen.

Wie installiere ich die Plattform lokal?

Mit dem Einzelplatz-Startpaket. Es gibt es auf Anfrage (Kontakt). Danach forderst du die Community-Lizenz direkt in der Fabrik an — oder importierst eine Professional- oder Enterprise-Lizenzdatei. Die Fabrik läuft nativ auf deinem Rechner, nur die Datenbank im Container. Klick für Klick im Schnellstart; Self-Hosted und Air-Gap gibt es über Enterprise.

Welche Voraussetzungen brauche ich?

• Java 25 und git.
• Docker (Desktop oder Engine) für die Datenbank.
• Freie Ports 8080 (Fabrik) und 5432 (Postgres, nur lokal gebunden).
• Für echte Läufe die CLI deines KI-Agenten (z. B. Claude Code) mit Abo oder API-Schlüssel — für den Mock-Adapter nicht.

Das Startpaket enthält install-softwarefabrik.sh (WSL/Linux/macOS) und install-voraussetzungen.ps1 (Windows); sie prüfen Java 25, git, git-lfs, Docker und die Claude Code CLI und installieren Fehlendes nach Rückfrage. Toolchains für deine Projekte (JDK, Maven, .NET SDK, Node.js, Go, uv) installiert die Fabrik seit v0.45.0 selbst unter Einrichtung → Werkzeuge.

Brauche ich API-Keys?

Für die Demo lokal reicht der Mock-Adapter — keine Keys. Für echte Vendor-Aufrufe brauchst du einen API-Key oder ein Abo-Login der Agenten-CLI. Am einfachsten trägst du den Key in der Ersteinrichtung ein (Einrichtung → KI-Zugang); die Fabrik prüft ihn sofort. Anthropic-, OpenAI-, Gemini-Keys werden — dort oder im /integrations-View — verschlüsselt persistiert (AES-GCM, Master-Key aus SOFTWAREFABRIK_SECRETS_MASTER_KEY).

Was ist der Mock-Adapter und wann nutze ich ihn?

Der Mock-Adapter ist ein Test-Adapter, der ohne API-Key funktioniert und deterministische Pseudo-Tokens in den Workspace schreibt. Ideal für:

• Erste Plattform-Tests: Schnellstart, Onboarding ohne Vendor-Kosten.
• CI-Pipelines: wenn die Plattform-Mechanik getestet werden soll, nicht das LLM.
• Reproduktion von Bugs: wenn ein Lauf komische Logs zeigt, kann man ihn mit Mock nachstellen, ohne erneut Tokens zu verbrennen.

Output ist nicht „echter Code“ — eher Pseudo-Inhalte, die einen typischen Lauf-Verlauf simulieren.

Was kostet die Plattform?

Community ist kostenfrei. Professional kostet 20–30 €/Monat pro Nutzer, Enterprise startet bei 20.000 €/Jahr (Self-Hosted und Air-Gap als individuelle Verträge). Was zusätzlich kostet, sind die Vendor-API-Kosten (Anthropic, OpenAI, Google) für die echten Coding-Calls — die Plattform ist hier nur Vermittler.

Was sind die Limits der Community-Version?

Die Grenzen der Community-Lizenz — Läufe pro Tag, Agenten, Rechner je E-Mail-Adresse, Laufzeit — stehen gesammelt auf der Seite Preise, dort auch, wie gezählt wird. Kein Support-SLA und kein Spec-Driven Development; Mandanten, Rollen, SSO und Audit-Kette sind enthalten.

Welche Daten werden an externe Server übertragen?

Im Default-Setup nur:

• An den Lizenzserver: Lizenz-ID (UUID), Gerätefingerprint-Hash (SHA-256), E-Mail-Hash, Client-Version, ISO-Land der IP.
• An den Versions-Lookup (Maven Central, GitHub, npm): nur das HTTP-GET ohne Auth.
• Nur wenn ein ADMIN unter Einrichtung → Werkzeuge eine Toolchain installiert: Downloads ohne Auth von den Herstellerquellen (Adoptium, Apache, Microsoft, nodejs.org, go.dev, GitHub für uv). Abschaltbar mit softwarefabrik.werkzeuge.installation-erlaubt=false.
• An den konfigurierten LLM-Vendor: dein Prompt + Workspace-Inhalte. Das hängt vom Vendor ab.

Im Air-Gap-Modus: nichts. Details im Transparenz-Dokument.

Was hat sich seit den Anfängen getan?

Kurz: Aus dem MVP mit zwei Wizard-Templates ist ein Werkzeug für den ganzen Entwicklungszyklus geworden — iterative Weiterentwicklung mit Branch/PR, Quality Gate, Mandanten und Rollen, attestierte Audit-Kette, Spec-Driven Development und ein Build-Gate für viele Stacks. Alle Releases mit ausführlichen Notes stehen auf der News-Seite.

Welche Probleme löst die Plattform konkret?

• Zu wenige oder unstrukturierte Commits beim AI-Coding.
• Fehlende Transparenz über Logs, Status und Freigaben.
• Inkonsistente Projekt-Definitionen über Teams hinweg.
• Schwierige Wiederverwendung guter Projekt-Setups (jedes Mal von vorne).
• Hoher manueller Aufwand bei der Steuerung mehrerer Coding-CLIs.
• Fehlende automatisierte Qualitätsbewertung der AI-Resultate.

Welche Agentenrollen sind vorgesehen?

Sieben Rollen: Architect, Developer, Reviewer, QA, Security Reviewer, Documentation und Merge/Release. Pro Rolle kann ein preferredModel gesetzt werden — ein Architect bekommt z.B. claude-opus-5-5 für tiefe Designentscheidungen, ein Developer das schnellere claude-sonnet-5-5. Die Rollen werden in AGENTS.md als Markdown serialisiert und vom Coding-Agent als Kontext gelesen.

Wie läuft ein typischer Arbeitsablauf ab?

1. Einmalig als Administrator: „Ersteinrichtung starten“ auf dem Dashboard — KI-Agent und Abo oder API-Schlüssel wählen, offene Punkte der Systemprüfung beheben, loslegen.
2. Projekt beschreiben: „Neues Projekt“ → Schnellstart (Name, Art, Beschreibung) und „Bauen“ — das legt das Projekt an und startet den ersten Lauf. Für ein bestehendes Projekt: „Bestehendes Projekt weiterentwickeln“ mit Ordner oder Git-Adresse und Auftrag, dann „Importieren und bauen“.
3. Auf der Laufseite (aktualisiert sich selbst) Fortschritt verfolgen, bei Wartet auf deine Freigabe die Änderungen ansehen und „Freigeben und fortsetzen“ klicken; der Kasten „Was jetzt?“ nennt den nächsten Schritt.
4. Nach Abgeschlossen (COMPLETED) die Karte „Ergebnis“ ansehen: Startbefehl unter „Selbst ausprobieren“, ZIP-Download; in „Experte“ ggf. „Quality-Gate ausführen“ und Findings prüfen.
5. Weiter mit „Weiter verbessern“ bzw. „Nächster Auftrag“ auf der Projektseite oder „Vorschläge machen lassen“ (Plan-Lauf ins Backlog). Ist ein Lauf gescheitert: „Erneut versuchen“ mit „Was soll anders sein?“.

Warum wird mit Markdown-Artefakten gearbeitet?

Dateien wie PROJECT.md oder INSTRUCTIONS.md sind menschenlesbar, versionierbar und für AI-Tools gut nutzbar. Sie bilden den „Arbeitsvertrag“ zwischen Nutzer, Plattform und Agent. Der Agent liest sie als Top-Level-Brief, du kannst sie editieren und im Git-Verlauf nachvollziehen. Im Gegensatz zu binären Konfigurationen oder DB-Spalten ist Markdown auch ohne unsere Plattform sinnvoll lesbar — du verlässt also nie ein proprietäres Format.

Ist die Plattform schon ein echtes Multi-Agent-System?

Nicht im Sinne von „mehrere Agenten mit gegenseitiger Kommunikation“. Ein Lauf hat genau einen ausführenden Adapter; das Modell wird je Rolle gewählt (Plan → Architect, Build → Developer), und das Quality Gate prüft mit eigenen Reviewern. Seit v0.21 gibt es darüber eine Workflow-Ebene: Ein Vorhaben zerfällt in Tasks, die als Teil-Läufe parallel laufen — höchstens drei gleichzeitig je Workflow, jeder in einem eigenen git-Worktree, standardmäßig per Feature-Flag abgeschaltet. Details unter Bekannte Grenzen.

Wie starte ich die Plattform?

Im entpackten Startpaket:

cp .env.example .env     # Admin-Passwort setzen
./start.sh               # Windows: .\start.ps1

Das Skript prüft die Voraussetzungen, startet Postgres im Container und dann die Fabrik; danach http://localhost:8080 öffnen. Details im Schnellstart.

Welche Java-Version brauche ich?

Java 25 (LTS). Spring Boot 4.1.1. Wenn du das JAR direkt startest, brauchst du ein passendes JDK.

Was ist mit Postgres?

PostgreSQL 18 als Single-Tenant-DB (im docker-compose.yml auf postgres:18.6-alpine gepinnt). Schema-Migrationen über Flyway, aktuell bis V82. Im Test-Profil läuft H2 mit Postgres-Kompatibilitätsmodus.

Wie funktioniert die Plattform offline?

Die Fabrik prüft ihre Lizenz offline; den Lizenzserver braucht sie nur zum Erneuern des Leases. Ist er nicht erreichbar, gilt das vorhandene Lease weiter, danach eine Grace-Period und auf Wunsch eine kurze Notfall-Grace; ist auch sie abgelaufen, startet kein neuer Lauf mit einem echten KI-Agenten mehr; Läufe mit dem Mock bleiben möglich (Zusammenführen und Pull-Requests gibt es aber nur mit gültiger Lizenz). Wie lange das jeweils ist, hängt von Stufe und Auslieferungsform ab — die Werte stehen unter Preise. Enterprise Air-Gap kommt ganz ohne Netzwerk aus: Erneuerung einmal jährlich über eine signierte Zertifikatsdatei (USB-Stick oder kontrollierter Datei-Transfer).

Air-Gap-Betrieb möglich?

Ja, mit einer Enterprise-Air-Gap-Lizenz. Die Plattform selbst hat keine zwingende Internet-Abhängigkeit. Was du brauchst:

• Vollständig offline verifizierbares Lizenz-Zertifikat (Ed25519-signiert, jährlich erneuert).
• Jährliche Erneuerung per USB-Stick oder Datei-Transfer.
• LLM muss on-prem betrieben werden (z.B. Ollama mit Qwen 3 Coder, DeepSeek V3.2). Vendor-Cloud-Adapter sind im Air-Gap nicht möglich.
• Versions-Cache muss im Internet-Mode gefüttert werden — alternativ Fallback-Versionen aus dem Code.
• Werkzeug-Installation abschalten (softwarefabrik.werkzeuge.installation-erlaubt=false) und Toolchains vorab bereitstellen — die Fabrik lädt sie sonst aus dem Internet.

Wie viele Templates gibt es?

19 — fünf Backends (spring-boot-backend, quarkus-backend, dotnet-backend, python-fastapi, node-express), 13 Frontends (static-frontend, frontend-react, frontend-angular, frontend-vue, frontend-thymeleaf, frontend-vaadin, frontend-blazor, frontend-flutter, frontend-react-native, frontend-maui, frontend-wpf, frontend-monogame, frontend-javafx) und existing-repo-import für bestehende Repositories.

Welche Templates gibt es im Detail?

Snippets und Basis-Prompts liegen auf dem Classpath unter resources/wizard/snippets/<lang>/ bzw. resources/wizard/prompts/<lang>/ und sind in DE und EN verfügbar (Sprache wählst du im Wizard-Schritt 4).

Was passiert im letzten Schritt des Wizards?

Zusammenfassung mit Objective-Vorschau (collapsible, zeigt den finalen Initial-Prompt für den Agent) und Kosten-Schätzung (lokal via JTokkit, ohne LLM-Call, Default-Modell claude-sonnet-5-5).

Wie lege ich ein Projekt ohne Wizard an?

„Neues Projekt“ auf Dashboard und Projektliste öffnet den Schnellstart: drei Angaben (Name, Art, Beschreibung) statt sechs Schritte, dann „Bauen“. In der Darstellung „Experte“ legt „Nur Projekt anlegen“ das Projekt an, ohne einen Lauf zu starten. Willst du alles selbst füllen, nimm in der Projektliste „Leeres Projekt (Experten)“ (bis 0.46 „Schnell anlegen“): ein zweifeldiges Formular (Projekttitel, Produktname), danach landest du direkt im Editor. Der „Ausführliche Assistent“ steht daneben, wenn du Stack und Prüfwerkzeuge Schritt für Schritt festlegen willst.

Abschalten musst du nichts; einen Schalter, der den Assistenten aus der Oberfläche entfernt, gibt es nicht. Der Schalter „Einfach | Experte“ in der Kopfzeile (ab 0.47) regelt nur, wie viele Optionen die Oberfläche zeigt; was du darfst, bestimmt allein deine Rolle.

Welche Adapter gibt es?

Welche Default-Modelle nutzt die Plattform pro Rolle?

Pro Agentenrolle ist ein Default-Modell hinterlegt (ModelCatalog):

• Architect & Documentation: claude-opus-5-5 — für tiefe Design- und Doku-Entscheidungen.
• Developer, QA & Merge/Release: claude-sonnet-5-5 — ausgewogen für Implementierung.
• Reviewer & Security Reviewer: claude-haiku-5-5 — schnell und günstig für read-only-Prüfungen.

Automatisch genutzt werden davon nur die Defaults von Architect (Plan- und Spec-Läufe) und Developer (Build-Läufe), und nur beim Claude-Adapter; die übrigen sind Vorschläge für das Wunschmodell einer Rolle. Vorrang haben ein Routing-Override in den Einstellungen (run.routing.plan-model, run.routing.build-model, run.routing.spec-model) und das Wunschmodell des Teams. Aider und Kimi nehmen ihr Default-Modell aus der Konfiguration (softwarefabrik.execution.aider.model bzw. …kimi.model); Codex und Gemini überlassen die Wahl derzeit ihrer CLI.

Wie funktioniert das Modell-Routing pro Rolle?

Jede AgentDefinition hat ein nullable preferredModel-Feld (V14). Der Claude-Code-Adapter hängt es als --model-Flag an die CLI-Aufrufzeile. Bei IDs, die nicht in der Preistabelle stehen, fällt er auf den CLI-Default zurück und schreibt einen Hinweis ins Lauf-Log. Welches Modell aus welcher Quelle kam, hält die Attestierung RUN_MODELL_AUFGELOEST fest.

Kann ich pro Lauf einen anderen Adapter wählen?

Ja. Im Formular „Neuer Lauf“ gibt es in der Darstellung „Experte“ die Auswahl „KI-Werkzeug (Adapter)“; in „Einfach“ nimmt die Fabrik den eingestellten Adapter. Wenn du dort etwas wählst, wird der globale Default überschrieben (Override-Reihenfolge: RUN > PROJECT > USER > GLOBAL > YAML). Praktisch z.B. für A/B-Vergleiche: gleicher Auftrag, einmal mit Claude, einmal mit Codex, dann die Ergebnisse vergleichen.

Was macht das Quality Gate?

Das Quality Gate ist eine automatische Bewertung des Lauf-Outputs. Es ruft mehrere Reviewer auf, sammelt ihre Findings und liefert ein aggregiertes Verdict (PASSED / WARNING / FAILED / SKIPPED / ERROR). Reviewer sind read-only — sie schreiben nichts in den Workspace, sie prüfen nur.

Welche Stacks baut und testet das Build-Gate?

Das Build-Gate läuft vor dem Quality Gate und baut nach dem erkannten Projektprofil. Stufe A (geprüft): Maven und .NET. Stufe B (nutzbar): Gradle, Python (pip, uv, Poetry), Node.js (npm, pnpm, Yarn), Go, Rust und CMake. Für andere Builds trägst du auf der Projektseite einen Build-Befehl ein.

Fehlt ein Werkzeug oder hat kein Bau- oder Testschritt etwas geprüft, heißt das Ergebnis „nicht geprüft“ statt rot — und nie bestanden: Der Lauf braucht dann vor dem Merge eine Freigabe. Unter Build-Container setzt du je Projekt Image, CPUs, Speicher und Zeitlimit; fehlende Toolchains installiert ein ADMIN unter Einrichtung → Werkzeuge. Details im Benutzerhandbuch, Abschnitt 5.5.

Welche Reviewer sind eingebaut?

• aider-review — ruft die Aider-CLI im read-only-Modus auf, sucht nach Code-Smells und Verbesserungsvorschlägen.
• claude-review — ruft Claude Code im read-only-Modus auf und lässt das Modell den eigenen Output kritisch prüfen.
• security-reviewer — statische Heuristik-Engine: scannt nach Hardcoded-Passwörtern, schwacher Krypto, SQL-Injection-Patterns, fehlenden Input-Validierungen, …
• architecture-reviewer — statische Pfad-Heuristik: Schichtverstöße in Java/Kotlin-Paketen (z.B. JPA in der Domäne), Änderungen an bestehenden Flyway-Migrationen und eingecheckte .env-Dateien. Ohne Java/Kotlin im Diff sagt er, dass seine Schichtregeln nicht greifen.
• hallucination-reviewer — sucht erfundene Methoden-Aufrufe, nicht-existierende Pakete oder ausgedachte API-Signaturen — und prüft Behauptungen über den Code (z.B. „alle Tests laufen durch“ ohne Test-Änderung). Neue Importe gleicht er mit dem Manifest ab (package.json, requirements.txt/pyproject.toml, *.csproj, go.mod, Cargo.toml); fehlt ein Paket dort, meldet er einen Hinweis.
• dependency-scan — Trivy-basierter Abhängigkeits- und Lizenz-Scan. CVE-Findings der Kategorie SECURITY blockieren den Merge.
• spec-conformance — nur bei Läufen mit Spec: prüft regelbasiert, ob jedes gebundene Akzeptanzkriterium in einem Test referenziert ist (Heuristik, siehe Known Limitations).

Was bedeuten die Verdicts?

• PASSED — keine Findings, alle Reviewer grün.
• WARNING — einzelne Findings unterhalb der Blockierungs-Schwelle.
• FAILED — mindestens ein blockierendes Finding (durch Policy oder Sonderregel).
• SKIPPED — alle Reviewer wurden übersprungen (z.B. weil keine Reviewer-CLI installiert ist oder es nichts zu prüfen gab).
• ERROR — ein Reviewer ist mit Fehler abgebrochen (z.B. Timeout) oder unter strict fehlt ein Pflicht-Review. Eine nicht installierte Reviewer-CLI zählt als übersprungen, nicht als Fehler. Bewusst nicht verschluckt.

Jeder Reviewer liefert Findings mit Kategorie und Severity (LOW/MEDIUM/HIGH/CRITICAL) sowie einen Confidence-Score (0..1) für sein Gesamtergebnis; daraus wird das Verdict aggregiert.

Was sind die Sonderregeln?

Zwei Finding-Typen sind immer blockierend, unabhängig von der Policy-Einstellung:

• SECURITY/HIGH — z.B. Hardcoded-Secrets in commitetem Code, schwache Krypto-Algorithmen, offensichtliche SQL-Injection.
• ARCHITECTURE/CRITICAL — z.B. Domain-Klasse importiert Spring, Web-Schicht greift direkt auf Infrastructure zu.

Diese Sonderregel verhindert, dass eine zu lockere Policy versehentlich kritische Probleme durchwinkt.

Was ist der Unterschied zwischen strict und lenient Policy?

• lenient (Default): nur CRITICAL-Findings blockieren, keine Pflicht-Reviewer, keine Confidence-Untergrenze. Gut für die ersten Durchläufe und experimentelle Projekte.
• strict: zusätzlich blockieren HIGH-Findings, Security- und Architektur-Review sind Pflicht (fehlen sie, endet das Gate mit ERROR), und liegt der aggregierte Confidence-Score unter 0,7, gibt es mindestens eine Warnung (WARNING). Gut für produktive Setups.

Sonderregeln (SECURITY/HIGH, ARCHITECTURE/CRITICAL) sind unabhängig davon immer blockierend.

Was kann ich im Settings-Bereich konfigurieren?

Unter /einstellungen (Einrichtung → Einstellungen, ADMIN-only) kannst du:

• KI-Zugang: je Agent Abo oder API-Schlüssel und Anmelde-Verzeichnis, als eine Tabelle.
• Betriebsmodus: Einzelplatz (Abo) oder Team (API-Pool).
• Workspace: Default-Wurzelpfad für alle Lauf-Workspaces.
• Git: User-Name und E-Mail für Auto-Commits.
• Adapter: Default-Adapter und Default-Modell pro Adapter.
• Wizard: Versions-Cache-Übersicht und manueller Refresh.
• Funktionsschalter: Stand und Umgebungsvariable (Workflows, Spezifikationen, PR-Rückmeldung, Lizenzprüfung, signierte Audit-Kette) — nur lesbar, weil sie beim Start wirken.

Modelle, Steuerartefakte, Kosten und Läufe stehen unter „Erweitert“ eingeklappt. Quality-Gate-Modus und -Strenge, Sandbox und Freigabe stellst du seit 0.49 auf der Seite Leitplanken (/leitplanken) ein — in drei Stufen (Vorsichtig, Ausgewogen, Schnell) oder in „Experte“ einzeln. Import-Ordner und Git-Hosts stehen unter Einrichtung → Import-Ordner und Git-Hosts.

Wie funktioniert das Budget?

Wirksame Budgets laufen in Euro und je Kalendermonat, nicht in Tokens. Die Kosten je Lauf berechnet die Plattform aus dem Token-Verbrauch und der Preistabelle.

• Projektbudget: Monatsbudget je Projekt mit Warnschwelle (Default 80 %). Optional erzwungen: Ab 100 % wird die Anlage neuer Läufe blockiert.
• Mandantenbudget: Monatsbudget über alle Projekte eines Mandanten, optional als harter Cap.

Laufende Läufe werden nicht abgebrochen — sie laufen zu Ende.

Wann wirken Setting-Änderungen?

Sofort: Beim Speichern verwirft der SettingService den betroffenen Cache-Eintrag. Der 5-Minuten-TTL-Cache begrenzt nur, wie lange ein auf anderem Weg (etwa direkt in der Datenbank) geänderter Wert veraltet bleiben kann. Ein Neustart ist nicht nötig.

Wer kann Settings ändern?

Nur Nutzer mit Rolle ADMIN. Primär der Bootstrap-Admin (SOFTWAREFABRIK_ADMIN_USER); weitere Admins legst du über /admin/nutzer an. Jede Änderung erzeugt einen Audit-Log-Eintrag mit Subject (wer), Scope, Key und Zeitstempel; die Werte selbst werden nicht protokolliert.

Wie steht es um Sicherheit und Datenschutz?

Die Plattform ist auf datensparsame und nachvollziehbare Nutzung ausgelegt:

• Keine Secrets im Code, kein Klartext-Passwort im Log.
• API-Keys AES-GCM-verschlüsselt im Postgres (Master-Key aus Env-Var).
• Passwörter mit BCrypt gehasht (Standard-Kostenfaktor 10).
• Audit-Log für alle sicherheitsrelevanten Aktionen.
• Approval-Policies vor kritischen Phasen.
• Postgres-Mapping in docker-compose auf 127.0.0.1 gepinnt — nicht versehentlich nach außen offen.
• pgJDBC 42.7.14 (u.a. CVE-2026-42198 und CVE-2026-54291 behoben).

Wie läuft der Agent isoliert?

Zwei Modi: Der Agent läuft als Prozess neben der Plattform: gefilterte Env-Variablen, ephemeres HOME mit nur den Anmeldedaten des Adapters, Workspace als Arbeitsverzeichnis. Zusätzlich kapselt ContainerProcessSandbox (Setting execution.sandbox.variant=container) Build und Scans des generierten Projekts in einem ephemeren Docker- oder Podman-Container mit --cpus 2 --memory 4g --pids-limit 512 --read-only (CPUs und Speicher als Standard, je Projekt unter Build-Container bis zu den Grenzen des Betreibers anpassbar); Netz bleibt dort erlaubt (Maven-Abhängigkeiten, trivy-Datenbank).

Wo werden API-Keys gespeichert?

In Postgres, verschlüsselt mit AES-GCM. Master-Key aus SOFTWAREFABRIK_SECRETS_MASTER_KEY (mindestens 32 Zeichen). Ohne Master-Key startet die Plattform nicht — nur das lokale Entwicklungsprofil nutzt einen unsicheren Ersatzschlüssel. Audit-Log loggt jede Schlüsseländerung.

Wie wird man als Nutzer authentifiziert?

In v1: lokale Authentifizierung mit Username + Passwort gegen die Plattform-DB. BCrypt-gehashte Passwörter, CSRF-Schutz, HttpOnly-Session-Cookie mit SameSite=Lax; das Secure-Flag schaltest du hinter HTTPS mit SOFTWAREFABRIK_COOKIE_SECURE=true ein (ab 0.41.5). Optional delegiert die Plattform die Anmeldung per OpenID Connect an einen Unternehmens-IdP (Keycloak, Entra ID, Okta, …); neue SSO-Nutzer werden als VIEWER ohne Mandant angelegt.

Welche Daten werden im Audit-Log gespeichert?

• Nutzerverwaltung (Anlage, Rolle, Mandant, Sperre, Passwort-Reset, SSO-Provisionierung). Login-Versuche selbst werden nicht protokolliert.
• Setting-Änderungen (Scope, Key, Subject, Zeitstempel — ohne Werte).
• Lauf-Starts (Lauf-ID, Adapter, Modell, Subject).
• Approval-Entscheidungen (Phase, Decision, Subject).
• Adapter-Konfigurationsänderungen (Integration-Setup mit verschlüsseltem API-Key).

Append-only als Hash-Kette, bei aktivierter Attestierung jeder Eintrag Ed25519-signiert; Manipulationen erkennt die Kettenprüfung. Tabelle audit_event.

Ist die Plattform für regulierte Umfelder geeignet?

Sie ist gut anschlussfähig — Nachvollziehbarkeit, Struktur, Dokumentation, Git-Disziplin und explizite Freigaben sind eingebaut. Die konkrete Härtung (z.B. ISO-27001-Konformität, BAIT, DORA) hängt vom Einsatzumfeld ab und braucht zusätzliche organisatorische Maßnahmen. Technisch helfen die Compliance-Profile (EU AI Act, BAIT/MaRisk/DORA, BSI/VS-NfD) als signierte Policy-as-Code, die signierte Audit-Kette und der Audit-Export. Für Behörden empfehlen wir den Air-Gap-Tier mit on-prem-LLM.

Welche Lizenzstufen gibt es?

Drei Stufen — Community, Professional und Enterprise:

• Community (kostenlos, kein Konto, nur E-Mail-Adresse): für den Einzelplatz; Mandanten, Rollen, SSO und Audit-Kette inklusive. Anfordern direkt in der Fabrik unter Einrichtung → Lizenz.
• Professional (20–30 €/Monat pro Nutzer): höhere Grenzen, Spec-Driven Development, Priority-Support.
• Enterprise (ab 20.000 €/Jahr): vertragliche Grenzen, SDD-Governance, Cloud/Self-Hosted/Air-Gap, Priority-Support.

Alle Grenzen und Lease-Zeiten: Preise. Was heute davon durchgesetzt wird, steht dort und unter Bekannte Grenzen. Die öffentliche Demo-Instanz braucht keine Lizenz — „Demo“ ist keine Stufe.

Wie funktioniert die Lizenz technisch?

EdDSA-/Ed25519-signierte JWT-Lease-Token vom Lizenz-Service. Die Plattform verifiziert offline gegen den mitgelieferten Public Key (zusätzlich veröffentlicht unter https://license.softwarefabrik.io/api/v1/pubkey). Tier-Features sind im Lease-Claim codiert. Setup & Trust-Chain im Transparenz-Dokument.

Welche LLMs unterstützt die Plattform?

• Anthropic Claude (offizielle API; die Cloud-Gateways AWS Bedrock und Google Vertex AI sind experimentell — implementiert, aber noch nicht live end-to-end getestet; produktiver Einsatz erst nach kundenseitiger Verifikation).
• OpenAI (offizielle API; Azure OpenAI ist experimentell — implementiert, aber noch nicht live end-to-end getestet; produktiver Einsatz erst nach kundenseitiger Verifikation).
• Google Gemini (Vertex AI ist experimentell — implementiert, aber noch nicht live end-to-end getestet; produktiver Einsatz erst nach kundenseitiger Verifikation).
• Moonshot Kimi (Kimi-CLI, API-Key oder Abo).
• On-Prem über Ollama oder vLLM: Qwen 3 Coder, DeepSeek V3.2, GLM-5.1, weitere.

Die LLM-Auswahl ist Kunden-Entscheidung und wird im Adapter konfiguriert. Für Air-Gap-Betrieb sind nur on-prem-LLMs möglich. Eine konsolidierte Liste offener Punkte steht unter Bekannte Grenzen.

Kann ich zwischen den Tiers wechseln?

• Community → Professional: jederzeit, indem du die Professional-Lizenzdatei importierst (Einrichtung → Lizenz).
• Professional → Enterprise: per Kontaktaufnahme, individuelle Migration inkl. vertraglicher Abstimmung.
• Enterprise-Deployment-Wechsel (z.B. Cloud → Self-Hosted): Teil des Vertrags, wird mit neuer Lizenzdatei umgesetzt.

Was ist der Unterschied zu LangChain / LangGraph / AutoGPT?

LangChain und LangGraph sind Library-Frameworks für Python-Entwickler, die selbst AI-Workflows bauen. AutoGPT ist ein experimenteller Auto-Run-Agent, der weitgehend autonom Aufgaben zerlegt. Die Software Factory ist keine Library — sie ist eine fertige Webanwendung mit definiertem Workflow (Projekt → Artefakte → Lauf → Quality Gate). Du programmierst nichts, du nutzt sie. Die Zielgruppe ist deshalb deutlich breiter: nicht nur Python-Devs mit AI-Hintergrund, sondern jeder Lead Developer.

Wann kommt Multi-Agent-Ausführung?

Teilweise schon da: Plan-, Build- und Spec-Läufe bekommen je Laufart ein eigenes Modell (Capability-Routing: Plan und Spec das des Architect, Build das des Developer), Reviews laufen mit eigenen Reviewern, und seit v0.21 verteilt die Workflow-Ebene ein Vorhaben auf parallele Teil-Läufe (Feature-Flag, höchstens drei gleichzeitig, nur auf einem Host). Agenten, die direkt miteinander kommunizieren, gibt es nicht.

Gibt es eine Roadmap?

Ja, in der Distribution unter docs/roadmap/reifegrad-roadmap.md. Die Mandantentrennung (eigene Policy, Audit-Sicht, Kosten und Export je Mandant) ist seit v0.17 geliefert; eine Plugin-API ist nicht eingeplant, ein SPA-Frontend bewusst ausgeschlossen. Die News-Seite hält den jeweils aktuellen Stand fest, offene Einschränkungen sammelt die Seite Bekannte Grenzen.

Gibt es weiterführende technische Hintergrundinformationen?

Ja. Als Architektur-Deep-Dive gibt es ein eigenes Whitepaper, das die architektonischen Grundlagen agentischer Softwareentwicklung beschreibt: Referenzarchitektur, Agenten-Orchestrierung, AI-Guardrails, Shared Knowledge Stores und die Integration in den Software Development Lifecycle. Das PDF ist kostenfrei und ohne Registrierung abrufbar.

Wie funktioniert der Wizard intern?

Unter /wizard gibt es zwei Wege. Der Schnellstart (/wizard/schnellstart, Ziel von „Neues Projekt“) fragt nur Name, Art und Beschreibung ab, setzt den Rest mit Vorgaben; „Bauen“ legt das Projekt an und startet sofort den ersten Lauf mit der Beschreibung als Auftrag. Sein zweiter Reiter importiert ein bestehendes Projekt (Ordner oder Git-Adresse) und startet ebenso den ersten Lauf. Der „Ausführliche Assistent“ ist ein Sechs-Schritt-Controller mit eigener Persistenz in wizard_draft (V12). Schritte:

1. Zielplattform: Web, Mobile oder Desktop. Die Wahl bestimmt, welche Backends und Frontends überhaupt zusammenpassen.
2. Backend: Spring Boot, Quarkus, .NET, FastAPI, Express — oder der Import eines bestehenden Repositories.
3. Frontend(s): ein oder mehrere Frontends (React, Angular, Vue, Thymeleaf, Vaadin, Blazor, Flutter, React Native, MAUI, WPF, MonoGame, JavaFX, statisch).
4. Fragen: je Template ein eigenes Set (Java-Version, DB, Architektur-Stil, Node-Version, Build-Tool, …). Die Antworten landen in einer JSON-Spalte.
5. Quality-Gate-Toggles: z.B. ArchUnit, OWASP Dependency-Check, Trivy, Playwright, ESLint, Vitest, Ruff, mypy, Bandit oder Roslyn-Analyzer. Welche erscheinen, hängt vom gewählten Stack ab — ArchUnit etwa nur für Java-Backends.
6. Zusammenfassung: Übersicht aller Antworten mit Kosten-Schätzung und Prompt-Vorschau, dann „Projekt anlegen und bearbeiten“. Der Wizard erzeugt eine ProjectDefinition, befüllt alle Editor-Felder und setzt den Draft auf completed.

Drafts überleben Browser-Reload und Server-Restart. Die nächste /wizard-Visite zeigt einen Knopf „Entwurf fortsetzen“, der dich auf den letzten gespeicherten Schritt bringt. Ungeschlossene Drafts werden nach 30 Tagen automatisch gelöscht (Cleanup-Job um 04:00).

Warum Spring Boot + Thymeleaf statt Angular/React?

Version 1 priorisiert Orchestrierung, Lauf-Modell, Git-/Build-Integration und Nachvollziehbarkeit. Eine serverseitige UI mit Spring Boot und Thymeleaf reduziert Komplexität — kein separates Frontend-Build, keine API-Versionierung, keine doppelte Authentifizierung. Das macht den Produktkern schneller belastbar. Eine SPA ist bewusst nicht geplant (Reifegrad-Roadmap: „keine SPA“).

Wie kommen die Versions-Werte in den Wizard?

Aus dem version_cache (V13). Ein täglicher @Scheduled-Job um 03:00 holt aktuelle stabile Versionen aus drei Quellen:

• Maven Central für Spring Boot, ArchUnit, OWASP Dependency-Check.
• GitHub Releases für Trivy CLI.
• npm Registry für Playwright.

Cache-Keys sind fachlich, nicht technisch: spring-boot.3.x, archunit.latest, trivy.cli.latest, … Wenn der Cache leer oder stale ist, fällt der Wizard auf hart kodierte Fallback-Versionen aus dem Code zurück.

Was passiert, wenn der Versions-Cache stale ist?

„Stale“ heißt: Java-berechnet, der letzte Refresh ist mehr als 25 Stunden her. Der Wizard zeigt die Werte trotzdem (mit einem Stale-Badge in der Admin-UI), und du kannst auf /einstellungen/wizard/versions manuell auf „Jetzt manuell refreshen“ klicken, um einen synchronen Lookup auszulösen. Wenn der Lookup-Job mehrfach gescheitert ist, siehst du die letzte Fehlermeldung in der Spalte last_error.

Können Templates erweitert werden?

Per Code: neuer Eintrag im TemplateRegistry (immutable Record mit Feldern und unterstützten Toggle-IDs) plus Snippets unter resources/wizard/snippets/<lang>/<toggleId>.md und Basis-Prompt unter resources/wizard/prompts/<lang>/<templateId>/basis.md. Aktuell sind 19 Templates registriert. UI-basiertes Template-Management (Custom-Templates per Drag-and-Drop) bleibt bewusst V2-Thema.

Was ist die Override-Reihenfolge?

PROJECT > USER > GLOBAL > YAML. Heißt: ein Wert auf Projekt-Ebene überschreibt einen Wert auf User-Ebene überschreibt einen globalen Wert überschreibt den Default aus application.yml. Der SettingService implementiert diese Resolution einheitlich für alle Settings.

Können externe Plugins / Adapter geladen werden?

In v1: Nein. Adapter werden als Java-Klasse im Code hinzugefügt. Eine Plugin-API (z.B. via Java Service Provider Interface oder Spring-Boot-Starter-Mechanismus) ist derzeit nicht eingeplant, weil ein stabiles Plugin-API-Design erst lohnt, wenn die Adapter-Logik mehrfach iteriert wurde.