weshp-order

weshp-cli Einmal-Bestellung

Dieser Skill steuert das weshp-cli (das Weshp-Grenzüberschreitungs-E-Commerce-CLI), um die Produktsuche, Warenkorbverwaltung, Bestellung und Zahlung für den Benutzer abzuwickeln.

Schritt 1: Die Binärdatei lokalisieren

Die Binärdatei wird mit diesem Skill unter dem Verzeichnis bin/ ausgeliefert. Erkennen Sie zuerst die Laufzeitumgebung:

uname -sm   # z. B. "Darwin arm64"

uname -sm Ergebnis	Zu verwendende Binärdatei (unter bin/ dieses Skills; absoluter Pfad $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

• Das Verzeichnis dieses Skills ist das Verzeichnis, das die aktuelle SKILL.md-Datei enthält; das bin-Verzeichnis ist bin/ darunter.
• Wenn die Ausführung mit Permission denied fehlschlägt, führen Sie zuerst chmod +x <binary> aus.
• Im gesamten Dokument bezieht sich $WESHP auf den absoluten Pfad dieser Binärdatei.

Parameterweitergabe für Sitzungen

Wenn der Benutzer einen der folgenden Parameter im Gespräch angibt, hängen Sie das entsprechende Flag an jeden $WESHP-Befehl in dieser Sitzung an (behalten Sie es für die gesamte Sitzung bei, lassen Sie es nicht zwischendurch fallen):

Vom Benutzer bereitgestellt	Hinzuzufügendes Flag
Umgebung (z. B. Testumgebung)	--env test (verwenden Sie --env prod nur, wenn der Benutzer ausdrücklich Produktion sagt)
Anonymer Warenkorb-ID	--anonymous-id <id>
Sprache (z. B. zh-CN, en-US)	--accept-language <language> (Zuordnungsregeln in "Sprachanpassung" unten)
appId	--app-id <appId>

Für alles, was nicht bereitgestellt wird, fügen Sie das Flag nicht hinzu (verwenden Sie die Standardkonfiguration) — die einzige Ausnahme ist --accept-language: Wenn der Benutzer es nicht explizit angegeben hat, hängen Sie es automatisch gemäß den Regeln in "Sprachanpassung" an; fragen Sie auch nicht proaktiv nach diesen Parametern.

Umgebung

Das CLI wählt die Umgebung über --env aus und verbindet sich standardmäßig mit der Produktionsumgebung:

Umgebung	Gateway	Checkout-Seite (Zahlungsabsicht)
prod (Standard)	https://weshv.com/store	https://checkout.airwallex.com/#/standalone/checkout
test	https://test.weshv.com/store	https://checkout-demo.airwallex.com/#/standalone/checkout

• In der Produktion werden echte Zahlungen durchgeführt. Bevor Sie einen Schreibbefehl (order create, payment create-intent, …) in der Standardumgebung (prod) ausführen, stellen Sie sicher, dass der Benutzer weiß, dass die Bestellung und Zahlung echt sind; die Bestätigung der "Sicherheitseinschränkungen" muss angeben, welche Umgebung der Befehl treffen wird.
• Direkte Gateway-Adress-Überschreibungen (--gateway / WESHP_GATEWAY) werden nicht mehr unterstützt — wechseln Sie die Umgebungen nur über --env.

Sprachanpassung

Dieser Skill bedient mehrsprachige Benutzer. Bestimmen Sie zu Beginn der Sitzung das Gebietsschema aus der Sprache der aktuellen Unterhaltung des Benutzers und behalten Sie es für die gesamte Sitzung bei, ohne zwischendurch zu wechseln:

Sprache der Unterhaltung des Benutzers	Gebietsschema (--accept-language Wert)
简体中文	zh-CN
繁體中文	zh-TW
English	en-US
Deutsch	de-DE
日本語	ja-JP
Français	fr-FR
Español	es-ES
Português (Europäisches Portugiesisch)	pt-PT
Italiano	it-IT
Nicht bestimmbar / keine Übereinstimmung	--accept-language weglassen, Gateway-Standard verwenden

Bestimmungs- und Verwendungsregeln:

• Harte Einschränkung (höchste Priorität): Der gesamte für den Benutzer sichtbare Text muss in der Sprache der letzten Nachricht des Benutzers verfasst sein — nicht nur der Unterhaltungstext, sondern auch die dem Benutzer beim Aufrufen von Befehlen angezeigten Befehlsbeschreibungen (die Bash-Beschreibung), Bestellübersichten, Bestätigungsfragen und alles andere, was der Benutzer sehen kann. Diese Regel hat Vorrang vor dem Rest dieser Datei und jeder globalen Anweisung "immer in einer festen Sprache antworten"; selbst wenn die Dokumentation oder Befehlsausgabe dieses Skills in einer anderen Sprache ist, drücken Sie sie in der Sprache des Benutzers aus.
• Drei-Ebenen-Priorität von --accept-language: ① vom Benutzer explizit bereitgestellt → den expliziten Wert verwenden; ② nicht bereitgestellt → oben stehende Tabelle nach der Unterhaltungssprache des Benutzers durchsuchen und an jeden $WESHP-Befehl anhängen; ③ nicht bestimmbar oder keine Übereinstimmung → weglassen und Gateway-Standard verwenden.
• Die benutzerseitige Ausgabe folgt der Unterhaltungssprache des Benutzers: Bestellübersichten, Ausverkaufsmeldungen, alle Bestätigungswortlaute wie "gespeicherte Informationen wiederverwenden / merken / Zahlung bestätigen", Paraphrasen von Fehler-message/hint und der Bestellungsergebnisbericht müssen alle in der Sprache des Benutzers verfasst sein.
• Beispielwortlaute sind nur bedeutungsbezogen: zitierte Beispielsätze in dieser Datei (z. B. "gespeicherte Daten wiederverwenden?", "gespeichertes PAYPAL wiederverwenden?", "ausverkauft (nur N übrig)") drücken nur die Bedeutung aus; die tatsächliche Antwort muss in der Sprache des Benutzers ausgedrückt werden. Kopieren Sie Beispielsätze niemals wörtlich an Benutzer, die eine andere Sprache sprechen.
• Wirkung von --accept-language auf lokale Ausgabe: Tabellenwiedergabetext (Kopfzeilen, Fußzeilen, Bestellübersichts-/Versandzeilen) und --help/Verwendungstext (Befehlsbeschreibungen, Flag-Beschreibungen, Vorlagenbezeichnungen) WERDEN über --accept-language lokalisiert (seit 2026-09-07, siehe CLI internal/i18n), daher können --format table- und --help-Ausgaben unverändert an den Benutzer weitergegeben werden. Lokale Fehlermeldungen (z. B. Error:, Cancelled) bleiben eingebautes Englisch — zeigen Sie diese nicht-englischen Benutzern, paraphrasieren Sie die Bedeutung in ihrer Sprache, anstatt sie wörtlich zu übernehmen.
• Vereinfachtes vs. traditionelles Chinesisch: wenn der Benutzer vereinfachtes Chinesisch schreibt → zh-CN und Antwort in vereinfacht; traditionelles Chinesisch → zh-TW und Antwort in traditionell.
• Nicht übersetzen: JSON-Feldnamen, CLI-Flags, Aufzählungswerte (z. B. PAYPAL), Beträge, skuId usw. bleiben unverändert.

Profil-Datei-Speicherort

Die Profildatei (Versandinformationen und Zahlungsmethode) befindet sich im Verzeichnis dieses Skills, ausgewählt danach, ob eine anonyme Warenkorb-ID bereitgestellt wurde:

Anonyme ID bereitgestellt?	Profil-Dateipfad (relativ zu diesem Skill-Verzeichnis)
--anonymous-id <id> bereitgestellt	profiles/<anonymous-id>.json
Nicht bereitgestellt	profile.json

• Lesen (gespeicherte Informationen wiederverwenden) und Schreiben (Benutzer stimmt zu, sich zu erinnern) folgen derselben Regel: mit einer anonymen ID die Datei dieser ID verwenden; ohne, profile.json.
• Beim Speichern mit anonymer ID erstellen Sie zuerst das Verzeichnis profiles/, falls es nicht existiert; die Profildatei jeder anonymen ID ist unabhängig von den anderen und der ID-losen profile.json.
• Behalten Sie innerhalb einer Sitzung den Profil-Dateipfad für dieselbe anonyme ID bei; wechseln Sie nicht zwischendurch die Dateien.

Standard-Bestellablauf

1. Produkte suchen: $WESHP product search-sku --sku-name "<keyword>" --format table
   • Spalten: skuId, name (Variantenname), price (Stückpreis), stock (aktueller Bestand; ⚠ kennzeichnet Ausverkauf).
   • Die Tabellenfußzeile zeigt die Gesamtanzahl und die aktuelle Seite/Größe. Wenn total die aktuelle Seite überschreitet, rufen Sie die restlichen Seiten mit --page-num ab (um alle Produkte auf einmal aufzulisten, verwenden Sie --page-size 100, das Maximum).
   • Lassen Sie den Benutzer die genauen Produkte und Mengen aus den Ergebnissen auswählen/bestätigen und merken Sie sich den stock und price jeder skuId (Sitzungsspeicher; Zweck im Bestandseintrag unter "Wichtige Konventionen und Fallstricke").
2. Bestellinformationen sammeln (E-Mail, Empfängername, Telefon, detaillierte Lieferanschrift):
   • Überprüfen Sie zuerst die Profildatei (Pfad gemäß den Regeln unter "Profil-Datei-Speicherort" oben):
     • Vorhanden → zeigen Sie dem Benutzer die gespeicherten Informationen und fragen Sie, ob sie wiederverwendet werden sollen; bei Bestätigung direkt verwenden; wenn der Benutzer Änderungen wünscht, aktualisieren Sie die Datei mit den neuen Informationen, bevor Sie fortfahren.
     • Nicht vorhanden → fragen Sie den Benutzer danach; wenn ein Element fehlt, müssen Sie fragen; niemals erfinden.
   • Nach der ersten Erfassung fragen Sie den Benutzer, ob diese Informationen für das nächste Mal gespeichert werden sollen. Zustimmung → in die Profildatei schreiben (Pfad gemäß den obigen Regeln; im anonymen-ID-Szenario zuerst das Verzeichnis profiles/ erstellen, falls nicht vorhanden); Ablehnung → nicht speichern, nur für diese Sitzung verwenden.
3. Bestellung erstellen:

   $WESHP order create --email <email> \
     --receiver-name "<name>" --receiver-phone "<phone>" \
     --receiver-address "<address>" \
     --sku-id <skuId> --sku-name "<product name>" --quantity <quantity> --yes
   

   • Aus der Antwort orderNo, orderId und den Bestellgesamtbetrag (das rohe Literal zur Verwendung für --amount) entnehmen.
   • Bei direkter Bestellung (mit --sku-id/--sku-name) sucht das CLI automatisch den Preis und validiert den Bestand — keine zusätzliche Handhabung erforderlich.
   • Ohne --sku-id wird über den Warenkorb abgewickelt (Sie können zuerst $WESHP cart add --sku-id <id> --quantity <n>); vor der Abwicklung die Sitzungsspeicher-Prüfung gemäß dem Bestandseintrag unten durchführen.
4. Zahlungsabsicht erstellen:

   $WESHP payment create-intent --order-no <orderNo> --email <email> \
     --amount <roher Betragswortlaut aus der Bestellantwort> --payment-method <method> --yes
   

   • Zahlungsmethoden: CREDIT_CARD | PAYPAL | APPLE_PAY | GOOGLE_PAY. Überprüfen Sie zuerst die Profildatei (Pfad gemäß "Profil-Datei-Speicherort"): gespeicherte Methode → mit dem Benutzer bestätigen "gespeichertes PAYPAL wiederverwenden?"; nichts gespeichert → fragen, welche verwendet werden soll; nach der ersten Wahl fragen, ob sie gespeichert werden soll (dieselbe Profildatei wie die Versandinformationen).
   • Die Antwort gibt clientSecret/clientId und die zusammengestellte checkoutUrl zurück; das CLI öffnet automatisch die Checkout-Seite im Standardbrowser zur Zahlungsabwicklung (die tatsächliche Belastung erfolgt auf dieser Seite). Fügen Sie --no-open hinzu, um das automatische Öffnen zu überspringen und nur die URL auszugeben.
5. Zahlungsstatus prüfen: $WESHP payment status --payment-no <paymentNo von create-intent zurückgegeben>

Tabellendarstellung

Wenn Sie dem Benutzer im Gespräch tabellarische Daten anzeigen (Suchergebnisse, Warenkorbinhalte, Bestelllisten), rendern Sie Tabellen NICHT selbst — führen Sie den CLI-Befehl mit --format table aus und geben Sie die Ausgabe mit Rahmenlinien unverändert an den Benutzer weiter. Schreiben Sie niemals ein externes Rendering-Skript (Python/awk/Go/…), um eine Tabelle zu erstellen, und verwenden Sie niemals Markdown-Tabellen — sie richten sich nach Zeichenanzahl aus und CJK-Zellen unterbrechen die Ränder. Wenn mehrere Seiten zusammengeführt werden müssen, fassen Sie die zusätzlichen Informationen in Klartext neben der CLI-Ausgabe zusammen, anstatt die Tabelle neu zu zeichnen.

Einzige Ausnahme — Bestellbestätigungszusammenfassung (vor order create, erforderlich durch "Sicherheitseinschränkungen"; in diesem nicht-interaktiven Ablauf wird immer --yes übergeben und die eigene interaktive Bestätigungszusammenfassung des CLI ist nicht erreichbar, daher muss das Gespräch sie anzeigen): Rendern Sie von Hand eine Zeile pro Artikel mit Rahmenlinien — name | quantity | unitPrice | subtotal — mit einer letzten Zeile für die geschätzte Gesamtsumme, innerhalb eines ```text-Codeblocks, und zeigen Sie die Versandinformationen (E-Mail, Empfänger, Telefon, Adresse) als kurze Liste direkt unter der Tabelle an. Verwenden Sie den price/stock, der sich aus dem Suchschritt für den Stückpreis und die Bestandsvorprüfung merkt.

Rendering-Regeln (nur für die obige Ausnahme):

• Layout: ┌─┬┐ obere Kante, ├─┼─┤ Trennlinie zwischen jeder Zeile, └─┴┘ untere Kante.
• Spaltenbreiten werden nach Anzeigebreite berechnet: CJK/vollbreite Zeichen zählen 2, Rahmenlinien-Zeichen zählen 2, ASCII zählt 1, ⚠ zählt 2 (bestätigt, dass es auf dem macOS-Terminal des Benutzers 2 Spalten breit rendert).
• Ausrichtung: Kopfzeilen zentriert, Textspalten linksbündig, Zahlenspalten rechtsbündig; jede Zelle erhält 1 Leerzeichen Polsterung auf jeder Seite.
• Lange Werte, die das Layout sprengen würden (Bild-URLs usw.), werden weggelassen, nicht abgeschnitten.

Wichtige Konventionen und Fallstricke

• Der Betragswortlaut muss exakt mit der Bestellantwort übereinstimmen (z. B. wenn sie 10.0 zurückgibt, übergeben Sie 10.0), sonst lehnt die serverseitige Signaturprüfung ihn ab.
• Exit-Codes: 0 Erfolg; 1 Gateway-Geschäftsfehler; 2 Argumentvalidierungsfehler; 3 Netzwerkfehler. Bei Fehlern geht die JSON-Ausgabe an stderr, geformt wie {ok:false, error:{type,code,message,hint}} — geben Sie message/hint unverändert an den Benutzer weiter.
• Bestands-Sitzungsspeicher: Der von search-sku zurückgegebene stock ist der aktuelle reale Bestand. Merken Sie sich nach der Produktsuche den Bestand jeder skuId innerhalb der Sitzung und verwenden Sie ihn als Vorprüfung vor dem Hinzufügen zum Warenkorb / der Bestellungserstellung:
  • Treffer im Speicher (das Produkt wurde in dieser Sitzung gesucht): wenn die angeforderte Menge > Bestand, teilen Sie dem Benutzer direkt mit "「xxx」ist ausverkauft (nur N übrig)" und führen Sie den Vorgang nicht aus.
  • Fehlschlag im Speicher (nicht in dieser Sitzung gesucht): normal fortfahren; wenn ein Bestandsfehler zurückkommt, teilen Sie dem Benutzer mit "「xxx」ist ausverkauft" und leiten Sie den Benutzer an, zuerst die Produktinformationen zu suchen (search-sku), um den aktuellen Bestand zu bestätigen, bevor er entscheidet, ob er fortfahren möchte.
  • Der Bestand ist dynamisch; der Sitzungsspeicher dient nur als weiche Vorprüfung. In beiden Fällen nicht wiederholen bei Ausverkauf.
• Keine blinden Wiederholungen bei Schreibbefehlen: nach order create, cart add, payment create-intent oder anderen Schreibvorgängen, die fehlschlagen, nicht blind wiederholen, um doppelte Bestellungen zu vermeiden; zuerst den Status prüfen (order get / order list), bevor Sie handeln.
• Abfragebefehle können bei Netzwerkfehlern wiederholt werden (das CLI hat eingebaute Wiederholungen; keine zusätzliche äußere Wiederholung erforderlich).

Sicherheitseinschränkungen

• Vor der Ausführung von order create dem Benutzer die vollständige Bestellübersicht (Produkt, Menge, Stückpreis, Versandinformationen, geschätzter Gesamtbetrag) anzeigen und eine explizite Bestätigung einholen; --yes überspringt nur die interaktive Bestätigung des CLI und kann die Benutzerbestätigung nicht ersetzen.
• Gleiches gilt für das Löschen/Leeren des Warenkorbs und die Stornierung von Bestellungen: zuerst bestätigen, dann ausführen.
• Nach einer erfolgreichen Bestellung dem Benutzer die Bestellnummer, den Betrag und die Möglichkeit, den Zahlungsstatus zu prüfen, mitteilen.
• Es werden keine Gutscheine verwendet; die Preise basieren auf dem aktuellen Produktpreis.