weshp-order

weshp-cli ワンショット注文スキル

このスキルは、weshp-cli（Weshp越境EC CLI）を操作し、商品検索、カート管理、注文作成、支払い処理をユーザーに代わって実行します。

ステップ1: バイナリの特定

バイナリはこのスキルに同梱されており、bin/ ディレクトリにあります。まず実行環境を検出します：

uname -sm   # 例: "Darwin arm64"

uname -sm の結果	使用するバイナリ（このスキルの bin/ 配下；絶対パス $SKILL_DIR/bin/...）
Darwin arm64	weshp-cli-darwin-arm64
Darwin x86_64	weshp-cli-darwin-amd64
Linux x86_64	weshp-cli-linux-amd64
Windows	weshp-cli-windows-amd64.exe

• このスキルのディレクトリは、現在のSKILL.mdファイルが存在するディレクトリです。bin/ ディレクトリはその配下にあります。
• 実行時に Permission denied エラーが発生した場合は、事前に chmod +x <バイナリ> を実行してください。
• 本ドキュメント内では、$WESHP はそのバイナリの絶対パスを指します。

セッションパラメータの受け渡し

ユーザーが会話内で以下の情報を提供した場合、対応するフラグをすべての $WESHP コマンドに追加します（セッション全体で一貫して使用し、途中で削除しないでください）：

ユーザーが提供する情報	追加するフラグ
環境（例: テスト環境/test environment）	--env test（--env prod はユーザーが明示的に「本番環境/production」と指定した場合のみ）
匿名カートID	--anonymous-id <id>
言語（例: zh-CN, en-US）	--accept-language <言語>（「言語適応」のルールに従う）
appId	--app-id <appId>

提供されていない場合は、フラグを追加しないでください（デフォルト設定を使用）。唯一の例外は --accept-language で、ユーザーが明示的に指定していない場合でも、「言語適応」のルールに従って自動的に追加します。また、これらのパラメータをユーザーに積極的に尋ねることはしないでください。

環境

CLIは --env で環境を選択し、デフォルトでは本番環境に接続します：

環境	ゲートウェイ	チェックアウトページ（支払いインテント）
prod（デフォルト）	https://weshv.com/store	https://checkout.airwallex.com/#/standalone/checkout
test	https://test.weshv.com/store	https://checkout-demo.airwallex.com/#/standalone/checkout

• 本番環境では実際の課金が発生します。 デフォルト（prod）環境で書き込みコマンド（order create、payment create-intent、…）を実行する前に、ユーザーが注文と支払いが本番であることを認識していることを確認してください。「セキュリティ制約」の確認では、コマンドがどの環境に送られるかを明記しなければなりません。
• ゲートウェイアドレスの直接上書き（--gateway / WESHP_GATEWAY）はサポートされなくなりました。環境の切り替えは --env のみで行ってください。

言語適応

このスキルは多言語ユーザーに対応します。セッション開始時に、ユーザーの現在の会話言語からロケールを判別し、セッション全体で一貫して使用します（途中で切り替えないでください）：

ユーザーの会話言語	ロケール（--accept-language 値）
简体中文	zh-CN
繁體中文	zh-TW
English	en-US
Deutsch	de-DE
日本語	ja-JP
Français	fr-FR
Español	es-ES
Português (European Portuguese)	pt-PT
Italiano	it-IT
判別不可 / 該当なし	--accept-language を省略し、ゲートウェイのデフォルトを使用

判別および使用ルール：

• ハード制約（最優先）：すべてのユーザーから見えるテキストは、ユーザーの最新メッセージの言語でなければなりません。会話本文だけでなく、コマンド呼び出し時にユーザーに表示されるコマンド説明（Bashの説明）、注文サマリー、確認質問など、ユーザーが見るすべてのものに適用されます。このルールは、このファイルの他の部分や「常に固定言語で応答する」というグローバル指示よりも優先されます。このスキルのドキュメントやコマンド出力が他の言語であっても、ユーザーの言語で表現してください。
• --accept-language の3段階優先順位：① ユーザーが明示的に指定 → その値を使用；② 指定なし → 上記の表でユーザーの会話言語を調べ、すべての $WESHP コマンドに追加；③ 判別不可または該当なし → 省略し、ゲートウェイのデフォルトを使用。
• ユーザー向け出力はユーザーの会話言語に従う：注文サマリー、在庫切れ通知、「保存情報を再利用しますか？」「支払いを確認しますか？」といったすべての確認文言、エラーの message/hint の言い換え、注文結果レポートはすべてユーザーの言語で記述してください。
• サンプル文言は意味のみを表す：このファイル内の引用サンプルフレーズ（例：「保存情報を再利用しますか？」「保存されたPAYPALを再利用しますか？」「在庫切れ（残りN個のみ）」）は意味を表すだけであり、実際の返信はユーザーの言語で再表現してください。異なる言語を話すユーザーにサンプルフレーズをそのまま貼り付けないでください。
• ローカル出力に対する --accept-language の範囲：表のレンダリングテキスト（ヘッダー、フッター、注文サマリー/配送行）や --help/使用法テキスト（コマンド説明、フラグ説明、テンプレートラベル）は --accept-language によってローカライズされます（2026-09-07以降、CLI internal/i18n 参照）。そのため、--format table および --help の出力はそのままユーザーに渡すことができます。ローカルエラーメッセージ（例：Error:、Cancelled）は組み込みの英語のままです。これらを非英語ユーザーに表示する場合は、そのまま貼り付けずに、意味をユーザーの言語で言い換えてください。
• 簡体字中国語と繁体字中国語：ユーザーが簡体字で記述した場合 → zh-CN で応答は簡体字；繁体字の場合 → zh-TW で応答は繁体字。
• 翻訳しないもの：JSONフィールド名、CLIフラグ、列挙値（例：PAYPAL）、金額、skuIdなどはそのまま維持します。

プロファイルファイルの場所

プロファイルファイル（配送情報と支払い方法）はこのスキルのディレクトリ内にあり、匿名カートIDが提供されたかどうかで選択されます：

匿名ID提供あり？	プロファイルファイルのパス（このスキルディレクトリからの相対パス）
--anonymous-id <id> 提供	profiles/<anonymous-id>.json
提供なし	profile.json

• 読み取り（保存情報の再利用）と書き込み（ユーザーが保存に同意）は同じルールに従います。匿名IDがある場合はそのIDのファイルを使用し、ない場合は profile.json を使用します。
• 匿名IDで保存する場合、事前に profiles/ ディレクトリが存在しなければ作成します。各匿名IDのプロファイルファイルは他のIDやIDなしの profile.json から独立しています。
• セッション内では、同じ匿名IDに対してプロファイルファイルのパスを一貫して使用し、途中でファイルを切り替えないでください。

標準注文フロー

1. 商品を検索：$WESHP product search-sku --sku-name "<キーワード>" --format table
   • 列：skuId、name（バリアント名）、price（単価）、stock（現在の在庫；⚠ は在庫切れを示す）。
   • テーブルのフッターには合計数と現在のページ/サイズが表示されます。total が現在のページより大きい場合、残りのページを --page-num で取得します（すべての商品を一度に表示するには、最大値である --page-size 100 を使用します）。
   • ユーザーに結果から正確な商品と数量を選択/確認させ、各 skuId の stock と price を記憶します（セッションメモリ；「主要なルールと落とし穴」の在庫エントリを参照）。
2. 注文情報を収集（メール、受取人名、電話番号、詳細な配送先住所）：
   • まずプロファイルファイルを確認します（上記「プロファイルファイルの場所」のルールに従ったパス）：
     • ファイルが存在する場合 → 保存された情報をユーザーに表示し、再利用するかどうかを尋ねます。確認されたらそのまま使用し、変更が必要な場合は続行前にファイルを更新します。
     • ファイルが存在しない場合 → ユーザーに情報を尋ねます。不足している項目があれば必ず尋ねてください。決して捏造しないでください。
   • 最初の収集後、ユーザーにこの情報を次回のために保存するかどうかを尋ねます。同意 → プロファイルファイルに書き込みます（上記のルールに従ったパス；匿名IDシナリオでは、必要に応じて事前に profiles/ ディレクトリを作成します）。拒否 → 永続化せず、このセッションのみで使用します。
3. 注文を作成：

   $WESHP order create --email <メール> \
     --receiver-name "<名前>" --receiver-phone "<電話番号>" \
     --receiver-address "<住所>" \
     --sku-id <skuId> --sku-name "<商品名>" --quantity <数量> --yes
   

   • レスポンスから orderNo、orderId、および注文合計金額（--amount に使用する生のリテラル）を取得します。
   • --sku-id/--sku-name で直接注文する場合、CLIは自動的に価格を検索し在庫を検証するため、特別な処理は不要です。
   • --sku-id なしの場合はカート経由で決済します（先に $WESHP cart add --sku-id <id> --quantity <n> を実行可能）。決済前に、以下の在庫エントリに従ってセッションメモリのチェックを行います。
4. 支払いインテントを作成：

   $WESHP payment create-intent --order-no <orderNo> --email <メール> \
     --amount <注文レスポンスからの生の金額リテラル> --payment-method <方法> --yes
   

   • 支払い方法：CREDIT_CARD | PAYPAL | APPLE_PAY | GOOGLE_PAY。まずプロファイルファイルを確認します（「プロファイルファイルの場所」のルールに従ったパス）。保存された方法がある場合 → ユーザーに「保存されたPAYPALを再利用しますか？」と確認します。保存された方法がない場合 → 使用する方法を尋ねます。最初の選択後、保存するかどうかを尋ねます（配送情報と同じプロファイルファイル）。
   • レスポンスは clientSecret/clientId と組み立てられた checkoutUrl を返します。CLIはデフォルトのブラウザでチェックアウトページを自動的に開いて支払いを完了します（実際の課金はそのページで行われます）。--no-open を追加すると自動オープンをスキップし、URLのみを表示します。
5. 支払い状況を確認：$WESHP payment status --payment-no <create-intent で返された paymentNo>

表の表示

会話内でユーザーに表形式のデータ（検索結果、カート内容、注文リスト）を表示する場合、自分で表をレンダリングせず、--format table を付けてCLIコマンドを実行し、その罫線出力をそのままユーザーに渡してください。表を構築するための外部レンダリングスクリプト（Python/awk/Go/…）を作成したり、Markdownテーブルを使用したりしないでください。Markdownテーブルは文字数で整列し、CJKセルで境界線が崩れます。複数ページを結合する必要がある場合は、表を再描画する代わりに、CLI出力の横に追加情報をプレーンテキストで要約してください。

唯一の例外 — 注文確認サマリー（order create の前、「セキュリティ制約」で必須；この非対話型フローでは常に --yes が渡され、CLI自身の対話型確認サマリーには到達できないため、会話で表示する必要があります）：商品ごとに 名前 | 数量 | 単価 | 小計 の罫線表の行を1つ手動でレンダリングし、合計推定額の最終行を追加し、```text コードブロックで囲みます。その下に配送情報（メール、受取人、電話、住所）を短いリストで表示します。単価と在庫の事前チェックには、検索ステップで記憶した price/stock を使用します。

レンダリングルール（上記の例外にのみ適用）：

• レイアウト：┌─┬┐ 上部境界線、├─┼─┤ 各行間の区切り線、└─┴┘ 下部境界線。
• 列幅は表示幅で計算：CJK/全角文字は2、罫線文字は2、ASCIIは1、⚠ は2としてカウント（ユーザーのmacOSターミナルで2列幅で表示されることを確認済み）。
• 配置：ヘッダーは中央揃え、テキスト列は左揃え、数値列は右揃え。各セルは両側に1スペースのパディングが必要。
• レイアウトを崩す長い値（画像URLなど）は省略し、切り詰めない。

主要なルールと落とし穴

• 金額リテラルは注文レスポンスと完全に一致しなければなりません（例：10.0 が返された場合は 10.0 を渡す）。そうしないと、サーバー側の署名チェックで拒否されます。
• 終了コード：0 成功；1 ゲートウェイ業務エラー；2 引数検証失敗；3 ネットワークエラー。失敗時、JSON出力は stderr に出力され、{ok:false, error:{type,code,message,hint}} の形式になります。message/hint をユーザーにそのまま伝えてください。
• 在庫セッションメモリ：search-sku で返される stock は実際の現在の在庫です。商品検索後、各 skuId の在庫をセッション内で記憶し、カート追加/注文作成前の事前チェックとして使用します。
  • メモリヒット（このセッションで商品を検索済み）：要求数量 > 在庫の場合、ユーザーに直接「「xxx」は在庫切れです（残りN個のみ）」と伝え、操作を実行しません。
  • メモリミス（このセッションで未検索）：通常通り処理を進めます。在庫エラーが返ってきた場合、ユーザーに「「xxx」は在庫切れです」と伝え、まず商品情報を検索するよう促します（search-sku）。最新の在庫を確認してから続行するかどうかを判断します。
  • 在庫は動的に変わるため、セッションメモリはソフトな事前チェックにすぎません。いずれの場合も、在庫切れ時にリトライしないでください。
• 書き込みコマンドの盲目的なリトライ禁止：order create、cart add、payment create-intent などの書き込み操作が失敗した後、重複注文を防ぐために盲目的にリトライせず、まず状況を確認します（order get / order list）。
• クエリコマンドはネットワークエラー時にリトライされる場合があります（CLIに組み込みリトライがあるため、外部からの追加リトライは不要です）。

セキュリティ制約

• order create を実行する前に、ユーザーに完全な注文サマリー（商品、数量、単価、配送情報、推定合計金額）を表示し、明示的な確認を得てください。--yes はCLIの対話型確認をスキップするだけで、ユーザーの確認を代替できません。
• カートの削除/クリア、注文キャンセルも同様に、最初に確認し、その後実行してください。
• 注文成功後、注文番号、金額、および支払い状況の確認方法をユーザーに報告してください。
• クーポンは使用されません。価格は商品の現在の価格に基づきます。