docs(order-compute): egress hang warning, legacy names, cap units, zone shape, x402 version

[GigaHierz]

Why

Two reports from completed e2-micro rentals (#5 on macOS, #9 on Linux) list things the skill either under-states or does not say:

• A denied outbound connection hangs rather than refusing ([docs] Confirmations from a real e2-micro purchase, plus an undocumented x402 version mismatch #5, item 2). The skill mentioned it in half a sentence. For an unattended script this is the expensive failure mode: it silently burns the lease the user already paid for.
• setup prints legacy service=cpay and instances are named cpay-<txprefix> ([docs] Confirmations from a real e2-micro purchase, plus an undocumented x402 version mismatch #5 item 4, [feedback] Linux e2-micro rental OK — leftover cpay naming, USDC-labelled cap, zone shape drift, receipts still non-recoverable #9 item 1). An agent following docs that only say "buy" can conclude it hit the wrong product.
• The cap confirmation hard-codes "USDC" ([feedback] Linux e2-micro rental OK — leftover cpay naming, USDC-labelled cap, zone shape drift, receipts still non-recoverable #9, item 2). An agent comparing a USDT balance against a "USDC cap" may refuse a valid USDT purchase. I checked accounts.js in the published @celo/buy@0.5.0: the cap is stored as atomic units with no token, so it applies to USDT at the same rate.
• zone is a short name in the paid response and a full GCE URL in the poll ([feedback] Linux e2-micro rental OK — leftover cpay naming, USDC-labelled cap, zone shape drift, receipts still non-recoverable #9, item 3).
• This gateway's 402 is x402Version: 1 while Celo's facilitator issues v2 ([docs] Confirmations from a real e2-micro purchase, plus an undocumented x402 version mismatch #5, item 3), and nothing signals it.
• The published latency was read as an upper bound; [feedback] Linux e2-micro rental OK — leftover cpay naming, USDC-labelled cap, zone shape drift, receipts still non-recoverable #9 and [feedback] USDT-only wallet: insufficient_balance recommends funding USDC instead of --token USDT; setup cannot adopt a declared agent wallet #11 measured 16 s and 43 s for the same leg.

What

skills/order-compute/SKILL.md only.

• Egress paragraph is now a bold warning with two timeout examples.
• A note after the setup command that the cpay names are expected.
• Cap paragraph: amount is in dollars; the "USDC" wording is cosmetic; a USDT purchase is governed by the same cap.
• x402 version note at the end of the CLI section.
• "Collect the result": observed latency range, and take zone from the paid response, not the poll.

Not in this PR: the cross-wallet funding note (#9, item 5) is in #15, and the receipts limitation (#9, item 4) is already documented and tracked upstream. The CLI wording fixes themselves (cap message, legacy label, zone normalisation) are filed upstream; this PR documents the current behaviour so agents stop misreading it today.

Verification

• npm pack @celo/buy@0.5.0 → dist/commands/accounts.js writes the cap via setDailySpendCap(name, atomic.toString()) and prints fmtAmount(atomic, 6, 'USDC'); no token is stored.
• dist/commands/setup.js prints stored in OS keychain (legacy service=cpay).
• Unpaid POST https://usebuy.ai/gcloud/vm today returns "x402Version":1.
• PR ci: check the skill against the deployed gateway, not a branch #10's check-against-gateway.mjs passes on this branch (prices and types unchanged).

Closes #5, closes #9.

🤖 Generated with Claude Code

[olanrewajuakeem]

Reporter of #5 here — the egress rewrite is exactly right, and making the hang the headline rather than a clause is the important change. The 15–45s range matches what I measured: 28.95s wall clock on macOS for buy curl → paid response, with a cold npx --yes resolution included.

Two things I'd add, both about the hang:

1. The failure table has no row for "script hung past the lease." The new warning says the poll never reaches done — but every other row in that table answers "charged?", and this path doesn't appear at all. An agent that misses the warning pays, provisions, hangs for the full hour, and gets nothing. Is that refundable? What should it report? Right now the most expensive failure mode is the only one without an entry.

2. A per-call timeout still leaves one unguarded call able to consume the lease. Worth suggesting a bound on the whole script as well — e.g. prefixing with timeout 3000 — so a script that stalls exits while the lease still has time to return partial output, rather than being killed by expiry with nothing retained.

Both are cheap to document, and both turn a silent loss into a reported one.