Units correctness: exact imperial entry, garden grid at dimension scale (#47) #60

Merged

steve merged 2 commits from fix/units-correctness into main 2026-07-21 04:50:49 +00:00

Conversation 4 Commits 2 Files Changed 7

+204 -57

2 Commits

Author	SHA1	Message	Date
steveandClaude Opus 4.8	0169e32584	Address Gadfly review on the units fix ... Five findings, all fair: The soft-minimum hint contradicted itself. "did you mean ft?" made sense when the grid field was labelled inches sitting under a feet field — which is exactly what this PR removed. The remaining failure mode is different: someone reaching for plant spacing, which belongs to the bed, not the garden. The hint now says that, and points at where the bed grid actually lives. The stale "1 typed meaning one foot" comments went with it. gridNote was a three-level nested ternary; it is now gridNoteFor, with the same logic in explicit branches and the reasoning in one doc comment rather than threaded between the arms. cmFromDisplay(parseFloat(gridSize), unit) was computed once for the hint and again in the submit handler. Hoisted to a single per-render value so the two can't disagree about what was entered. roundCm's comment called the 1e-6 cm grain "1 nanometer"; it is 10 nm. Corrected — the constant was always fine, only the comment was wrong. Extracted the duplicated overlay-badge class string. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ	2026-07-21 00:49:23 -04:00
steveandClaude Opus 4.8	782f2394b2	Units correctness: exact imperial entry, garden grid at dimension scale ... Three compounding defects in the measurement layer (#47), measured against the live Home garden rather than estimated. Entry was quantized to whole centimeters even though every measurement column is REAL and the server only range-checks. A 12in grid stored 30cm — an 11.811in grid, short by 0.189in per cell, and because the error is systematic it accumulates: 4.61in of drift across a 24ft garden. cmFromFtIn / cmFromMeters / cmFromSpacing now convert exactly, rounding only at 1e-6 cm to clear IEEE-754 dust (12 x 2.54 is 30.479999999999997 in binary). Display-side rounding is untouched, so cm quantization still can't show through in a field. The garden grid was entered at spacing scale: "Grid size (in)" sat directly under "Width (ft)", two adjacent numeric fields at two different scales distinguished only by a suffix. Home ended up on a 3cm grid, almost certainly "1" typed meaning one foot. The garden grid is a layout concern, so it moves to dimension scale and reads "Garden grid (ft)"; the bed grid in the object inspector is a plant-spacing concern and deliberately stays at cm/in. A sub-10cm garden grid now draws a soft warning rather than being silently accepted. Snap could stay active while the grid stopped drawing: the canvas faded the grid out below 6px per cell, so Home ran with snapToGrid on, no grid drawn, and no snapping you could feel. Replaced the fade with coarsening — visibleGridStepCm picks the smallest multiple of the true grid (2x, 5x, 10x...) whose cells are legible, so every line drawn is still a real grid line and something aligned to the grid is always visible. When the drawn step isn't the true grid the canvas says so; a degenerate grid it can't draw at all says that instead of nothing. Closes #47 Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ	2026-07-21 00:38:06 -04:00