Bench round 3, 2026-09-11, on the user's ZONA over `npm run dev` (localhost), EUCLID, row 1 of the
Phase 12 gate's twelve. Verbatim:

> calibration is still waay off. i need to tap multiple times on a LED to react. putting a fingertip
> between two leds and nothing happens, its just not reliable at all.

Asked whether the lit cell is under the finger or offset:

> not really. for example if my finger is directly on top of the LED in row 2 column 8 the top right
> LED lights up, same in each corne. so its not precise.
> I mean it never can be precise as the motion detector are not directly under the LEDs. that's why
> each config should work with gradient lighting. so if i touch between two LEDs both should light up
> dimly and if I move in one direction that should be brighter. the same should happen if I touch in
> the middle of a 4 LEDs. each should light up and only the brightness should change depending how I
> move my fingers. The module doesnt only send 9x9 messages, it sends a lot more. LEDs should
> indicate that

Orchestrator's reading, confirmed by the user ("continue"): two problems. (1) The sensor-to-LED map
is uncalibrated - the outer LEDs are reached before the finger is over them; nobody has measured the
value the sensor reports with a finger centred on each LED. (2) Phase 12's library renders a finger
as one cell (Q's hit-test with hysteresis); the sensor is not under the LEDs, so the finger must be
drawn bilinearly across the 2x2 LEDs around it, weighted by distance, and any discrete choice an
entry needs comes from those weights. This is Phase 12.1. It lands before 13-14 (the Sandbox
compiler would otherwise inherit the cell model). 13-07..13-13 do not depend on it.

Rows 2-12 of the gate's bench were not run this round.

## Probe C, run 1 (11:43:50 - 11:44:31), CC20 = x, CC21 = y, CC22 = target

| target | cell | x | y |
|---|---|---|---|
| 1 | 36 | 1 | 61 |
| 2 | 37 | 13 | 63 |
| 3 | 38 | 29 | 61 |
| 4 | 39 | 46 | 62 |
| 5 | 40 | 64 | 68 |
| 6 | 41 | 85 | 66 |
| 7 | 42 | 100 | 62 |
| 8 | 43 | 120 | 64 |
| 9 | 44 | 126 | 60 |
| 10 | 4 | 127 | 68 | <- not a row-0 reading: x is the right edge; a re-tap after a dropped lift at target 9. Discarded. |
| 11 | 13 | 65 | 12 |
| 12 | 22 | 65 | 26 |
| 13 | 31 | 66 | 48 |
| 14 | 49 | 65 | 83 |
| 15 | 58 | 66 | 97 |
| 16 | 67 | 65 | 115 |
| 17 | 76 | 67 | 126 |
| 18 | 0 | 1 | 0 |
| 19 | 8 | 127 | 0 |
| 20 | 72 | 0 | 127 |
| 21 | 80 | 127 | 126 |

Derived (orchestrator, to be checked by the planner):
KX = 1, 13, 29, 46, 64, 85, 100, 120, 126   (steps 12, 16, 17, 18, 21, 15, 20, 6)
KY = [0], 12, 26, 48, 68, 83, 97, 115, 126   (KY[0] from corners 18 and 19, both y = 0; steps -, 14, 22, 20, 15, 14, 18, 11)
The sensor saturates inside the outer LED on the high side of both axes (LED 7 -> LED 8 is 6 units
in x, 11 in y) and is nearly linear elsewhere at ~17 per LED. Corners agree with the knots within
2 units: separable. The user's "row 2 / column 8 lights the corner" follows: x = 120 under the
naive 128/9 map is cell 8.
Hand/flatness not reported. A second pass would give target 10 directly.

## Decision, 2026-09-11

Asked "Use 255/6 (the system Timer) as the library's second slot? It means HANGAR writes a fourth
string to the module and PUT BACK restores it", the user answered: "yes". Phase 12.1 builds the
library across 255/0 and 255/6. The KEEP-once-during-the-bench question is still open.
