Green tests.
Good change?

A pass describes the checks you ran. Use this map to see which parts of the task the original six cases exercise, and which still need evidence.

The runner has its own boundary. JSON has no NaN or Infinity literals. If a numeric value parses to infinity, such as 1e400, the runner rejects the case before calling either candidate. That is an invalid run, not evidence that a candidate rejected the input. A quoted "Infinity" tests a string instead. The task's non-finite-input requirement needs a separate direct JavaScript check.

1. Run the original cases and inspect their evidence. Notice that every base_seconds and cap_seconds is a valid positive number.
2. Replace the editor contents with the four cases below. They isolate wrong types, zero, and a negative value while keeping the other inputs valid. Predict each outcome before running.

[
  {
    "id": "reject-string-base",
    "input": { "attempts": 2, "base_seconds": "1", "cap_seconds": 4 },
    "expected_error": "TypeError"
  },
  {
    "id": "reject-null-cap",
    "input": { "attempts": 2, "base_seconds": 1, "cap_seconds": null },
    "expected_error": "TypeError"
  },
  {
    "id": "reject-zero-base",
    "input": { "attempts": 2, "base_seconds": 0, "cap_seconds": 4 },
    "expected_error": "RangeError"
  },
  {
    "id": "reject-negative-cap",
    "input": { "attempts": 2, "base_seconds": 1, "cap_seconds": -1 },
    "expected_error": "RangeError"
  }
]

3. Run the checks and compare expected with actual for each case. Then add distinct cases for a negative base, a zero cap, and other wrong types. Keep only one invalid field per case so the failure is interpretable.
4. These four cases replace the original six in this run. To keep both kinds of coverage, combine the arrays with unique IDs and rerun. Reset example cases restores the original six; download your edits first if you want to keep them.

Check your reasoning: with exactly these four cases, Candidate A passes 4/4 and Candidate B passes 0/4 JSON cases. B returns arrays instead of the required errors. Its trusted-test and protected-file failures remain separate reasons to reject it. More cases expose more behavior; they still do not establish every possible input or an agent's reliability.

1. Start with a real failure. Choose an ordinary task where it can happen. Freeze the task, clean starting fixture, checks, and acceptance rule before seeing a result.
2. Run the agent on that fixture. Keep evaluator cases and reference answers outside its workspace. Record the model, settings, instructions, tools, permissions, and starting revision.
3. Grade what it produced. Replace a candidate's implementation and retain its submitted test file. Run the trusted checks; inspect the full diff for weakened assertions and unrelated changes. This exercise's exact file comparison only protects one file.
4. Repeat on fresh tasks and runs. Retain failures and execution errors as well as passes. These two hand-written examples demonstrate the grader; they cannot establish an agent's failure rate or an improvement.