TypeScript with DevFlow: scanning, verification, isolation

DevFlow runs TypeScript tasks in devflow/agent-universal:stable, audits a package.json at the repo root with pnpm audit, and caps every test container at 4 CPUs and 4 GB of memory.

Manifests

package.json

Dependency scanner

pnpm_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 TypeScript 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 a package.json at the repo root and runs pnpm audit when a task finishes and on recurring vulnerability polls. Only the root is checked, so a package.json that lives only in a subdirectory is not audited. 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 corepack pnpm build and corepack pnpm test. The universal image ships Node 22 with corepack enabled, so the pinned package manager is downloaded under $HOME/.cache at run time. With no commands configured, the task can merge unverified, and the timeline shows it.

Isolation and limits

Every cache resolves under $HOME, a per-container tmpfs, and the repo's install setup runs before the agent starts, so dependencies are already in place. 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

Add input validation to an API route. The planner asks where validation errors should surface, you answer and approve the plan. The implementer changes the route and its tests in the worktree, the gate runs the test command, and the PR lands on its own devflow branch.