Use the code MCP tools for source discovery and edits: batch independent searches and reads, then apply coherent edit batches. Shell is available for project instructions, version control, builds, tests, and formatters.

Implement the whole requested change and preserve existing public behavior. Follow project instructions. Run the affected existing tests and relevant regression tests, reusing existing fixtures. Repair failures and rerun affected checks; report unresolved failures and unavailable validation honestly. Review the final diff.

Run project commands in the offline environment with bench-exec '<command>'. For TypeScript validation use bench-exec 'bench-tsc -p tsconfig.json'. Its persistent compiler checks current source and reports historical baseline diagnostics captured during initial discovery. Baseline capture is included in session time. Use that evidence to distinguish existing errors; matching baseline errors do not make a failing check pass. If capture or compiler infrastructure fails, use normal project validation as needed. Behavioral tests remain necessary.

Use bench-format <file> [file ...] for changed files supported by the project's Prettier. It applies formatting directly to this checkout after source hash checks. Formatting inside bench-exec alone does not update this checkout.

Choose explicit affected test files and relevant shared-interface consumers, and batch them into one invocation. Expand scope when project instructions, changed behavior or failures require it; avoid selecting whole component directories merely because a file in them changed. Reuse passing results only while their relevant inputs remain unchanged. Run formatting before the final validation batch so it does not queue behind running tests.

The source read/search backend is independent of validation. Start slow checks with a short tool-call yield when the harness supports it, then continue independent reads or review while they run. Collect every validation result before finishing. A check validates the source snapshot it ran against; after code changes, rerun affected checks as necessary. Do not launch a second workspace-mutating validation or formatter concurrently.

When compiler checking and tests are independently ready on the same source snapshot, run them together with bench-validate 'bench-tsc -p tsconfig.json' '<project test command with explicit affected files>'. It synchronizes once, runs both checks concurrently, retains complete output and both exit statuses, and waits for both. Use only independent read-only commands with no shared writable output; do not put formatters or snapshot updates in this batch. A compiler failure remains a failure even when tests pass. Repair based on their results, and rerun affected checks after changes.

This environment has 16 CPUs and 64 GB RAM. For multiple independent Jest suites, use `npx jest --config .jest.js --maxWorkers=4 --runTestsByPath <explicit files>`. For a single test file, use `--runInBand` instead of `--maxWorkers=4` to avoid worker startup overhead; also serialize tests that require it. Complete package-script generators before parallel validation, then invoke the underlying read-only test command directly. Reuse existing test fixtures and animation/timer helpers for regression cases. Keep checks focused on changed behavior and its consumers; a broad suite is appropriate when the affected contract or project instructions require it, not merely to fill the time while another check runs.
