A POS register ran on money components that grew up in banking

⁠Build log series⁠: I hand a real screen to an AI that has never seen Gunjo (@gunjo/ui) and let it build. This round switched industries to retail: a ⁠POS register checkout⁠ (cart line items, reduced tax rates, cash tendered and change, payment methods, receipt).

Result: 4.5/5

tsc and build passed, the console stayed clear, the 375px layout (a tablet register) switched to cards, the per-rate tax breakdown came out exact, insufficient cash blocked the checkout, and the page had a single h1.

The star this round: the money components carried into yet another industry

The money and form components grown through banking, accounting, and payroll all got used by the agent on a retail POS screen. Its notes:

• ⁠CurrencyInput (issue #176): used it⁠ for cash tendered and yen discounts. Keeps an internal text draft so digit grouping holds while typing, returns a number, clamps with min and max, forwards ARIA attributes. It rerendered cleanly from externally controlled values when the quick-cash buttons fired. ⁠Zero friction.⁠
• ⁠EditableDataTable (issue #199): used it, the standout⁠ for the cart lines. Quantity steppers, tax-rate badges, auto-calculated amounts, renderFooterCell, and automatic mobile cards. ⁠This is the component that made the screen cheap to build.⁠
• ⁠RevealSection (issue #213): used it⁠ for the cash-shortage block, the cashless hint, and the member panel. role="region" plus aria-live gives conditional sections exactly the right accessibility. ⁠Worked as intended.⁠
• ⁠formatCurrency (issue #180): on 100% of the displayed amounts.⁠ Ten rounds in a row.

⁠RevealSection, built in the previous round, was picked up by the very next round's agent in a different industry.⁠ The compounding crossed one more industry line. Fintech, accounting, payroll, retail: any screen that handles money can now be assembled from this same family.

The new gaps are POS-specific composites

What blocked a perfect score were the register-specific composite patterns:

• 🟠 ⁠No numeric keypad or checkout input pad⁠ (the biggest one). The agent hand-rolled the cash-tendered flow, quick-cash buttons, change, and the shortage block (issue #216, first POS sighting).
• 🟠 ⁠No receipt or print layout⁠ (issue #217, first POS sighting).
• 🟠 ⁠No MoneyOrPercent for yen-or-percent discounts⁠ (hand-rolled on the invoice screen in #37 and again here, issue #218, second sighting).

⁠No new component shipped this round either. The rule of three holds: a missing component gets built only after three separate screens have needed it independently.⁠ The POS composites sit at one or two sightings, below the threshold. Logged honestly, nothing more.

What I took away: the rule of three prevents overbuilding

table-to-card (issue #190): built after three sightings, #34, #35, #36
CurrencyInput (issue #176): built after four sightings, #32 through #40
MoneyOrPercent (issue #218): second sighting (the invoice screen in #37 plus this register), not built yet

The value of running this test at volume is that frequency surfaces the components worth building. The reverse also holds: while frequency is low, nothing gets built. Building from a single "nice to have" is how a library bloats. Counting change and printing receipts feel intensely POS-specific, but they await a second appearance. With the money family mature, disciplined decisions not to build are part of growing the library too.

Next up: build log #43

• ⁠Another industry⁠ (medical or logistics), or a second retail screen (inventory or returns) to recheck change counting and receipts.

The run

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

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