The next cold agent dug up last round's Delta and used it everywhere

⁠Build log series⁠: I hand a real screen to an AI that has never seen Gunjo (@gunjo/ui) and let it build. Retail screen four: ⁠returns and refunds⁠ (original-transaction lookup, partial returns, reason codes, refund calculation, refund tender, restocking).

The policy stands: cover an industry with three to five screens that share as little as possible, industry-specific UI first. After selling (#42), counting (#43), and closing (#44), this round rewinds: walking a sold transaction backwards to undo it. Still retail, and unlike all three.

Result: 4.5/5

tsc and build passed, the console stayed clear, 375px switched to cards, refund amounts recalculated instantly from return quantities, a missing reason blocked confirmation, high-value and no-receipt cases hit an approval gate, a completed return went read-only, the page had a single h1, and the refund amount was announced as text plus sign.

The star this round: the agent found Delta on its own and adopted it everywhere

The biggest bet in this series has been this: ⁠does a component I build actually get discovered and used by the next agent, which starts from zero?⁠ Every round's agent is a blank slate. It does not know what was built last time. Its only clues are the contents of @gunjo/ui and gunjo.jp.

Last round, after the third over/short sighting, I built Delta (issue #221), the minimal signed-difference component. This round's agent ⁠found Delta by itself and used it for everything refund-shaped⁠:

⁠Delta: used it, it fit beautifully, the standout of this screen.⁠ The exact minimal component for refund amounts. Ran it with value={-amount}, format={(n)=>yen(Math.abs(n))} (the amount stays absolute, the component owns the sign), and labels={{ negative: "Refund" }}. ⁠Cells in EditableDataTable (per-line refund amounts), the column footer (returned-items total), the prorated-discount row, the summary (refund total), and the refund-method table: one component across the whole screen.⁠ With the sign-driven destructive tone and an always-announced label, a refund reads as ⁠text plus sign, not just color⁠. ⁠I never fought it once, and hand-wrote zero difference displays.⁠

This is what the compounding actually is. A person makes the build decision through the rule of three, my partner AI (the one that does the implementation work in this series) builds the component, and then ⁠the next blank-slate agent excavates it and composes with it, friction-free⁠. The agent is not learning (it starts clean every time). ⁠The package is growing, and every new agent keeps finding the same things in it.⁠ That is why the verification can be trusted.

The cross-cutting set was adopted wholesale too: EditableDataTable (per-line return quantities, a reason Select, auto-calculated refunds, column totals through renderFooterCell, cards at 375px), NumberInput (stepper, clamped between zero and the purchased quantity), CurrencyInput (hand-entered unit prices on no-receipt returns), RevealSection plus ApprovalSteps (the approval panel appears through role="region" on high-value and no-receipt cases, with an approval trail), and formatCurrency on every yen amount.

What I fixed this round: a prop that exists but cannot be found in the docs

The clear defect this time was ⁠findability⁠:

• 🟡 ⁠CardTitle's as prop is missing from the docs.⁠ CardTitle ships as (h1 through h6, p, or div, defaulting to h3), yet every demo on the Card docs page uses a bare <CardTitle> and the props table lists only className and children. ⁠Two consecutive agents stepped on this from opposite sides⁠: #44's read the .tsx types, found as="h2", and got the heading order right; this round's agent relied on the docs alone, missed it, and produced an h1-to-h3 jump. ⁠The capability exists; the docs just never surface it.⁠ I added the as row to the props table (PR #224). Not a new component, just making an existing capability visible so this stops recurring.

Logged, not built (not yet at three)

• 🟠 ⁠Scan or receipt-lookup input⁠ (type or scan, resolve a record, then found or not-found; issue #220, ⁠second sighting⁠: stocktake SKUs in #43 plus receipt lookup here). The agent named it the biggest gap. One more sighting and it gets built.
• 🟠 ⁠A constrained refund-method selector⁠ (the original payment constrains the refund: card sales can only be reversed to the card, no cash back). Handled with disabled options on Select. A different thing from #42's numeric keypad (noted on issue #216; the keypad stays at one sighting, the constrained selector is new).
• 🟡 A boxed or card variant of RevealSection would make approval panels easier (the border and padding get hand-tuned every time).

What I took away: compounding is not the AI getting smarter

#44: over/short seen three times, so a person builds Delta
#45: a blank-slate agent excavates Delta and adopts it across the refund screen, without a fight

The verification is trustworthy precisely ⁠because the agent remembers nothing⁠. If it remembered, "I used it last time" would contaminate the result. A fresh agent starting from zero, digging through the package, and arriving at the same component every time is evidence that the component is ⁠genuinely discoverable and composable⁠. All I shipped this round was one line of docs (the library held). But last round's investment came back with interest.

Next up: build log #46

• ⁠Retail screen five⁠ (register open, receiving, or the third scan sighting for issue #220, which is the build threshold), or a new industry.

The run

• ⁠gunjo.jp⁠ / npm @gunjo/ui / ⁠GitHub⁠
• Earlier rounds: #1 through #44
• ⁠GunjoUI by UIXHERO⁠

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