# Woo Revenue Incident Graph

> Diagnoses why a WooCommerce store's checkout revenue path broke, by joining that store's own privacy-safe
> aggregate signals with public release and issue evidence on one timeline. Answers three questions: is something
> wrong right now, what most likely broke it, and did the fix hold. Free beta — every tool, every call.

This is a diagnostic, not a store-management tool. It is read-only: it cannot change an order, a refund, a payment or
a plugin. It never receives a customer, order or payment identifier, because the store's collector does not send one.

## MCP

Endpoint: https://revenue-graph.utilityhouse.xyz/mcp — JSON-RPC 2.0 (initialize, tools/list, tools/call, ping). Directory-specific routes serving
the same free tools: https://revenue-graph.utilityhouse.xyz/mcp/registry, /mcp/smithery, /mcp/glama, /mcp/cursor, /mcp/claude, /mcp/openai.

The store an answer is about comes from the request's credential (Authorization: Bearer <store_id>.<secret>), never
from a tool argument — no tool takes a store id.

Tools (four, all free, all read-only — none of them writes anything):
- `get_checkout_health_snapshot` — is anything wrong with this store's checkout and payment path right now, and is
  a diagnosis worth running? Order counts by status with the change across the window, gateway/webhook/error/
  scheduler health, data freshness, and whether coverage is sufficient to diagnose from.
- `diagnose_revenue_incident` — up to three ranked hypotheses, each with the store observations behind it,
  independent public sources where they exist, counterevidence, remaining unknowns, safe next steps and a
  verification plan. Abstains with a stated reason when the snapshot is stale, coverage is thin, or the signals
  support no cause.
- `check_checkout_change_risk` — is a component and version known to have broken checkout elsewhere? Says
  "unknown" when nothing independent is on record, rather than treating absence of reports as a safety record.
- `verify_revenue_recovery` — did the fix hold? Compares the window before a stated change against the window
  since. Returns "unknown" rather than "resolved" when too little new data has arrived; a quiet ten minutes is not a
  recovery.

## Sending store signals

POST https://revenue-graph.utilityhouse.xyz/v1/snapshot with an HMAC-signed envelope {storeId, timestamp, nonce, signature, body}; the signature
covers storeId.timestamp.nonce.body. The WordPress plugin in packages/wp-diagnostic-plugin/ does this every fifteen
minutes once an administrator connects the store.

## Payments

Off. Free beta, every tool, every call, on every route. Enabling payments requires two independent flags, not one.
Accuracy is not yet measured against real incidents, and charging for an unmeasured diagnostic would be selling an
unchecked claim — see /pricing and EVAL-REPORT.md, where every accuracy target is recorded as UNMEASURED.

## Privacy

A connected store sends counts, health states and closed-taxonomy labels: orders by status per hour, status
transition counts (timings only where enough orders exist that none can be singled out), order-note reason codes
from a fixed list of nine, gateway availability, webhook success/failure counts, scheduler backlog, whether the
checkout page is published and contains a checkout, and recent plugin/theme/core changes.

Error fingerprints are NOT collected. Normalising arbitrary text from third-party plugin logs cannot be proven safe,
so the family is empty by design and every answer says so rather than letting an empty list read as health.

Never collected: customer name, email, phone, address or IP; order numbers, contents or history; card or payment
method details; payment intent, charge, customer, session or transaction identifiers; API keys, cookies, nonces or
authorization headers; webhook URLs, secrets or bodies; log files or database dumps; wp-config values, absolute paths
or table prefixes. A snapshot carrying any of these is refused whole rather than cleaned and stored. See /privacy and
PRIVACY-DATA-FLOW.md.