# Reference patch — 01-bigger-board-longer-line

The answer key for how the reference absorbs this change. **Never shipped to the candidate.**

**No file changes at all.** `Entry.create(int, int)` already exists, `TicTacToeFactory.of` already
takes the size and the win length as arguments, `StandardGrid` is already sized by its
constructor argument rather than a constant, and `WinRule` already scans for `winLength` in a
row rather than a hardcoded 3. A 4x4 board where 4 in a row wins is not a new case the reference
had to be taught — it is the same code asked a different question, which it already knew how to
answer.

## Measurement

`reference_diff = 0` (no file in `reference/src/` differs at all), so
`diff_budget = max(3, 0 + ceil(0/2)) = 3`, the floor.

Both suites are green: the curveball suite **5 tests, 5 passed**, and the base suite
**17 tests, 17 passed** — nothing here touches the standard 3x3 game.

## What this curveball actually measures

It reads like a feature and is really a check that the base problem's own headline requirement —
"the board size and the win length should be configurable at construction" — was actually built
that way, and not merely accepted as a `size` parameter that the win-detection code silently
ignored in favour of a hardcoded 3. A design that wrote `for (int i = 0; i < 3; i++)` anywhere in
its line-scanning would pass every base test (which never asks for anything but 3-in-a-row) and
fail this one, with no code to point at — because the bug is an assumption, not a missing
feature. `WinRule.completesLineAt` counts a run in each of the four directions and compares it to
`winLength`; there is no length written into it anywhere but the field the constructor was given.
