Public task

dc-0727-version-diff

Build the comparison engine for a site-planning platform: turn two database snapshots into the business diff — what was really edited, renamed, and re-planned — with per-entity identity, reviewed totals, and a paged report.

hardsoftware-engineering

Part of DiffBench ↗

Model configurations: 3
Evaluation attempts: 5
Public examples: 5

Current task results

Evaluation comparison

Published evaluation results for this task version. Each bar shows a model configuration’s average score.

Model averages for this task version
Model	Average score	Score range	Attempts
gemini-3.1-pro-previewgoogle-vertex · opencode · 1.18.11	33.0%	33.0% – 33.0%	11 scored
GPT 5.6 Solopenai · opencode · 1.18.11	33.0%	33.0% – 33.0%	11 scored
Muse Spark 1.3 Contributoropencode · opencode · 1.18.11	22.0%± 11.0 pp SE	0.0% – 33.0%	33 scored

Averages and ranges use scored attempts on this exact version. Attempts without a score are counted separately. SE measures uncertainty across attempt scores.

The task

What the agent receives

# Build the version diff review

The platform snapshots the working database on a schedule (see
`platform/snapshots/`), and operators want to review two versions against each
other before deciding anything: "I made a mistake in Tuesday's edits — pull up
today against Tuesday 06:00 and tell me everything that changed, so I can
decide whether to roll back."

Implement `lib/versionDiff.mjs` exporting `computeVersionDiff` and
`computeVersionDiffDetails` as consumed by `bin/diff.mjs`, following the
response contracts in `contracts/versionDiff.schema.mjs` and the house
conventions in `contracts/README.md`. The diff must stay reviewable on real
databases: identity that survives the app's own flows, aggregated allocation
review, bounded payloads with a pager, and read-only execution against both
databases.

Check your work with
`node bin/diff.mjs snap-2026-07-26-0600` and
`node contracts/validate.mjs <saved-output.json>`.