PuzzleTeam defines the rules as:
Hashi is played on a rectangular grid with no standard size. Some cells start out with numbers from 1 to 8 inclusive; these are the islands. The rest of the cells are empty. The goal is to connect all of the islands into a single connected group by drawing a series of bridges between the islands. The bridges must follow certain criteria:
How I actually solve one — the reasoning I run before any code does, written out in full. Underneath the drawing, Hashi is a graph problem: the islands are vertices, the bridges are edge capacities, and the whole solve is capacity bookkeeping plus one global connectivity argument. Read down the right column; the board on the left follows whichever step you are on.
A Hashi board looks like a drawing puzzle, but I never treat it as one. The islands are the vertices of a graph; two islands that face each other along a clear row or column are joined by a potential edge; and solving means assigning every edge a bridge count from . Each island pins down the sum over its own edges:
Before touching anything I run one sanity check. Every bridge has two ends, so the printed numbers must pay for an even total — the handshake identity every graph obeys:
The one thing the grid adds to the graph is geometry: two potential edges that pass through the same water cell are mutually exclusive, because bridges may not cross. I record those exclusions once, up front — and from that point on the board is pure bookkeeping. The drawing never matters again.
The robotic solver on real boards: the daily puzzle comes straight from the API, and the samples — 7×7 · Easy up to 40×50 · Special — replay recorded solver runs move by move.