[RibatTRW]

What Changed

• HexNovels now returns site-relative paths with a leading slash (e.g. /content/slug) from the novel list parser. It also defines resolveUrl, so the app's web view builds a full URL instead of dropping the /.
• A new normalizePath helper accepts both the new slash form and the legacy paths saved by 1.0.0. parseNovel and parseChapter use it, so existing library entries keep loading.
• Bumped the plugin version from 1.0.0 to 1.0.1.

🤖 Generated with Claude Code

Risk Assessment

✅ Low: The change is a small, well-bounded fix. Paths now carry a leading slash, a normalizePath helper accepts legacy slash-less saved paths, and the version is bumped to 1.0.1. I traced new, legacy and absolute-URL inputs through resolveUrl, parseNovel and parseChapter and found no wrong result. I did not run the live check.

Testing

I bundled the real plugin and ran it against live hexnovels.me. resolveUrl returns https://hexnovels.me/content/<slug> for both '/content/…' and legacy 'content/…' paths, so the missing-slash URL from the issue is gone. popularNovels returned 40 novels with leading-slash paths. parseNovel loaded 440 chapters from both path forms and normalised the novel path to '/content/…'. Real chapters parse from both new and legacy paths: a text chapter returned 10045 chars. The checker's parseChapter FAIL is not caused by the fix: chapter 1 of the first novel is illustration-only, and the plugin deliberately returns a 74-char notice for those. I did not drive the Android app or WebView itself, only the plugin functions that produce the URLs. I removed my temporary files.

• Live validation: ✅ go - 4 of 4 scenarios driven live against the product

Scenario	Result	Live	Evidence
WebView URL for a novel has the slash between .me and content	✅ pass	live	resolveUrl('/content/a-kusuriya-no-hitorigoto-ln-2011') returned https://hexnovels.me/content/a-kusuriya-no-hitorigoto-ln-2011
Opening a novel from popular or search lists shows its chapters	✅ pass	live	popularNovels returned 40 novels; parseNovel on the first returned 440 chapters; the live checker's searchNovels returned 2 results
Legacy saved path without a leading slash (library entry from 1.0.0) still opens	✅ pass	live	parseNovel('content/a-kusuriya-no-hitorigoto-ln-2011') returned path '/content/…' and 440 chapters; resolveUrl of the legacy path matched the correct URL
Reading a chapter works with new and legacy chapter paths	✅ pass	live	Chapter 6 parsed to 10045 chars of text. The illustration-only chapter 1 returned the 74-char notice from both the new and the legacy path form.

• Outcome: ⚠️ 1 info across 1 run (51.4s)

Pipeline

Updates from git push no-mistakes

✅ **Intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

✅ **Review** - passed

✅ No issues found.

⚠️ **Test** - 1 info

• ℹ️ The live checker's parseChapter step FAILs (74 chars, below its 200-char minimum) because it picks chapter 1 of the first novel, which is illustration-only. That chapter returns a fixed notice by design, and the fix does not cause it. Chapter 6 parsed fine with 10045 chars.
• Live validation: ✅ go - 4 of 4 scenarios driven live against the product

Scenario	Result	Live	Evidence
WebView URL for a novel has the slash between .me and content	✅ pass	live	resolveUrl('/content/a-kusuriya-no-hitorigoto-ln-2011') returned https://hexnovels.me/content/a-kusuriya-no-hitorigoto-ln-2011
Opening a novel from popular or search lists shows its chapters	✅ pass	live	popularNovels returned 40 novels; parseNovel on the first returned 440 chapters; the live checker's searchNovels returned 2 results
Legacy saved path without a leading slash (library entry from 1.0.0) still opens	✅ pass	live	parseNovel('content/a-kusuriya-no-hitorigoto-ln-2011') returned path '/content/…' and 440 chapters; resolveUrl of the legacy path matched the correct URL
Reading a chapter works with new and legacy chapter paths	✅ pass	live	Chapter 6 parsed to 10045 chars of text. The illustration-only chapter 1 returned the 74-char notice from both the new and the legacy path form.

• npm ci
• npm run check:plugin -- plugins/russian/hexnovels.ts: popularNovels, searchNovels and parseNovel PASS; parseChapter FAIL on an illustration-only chapter 1 (74 chars)
• Throwaway esbuild-bundled driver run against hexnovels.me: resolveUrl, popularNovels paths, parseNovel with new and legacy paths, parseChapter on new and legacy chapter paths

✅ **Document** - passed

✅ No issues found.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.

[greptile-apps]

Confidence Score: 5/5

[Low impact] The PR appears safe to merge, with no actionable issues found.

Summary

HexNovels now keeps the leading slash in novel and chapter paths.

• HexNovels paths keep their leading slash and resolve to the right pages.

No actionable issues were found. The review checked the code; it did not repeat the reported live tests.

_{Reviews (1) · Last reviewed commit: "fix(russian/hexnovels): use leading-slas..." · Reviewed by Greptile}