Find Out Why SpeedyCache Is Not Caching a Page with AI

My WordPress site uses SpeedyCache. The page at [page URL] does not seem to be cached. Find out why without changing anything.

1. Run discover_abilities with category speedycache-cache. If speedycache-cache/delete-url is not there, run rest_api GET /wp/v2/plugins with search speedycache. If SpeedyCache is active, tell me its AI abilities are off until I turn on Enable AI Abilities on SpeedyCache's AI Abilities page in wp-admin (the MCP Adapter and Application Password steps on that page are not needed for WPVibe; if it is already on, the site needs SpeedyCache 1.4.3 or newer and WordPress 6.9 or newer), and stop. If it is installed but not active, tell me to activate it and then turn on that switch, and stop. If it is not installed, tell me this recipe is for the free SpeedyCache plugin, and stop. Never run speedycache-cdn/get or speedycache-import/export, and never read the speedycache_cdn or speedycache_object_cache options any other way: they hold my CDN API key and object cache login in full.
2. Run speedycache-settings/get. If cache_enabled is false, that is the cause: tell me to turn on the cache on SpeedyCache's Cache tab, and stop.
3. Run run_wp_cli config get WP_CACHE. If it is not true, that is the cause: WordPress never loads SpeedyCache's serving code, so pages can be stored but are not served (on nginx and most hosts). Tell me turning the cache off and on again on the Cache tab retries adding it to wp-config.php, or my host can add it, and stop. Then read wp-content/advanced-cache.php with read_file (scope wp-content) and check it contains speedycache_ac_serve_cache. If it does not exist or belongs to another plugin or my host, tell me SpeedyCache can store pages but is not the one serving them: another cache plugin or host cache owns that file, and two page caches should not run together. Stop.
4. SpeedyCache keeps each cached page as an index.html file at wp-content/cache/speedycache/HOST/all/PATH/index.html (the home page is all/index.html). First run list_files with scope wp-content and directory cache/speedycache to find the HOST folder, then list HOST/all. Count only index.html files as cached pages (ignore .gz copies; some folders, such as category or date paths, hold no page of their own). If the all folder does not exist, nothing is cached. Check whether this page has a cached copy. If it does, read its last line with read_file (files under 64 KB) for the time it was cached, in my site's timezone.
5. If it is cached, the page is fine and the visitor is the reason. Tell me SpeedyCache does not serve its cached copy to: logged-in users (unless logged_in_user is true), phones and tablets while mobile is true (Mobile Override), anyone with a comment author cookie, or a link with a query string other than the tracking ones it ignores (utm_ tags, fbclid, gclid, msclkid, ref and similar). Tell me to test logged out, in a private window, on a computer, with the plain URL. Stop here.
6. If it is not cached, find the page with rest_api GET /wp/v2/pages with slug SLUG, status any, context edit and fields id,slug,link,password,status (or the same on /wp/v2/posts, or the type's own route) and check, in order: a password (SpeedyCache never caches password-protected pages); a WooCommerce cart, checkout or My Account page (never cached, on purpose); a dot in the path (never cached).
7. Run run_wp_cli option get speedycache_exclude --format=json. Its keys are the rule ids: the delete ability needs these, and they can skip numbers after an earlier delete, so do not use the position from speedycache-excludes/list. Check every page rule against this page: homepage, page (every page), category, tag, archive and attachment match those kinds of page; post_id lists IDs; shortcode matches a page that uses that shortcode; startwith and contain compare the rule text, exactly as typed, with the page path without its outer slashes (so a startwith rule starting with a slash never matches); exact compares it with the whole path, case-sensitive and including any query string. A post rule does nothing. Cookie and user agent rules stop a page being stored when the visitor who loads it has that cookie or browser; a cookie rule with empty text (such as has Woocommerce Items in Cart) matches every visitor with any cookie, so the page is stored only by cookieless visits and the preload. css and js rules do not affect page caching. Name any rule that matches and its id.
8. If nothing above applies, the page may never have been visited since the cache was last cleared. Ask me to open it once in a private window, then list the folder again. If it still has no copy and the all folder holds no pages at all, the likely cause is the site running behind a proxy that does not tell WordPress the visit is HTTPS: SpeedyCache caches nothing then. If other pages are cached, another plugin is probably telling caches to skip this one; name the active plugins that handle forms, carts, memberships or bookings from run_wp_cli plugin list --status=active as the likely ones.
9. Tell me the cause and the one change. If it is an exclude rule I do not want, ask me to confirm that rule by its type, prefix and text. Only on my yes, run speedycache-excludes/delete with rule_id set to its id from step 7, run option get speedycache_exclude again to confirm that rule, and only that rule, is gone, then ask me to visit the page once and check that a cached copy appears.