Schedule the terminal cranes to dispatch every container in order

A container terminal is a 5 x 5 yard. Containers pour in through five receiving gates on the left edge and must leave through five dispatch gates on the right edge in a strict order. You command five cranes — one big crane that can hoist a container high and glide over other stacks, and four small cranes that must keep their load low and cannot pass over an occupied square. Every turn you move all cranes at once. Mis-order a dispatch, send a container out the wrong gate, or leave one stranded and the yard is fined enormously; do it cleanly and your only cost is the number of turns you took. Your job is to choreograph the cranes so every container is dispatched from its correct gate, in order, in as few turns as possible.

Hard Constraints

The yard. An N x N grid, N = 5. Cell (0,0) is the top-left; (i,j) is i cells down and j cells right. N^2 = 25 containers numbered 0 .. 24 enter the yard.

• Receiving gates (left edge, column 0): from the gate at (i,0), N containers arrive one at a time. The j-th container to arrive at row i is A[i][j] (given in the input). The next container in a row's queue only materialises at (i,0) once that cell is empty (and no crane is holding a container while parked on it).
• Dispatch gates (right edge, column N-1): any container placed on (i,N-1) is dispatched instantly (it leaves the board at the end of that turn). Gate (i,N-1) is supposed to dispatch containers N*i, N*i+1, ..., N*i+N-1, in that order.
• Every square (gates included) holds at most one container. Non-dispatch squares are free scratch space for reordering.

Initially the big crane (crane 0) sits at (0,0) and the small cranes 1..N-1 sit at (1,0) .. (N-1,0). Every crane starts empty. The first container of each row is already sitting on its receiving gate at turn start.

Cranes and moves. Crane 0 is the big crane: while carrying a container it may still move onto a square that already holds a container. Cranes 1..N-1 are small: while carrying a container they may not move onto a square that holds a container. (Empty, any crane may move onto an occupied square.) Each turn you issue one action per crane simultaneously:

• P — pick up the container on the current square (illegal if the crane already holds one, or the square is empty).
• Q — put down the held container on the current square (illegal if the crane holds nothing, or the square is already occupied).
• U/D/L/R — move one square up / down / left / right (illegal to leave the board; the small-crane carrying restriction applies).
• B — retire this crane (illegal while holding a container). A retired crane is removed from the yard for good and no longer occupies a square.
• . — do nothing.

Collisions are illegal and abort the run: after a turn no two (non-retired) cranes may occupy the same square, and no two may swap squares. Any illegal action anywhere makes the whole output invalid and forfeits that case.

Beyond the game rules:

• Submit an algorithm, not precomputed answers — the grader re-runs your code on instances you have never seen. Do not key on seeds or instance names.
• /app/methods/main/ is what gets graded. Keep the run.sh contract below.
• Each sealed case runs your run.sh under a wall-clock cap of 20 s. A crash, timeout, or malformed output forfeits that case.
• There is no network at run time, on the workbench or in the grader. Python 3, g++ and a JDK 17 are available in both; anything else you have to write yourself.

What You Have

• tools/in/ — 100 visible instances (seeds 0-99).
• tools/gen — the generator. Make more instances with ./tools/gen seeds.txt --dir=OUTDIR, one unsigned-64-bit seed per line. For local testing use seeds in 0..10000 only — the sealed grading seeds live far outside that range, so staying inside it keeps your practice set from colliding with the hidden set.
• tools/vis — the visualiser/judge, the same one the grader uses: ./tools/vis in.txt out.txt prints Score = <absolute score> and writes a vis.html you can open.
• python3 selfcheck.py [N] — free and unlimited: runs your run.sh on the first N visible cases (default 100) and prints each case's raw score.
• methods/main/solution.py — a crude single-big-crane sequential dispatcher, yours to rewrite or delete.

The instance arrives on stdin:

N
A[0][0] A[0][1] ... A[0][N-1]
...
A[N-1][0] ... A[N-1][N-1]

N = 5. Row i lists the N containers arriving at receiving gate (i,0) in arrival order. The N^2 values are a permutation of 0 .. N^2-1.

What You Submit

Leave your best solver in methods/main/:

• run.sh (required): run once per test case as bash run.sh < instance.txt > out.txt. It must read one instance on stdin and write the operation grid on stdout. Any language.
• build.sh (optional): if present, the grader runs it once before grading (e.g. to compile a C++ or Java solver). Do your compilation here and have run.sh exec the built binary.

The operation grid on stdout is exactly N lines. Line i is the string of actions for crane i over successive turns, each character one of P Q U D L R B .. Lines may differ in length; a line shorter than the longest is padded with . (idle). The number of turns is the length of the longest line, and each line must be non-empty and at most 10000 characters.

There is no submit step and no per-attempt feedback. Work and self-check for as long as your run window allows, then leave your best run.sh in place.

How It Is Judged

The grader reruns your run.sh on 200 sealed instances you never see, drawn from the same generator, and scores each with the same visualiser. For one case, let

• M0 = number of turns (the length of the operation grid),
• M1 = total inversions among correctly-dispatched containers: for each gate i, over the containers it dispatched that belong to it (N*i <= b < N*(i+1)) in dispatch order, count pairs that are out of increasing order,
• M2 = number of containers dispatched from the wrong gate,
• M3 = number of containers never dispatched.

The absolute score is

M0 + 100*M1 + 10000*M2 + 1000000*M3      (LOWER is better)

A perfect run dispatches all 25 containers from the right gates in order, so its score is just the turn count M0. The huge weights on M2/M3 mean an incomplete or mis-routed plan scores in the tens of thousands or millions — far worse than any honest turn count. Get a fully-correct plan first, then shorten it. Scoring is per case and then aggregated, so a case you forfeit cannot be carried by a case you optimise.

How the raw scores map to the final reward is deliberately not disclosed — optimise the raw score itself. The starter as shipped is the zero of that scale: submitted unchanged it scores 0.