The third hand-built ranking became Leaderboard on a safety screen

⁠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 fifth staff-facing bus round⁠, matching rail and air, covered a dense ⁠transport safety and incident console⁠: crashes, incidents, near misses, complaints, responsibility, depot safety metrics, report approval, and prevention.

Result: 4.5/5, and Leaderboard settled on its third case

The desktop-density screen passed tsc. The agent reported:

⁠This library was clearly built for this kind of Japanese administrative operations console.⁠ Most of the screen used real components rather than hand-rolled markup. The only substantial gap, and the reason for the half-point deduction, was the absence of a ranking component, plus a few smaller usability issues.

The core observation: Leaderboard reached three of three

The screen ranked safety metrics by depot and route, with the worst results first so they could be addressed. The agent found:

⁠This was a real gap. There was no ranking or leaderboard component.⁠ Searching the entry point found neither rank nor leaderboard. A Leaderboard or RankingList taking {rank,label,value,delta,tone}[] in worst-first order would replace about 40 hand-rolled lines with rank chips. It was the highest-value addition. The by-use-case catalog also sends "Ranking" and "Worst Performers" to StatGroup, which is wrong.

This was the third case: taxi revenue ranking in #143, bus route profitability in #154, and depot safety here. I built it immediately:

• ⁠Leaderboard⁠ renders preordered rows with rank chips, a value bar normalized by max, and Delta. The caller chooses best-first or worst-first order. Rank is the array position, so the component never guesses who comes first.
• deltaTones={{positive:"destructive"}} makes rising accident, cost, or complaint rates red in a worst-first ranking.
• It owns a ranked list, distinct from BarChart without rank and StatGroup with unordered KPIs.
• I added a Leaderboard row to the by-use-case catalog and clarified on StatGroup that rankings belong elsewhere.

PR#413 passed structural verification, tsc, and the build, then confirmed rank chips, normalized bars at 100, 89.4, and 65.97 percent for values 4820, 4310, and 3180, plus the data slot in the browser. Issue #395 closed. ⁠This was the sixteenth component produced by the series.⁠

What I took away: active false guidance accelerates a build

The catalog had said ⁠ranking and worst performers belong in StatGroup⁠, even though StatGroup has no order. The gap therefore carried two costs:

• Without a component, adopters hand-roll the ranking.
• With a false lead, they first waste time forcing an unordered KPI group into the job.

On the third case I paired the component build with the catalog correction. A missing component and a wrong answer are separate harms, hand-rolling and misdirection, and both need to close together.

What it flagged

• ✅ ApprovalSteps fit incident report, approval, and corrective action, with Japanese default labels, aria-current, and a comment slot for return reasons.
• ✅ SafetyBanner fit exactly, including role=alert, aria-live, and an action slot.
• ✅ ActionQueue, StatGroup, DataTable, Delta, and Meter in higher-is-worse mode introduced no friction.
• 🟡 This was the second lower-is-better case from issue #412. Accident rates and near-miss reporting culture required manual tone inversion; zero as a target remained absent as a first-class concept.

⁠What I built under src this round: Leaderboard.⁠ The 4.5/5 triggered the third-case build and corrected the catalog.

📊 Component scoreboard (⁠16 built⁠)

Stringline / StatusBoard / ExpiryBadge / BottomActionBar / Gantt with intraday resolution / ⁠Leaderboard⁠, plus earlier components In progress: SegmentedControl beyond three cases, ReferralCard, ComparisonTable, and inverted metrics at two of three.

📋 Mode progress

• ✈️ Air: five staff + six passenger screens ✅ / 🚆 Rail: five staff + six passenger screens ✅ / 🚕 Taxi: six staff + six passenger screens ✅
• 🚌 ⁠Bus: five staff (operations, dispatch, planning, revenue, safety) + three passenger screens⁠. Staff depth now matches rail and air; passenger coverage remained thinner.
• 🚚 Trucking: not started

Next up: build log #156

• Deepen passenger bus with tickets, IC cards, passes, or service information, the weaker side beside five staff screens, or open trucking.

The run

• ⁠gunjo.jp⁠ / ⁠Leaderboard⁠ / ⁠ApprovalSteps⁠ / ⁠Delta⁠ / npm @gunjo/ui / ⁠GitHub⁠ / previous rounds #1 through #154
• ⁠GunjoUI by UIXHERO⁠

The third ranking became Leaderboard. A missing component and a false catalog answer impose different costs, so the build and the guidance fix landed together.