Bus finished as the fourth mode with balanced staff and passenger depth

⁠Build log series⁠: I give an AI that has never seen Gunjo (@gunjo/ui) only the public npm package and the gunjo.jp docs, then ask it to build a real screen. This ⁠sixth and final passenger-facing bus round⁠ covered a ⁠mobile IC wallet, balance charging, and usage history⁠: prominent balance, manual and automatic charging, history, and bus rewards. Bus now has five staff and six passenger screens.

First, bus became the fourth complete mode

Staff bus coverage included operations, dispatch, planning, revenue, and safety. Passenger coverage included arrivals, intercity booking, route search, tickets, service status, and this IC wallet. At five staff and six passenger screens, bus joined air, rail, and taxi as the fourth mode with comparable depth. Trucking remained.

Result: 4/5. The wallet was one of the library's strongest fits

The screen passed tsc and fit a 375px mobile-first layout. The agent reported:

⁠This was one of the most compatible domains I could have been given.⁠ A transit IC wallet is exactly what these components were built for. The LoyaltySummaryCard JSDoc literally names transit IC cards, points, and IC balance. Only one gap remained: transaction history grouped by date.

The first core observation: balance and SegmentedControl validated the foundation

• ⁠LoyaltySummaryCard⁠, built in #118, fit the prominent IC balance outright. The doc names IC balance as a use case. In practice, balance, meta (card name and last four digits), tier (integrated pass), secondary (route and last use), progress (rewards), and alert filled every named slot without friction.
• ⁠SegmentedControl⁠, built in #156, was independently found again for automatic-charge threshold and amount settings. The agent correctly switched to a two-column RadioCard grid for five charge amounts because the docstring says two to four segments. Five equal-width options would crush a long yen value at 375px. The documented boundary prevented misuse.

The second core observation: TransactionList reached two of three

The only hand-rolled area was usage history grouped by date:

⁠There was no SectionList for date grouping and no transaction list.⁠ ListCard, Timeline, MetadataList, and DataTable do not produce sticky date headers. The catalog sends transaction history to DataTable or ListCard, leaving grouping entirely to the adopter. I built a Map<date, Txn[]>. Signed amounts and post-transaction balances also did not fit ListCard slots, so I forced the amount into status and added screen-reader text for credit or debit. ⁠A TransactionList or LedgerList with date groups, signed amounts that do not rely on color, and running balances is the highest-value missing wallet component.⁠

Taxi ride history in #149 had already hand-rolled monthly grouping, putting SectionList or GroupedList at two of three on issue #404. This screen sharpened the specification beyond group heading, rows, and subtotal: wallets, IC cards, banking, and expenses need signed inflows and outflows plus a running balance. The catalog's transaction-history guidance remained incomplete. One more case would trigger the build.

What I took away: repeating completion four times produced a pattern

Air, rail, taxi, and bus established a stable definition of complete coverage:

1. Five or six staff screens across operations, crews, fleet, revenue, safety, and planning.
2. Five or six passenger flows across guidance, booking, history, support, membership, and wallets.
3. Comparable depth on both sides, always digging into the weaker passenger side.

By the fourth mode, few new component gaps appeared. Leaderboard, SegmentedControl, and LineChip had just cleared the backlog of accumulated cases, leaving near-threshold items such as TransactionList and ValidityTimer. Most of this final screen validated LoyaltySummaryCard and SegmentedControl. That is evidence that the foundation had been through a full pass. Trucking would be the final test of whether anything structurally new remained.

What it flagged

• 🟡 ⁠TransactionList or LedgerList⁠, with date groups, signed amounts, and running balance, at two of three on issue #404.
• 🟡 The agent reused LoyaltySummaryCard.alert for a neutral footnote, suggesting a footnote slot. The Toast API also surprised an adopter expecting an object API instead of showToast(message, type). I added both to issue #404.
• ✅ LoyaltySummaryCard, SegmentedControl, RadioCard, AmountBreakdown, Switch, StatGroup, and BottomActionBar all fit directly.

⁠Nothing new was added under src this round.⁠ The 4/5 completed bus, validated two foundations, and put SectionList at two of three.

📊 Component scoreboard (⁠18 built⁠)

Gantt with intraday resolution / Leaderboard / SegmentedControl / LineChip, plus earlier components In progress: ⁠SectionList or TransactionList at two of three⁠, ValidityTimer at one of three, ComparisonTable, and tone or icon on Statistic.

📋 Mode progress: four complete

• ✈️ Air ✅ / 🚆 Rail ✅ / 🚕 Taxi ✅ / 🚌 ⁠Bus, five staff + six passenger screens⁠ ✅
• 🚚 Trucking: not started, the fifth and final mode

Next up: build log #159

• Open trucking, the final new mode, from the staff side before shipper pickup requests and tracking, or deepen an existing mode.

The run

• ⁠gunjo.jp⁠ / ⁠LoyaltySummaryCard⁠ / ⁠SegmentedControl⁠ / ⁠AmountBreakdown⁠ / npm @gunjo/ui / ⁠GitHub⁠ / previous rounds #1 through #157
• ⁠GunjoUI by UIXHERO⁠

Bus completed the fourth mode. Repeating the process four times made completion a pattern: five or six staff screens, five or six passenger screens, and comparable depth on both sides.