@flusterduck/mcp-server 0.7.0 → 0.7.3

package/dist/{chunk-7KMA7AVO.js → chunk-5X7MKSGI.js}

@@ -465,7 +465,7 @@ Session limits are pooled across all sites in the org, not per-site. All plans i
     "title": "Detectors, signals & friction types",
     "description": "The three words that come up everywhere, explained in plain English: detectors watch, signals report, friction types organize.",
     "group": "Product",
-    "content": "# Detectors, signals, and friction types\n\nThree words come up everywhere in Flusterduck \u2014 detectors, signals, and friction types \u2014 and they're easy to mix up. Here's the difference in plain English, with one example carried all the way through.\n\n## The one-sentence version\n\n**Detectors watch. Signals report. Friction types organize.** Repeated signals then cluster into **issues** \u2014 the ranked list you actually work from.\n\n## Detectors: the watchers\n\nA detector is a small piece of code inside the SDK that watches for one specific pattern of struggle. Nothing more.\n\nThe rage-click detector watches for someone clicking the same spot again and again in frustration. The dead-click detector watches for taps on things that look clickable but aren't. The ghost-toggle detector watches for switches that get clicked but never change. About a hundred of these watchers ship in the SDK, and every one of them runs automatically from the single script tag \u2014 there is nothing to configure, instrument, or turn on.\n\nThink of detectors as a hundred quiet observers, each trained to notice exactly one way a person can get stuck.\n\n## Signals: the reports\n\nA signal is what a detector sends the moment it sees its pattern \u2014 one timestamped observation from one real person's session:\n\n> Rage click on **\"Apply coupon\"** \xB7 `/checkout` \xB7 2:51 PM\n\nThat's a single signal: which pattern fired, on which element (its visible label, PII-redacted in the browser before anything is sent), on which page, at what moment, with a confidence score for how certain the detector is. Signals are the raw sightings \u2014 plentiful, small, and individually not very dramatic. One person rage-clicking once might mean nothing. The value comes from what happens next.\n\n## Friction types: the filing system\n\nA friction type is the named category a signal belongs to \u2014 the label Flusterduck's scoring, dashboard, and AI use to group, weight, and rank what the detectors saw. `rage_click`, `dead_click`, `form_abandonment`, `no_op_interaction` \u2014 there are 115 of them, each with a weight reflecting how strongly it predicts a lost conversion (a dead-end checkout submit weighs far more than a stray scroll bounce).\n\nFriction types are why the dashboard can say something useful instead of showing you a firehose: every sighting is filed, weighted, and comparable.\n\n## Why are there more detectors than friction types?\n\nBecause several watchers can file reports under one category. Different detectors catch mobile taps that miss their target, thumb-zone misses, and near-miss clicks from different angles \u2014 and their reports can land in the same friction type. The detector count grows every time we learn a new way users get stuck (it's an iterative process \u2014 every real-world bug we see becomes a detector); the friction-type list grows more slowly, only when a genuinely new *category* of struggle shows up.\n\n## From signals to issues\n\nSignals don't reach your issue list one at a time. When the same friction type keeps firing on the same page or element across multiple sessions, Flusterduck clusters those signals into a single **issue** \u2014 with a plain-language title, a severity bounded by how many users it actually reached, a confidence grade, a revenue estimate, and (on paid plans) an AI diagnosis grounded in your page's actual content. That ranked issue list is the product; detectors, signals, and friction types are the machinery underneath it.\n\nRead more: [Signals reference](/signals) \xB7 [Issues](/issues) \xB7 [Scoring](/scoring)\n\n## FAQ\n\n**Do I need to configure any of this?** No. All detectors run automatically from one script tag. You can turn individual detectors off in the SDK config if you ever need to, but the default is everything on.\n\n**Does more detectors mean more data sent from my site?** Barely \u2014 signals are tiny structured events (a name, a selector, a redacted label, timestamps), not recordings. There is no session replay and no page content captured from your visitors' sessions.\n\n**Can one user action fire multiple detectors?** Yes, and that's useful: a broken button might draw rage clicks *and* no-op interactions *and* an error signal. Co-occurring signals on the same element are strong evidence they share one root cause, and the clustering treats them that way.\n"
+    "content": "# Detectors, signals, and friction types\n\nThree words come up everywhere in Flusterduck \u2014 detectors, signals, and friction types \u2014 and they're easy to mix up. Here's the difference in plain English, with one example carried all the way through.\n\n## The one-sentence version\n\n**Detectors watch. Signals report. Friction types organize.** Repeated signals then cluster into **issues** \u2014 the ranked list you actually work from.\n\n## Detectors: the watchers\n\nA detector is a small piece of code inside the SDK that watches for one specific pattern of struggle. Nothing more.\n\nThe rage-click detector watches for someone clicking the same spot again and again in frustration. The dead-click detector watches for taps on things that look clickable but aren't. The ghost-toggle detector watches for switches that get clicked but never change. About a hundred of these watchers ship in the SDK, and every one of them runs automatically from the single script tag \u2014 there is nothing to configure, instrument, or turn on.\n\nThink of detectors as a hundred quiet observers, each trained to notice exactly one way a person can get stuck.\n\n## Signals: the reports\n\nA signal is what a detector sends the moment it sees its pattern \u2014 one timestamped observation from one real person's session:\n\n> Rage click on **\"Apply coupon\"** \xB7 `/checkout` \xB7 2:51 PM\n\nThat's a single signal: which pattern fired, on which element (its visible label, PII-redacted in the browser before anything is sent), on which page, at what moment, with a confidence score for how certain the detector is. Signals are the raw sightings \u2014 plentiful, small, and individually not very dramatic. One person rage-clicking once might mean nothing. The value comes from what happens next.\n\n## Friction types: the filing system\n\nA friction type is the named category a signal belongs to \u2014 the label Flusterduck's scoring, dashboard, and AI use to group, weight, and rank what the detectors saw. `rage_click`, `dead_click`, `form_abandonment`, `no_op_interaction` \u2014 there are 116 of them, each with a weight reflecting how strongly it predicts a lost conversion (a dead-end checkout submit weighs far more than a stray scroll bounce).\n\nFriction types are why the dashboard can say something useful instead of showing you a firehose: every sighting is filed, weighted, and comparable.\n\n## Why are there more detectors than friction types?\n\nBecause several watchers can file reports under one category. Different detectors catch mobile taps that miss their target, thumb-zone misses, and near-miss clicks from different angles \u2014 and their reports can land in the same friction type. The detector count grows every time we learn a new way users get stuck (it's an iterative process \u2014 every real-world bug we see becomes a detector); the friction-type list grows more slowly, only when a genuinely new *category* of struggle shows up.\n\n## From signals to issues\n\nSignals don't reach your issue list one at a time. When the same friction type keeps firing on the same page or element across multiple sessions, Flusterduck clusters those signals into a single **issue** \u2014 with a plain-language title, a severity bounded by how many users it actually reached, a confidence grade, a revenue estimate, and (on paid plans) an AI diagnosis grounded in your page's actual content. That ranked issue list is the product; detectors, signals, and friction types are the machinery underneath it.\n\nRead more: [Signals reference](/signals) \xB7 [Issues](/issues) \xB7 [Scoring](/scoring)\n\n## FAQ\n\n**Do I need to configure any of this?** No. All detectors run automatically from one script tag. You can turn individual detectors off in the SDK config if you ever need to, but the default is everything on.\n\n**Does more detectors mean more data sent from my site?** Barely \u2014 signals are tiny structured events (a name, a selector, a redacted label, timestamps), not recordings. There is no session replay and no page content captured from your visitors' sessions.\n\n**Can one user action fire multiple detectors?** Yes, and that's useful: a broken button might draw rage clicks *and* no-op interactions *and* an error signal. Co-occurring signals on the same element are strong evidence they share one root cause, and the clustering treats them that way.\n"
   },
   {
     "slug": "signals",
@@ -745,7 +745,7 @@ A pre-written tooltip tells you what the author thought you'd need to know. Guid
     "title": "Autofix",
     "description": "Generate an AI fix proposal per issue: root cause, the change, an agent prompt. Never edits your repo.",
     "group": "Issues",
-    "content": "# Autofix\n\nAutofix turns an issue's evidence into a concrete fix \u2014 a root cause, the specific change to make, likely places to look, a way to verify it, and a prompt you can paste straight into your coding agent (Claude Code, Cursor). When you connect the Flusterduck GitHub App, Autofix goes further: it researches your repository and opens a **draft pull request** with the change.\n\n## Two modes\n\n**Brief (always available).** Autofix reads the behavioral evidence already on the issue (the same no-PII data used for diagnosis) and proposes a change. You \u2014 or your agent \u2014 ship it. Flusterduck never sees your repository in this mode.\n\n**Draft PR (GitHub App connected).** With the GitHub App installed, Autofix researches the connected repo, reads the files most likely at fault, plans the smallest safe change, and opens a **draft** pull request. It only edits files it read, never creates files, and never merges. If it isn't confident it can fix the issue safely from what it can see, it falls back to the brief rather than pushing a guess.\n\nThe model that plans repo-level fixes is Claude Sonnet.\n\n## Using it\n\nOpen any issue and press **Generate fix** on the Autofix card. You get:\n\n- **Root cause** \u2014 the specific UX/code cause the evidence supports.\n- **The change** \u2014 what to change, specific enough to implement.\n- **Likely places to look** \u2014 best-guess file/component locations (never asserted as fact).\n- **How to verify** \u2014 a manual check or test to confirm the fix worked.\n- **Agent prompt** \u2014 a self-contained instruction to paste into your coding agent.\n- **Draft PR** \u2014 when the GitHub App is connected and the fix is confident, a link to the opened pull request and the files it changed.\n\nRegenerate any time to get a fresh proposal.\n\n## Limits and cost\n\nAutofix is a **count of fixes**, included by plan: Scale (5/mo), Pro (20/mo), Enterprise (unlimited). Grow includes none but can buy packs. The count only decrements on a successful generation, and resets each billing cycle.\n\nNeed more than your monthly allowance? Buy an **autofix pack** from **Settings \u2192 Billing**. Purchased fixes stack on top of your plan quota and don't expire monthly \u2014 they're spent only after the included allowance runs out.\n\nAutofix runs on its own AI budget, separate from issue diagnosis and Guide, so heavy autofix use can never starve diagnosis (and vice versa). You never see a dollar meter \u2014 just the fix count.\n\n## Safety boundary\n\nThe draft-PR boundary is deliberate: a wrong draft PR is a shrug, a wrong auto-merge is an outage. Autofix always opens PRs as drafts and never merges \u2014 you review and ship.\n"
+    "content": "# Autofix\n\nAutofix turns an issue's evidence into a concrete fix \u2014 a root cause, the specific change to make, likely places to look, a way to verify it, and a prompt you can paste straight into your coding agent (Claude Code, Cursor). When you connect the Flusterduck GitHub App, Autofix goes further: it researches your repository and opens a **draft pull request** with the change.\n\n## Two modes\n\n**Brief (always available).** Autofix reads the behavioral evidence already on the issue (the same no-PII data used for diagnosis) and proposes a change. You \u2014 or your agent \u2014 ship it. Flusterduck never sees your repository in this mode.\n\n**Draft PR (GitHub App connected).** With the GitHub App installed, Autofix researches the connected repo, reads the files most likely at fault, plans the smallest safe change, and opens a **draft** pull request. It only edits files it read, never creates files, and never merges. If it isn't confident it can fix the issue safely from what it can see, it falls back to the brief rather than pushing a guess.\n\nThe model that plans repo-level fixes is Claude Sonnet.\n\n## Using it\n\nOpen any issue and press **Generate fix** on the Autofix card. You get:\n\n- **Root cause** \u2014 the specific UX/code cause the evidence supports.\n- **The change** \u2014 what to change, specific enough to implement.\n- **Likely places to look** \u2014 best-guess file/component locations (never asserted as fact).\n- **How to verify** \u2014 a manual check or test to confirm the fix worked.\n- **Agent prompt** \u2014 a self-contained instruction to paste into your coding agent.\n- **Draft PR** \u2014 when the GitHub App is connected and the fix is confident, a link to the opened pull request and the files it changed.\n\nRegenerate any time to get a fresh proposal.\n\n## Limits and cost\n\nAutofix is a **count of fixes**, included by plan: Scale (5/mo), Pro (20/mo), Enterprise (unlimited). Grow includes none. The count only decrements on a successful generation, and resets each billing cycle.\n\nNeed more than your monthly allowance? Autofix scales with your plan, not \xE0 la carte \u2014 **upgrade your plan** for more fixes. There are no add-on packs to buy.\n\nAutofix runs on its own AI budget, separate from issue diagnosis and Guide, so heavy autofix use can never starve diagnosis (and vice versa). You never see a dollar meter \u2014 just the fix count.\n\n## Safety boundary\n\nThe draft-PR boundary is deliberate: a wrong draft PR is a shrug, a wrong auto-merge is an outage. Autofix always opens PRs as drafts and never merges \u2014 you review and ship.\n"
   },
   {
     "slug": "guide-explanations",

package/dist/cli.js

@@ -1,7 +1,7 @@
 #!/usr/bin/env node
 import {
   createFlusterduckMCPServer
-} from "./chunk-7KMA7AVO.js";
+} from "./chunk-5X7MKSGI.js";
 
 // src/cli.ts
 import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

package/dist/index.js

@@ -1,7 +1,7 @@
 import {
   FlusterduckAPI,
   createFlusterduckMCPServer
-} from "./chunk-7KMA7AVO.js";
+} from "./chunk-5X7MKSGI.js";
 export {
   FlusterduckAPI,
   createFlusterduckMCPServer

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flusterduck/mcp-server",
-  "version": "0.7.0",
+  "version": "0.7.3",
   "description": "MCP server for UX friction data. Connect Claude, Cursor, Windsurf, Copilot, Cline to rage click and dead click analytics. Model Context Protocol.",
   "mcpName": "com.flusterduck/mcp-server",
   "license": "SEE LICENSE IN LICENSE.md",
@@ -58,7 +58,7 @@
     "tsup": "8.5.1",
     "typescript": "5.9.3",
     "vitest": "4.1.8",
-    "@flusterduck/tsconfig": "0.7.0"
+    "@flusterduck/tsconfig": "0.7.2"
   },
   "author": "Creayo LLC <admin@creayodev.com>",
   "homepage": "https://docs.flusterduck.com/mcp",