Review WooCommerce code for HPOS, checkout, and money bugs

This skill reviews generated or changed WooCommerce code before it ships, applying rules as a guard pass after the first implementation pass. WooCommerce is a moving platform - order storage changed engines (to HPOS) and checkout changed frameworks (to Blocks/Store API) - so code written from memory tends to target the WooCommerce of three years ago, and with money on the line, "works on my demo store" isn't a real standard. The rules target systematic AI-agent failures: reading order meta through get_post_meta() (broken on HPOS stores), updating products via direct meta writes that skip lookup tables and hooks, validating checkout only in JavaScript, computing prices as floats, and registering woocommerce_* hooks before confirming WooCommerce is even active.

It runs in three modes: guard-pass (recommended, applying the rules to a diff or target files after code is written), live mode (applying the same rules while writing, when invoked beforehand), and review mode (walking a structured checklist to produce a findings report without editing unless asked) - running wp-guard alongside when installed, for the full WordPress layer. A security floor holds at maximum severity in all WooCommerce code regardless of mode: escape all output with the context-correct esc_* function, unslash then sanitize all request data before it touches logic, require a capability check plus nonce on every state change, and use $wpdb->prepare() for every query containing a variable. Before applying rules it determines the order storage mode in play (HPOS, legacy posts, or both - defaulting to both), which checkout is active (Blocks/Store API, legacy shortcode, or both, since hooks for one don't fire in the other), and whether WooCommerce activity is properly guarded with a class_exists('WooCommerce') check.

Eight rules split by severity. Must-fix order/product rules: orders must go through the CRUD API (wc_get_order(), $order->get_meta()/update_meta_data()+save()) rather than get_post_meta() or WP_Query on shop_order, which silently break on HPOS; products, customers, and coupons go through their own CRUD objects and save() rather than direct meta writes that skip lookup-table sync and hooks; and any extension touching orders or checkout must explicitly declare HPOS/checkout-blocks compatibility or show every store owner a warning banner. Must-fix checkout/money rules: checkout validation must be enforced server-side (at woocommerce_checkout_process or via Store API schemas), since JavaScript validation is UX, never security; and prices must go through wc_format_decimal()/wc_price()/WooCommerce's own rounding settings, never float arithmetic or number_format(). Should-fix runtime rules: WC()->cart/WC()->session are null outside normal requests and must be guarded in REST/cron/CLI/admin contexts; existing hooks are preferred over template overrides, which freeze a copied file at one WooCommerce version; and background work at scale must go through Action Scheduler with idempotent handlers, since order events can fire more than once.

A self-check runs before delivery, grepping the diff for forbidden order-meta calls, checking every write goes through a CRUD object's save(), confirming HPOS/checkout-blocks compatibility declarations, verifying server-side checkout enforcement, catching float arithmetic on money, and confirming the security floor (escaping, sanitizing, capability/nonce checks, prepared queries) is fully met.

Use it reactively after an agent writes or modifies WooCommerce hooks, HPOS logic, or checkout flows - extensions, payment/shipping integrations, checkout customizations, order/product logic. It explicitly does not cover the full WordPress layer beyond its own security floor (that's wp-guard's jurisdiction when installed), doesn't review store configuration, theme styling, or payment provider account setup, and doesn't decide pricing or business logic - it guards how WooCommerce code ships, not what the store sells.

Input is generated or changed WooCommerce code (a diff or target files) plus the project's declared WooCommerce version range and order-storage/checkout configuration. Output is either corrected code (guard-pass/live mode) or a structured findings report grouped by file and rule (review mode).

It runs alongside wp-guard for the full WordPress layer and pulls from four companion reference files covering HPOS/CRUD patterns, checkout/money handling, the review checklist, and citable WooCommerce developer docs.

Developers shipping WooCommerce extensions, integrations, or checkout customizations who need HPOS-safe data access, server-side checkout validation, and correct money handling verified before code reaches a real store.