OpenReceive Files

• WooCommerce agent directions: the agent's first message now asks for the receive-only NWC code. When the user asked for stablecoins, the second message is the LSC walkthrough. Setup is not reported complete until both codes are saved, or the user says "Bitcoin only". The user pastes codes into the chat. The agent writes each code to a temporary file with its file-editing tool, feeds it to wp openreceive configure on stdin and deletes the file. The version-pinned wp plugin install …/openreceive-wordpress-0.4.17.zip --activate line now has its own step. A test checks every payload's Step 0.
• Every agent payload opens with a line asking the agent to fetch it raw: a summarizing fetch dropped the WooCommerce install step.
• WordPress: wp openreceive test-invoice <order-id> mints a Lightning invoice for an unpaid OpenReceive order, through the same checkout route as its order-pay page. It prints the amount in sats, the invoice and the order-pay link. wp openreceive doctor no longer prints the Node skills command.
• WordPress: requests reuse the wallet's receive-only preflight answer for ten minutes, as Laravel already does. Before, every REST call and every checkout page render made a relay round trip, which a slow relay turned into multi-second checkouts and occasional 503s. Saving settings and doctor still preflight live. A 503 from the plugin's routes now logs its redacted reason and request id to the WooCommerce openreceive log.
• Refresh vulnerable dependencies in the workspace and demo lockfiles: Vue 3.5.43, sharp 0.35.5, proxy-addr 2.0.8, compression 1.8.2, source-map-js 1.2.2, shell-quote 1.12.0, smol-toml 1.9.0, postcss-selector-parser 7.1.6, Werkzeug 3.1.9 and Mako 1.4.3. These are repository build/test and demo dependency updates; published package dependency constraints are unchanged. The two rubyzip alerts remain blocked by rbsecp256k1's ~> 2.3 constraint.

The matching WordPress/WooCommerce ZIP bundles the 0.4.17 PHP engine and checkout.

Validation: full cross-platform CI, WordPress integration (including test-invoice against the testkit wallet), WordPress browser checkout and swap-refund tests, and Plugin Check. No real invoice or manual payment was requested.