Recovery Probe

io.github.BojanKovachki由 GitHub 帳號 BojanKovachki 發布v1.0.2更新於 Oct 29, 2026

Fail reads in web and Electron test apps, inspect recovery, and compare before/after evidence.

概覽

AI 產生的概覽

本機 MCP 伺服器,讓編碼代理對 Web 與 Electron 應用注入故障、觀察介面復原情況並比對證據。

可以做什麼
  • 讓畫面背後的網路讀取失敗,並判斷資料是否復原
  • 觀察畫面是否出現過期內容或卡在舊狀態的資料列
  • 查看儲存或傳送失敗時使用者看到什麼,並讓 SDK 自身的 HTTPS 連線失敗
  • 找出把失敗讀取變成「沒有資料」的程式碼
  • 透過比對、監看與驗證執行來證明修正有效
  • 產生 HTML 與 JSON 報告,比對故障執行與健康基準
適用情境
適合在代理準備聲稱程式碼已處理錯誤時,先讓它真的製造一次讀取失敗並查看畫面。也適合需要排查無聲空狀態與復原路徑問題的 Web 或 Electron 應用測試。
執行需求
透過 npx 以 stdio 在本機執行,需要 Node.js 22 或更新版本;瀏覽器檢查還需安裝 Playwright 與 Chromium。目標 Web 應用需已啟動,Electron 應用需開啟本機遠端偵錯埠;IPC 檢查需在主程序載入僅供開發用的鉤子。未宣告帳號、API 金鑰或環境變數。
安裝前請注意
報告與 MCP 結果可能包含端點路徑、選擇器、標記文字、選用截圖,以及最多 200 字元的新出現畫面文字,這些內容未經去識別化,可能含個人資料,分享或交給代理前請先檢查。只測試你有權測試的應用與帳號,並讓偵錯埠僅監聽本機。只有選用的修復流程會呼叫 AI 服務。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 Recovery Probe,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。

其他 MCP 客戶端

參照 儲存庫 中的啟動說明。

README

Recovery Probe

Stop assuming your code works. Test what actually happens.

Recovery Probe helps developers and AI coding agents discover bugs that ordinary tests can miss. It deliberately triggers failures in web and Electron applications, observes how the UI responds, and produces evidence you can use to reproduce, fix, and verify problems.

A failed request should not silently turn a populated screen into “No items found.” Recovery Probe helps you reproduce that failure and check whether the application recovers as expected.

[CI] [npm] [License: MIT]

[Recovery Probe catches a broken retry flow and passes the fixed one]

Try it

You need Node.js 22 or newer.

bash
npm install --save-dev recovery-probe playwrightnpx playwright install chromiumnpx recovery-probe demo

The demo runs two versions of a small app. Both load fine. Only the fixed one survives a 503, a dropped connection and a broken JSON response.

Check your own app

Web app. Start it, then run:

bash
npx recovery-probe init http://localhost:3000

A browser opens. Sign in, go to the screen you care about, and click something that only shows up once its data has loaded. Recovery Probe finds the request behind it, fails it three ways, and tells you whether the data came back.

Electron app. Start it with --remote-debugging-address=127.0.0.1 --remote-debugging-port=9222, then run npx recovery-probe init.

Electron app that loads data over IPC. Load the small development-only hook in the main process. npx recovery-probe doctor prints the code and the path to load it from. Restart the app with the inspector on, then run npx recovery-probe init: it lists the hook's channels, asks which one loads the screen, and fails it in a few ways.

Each run saves an HTML and JSON report. Run the same command again to repeat the check, or add --fresh to set it up again. If something's missing, npx recovery-probe doctor says what and how to fix it.

More

ToRunDocs
Fail the read behind a screen without writing assertionsdiscoverDiscovery
Catch stale screens and rows stuck in an old state, without faultsobserveObserve
See what users get when Save or Send failsactionAction check
Fail an SDK's or a main process's own HTTPS connectionsnetNetwork faults
Find code that turns a failed read into "no data"suspectsSuspects
Prove a change fixed itcompare, watch, verifyCompare, Watch, Verify

Use it from a coding agent

recovery-probe mcp is an MCP server. Any agent that supports MCP can use it to fail a read and look at the screen before it claims the code handles errors. Most agents take this config:

json
{  "mcpServers": {    "recovery-probe": { "command": "npx", "args": ["recovery-probe", "mcp"] }  }}

Other config formats and the list of tools are in MCP.

Use it in your tests

withFault fails matching requests inside a Playwright test:

js
import { test, expect } from '@playwright/test'import { withFault } from 'recovery-probe'
test('profile recovers after a 503', async ({ page }) => {  const stats = await withFault(    page,    { match: '**/api/profile', kind: 'http-error', status: 503 },    async () => {      await page.goto('http://127.0.0.1:3000/profile')      await page.getByRole('button', { name: 'Retry' }).click()      await expect(page.getByTestId('profile-name')).toHaveText('Test User')    },  )  expect(stats.applied).toBe(1)})

If nothing matches, withFault throws FAULT_NOT_TRIGGERED instead of passing. For code that takes a fetch function there's createFaultFetch. See API.

How it decides

  • Every faulted run has a healthy run right before it, on the same screen, and the report compares the two.
  • A result is a pass, a failure or inconclusive. A fault that never fired, an unstable baseline or a path it can't reach is inconclusive, never a pass.
  • Some findings, like SILENT_EMPTY, are leads. They tell you where to look, not that the code is wrong.
  • Exit codes: 0 passed, 1 a check failed, 2 needs review or inconclusive, 3 wrong usage or config, 4 couldn't run.

Where it works

  • Web apps in Chromium, either launched by Recovery Probe or attached through a local debugging port.
  • Electron apps, over HTTP in the renderer or over IPC with the hook.
  • Native HTTPS clients that use HTTPS_PROXY, such as an SDK in the main process. Only whole connections can fail there.
  • Android WebViews, experimental.

It doesn't simulate a whole device going offline, WebSocket drops, token expiry, sleep or slow networks.

Privacy

Reports stay on your machine and there's no telemetry. Request and response bodies aren't recorded, and discovery and observation keep screen text only as hashes. Reports can still contain endpoint paths, selectors, text you picked as a marker and, with --screenshots, what was on screen, so check them before you share them. Nothing calls an AI service except the opt-in repair workflow.

Failed recovery checks can also save screenText: up to 200 characters of newly visible screen text, included in terminal output, reports, fix briefs and MCP results. These quotes are not redacted and can contain personal or sensitive data even without screenshots. Review these outputs before sharing them or passing them to an agent.

Only test apps and accounts you're allowed to, and keep debugging ports on localhost.

Compatibility in 1.x

The compatibility commitment covers documented, non-experimental package exports, CLI commands and options, exit codes, configuration fields, MCP tools and JSON report fields. Removing or renaming these interfaces, changing their types incompatibly, or changing their documented meaning requires a major version. Backward-compatible additions can ship in minor releases; fixes that restore documented behavior can ship in patch releases.

Consumers should tolerate additional JSON fields. Exact terminal wording, HTML layout, timing measurements and heuristic findings are not fixed contracts. Internal files under dist/ are not public imports; use the package's declared exports. Features explicitly labeled experimental, including Android WebView support and repair, may change in minor releases, with changes recorded in the changelog.

Upgrading to 1.0

1.0 removes the old command spellings desktop, web, ipc, --demo and --config. Each now stops with a usage error that names the commands that replaced it, such as windows, reads, check, discover, action and demo. Usage errors exit with 3 and setup failures with 4, where the old spellings exited with 2, so update CI scripts that read exit codes. demo and the JSON runner's check write report.json into the --out folder. Restart the development app after upgrading so its IPC hook matches the CLI. Public package imports and the hook's path are unchanged. See the changelog.

Docs

Guided start · Desktop and browsers · IPC · Discovery · Observe · Refresh · Network faults · Android · Suspects · Compare · Watch · Verify · MCP · API · JSON runner · CI · Repair · Changelog

Contributing

See CONTRIBUTING.md. Report security issues as described in SECURITY.md.

License

MIT © 2026 Bojan Kovachki

來源:README.md,提交 deed614

工具

0
SourceWeft 尚未在沙箱中啟動過該軟體包,因此其工具未知。

版本歷史

1
  1. v1.0.2最新Oct 29, 2026

評分

已滿足適用檢查項的 50%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通25 分

    請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。

  • 已宣告認證方式10 分

    請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。

  • 已列出工具15 分

    請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。

  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分