Was die Fabrik eigentlich ist.

Welche Probleme löst es konkret?

Die direkte Shell-Nutzung von Claude Code ist mächtig, aber prozessual rau. Genau diese Reibungspunkte adressiert die Plattform:

• Prompt-Chaos in der ShellProjektdefinitionen entstehen ad-hoc, sind nicht versionierbar und schwer wiederverwendbar.
• Wenige Commits, unklare Git-HistorieLange Claude-Sessions produzieren große, schlecht reviewbare Änderungen.
• Freigaben ohne KontextManuelle Approvals werden routinemäßig abgenickt, kritische Phasen sind nicht sichtbar markiert.
• Keine durchgängige NachvollziehbarkeitLogs, Build-Ergebnisse und Agenten-Entscheidungen verteilen sich auf Terminal, Editor und Notizen.
• Nachfolge-Projekte fangen bei null anBewährte Agent-Rollen, Teams und Leitplanken werden nicht konserviert.

Für wen ist das?

Die Plattform ist für technische Verantwortliche gebaut, die AI-gestützte Entwicklung strukturiert einsetzen wollen — typischerweise im Mittelstand, in regulierten Umfeldern oder bei Beratungen, die Code-Resultate auch dokumentieren müssen. Kein Massen-Consumer-Produkt; Hobbyisten sind mit Claude Code direkt schneller bedient.

Einblick in die Plattform

So sieht die laufende Fabrik aus — hier der Projekt-Assistent. Darunter schematisch die weiteren Arbeitsbereiche.

localhost:8080/wizard

Projektinhalte
[ Projektname        ]
[ Zielbild           ]
[ Constraints / DoD  ]
        Zurück  [ Weiter ]

✓ INTAKE
✓ PROMPT_ASSEMBLY
✓ WORKSPACE_PREPARATION
⟳ EXECUTION · running…
· VALIDATION
· COMPLETION

a1f2e3b feat: DoD persistiert
7c9d4a2 test: policy paths
e2b8f6c feat: run validation
─────────────────────────
mvn verify · PASS
42 tests · coverage 82 %

Artefakte
 PROJECT.md
 INSTRUCTIONS.md
 AGENTS.md
 WORKFLOW.md
 DEFINITION_OF_DONE.md
 README.md

So konkret sieht das aus

Beispiel: Du willst eine einfache REST-API für Rechnungen bauen. So läuft der Weg über die Softwarefabrik — vom 15-Sekunden-Wizard bis zum validierten Commit.

Projektname: Invoice API
Zielbild:    REST-API für Rechnungen,
             CRUD + Statusübergänge
Tech:        Spring Boot 4, PostgreSQL 16, Flyway
DoD:         alle Endpoints getestet,
             mvn verify grün, Coverage ≥ 85 % Line / ≥ 81 % Branch

✓ PROJECT.md             47 Zeilen
✓ INSTRUCTIONS.md        32 Zeilen
✓ WORKFLOW.md            19 Zeilen
✓ DEFINITION_OF_DONE.md  14 Zeilen
✓ AGENTS.md              21 Zeilen
✓ README.md              28 Zeilen
✓ Git-Repo               initial commit
✓ Run-Template           mvn verify Gate

Run #42 · Invoice API · claude-code adapter        Phase 5 / 7

14:32:01  ✓ INTAKE                            2 s
14:32:03  ✓ PROMPT_ASSEMBLY                   4 s
14:32:07  ✓ WORKSPACE_PREPARATION            8 s
14:32:15  ⟳ EXECUTION (claude-code)      4 min 12 s
            ├ src/main/java/…  +247 Zeilen
            ├ src/test/java/…  +89 Zeilen
            └ 3 Commits · feat, test, docs
14:36:27  ✓ VALIDATION (mvn verify)         52 s
            · CORRECTION übersprungen — Validation grün
14:37:19  ⏸ COMPLETION (wartet auf Freigabe)  —

Gesamt 5 min 18 s · 336 Zeilen Code · 42 Tests · Coverage 82 %

Der vollständige Loop: von der Idee zur nächsten Iteration

Ein einzelner Run endet nicht am Quality Gate — die Fabrik denkt in Iterationen. Auf einem persistenten Workspace (frisch angelegt oder per Repo-Import aus einem bestehenden Repository) schließt sich ein durchgängiger Kreislauf in acht Schritten:

1. Planen — ein Plan-Run zerlegt das Ziel in Markdown-Pläne, die als Backlog einzeln auswählbar werden.
2. Auswählen — du aktivierst einen Backlog-Eintrag als nächste Aufgabe.
3. Bauen — ein Build-Run arbeitet auf einem eigenen Branch, nicht direkt auf dem Hauptstand.
4. Selbstkorrektur — bei rotem Build wiederholt die Plattform die Korrektur automatisch und begrenzt, bis der Build grün ist.
5. Quality-Gate — läuft in der Pipeline wahlweise aus, beratend oder blockierend.
6. Liefern — mit Git-Remote und GitHub-Token entstehen Push und Pull-Request; ohne beides wird lokal in den Hauptstand gemerged.
7. Lernen — ein Project-Memory bewahrt Erkenntnisse und fließt in Folge-Runs ein.
8. Weiter — optionale Auto-Folgevorschläge führen direkt zur nächsten Iteration — der Loop schließt sich.

Was V1 leisten soll

Das Reifegradmodell der Plattform definiert fünf Stufen. V1 erreicht die Stufen M1 bis M4:

Bestandteile

Plattform-Kern (eine Spring-Boot-Anwendung)

• Projekt-Editor und -Wizard — Erfassung von Projekten als strukturierte Markdown-Artefakte.
• Run-Engine — Orchestrierung der Phasen, Live-Streaming, Status-Tracking.
• Adapter-Registry — Anbindung an Coding-CLIs als Spring-Beans.
• Quality-Gate — aggregiert Reviewer-Findings (architecture, hallucination, security, aider, claude) zum Verdict.
• Settings, Audit, Secrets — Cross-Cutting-Concerns mit Override-Logik, Audit-Trail und Verschlüsselung.
• Conductor — schreibt vor jedem Run die CLI-Konfiguration ins Workspace.

Lizenz-Service (separater Microservice)

• License-Service — Spring-Boot-Anwendung mit Ed25519-Signatur (EdDSA), gibt JWT-Lease-Tokens für die Tier-Prüfung aus.
• Keycloak — Identity-Provider für Kunden-Login bei der Lizenz-Verwaltung.

Demo-Infrastruktur

• demo.softwarefabrik.io — öffentliche Single-Tenant-Demo-Instanz mit Mock-Adapter, täglichem Reset.

Lizenzmodell · Kurzform

Drei Stufen mit bewusst reibungsarmem Einstieg. Detaillierter Vergleich und Registrierungsprozess auf der Seite Lizenzmodell.

Was das Projekt alles beinhaltet

Technische Basis von Version 1

Angular ist in Version 1 bewusst nicht nötig. Fokus auf Workflow, Orchestrierung, Nachvollziehbarkeit und Wiederverwendbarkeit.

Was V1 bewusst nicht leisten muss

• grafischer Workflow-Designer
• Cloud-Skalierung und Mandantenfähigkeit
• vollwertige CI/CD-Plattform

Empfohlenes Domänenmodell

Wichtige UX-Leitentscheidung

Der Nutzer soll nicht zuerst manuell Markdown-Dateien schreiben müssen.

Idee → strukturierte UI-Erfassung → automatisch generierte Markdown-Artefakte → editierbare Vorschau → Run

Deep Dive: Architektur hinter der Softwarefabrik

Die Softwarefabrik basiert auf einer fundierten Architektur für agentische Softwareentwicklung. Das begleitende Whitepaper beschreibt Referenzarchitekturen, Agenten-Orchestrierung, Guardrails und SDLC-Integration auf 76 Seiten — als konzeptionelles Fundament des Produkts.

Weiterlesen

• → Einführung — Bedienung Schritt für Schritt.
• → Architektur — technischer Aufbau und Modulgrenzen.
• → News — Release-Historie bis v0.19.0.
• → Lizenzmodell — Community / Professional / Enterprise.