Three screens in a row hand-rolled mobile cards, so DataTable got renderCard

⁠Build log series⁠: I hand a real screen to an AI that has never seen Gunjo (@gunjo/ui) and let it build. Banking screen five: a ⁠credit-card statement⁠ (a credit-limit gauge, points, spending by category, the transaction list, changing the payment method).

Banking, layer by layer: #32 forms, #33 charts, #34 tables, #35 calculators, and this round the ⁠limit gauge, loyalty points, and category spending⁠ layer.

Result: 4.5/5

tsc and build passed, the console stayed clear, 375px collapsed the statement into 25 cards, the gauge's used plus remaining equaled the limit, and the page had a single h1.

The main event: a missing component that appeared three rounds straight finally got built

DataTable scrolling horizontally on mobile (its min-w-[720px] floor) has now been worked around by hand ⁠three rounds in a row: the transaction history in #34, the amortization schedule in #35, and the statement here⁠ (first logged as issue #190 back in #34). So this time I built it:

🟠 ⁠At 375px, DataTable still renders a 720px table and scrolls it sideways.⁠ Mobile wants cards. Every round hand-rolls an sm:hidden card list.

The fix (issue #195, landed in the same PR)

⁠Added renderCard⁠ (opt-in, nothing existing breaks): pass it and md and up render the table while mobile renders ⁠the same sorted and paginated row data⁠ as cards, with no second copy of the state. ⁠Verified in a browser⁠: a table at 1280px, and at 375px no table, ten cards (already paginated), and ⁠no horizontal scrolling⁠.

"Build it only once the same missing component shows up three times." Run the cold test across industries and screen after screen, and ⁠the components people actually want float to the surface, by sheer frequency⁠.

The foundation still held: four rounds of compounding in a row

Once again, the agent praised strengths grown in earlier rounds:

• ⁠formatCurrency (issue #180), "excellent, the standout," for the fourth consecutive round.⁠ ¥371,650 with zero setup, compact for ¥372K.
• ⁠SegmentedGaugeCard was "a nearly perfect credit-limit gauge"⁠: used, remaining, and limit agree, and the tone steps from primary through warning to destructive as utilization climbs.
• ⁠GaugeChart⁠ announces "this month's spending: ¥200,000" through role="img" instead of being a mute arc.
• ⁠DonutChart⁠ legends carried percent plus yen, ⁠Badge⁠ covered the payment types (single, installments, revolving), ⁠Dialog⁠ recalculated fees with aria-live, and ⁠ThemeProvider⁠ (issue #171) worked from the start.

The rest of the gaps

• 🟠 No points or loyalty panel component (assembled from Card, Statistic, and Alert: acceptable).
• 🟡 The gauge and donut carry fixed max-w-* (they shrink, but cannot grow into a wide column).
• 🟡 defaultChartValueFormatter is still en-US (issue #197, a sequel to issue #180; passing formatValue avoids it).

What I took away: frequency surfaces the components worth building

#34 transaction history:    table-to-card hand-rolled
#35 amortization schedule:  table-to-card hand-rolled (again)
#36 card statement:         table-to-card hand-rolled (third time), so renderCard shipped (issue #195)

One "nice to have" is never enough. ⁠The same hand-roll three screens in a row is proof of a component people actually need.⁠ This is where running the cold test at volume pays off.

Next up: build log #37

• ⁠Five banking layers down.⁠ On to the adjacent money-heavy industries (accounting, payroll, POS), to see whether the bank-grown formatCurrency, renderCard, and gauges carry over.

The run

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

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