Was ist neu in der Agentic Software Factory

Kosten-Schätzung im Wizard, Inline-Diffs und Browser-Notifications

Mit 0.8.0 schliesst die Plattform zwei vertagte Bausteine ab: der Projekt-Assistent zeigt schon vor dem ersten Run, wieviel der Run grob kosten wird, und die Approval-View blendet einen echten Diff der bisherigen Workspace-Aenderungen ein — statt blindem "Approve / Reject". Browser-Notifications informieren auch nach geschlossenem Tab ueber Run-Abschluss oder Approval-Bedarf.

Wizard Schritt 4 — Kosten-Schätzung (Phase 4.5)

• Neuer WizardCostEstimator verbindet den existierenden PromptComposer, den TokenEstimator aus Phase 9 (JTokkit) und die ModelPricingProperties zu einer lokalen EUR-Schätzung. Kein LLM-Call, keine Latenz im Wizard.
• Default-Modell claude-sonnet-4-6, Annahme Output = 1.5x Input. Bewusst konservativ, damit die angezeigte Zahl Run-Kosten nicht systematisch übertreibt.
• Modelle ohne Preistabelle zeigen den Hinweis "keine Preistabelle hinterlegt" statt fiktiver Zahlen.

Inline-Diffs vor Approval (Phase 7.5b)

• GitService#diffSeit shellt git diff --no-color <sha> aus dem Workspace, gekappt bei 256 KB, damit ein versehentlich riesiger Diff den Heap nicht füllt.
• Die Run-Detail-View blendet bei WAITING_FOR_APPROVAL eine collapsible Diff-Karte ein — Vergleich gegen den frühesten GitCheckpoint des Runs.
• Approve / Reject ist damit nicht mehr blind; der Diff macht sichtbar, was der Agent geändert hat.

Browser-Notifications (Phase 7.5a)

• LogStreamService emittiert pro Poll-Zyklus zusätzlich ein status-SSE-Event, sobald sich der Run-Status ändert — kein zweiter Endpunkt nötig.
• Detail-View zeigt einen "Aktivieren"-Button für die Web-Notifications-API. Permission wird nur auf User-Klick angefordert (sonst lehnen moderne Browser stillschweigend ab).
• Notifications feuern bei COMPLETED, FAILED, TIMEOUT, CANCELLED, NEEDS_CORRECTION und WAITING_FOR_APPROVAL — den Stati, für die der Nutzer nach einem geschlossenen Tab zurückkommen sollte.

Begleitend

• 985 Tests grün, JaCoCo-Schwellen 80 % Line / 80 % Branch durchgehend gehalten.
• Demo unter demo.softwarefabrik.io läuft mit v0.8.0.

Run-Templates, Container-Sandbox, Live-Token-Stream

Mit 0.7.0 bekommt die Software Factory drei ausstehende Bausteine aus dem Sicherheits- und Wiederverwendungs-Block: ein wiederverwendbares Run-Template, eine optionale Container-Sandbox pro Run und ein echter Live-Stream der Token-Verbräuche statt End- Sammlung.

Run-Templates (Phase 7.5)

• Aus einem abgeschlossenen Run lässt sich ein RunTemplate speichern (Adapter, Team, Ziel). Im nächsten Quick-Start ist es der bevorzugte Vorschlag — spart Klickwege bei wiederkehrenden Aufträgen.
• Templates haben pro Ersteller und optionalem Projekt-Scope eigene Liste. Beim Anwenden wird ein neuer Run mit den Template-Werten vorbelegt; sie sind nicht an einen Run hart gebunden — wird ein Projekt gelöscht, bleibt das Template als Schablone erhalten.
• Audit: jeder Template-Wechsel landet als RUN_TEMPLATE_CREATED/UPDATED/DELETED im Audit-Log. Browser-Notifications und Inline-Diffs sind bewusst in eine spätere Iteration vertagt.

Container-Sandbox pro Run (Phase 8, ADR-0011 B)

• Neue ContainerProcessSandbox startet jeden Agent-Subprozess in einem ephemerem Docker- oder Podman-Container mit harten Limits: --cpus 2, --memory 4g, --pids-limit 512, --read-only Root + /tmp als tmpfs, --network=none als Default.
• Workspace wird per Bindmount auf /workspace verfügbar gemacht — alles andere bleibt unsichtbar. Das ist die Antwort auf die Frage "läuft der Agent auf meinem Filesystem?".
• Auswahl per Setting execution.sandbox.variant=container; fehlt Docker im PATH, fällt die Plattform mit Log-Warnung auf die bisherige LocalProcessSandbox zurück. Single-Tenant-Hosts merken nichts; Enterprise-Tier kann ohne Code-Änderung umschalten.

Live-Token-Stream + lokale Schätzung (Phase 9, ADR-0013)

• Neuer ClaudeStreamJsonParser liest --output-format=stream-json zeilenweise und emittiert pro Event ein typisiertes ExecutionEvent.Usage mit Input-, Output- und Cached-Tokens plus Modell-ID und Request-ID. Der Logviewer sieht damit Token-Verbräuche live statt erst nach Run-Ende.
• TokenEstimator (mit com.knuddels:jtokkit:1.1.0) liefert lokale Token-Schätzungen vor Run-Start — Wizard Schritt 4 kann Kosten vorhersagen, ohne Vendor-Call.
• Wir übernehmen die Konzepte als Eigenimplementation, ohne harte Library-Dependency auf claudecode4j (Single-Maintainer-Risiko zu hoch) — Details in ADR-0013.

Begleitend

• 970+ Tests grün, JaCoCo-Schwellen 80 % Line / 80 % Branch durchgehend gehalten.
• ADR-0011 (agent-sandbox) von Proposed auf Accepted gesetzt; ADR-0013 (claudecode4j-konzept-uebernahme) neu.
• Demo unter demo.softwarefabrik.io läuft mit v0.7.0.

Conductor: Modell-Routing, Plugin-Sync und Repo-Import

Mit 0.6.0 hört die Software Factory auf, ein Wrapper um Claude Code zu sein, und beginnt, der Conductor des gesamten Setups zu werden. Drei Roadmap-Phasen liefern den Sprung: pro Agent-Rolle wird ein bevorzugtes Modell geroutet, lokal installierte Plugins und Skills werden vor jedem Run ins Workspace gemapped, und ein sechstes Wizard-Template übernimmt bestehende Repositories unter Plattform-Kontrolle.

Modell-Routing pro Agent-Rolle (Phase 5)

• Default-Mapping: Architect und Documentation nutzen claude-opus-4-7, Developer / QA / Merge-Release laufen auf claude-sonnet-4-6, Reviewer und Security-Reviewer ziehen claude-haiku-4-5. Spart Tokens, ohne Qualität bei strategischen Rollen zu opfern.
• Jede AgentDefinition hat jetzt ein preferredModel-Feld (Migration V14), das vom ClaudeCodeExecutionAdapter automatisch als --model-Flag durchgereicht wird. Tippfehler- IDs fallen auf den CLI-Default zurück — kein Build-Crash.
• Drift-Erkennung: wenn die CLI ein anderes Modell verwendet hat als angefordert (z. B. weil Subagent- Delegierung umgeleitet hat), erscheint eine Warnung im Log.

Plugin- und Skills-Sync (Phase 6)

• Neues Modul conductor: scannt ~/.claude/plugins/ und ~/.claude/skills/ beim ersten Aufruf, cached die Ergebnisse, bietet manuellen Refresh. Inklusive Path-Traversal-Schutz gegen Symlinks, die nach außen zeigen.
• Vor jedem Run schreibt die Plattform .claude/settings.local.json ins Workspace (Plugin-Whitelist + Skills-Pfad). Claude Code respektiert Workspace-Settings automatisch.
• Pro aktivem Team-Mitglied entsteht eine .claude/agents/<rolle>.md mit YAML-Frontmatter (name, description, model, role). Subagents sind damit CLI-nativ delegierbar.

Repo-Import-Template (Phase 7, teilweise)

• Sechstes Wizard-Template existing-repo-import: statt ein neues Skeleton anzulegen, weist es Claude Code an, ein bereits vorhandenes Repo zu inspizieren und einen IMPORT_REPORT.md zu schreiben (Markdowns lesen, Build-Config scannen, Verzeichnis-Überblick). Kein Code wird vor dem Review angetastet.
• Felder: Pfad zum Repository, primäre Sprache (9 Optionen), Build-Tool (9 Optionen), aktueller Stand, nächste Schritte. Initial-Prompt liegt in DE und EN auf dem Classpath.

Project-Memory via PROJECT_NOTES.md (Phase 7, teilweise)

Das freeText-Feld der ProjectDefinition wird beim Run-Start automatisch als PROJECT_NOTES.md in den Workspace-Root geschrieben. Der Coding-Agent findet die Datei im Repo und nutzt sie als zusätzlichen Kontext — eine unter Nutzer-Kontrolle stehende Memory-Schicht, die zwischen Runs persistiert.

Bewusst nicht in dieser Version

Aus Phase 7 fehlen noch: RunTemplate-Entity ("Letzten erfolgreichen Run als Vorlage speichern"), Browser-Notifications nach Run-Abschluss, und Inline-Diffs vor Approval. Diese kommen in einer Folge-Iteration (Phase 7.5), bauen aber auf der jetzt gelieferten Conductor- Infrastruktur auf.

Begleitend

• 900+ Tests grün, JaCoCo-Schwellen 80 % Line / 80 % Branch durchgehend gehalten.
• Neuer Datei-Output unter .trivyignore mit fünf bewusst akzeptierten Go-stdlib-CVEs im eclipse-temurin:25-jre-Base-Image (Container-Helper-Binaries, nicht der Java-Code).
• Demo unter demo.softwarefabrik.io läuft mit v0.6.0.

Polyglot: der Wizard deckt jetzt fünf Stacks ab

Mit 0.5.0 wird die Software Factory mehrsprachig. Der Projekt-Assistent bot bisher zwei Templates an: Spring Boot Backend und Static Frontend. Drei polyglotte Templates kommen dazu — damit deckt die Plattform die häufigsten Backend-Stacks der Solo-Entwickler ab.

Drei neue Templates

• ASP.NET Core Backend (.NET) — wählbare .NET-Version (8 oder 9), Projekt-Variante (WebAPI / MVC / Worker Service), Datenbank über EF Core (PostgreSQL oder SQL Server) oder Dapper, Architektur-Stil Clean Architecture, Layered oder Vertical Slice, konfigurierbarer Root-Namespace.
• Python-Backend (FastAPI / Flask) — Python 3.12 oder 3.13, Web-Framework FastAPI oder Flask, Datenbank-Treiber SQLAlchemy mit PostgreSQL oder SQLite, Package-Manager-Wahl zwischen uv, pip und poetry.
• Node.js Backend (Express / Fastify / Hono) — Node 20 oder 22, drei Framework-Optionen, ORM Prisma oder Drizzle (oder keine), Sprache TypeScript oder JavaScript, Package-Manager pnpm / npm / yarn.

Zehn neue Quality-Gate-Toggles

• .NET: Roslyn-Analyzers mit TreatWarningsAsErrors, SonarAnalyzer.CSharp als zusätzliches Regelwerk, NuGetAudit für Vulnerability-Scan im dotnet restore.
• Python: Ruff als All-in-one Linter und Formatter, mypy im Strict-Mode, pytest-cov mit hartem Coverage-Gate (--cov-fail-under=80), Bandit als Security-Linter mit optionalem SARIF-Upload.
• Node: ESLint in der Flat-Config-Form (ESLint 9+), Vitest als Test-Runner mit v8-Coverage, npm-audit-signatures für Sigstore-Provenance.

Trivy für alle

Der Trivy-Container-Scan-Toggle deckt jetzt alle fünf Templates ab — egal ob du eine Java-, .NET-, Python- oder Node-Anwendung baust, das fertige Container-Image kann auf bekannte CVEs gescannt werden.

Versions-Cache erweitert

Elf neue Cache-Keys: ESLint, Vitest und Node-LTS werden über npm- und GitHub-Releases-API täglich aktualisiert; .NET-, Python- und die Tool-Versionen sind statisch im Code-Katalog gepflegt und werden mit Releases der Plattform angehoben. Die Admin-Inspect-Seite unter /einstellungen/wizard/versions zeigt jetzt 16 Einträge statt fünf.

Was bewusst nicht in dieser Version steckt

Go, Rust, PHP und Ruby fehlen — wir warten auf konkrete Nutzer-Nachfrage, bevor wir weitere Templates pflegen. Die Architektur ist trivial erweiterbar: neue Templates kommen über zusätzliche Code-as-Data-Einträge im TemplateRegistry plus jeweils sechs Markdown-Files (Initial-Prompt DE/EN, drei bis fünf Toggle-Snippets je DE/EN). Keine Migration, keine Schema-Änderung. Sag Bescheid, welcher Stack als nächstes kommen soll.

Begleitend

• 841 Tests grün, JaCoCo-Schwellen 80 % Line / 80 % Branch durchgehend gehalten.
• Roadmap-Doku docs/roadmap/projekt-wizard.md aktualisiert: Toggle-Katalog von 4 auf 14 Toggles, drei zusätzliche Template-Steckbriefe.
• Demo-Instanz unter demo.softwarefabrik.io läuft mit v0.5.0 — direkt durchklickbar, kein Login.

Settings, Wizard, Quality Gates: aus Cockpit wird geführte Plattform

Die 0.4.0 hebt die Plattform vom „Selber-konfigurieren" in einen geführten Modus: globale Defaults haben einen eigenen Bereich, ein vier-Schritt-Assistent legt neue Projekte mit passendem Stack und aktivierbaren Quality-Gates an, und ein täglicher Hintergrund-Job haelt die „neuste stabile Version" pro Komponente vor.

Globale Settings-UI

• Neuer Bereich /einstellungen (nur ADMIN) mit Sektionen Workspace, Adapter, Modelle pro Adapter (claude / codex / gemini / aider) und Token-Budget-Caps (Tag / Woche).
• Override-Logik PROJECT > USER > GLOBAL > YAML über den neuen SettingService; Konsumenten lesen nicht mehr direkt aus application.yml, sondern über den Service. Änderungen wirken ohne Restart (5-min-Cache).
• Quick-Start-Knopf in der Run-Liste startet einen Run aus dem Setup des zuletzt erfolgreichen Runs in unter drei Klicks.
• Audit-Log für jede Setting-Änderung; Flyway V9 (app_setting).

Vier-Schritt-Projekt-Wizard

• Neuer Pfad /wizard: Template-Auswahl → template-spezifische Fragen → Quality-Gate-Toggles → Zusammenfassung. Am Ende landet alles im normalen Projekt-Editor mit vorbelegten Feldern.
• Drafts überleben Browser-Reload und App-Restart; „Entwurf fortsetzen" ist auf der Eintrittsseite verfügbar. Tageskleaner löscht offene Drafts > 30 Tage.
• Zwei initiale Templates: Modernes Spring Boot Backend (Java-Version, DB, Architektur-Stil, Package-Base) und Statisches Frontend (Node.js-Version, Vite / Astro / plain HTML).
• Initial-Prompts in DE und EN auf dem Classpath, Placeholder werden serverseitig ersetzt.
• /projects/new bleibt als „Schnell anlegen"-Pfad für erfahrene User erhalten.

Quality-Gate-Toggles

• ArchUnit-Schichtentests, OWASP Dependency-Check, Trivy Container-Scan und Playwright E2E-Tests – aktivierbar im Wizard, gefiltert nach Template (Playwright erscheint nur bei Templates mit Web-UI).
• Markdown-Snippets in DE und EN unter wizard/snippets/<lang>/<id>.md; werden an den Initial-Prompt für den Coding-Agent angehängt.
• Versionen der Tools (ArchUnit, OWASP-Plugin, Trivy CLI, @playwright/test) werden serverseitig aus dem Versions-Cache eingesetzt – Snippets sind nicht mit veralteten Werten gepinnt.

Versions-Cache mit Hintergrund-Refresh

• Täglicher @Scheduled-Job (03:00 Server-Zeit) holt „neuste stabile Version" pro Komponente aus Maven Central, GitHub Releases und der npm Registry.
• Java-berechnete Staleness (kein Postgres-spezifisches Computed-Column, damit das H2-Test-Profil nicht bricht). Stale-Badge im Wizard und auf der Admin- Inspect-Seite ab 25 h Alter.
• Admin-Inspect-Seite unter /einstellungen/wizard/versions mit Tabelle, letztem Refresh-Zeitstempel, Fehler-Spalte und manuellem Refresh-Button.
• Flyway V12 (wizard_draft) und V13 (version_cache).

Sicherheit

• pgJDBC auf 42.7.11 gepinnt – behebt CVE-2026-42198 (HIGH, pgjdbc Client-side Denial of Service). Trivy-Image-Scan ist nach dem Bump wieder ohne HIGH/CRITICAL-Findings.
• docker-compose.yml bindet Postgres jetzt explizit auf 127.0.0.1:5432 statt 0.0.0.0:5432. Verhindert, dass das DB-Passwort an jedes Netzwerk mit TCP-Routing zum Host exponiert wird.

Drumherum

• 17 statische Seiten haben jetzt rel="canonical" plus hreflang-Alternates – Suchmaschinen können die DE/EN-Variante eindeutig zuordnen, www-/non-www-Duplikate verschwinden.
• Impressum erweitert um „Über mich"-Sektion mit Verlinkung auf janda.io und Umsatzsteuer-Identifikationsnummer.
• 810 + Tests gruen, JaCoCo-Schwellen 80 % Line / 80 % Branch durchgehend gehalten.

Token, Kosten, Live-Logs: aus Black-Box wird Cockpit

Die 0.3.0 ist ein Sprung beim Frontend: das Dashboard zeigt jetzt Token- und Kostenkurven der letzten 14 Tage, eine eigene Analytics-Seite trennt Tokens, Kosten, Budget und Adapter-Vergleich, Logs strömen live per Server-Sent-Events in den Browser, und Runs lassen sich pausieren, fortsetzen oder im Batch abbrechen.

Token- und Kosten-Schema

• Run-Metrics aggregieren pro Run Input-, Output- und Cached-Tokens, Dauer in Millisekunden, EUR-Kosten und Phasenstatus. Migration V7 legt die Tabelle und Token-Spalten in execution_log an.
• Modell-Preistabelle in application.yml (Input/Output/Cached pro 1 M Tokens) – aus der offiziellen Preisseite gepflegt für gpt-5.4-mini, gpt-5-mini, claude-sonnet-4-6, claude-opus-4-7 und claude-haiku-4-5.
• Claude-Code-Adapter ruft die CLI mit --output-format=json und parst Token-Verbrauch und Modell-ID aus dem Result-Payload.
• Mock-Adapter meldet deterministische Pseudo- Tokens (abgeleitet aus den Markdown-Längen) – Dashboard und Analytics zeigen sinnvolle Werte auch ohne echten Vendor-Run.

Dashboard-Upgrade und Dark-Mode

• Neue Widgets: Erfolgsquote, Ø Run-Dauer, 14-Tage-Kostensumme, Token-Verbrauch (Input/Output split) als SVG-Bar-Chart, EUR-Kostenkurve.
• Dark-Mode mit Sun/Moon-Toggle im Header, persistiert in localStorage; bewusste Nutzerwahl statt automatischem prefers-color-scheme.
• CSS-only Tooltips auf den Kennzahl-Kacheln, Skeleton-Klasse für nachladende Listen (mit prefers-reduced-motion), Hamburger-Menu unter 720 px.

Analytics-Seite mit Budget-Enforcement

• Neuer Menüpunkt /analytics mit vier Tabs: Token-Verbrauch (Input/Output/Cached gestapelt), Kosten (Tageskurve plus Aufschlüsselung pro Modell-ID), Budget (Monatsbudget pro Projekt verwalten) und Adapter-Vergleich (Runs/Tokens/Kosten/Erfolgsquote pro Adapter).
• CSV-Export pro Tab, RFC-4180-konform.
• Monatsbudget pro Projekt (Migration V8): Soft-Schwelle (default 80 %) plus optionaler harter Block-Modus, der neue Run-Anlagen bei > 100 % Auslastung mit klarer Fehlermeldung verhindert.

Live-Logs und Run-Kontrolle

• SSE-Endpoint /runs/<id>/logs/stream: Logs erscheinen live ohne Reload, Heartbeat alle 20 s, Auto- Reconnect nach 5 s bei Verbindungsverlust, Auto-Scroll-Toggle.
• Pause / Resume: neuer Status PAUSED, kontextsensitive Buttons in der Run-Detail- Ansicht (nur sichtbar bei passendem Status).
• Batch-Cancel: Checkboxen auf der Run-Liste plus „Ausgewählte abbrechen" – bereits terminale Runs werden ohne Fehler übersprungen.

Bewusst nicht enthalten

Aus der Phase-3-Roadmap fehlen noch: Gantt-Phasen-Timeline, Phase-Rollback, Kontext-Inject in laufende Runs und der Pre-Run-Dry-Run-Modus. Sie folgen in einer späteren Iteration – das aktuelle Release liefert den Cockpit-Sprung, ohne neue Adapter-Risiken einzuführen.

Begleitend

• Neues Runbook docs/runbooks/deploy-demo.md mit atomischem JAR-Tausch und Rollback-Pfad für demo.softwarefabrik.io.
• 628 Tests grün, JaCoCo-Schwellen 80 % Line / 80 % Branch / 80 % Instruction durchgehend gehalten.

Review-Schicht und Quality-Gate: aus „schreibt Code" wird „prüft Code"

Die 0.2.5 bringt die zweite Säule der Plattform: neben den ausführenden Agenten (Claude Code, Codex, Gemini, Aider) gibt es jetzt eine eigene read-only Review-Schicht mit aggregierendem Quality-Gate. Wer schreibt, wird geprüft – sauber getrennt im Klassenpfad und in der Verantwortung.

Neu in dieser Version

• Read-only-Reviewer: aider-review und claude-review rufen die jeweilige CLI im read-only-Modus auf; security, architecture-reviewer und hallucination-review arbeiten als statische Heuristiken ohne externes Tool.
• Quality-Gate mit konfigurierbarer Policy (strict/lenient): aggregiert Reviewer-Findings zu einer Entscheidung (PASSED / WARNING / FAILED / SKIPPED / ERROR), inklusive Confidence-Score-Aggregation.
• Sonderregeln unabhängig von der Policy: SECURITY/HIGH und ARCHITECTURE/CRITICAL sind immer blockierend; Reviewer-Crashes werden als ERROR materialisiert, nicht verschluckt.
• Quality-Gate-UI unter /runs/<id>/quality-gate mit Reviewer-Auswahl, Policy-Wahl und Ergebnisansicht (blockierend / nicht-blockierend, Confidence, Reviewer-Schritte).
• Dashboard-Charts: Run-Aktivität der letzten 14 Tage als Inline-SVG-Bar-Chart, Projekt- und Run-Status-Verteilungen als horizontale Balken – komplett serverseitig, ohne JavaScript.
• Demo-Profil für demo.softwarefabrik.io: Auto-Login als demo-User, Demo-Hinweis im Header, tägliches DB-Reset per Cron empfohlen.

Bewusst nicht enthalten

Continue (continue.dev) ist nicht integriert – die Begründung steht in docs/review-and-quality-gate.md. Kurz: Continue hat keinen stabilen non-interaktiven CLI-Modus, der sich aus einer Server-App im read-only-Betrieb verlässlich aufrufen ließe.

Begleitend

• Neue Doku-Kapitel docs/review-and-quality-gate.md und Runbook docs/runbooks/demo-instanz.md.
• Vorbereitetes Word-Supplement docs/word-supplement-v1.4.md für die nächste Version des Konzeptpapiers.
• Versionssprung auf 0.2.5 – sichtbar im Footer der Plattform und unter /changelog.

Vier Adapter statt einem: Codex, Gemini und Aider sind dazugekommen

Bislang war die Softwarefabrik fest auf Claude Code als ausführenden Entwicklungsagenten ausgerichtet. Mit der neuen Adapter-Registry kann jetzt pro Run gewählt werden, welcher Agent die Arbeit erledigt – und es stehen gleich drei weitere Vendor-Adapter zur Verfügung.

Was sich geändert hat

• Adapter-Registry: alle Adapter leben gleichzeitig im Backend. Der konkrete Adapter wird im Run-Wizard ausgewählt und auf dem Run persistiert.
• OpenAI Codex (codex exec): OpenAIs offene Terminal-CLI, vergleichbar mit Claude Code.
• Google Gemini (gemini -p): Googles offene Terminal-CLI, mit großzügigem Free-Tier per Google-Login.
• Aider: ausgereifter Open-Source-Agent mit konfigurierbarem Modell-Backend (Anthropic / OpenAI / Gemini / lokal via Ollama).
• Mock bleibt der DEMO-Default – ohne Lizenz, ohne externe Tools, immer verfügbar.

Lizenzlage

Alle Vendor-Adapter sind ab Community aktiv. Das Mock-Adapter bleibt im DEMO-Modus die alleinige Option, damit die Plattform direkt nach dem Download ohne Anmeldung lauffähig ist.

Begleitend

• Neue UI-Seite /changelog in der Anwendung mit voller Versionshistorie.
• Aktuelle Version sichtbar im Footer der Plattform mit Link zur Historie.
• DB-Migration V3 erweitert die Run-Tabelle um die Adapter-ID.

Erste produktiv lauffähige Version

Die Agentic Software Factory startet als lokale Control Plane für AI-gestützte Softwareentwicklung – mit Claude Code als initialem Entwicklungsagenten, Lease-basiertem Lizenz-Stack (Keycloak + Spring-Boot-License-Service, RS256 JWT) und barrierearmer Thymeleaf-UI.

• Projektidee-Wizard mit Markdown-Generator (PROJECT.md, INSTRUCTIONS.md, AGENTS.md, ...).
• Run-Lebenszyklus mit Phasen, Status und Audit-Log.
• Workspace-Anlage mit Git-Init und Build-Gate (mvn verify).
• Approval-Policies, Spring-Security-Login, Bootstrap-Admin.
• Air-Gap-fähiges Lease-System mit COMMUNITY/PROFESSIONAL/ENTERPRISE.