x402-economy-triage

You triage the three.ws x402 agent economy. Do not guess; run the checks in this order and report which failure class matched.

Failure classes, in check order

1. Settle-floor starvation (config, no funding needed). Grep production logs for fee_wallet_below_floor first: gcloud logging read 'resource.type="cloud_run_revision" resource.labels.service_name="three-ws-api" "fee_wallet_below_floor"' --freshness=6h --project aerial-vehicle-466722-p5 Use the BARE quoted string, never textPayload:"...". This service logs structured JSON, so the marker lives in jsonPayload; a textPayload: query returns zero rows with exit 0 and reads as "class ruled out" while the cause is live. That false negative sent a 2026-07-30 triage straight past the real cause. If it hits, this is the settle outage that looks like dry wallets but is fixed by config (floor/limiter env vars on the Cloud Run service), not by funding. The log line carries the exact shortfall (fee_wallet_below_floor:3823135<4000000). Read it before acting: a shortfall of a few hundred thousand lamports means the refill leg is blocked, NOT that the floor is set too high. Do not lower the floor to clear it.

   Check class 5 before concluding the floor itself is the problem. Floor starvation is usually a symptom: if the Solana RPC tier is exhausted, the treasury reclaim cannot run, so the sponsor drifts under its floor and every settle fails. On 2026-07-30 that chain ran from 18:00 to 02:45 and cleared the moment SOLANA_RPC_URL was repointed at a healthy lane, with no funding at all.

2. Capital dispersion (one-way drift into agent wallets). Run node scripts/audit-wallet-flows.mjs to get the dispersion picture. The funding master IS the x402 payer (shared alias); SOL parked in per-agent wallets is stranded capital, not a leak. scripts/gpu-capacity.mjs is unrelated; do not touch it.

3. Genuinely dry. Never quote a remembered burn rate; measure it, because the figure has been wrong by 10x. Derive lamports-per-settle and the settle count from x402_self_facilitator_log over the window you care about, then multiply. If the payer balance is below a day of measured burn, report the exact balance, the derived rate, the resulting runway in hours, and that the owner must fund or throttle (the env levers, governors and their defaults are in docs/x402-ring-economy.md; the payer-float row and its floor var are in the env table of docs/ops/gcp-production.md). Never top up per-agent wallets; that strands SOL and kills the rail.

   Also check affordability against the ring's own prices before calling it dry. A settle_unaffordable stall means X402_PRICE_RING_SETTLE exceeds the ring payer's float, which is a config fix (lower the price with --update-env-vars), not a funding problem.

4. gcloud auth dead. If gcloud commands fail with invalid_rapt, that is the sperax.io Workspace reauth policy, not token expiry. There is no on-machine fallback: gather everything that does not need gcloud, then report that the owner must run gcloud auth login once.

5. Solana RPC lane exhaustion (upstream of classes 1 and 3). Probe every lane with a METERED method; getHealth is unmetered and answers ok on an exhausted endpoint. One getBalance POST per endpoint tells you whether the paid tier is dark. If it is, expect blocked reclaims, broadcast_failed settles and floor drift. Two tells that a broadcast_failed cluster is RPC-shaped rather than insufficient funds: it is amount-independent (group failures by payment amount, and a rail fault fails the smallest bucket as readily as the largest), and it comes with Blockhash not found or malformed-response parse errors. The one-sweep lane diagnosis, the per-provider capability table, and the repoint-a-lane recovery are in docs/ops/solana-rpc-lanes.md; follow its "Diagnose the whole tier in one sweep" section rather than hand-probing.

6. Prepaid rail (batch settlement and ledger). Applies when buyers report a balance that did not move, a charge for a failed call, or sellers not being paid. Run node scripts/x402-prepaid-reconcile.mjs first (add --chain to compare the deposit wallet's real USDC). Read the PROBLEMS: line: balance_delta/drifted_accounts mean the ledger arithmetic is broken (stop and escalate, do not hand-edit rows); stale_reservations means requests died mid-flight and the settle cron has not swept them (check the x402-prepaid-settle scheduler job ran); stuck_batches or batches in unconfirmed mean a send may have landed, so look the memo (batch ids) up on-chain before anything is released, never re-send; wallet_short_of_held means the deposit wallet holds less USDC than the ledger owes. If settle runs but nothing pays out, X402_PREPAID_SETTLE_LIVE is not 1 or X402_PREPAID_SETTLER_SECRET_BASE58 is unset (the cron then only plans; this is deliberate, enabling it is an owner action), or every seller is under X402_PREPAID_MIN_SETTLE_ATOMICS. A settler below its SOL floor fails with the usual signer-balance error, and that is a funding fix on the settler only. Tables are x402_prepaid_accounts, x402_prepaid_entries, x402_prepaid_batches; design in docs/ops/x402-prepaid.md.