AI に入庫（棚入れ）を作らせてみた — 逆順スキャンでもコンポーネントは効き、Progress の小さな不備を1つ埋めた（やってみた #48）

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。物流/倉庫(WMS)2枚目——⁠入庫 / 棚入れ (put-away)⁠（入庫指示 × 商品スキャン → 推奨ロケーション → 格納先スキャン × 容量/充填 × 分割格納 × 在庫計上）。

#47 ピッキング（ロケ→商品で⁠取り出す⁠）と対の、⁠商品→ロケで格納する⁠入庫側。2段スキャンが⁠逆順⁠（商品先 → 格納先ロケ）になるのが今回の肝。同じ物流でも、出庫と入庫で作法が鏡像になる。

結果 — 4/5

tsc/build 緑・console 0・375px ハンディプライマリ・商品スキャン→推奨棚＋容量表示→ロケスキャンで+1・満杯はオーバーストック阻止＋読み上げ・分割格納（3+5=8 を2棚へ）・対象外はエラー・入庫確定で read-only サマリ（棚別ロールアップ）・h1 1個。

逆順でも、育てたコンポーネントはそのまま効いた

スキャン順が #47 と逆（商品→ロケ）でも、ScanInput は両方のスキャンに効きました:

⁠両方のスキャンに ScanInput⁠ — この画面の主役だ。onScan(code) → ScanResult {ok, message} がまさに正しい設計。タイプして Enter、lockMs で二重発火の抑制、自動クリア、再フォーカス、控えめ（polite）な aria-live が全部入り。段ごとに key で remount して、label と handler を差し替えた。

Delta（残数・muted/success）・EditableDataTable（格納グリッド・renderFooterCell・375px カード化）・RevealSection（容量の上書き/保留/検証ゲート）・Progress（充填率の label/valueText）・CardTitle as・formatCurrency（¥186,400）——⁠全部発掘・採用⁠。複利は逆順の鏡像の画面でも崩れませんでした。

src で直した不備 — Progress に意味を持たせる tone

今回のはっきりした不備は、⁠既存の出荷コンポーネントに明らかに足りない prop⁠ でした:

• 🟠 ⁠Progress の充填バーが bg-foreground 固定⁠で、容量メーターの色調（残りわずか→警告、満杯→赤）が出せない。予備知識ゼロの AI は、Progress の上に色付きバーを -mt-2.5 で⁠重ねる小細工⁠を強いられました。→ ⁠tone prop（default/primary/success/warning/destructive/info）を追加⁠（#229・PR #231・ブラウザ実証）。既定は中立のまま＝既存の呼び出しは無変更。

これは⁠新しいコンポーネントではなく、既存コンポーネントへの小さな追加⁠なので、3回ルール（新しいコンポーネントは3回見てから作る）とは別軸——#219（label/valueText 追加）と同じ「明らかな不備＋悪い回避策」は即修正する判断です。docs にも「意味を持つ充填（tone）」のデモ＋未掲載だった label/valueText/tone を追記。

課題に記録だけした欠落（新しいコンポーネントは3回ルール）

• 🟠 ⁠ロケーション容量/充填の Meter コンポーネント⁠（#230・1回目）。「この棚に入る？」の専用コンポーネントが無い。Progress＋tone で当座は組めるが、⁠複数セグメント（現在の充填＋入荷分の重ね表示）＋閾値の色調＋容量の形状⁠の Meter/Gauge が理想。倉庫容量/ストレージ使用量/クォータで再出現したら作る。
• 🟠 ⁠2段スキャンのゲート（ScanGate）⁠（#227・⁠2回目⁠）。#47 は location→item、#48 は item→location——⁠順序が逆でも欲しい＝概念が順序に依存せず通用する⁠。予備知識ゼロの AI が再び scanStage の状態管理を手組み。あと1回で作る。
• 🟡 分割格納のエディタ・グリッド内の Select が標準要素のまま。

学び — 「小さな既存修正」と「新しいコンポーネント」を分けて捌く

即修正（既存コンポーネントの明白な不備）: Progress tone #229 → 反映
課題に記録して待つ（新しいコンポーネント・3回ルール）: 容量 Meter #230(1回)・ScanGate #227(2回)

複利が回り始めた段階の規律は、⁠欠落の"種類"で対応を変える⁠こと。既存コンポーネントが prop 1個足りなくて、使う側が小細工を強いられているなら即直す（#219・#229）。一方、まったく新しい合成コンポーネント（ScanGate・容量 Meter）は、頻度がコンポーネントを浮かび上がらせるまで、課題に記録して待つ。作りすぎを避けつつ、明白な不備は放置しない——この2軸でライブラリは健全に育ちます。今回は逆順スキャンでも全コンポーネントが効き、不備は Progress の prop 1個だけ＝物流2枚目もライブラリはほぼ持ちこたえました。

次回予告（やってみた #49）

• ⁠物流をもう1枚⁠（出荷検品/梱包 or 在庫ロケーション管理）で ScanGate#227 を3回目＝作る閾値へ、容量 Meter#230 も2回目を狙う。方針: 1業界3〜5枚・可能な限り違う内容・業界特有UI最優先。

試す

• ⁠gunjo.jp⁠ ／ npm @gunjo/ui ／ ⁠GitHub⁠
• 前回まで: #1〜#47
• ⁠GunjoUI by UIXHERO⁠

まだ alpha。逆順スキャンでもコンポーネントは効き、Progress の小さな不備を1つ埋めた回。