Dart Style in Haskell

A production code formatter is a full language frontend plus a constraint solver: it must scan and parse the entire language (every declaration form, expression, comment placement, and string interpolation) and then choose line splits that satisfy a page width while matching thousands of precedents byte for byte. Dart's formatter is harder still because it has two complete layout engines: the classic "short" style and the current "tall" style, with different splitting rules and trailing-comma handling.

The agent is handed tests, not source: the workspace contains no formatter implementation to port from, only the formatter's input/expected-output test corpus. The behaviour has to be reconstructed from what those cases pin down, in Haskell.

Implement the Dart code formatter as a Haskell executable named dart-style that reads Dart source on stdin and writes the formatted result to stdout, working in the provided cabal project at /app/dart-style/.

• Changes are confined to .hs files under src/; the build configuration (dart-style.cabal, cabal.project) is fixed and language extensions go in per-file pragmas.
• Both formatting styles must work, selected by --style short|tall, along with arbitrary --page-width and --indent values, --compilation-unit versus --statement parsing, and --trailing-commas automate|preserve.
• Correctness is byte-exact: each corpus case feeds input on stdin and compares stdout against the expected output byte for byte.
• cabal build all must succeed and cabal list-bin dart-style must locate the executable.

A compiling cabal scaffold at /app/dart-style/, an /app/README.mdspelling out the build commands and the full CLI contract, and the formatter's test corpus at /app/tests/: short/ and tall/ .stmt/.unit case files plus large real-world benchmark/ inputs. A provided /app/run-tests.shbuilds the project and runs the corpus (all of it, a matching subset, or with per-case mismatch diffs), backed by a documented Python runner the agent can reuse for its own tooling. GHC 9.6.7 and cabal 3.12 are preinstalled with the scaffold's dependencies cached for offline use; the machine is offline and a sandbox-timer CLI reports the remaining budget. The real Dart SDK is baked into the image for verification only and is not reachable by the agent.

A clean-room verifier, separate from the agent's environment, reconstructs the graded project from a pristine baked scaffold plus only the agent's .hs sources, strips the Dart runtime, clean-rebuilds with cabal as a non-root user, and runs a root-only scored corpus of roughly 5,000 cases. The scored corpus is a perturbed rendering: the same pinned dart formatre-renders every case at a different page width and indent at image build, so memorising the visible corpus's expected outputs does not transfer.

• The reward is byte-exact passes divided by scored cases, where scored cases are the changed-input cases the pinned reference formatter passed at image build. Unchanged-input cases (about 11% of the corpus) are excluded from both numerator and denominator, so copying stdin to stdout scores 0.
• Hard gates: a failed build or missing executable, a reachable Dart runtime, or submitting the unmodified starting scaffold zeroes the result.
• Each case runs under a fixed 30-second timeout and the whole suite under a fixed 4600-second deadline; tripping the deadline records an invalid run rather than a partial score.