A targeted follow-up pushed Statistic goodWhen to its third case

⁠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. After I finished all five transport modes, this round deliberately deepened the remaining candidates with a ⁠rail punctuality and performance dashboard⁠: on-time rate, delay rate, service disruptions, and crowding by line.

Result: 4/5. Statistic.goodWhen reached its third case as intended

The dense desktop screen passed tsc. The agent reported:

⁠This was a genuinely strong analytics and operations library.⁠ Nearly every box had a purpose-built component, and difficult semantic patterns such as lower-is-better metrics, values against named limits, and worst-line rankings had already been anticipated, except on the central KPI component itself.

The core observation

The third goodWhen case triggered a targeted build. On-time performance is better when higher; delays and crowding are better when lower. The agent found:

⁠Statistic separates trend, the arrow, from tone, the color, but defaults tone from trend, with up always green.⁠ There is no goodWhen, direction, or per-sign tone. An increase in delays or crowding is worse but appears green. I hand-rolled directionProps(delta, goodWhen). The gap is obvious because sibling components already solve it: Delta has sign-specific tones, Leaderboard has deltaTones, and Meter has direction. Statistic needs the same treatment.

This was the third case after operating ratio in #154 and cost or loaded-distance ratio in #163. I added:

• goodWhen?: "higher" | "lower" to Statistic. The arrow remains the actual trend while only the tone reverses. With lower, an increase renders in the destructive tone and a decrease in the success tone. An explicit tone still wins, and default behavior remains unchanged. StatGroup items inherit the prop.
• Browser verification in PR#427 confirmed a falling crowding rate with goodWhen="lower" appearing green, and rising delay count appearing red. Issue #412 closed.

On-time rate can now use goodWhen="higher" and delay count goodWhen="lower" without manually managing tone per metric. ⁠This was the twenty-second component-level build or extension in the series.⁠

What I took away

Targeted follow-ups can advance stored candidates deliberately. After completing the five modes, the remaining candidates included Statistic.goodWhen at two of three, OriginDestination at one of three, and document downloads at one of three. A rail performance dashboard naturally exercised all three:

• Inverted KPIs supplied the third goodWhen case and triggered the build.
• Origin-to-destination headings supplied another OriginDestination case.
• Monthly report downloads supplied another document-row case.

One screen advanced three candidates. The series had moved from discovering new gaps to ⁠choosing screens that naturally bring stored evidence to the rule of three.⁠ That is another steady state for a mature foundation.

What it flagged

• ✅ NavRow, built in #168, was independently found one round later for monthly report rows.
• ✅ Delta, Leaderboard, LimitMonitor, LineChart, and LineChip all fit their inverted-tone, target, threshold, and contrast jobs directly.
• 🟡 #169 was the second OriginDestination case, after #166. The catalog still misdirected a compact A-to-B heading to Itinerary; one more case would trigger the build on issue #425.
• 🟡 #169 was the second downloadable-report-row case, after #168.

⁠What changed under src this round: Statistic.goodWhen.⁠ The 4/5 created the extension and advanced two more stored candidates.

📊 Component scoreboard

⁠22 built or extended.⁠ Four of the nine components and extensions added this session: SectionList / RouteStops with multiday timestamps / NavRow / ⁠Statistic with goodWhen⁠. In progress: ⁠OriginDestination at two of three⁠, document-download rows at two of three, and MatchCard at one of three.

📋 Mode progress

• ✈️ Air ✅ / 🚆 Rail ✅ / 🚕 Taxi ✅ / 🚌 Bus ✅ / 🚚 Trucking ✅
• Targeted follow-ups: goodWhen built, while OriginDestination and document downloads moved to two of three

Next up

Build log #170:

• Continue a targeted follow-up to bring OriginDestination or document downloads to the third case, or move to a new industry.

The run

• ⁠gunjo.jp⁠ / ⁠Statistic⁠ with goodWhen / ⁠Leaderboard⁠ / ⁠LimitMonitor⁠ / npm @gunjo/ui / ⁠GitHub⁠ / previous rounds #1 through #168
• ⁠GunjoUI by UIXHERO⁠

A targeted follow-up pushed Statistic.goodWhen to its third case and advanced two more stored candidates. Mature deep dives now choose screens that naturally complete accumulated evidence.