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, Run-Orchestrierung gegen Coding-CLIs (Claude Code, Codex, Gemini, 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.

Was hat sich seit v0.4.0 getan?

Acht Releases haben die Plattform vom „MVP mit zwei Wizard-Templates“ zum komplett orchestrierten Solo-Dev-Werkzeug ausgebaut:

• v0.4.0 — Settings + Wizard. /einstellungen mit Override-Reihenfolge PROJECT > USER > GLOBAL > YAML + 5-Min-TTL-Cache; Vier-Schritt-Wizard mit zwei Templates und Versions-Cache.
• v0.5.0 — Polyglott. Vier weitere Wizard-Templates: .NET Backend, Python FastAPI, Node Express, plus das spätere Existing-Repo-Import. Insgesamt sechs Templates.
• v0.6.0 — Conductor. Modell-Routing pro Rolle (preferredModel wird als --model-Flag durchgereicht); Plugin-/Skills-Sync; Repo-Import-Wizard und PROJECT_NOTES.md.
• v0.7.0 — Härtung. Container-pro-Run-Sandbox (Docker/Podman mit --cpus 2 --memory 4g --pids-limit 512 --read-only --network=none) als Setting wählbar; Run-Templates aus erfolgreichen Runs; Live-Token-Stream via NDJSON-Parser.
• v0.8.0 — UX-Spitze. Kosten-Schätzung in Wizard-Schritt 4 (lokal via JTokkit); Inline-Diff der Workspace-Änderungen vor Approval; Browser-Notifications bei Run-Abschluss.
• v0.8.1 — Wizard-Polish. Progress-Stepper, Objective-Vorschau, server-seitige Pflichtfeld-Validierung, Empty-State für VERSION_PICK.
• v0.9.0 — Claude-Abo-Auth & Observability. Coding-Runs wahlweise über dein Claude-Max/Pro-Abo statt API-Key; Prometheus-Metriken (Observability Ebene 1) unter /actuator/prometheus.
• v0.9.1 — Härtung & Qualität. Erhöhte Test-Coverage (Issuer-Sicherheitstest, testbares CSV-Escaping; Branch-Coverage 0.815 bei Gate ≥0.80), erweiterte ArchUnit-Regeln (hexagonale Ports-and-Adapters + Freeze-Ratchet gegen Modul-Zyklen und web→repository), Doku-/DRY-Aufräumung.
• v0.10.0 — Windows-nativer Einzelplatz & Boot-Härtung. Claude-Abo-Modus läuft nativ unter Windows (OS-bewusste Env-Allowlist + claude.cmd-Default, end-to-end verifiziert); Boot-Crash in Nicht-demo-Profilen und /teams/{id}-500 behoben; Boot-Smoke als CI-Pflicht-Gate; Community-Lease 30 Tage mit Refresh beim Start.
• v0.11.0 — Stack-Wizard & Codex-Abo. Projekt-Wizard kombiniert Zielplattform × Backend × Frontend(s) (17 Templates, 12 Frontends, Multi-Target, Migration V16); OpenAI Codex läuft über das ChatGPT-Abo statt über OPENAI_API_KEY (analog Claude-Abo, in der UI umschaltbar).
• v0.12.0 — Quarkus & Benutzerhandbuch. Quarkus als Backend-Stack im Wizard (neben Spring Boot); ausführliches Benutzerhandbuch (DE+EN) für den Einzelplatz; echte Umlaute im deutschen UI und saubere Cache-Header.
• v0.13.0 — Iterativer SDLC. Projekt-persistenter Workspace + Re-Run (Weiterentwicklung auf bestehendem Code), echter Repo-Import, Project-Memory (Learnings), und Roadmap/Pläne als Backlog (Plan-Run erzeugt plans/*.md, Aktivieren startet einen Build-Run).
• v0.14.0 — Branch/PR & SDLC-Reife. Branch-Isolation pro Build-Run mit optionalem Push + Pull-Request (GitHub), automatische Korrektur-Feedback-Schleife, Quality-Gate in der Pipeline (aus/beratend/blockierend) und Auto-Folgevorschläge; Wizard mit .NET 10.

Die News-Seite hat die ausführlichen Release-Notes.

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.

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.

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-4-8 für tiefe Designentscheidungen, ein Reviewer das schnellere claude-haiku-4-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. Projekt-Idee erfassen (Wizard oder Schnell-Anlegen).
2. Projekt-Felder ausfüllen oder vom Wizard übernehmen.
3. Markdown-Artefakte generieren und einmal durchlesen.
4. Team-Zusammenstellung prüfen (oder Default akzeptieren).
5. Run mit klarem Ziel anlegen, auf READY setzen, starten.
6. Logs, Phasen und Git-Diff verfolgen, Approvals klicken.
7. Nach COMPLETED Quality Gate ausführen, Findings prüfen.
8. Bei Bedarf Folge-Run mit Korrekturziel aufsetzen.

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.

Warum Spring Boot + Thymeleaf statt Angular/React?

Version 1 priorisiert Orchestrierung, Run-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-Version steht im Backlog (ADR-0015 in Diskussion), aber erst, wenn der Kern stabil ist.

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

Nicht im Sinne von „mehrere Agenten parallel mit gegenseitiger Kommunikation“. Version 1 bereitet Rollen, Teams und Workflow-Strukturen dafür vor, setzt aber zunächst auf einen ausführenden Adapter pro Run. Das Ziel ist ein sauberer Ausbaupfad, nicht maximale Komplexität im ersten Schritt. Echtes Multi-Agent (verschiedene Modelle pro Phase, gegenseitiges Review) ist Teil der Roadmap ab Phase 5/6.

Wie installiere ich die Plattform lokal?

Drei Wege: (1) Docker Compose mit dem mitgelieferten docker-compose.yml — einfachster Pfad; (2) Spring-Boot-JAR direkt starten plus eigene Postgres-Instanz; (3) Air-Gap-Auslieferung auf Anfrage. Siehe Schnellstart für die Klick-für-Klick-Anleitung.

Welche Voraussetzungen brauche ich?

• Docker (24+) und Docker Compose v2.
• Freier Port 8080 (Web) und 5432 (Postgres, lokal gebunden).
• ~5 GB Plattenplatz für Container-Images, Build-Cache und erste Workspaces.
• Eine .env-Datei mit Bootstrap-Admin-Credentials und Master-Key.

Java, Maven oder Node musst du nicht lokal installieren, solange du im Container-Modus bleibst. Erst wenn du echte Vendor-Adapter wie claudecode oder codex nutzen willst, brauchst du die jeweilige CLI lokal.

Wie starte ich die Plattform?

Aus dem freigeschalteten Distributions-Bundle (kein öffentliches Repo — Zugang auf Anfrage):

tar xzf softwarefabrik-einzelplatz.tar.gz
cd softwarefabrik
# .env anlegen mit ADMIN_USER, ADMIN_PASSWORD, DB_PASSWORD, SECRETS_MASTER_KEY
docker compose up -d

Den Master-Key generierst du mit openssl rand -base64 32 (mindestens 32 Bytes). Details im Schnellstart.

Welche Java-Version brauche ich?

Java 25 (LTS). Spring Boot 4.0.7. 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.3-alpine gepinnt). Schema-Migrationen über Flyway, aktuell bis V32. Im Test-Profil läuft H2 mit Postgres-Kompatibilitätsmodus.

Brauche ich API-Keys?

Für die Demo lokal reicht der Mock-Adapter — keine Keys. Für echte Vendor-Aufrufe: Anthropic-, OpenAI-, Gemini-Keys werden im /integrations-View verschlüsselt persistiert (AES-GCM, Master-Key aus SOFTWAREFABRIK_SECRETS_MASTER_KEY).

Wie funktioniert die Plattform offline?

Antwort hängt vom Tier ab:

• Community und Professional: bis zu 30 Tage offline nutzbar (Grace-Period nach Lease-Ablauf). Danach lässt sich die 24-Stunden-Notfall-Grace einmalig per Klick aktivieren.
• Enterprise Self-Hosted: bis zu 90 Tage offline. Der Lizenzserver läuft in diesem Szenario ohnehin im internen Netz.
• Enterprise Air-Gap: komplett ohne Netzwerk. Erneuerung einmal jährlich über eine signierte Zertifikats-Datei (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, 365 Tage gültig).
• 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.

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.
• An den konfigurierten LLM-Vendor: dein Prompt + Workspace-Inhalte. Das hängt vom Vendor ab.

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

Wie funktioniert der Wizard intern?

Der Wizard ist ein Vier-Schritt-Controller unter /wizard mit eigener Persistenz in wizard_draft (V12). Schritte:

1. Template-Auswahl: Du wählst zwischen spring-boot-backend und static-frontend. Das Template bestimmt, welche Fragen in Schritt 2 kommen.
2. Fragen: Pro Template ein Set von Fragen (Java-Version, DB, Architektur-Stil, Node-Version, Build-Tool, …). Die Antworten werden in einer JSON-Spalte gespeichert.
3. Quality-Gate-Toggles: ArchUnit, OWASP, Trivy, Playwright. Welche Toggles erscheinen, hängt vom Template ab (z.B. ArchUnit nur für Backend).
4. Zusammenfassung: Übersicht aller Antworten, dann „Projekt anlegen“. Beim Abschluss erzeugt der Wizard ein ProjectDefinition, befüllt alle Editor-Felder, setzt den Draft-Status 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).

Wie viele Templates gibt es?

Sechs: spring-boot-backend, static-frontend, dotnet-backend, python-fastapi, node-express, existing-repo-import.

Welche Templates gibt es im Detail?

Snippets liegen auf dem Classpath unter resources/wizard/templates/<name>/ und sind in DE und EN verfügbar (Sprache wählst du im Wizard-Schritt 2).

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 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.

Was passiert in Schritt 4 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).

Wie schalte ich den Wizard ab und nutze nur „Schnell anlegen“?

Du brauchst den Wizard nicht abzuschalten — der Knopf „Schnell anlegen“ bleibt auf der Projekt-Liste sichtbar und öffnet ein zweifeldiges Formular (Projekttitel, Produktname). Du landest direkt im Editor und füllst alles selbst.

Wenn du den Wizard komplett ausblenden willst (z.B. weil dein Team nur Schnell-Anlegen nutzt), kannst du in den Settings unter UI den Toggle „Wizard-Eintrag im Menü“ ausschalten. Die Route bleibt aber technisch erreichbar — wir verstecken sie nur in der Navigation.

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 sechs Templates registriert. UI-basiertes Template-Management (Custom-Templates per Drag-and-Drop) bleibt bewusst V2-Thema.

Welche Adapter gibt es?

Welche Default-Modelle nutzt die Plattform pro Rolle?

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

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

Zusätzlich gibt es pro Adapter ein Default-Modell unter /einstellungen → Adapter (z.B. execution.model.codex → gpt-5, execution.model.gemini → gemini-2.5-pro). Diese Defaults gelten für alle neuen Runs, außer der User wählt im Run-Anlage-Dialog explizit ein anderes Modell.

Wie funktioniert das Modell-Routing pro Rolle?

Jede AgentDefinition hat ein nullable preferredModel-Feld (V11). Der Claude-Code-Adapter hängt es als --model-Flag an die CLI-Aufrufzeile. Bei unbekannten IDs fällt er auf den CLI-Default zurück. Drift-Erkennung emittiert ein Warning-Event, wenn das tatsächlich genutzte Modell vom angeforderten abweicht.

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 Run 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 Run-Verlauf simulieren.

Kann ich pro Run einen anderen Adapter wählen?

Ja. Auf der Run-Anlage-Seite gibt es ein Dropdown „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 Run-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 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 — statische Heuristik-Engine: scannt nach Hardcoded-Passwörtern, schwacher Krypto, SQL-Injection-Patterns, fehlenden Input-Validierungen, …
• architecture-reviewer — vergleicht den Code gegen die Architekturvorgaben in PROJECT.md + WORKFLOW.md. Findet Schichtenverletzungen, falsche Abhängigkeiten.
• hallucination-review — sucht erfundene Methoden-Aufrufe, nicht-existierende Pakete oder ausgedachte API-Signaturen.

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 — Quality Gate wurde nicht ausgeführt (z.B. weil Run abgebrochen).
• ERROR — ein Reviewer ist gecrasht (z.B. weil seine CLI fehlt). Bewusst nicht verschluckt.

Jeder Reviewer liefert Findings mit Severity (LOW/MEDIUM/HIGH/CRITICAL) und Confidence (0..1), aus denen das Gesamt-Verdict aggregiert wird.

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?

• strict (Default): jedes WARNING blockiert weitere Phasen. Gut für produktive Setups.
• lenient: WARNING führt zur Anzeige, blockiert aber nicht. Gut für die ersten Tutorial-Durchläufe und experimentelle Projekte.

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

Was kann ich im Settings-Bereich konfigurieren?

Unter /einstellungen (ADMIN-only) kannst du:

• Workspace: Default-Wurzelpfad für alle Run-Workspaces.
• Git: User-Name und E-Mail für Auto-Commits.
• Adapter: Default-Adapter und Default-Modell pro Adapter.
• Budget: Tages- und Wochen-Token-Caps, Soft-Schwelle.
• Wizard: Versions-Cache-Übersicht und manueller Refresh.
• Quality Gate: Policy strict / lenient, Reviewer-Aktivierung.

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.

Wie funktioniert das Token-Budget?

Du setzt einen Tages-Token-Cap (z.B. 2.000.000) und/oder einen Wochen-Token-Cap. Pro Run werden die verbrauchten Tokens (Input + Output) summiert. Es gibt zwei Modi:

• Soft-Schwelle (Default 80 %): Bei Überschreitung wird in der UI ein Warn-Banner angezeigt. Neue Runs sind weiter möglich.
• Hard-Limit bei 100 %: Neue Run-Anlage wird blockiert mit Hinweis „Tagesbudget erreicht“. Laufende Runs werden nicht abgebrochen — sie laufen zu Ende.

Reset um Mitternacht (lokale Zeit) für Tag, Sonntag 00:00 für Woche.

Wann wirken Setting-Änderungen?

Maximal 5 Minuten nach dem Speichern, weil der SettingService einen 5-Minuten-TTL-Cache hat. Das ist ein bewusster Trade-off: weniger DB-Hits pro resolve, dafür leichte Verzögerung. Wenn du es sofort sehen willst, gibt es einen Knopf „Cache jetzt invalidieren“ auf der Settings-Seite.

Wer kann Settings ändern?

Nur Nutzer mit Rolle ADMIN. Primär der Bootstrap-Admin (SOFTWAREFABRIK_ADMIN_USER); weitere Admins legst du über /admin/users an. Jede Änderung erzeugt einen Audit-Log-Eintrag mit Subject (wer), Key, Old-Value, New-Value, Timestamp.

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 12 Runden gehasht.
• 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.11 mit CVE-2026-42198-Fix.

Wie läuft der Agent isoliert?

Zwei Modi: LocalProcessSandbox (Default) startet den Agent im selben Container wie die Plattform, gefilterte Env-Variablen, Workspace als Arbeitsverzeichnis. ContainerProcessSandbox (Setting execution.sandbox.variant=container) startet jeden Run in einem ephemerem Docker- oder Podman-Container mit --cpus 2 --memory 4g --pids-limit 512 --read-only --network=none.

Wo werden API-Keys gespeichert?

In Postgres, verschlüsselt mit AES-GCM. Master-Key aus SOFTWAREFABRIK_SECRETS_MASTER_KEY (mindestens 32 Bytes Base64). Ohne Master-Key startet die Plattform nicht. 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, Session-Cookies (HttpOnly, Secure, SameSite=Lax). Für Enterprise-Tier zusätzlich Keycloak-OIDC mit Device-Authorization-Grant — einmaliger Login im Browser, danach speichert die App ein verschlüsseltes Refresh-Token lokal.

Welche Daten werden im Audit-Log gespeichert?

• Login-Versuche (erfolgreich + fehlgeschlagen, mit User-Subject und IP-Land).
• Setting-Änderungen (Key, Old-Value, New-Value, Subject, Timestamp).
• Run-Starts (Run-ID, Adapter, Modell, Subject).
• Approval-Entscheidungen (Phase, Decision, Subject).
• Adapter-Konfigurationsänderungen (Integration-Setup mit verschlüsseltem API-Key).

Append-only — nichts wird gelöscht oder editiert. 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. 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, keine Registrierung): 10 Runs/Tag, 3 parallele Agenten, 3 Geräte. Kein Team, kein SSO, kein Audit-Log. Gut zum Ausprobieren.
• PROFESSIONAL (20–30 €/Monat pro Nutzer): 100 Runs/Tag, 10 Agenten, 5 Geräte, Priority-Support. Kein Team/SSO/Audit.
• ENTERPRISE (ab 20.000 €/Jahr): 1000 Runs/Tag, 50 Agenten, Geräte laut Vertrag, Team + SSO + Audit-Log + Priority-Support.

Details: Lizenzmodell. Die öffentliche Demo-Instanz braucht keine Lizenz — „Demo“ ist kein Tier.

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.

Wie funktioniert die Lizenz technisch?

EdDSA-/Ed25519-signierte JWT-Lease-Token vom Lizenz-Service. Die Plattform verifiziert offline gegen den Public Key (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).
• 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 Known Limitations.

Kann ich zwischen den Tiers wechseln?

• Community → Professional: jederzeit über Account-Upgrade.
• 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 sind die Limits der Community-Version?

• 10 erfolgreiche Runs pro Tag (Reset um 00:00 lokaler Zeit).
• 3 parallele Agenten pro Run.
• Keine Team-Features, kein SSO, kein Audit-Log, kein Support-SLA.
• Fehlgeschlagene, abgebrochene oder in Timeout gelaufene Runs zählen nicht mit.

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 → Run → 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?

Roadmap Phase 5/6 (Sommer/Herbst 2026). Konkret: pro Phase ein anderer Agent (Plan = Architect / Implement = Developer / Review = Reviewer), mit eigenen Modellen pro Rolle. Die Datenbank-Schema-Vorbereitung ist mit V11 (agent_preferred_model) bereits da — fehlt nur die Orchestrierungs-Logik.

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 im Backlog (ADR-0014). Wir verzögern das bewusst, weil ein stabiles Plugin-API-Design erst lohnt, wenn die Adapter-Logik mehrfach iteriert wurde.

Gibt es eine Roadmap?

Ja, in der Distribution unter docs/roadmap/reifegrad-roadmap.md. Die Mandanten-Grundlagen (Isolation an der Projektgrenze, RBAC, SSO) sind bereits vorhanden; die vollständige, auditsichere Mehrmandanten-Fähigkeit (getrennte Policy/Audit/Reports pro Mandant) sowie externes Plugin-API und SPA-Frontend sind perspektivisch eingeplant — bis dahin: eine Instanz pro Mandant empfohlen. Die News-Seite hält den jeweils aktuellen Stand fest, offene Einschränkungen sammelt die Seite Known Limitations.

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 starte ich am besten?

Mit dem Schnellstart (10 Minuten, Mock-Adapter, ohne API-Kosten). Wenn das läuft: Tutorial mit echtem Claude-Code-Adapter (45 Minuten). Wer einfach klicken will, ohne lokal zu installieren: Live-Demo.