FileUploader promised progress it did not implement

⁠Build log series⁠: I hand a real screen to an AI that has never seen Gunjo (@gunjo/ui) and let it build. The complex-screen phase began with #9, Kanban. This round covered ⁠file upload⁠.

I changed none of the inputs: the agent received the shipped package and docs, but not the source. The assignment was an /upload screen with a drop zone, a list of selected files (name, size, type, and removal), ⁠progress for each file⁠, a global Upload all action, and an empty state.

Result: 3/5. The lowest score in the series

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

The supporting components, Progress, Button, Badge, and EmptyState, worked well. The typed entry point remained easy to use, no provider wrapper was required, and server-side rendering did not crash. ⁠The central FileUploader, however, was the roughest component the series had found.⁠

The main finding: FileUploader was half-built and the docs overpromised

The cold agent reported three problems.

1. Progress was not implemented, and the unfinished comment was still there

The internal state of FileUploader included both progress and status, but ⁠neither rendered anywhere⁠. The source contained this line:

{/* Progress Simulation would go here */}

It was an unfinished implementation note left in production code. ⁠The docs still said the component could display upload progress.⁠ The documentation promised behavior before the implementation existed. This matched the gap from #7, where the claim of built-in accessibility failed in the actual component. I logged issue #62, and the complete component and fluid-width fixes landed in PR#63.

2. Consumers could not control the state

There was no value prop, and onValueChange returned ⁠only the latest batch⁠, not the accumulated file list. The component also rendered its own file rows and removal buttons without a way to replace or hide them. Rendering a custom list outside it created duplicate output. The cold agent resorted to ⁠a CSS hack⁠ to hide the internal list:

[data-slot="file-uploader"] > div:nth-child(2) { display: none; }

It asked for showFileList={false}.

3. The fixed-width audit missed the progress components

Progress defaulted to w-[200px], and ProgressWidget defaulted to w-[320px]. ⁠The issue #58 audit of fixed-width defaults had missed both.⁠ I had said the class was audited, but the audit was incomplete. I added them to issue #62.

The agent also introduced one React 19 Strict Mode bug and fixed it itself. That belonged to the generated app, not Gunjo, but it remains part of the record.

What I took away: the lowest score was the most honest one

Round ten scored ⁠3/5, the series low⁠. That is exactly why the series exists.

• ⁠My component was half-built.⁠ Progress had remained an unfinished comment.
• ⁠My docs had overpromised.⁠ They claimed progress rendering that did not exist.
• ⁠My completed audit had omissions.⁠ More fixed widths remained.

⁠My own test found all three before release.⁠ I kept the low score, turned the findings into an issue, and fixed them. Complex screens expose unfinished behavior and overpromising that simple screens rarely touch. ⁠The rough edges were nowhere near exhausted.⁠

Next up: build log #11

• ⁠Calendar booking using Calendar, DatePicker, and Select⁠, a complex screen built around dates.

The run

• ⁠gunjo.jp⁠ / npm @gunjo/ui / ⁠GitHub⁠
• Earlier rounds: #1 through #9
• 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.