From capture to diagnosis: the full sequence #
A Loupely diagnosis isn’t a summary of your error log. It’s the output of a multi-step pipeline that runs in a few seconds between when you click Run Diagnosis and when the result appears in the popup. Understanding what happens in those seconds helps you interpret the result and know what to do when something unexpected comes back.
Step 1: Local capture #
The Chrome extension captures browser-side data from the active tab: JavaScript errors, network requests, DOM state, console output. Simultaneously, it requests server-side data from the WordPress Plugin via the authenticated REST API Endpoint: PHP Errors, Hook Execution, WooCommerce pipeline events, plugin list, server configuration.
Before anything leaves your browser, the extension runs the credential scanner locally. API keys, authentication tokens, and other sensitive values are detected and removed from the payload. The scanner runs in the extension’s content script, which means the original credentials never leave your device. Only the sanitized payload proceeds to the next step.
Step 2: Transmission #
The sanitized capture payload is transmitted over HTTPS to Loupely’s Edge Function infrastructure. The payload is not stored permanently. It’s processed in memory and discarded after the diagnosis is generated. What gets stored is the session metadata: the failure class, the triage route, the platform and plugin context. Not the full capture contents.
Step 3: Correlation #
The Edge Function runs the correlation rules against the combined browser and server signals. These rules look for known patterns that connect browser-side symptoms to server-side causes. Each matching rule produces a signal classification and a confidence score. Multiple rules can fire on the same capture; the highest-confidence match determines the failure class. See Cross-Signal Correlation: What It Is and Why It Matters for a detailed explanation of this step.
Step 4: AI diagnosis generation #
The classified failure, along with the relevant signals that triggered it, is passed to Claude (Anthropic’s AI model) with a structured prompt. The prompt instructs the model to produce a plain-language explanation of what broke, where it came from, and what to do about it, scoped specifically to the failure class and the evidence available. The model doesn’t see your full capture file. It sees the structured classification output and the specific signals that support it.
This is why the diagnosis is specific rather than generic. The AI isn’t summarizing your error log. It’s explaining a classified failure pattern in terms a non-technical site owner can act on.
Step 5: Triage determination #
The triage route is determined by the failure class, not by the AI. The correlation rules that classify the failure also specify the appropriate next step: rollback to a previous state, contact the hosting provider, deactivate a specific plugin, clear cache, or hand off to a developer. The AI explains the triage in context. The routing logic determines which triage path applies.
Step 6: Result delivery #
The diagnosis text and triage step are returned to the extension popup. 1 credit is deducted from your balance at this point. The capture file (containing the full sanitized payload) becomes available for download. The session metadata is recorded.
The entire pipeline from click to result typically takes 3 to 8 seconds depending on server response time and network conditions.
What this means for the quality of the diagnosis #
The diagnosis is only as good as the evidence captured. If the failure didn’t produce signals during the capture window (because it’s intermittent, or because you didn’t reproduce it before clicking diagnose, or because it lives in a layer Loupely doesn’t instrument), the correlation rules won’t find a pattern. The result will be a Null Result or a low-confidence classification. Reproducing the failure deliberately before clicking Run Diagnosis gives Loupely the best chance of capturing the evidence it needs.