feat(ci): add live-verification check for plugin PRs (#2386)

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

docs/quickstart.md

@@ -3,19 +3,21 @@
 1. [Requirements](#requirements)
 2. [Single plugin guide](#quick-guide)
 3. [Multi-src guide](#creating-multi-src-plugins)
+4. [Testing your plugin](./testing.md)
 
 ### Requirements
 
--   [git](https://git-scm.com/doc/ext) basics
--   Typescript or Javascript basics
--   Node >=22
--   Installing the dependencies with `npm i`
+- [git](https://git-scm.com/doc/ext) basics
+- Typescript or Javascript basics
+- Node >=22
+- Installing the dependencies with `npm i`
 
 ### Guide
 
 1. Create plugin script in `/plugins` [<span style="font-size: 0.8rem;">(learn more)</span>](#creating-plugin-script)
 2. Copy code from [plugin-template.ts](./plugin-template.ts)
 3. Start coding [<span style="font-size:0.8rem">(documentation)</span>](./docs.md)
+4. Run `npm run check:plugin -- plugins/<lang>/yourPlugin.ts` before opening a PR — see [Testing your plugin](./testing.md)
 
 #### Creating plugin script
 

docs/testing.md

@@ -0,0 +1,44 @@
+# Testing your plugin
+
+`tsc`, ESLint, and Prettier all check that your plugin _compiles_. None of them can tell you
+whether it actually returns novels, chapters, or search results from the real site — plugins fail
+in ways the compiler can't see, because the wiki/site content they scrape has no schema: an empty
+chapter list, a chapter body that's actually a "back to top" nav page, search results leaking
+pages in the wrong language, and so on.
+
+## `npm run check:plugin`
+
+Bundles your plugin with esbuild the same way the production build does, then runs it against the
+live site — calling `popularNovels`, `searchNovels`, `parseNovel`, and `parseChapter` in sequence,
+using your plugin's own default filter values (the same values the app would send).
+
+```sh
+npm run check:plugin -- plugins/english/yourPlugin.ts
+```
+
+You can check multiple plugins in one run:
+
+```sh
+npm run check:plugin -- plugins/english/yourPlugin.ts plugins/english/anotherPlugin.ts
+```
+
+Each step reports one of three outcomes:
+
+- **PASS** — got a plausible result (non-empty novel list, a chapter body over ~200 characters,
+  etc).
+- **FAIL** — the plugin ran but returned something wrong (empty results, a novel with no chapters,
+  a suspiciously short chapter body, or a thrown error that isn't network-related). This is what
+  you're looking for before opening a PR.
+- **INCONCLUSIVE** — the site itself was unreachable, timed out, or returned a Cloudflare-style
+  block during this run. Not a plugin bug; re-run later or check the site manually.
+
+## CI
+
+Any PR that touches a file under `plugins/**/*.ts` (excluding multisrc-generated files) runs this
+same check automatically against just the changed plugins, and posts a summary comment. The check
+only fails the PR on a genuine `FAIL` — `INCONCLUSIVE` results (a site being briefly down) never
+block a merge.
+
+You can also trigger it manually against any plugin path from the Actions tab
+(`Plugin Live Check` → `Run workflow`), which is useful for re-checking an existing plugin after
+its target site changes layout.