What has changed at the factory.

What happens after delivery — half of it, at least

One of the four measurement gaps was called „escaped defects and rollbacks“, on the grounds that the factory ends at the merge and never learns what comes after. For the rollback half that is not true. A git revert sits in the very history the factory has in front of it again on the next run. What was missing was the anchor — the merge commit a revert can refer to.

The factory now records it, and on the next run it looks up what became of the last one. The overview shows a rollback rate.

Why this is not a defect metric

What is measured is the revert, not the defect. A revert commit is a fact in the history. „A later commit touched the same file“ would be a guess — it may just as well be the next feature. Only the first half of the old gap therefore remains: escaped defects. Doing that properly would need an issue-tracker integration, which does not exist.

The rate is a lower bound, and it says so. Anyone who applies a change in reverse by hand and commits without the revert line will not show up. There is a dedicated test for that — as a recorded limit, not a bug. A number that presents itself as complete would be worse here than one that names its boundary.

Only checkable deliveries are in the denominator. A merge without a recorded commit cannot be looked up; counting it as „not rolled back“ would mean improving the rate through missing data.

Three of the original four gaps remain open: human active working time, escaped defects, and the comparison against manual implementation.

One of the four gaps is a gap no longer

The last release listed four metrics as named gaps beside the numbers. One of them was the change in test coverage, and the reason given was: what gets stored is a summary of the build output, not a coverage figure.

That was true — but it was not a reason, it was a missing line. The coverage report is already sitting in the workspace; it only had to be read, rather than guessed from log lines. The factory now does that after every build, in three formats — JaCoCo for Java, Cobertura for .NET and Python, Istanbul for Node. The order is fixed, so the metric does not depend on which file the filesystem happens to name first.

Three decisions worth seeing

No report does not mean zero percent. The columns are deliberately nullable. A project without a coverage report does not have 0 % coverage — it is simply unknown. A default of 0 would have written exactly the confusion into the schema that these metrics otherwise set out to avoid.

The change is in percentage points, not percent. From 80 % to 84 % is four percentage points and five percent — conflating the two turns a small improvement into a large one. And it appears only from the second measurement onwards: a change against nothing is not a change.

The report is read without an XML parser. It comes from agent-generated code and is therefore untrusted. A parser would be an attack surface right in the input path; the values needed can be read without one.

Three gaps remain: human active working time, escaped defects and rollbacks, and the comparison against manual implementation. They still stand there as gaps, not as numbers.

Metrics — and the four questions we don't answer

The factory now measures what it does: how long a piece of work took to complete, how many tasks passed their quality gate on the first attempt, how often things were corrected and replanned, what a piece of work and a single run cost, and how often merges ran into conflicts — broken down by conflict kind.

None of it is recorded separately. Every value is derived from data that arises anyway. A metric kept in its own table drifts sooner or later from what it is meant to describe.

What's missing is the more interesting part

The roadmap names nine metrics. Four of them the platform cannot answer honestly — and they now sit as named gaps next to the numbers, not in the small print:

• Human active working time. The platform sees how long something waited — not whether anyone worked on it. Equating the two would be the most elegant way to fool yourself. Waiting time is therefore reported separately and under a different name.
• Test coverage change. What's stored is a summary of the build output, not a coverage figure.
• Escaped defects and rollbacks. That needs feedback from operations after delivery — the platform ends at the merge.
• Comparison with manual implementation. That reference group doesn't exist in the system. A comparison would be a claim about work that never happened here.

A metric that is named differently from what it measures is worse than a missing one — it gets believed.

For the same reason the overview shows a dash where others would show a zero: a piece of work without a single merge doesn't have a 0 % conflict rate — it has none at all. Equating the two reads a good result out of an empty sample.

Work that carries on by itself — and a failure that doesn't stay silent

Until now parallel tasks only started at the push of a button. When a task became eligible because its predecessor finished, nothing happened until someone clicked again. And on an application restart, nobody picked up the work in flight.

• Every instance registers and sends a heartbeat. Without it, „crashed“ cannot be told apart from „busy“ — and without that distinction, releasing a stuck task would be guesswork with the risk of two processes touching the same one.
• Claim before side effect. A task is claimed before working directory and run come into existence. Two processes cannot both win.
• A failure never produces silent success. If the task hadn't started, nothing happened — it is handed out again. If it was already running, it counts as failed: the working directory may be in an unknown state, and silently repeating it is exactly what the platform is meant to prevent. The way back leads through the justified replanning introduced in v0.24.
• Automatic dispatch — off by default. Starting runs on its own costs tokens; you switch that on deliberately.

What we did not build: operation across several machines. The roadmap ties it to a condition — measurable demand — and that is not met. A pool across several hosts would put credentials and file access on further machines: attack surface for a load that doesn't exist yet. The coordination layer is the prerequisite for it and useful in its own right until then.

„Merge conflict“ is not a diagnosis

Two competing migration numbers, a dependency added twice, and a genuine logical contradiction all look the same to Git — yet they demand completely different responses. As long as a platform doesn't tell them apart, it can neither escalate sensibly nor resolve them automatically later. An agent that only hears „resolve the conflict“ is guessing.

• Seven conflict kinds, checked from the most expensive to the most harmless. A migration collision that happens to include a formatting conflict stays a migration collision — the reverse classification would invite overwriting.
• Analysis without side effects. The merge is computed in the object store without touching the working directory. It has to keep a defined state throughout — otherwise nobody could say afterwards which one applies.
• Rebase only where it helps. A rebase removes conflicts that arise because a branch is old. With a genuine contradiction it merely postpones them — so it is not even attempted there, although it would technically run. An attempt without new information is the blind retry the platform has forbidden since v0.24.
• Escalation with full context. Whoever has to decide a conflict didn't follow the process. Instead of „conflict in 3 files“, the report names branch, task, conflict kind, what was already tried, why the rebase didn't help, the contract revisions involved and the consequence of each decision.

One limit we name deliberately: two branches adding V99__a.sql and V99__b.sql merge cleanly — different filenames. That is exactly what makes number collisions treacherous: they only surface at deploy time. The classification only applies when Git reports a conflict at all.

Also: the chat assistant spoke German on the English pages and stayed dark in light mode. Both fixed — it now follows the page's language and colour mode.

An AI chatbot on this site — and plans that explain themselves

New on softwarefabrik.io: there is now an AI assistant in the bottom right. It answers questions about the platform from the public website content and the project documentation — architecture, security, operations, change history. It deliberately does not know the operations runbooks, the security reviews or the roadmap: a bot that quotes from a planning document turns it into a promise for the reader.

The widget loads a script from the provider TrustChat on every page view and transmits your IP address in the process — even if you never open the chat. The privacy policy covers this in section 6.

Under the hood: plans that explain themselves

Since v0.21 a piece of work splits into tasks that run in parallel. What happens when the ground shifts while they work? Until now you could simply restart a task. v0.24 forbids that.

• No blind retry. A repeat run is only permitted when there is new input: a changed contract revision, a merge conflict, a red build, a reviewer finding. Reordering or re-cutting a task explicitly does not count — that rearranges work but gives the agent nothing it didn't have last time. Repetition without new information only costs tokens and produces the same result.
• Every plan change is justified, not merely counted. The version number says which plan applies. What gets asked is why this one — usually weeks later, when nobody remembers. So the justification is mandatory, and the change is attested via the signed audit chain.
• Tasks can be split and merged. When splitting, the parts do not inherit the write areas — if they all inherited the same ones they could never run in parallel, and splitting would be pointless.
• The why-trace shows the plan history, not just the current number.

Contracts: what an agent worked against — and what that breaks

v0.22 let several agents write in parallel. That leaves one class of failure no single check finds: a contract break sits between two components, not inside one. The provider's build is green, the consumer's is too — only together do they break. v0.23 therefore makes the shared ground explicit.

• Contracts are versioned and immutable. Every revision has a number and a content hash. If a revision could be altered afterwards, a run's proof would point at content that might since have become something else — the proof would be worthless.
• Every run proves what it worked against. The binding is fixed at start, not at planning time: when planning, it isn't settled when the task will run, so an earlier binding would be a bet.
• A new revision devalues work in progress — visibly. Anything bound to a superseded revision is marked stale and can no longer be merged. The check runs twice: before queueing and before merging, because a contract can change while an entry waits in the queue.
• Breaks are named, not prevented. Removed paths, operations, fields and schemas are detected — and newly required fields, because formally that only "tightens" things while existing callers actually break. It still doesn't block: a breaking change is sometimes exactly the goal. Blocking would turn the registry into a bottleneck and push people to work around it.
• Unchanged content creates no new version. Not an optimisation but a rule — a save click without a change must not devalue work in progress.

v0.23.1 fixes a startup failure in the first revision: a column was declared CHAR instead of VARCHAR, which aborted schema validation against PostgreSQL. It only surfaced at deploy time — the test suite runs against H2 and creates the schema itself, so it never checks the migration against the mapping. The boot smoke against real PostgreSQL is the only stage that catches this class of error.

Plus a consistency pass over docs and website: several pages carried current version numbers above outdated content — the architecture page listed 21 instead of 29 modules, and the limitations page still claimed parallel execution was deferred. Both fixed.

Writing in parallel — and then proving it fits together

v0.21 let several agents analyse. v0.22 lets them change code. That is the harder half: two agents writing at the same time produce results nobody can attribute any more. The answer comes in two parts — an ownership rule before, and a verification after.

• Ownership instead of trust. Every writing task declares its write areas. If they overlap with those of a running task, it never starts. The check happens before execution, not after — an agent that works first and is cancelled afterwards has cost money and delivered nothing.
• Build configuration and migrations are always exclusive, even when not declared. Two concurrent changes there almost certainly collide — think of two agents assigning the same migration number.
• Ownership claims expire. A crashed agent process would otherwise block the workflow permanently. Leases have a lifetime and a heartbeat; orphaned ones are detected and released.
• Merges run sequentially, in plan order. Each merge changes the state the next one merges against — and that order must not depend on who happened to finish first, or the result is not reproducible.
• A second gate above the whole. The per-run gate checks a change on its own. Only the integration gate checks whether they work together — three individually green changes can break jointly. A workflow counts as complete only via that verdict.
• A merge conflict pauses, it does not fail. It is not a technical error but a decision: retry or discard the branch. A discarded branch turns the gate red — a workflow whose work was partly left behind does not count as successful.

This layer too stays off behind the feature flag. Conflict resolution is deliberately still human — an agent that reconciles the branch itself comes later.

Parallel agent runs: the workflow layer

Until now exactly one agent ran per project. v0.21 introduces a layer above: a piece of work splits into tasks with dependencies, several analysis runs execute in parallel, and a synthesis step brings them together.

• One writer per working directory. Parallelism comes from more worktrees, not more agents in the same directory. Only that keeps every change attributable to exactly one run — the prerequisite for why-trace and attestation.
• Synthesis must not smooth things over. Its brief explicitly demands contradictions between the analyses and attributes them to their sources. A harmonising summary would destroy the very reason for running several independent analyses.
• Budgets bite beforehand. The cap is checked before the next run starts, not afterwards on the invoice.
• Plan approval stays with a human. Agents plan, but no run starts without consent.

The layer is off by default. Without the feature flag the platform behaves exactly as before — one run per project.

Kimi adapter, build number, docs sweep — and a scan that finally ran

v0.20 adds a tenth execution adapter, makes every running instance traceable to a specific change, and cleans up the documentation. The most instructive part was a defect in our own pipeline:

• Kimi adapter (Moonshot AI): the tenth adapter, with both authentication paths — API key via the Moonshot Open Platform or subscription via a “Kimi for Coding” membership. In subscription mode the factory actively strips the key variables so the CLI cannot silently take the paid path.
• Build number in the UI: the PR number and short commit now sit next to the version — every running instance is traceable to a specific change.
• The dependency scan was running without an API key. The repository secret was set but only used as a guard, never passed to Maven. The scan therefore ran unauthenticated against the public feed and never completed properly — invisible, because the job is configured as advisory. Fixed. The first complete run promptly reported three CVEs: two are fixed (jackson-databind, log4j-api), one has no upstream fix and is documented with an expiry date — see Known Limitations.
• Documentation brought current: manuals from 0.12 to 0.20, a new administration manual covering tenants, RBAC, policy-as-code, compliance profiles and attestation, plus corrected figures across the feature pages.
• UI fixes: the team view shows agent names instead of raw UUIDs, the agent overview gained a short description, and there is a new view for an agent's team memberships.

Vendor-neutral guardrails, skill library, routines & more

After analysing the open-source project Paperclip AI, v0.19 adopts four building blocks — plus a model-independent behavioural policy:

• Engineering Guardrails: a vendor-neutral policy (correctness & reviewability over speed) flows into the context of every coding agent (Claude, Codex, Gemini, local models) on every run and is projected into the repo as a canonical AGENTS.md.
• Skill library: tenant-scoped, versioned, signed — catalog → install/fork, instead of a filesystem scan.
• Routines: scheduled/recurring runs via cron (nightly dependency scan, weekly docs refresh).
• Segregation of duties (approver ≠ author) and cost attribution per provider in analytics.

Security patch: hardening the repo/remote coupling

An adversarial re-review of v0.18 found three findings in the new remote-sync layer — all closed:

• Remote URL as a trust boundary: project remote URLs are now validated centrally (host allowlist, scheme whitelist) — the shared GitHub token never leaves for a foreign host.
• Hardened git transport: only the required protocols, no remote-helper abuse.
• Branch isolation: the merge-conflict correction stays strictly on the run branch.

Repo reality: PR/CI feedback, remote sync, multi-version

The iterative SDLC loop is coupled to the real world of the Git repo:

• PR/CI feedback: a build run now completes only once the pull request is merged and CI is green — a red CI automatically triggers a correction round.
• Remote sync & conflicts: the state is reconciled with the remote before each run; merge conflicts go into the correction loop instead of aborting.
• Multi-version: milestones group backlog items into iterations and release them (per-project changelog + Git tag + GitHub release); backlog items can depend on each other.

Security patch: governance hardening after internal re-review

An adversarial multi-agent re-review of v0.17 found four multi-tenant issues — all closed:

• Global policy floor: a tenant policy can now only tighten the operator baseline (EU AI Act / BAIT / VS-NfD), never weaken it.
• Operator surfaces sealed: tenant management and budget caps are consistently reserved for the platform operator.

Patch: Tomcat security update

Embedded Tomcat bumped to 11.0.23 (CVE-2026-55276, CVE-2026-53434, CVE-2026-53404 — rated low by Apache, patched immediately as a precaution).

Enterprise hardening: full tenant isolation, container sandbox for build & scans

v0.17 closes the hardening work packages deliberately left open after v0.16:

• Full tenant isolation: separate active governance policy per tenant, audit events attributed to their tenant as part of the signed hash chain, tenant-scoped database queries instead of in-memory filtering. Operator surfaces (attestation, costs, policy, export) show tenant users only their own view.
• Container sandbox for build & scans: the build of generated code and the trivy scans run in an ephemeral container when the container variant is active (read-only, resource limits, only the workspace mounted) — with real Docker isolation tests.
• Key rotation: Ed25519 signing keys are rotatable; old attestations remain verifiable via the key ring.
• Costs per user (seat): every run records the triggering user — consumption can now be evaluated per seat, in addition to the per-tenant view.

Patch: all findings of an adversarial multi-agent re-review fixed

An internal re-review of v0.16 (security + architecture with Opus 4.8, adversarially cross-checked) found five residual gaps — all closed in this patch:

• Validation approval enforced: regulated profiles (BAIT/MaRisk/DORA, BSI-VS-NfD) now actually stop before merge for four-eyes approval — previously signed but not enforced.
• Two IDOR write gaps closed: prompt artifacts and per-project budgets were writable via a foreign project ID; now tenant wall + role guard.
• Attestation integrity: the actually enforced policy version is attested at execution time; mandatory attestation forces real signing (no silent no-op) and a durable key.
• Fail-closed: ambiguous gate configuration blocks (instead of silently downgrading to advisory).

Security & honesty hardening before the test-user handover

Consolidation from an internal 5-pass review (security, architecture, docs, onboarding): governance is now actually enforced, authorization is sealed, and the limits are named honestly.

• Governance enforced: the active, signed policy-as-code makes gate strictness, mandatory approvals and mandatory attestation genuinely effective (strictest value wins) — compliance profiles like the EU AI Act now actually take effect instead of being decorative.
• Authorization & isolation: role-based protection on all write endpoints, closed IDOR gaps, OIDC login via a stable subject claim, operator surfaces shieldable against cross-tenant visibility.
• Audit hardening: a signed chain head detects truncation of the newest audit entries; the unsigned mode is clearly marked “not tamper-proof”.
• Honesty & onboarding: cloud gateways marked experimental, current model defaults (Opus 4.8 / Sonnet 5), single-seat default “manual approval before merge”, a mock-adapter hint and a new “Known Limitations” page.

From funnel to sovereign product: multi-tenancy, attestation & supply chain

The big enterprise/sovereignty expansion (roadmap P0–P4): team operation with hard tenant isolation, cryptographic provability of every AI-assisted decision, and supply-chain integrity for the generated code.

• Operating mode & model backends: single-seat subscription vs. team API pool; OpenAI-compatible adapter (vLLM/Ollama), gateways (Bedrock/Vertex/Azure) (experimental), enforced per-project model policy.
• Multi-tenancy & RBAC: hard tenant isolation, roles (Viewer→Admin), SSO federation (OIDC), per-tenant cost attribution + monthly budgets (foundations; full multi-tenancy still to come).
• Provenance & attestation: signed, tamper-evident audit hash chain (Ed25519), reproducible “why” trace per run, versioned + signed policy-as-code, compliance profiles (EU AI Act, BAIT/MaRisk/DORA, BSI/VS-NfD), regulator audit export.
• Supply-chain integrity: SBOM per build (CycloneDX), signed artifacts, dependency/license scan as a blocking gate output in the correction loop.

Branch & pull request, self-correction, quality gate & auto-loop

The SDLC loop becomes production-ready: every build run on its own branch, optional push + pull request to GitHub, automatic correction on a red build, and a quality gate in the pipeline.

• Branch per build run (sdlc/run-…): success → merge into base, failure → work stays isolated, base stays clean.
• Push + pull request (GitHub): with a project remote URL and a GitHub token, a successful build run opens a PR automatically.
• Automatic correction loop: on a red build the feedback is fed back and the build retried (bounded).
• Quality gate in the pipeline (off/advisory/blocking) and auto follow-up proposals that close the loop by themselves.
• Wizard: .NET 10 (LTS) as default (9/8 still selectable).

Iterative SDLC: persistent workspace, memory & roadmap plans

The factory becomes a lifecycle manager, not just a project starter: follow-up runs continue on the existing code, learn along the way and plan the next steps.

• Persistent workspace + re-run: a follow-up run builds on the previous run's code (instead of starting empty) — real development across versions.
• Real repo import: an existing repository (local path or Git URL) is adopted and then developed further through the factory.
• Project memory: curated learnings/decisions per project that flow in as MEMORY.md before each run and are learned back afterwards.
• Roadmap/plans as a backlog: a plan run proposes next steps as plans/*.md; in the backlog menu you activate a plan and a build run implements it on the existing code.

Quarkus backend & comprehensive user manual

The wizard now knows Quarkus as a backend, and there is an extensive user manual (EN + DE) for the single seat.

• Quarkus as a backend stack (Java) next to Spring Boot — Quarkus REST + Hibernate ORM Panache, Maven/Gradle, optional native image. Combinable with the Java frontends and the agnostic SPA/client frontends.
• User manual: single-seat setup (Claude plan / Codex plan / API keys), project definition with examples, the run lifecycle, and an honest assessment of what the factory does today for the wider SDLC (development across versions) — and what is still missing.
• Polish: proper umlauts in the German wizard UI; clean cache headers (no stale pages after updates).

Stack wizard (platform × backend × frontend) & Codex plan

Two big building blocks: the project wizard now combines stacks freely, and OpenAI Codex runs — like Claude — on your plan instead of an API key.

Project wizard: target platform × backend × frontend(s)

• Three orthogonal dimensions instead of a single template choice: first the target platform(s) Web/Mobile/Desktop (multi-select), then a backend (0..1), then frontend stacks (0..N). This expresses full-stack and multi-target products — one backend with a web frontend and a mobile app.
• Compatibility filter + coverage warning: server-rendered frontends are language-bound (Vaadin/Thymeleaf → Java, Blazor/WPF → .NET); SPA/mobile/desktop clients are runtime-agnostic via REST. If a platform has no frontend, you get a warning.
• Multi-part objective prompt: backend base + frontend bases + integration snippets (SPA REST, server-rendered, shared API contract, monorepo layout). Catalog: 17 templates, 12 frontends.

OpenAI Codex on a ChatGPT plan

• Codex plan mode mirroring the Claude plan: SOFTWAREFABRIK_CODEX_AUTH_MODE=subscription runs Codex via the ChatGPT Plus/Pro login (codex login); OPENAI_API_KEY is stripped from the subprocess in plan mode, CODEX_HOME set optionally. Switchable in the Settings UI.

Windows-native single-seat operation & boot hardening

The Claude plan mode now runs natively on Windows — without the WSL detour — plus two boot fixes and a new mandatory gate against startup regressions.

Claude plan native on Windows (no WSL)

• OS-aware env allowlist: on Windows, USERPROFILE, APPDATA, LOCALAPPDATA, SYSTEMROOT, COMSPEC, PATHEXT … are passed through and matched case-insensitively — otherwise claude wouldn't find its %USERPROFILE%\.claude. The ANTHROPIC_API_KEY stripping in plan mode is case-insensitive too. Unix/WSL behavior unchanged.
• OS-aware claude default: if claude.cmd is on PATH (npm installer) it is named explicitly; otherwise the bare claude stays, which Windows resolves to claude.exe itself. Explicitly configured commands are left untouched.
• Verified end-to-end on a real Windows 10 machine: native plan run via the Max subscription, a set dummy API key was correctly stripped.

Boot hardening & fixes

• Boot crash in all non-demo profiles fixed (local/container/prod): a disabled FilterRegistrationBean with a null filter crashed the Tomcat start since Spring Boot 4.0.7. The suppression bean is now bound to @Profile("demo").
• /teams/{id} 500 fixed: LazyInitializationException on team.members when rendering the detail page — members are now loaded via @EntityGraph.
• Boot smoke as a mandatory gate: a new CI job starts the app via docker compose in the container profile against real Postgres and waits for /actuator/health=UP — catching boot-time regressions that MOCK-based tests miss.

Single-seat license: 30-day lease with refresh

• Community lease raised from 7 to 30 days; best-effort lease refresh on every app start. If the license server is unreachable, the factory keeps running with the existing lease + 30 days grace — startup is not blocked. Air-gap mode unchanged.

Hardening & quality: coverage, ArchUnit, cleanup

0.9.1 is a pure quality release on top of 0.9.0 — no new features, but more safety through tests and a pinned-down architecture.

• More test coverage: a targeted issuer security test in LicenseVerifier (the issuer validation was previously untested) and testable CSV escaping in the analytics export. Branch coverage 0.815 against a ≥0.80 gate.
• Extended ArchUnit rules: hexagonal ports-and-adapters rules plus a freeze ratchet against module cycles and web→repository shortcuts — architecture violations break the CI run.
• Docs and DRY cleanup: package-info files, doc fixes and de-duplicated code.

Claude plan auth & Prometheus observability

Two improvements for nicer single-seat operation and better maintainability.

• Claude plan instead of API key: Coding runs can use your Claude Max/Pro subscription instead of a separate ANTHROPIC_API_KEY — toggle via SOFTWAREFABRIK_CLAUDECODE_AUTH_MODE=subscription. Full guide: Single seat with Claude plan. Bring-your-own-subscription for multiple Pro users is prepared.
• Prometheus metrics (observability level 1): Scrape endpoint /actuator/prometheus for JVM, HTTP and DB-pool metrics as a basis for Grafana & alerting. Restricted to ROLE_ADMIN, scraped via HTTP Basic, with a shared application label.

Both are test-covered and don't change existing API-key setups.

Wizard polish: stepper, objective preview, validation

Pure UX update for the project assistant. Four visible improvements lifting the wizard from "works" to "feels polished".

• Progress stepper: visual indicator 1→2→3→4 on top of every step; completed steps are links back.
• Objective preview in step 4: collapsible card with the fully composed initial-objective prompt.
• Server-side required-field validation: missing fields lead to a redirect with an error list, already entered values stay.
• Version cache empty state: "loading versions..." + link to the admin cache page, instead of a silently empty field.

Wizard cost estimate, inline diffs, browser notifications

Two deferred building blocks closed: the wizard shows roughly what a run will cost before it even starts, and the approval view shows a real diff of the workspace changes instead of "approve/reject" buttons.

Wizard step 4 — cost estimate (phase 4.5)

• WizardCostEstimator wires PromptComposer, the phase-9 TokenEstimator (JTokkit) and ModelPricingProperties. Local EUR estimate, no LLM call.
• Default claude-sonnet-4-6, output assumption 1.5x input. Unknown models show "no price table configured".

Inline diffs before approval (phase 7.5b)

• GitService.diffSeit() shells out git diff --no-color <sha> from the workspace, capped at 256 KB.
• At WAITING_FOR_APPROVAL the detail view embeds the diff since the earliest run checkpoint as a collapsible card.

Browser notifications (phase 7.5a)

• LogStreamService emits a status SSE event per poll cycle on status change.
• Notifications fire on COMPLETED, FAILED, TIMEOUT, CANCELLED, NEEDS_CORRECTION, WAITING_FOR_APPROVAL.

Run templates, container sandbox, live token stream

Three outstanding building blocks from the security and reuse track.

Run templates (phase 7.5)

• From a finished run you can save a RunTemplate (adapter, team, objective). It becomes the preferred suggestion on the next quick-start.
• Audit events RUN_TEMPLATE_CREATED/UPDATED/DELETED.

Container sandbox per run (phase 8, ADR-0011 B)

• ContainerProcessSandbox starts every agent in an ephemeral Docker/Podman container with --cpus 2 --memory 4g --pids-limit 512 --read-only --network=none.
• Workspace via bindmount to /workspace; everything else is invisible.
• Selection via setting execution.sandbox.variant=container; fallback to local with log warning if Docker is missing.

Live token stream + local estimation (phase 9, ADR-0013)

• ClaudeStreamJsonParser reads --output-format=stream-json line by line, emits a typed ExecutionEvent.Usage per event.
• TokenEstimator (with com.knuddels:jtokkit:1.1.0) provides local estimates before a run starts.

Conductor: model routing, plugin sync and repo import

The platform stops being a wrapper around Claude Code and becomes the conductor of the entire setup.

Per-role model routing (phase 5)

• Default mapping: Architect & Documentation → claude-opus-4-7; Developer/QA/Merge-Release → claude-sonnet-4-6; Reviewer/Security → claude-haiku-4-5.
• AgentDefinition gets a nullable preferredModel field (V14). The Claude Code adapter appends it as a --model flag. Drift detection emits an OUTPUT event on model mismatch.

Plugin and skills sync (phase 6)

• Module conductor scans ~/.claude/plugins/ and ~/.claude/skills/ with path-traversal guarding.
• Before every run the platform writes .claude/settings.local.json and .claude/agents/<role>.md per team member into the workspace.

Repo-import template (phase 7, partial)

• Sixth wizard template existing-repo-import: instead of bootstrapping a new skeleton it instructs Claude Code to inspect an existing repo and write an IMPORT_REPORT.md.

Project memory via PROJECT_NOTES.md

The freeText field of the ProjectDefinition is auto-written as PROJECT_NOTES.md into the workspace root at run start.

Polyglot: the wizard now covers five stacks

Three new wizard templates for the most common solo-dev backend stacks: dotnet-backend (ASP.NET Core), python-fastapi and node-express. Proof that the phase-4.5 architecture (templates as code-as-data plus snippets) really is extensible for further families.

Settings, wizard, version cache

Four major feature packs: Settings UI at /einstellungen, project assistant at /wizard with two templates, daily version cache from Maven Central / npm / GitHub, quick start in the run list. Plus pgJDBC 42.7.11 (CVE fix) and Postgres loopback pinning.

Tokens, costs, live logs: from black box to cockpit

A frontend leap: dashboard with 14-day token and cost charts, a dedicated analytics page (tokens, costs, budget, adapter comparison), live logs via Server-Sent Events plus pause/resume and batch cancel for runs. Includes a run-metrics schema (migration V7), a model price table, and a monthly budget per project with a soft threshold and an optional hard block (V8).

Review layer and quality gate: from "writes code" to "checks code"

The platform's second pillar: a read-only review layer with an aggregating quality gate. aider-review and claude-review run read-only; security, architecture-reviewer and hallucination-review run as static heuristics. Configurable policy (strict/lenient), special rules for SECURITY/HIGH and ARCHITECTURE/CRITICAL, a quality-gate UI, and a demo profile for demo.softwarefabrik.io.

Four adapters instead of one: Codex, Gemini and Aider have joined

New adapter registry: pick the agent per run. Adds OpenAI Codex (codex exec), Google Gemini (gemini -p) and Aider (configurable model backend). Mock stays the DEMO default — no license, no external tools. All vendor adapters are unlocked from Community upwards; a new /changelog page and an adapter-ID column on the run table (V3).

First production-capable release

Ships as a local control plane for AI-assisted software development — with Claude Code as the initial development agent, a lease-based licensing stack (Keycloak + Spring-Boot license service) and an accessibility-conscious Thymeleaf UI. Project-idea wizard with a Markdown generator, run lifecycle with phases and audit log, workspace bootstrap with git init and a build gate (mvn verify), approval policies, and an air-gap-capable lease system with COMMUNITY/PROFESSIONAL/ENTERPRISE tiers.