Owner review on PR #61:
- п.9 (option B). Hide the native spinner on EVERY numeric input in
the calculator (DWSC blocks, armament, tech, planet MAT, custom
load, lock value, modernization target tech) and drive every step
through ArrowUp / ArrowDown. The column widths stay stable and the
inputs read consistently across the whole row. The ship blocks
keep the smart (0 ↔ 1) jump on ArrowUp/ArrowDown; armament steps
±1 with a JS handler instead of relying on the native spinner.
Other inputs step by their natural grain (±0.001 for tech / lock,
±0.01 for MAT / load).
- п.10. Tech-level labels (`tech-val`) and the planet MAT label
(`mat-val`) now read through the same `Ceil3` formatter as the
derived results, so plain-text numeric values share the report's
3-decimal tabular formatting. The design-area component receives
`formatNumber` as a prop; the resolved (goal-seek) cell uses the
same formatter, so the read-only computed value matches the rest
of the row.
- п.12. `computeCalculator` now validates the back-solved block
against the same DWSC rule the live validator enforces (`0` or
`≥ 1`). When the solver lands in the `(0, 1)` gap (e.g. attack
0.5 / weaponsTech 1.5 → weapons 0.333…) the lock is flagged
infeasible — the lock input flips red and the claimed block is
NOT back-solved into the invalid range, so the design preview
keeps reading the user's own typed values instead of silently
showing a sub-1 block.
- new. Selecting an existing ship class from the name datalist now
loads it immediately. `change` fires only on blur in Firefox,
which is why the previous behaviour looked delayed; switching the
load to `oninput` with an `InputEvent.inputType` check makes the
load synchronous everywhere (datalist replacement carries
`"insertReplacementText"` in Chromium / WebKit, `undefined` in
Firefox; keyboard typing always carries a typing `inputType`).
Before loading we compare the live blocks to the previously
loaded class (or to the empty defaults) and, if they differ, ask
through a `window.confirm`. On decline we revert the name field
and leave the design untouched.
Tests: calculator-tab and calc-model gain six cases (armament
step, tech/MAT formatter labels, lock infeasible on (0, 1) for
both attack→weapons and emptyMass→cargo, lock-value Arrow step,
dropdown immediate load + confirm-blocks-load + confirm-allows-load),
all 779 vitest tests green. docs/calculator-ux.md follows the new
behaviour.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Fuse the standalone ship-class designer (Phases 17/18) into a sidebar calculator: live mass/speed/attack/defence/bombing results, a planet build-rate readout, single-target goal-seek, a modernization-cost mode, and auto reach circles on the map for the selected planet.
pkg/calc becomes the single source for the new math (no mirroring): extract BombingPower from the engine model and the per-turn ship-production loop from controller.ProduceShip into pkg/calc (engine now delegates), and add inverse goal-seek solvers in pkg/calc/solve.go. Thin-bridge the combat, planet-build, and solver functions through ui/core/calc + ui/wasm and rebuild core.wasm.
Remove the standalone designer view/route; the ship-classes table and the view/bottom menus open the calculator via a shared request store.
Docs: rewrite ui/PLAN.md Phase 30, adjust Phase 34 (realistic forecast + CAP/COL ownership), add ui/docs/calculator-ux.md, extend calc-bridge.md, fix navigation.md; remove ui/CALCULATOR.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Ilia Denisov