{
  "title": "Software issue histories for testing AI coding agents",
  "source_page": "https://fiund.com/industries/software-issue-resolution-data",
  "authorship": "Original fictional Fiund editorial exercise. No actual operating records or third-party source assets are included.",
  "example": {
    "title": "An issue's first passing test does not prove a general repair",
    "context": "An original local task defines sum_sizes as the sum of nonnegative integer list entries. Dummy snapshots, fixtures and candidate results expose a shortcut without relying on a public benchmark or customer repository.",
    "records": [
      [
        "SO1",
        "Reproducible starting fixture",
        "sum_sizes([2,3]) returns 2 but expected 5. Empty input returns expected 0. Snapshot S1 and fixed dependency list supplied."
      ],
      [
        "SO2",
        "Candidate output log",
        "Candidate C returns 5 for [2,3], 0 for [], and 5 for [0,4]. Last expected output is 4."
      ],
      [
        "SO3",
        "Independent acceptance key",
        "Task requires all valid lists, not just the first fixture. Candidate patch and reference solution kept separate from model input."
      ]
    ],
    "question": "Which regression does candidate C fix in the supplied checks, and what evidence prevents calling the issue fully repaired?",
    "answer": "SO2 shows C passing the original [2,3] reproduction and retaining the empty-list result. It fails the independent [0,4] check by returning 5 instead of 4. Under SO3's stated task, that is evidence against a general repair despite the first test passing. Report each input, expected value and observed value; do not label the issue resolved or infer a correct implementation from one successful case.",
    "failureModes": [
      "Accepting a hard-coded shortcut after only the original reproduction passes.",
      "Leaking the reference solution or adjacent fix discussion into the evaluation input."
    ],
    "fields": [
      [
        "Snapshot and dependency fixture",
        "Makes the starting failure reproducible."
      ],
      [
        "Input, expected and observed output",
        "Shows exactly which behavior a check proves."
      ],
      [
        "Held-out acceptance case",
        "Rejects a shortcut that fits only the first example."
      ],
      [
        "Task-family split",
        "Keeps closely related fix-revealing cases together."
      ]
    ],
    "holdout": "Use a separately authored list family with three or more entries and varied zeros. Have an independent maintainer verify legitimate implementations and reject constant-output shortcuts before accepting the task pack.",
    "boundary": "Use original self-contained code and synthetic fixtures. Exclude credentials, deployment URLs, customer traces, protected issue comments and unlicensed dependencies."
  }
}