@rozoai/checkout 0.1.2 → 0.1.4

package/README.md

@@ -32,7 +32,7 @@ npx @rozoai/checkout pay <coinbase-link> --with usdt-solana
 | Polygon | `usdt-polygon` `usdc-polygon` | `137` | 6 decimals |
 | Base | `usdc-base` | `8453` | 6 decimals |
 | Solana | `usdt-solana` `usdc-solana` | `900` | SPL; native SOL not supported |
-| Stellar | `usdc-stellar` | `1500` | memo required — shown in the deposit block |
+| Stellar | `usdc-stellar` | `1500` | `MEMO_TEXT` memo required — shown in the deposit block |
 | Bitcoin Lightning | `btc-lightning` | `lightning` | BOLT11; amounts in satoshis |
 
 Native gas coins (SOL, BNB, ETH, MATIC) and on-chain BTC are not accepted.
@@ -169,7 +169,8 @@ npx @rozoai/checkout pay <coinbase-link> --with usdt-solana
 ```
 
 Wallet: any wallet, no key. `--send` signs locally using your Solana CLI
-keypair or an encrypted keystore.
+keypair or an encrypted keystore, and supports EVM chains and Solana only —
+Stellar and Lightning are Mode A only.
 </details>
 
 <details>
@@ -183,7 +184,8 @@ npx @rozoai/checkout pay <coinbase-link> --with usdt-solana
 ```
 
 Wallet: any wallet, no key. `--send` signs locally using your Solana CLI
-keypair or an encrypted keystore.
+keypair or an encrypted keystore, and supports EVM chains and Solana only —
+Stellar and Lightning are Mode A only.
 </details>
 
 <details>
@@ -197,7 +199,8 @@ npx @rozoai/checkout pay <coinbase-link> --with usdt-solana
 ```
 
 Wallet: any wallet, no key. `--send` signs locally using your Solana CLI
-keypair or an encrypted keystore.
+keypair or an encrypted keystore, and supports EVM chains and Solana only —
+Stellar and Lightning are Mode A only.
 </details>
 
 <details>
@@ -211,7 +214,8 @@ npx @rozoai/checkout pay <coinbase-link> --with usdt-solana
 ```
 
 Wallet: any wallet, no key. `--send` signs locally using your Solana CLI
-keypair or an encrypted keystore.
+keypair or an encrypted keystore, and supports EVM chains and Solana only —
+Stellar and Lightning are Mode A only.
 </details>
 
 <details>
@@ -226,7 +230,8 @@ npx @rozoai/checkout pay <coinbase-link> --with usdt-solana
 ```
 
 Wallet: any wallet, no key. `--send` signs locally using your Solana CLI
-keypair or an encrypted keystore.
+keypair or an encrypted keystore, and supports EVM chains and Solana only —
+Stellar and Lightning are Mode A only.
 </details>
 
 <details>
@@ -240,7 +245,8 @@ openclaw agent exec "Pay this OpenRouter link with USDT on Solana by running: np
 ```
 
 Wallet: any wallet, no key. `--send` signs locally using your Solana CLI
-keypair or an encrypted keystore.
+keypair or an encrypted keystore, and supports EVM chains and Solana only —
+Stellar and Lightning are Mode A only.
 </details>
 
 <details>
@@ -255,7 +261,8 @@ npx @rozoai/checkout pay <coinbase-link> --with usdt-solana
 ```
 
 Wallet: any wallet, no key. `--send` signs locally using your Solana CLI
-keypair or an encrypted keystore.
+keypair or an encrypted keystore, and supports EVM chains and Solana only —
+Stellar and Lightning are Mode A only.
 </details>
 
 <details>
@@ -304,7 +311,8 @@ If the agent has no shell but can make HTTP requests, it can drive the four
 public endpoints directly — see [how it works](docs/how-it-works.md).
 
 Wallet: any wallet, no key. `--send` signs locally using your Solana CLI
-keypair or an encrypted keystore.
+keypair or an encrypted keystore, and supports EVM chains and Solana only —
+Stellar and Lightning are Mode A only.
 </details>
 
 ## Three rules worth knowing
@@ -313,6 +321,10 @@ keypair or an encrypted keystore.
   cached response or a screenshot.
 - **Send the exact amount shown.** It is normally larger than the invoice — it
   includes the bridge and network fees.
+- **Stellar deposits carry a memo, and it is `MEMO_TEXT`** — even when it looks
+  like a number (`65371582` is text, not an id). Sending it as `MEMO_ID`
+  produces a different memo and the payment will not be matched. The deposit
+  block states the type as `receiverMemoType`.
 - **Never pay a funded order twice.** If a payment has already been detected,
   stop and get a human to reconcile it; a second payment to a one-time address
   is not guaranteed to be credited.
@@ -331,6 +343,15 @@ The full list of what this refuses to do, and why, is in
 
 ## Changelog
 
+- **0.1.3** — fixes found by the first real payment. The built bundles no
+  longer crash with `__filename is not defined` on Node 22+ (the esbuild banner
+  now shims `__filename`/`__dirname` as well as `require`, and every bundle is
+  now executed by the test suite). Stellar deposits state their memo type
+  (`MEMO_TEXT`, even when the memo looks numeric). Orders show remaining
+  validity as a duration ("expires in 47m") in the deposit block and in
+  `status`, with the exact command to make a fresh one. Reusing an existing
+  unpaid order, and asking for a coin that differs from it, are both explained
+  instead of reading as errors.
 - **0.1.2** — Mode B no longer needs a raw private key in an environment
   variable. On Solana it uses the `~/.config/solana/id.json` that
   `solana-keygen` already wrote; on EVM an encrypted V3 keystore whose

package/docs/QUICKSTART.es.md

@@ -159,6 +159,7 @@ exigen los scripts de envío.
 ```
 
 Enviar exactamente los campos que entrega este bloque. Para Lightning,
+En Stellar el memo es **`MEMO_TEXT`** aunque parezca numérico: enviarlo como `MEMO_ID` no coincidirá. `deposit.expiresIn` indica cuánto sigue siendo válida la orden.
 `deposit.lnInvoice` contiene la cadena BOLT11 que hay que escanear, y
 `deposit.amount` está en satoshis.
 
@@ -182,8 +183,9 @@ Eso es todo el Modo A. Continuar en el paso 5.
 
 ### La forma opcional: dejar que el script pague (Modo B)
 
-Solo si se quiere que esta máquina firme, y únicamente en cadenas EVM y Solana.
-Esta es la única parte que necesita una clave.
+Solo si se quiere que esta máquina firme, y únicamente en **cadenas EVM y
+Solana**: no hay `--send` para Stellar ni Lightning, que se pagan desde la
+propia billetera. Esta es la única parte que necesita una clave.
 
 **Solana: usar el par de claves que ya se tiene.** Si alguna vez se ejecutó
 `solana-keygen`, `~/.config/solana/id.json` ya existe y se usa automáticamente:

package/docs/QUICKSTART.ja.md

@@ -141,6 +141,7 @@ node scripts/dist/create-order.js --url "$LINK" --chain 900 --token USDT --confi
 ```
 
 このブロックが示すフィールドを、そのとおりに送金してください。Lightning の場合、
+Stellar の memo は数字に見えても**常に `MEMO_TEXT`** です — `MEMO_ID` として送ると一致しません。`deposit.expiresIn` に残りの有効時間が出ます。
 `deposit.lnInvoice` にスキャン用の BOLT11 文字列が入り、`deposit.amount` は
 satoshi 単位になります。
 
@@ -163,8 +164,8 @@ satoshi 単位になります。
 
 ### 任意の方法: スクリプトに支払わせる（モード B）
 
-このマシンに署名させたい場合のみで、対象は EVM チェーンと Solana だけです。鍵が
-必要なのはこの部分だけです。
+このマシンに署名させたい場合のみで、対象は **EVM チェーンと Solana だけ**です。Stellar と
+Lightning に `--send` はなく、自分のウォレットから支払います。鍵が必要なのはこの部分だけです。
 
 **Solana — すでにある鍵ペアをそのまま使います。** `solana-keygen` を一度でも実行して
 いれば `~/.config/solana/id.json` が既に存在し、自動的に使われます:

package/docs/QUICKSTART.md

@@ -151,7 +151,10 @@ scripts require.
 }
 ```
 
-Send exactly the fields this block gives you. For Lightning,
+Send exactly the fields this block gives you. On Stellar the memo is
+**`MEMO_TEXT`** even when it looks numeric — sending it as `MEMO_ID` will not
+match. `deposit.expiresIn` tells you how long the order stays valid. For
+Lightning,
 `deposit.lnInvoice` holds the BOLT11 string to scan, and `deposit.amount` is
 in satoshis.
 
@@ -174,8 +177,9 @@ That is the whole of Mode A. Skip to step 5.
 
 ### The optional way: let the script pay (Mode B)
 
-Only if you want this machine to sign for you, and only on EVM chains and
-Solana. This is the only part that needs a key.
+Only if you want this machine to sign for you, and only on **EVM chains and
+Solana** — there is no `--send` for Stellar or Lightning, which are paid from
+your own wallet. This is the only part that needs a key.
 
 **Solana — use the keypair you already have.** If you have ever run
 `solana-keygen`, `~/.config/solana/id.json` already exists and is used

package/docs/QUICKSTART.zh.md

@@ -129,7 +129,7 @@ node scripts/dist/create-order.js --url "$LINK" --chain 900 --token USDT --confi
 }
 ```
 
-严格按这个信息块给出的字段来发送。对于 Lightning，`deposit.lnInvoice` 里是供扫码的
+严格按这个信息块给出的字段来发送。Stellar 上的 memo 即使看起来是纯数字，也**始终是 `MEMO_TEXT`** —— 按 `MEMO_ID` 发送不会被匹配上。`deposit.expiresIn` 会告诉你订单还有多久过期。对于 Lightning，`deposit.lnInvoice` 里是供扫码的
 BOLT11 字符串，`deposit.amount` 的单位是聪 (satoshis)。
 
 ## 4. 付款
@@ -150,8 +150,8 @@ BOLT11 字符串，`deposit.amount` 的单位是聪 (satoshis)。
 
 ### 可选的方式：让脚本替你付（模式 B）
 
-只有当你想让这台机器替你签名时才需要，而且只支持 EVM 链和 Solana。这是整个流程里
-唯一需要私钥的部分。
+只有当你想让这台机器替你签名时才需要，而且**只支持 EVM 链和 Solana** —— Stellar 和
+闪电网络没有 `--send`，只能用你自己的钱包付。这是整个流程里唯一需要私钥的部分。
 
 **Solana —— 直接用你已有的密钥对。** 只要你跑过 `solana-keygen`，
 `~/.config/solana/id.json` 就已经存在，脚本会自动使用它：

package/docs/README.es.md

@@ -34,7 +34,7 @@ npx @rozoai/checkout pay <coinbase-link> --with usdt-solana
 | Polygon | `usdt-polygon` `usdc-polygon` | `137` | 6 decimales |
 | Base | `usdc-base` | `8453` | 6 decimales |
 | Solana | `usdt-solana` `usdc-solana` | `900` | SPL; SOL nativo no admitido |
-| Stellar | `usdc-stellar` | `1500` | memo obligatorio — se muestra en el bloque de depósito |
+| Stellar | `usdc-stellar` | `1500` | memo `MEMO_TEXT` obligatorio — se muestra en el bloque de depósito |
 | Bitcoin Lightning | `btc-lightning` | `lightning` | BOLT11; importes en satoshis |
 
 Las monedas de gas nativas (SOL, BNB, ETH, MATIC) y el BTC on-chain no se aceptan.
@@ -103,7 +103,7 @@ Para pagar un enlace de pago de OpenRouter / Coinbase, ejecuta:
 npx @rozoai/checkout pay <coinbase-link> --with usdt-solana
 ```
 
-Billetera: cualquier billetera, **sin clave**. Solo `--send` la necesita: firma localmente con el par de claves de la CLI de Solana o un keystore cifrado.
+Billetera: cualquier billetera, **sin clave**. Solo `--send` la necesita: firma localmente con el par de claves de la CLI de Solana o un keystore cifrado, y solo admite cadenas EVM y Solana (Stellar y Lightning son solo Modo A).
 </details>
 
 <details>
@@ -329,6 +329,14 @@ La lista completa de lo que esta herramienta se niega a hacer, y por qué, está
 
 ## Registro de cambios
 
+- **0.1.3** — Correcciones surgidas del primer pago real. Los bundles ya no fallan
+  con `__filename is not defined` en Node 22+ (el banner de esbuild ahora define
+  `__filename`/`__dirname` además de `require`, y las pruebas ejecutan cada bundle
+  de verdad). Los depósitos de Stellar indican el tipo de memo (`MEMO_TEXT`, aunque
+  el memo parezca numérico). Las órdenes muestran la validez restante como duración
+  ("expires in 47m") en el bloque de depósito y en `status`, con el comando exacto
+  para crear una nueva. Reutilizar una orden impaga existente, y pedir una moneda
+  distinta a la suya, ahora se explican en lugar de parecer errores.
 - **0.1.2** — El Modo B ya no necesita una clave privada en bruto en una variable
   de entorno. En Solana usa el `~/.config/solana/id.json` que `solana-keygen` ya
   creó; en EVM un keystore V3 cifrado cuya frase de contraseña se solicita.

package/docs/README.ja.md

@@ -33,7 +33,7 @@ npx @rozoai/checkout pay <coinbase-link> --with usdt-solana
 | Polygon | `usdt-polygon` `usdc-polygon` | `137` | 小数点以下 6 桁 |
 | Base | `usdc-base` | `8453` | 小数点以下 6 桁 |
 | Solana | `usdt-solana` `usdc-solana` | `900` | SPL。ネイティブの SOL は非対応 |
-| Stellar | `usdc-stellar` | `1500` | メモが必須 — 入金ブロックに表示されます |
+| Stellar | `usdc-stellar` | `1500` | `MEMO_TEXT` のメモが必須 — 入金ブロックに表示されます |
 | Bitcoin Lightning | `btc-lightning` | `lightning` | BOLT11。金額は satoshi 単位 |
 
 ネイティブのガス通貨（SOL、BNB、ETH、MATIC）およびオンチェーンの BTC は受け付けません。
@@ -89,7 +89,7 @@ OpenRouter / Coinbase の決済リンクを支払うには、次を実行して
 npx @rozoai/checkout pay <coinbase-link> --with usdt-solana
 ```
 
-ウォレット: どのウォレットでも構いません。**鍵は不要です。** Solana CLI の鍵ペアまたは暗号化された keystore を使う `--send` の場合だけ
+ウォレット: どのウォレットでも構いません。**鍵は不要です。** Solana CLI の鍵ペアまたは暗号化された keystore を使う `--send`（EVM チェーンと Solana のみ、Stellar と Lightning はモード A 専用）の場合だけ
 環境変数の鍵が必要です。
 </details>
 
@@ -320,6 +320,13 @@ WalletConnect 専用のモバイルウォレット、取引所アカウント。
 
 ## 変更履歴
 
+- **0.1.3** — 最初の実際の支払いで見つかった不具合の修正。ビルド済みバンドルが Node 22 以降で
+  `__filename is not defined` により停止しなくなりました（esbuild の banner が `require` に加えて
+  `__filename`/`__dirname` も定義し、テストが各バンドルを実際に実行するようになりました）。Stellar の
+  入金では memo の種類（`MEMO_TEXT`。memo が数字に見える場合も同様）を明示します。注文の残り有効時間を
+  入金ブロックと `status` の両方で継続時間として表示し（"expires in 47m"）、期限切れ時には新しい注文を
+  作るコマンドをそのまま示します。既存の未払い注文の再利用と、それと異なる通貨を指定した場合の双方を、
+  エラーではなく説明として提示します。
 - **0.1.2** — モード B で環境変数に生の秘密鍵を置く必要がなくなりました。Solana では
   `solana-keygen` が既に作成した `~/.config/solana/id.json` を、EVM では暗号化された
   V3 keystore（パスフレーズは対話的に入力）を使います。`--keyfile` でどちらも明示でき、

package/docs/README.zh.md

@@ -30,7 +30,7 @@ npx @rozoai/checkout pay <coinbase-link> --with usdt-solana
 | Polygon | `usdt-polygon` `usdc-polygon` | `137` | 6 位小数 |
 | Base | `usdc-base` | `8453` | 6 位小数 |
 | Solana | `usdt-solana` `usdc-solana` | `900` | SPL；不支持原生 SOL |
-| Stellar | `usdc-stellar` | `1500` | 必须带 memo —— 会在充值信息块里给出 |
+| Stellar | `usdc-stellar` | `1500` | 必须带 `MEMO_TEXT` memo —— 会在充值信息块里给出 |
 | Bitcoin Lightning | `btc-lightning` | `lightning` | BOLT11；金额单位为聪 |
 
 原生 gas 币（SOL、BNB、ETH、MATIC）以及链上 BTC 均不接受。
@@ -82,7 +82,7 @@ Codex 会读取项目根目录的 `AGENTS.md`。加一条常驻指令，它就
 npx @rozoai/checkout pay <coinbase-link> --with usdt-solana
 ```
 
-钱包：任意钱包，**无需私钥**。只有 `--send` 需要，它用你的 Solana CLI 密钥对或加密 keystore 在本地签名。
+钱包：任意钱包，**无需私钥**。只有 `--send` 需要，它用你的 Solana CLI 密钥对或加密 keystore 在本地签名；仅支持 EVM 链和 Solana —— Stellar 与闪电网络只能用模式 A。
 </details>
 
 <details>
@@ -292,6 +292,12 @@ echo '.env' >> .gitignore
 
 ## 更新日志
 
+- **0.1.3** —— 第一笔真实付款暴露出来的问题修复。构建产物在 Node 22+ 上不再因
+  `__filename is not defined` 崩溃（esbuild banner 现在同时注入 `__filename`/`__dirname`
+  和 `require`，并且测试会真正执行每一个构建产物）。Stellar 充值现在会明确标出 memo
+  类型（`MEMO_TEXT`，即使 memo 看起来是纯数字）。订单在充值信息块和 `status` 里都会以
+  时长显示剩余有效期（"expires in 47m"），过期时给出重新下单的完整命令。复用已有的未付
+  订单、以及所选币种与已有订单不一致这两种情况，现在都会被解释清楚，而不是看起来像报错。
 - **0.1.2** —— 模式 B 不再需要把原始私钥放进环境变量。Solana 直接用 `solana-keygen`
   已经写好的 `~/.config/solana/id.json`；EVM 用加密的 V3 keystore，口令交互式提示输入。
   `--keyfile` 可以显式指定其中任一种，相关设置也可以放进已 gitignore 的 `.env`。

package/docs/review-history.md

@@ -0,0 +1,77 @@
+# Review history
+
+[← back to the README](../README.md) · [Safety design](safety.md)
+
+This tool moves other people's money. It was reviewed adversarially before it
+was written, again after it was written, and again after the first real payment.
+This page is the record of that.
+
+## Design review — 3 rounds, before any code existed
+
+The design was written as a plan document and reviewed by an independent model
+with a standing instruction to hunt for anything that could lose funds. No code
+was written until the plan passed with no P0 findings.
+
+| Round | Verdict |
+|---|---|
+| 1 | 6 P0, 7 P1, 2 P2 — plan revised |
+| 2 | still had P0s: several round-1 fixes were incomplete, plus one new P0 — plan revised again |
+| 3 | no P0 — implementation began |
+
+The P0s were about the plan being wrong regarding the payment rails, not about
+style. Among them: the reuse rule was mis-stated (an existing order is reused
+whenever it is merely unexpired, not only when it is unpaid); the binding
+confirmation was placed before the deposit details existed, so it could not
+bind them; and the payment link could be consumed by another payer between the
+quote and the signature, which needed a re-check immediately before paying.
+
+## Code review — 2 rounds, after implementation
+
+| Round | Verdict |
+|---|---|
+| 1 | 8 P0, 10 P1, 5 P2 |
+| 2 | 20 of 23 resolved; 3 residual findings, then fixed |
+
+The round-1 P0s were the interesting ones, and each is now a real code path
+with its own error code and tests:
+
+- the confirmation gate and the `--send` opt-in were documented but not
+  actually enforced
+- the send-once claim was a check-then-act race that two concurrent processes
+  could both pass
+- an unreadable `amountReceived` was treated as "no money received" rather than
+  as money
+- the post-create comparison ignored security-critical fields when they were
+  simply absent
+- payability was not re-proved immediately before signing, and incomplete
+  upstream state read as payable
+- deposit instructions were not validated for completeness before being shown
+- provider errors could leak credential-bearing URLs
+- the tracked-secret check failed open when it could not consult git
+
+## First real payment
+
+A live payment then settled in about a minute — and surfaced four more defects,
+all fixed in 0.1.3:
+
+- the built bundles crashed on newer Node because the bundler's CommonJS shim
+  was incomplete; it had never been caught because only `--help` was ever run
+  against a built bundle. The test suite now executes every bundle.
+- the Stellar memo type was not stated anywhere, and sending that memo with the
+  wrong type loses the payment. It is `MEMO_TEXT`, and the deposit block now
+  says so.
+- reusing an existing unpaid order, and asking for a coin that differs from it,
+  both read as errors rather than as the ordinary situations they are
+- nothing showed how long an order had left, and a real payment nearly missed
+  its window
+
+## What this means for a reader
+
+Every finding above is closed, and the behaviours they produced are covered by
+the test suite, which runs entirely offline against recorded fixtures. The full
+list of what this tool refuses to do, and why, is in
+[docs/safety.md](safety.md).
+
+The detailed review transcripts are kept internally; they quote source from
+private repositories and so are not published here. The findings themselves are
+summarised above in full — nothing material is omitted.

package/llms.txt

@@ -54,6 +54,8 @@ Where the material comes from:
   `cast wallet import <name> --interactive` writes a V3 keystore to
   ~/.foundry/keystores/<name>; `geth account import` also writes one. Browser
   wallets do not export keystores, only raw keys.
+- --send supports EVM chains and Solana ONLY. Stellar and Lightning are paid
+  from the user's own wallet (Mode A); there is no local signing for them.
 - Hardware wallets, WalletConnect-only wallets and exchange accounts CANNOT be
   used with --send. Those users take the default keyless path, which works with
   any wallet.
@@ -108,7 +110,11 @@ private key (EVM and Solana only); every other path is keyless.
    Pay EXACTLY source.amount of the requested token on the requested chain to
    source.receiverAddress, including every other field the block carries (Stellar
    routes on a shared hub address plus source.receiverMemo, so omitting the memo
-   loses the payment).
+   loses the payment). The Stellar memo is ALWAYS MEMO_TEXT, even when it is all
+   digits (e.g. 65371582) — sending it as MEMO_ID produces a different memo and
+   the payment will not match. The deposit block reports this as
+   receiverMemoType. Orders expire: deposit.expiresIn / status expiry.expiresIn
+   give the remaining validity as a duration.
    For Lightning, pay the BOLT11 in source.lnInvoice (receiverAddress is empty).
 
 4) Poll until settled:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rozoai/checkout",
-  "version": "0.1.2",
+  "version": "0.1.4",
   "type": "module",
   "description": "Pay an OpenRouter Coinbase Payment Link with BTC Lightning, or USDT/USDC on Solana, BNB Chain, Ethereum, Polygon, Base or Stellar.",
   "license": "MIT",