Ugly data could not break the charts, but one missing type broke the build

⁠Build log series⁠: I hand a real screen to an AI that has never seen Gunjo (@gunjo/ui) and let it build. After #1, settings, #2, a modal announcement, and #3, a carousel, this round reached a core differentiator: ⁠dashboard charts⁠.

Gunjo's charts are built from ⁠HTML and CSS layout components⁠, not SVG. The goal is to ⁠survive arbitrary data⁠. They need to hold up under messy real-world inputs, not only polished sample data: wildly different scales, outliers, zeros, and tiny values.

I had the cold agent ⁠stress-test that claim⁠. The conditions stayed the same: only the public npm alpha.2 package and the gunjo.jp docs, with no source access. The assignment was an ⁠analytics dashboard⁠ at /dashboard, with KPI cards, several charts, and a data table.

Result: 4/5. The dashboard worked, and the charts held up

npm run build passed, the page rendered statically, and the console stayed clear.

The agent deliberately supplied ⁠hostile data⁠. As the screenshot shows, every case rendered correctly:

• ⁠Two series on different scales⁠, revenue in the tens of thousands and refunds in the thousands, shared one line chart. Refunds hugged the baseline without breaking the layout.
• ⁠A zero in the middle of a series⁠, June revenue at $0, dropped sharply to the baseline and recovered.
• ⁠A ninefold outlier and a zero bar⁠, W4 at 3,850 and W6 at 0, let the outlier set the maximum while the zero bar stayed empty and the average line remained correct.
• ⁠A zero-value donut segment⁠, Affiliate at 0%, displayed 0% without NaN or a broken conic-gradient.
• ⁠A tiny pie slice⁠, Other at 0.8%, stayed visible even at that width.

⁠The claim that layout components keep charts stable under arbitrary data survived the stress test.⁠ Rounds one through three found rough edges. Round four ⁠proved one of the library's selling points⁠.

The typed entry point helped again. The agent immediately found LineChart, BarChart, DonutChart, PieChart, Statistic, and Table. A common ⁠data contract⁠, ChartDataPoint = { label?, value, color? }, makes every chart easier to understand, and formatting values requires only an Intl.NumberFormat passed to formatValue.

The rough edge: one missing type undermined typed discovery

One real bug still ⁠stopped the build⁠.

import { type ChartDataPoint } from "@gunjo/ui" // Not exported

Every chart expected ChartDataPoint through its public props, but ⁠the type was not exported from the shared @gunjo/ui entry point⁠. It stopped inside chart-utils.ts. Consumers who wanted to type chart data could not refer to its contract by name. The agent copied the same type locally as a workaround, but the omission undercut Gunjo's promise that ⁠following the types reveals how a component works⁠. I logged it in issue #53, and the export landed in PR#54.

Other rough edges:

• ⁠The docs' code examples still did not appear in fetched content.⁠ Issue issue #50 from round two was not deployed, so the agent reconstructed the call pattern from types.
• The docs do not explain that LineChart takes its x-axis labels from the longest series.
• The Table wrapper carries both w-[400px] and w-full. The duplicate classes are harmless but look like residue.

What I took away

Have the AI use it | Find the rough edges | Fix every source consistently (SSOT) | Run it again

Round four established two things. ⁠First, the charts really do survive arbitrary data.⁠ The claim held. ⁠Second, the missing type export blocked consumers who wanted to work from types.⁠ I can show the strength without inflating it and add the flaw to the issue list without hiding it.

Next up: build log #5

• ⁠Login and sign-up using Form, Input, Button, and Tabs⁠, an authentication pattern with high search demand.

The run

• ⁠gunjo.jp⁠ / npm @gunjo/ui / ⁠GitHub⁠
• Earlier rounds: #1, settings / #2, modal announcement / #3, carousel
• Overview: Gunjo (@gunjo/ui) / Why it exists: Design systems in the age of AI
• ⁠GunjoUI by UIXHERO⁠

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