Atlas runs a JavaScript suite with vitest through its bash tool and converts the red output into a prioritized list of distinct root causes. A full vitest run over a Node and browser project prints far more than any model should read, so Atlas truncates at 2000 lines or 50 KB, writes the complete log to a retained file, and reports the path, which means triage happens against the whole log rather than a lossy tail. Atlas then greps that log to group failures by cause instead of by test name, records one todowrite entry per cause with status pending, and fixes them one at a time with edit, re-running only the affected spec files with pnpm vitest in between.
How do you triage a red vitest suite instead of fixing tests one by one?
Group by cause, not by file. A JavaScript suite reporting 87 failing specs across 12 files usually has three or four real causes, and in vitest projects the most common one is a module resolution error that fails every spec importing a shared helper. Atlas greps the saved log to find those causes first.
JavaScript failures cluster around a small number of chokepoints, and the chokepoints are recognizable. An ESM versus CommonJS mismatch in a dependency fails every spec that imports it, and the message is the same in all of them. A path alias that vitest cannot resolve because the config and the bundler config disagree produces Cannot find module across an entire directory. A change to a shared fixture breaks every snapshot at once. An unhandled promise rejection in a beforeEach fails everything in the file and tells you nothing about the assertions. Atlas reads the saved log and counts: this message appears 61 times, that one 19 times, this third one twice. The counts are the priority order, and the twice is often a genuinely separate bug worth its own todowrite entry.
What does Atlas do when vitest prints more output than fits in context?
Atlas's bash tool truncates inline output at 2000 lines or 50 KB, writes the complete vitest log to a retained file, and prints the path in an output truncated header. Atlas then reads and greps that file, so a JavaScript suite that emits 9000 lines of stack traces is still triaged in full.
vitest is verbose when it is unhappy. Each failing spec brings a stack trace through the test runner internals, a diff of the expected and received values, and frequently a warning about an unhandled rejection that has nothing to do with the assertion. Multiply by 87 specs and the console output is longer than anything a model can hold while also holding your source code. Atlas's answer is to keep every line but not in context: the bash tool saves the complete log to a file and names it. Reading a targeted slice with the read tool and counting occurrences with grep gives Atlas the shape of the failure set without ingesting all of it. Pass a generous timeout in milliseconds to bash when the suite is slow, so a browser-environment project is not killed mid-run and misread as a hang.
What commands does Atlas run in a JavaScript repo during triage?
Atlas runs the real commands from your package.json. The full sweep is pnpm vitest through the bash tool with a generous millisecond timeout. Narrow re-runs target 1 spec file, for example pnpm vitest run src/cart/cart.test.js, and the formatting pass after a fix is prettier on the files that changed.
A triage transcript in a JavaScript repository is concrete from the first line. bash runs pnpm vitest across the project. The output overruns, so Atlas reads the saved log path from the truncation header. grep over that log counts the distinct error messages. todowrite records one entry per cause with status pending. edit applies a fix, and a narrow pnpm vitest run against just the affected spec file proves it, in seconds rather than the minutes a full sweep costs. Atlas also reads your npm scripts, so if the team wraps the runner in a script the correct invocation is used rather than a guessed one. When the failure turns out to be a dependency problem rather than a code problem, pnpm is where it gets resolved, and prettier tidies whatever Atlas touched before you review the diff.
How does Atlas keep track of several JavaScript failures at once?
One todowrite entry per distinct cause, each with status pending. A JavaScript triage session that starts with 87 failures and four causes ends with four closed entries, not with three fixed causes and a confident summary that quietly omits the fourth because it fell out of context ten turns ago.
Drift is the characteristic failure of agent-driven triage. The suite gets greener, the momentum feels like progress, and the last cause is never addressed. Atlas's todowrite list is the countermeasure, and in a JavaScript repo the entries are specific: fix the ESM import in src/utils/format.js, update the shared fixture that broke every snapshot in src/cart/, resolve the path alias mismatch between the vitest config and the bundler config, and handle the unhandled rejection in the beforeEach of src/api/client.test.js. Fixes proceed one at a time with edit, each surfaced as a unified diff for approval before writing. Atlas snapshots file changes as git patches, so a fix that made the suite worse can be diffed and rolled back without losing the rest of the session.
Is it safe to let Atlas run vitest and edit JavaScript unattended?
In 2026, every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, which covers the bash call that invokes pnpm vitest and the edit call that changes src/utils/format.js. Atlas also computes a unified diff for every file edit and surfaces it for approval before writing.
A JavaScript test run is not inert. A spec can hit a dev server, an npm script can invoke a build or a codegen step, and a lifecycle hook in a package can execute arbitrary code. Atlas puts all of it behind one permission model evaluated before the tool call runs. A common setup allows pnpm vitest and prettier outright, asks on anything that installs or updates dependencies through pnpm, and denies destructive shell patterns entirely. Edits stay under diff approval regardless, so the change to a shared fixture that will ripple through forty snapshots is something you read before it exists on disk. With git patch snapshots underneath, a triage session that touches a dozen JavaScript files remains fully reversible.
Step by step
- 01Run the full suite with the bash tool: pnpm vitest, passing a generous timeout in milliseconds so a slow browser-environment suite is not killed mid-run.
- 02If bash reports output truncated at 2000 lines or 50 KB, read the log file named in the truncation header to see the complete vitest output.
- 03Grep the saved log to count distinct error messages, which groups the failures by root cause instead of by spec name.
- 04Separate resolution errors from assertion failures; Cannot find module across a directory is a config or dependency problem for pnpm, not a bug in your JavaScript.
- 05Record one todowrite entry per distinct cause with status pending, for example the ESM import in src/utils/format.js and the shared fixture breaking every snapshot in src/cart/.
- 06Fix the causes one at a time with edit, approving the unified diff Atlas surfaces for each JavaScript file before it is written.
- 07Re-run only the affected specs between fixes via bash, for example pnpm vitest run src/cart/cart.test.js, so the loop takes seconds rather than minutes.
- 08Run prettier on the changed files, then run the full pnpm vitest suite once more to confirm every todowrite entry is genuinely closed.
Frequently asked questions
- How do I get an AI agent to triage dozens of failing vitest tests?
- Have it group by root cause. Atlas runs pnpm vitest through bash, saves the complete log when output passes 2000 lines or 50 KB, greps that log to count distinct error messages, and records one todowrite entry per cause with status pending.
- What happens when vitest output is too long for the model's context?
- Atlas's bash tool truncates the inline output at 2000 lines or 50 KB, writes the complete log to a retained file, and prints the path in an output truncated header. Atlas reads and greps that file, so no failing spec is lost to a truncated tail.
- Why do dozens of JavaScript specs fail at once from one mistake?
- Because JavaScript failures cluster at chokepoints. An ESM versus CommonJS mismatch, an unresolvable path alias, or a changed shared fixture fails every spec that touches it. Atlas counts the repeated error message and treats the cluster as one todowrite entry, not eighty.
- Does Atlas re-run the entire suite after each fix?
- No. Atlas re-runs only the affected specs between changes, for example pnpm vitest run src/cart/cart.test.js, and runs the full pnpm vitest suite once at the end to confirm every todowrite entry is genuinely closed.
- Can Atlas tell a dependency problem from a code bug in a JavaScript suite?
- Yes. Cannot find module across an entire directory points at a config or dependency problem you resolve with pnpm, while an assertion diff points at code. Atlas separates them when grouping the saved log and files them as separate todowrite entries.
- Is it safe to let an AI agent run npm scripts against my repo?
- Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, including the bash call that invokes pnpm vitest. Allow the test and prettier commands, ask on anything that installs dependencies, and deny destructive shell patterns.
- Can I undo the JavaScript fixes Atlas made during triage?
- Yes. Atlas snapshots file changes as git patches so edits can be diffed and rolled back, and Atlas computes a unified diff for every file edit and surfaces it for approval before writing to src/utils/format.js or any other file.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Run the Test Suite and Triage the Failures with Atlas in 2026
How to triage a failing test suite with Atlas in 2026: bash truncates at 2000 lines or 50 KB and saves the full log, then grep groups failures by root cause.
Atlas for JavaScript in 2026
In 2026, Atlas empowers JavaScript developers with a terminal-native AI coding agent. It indexes code by AST, uses local embeddings, and offers permission-gated tools for safe, efficient development.
Migrate a deprecated API across every callsite in JavaScript with Atlas (2026)
How Atlas migrates a deprecated JavaScript API across every callsite in 2026: lsp findReferences enumerates callers, todowrite tracks them, apply_patch migrates each one.
Audit a JavaScript Repo with Parallel Subagents in 2026
In 2026, JavaScript developers use Atlas to sweep entire repositories for code issues. Leverage parallel subagents to audit pnpm projects, vitest configurations, and prettier formatting without blowing your main context
Research a Third-Party API Before Integrating It in JavaScript with Atlas (2026)
Atlas uses websearch and webfetch to pull live API docs into context before you write JavaScript, so your Node or browser integration matches the real endpoints in 2026.
Debug a Single Failing Test in JavaScript with Atlas (2026)
Debug one failing JavaScript test with Atlas in 2026: run it in isolation with vitest through pnpm, walk the call path with the lsp tool, and fix the code, not the assertion.
Plan a Multi-File Change Before Editing in JavaScript with Atlas in 2026
Plan a multi-file JavaScript change before editing in 2026. Atlas's plan agent denies edit outside .atlas/plans/*.md, and plan_exit gates the build agent handoff.
Document a JavaScript Module with a README Using Atlas (2026)
How Atlas writes a README for a JavaScript module in 2026: enumerate exports with the lsp tool, read the source, verify every sample with vitest and pnpm.