Warn on repeated test commands without workspace changes

[yablokolabs]

Summary

A coding agent can repeatedly run the same test suite without changing the workspace. The command may be intentional once, but consecutive equivalent runs with no intervening source change consume step budget without adding evidence.

This is the test-command half of finding §11 from Yabloko Labs' evaluation. It is separate from repeated file reads because test progress depends on workspace state rather than read-range coverage.

Current behavior

Atomic's generic loop tracker hashes exact tool arguments and results:

• loop-detector.ts

That detector uses general thresholds and does not know that a recognized test command repeated against an unchanged workspace is a stronger no-progress signal. Small changes to execution-only parameters can also produce a different raw argument hash.

Proposed behavior

Add a narrowly scoped test-command detector that starts warn-only until false-positive behavior is proven safe.

Initial classification should be explicit and testable, covering direct common forms such as:

• pytest and python -m pytest;
• cargo test and go test;
• npm test, pnpm test, yarn test, and bun test.

Build a semantic key from the resolved working directory, runner/subcommand, and meaningful suite/filter arguments. Ignore only execution controls proven not to change the selected tests, such as the tool timeout; changed cwd, environment, suite filters, features, or test arguments remain distinct.

Compare that key against a workspace fingerprint captured before each run. The fingerprint must observe mutations made by Atomic tools, shell commands, and external processes; it cannot be only an internal “write tool called” counter. Project input files should be fingerprinted under documented ignore rules so cache/output churn does not masquerade as source progress.

Acceptance criteria

• A second equivalent recognized test command against the same workspace fingerprint emits a no-progress warning with the previous result summary.
• The initial implementation warns but does not veto or force termination.
• An intervening Atomic write/edit/patch changes the fingerprint and permits the rerun.
• A shell-driven or external-process file mutation is also detected and permits the rerun.
• Same-size file replacement changes the fingerprint.
• Changed cwd, environment, selected suite, feature flags, or test filters are treated as distinct.
• Intentional repeats can be explicitly acknowledged without disabling generic loop protection for the rest of the turn.
• Cache, coverage, and build-output churn covered by documented ignores does not count as source progress.
• Unrecognized shell commands remain under the existing generic detector.
• Tests cover each classified runner, timeout-only variation, changed cwd/env, shell and external edits, same-size replacement, output-only churn, and intentional repeat override.