Flipping retail from selling to counting surfaced a different set of gaps

⁠Build log series⁠: I hand a real screen to an AI that has never seen Gunjo (@gunjo/ui) and let it build. Retail screen two: a ⁠physical inventory count⁠ (reconciling book stock, counted stock, and the variance, by location, with barcodes, variance reasons, and inventory value).

The working policy: at least three to five screens per industry, each as different as possible, with industry-specific UI first. So I picked the mirror opposite of #42's register (the selling side): back-room inventory operations. Not ringing up sales, but counting and reconciling.

Result: 4.5/5

tsc and build passed, the console stayed clear, 375px (a handheld terminal) switched to cards, variances rendered with sign, arrow, color, and an sr-only label, a variance reason was required and blocked confirmation when empty, and the page had a single h1.

Again this round: the money and form components fit a mirror-opposite screen

Even with the job reversed from the register, the components carried straight over. The agent's notes:

• ⁠EditableDataTable (issue #199): used without changes. The best fit here. This is exactly a reconciliation grid.⁠ Book stock read-only, counted stock editable, variance auto-calculated, variance reason as a Select, getRowError, automatic mobile cards.
• ⁠RevealSection (issue #213): used without changes.⁠ When a variance is nonzero, the reason reminder appears through role="region" plus aria-live and clears once a reason is filled in.
• ⁠NumberInput (stepper): used without changes.⁠ value ?? undefined distinguishes "not counted yet" from zero.
• ⁠formatCurrency {signed} (issue #180): eleven rounds straight.⁠ Signed yen on variance amounts (a negative ¥5,880 at cost, a negative ¥10,458 at retail).

What I fixed this round: Progress had no accessible name

One clear defect this time:

• 🟡 ⁠Progress carries no accessible name⁠ (it has role="progressbar" and the aria values, but a screen reader hears only a bare percentage, and axe flags it). I added ⁠label (wired to aria-label) and valueText (wired to aria-valuetext, as in "42 of 120 done")⁠ (issue #219, ⁠verified in a real browser⁠).

Logged, not built (not yet at three)

• 🟠 ⁠Barcode and SKU scan input⁠ (scan, match, increment, announce: the heart of retail, issue #220, first sighting).
• 🟠 ⁠A minimal inline variance or delta display⁠ (a signed number, an arrow, and a color that fit inside a table cell; Statistic is a card and does not fit). Profit-and-loss in #33 plus the variance here make issue #221 a second sighting.

What I took away: rotate the job and different gaps fall out

Retail #42, the register (selling): gaps in change counting, receipts, yen-or-percent discounts
Retail #43, the stocktake (counting): gaps in scan input, variance display, and Progress naming

Within one industry, flipping the job to its opposite keeps the shared components effective (money, grid, reveal) while surfacing ⁠the gaps specific to that screen⁠ (scanning, variance display). "Three to five screens per industry, as different as possible" turns out to be how you get a three-dimensional read on an industry. The money family is strong across the board; retail's operational side (scanning) is what grows next.

Next up: build log #44

• ⁠One more retail screen⁠ (returns or a register close) to push scanning and change counting toward a third sighting, or a new industry.

The run

• ⁠gunjo.jp⁠ / npm @gunjo/ui / ⁠GitHub⁠
• Earlier rounds: #1 through #42
• ⁠GunjoUI by UIXHERO⁠

Gunjo was still in early alpha at the time; issues are welcome.