.NET with DevFlow: scanning, verification, isolation

DevFlow runs .NET tasks in devflow/agent-universal:stable, audits .sln or .csproj files in a bounded walk of the tree with dotnet list package --vulnerable, and caps every test container at 4 CPUs and 4 GB of memory.

Manifests

.sln, .csproj

Dependency scanner

dotnet_audit

Agent image

devflow/agent-universal:stable

Scan timeout

300 s per scan by default

Container caps

4 CPUs, 4 GB memory (6 GB with swap), 512 processes

How a .NET task runs

You describe the task, the planner reads the code and may ask questions, and implementation starts only after you approve the plan. The plan splits into at most 8 subtasks, implemented in a git worktree on the branch devflow/<id>, then verified, summarized and opened as a PR. Agents work in the image listed above.

Dependency scanning

The scanner looks for .sln or .csproj files in a bounded walk of the tree and runs dotnet list package --vulnerable when a task finishes and on recurring vulnerability polls. Project files are used only when no solution exists, and each target is restored first and listed with --include-transitive. Each scan stops after 300 seconds by default (SCANNER_TIMEOUT_SECONDS) and never blocks the gate.

Verification gates

Gates run only the configured test_commands, stored as bare in-container commands, for example dotnet build and dotnet test. The universal image installs SDK 9 with DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1 and telemetry turned off. With no commands configured, the task can merge unverified, and the timeline shows it.

Isolation and limits

NuGet and build caches resolve under $HOME, a per-container tmpfs, so nothing is written into the image at run time. Test and build commands run in Docker as a non-root user, capped by default at 4 GB of memory (6 GB with swap), 4 CPUs and 512 processes. The agent can write only to the task worktree and its git data, toolchain paths such as /usr stay read-only, and code-writing roles reach only allowlisted hosts.

A typical task

Upgrade a vulnerable NuGet package. The scan names the package and the fixed version. Once you approve the plan, the implementer edits the project file in the worktree, the gate runs dotnet test, and the PR carries a verification evidence section.