>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3615672. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !196 >>> <p>A place's <code>position</code> is what every adjacency question in yoyaku_placement is answered from: <code>PlaceGeometry::run()</code> is consecutive positions, <code>fragments()</code> breaks where they skip, and <code>Together</code> seats a party together by taking them side by side. So a position is not a label and not a sort key. It is the claim that two seats touch, and nothing downstream can check it.</p> <p>Nothing derives it. Positions arrive with the venue, and a hall drawn on a plan is easy to number by sorting on x, which is right for a straight row and wrong for every row that turns: a balcony sweeping round the hall runs out of width and starts to climb, so an x-sort interleaves its two halves. Eleven rows of the bundled Auditorium de Bordeaux package are numbered that way. Its worst pair sits 1986 map units apart while holding consecutive positions.</p> <p><strong>Reproduced:</strong> a party of twelve booked across three tariffs was seated in two clumps a third of the hall apart, in one section and on consecutive positions, and reported as sitting together. The seating strategy was reading the positions correctly; the positions were the lie.</p> <p>A second defect with the same cause: positions have to run 1, 2, 3 within one <strong>area</strong>, because that is the only shape a run is read from, and a printed row numbered straight through when part of it belongs to a subsection leaves each half full of holes. The Auditorium's balcony had positions 1 to 9, then 12, 15, 19, 21 in one area, so a row of thirty-four free seats could not offer a run longer than nine.</p> <p>Note that the printed place number cannot be the ordering either: 35 rows of the same package are numbered outwards from the middle, so seats 1 and 2 sit beside each other at the centre, and some places are not numbered with numbers at all (35b).</p> <h3>Proposed fix</h3> <ul> <li>A <code>RowPath</code> service that recovers a row's order from the drawing: walk from one of the row's two ends (the furthest apart pair) to the nearest seat not yet walked. Which end comes first is not a geometric question, so the direction the venue already numbers in is kept, read from the whole row rather than from whichever seat holds position 1.</li> <li>A <code>PlacePositions</code> service that reports the rows disagreeing with the drawing, and renumbers them 1..N per area. Only places that actually move are saved, so a correct hall is untouched and running it twice changes nothing.</li> <li>Importing a venue package derives a drawn row's positions and logs how many rows it corrected.</li> <li><code>drush yoyaku:venue-positions &amp;lt;venue&amp;gt;</code> to check (exits non-zero on drift, so a deploy can gate on it) and <code>--fix</code> to repair.</li> <li>A Numbering tab on the venue that draws each row threaded in position order, since neither defect is visible from a list of places. An unbroken line follows the row; a line that doubles back does not.</li> <li>The shipped Auditorium package corrected: 265 places across 11 scrambled rows and 2 with holes.</li> </ul> <p>No change to any seating strategy or to <code>PlaceGeometry</code>: they were reading the data correctly. No change to the booker's map payload either, since the drawing already carried <code>position</code>.</p>