What the factory cannot yet do fully.

1. Cloud gateways are experimental

Alongside the official vendor APIs there are adapters for the cloud gateways AWS Bedrock, Google Vertex AI and Azure OpenAI. These are implemented but not yet live end-to-end tested.

• Production use of a gateway should happen only after customer-side verification with real cloud credentials.
• The direct vendor APIs (Anthropic, OpenAI, Google Gemini) and on-prem operation via Ollama/vLLM are not affected.

2. Parallel runs only behind a feature flag — and only on one host

Up to v0.20 exactly one run executed per project. Since v0.21 there is a workflow layer above it: a piece of work splits into tasks that run as independent child runs in parallel — each in its own git worktree. This is off by default.

• Without the feature flag softwarefabrik.workflow.enabled the platform behaves as before: one run per workspace.
• With the flag, at most three child runs execute concurrently per workflow. The limit is deliberately low: every run costs tokens, and more parallelism mainly increases integration effort.
• Since v0.21 the lock applies to the workspace, not the project. Two agents in the same directory remain excluded — otherwise no change would be attributable to a single run.
• No distributed worker pool. All child runs execute as processes on one machine.
• Merge conflicts and contract breaks are resolved by a human. Both pause the workflow and wait for a decision; an agent that reconciles the branch itself is planned, not built.

3. Execution of generated code — isolated environment recommended

Build runs execute agent-generated code (e.g. mvn verify, npm run build). Such code should always be treated as untrusted.

• Run build runs on an isolated or trusted environment, not on a host with sensitive access.
• The platform offers a container sandbox per run (execution.sandbox.variant=container, with network, CPU and memory limits). Further sandbox hardening is in progress.

4. Repository integration: pull requests and CI feedback for GitHub only

Push, pull request, CI status polling and GitHub releases are implemented against the GitHub API.

• GitLab, Bitbucket and Azure DevOps are not connected yet. For those hosts the local merge into the base branch applies; branch isolation, quality gate and the correction loop work unchanged.
• PR/CI feedback is deliberately opt-in (git.pr-feedback.enabled, off by default): unattended periodic remote contact should be a conscious operational decision.
• The factory-wide GitHub token is only used for hosts on the allowlist (git.allowed-hosts, default github.com).

5. Budget caps apply per tenant, not per user

Token usage and cost are captured per project, run, provider, tenant and per seat (the user who triggered the run) and exported as CSV.

• The hard budget cap applies at tenant level. There is no seat-level cap — the seat view reports, it does not constrain.
• If you need to enforce per-user limits, separate by tenant.

6. One known open CVE in the embedded Tomcat

CVE-2026-66299 (CVSS 7.5) affects tomcat-embed-* at version 11.0.24 — the servlet container the platform embeds.

• There is currently no fix. 11.0.24 is the newest available 11.0.x release on Maven Central; 11.0.25 does not exist yet.
• Downgrading would be harmful: 11.0.24 closes the more severe CVE-2026-59083 and CVE-2026-59084 (CVSS 9.1 each), which are open in 11.0.23 and earlier.
• The finding is recorded in the scan with an expiry date of 2026-11-06. After that the check deliberately fails again and forces a re-assessment — rather than quietly becoming permanent.
• It only became visible on 2026-08-06: the dependency scan previously ran in CI without an NVD API key and never completed properly. That defect is fixed.

Run the platform behind a reverse proxy rather than exposed to the internet — which is the recommended deployment anyway.