What has changed at the factory.

Honest messages around the project folder

Follow-up to the backup introduced in 0.52.5, found in an extensive hands-on test: “Erneut versuchen” (retry) turned a plan run into a build run — fixed. A subfolder containing its own Git repository made every run fail; the factory now skips such folders and names them. Your own changes to PROJECT_NOTES.md and to files under .claude/ are no longer lost silently: the factory saves them before rewriting and shows the command to get them back. The run page now shows what a run did not take over and how to retrieve it; the commands shown do exactly what the text next to them says.

Plan runs no longer delete your own work

If you changed something in the project folder while a plan or spec run was waiting for approval, you could lose those changes: the run cleaned the folder hard at the end. The factory now saves the state before the agent and restores it afterwards; only what the agent left outside the permitted folders is discarded — and even that stays retrievable as a backup in the repository. The bug had existed since 0.13.0. Also new: if there are unsaved changes in the project folder when a run starts, the factory still takes them into a commit, but now says so in the log and on the run page.

Merging and pull requests require a license

Mock runs still work without a license — for trying things out. The factory’s hand-over functions, however, now require a valid license: merging, push and pull request, and milestone release. Without a license a mock run ends cleanly, the result stays on its own branch, and the run page says so clearly. Nothing changes for runs with real AI agents; a reached daily limit does not hold up their merge.

Try it right away without a license

If you have no license yet you can start immediately: quick start, project page and „Neuer Lauf“ (new run) say before the click that the run uses the mock and produces no real code, and then start it. Until now the click ended in an error page. First-time setup offers „Erst ohne KI-Agent ausprobieren (Mock)“ (try without an AI agent first), and a rejected start leads back to the form without leaving an empty project behind.

Mock runs without a license

Runs with the mock no longer need a license, not even in the starter package: you can try the factory right after installing it without requesting anything. Mock runs do not count against the daily limit. For real AI agents the license applies unchanged; in a mock run the quality gate skips the reviewers that would start an AI program — the mock calls no AI model. The manually triggered quality gate now only starts such reviewers with a currently valid license.

Approval and cancel clearly separated

On the run page the approval now sits in its own highlighted block with its optional fields and the button „Freigeben und fortsetzen“ (approve and continue). Cancelling sits separately below, with its own clearly labelled field. Until now both fields were so close together that it was unclear which belonged to which button.

Easier start with Spring Boot

The quick start for Java web applications now uses an embedded database that needs no server and keeps the data after a restart. For projects with a separate backend and frontend, the build check finds the backend/ folder itself and shows the matching start command. The wizard names the target platforms in plain words and shows the next step after creating a project. Gradle can be installed under Einrichtung → Werkzeuge (setup → tools).

Version change on Windows by script

Windows gets uebernehmen.ps1: on a version change it takes over settings, database and working copies, with the same safeguards as the Linux script. start.ps1 now also starts on a fresh installation under Windows PowerShell 5.1, reads paths with umlauts correctly and no longer leaves settings behind in the PowerShell window. Both move scripts additionally verify the contents with a checksum over file names and sizes.

Version change takes the working copies along

When switching to a new version, uebernehmen.sh now moves the working copies into the new folder instead of continuing to work in the old version’s folder. On first start the factory adjusts all stored paths and reports in the start log whether the move succeeded. After that the old folder can be deleted. To keep the working copies where they are, use --workspaces-belassen.

Changing the API key made easy

Setup has its own „API-Schlüssel“ (API key) card in the simple view. For each provider the page clearly says “change key” or “enter key” and points out when a key from an environment variable on the machine takes precedence. If a run fails because of the key, a link on the run page leads straight there.

Quick start for Spring Boot fixed

The quick start now sets Java version, database, architecture and package name itself instead of writing unfilled placeholders into the task. A Spring Boot project with Thymeleaf is created in a single folder so the build check finds it. The result page shows the start command for newly created projects too and names bootRun for Spring Boot with Gradle. The starter package contains a new Spring Boot guide.

Website and docs reorganised

Four paths from the home page — product, demo, install, pricing — with new navigation, mobile menu and a single way to get it (“starter package on request”); new page “Terms and help”. In the app, user menu and footer show the right build time again instead of “1980”.

Community licence: clock skew tolerated

In the live test of the Community licence the factory rejected a freshly issued lease because the machine clock was one second behind the licence server. Up to five minutes of skew are now allowed — this also affected activation and renewal of purchased licences. Checked against the real licence server: request, start a run, renew.

Request the Community licence right in the factory

• Community licence: under Einrichtung → Lizenz the factory fetches the free licence itself — email address only, no account. 10 runs a day, 3 agents at once, up to 3 machines per email, renewed online every 30 days.
• Public demo: blocked actions show a clear message instead of the login page.

Follow-ups from the 0.50 acceptance

• Dashboard in „Einfach“ (simple) without the NVD warning; run page: „Abbrechen“ (cancel) set apart, the reason is folded away.
• Public demo: settings, integrations, users, licence and rules are read-only.
• Academy: „Teil-Lauf“ instead of „Child Run“.

Security fix for the public demo

On demo.softwarefabrik.io every visitor is automatically an administrator. The setup area new in 0.50.0 (system check, first-time setup, import folders and Git hosts) is now blocked there and no longer linked — otherwise visitors could have released server directories as import folders. Single-seat and team installations are not affected.

Easier to use, part 4: accessibility, orientation, new manual

The last block of the usability plan. 0.50.0 is the first release since 0.47.0 and also contains everything from 0.48.0 and 0.49.0.

• Accessibility: every table header carries scope, the last input fields without a label now have one, the menu button on narrow screens is a real button (keyboard, Escape closes it); code views, the notice bar and budget bars follow dark mode.
• Orientation: breadcrumbs (Projekte › project › Lauf › Logs) instead of different back links; a new page „Begriffe erklärt“ (terms explained) in the user menu — the factory's words in plain language.
• New manual: the user manual follows the guided path — initial setup, quick start, run page, result, project page; its own chapter on „Einfach“ (simple) and „Experte“ (expert), everything else in the expert chapter. The administration manual consistently says „Einrichtung“ (setup).

Easier to use, part 3: setup, system check, background runs

Not released separately, included in 0.50.0.

• System check: one page shows whether the factory is ready for a real run — agent programs, sign-in, git, Docker, build tools, import folders, Git hosts, licence, workspace; each row with finding, explanation and next step.
• Initial setup in three steps: choose the AI agent and subscription or API key (the key is checked right away), fix the open points of the system check, go to the quick start. No licence step.
• „Einrichtung“ instead of „Verwaltung“: in simple view four cards (AI access, tools & system, security, costs) in the user menu; operations and evidence collapsed for administrators.
• One place per topic: guardrails in three levels — Vorsichtig (careful), Ausgewogen (balanced), Schnell (fast); approval as one of three options (before execution, before merge, never).
• Untangled: one page per agent; import folders and Git hosts in the UI instead of environment variables; settings with AI access as a table and readable feature switches.
• Runs in the background: runs work in short steps in the background and the page refreshes itself. „Pausieren“ (pause) stops at the next step boundary, „Fortsetzen“ (resume) continues there. After a restart, interrupted runs end as „interrupted by restart“; the work stays on the run branch.
• Licence: dashboard and setup only offer „Lizenz importieren“ (import licence); the „Community starten“ promise is gone.

Easier to use, part 2: the guided path

Not released separately, included in 0.50.0.

• Build in one step: in the quick start „Bauen“ (build) creates the project and starts the first run right away; a line above the button shows the expected cost.
• Existing project in the quick start: a folder or Git address plus „Was soll geändert werden?“ (what should change?) is enough — import, detect language and build tool, start the first run.
• Simple run page: progress bar, cause of failure at the very top, „Erneut versuchen“ (try again) with „Was soll anders sein?“ (what should be different?), approval with one button; „Build nicht geprüft“ (build not checked) is a warning.
• Live status: run and project pages refresh themselves.
• New project page: description, „Nächster Auftrag“ (next task) with „Bauen“, previous runs and the latest result at the top; technical settings collected below.
• Result within reach: download as ZIP, a concrete start command from the real project file, „Weiter verbessern“ (keep improving) and „Vorschläge machen lassen“ (get suggestions).
• Fixed: simultaneous actions could fail at the audit chain with a database error; the chain is now locked until the write completes.

Easier to use, part 1

The first block of the usability plan: fewer stumbling blocks, clearer language, and the foundation for a simple and an expert mode.

• One entry point: “Neues Projekt” leads straight into the quick start; empty pages show the next step.
• Clear terms: consistent German terms and status names, page titles that match their tiles.
• Feedback: success, warning and error look different; deleting and discarding ask first; buttons don't fire twice.
• Usable on phones: every page; tables scroll sideways.
• Simple | Expert: a per-user switch in the header — pages get simplified step by step from 0.48.

Control in the UI and feedback from the test phase

What applies to a run is now in one place — and the handling follows what testers found difficult.

• Guardrails per project: quality gate, approvals, four-eyes principle, guardrails, sandbox, adapters, budgets and more — each value with its origin. Settable globally, per tenant and per project; lower levels only tighten. Every run records what applied to it.
• Agents that take effect: model, tools (read, git, build and test, change files) and policy per agent shape the call; the team order decides who plans and who builds. Agents and teams from MAINTAINER, with a preview “what the agent gets”.
• Run page: only buttons that work; “What now?”; a result card with changed files and “try it yourself”; no more dead-end error pages.
• Quick start: name, kind, description — the factory creates the project and the first run.
• Installation and version switch: install-softwarefabrik.sh checks and installs all prerequisites with a report; uebernehmen.sh takes over settings, database and working copies of the old version.
• German umlauts in all messages and German status names.

Practical readiness, block 2: many stacks, tools from the factory

The build gate now builds and tests far more than Java and .NET — and the factory installs missing toolchains itself.

• New project profiles: Gradle, Python (pip, uv, Poetry), Node.js (npm, pnpm, Yarn), Go, Rust and CMake — detected by their project files, with their own build and test steps.
• The factory manages tools: under Verwaltung → Werkzeuge it installs JDK, Maven, .NET SDK, Node.js, Go and uv without administrator rights, from the official sources, with a checksum. Agent and build gate share the same toolchain.
• Build container per project: own image, CPUs, memory and time limit — within the operator's limits; Maven image matching the JDK version in the pom; hardened containers.
• Language-neutral reviewers: test files by profile, imports missing from the manifest as hints, honest statements where rules don't apply; the project's linters (ruff, lint/typecheck) as check steps.
• Praxis-Suite: seven public reference projects against which every release proves import, profile detection and the gate trial run.

Production readiness, block 1: honest gate, project profiles, import with preview

Import existing projects and know before the first paid run whether the factory can build them.

• Not checked is not passed: if the build gate finds no build, the result is "not checked" and the run stops before the merge. Per project you can choose "fail the run" or "project deliberately has no build" instead. An approval only covers the build result it was given for.
• Project profiles: every stack is a profile made of data — detection, build steps, allowed agent commands, test patterns. Maven and .NET ship with it; further ecosystems follow without changes to the gate.
• Import as a separate step: take over the repository right away (without build output), preview with profiles and agent configuration found, confirm the profile, trial run of the gate as the baseline.
• Security: import URLs pass the same policy as push remotes; paths ending in .git no longer bypass the import allowlist.

Subscription runs survive the usage limit

If you use Claude Code or Codex on a subscription, no run is lost to the 5-hour or weekly limit any more.

• Pause instead of failure: when the agent hits the quota, the run goes to PAUSED and resumes automatically after the reported reset — with the same task, also in the correction loop and after a restart of the factory.
• You stay in control: "Fortsetzen" (resume) brings the start forward, "Abbrechen" (cancel) works at any time. Budget and attestation requirement are checked again before resuming; after five pauses the run fails as before.
• Traceable: pause, resumption and refusal are attested. API-key mode is unchanged.

Security patch for imported projects, tester package with guides

A patch release for everyone who brings existing repositories into the factory.

• Agent configuration stays as it was: whatever a run changes under .claude/, in .mcp.json or in the configuration of other agent CLIs is reset before the commit — even if the agent committed it itself. An agent cannot write itself permissions for later runs.
• Project context with a pre-check: if a repository's .claude/ brings process env, helper commands, additional directories, bypassPermissions or MCP enablement, the run starts without the project context and says why.
• Aider no longer reads repository configuration: with .env or .aider.* files in the repository, Aider does not start instead of running commands from them.
• Login page fixed: scripts and favicon load again.
• Tester package with HTML guides for installation and the first test with your own project; Claude Fable 5.2 in the model table.

The security review found further items for third-party repositories; they follow with 0.42.4 (details in the CHANGELOG).

MonoGame template, containers without root, CSP fixes

A patch release for .NET games and three bugs you notice in daily use.

• MonoGame in the wizard: new template for games (DesktopGL, WindowsDX, Android, iOS) from the official MonoGame templates, without a backend or with a .NET backend; separate, testable game logic and the content pipeline.
• Containers as your user: build and scan containers run as the owner of the workspace instead of root; bin/, obj/ and target/ then belong to you. Root-owned leftovers are fixed once.
• Blocked scripts repaired: the run page's browser notification, the confirmation before deleting a key and saving role and tenant on change all failed because of the content security policy. A test prevents new inline scripts.
• Small things: the first import no longer reports “workspace reused”; the wizard advises against .NET 8 and 9 for new projects (end of support November 10, 2026).

Better .NET support and a trial version with an expiry date

Existing C# and MonoGame projects now go through the factory with less manual work.

• Matching SDK in the sandbox: the factory reads the .NET version from global.json or the highest TargetFramework and builds in the matching image (e.g. net9.0 → sdk:9.0). Previously every project ran with .NET 8.
• The agent may call dotnet: it builds and tests C# projects itself while working instead of learning about failures only through the build gate and the correction loop.
• Wizard: the .NET templates suggest .NET 10 (LTS), 9 and 8 remain selectable; the help text names the end of support (8 and 9 end on November 10, 2026).
• Trial version: a build without a license file and with a fixed expiry date; the footer shows how long it is valid.

Tester package: license file, cost transparency, .NET

Everything someone needs to test the factory on their own machine with an existing repo and their own API key.

• License as a file: the license admin issues an activation file; the factory binds it to the machine on import (one device per license, optionally with a monthly euro limit). The distribution JAR requires a license that cannot be switched off by a setting; standalone certificates cover air-gap setups.
• Complete, visible costs: the AI merge and reviews now count too. The run page shows costs live, the run list and project page show the month so far with a budget bar. Every start shows an estimate first; the USD→EUR factor is a setting.
• .NET in the sandbox: C# projects also build in the container sandbox, with coverage via coverlet; each project can set its own build command.
• Taking over the result: the project page shows the Git commands to pull a run’s branch into your original repo. The import reports large repos and a missing git-lfs.
• Starter package: start scripts check Java 25, Docker, git and the CLI; a short guide walks through a test with your own repo in ten steps.

Build gate for .NET

Validation used to build Maven projects only; C# repositories passed without a build check.

• .NET detected: a solution (.sln/.slnx) or a single project file in the build directory. The gate runs dotnet tool restore, dotnet build and, with test projects, dotnet test; build errors feed the correction loop.
• MonoGame: verified with a real DesktopGL project including the content builder mgcb. WindowsDX projects need Windows.
• Honest instead of guessed: several solutions or an active container sandbox (no .NET image yet) report a warning instead of passing silently.

Adopting existing Claude Code projects

If you already work with Claude Code, you can now develop your repository further in the factory with everything it brings along.

• Claude Code project context per project: when enabled, the repository's CLAUDE.md, subagents, skills, commands and .claude/settings.json apply in factory runs. Hooks and .mcp.json stay off; verified empirically with Claude Code 2.1.310. Default: off, for your own, trusted repositories only.
• Nothing overwritten anymore: the factory no longer replaces your own CLAUDE.md, and its own subagents and skills do not overwrite project files of the same name. They also no longer end up in commits and pull requests.
• Other: session cookie with SameSite=Lax and optional Secure flag, DB password at least 16 characters, start scripts check only the CLI of the selected adapter.

The step-by-step guide is in the user manual.

Patch: quality gate without review CLIs

A bug-fix patch without migration. If aider or claude was not installed, the factory reported it as a timeout and the quality gate ended in ERROR instead of skipping both reviewers. They now count as SKIPPED; a mock run via Docker Compose ends with quality gate PASSED.

Patch: approvals, Git author, Compose

A bug-fix patch without migration.

• Approved runs continue. Since 0.30.0 a run stayed in WAITING_FOR_APPROVAL after “Approve and continue”, although the approval was in the audit log: the status change was not saved. A new test now covers exactly the path the UI takes.
• Git author: name and email from settings now apply to all of the factory's commits.
• Default model for Kimi and Aider can be set in settings; ineffective fields (token caps, Codex/Gemini model) were removed.
• Docker Compose: the app image ships git and wget. A mock run now completes and the health check reports “healthy”. For real agent runs, the native single-seat start remains the official path.
• License model now describes only what is technically enforced: tenants, roles, SSO and the audit chain are included in all tiers.

Patch: stored keys for all agent CLIs

A bug-fix patch without migration, continuing 0.41.1: Codex, Gemini, Kimi and Aider also read their key only from the factory process environment. In auth mode api-key they now inject the key stored under Integrations when the environment has none — Codex OPENAI_API_KEY, Gemini GEMINI_API_KEY, Kimi KIMI_API_KEY, Aider one of the three major providers depending on the model. The environment takes precedence; in subscription mode keys are still removed.

Patch: Anthropic key from the UI reaches the Claude CLI

A bug-fix patch without migration.

• Anthropic key from Integrations: Claude Code used to read the key only from the factory process environment; a key stored under Integrations was only used for the key test and the AI merge. In auth mode api-key the factory now injects it for runs and reviews when the environment has no ANTHROPIC_API_KEY. The environment still takes precedence; in subscription mode the key is still removed.
• Licence status page: the buttons to the licence model and Enterprise led to a 404.

Artifact evolution: evolve the control files without losing your additions

Until now every run rewrote the six control artifacts (PROJECT.md, INSTRUCTIONS.md, AGENTS.md, WORKFLOW.md, DEFINITION_OF_DONE.md, README.md) from the project definition — a rule you or an agent had added directly to AGENTS.md was gone afterwards. 0.41.0 versions these files and merges changes in a controlled way (ADR-0028).

Drift protection and artifact evolution

• Drift protection: the factory no longer overwrites a control file changed in the workspace. It saves it as an immutable snapshot, and the agent works with the changed version. Under Project → Artifacts every version is listed with origin and SHA-256; any of them can be restored.
• Three-way comparison per section: Artifact evolution compares the version last written, the workspace version and the newly generated one. What only you changed stays; what only the template changed comes in; what both changed differently is a conflict.
• Preview and approval: the preview shows the diff, conflicts and contradictions between the files. Approval (MAINTAINER or higher) applies all files as one set — transactionally: hash check against intermediate changes, atomic writes, a commit of only these files, return to the previous state on failure. Recovery cleans up stuck applications on startup. Critical conflicts block approval.
• Modes: off (default, previous behaviour), protect (drift protection only), approval (a run creates an update for approval on drift) and auto-safe (the run applies unambiguous updates without conflicts directly).
• AI merging only as a validated proposal: on request a model (default Claude Opus 5.5) proposes how to merge conflicts — directly via the Anthropic API when an API key is set (official Java SDK), otherwise via the Claude CLI with a plan. A deterministic validator rejects proposals that touch other sections, introduce secrets, hooks, MCP servers or permissions, or drop security rules. The AI never writes on its own.

Self-development and monorepos

• Adopt existing repos: if a file does not follow the factory structure, the analysis proposes to adopt the workspace version as the baseline. After that only real template changes come in. This lets the factory work on its own repository as a target project.
• Build directory per project: if the pom.xml is not in the root (e.g. under app/), the build gate runs mvn -B -f app/pom.xml verify. Without a build directory, a skipped build now warns when poms sit in subdirectories.
• Gemini plan mode: like Codex and Kimi, the Gemini adapter now also runs with the plan login (“Login with Google”, SOFTWAREFABRIK_GEMINI_AUTH_MODE=subscription).

Security and fixes

• Build gate without the factory's secrets. In local sandbox mode, mvn verify — that is, agent-written code including tests — inherited the factory's entire environment. The factory now removes SOFTWAREFABRIK_*, SPRING_DATASOURCE_* and variables with password, secret, token, API key or credential in their name. A workspace that contains the running factory's working directory is not built.
• Agents read AGENTS.md reliably. The factory's CLAUDE.md now imports the file via @AGENTS.md, and the run task of all nine adapters names PROJECT.md, INSTRUCTIONS.md, AGENTS.md and MEMORY.md explicitly. Previously Claude Code did not load the merely mentioned file.
• Workspace received the oldest artifact version. Once a project had been generated several times or edited in the UI, AGENTS.md, WORKFLOW.md, DEFINITION_OF_DONE.md and README.md in the workspace were at version 1. Fixed.

Migrations V67–V69.

Upgrade note: artifact evolution is off by default (artifact-evolution.mode=off); enable it under Settings → Control artifacts, globally or per project. For monorepos, set the build directory on the project page.

Patch: repo import only from released directories

A security patch without new features and without a migration. When importing an existing repository from a local path, the factory copies the directory into the workspace, where the agent reads it. Two gaps are closed:

• Symlinks in the source are no longer copied. Previously a link in the repository pulled the content of a foreign file into the workspace. The run log lists skipped entries.
• Local sources only from released directories. Previously anyone who could create an import project could have any directory on the server copied. The operator now defines the allowed directories (SOFTWAREFABRIK_IMPORT_ALLOWED_ROOTS); without an entry, local import is off. Git URLs are not affected.

Upgrade note: if you import local paths, add the directory before updating.

GitHub Spec Kit meets the factory's governance

Many teams now write their requirements with GitHub Spec Kit. 0.40.0 makes those specs usable in the factory without rewriting them — and allows projects that work entirely in the Spec Kit layout. Human approval, binding to approved revisions and the audit chain stay exactly as they were.

Spec Kit bridge: import and export

• The spec overview detects Spec Kit specs in the workspace (specs/<NNN>-<slug>/spec.md, template v1.2.2). A preview shows which Spec Kit ID gets which AC ID before anything is imported.
• An import always creates a draft, never an approval. The Spec Kit ID stays on the criterion as an alias ([FR-003]); origin and checksum are recorded in the audit chain.
• Every revision can be exported in Spec Kit format; export and re-import keep AC IDs and criterion texts.
• The spec-conformance reviewer treats a test that names FR-003 like a reference to the AC ID.

Projects in the Spec Kit layout

• Every project has a spec format: FABRIK (default) or SPEC_KIT. The wizard suggests SPEC_KIT when an imported repository already contains Spec Kit files.
• In the Spec Kit layout every run writes the Spec Kit templates, generates the constitution from the engineering guardrails and places each spec as specs/<NNN>-<slug>/spec.md. Changes to it are taken over as a new draft.
• Spec and plan runs follow the Spec Kit templates; questions marked [NEEDS CLARIFICATION] become open questions in the spec UI.
• Spec Kit itself is neither installed nor executed. Scripts, extensions and .claude/commands/ in the workspace block the quality gate under the MCP default ban.

Security: no symlinks in the workspace

A security review found that an agent could replace a path in the workspace with a symbolic link pointing outside, which the next run would then have written through. The factory now never reads or writes through a symlink in the workspace — for every file it creates, including AGENTS.md, CLAUDE.md and the skill files. A hit aborts the run with a reason and is recorded in the audit chain.

Migration V66 (one column). All spec functions remain tied to the SDD entitlement.