Imperial dimension fields took decimal feet rounded to 0.1 ft — which is 1.2 inches, so of the whole-inch marks in a foot only 0", 6" and 12" were exactly representable. Type 2.58 and the field redisplayed 2.6: the value stored fine, but what you typed and what you saw disagreed.
Two things made that read as an oversight rather than a decision. The app already speaks feet and inches, just not where you edit — formatCm renders 24′ 0″, so the garden card said 24′ 0″ × 24′ 0″ while the dialog beside it said Width (ft) 24. And cmFromFtIn(feet, inches) has always taken an inches parameter no caller ever passed.
What parses
parseDimension accepts 2' 7", 2′ 7″, 2ft 7in, 2' 7, 31", 2', and a bare 2.5 still meaning 2½ feet — so nothing anyone has typed before now breaks. Typographic quotes and unicode minus are normalized, so pasted text behaves like typed text. Garbage returns null and commits nothing; never a silent zero, which would turn a typo into a destructive edit.
formatDimensionInput renders it back as 2′ 7″, with one decimal inch (7′ 10.5″) rather than whole inches — 0.1″ is ~0.25 cm, so what's displayed stays honest about what's stored.
Metric entry is unchanged (decimal meters, optional m) and deliberately does not accept feet syntax.
The two sharp edges the issue called out
The sign applies to the whole value.-2' 6" is −(2ft + 6in) = −30″, not −2ft + 6in = −18″. The naive implementation attaches the sign to the feet term and gets −18″; splitSign peels it off the whole entry first, and there's a test for exactly that (including the unicode minus).
The no-op guard changed shape. It compared the parsed value against displayFromCm(current), which is what stopped a blur-without-edit from drifting the value. With compound entry there's no single display number to compare against — and a numeric tolerance has a nastier failure: a bed dragged on canvas to an arbitrary cm renders as 2′ 7.9″, and merely tabbing through the field would snap it to a whole inch.
It now compares the field's text against the string that field renders for the current value. That means "you didn't edit this" exactly, with no tolerance to pick. Typing the same value a different way (2' 7" vs 2′ 7″) falls through to the cm comparison and is still a no-op.
Mobile keyboards — the open question, decided
Imperial fields get inputMode="text", because ' and " are on no numeric keypad and inputMode="decimal" would make compound entry impossible on a phone. Metric keeps inputMode="decimal" since it never needs them. A bare number still means feet, so the keypad path stays usable either way.
This is the bit that wants checking on an actual phone before it's called settled — it's noted on #58 as something to watch.
Also
Includes the garden grid field, which #47 moved to dimension scale. Leaving it a number input beside two compound ones would have recreated the same two-scales-in-one-row confusion #47 removed.
cmFromDisplay is deleted — parseDimension is the entry path now and nothing else called it.
Unparseable input in the garden form gets a hint that names the accepted forms rather than "invalid input".
Verification
52 tests. Every whole-inch mark from 0″–12″ round-trips exactly; both quote styles and the spelled-out units parse; -2' 6" is −30″; a dragged position renders 2′ 7.9″ and not a whole inch; garbage is rejected in both unit systems. tsc --noEmit, npm run build, go test ./... green.
Closes #59. Phase 0 of #58, on top of #47.
Imperial dimension fields took decimal feet rounded to **0.1 ft — which is 1.2 inches**, so of the whole-inch marks in a foot only `0"`, `6"` and `12"` were exactly representable. Type `2.58` and the field redisplayed `2.6`: the value stored fine, but what you typed and what you saw disagreed.
Two things made that read as an oversight rather than a decision. The app **already speaks feet and inches, just not where you edit** — `formatCm` renders `24′ 0″`, so the garden card said *24′ 0″ × 24′ 0″* while the dialog beside it said *Width (ft) 24*. And `cmFromFtIn(feet, inches)` has always taken an inches parameter no caller ever passed.
### What parses
`parseDimension` accepts `2' 7"`, `2′ 7″`, `2ft 7in`, `2' 7`, `31"`, `2'`, and **a bare `2.5` still meaning 2½ feet** — so nothing anyone has typed before now breaks. Typographic quotes and unicode minus are normalized, so pasted text behaves like typed text. Garbage returns `null` and commits nothing; never a silent zero, which would turn a typo into a destructive edit.
`formatDimensionInput` renders it back as `2′ 7″`, with **one decimal inch** (`7′ 10.5″`) rather than whole inches — 0.1″ is ~0.25 cm, so what's displayed stays honest about what's stored.
Metric entry is unchanged (decimal meters, optional `m`) and deliberately does *not* accept feet syntax.
### The two sharp edges the issue called out
**The sign applies to the whole value.** `-2' 6"` is −(2ft + 6in) = **−30″**, not −2ft + 6in = −18″. The naive implementation attaches the sign to the feet term and gets −18″; `splitSign` peels it off the whole entry first, and there's a test for exactly that (including the unicode minus).
**The no-op guard changed shape.** It compared the parsed value against `displayFromCm(current)`, which is what stopped a blur-without-edit from drifting the value. With compound entry there's no single display number to compare against — and a numeric tolerance has a nastier failure: a bed dragged on canvas to an arbitrary cm renders as `2′ 7.9″`, and merely *tabbing through* the field would snap it to a whole inch.
It now compares the field's **text** against the string that field renders for the current value. That means "you didn't edit this" exactly, with no tolerance to pick. Typing the same value a different way (`2' 7"` vs `2′ 7″`) falls through to the cm comparison and is still a no-op.
### Mobile keyboards — the open question, decided
Imperial fields get `inputMode="text"`, because `'` and `"` are on no numeric keypad and `inputMode="decimal"` would make compound entry impossible on a phone. Metric keeps `inputMode="decimal"` since it never needs them. A bare number still means feet, so the keypad path stays usable either way.
**This is the bit that wants checking on an actual phone** before it's called settled — it's noted on #58 as something to watch.
### Also
- Includes the **garden grid field**, which #47 moved to dimension scale. Leaving it a number input beside two compound ones would have recreated the same two-scales-in-one-row confusion #47 removed.
- `cmFromDisplay` is deleted — `parseDimension` is the entry path now and nothing else called it.
- Unparseable input in the garden form gets a hint that names the accepted forms rather than "invalid input".
### Verification
52 tests. Every whole-inch mark from 0″–12″ round-trips exactly; both quote styles and the spelled-out units parse; `-2' 6"` is −30″; a dragged position renders `2′ 7.9″` and not a whole inch; garbage is rejected in both unit systems. `tsc --noEmit`, `npm run build`, `go test ./...` green.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ
Imperial dimension fields took decimal feet rounded to 0.1 ft, which is 1.2
inches — so of the whole-inch marks in a foot only 0", 6" and 12" were exactly
representable. Everything else was off by up to 0.6". Type 2.58 and the field
redisplayed 2.6: the value stored fine, but what you typed and what you saw
disagreed.
Two things made that read as an oversight rather than a decision. The app
already speaks feet and inches, just not where you edit — formatCm renders
24′ 0″, so the garden card said 24′ 0″ × 24′ 0″ while the dialog beside it said
Width (ft) 24. And cmFromFtIn(feet, inches) has always taken an inches
parameter no caller ever passed.
parseDimension accepts 2' 7", 2′ 7″, 2ft 7in, 2' 7, 31", 2', and a bare 2.5
still meaning 2½ feet, so nothing anyone has typed before now breaks.
formatDimensionInput renders the value back as 2′ 7″, with one decimal inch
(7′ 10.5″) rather than whole inches — 0.1" is about 0.25cm, so what is displayed
stays honest about what is stored. Metric entry is unchanged, decimal meters,
and deliberately does not accept feet syntax.
The sign applies to the whole value. -2' 6" is -(2ft + 6in) = -30", not
-2ft + 6in = -18". The naive implementation attaches the sign to the feet term
and gets -18"; there is a test for exactly that.
The no-op guard had to change shape. It compared the parsed value against
displayFromCm(current), which is what stopped a blur-without-edit from drifting
the value; with compound entry there is no single display number to compare
against, and a numeric tolerance has a nastier failure — a bed dragged on canvas
to an arbitrary cm renders as 2′ 7.9″, and merely tabbing through the field
would snap it to a whole inch. It now compares the field's TEXT against the
string that field renders for the current value, which means "you didn't edit
this" exactly. Typing the same value a different way falls through to the cm
comparison and is still a no-op.
The affected inputs move from type="number", which cannot hold 2' 7", to text.
Imperial gets inputMode="text" because ' and " are on no numeric keypad; metric
keeps inputMode="decimal" since it never needs them. A bare number still means
feet, so the keypad path stays usable on a phone either way — but this wants
checking on an actual phone before it's called settled.
Includes the garden grid field, which #47 moved to dimension scale: leaving it
as a number input beside two compound ones would have been the same
two-scales-one-row confusion #47 removed.
cmFromDisplay is gone; parseDimension is the entry path now and nothing else
called it.
Closes#59
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ
Live status board. Findings are posted in each model's own comment. Advisory only — does not block merge.
<!-- gadfly-status-board -->
## 🪰 Gadfly — live review status
2/5 reviewers finished · updated 2026-07-21 05:08:36Z
#### `claude-code/sonnet` · claude-code — ✅ done
- ✅ **security** — No material issues found
- ✅ **correctness** — Minor issues
- ✅ **maintainability** — Minor issues
- ✅ **performance** — No material issues found
- ✅ **error-handling** — Minor issues
#### `glm-5.2:cloud` · ollama-cloud — ⏳ 4/5 lenses
- ✅ **security** — No material issues found
- 🔄 **correctness** — running
- ✅ **maintainability** — Minor issues
- ✅ **performance** — No material issues found
- ✅ **error-handling** — No material issues found
#### `kimi-k2.6:cloud` · ollama-cloud — ⏳ 2/5 lenses
- 🔄 **security** — running
- 🔄 **correctness** — running
- ⚠️ **maintainability** — could not complete
- ✅ **performance** — No material issues found
- 🔄 **error-handling** — running
#### `opencode/glm-5.2:cloud` · opencode — ⏳ 3/5 lenses
- 🔄 **security** — running
- 🔄 **correctness** — running
- ✅ **maintainability** — Minor issues
- ✅ **performance** — No material issues found
- ✅ **error-handling** — No material issues found
#### `opencode/kimi-k2.6:cloud` · opencode — ✅ done
- ⚠️ **security** — could not complete
- ✅ **correctness** — No material issues found
- ✅ **maintainability** — No material issues found
- ✅ **performance** — No material issues found
- ✅ **error-handling** — No material issues found
<sub>Live status board. Findings are posted in each model's own comment. Advisory only — does not block merge.</sub>
formatDimensionInput signed values that had rounded to nothing, so a hair below
zero rendered "-0′ 0″" — wrong, and not something parseDimension round-trips.
The sign is now applied only once the rounded feet/inches are actually nonzero.
That fix wanted the decomposition in one place, which formatCm was duplicating
anyway, so both now share feetAndInches(cm, decimals) — magnitude only, sign
applied by the caller once it knows the result isn't zero.
Doing so incidentally fixed a latent bug in formatCm: it took Math.floor of a
negative total, so -76.2cm rendered "-3′ 6″", which reads as -(3ft+6in) = -42in
rather than the -30in it actually is. Nothing renders a negative dimension today
(formatCm is used for garden sizes), but it was wrong and now isn't.
The dimensionInputMode ternary and its comment were duplicated verbatim between
Inspector and GardenFormModal; it is now a helper in units.ts, where the reason
for it belongs anyway.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ
The -0′ 0″ catch was the real one: a hair below zero rounds to zero feet and zero inches, and signing that produced a string parseDimension doesn't round-trip. The sign is now applied only once the rounded result is actually nonzero.
Fixing it properly wanted the decomposition in one place — which formatCm was duplicating anyway — so both now share feetAndInches(cm, decimals), magnitude only, sign applied by the caller.
That incidentally fixed a latent bug in formatCm. It took Math.floor of a negative total, so -76.2 cm rendered -3′ 6″ — which reads as −(3ft + 6in) = −42″ rather than the −30″ it actually is. Exactly the sign-handling mistake #59 warned about for parsing, sitting in the formatter the whole time. Nothing renders a negative dimension today (formatCm is used for garden sizes, always positive), so it was never visible — but it was wrong, and now it isn't. Covered by a test.
dimensionInputMode was duplicated verbatim across two components, comment and all — now a helper in units.ts, where the reasoning belongs.
55 tests, tsc --noEmit, npm run build green.
All four Gadfly findings fixed in `62be7d9`.
The `-0′ 0″` catch was the real one: a hair below zero rounds to zero feet and zero inches, and signing that produced a string `parseDimension` doesn't round-trip. The sign is now applied only once the rounded result is actually nonzero.
Fixing it properly wanted the decomposition in one place — which `formatCm` was duplicating anyway — so both now share `feetAndInches(cm, decimals)`, magnitude only, sign applied by the caller.
**That incidentally fixed a latent bug in `formatCm`.** It took `Math.floor` of a *negative* total, so `-76.2 cm` rendered `-3′ 6″` — which reads as −(3ft + 6in) = −42″ rather than the −30″ it actually is. Exactly the sign-handling mistake #59 warned about for parsing, sitting in the formatter the whole time. Nothing renders a negative dimension today (`formatCm` is used for garden sizes, always positive), so it was never visible — but it was wrong, and now it isn't. Covered by a test.
`dimensionInputMode` was duplicated verbatim across two components, comment and all — now a helper in `units.ts`, where the reasoning belongs.
55 tests, `tsc --noEmit`, `npm run build` green.
steve
merged commit 3ec77a1099 into main2026-07-21 05:08:57 +00:00
steve
deleted branch feat/feet-and-inches-entry2026-07-21 05:08:58 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #59. Phase 0 of #58, on top of #47.
Imperial dimension fields took decimal feet rounded to 0.1 ft — which is 1.2 inches, so of the whole-inch marks in a foot only
0",6"and12"were exactly representable. Type2.58and the field redisplayed2.6: the value stored fine, but what you typed and what you saw disagreed.Two things made that read as an oversight rather than a decision. The app already speaks feet and inches, just not where you edit —
formatCmrenders24′ 0″, so the garden card said 24′ 0″ × 24′ 0″ while the dialog beside it said Width (ft) 24. AndcmFromFtIn(feet, inches)has always taken an inches parameter no caller ever passed.What parses
parseDimensionaccepts2' 7",2′ 7″,2ft 7in,2' 7,31",2', and a bare2.5still meaning 2½ feet — so nothing anyone has typed before now breaks. Typographic quotes and unicode minus are normalized, so pasted text behaves like typed text. Garbage returnsnulland commits nothing; never a silent zero, which would turn a typo into a destructive edit.formatDimensionInputrenders it back as2′ 7″, with one decimal inch (7′ 10.5″) rather than whole inches — 0.1″ is ~0.25 cm, so what's displayed stays honest about what's stored.Metric entry is unchanged (decimal meters, optional
m) and deliberately does not accept feet syntax.The two sharp edges the issue called out
The sign applies to the whole value.
-2' 6"is −(2ft + 6in) = −30″, not −2ft + 6in = −18″. The naive implementation attaches the sign to the feet term and gets −18″;splitSignpeels it off the whole entry first, and there's a test for exactly that (including the unicode minus).The no-op guard changed shape. It compared the parsed value against
displayFromCm(current), which is what stopped a blur-without-edit from drifting the value. With compound entry there's no single display number to compare against — and a numeric tolerance has a nastier failure: a bed dragged on canvas to an arbitrary cm renders as2′ 7.9″, and merely tabbing through the field would snap it to a whole inch.It now compares the field's text against the string that field renders for the current value. That means "you didn't edit this" exactly, with no tolerance to pick. Typing the same value a different way (
2' 7"vs2′ 7″) falls through to the cm comparison and is still a no-op.Mobile keyboards — the open question, decided
Imperial fields get
inputMode="text", because'and"are on no numeric keypad andinputMode="decimal"would make compound entry impossible on a phone. Metric keepsinputMode="decimal"since it never needs them. A bare number still means feet, so the keypad path stays usable either way.This is the bit that wants checking on an actual phone before it's called settled — it's noted on #58 as something to watch.
Also
cmFromDisplayis deleted —parseDimensionis the entry path now and nothing else called it.Verification
52 tests. Every whole-inch mark from 0″–12″ round-trips exactly; both quote styles and the spelled-out units parse;
-2' 6"is −30″; a dragged position renders2′ 7.9″and not a whole inch; garbage is rejected in both unit systems.tsc --noEmit,npm run build,go test ./...green.🤖 Generated with Claude Code
https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ
🪰 Gadfly — live review status
2/5 reviewers finished · updated 2026-07-21 05:08:36Z
claude-code/sonnet· claude-code — ✅ doneglm-5.2:cloud· ollama-cloud — ⏳ 4/5 lenseskimi-k2.6:cloud· ollama-cloud — ⏳ 2/5 lensesopencode/glm-5.2:cloud· opencode — ⏳ 3/5 lensesopencode/kimi-k2.6:cloud· opencode — ✅ doneLive status board. Findings are posted in each model's own comment. Advisory only — does not block merge.
All four Gadfly findings fixed in
62be7d9.The
-0′ 0″catch was the real one: a hair below zero rounds to zero feet and zero inches, and signing that produced a stringparseDimensiondoesn't round-trip. The sign is now applied only once the rounded result is actually nonzero.Fixing it properly wanted the decomposition in one place — which
formatCmwas duplicating anyway — so both now sharefeetAndInches(cm, decimals), magnitude only, sign applied by the caller.That incidentally fixed a latent bug in
formatCm. It tookMath.floorof a negative total, so-76.2 cmrendered-3′ 6″— which reads as −(3ft + 6in) = −42″ rather than the −30″ it actually is. Exactly the sign-handling mistake #59 warned about for parsing, sitting in the formatter the whole time. Nothing renders a negative dimension today (formatCmis used for garden sizes, always positive), so it was never visible — but it was wrong, and now it isn't. Covered by a test.dimensionInputModewas duplicated verbatim across two components, comment and all — now a helper inunits.ts, where the reasoning belongs.55 tests,
tsc --noEmit,npm run buildgreen.