Spec: lightnovelworld Series identity is read from the chapter page, not derived from it (#77) #80

New Issue

2026-08-11T09:27:48+07:00

sulthan commented

2026-08-11 09:27:48 +07:00

Spec for #77. Design settled in a grilling session on 2026-08-11; the decision is recorded in ADR-0008 and the vocabulary in CONTEXT.md. Evidence: docs/research/lightnovelworld-chapter-vs-series-slug.md.

Problem Statement

A Reader bookmarks a novel on lightnovelworld and it never shows a New Chapter, ever. The
Series sits in the list with a Latest Chapter frozen at whatever it was on the day it was
added. Nothing in the panel says anything is wrong.

For a smaller group of Readers the failure is louder: the same novel appears in the list
twice. One row was created from the novel's own page, the other from a chapter page,
and only one of them ever updates.

Around 7 to 10% of the novels on this Site are affected (3 of 41 sampled). The Site gives
no hint that these novels are different from any other.

Solution

The userscript stops guessing a Series' address and reads it from the page instead.

Every lightnovelworld chapter page carries a pointer back to the Series it belongs to -
an All Chapter anchor, plus a microdata breadcrumb saying the same thing. The userscript
reads that pointer and uses the slug in it as the Series identity. Where the pointer is
absent, the page is not a page the script understands and no Bookmark is offered, rather
than a Bookmark being created under an identity that was invented.

Existing Bookmarks created under the old, invented identity are repaired in place the next
time the Reader opens a chapter page of that novel. The Reader sees nothing: no second
row, no lost Progress, no prompt.

Separately, the Poll's chapter scan on this Site stops being scoped to a slug at all, so it
keeps working for a novel whose chapters are published under more than one Chapter Slug.
Because an unscoped scan would otherwise read the visitor comment thread at the foot of
the page, the scan is cut off before that thread begins.

User Stories

As a Reader, I want a novel I bookmarked from a chapter page to show a New Chapter when the Site publishes one, so that the ember accent means what it says.
As a Reader, I want the novel I bookmarked from a chapter page and the same novel bookmarked from its own page to be one row, so that my list is not silently duplicated.
As a Reader with an existing Bookmark on an affected novel, I want it repaired without being asked, so that I do not have to notice a problem I was never told about.
As a Reader with an existing Bookmark on an affected novel, I want my Progress preserved through that repair, so that the fix does not cost me the thing I was tracking.
As a Reader, I want the repair to also carry my Favourite and Lifecycle bucket across, so that a repaired row is indistinguishable from one that was never broken.
As a Reader whose repair happens while offline, I want the queued change to survive under the repaired identity, so that going offline mid-repair does not lose the write.
As a Reader, I want a Series whose chapters are published under two different Chapter Slugs to report the higher chapter number of the two, so that the Site's own split numbering does not stall my Latest Chapter at 99.
As a Reader, I want the Latest Chapter to be the highest chapter number the Site lists, so that the value follows the rule recorded in CONTEXT.md and in #79.
As a Reader, I want a comment left by another visitor on the Site to be unable to change my Latest Chapter, so that the New Chapter signal cannot be poisoned by a stranger.
As a Reader sharing a Series with other Readers, I want that same guarantee, because the Series row is shared and one poisoned value would reach every one of us.
As a Reader standing on a chapter page whose markup the script does not recognise, I want no Bookmark button at all, so that I am not offered an action that creates a wrong row.
As a Reader, I want a novel with a number in its title to resolve correctly, so that a title such as "…Not Them All Chapter 200" is not mistaken for a chapter link.
As a Reader on an old chapter page whose address still uses a retired Chapter Slug, I want it to resolve to the same Series as a current one, so that a deep link from a bookmark or a search result still works.
As a Reader, I want the userscript panel on a chapter page of a novel I already track to say "Tracked", not "+ Bookmark this", so that I do not create a duplicate by trusting the button.
As a Reader, I want auto-progress on dwell to keep working on an affected novel after the repair, so that reading the next chapter records it as it always did.
As a maintainer, I want the Poll to stop returning 404 for affected Series, so that the VPS log stops filling with a failure that never resolves.
As a maintainer, I want a Series whose truncation marker has vanished to be skipped and logged rather than scanned whole, so that a Site redesign degrades into staleness rather than into a wrong shared value.
As a maintainer, I want that skip to log the body length it saw, so that I can tell a genuine markup change from a body that was cut short by the size cap.
As a maintainer, I want an env-gated live test I can run on demand, so that I can check the Site still has the marker without waiting for a Reader to report staleness.
As a maintainer, I want the test fixtures to be real page text, so that a green suite means the code works against the Site rather than against something we made up.
As a maintainer, I want the affected-novel behaviour pinned by a regression test, so that the next person to touch this Site's adapter cannot silently reintroduce the derivation.
As a maintainer, I want the other five Sites left completely untouched, so that this change cannot regress manga or novelfull.
As a maintainer, I want a Reader who never opens a chapter page of an affected novel to be no worse off than today, so that the change has no downside path.

Implementation Decisions

Identity is discovered, never derived (ADR-0008)

The lightnovelworld adapter's chapter branch no longer builds a Series address by string
manipulation of the chapter path. It reads the page's All Chapter anchor, whose href is
the Series address, and takes the slug from it. The primary selector is the aria-label
attribute on that anchor; it was chosen over three alternatives on measurement (a generic
/novel/ href match hits the header navigation index first, a text match false-matches a
novel whose title ends in "All Chapter 200", and the JSON-LD breadcrumb's second position
is the chapter rather than the Series). The microdata breadcrumb's second crumb is the
fallback. When neither is present the page resolves to type: "other".

Across 8 chapter pages measured - chapter 1, chapter 1200, the newest chapter, both slugs
of the split novel, two divergent novels, and a novel with a number in its title - both
pointers were present and agreed every time.

The Chapter Slug is not stored

A Chapter Slug is the slug a chapter address is built from. It is not an identity, and a
Series may have several: one sampled novel serves chapters 1-99 under one Chapter Slug and
chapters 100-423 under another, both resolving, both pointing back at the same Series.
Storing it beside the identity was considered and rejected for that reason. The page shape
is carried on the detected page object only so the migration below can recognise a stale
row; nothing persists it.

The Poll's scan is unscoped and truncated

The lightnovelworld branch of the backend's chapter scan drops its per-Series slug
scoping and matches any chapter-shaped address on the host. This is what fixes the
split-slug novel, which no stored-slug approach can fix.

An unscoped scan would otherwise read the wpdiscuz comment thread the Site server-renders
below the chapter list, whose bodies are HTML and can carry an anchor. The scan therefore
runs against the body truncated at the first occurrence of the comment-thread marker. The
marker was chosen by measurement: it occurs exactly once per page and follows every chapter
anchor on all four Series pages sampled, whereas the two obvious alternatives occur 111 to
143 times per page including in <head>, before the chapter list.

A container-scoped match was considered and rejected. The research note originally proposed
one container; a later probe showed that container is the hidden, empty "Latest Reading"
template and the real list is classless. The backend scans raw HTML with no parser, so
container extraction means a second regex against class names - more fragile than the
truncation, protecting nothing extra.

Fail closed. Marker absent means skip the Series and log. It does not mean scan the
whole page. The log line carries the body length, because the marker sits at roughly 94% of
these documents (measured: byte 646,329 of 685,023 on one page, 1,117,457 of 1,183,036 on
another) and a body cut short by the size cap is indistinguishable from a markup change
without it. The size cap has about 3.5x headroom on this Site, not the 10x its comment
claims; correct that comment with the measured figure.

Client-side migration, opportunistic

A stored row is recognised as stale with no guessing: the chapter page yields both the
Chapter Slug from its own address and the series slug from its pointer. If those differ and
a row exists under the Chapter Slug identity, that row is the stale one.

The rewrite covers four storage sites, all of which must move together: the cached row's
key, identity and address; the retry-queue entry, if one exists under the old key; and the
per-device last-checked map. Then it syncs. Note the queue may hold an entry under the old
key whose replay still succeeds against the old server row, so the rewrite must cover the
queue rather than letting the two keys coexist.

A server-side migration was considered and rejected as impossible: the database holds no
source for the correct slug, and no endpoint on the Site maps one slug to the other.

The repaired row leaves its old shared Series row behind. Nothing deletes it, but the
Poll's due-query is an inner join against Bookmarks, so a Series with no Bookmarks is never
polled again - the orphan is permanently stored and permanently inert. A Reader who never
opens a chapter page of an affected novel does not heal, and continues exactly as today.

Vocabulary

CONTEXT.md already carries the settled terms: Series is identified by the canonical
slug the Site publishes, never by title and never by a Chapter Slug; Chapter Slug is a
new term, defined as plural by nature and always discovered; Latest Chapter is the
highest-numbered chapter, not a date and not the Site's own banner.

Testing Decisions

A good test here asserts a value a Reader or the Poll can observe - a resolved identity, a
chapter number, a rewritten row - and would fail if the logic broke. It does not assert
which selector was tried first, that a particular regex was compiled, or that a helper was
called. Three of the four seams already exist and must be reused; only one is new.

Seam 1 - the backend's chapter scan. Table-driven cases against fixture bodies, the
existing prior art in sites_test.go. Cases: a real Series page body with a real comment
block after the marker, containing a link to a high-numbered chapter of another novel,
asserting the comment cannot win; the split-slug novel, asserting the maximum spans both
Chapter Slugs; a body with no marker, asserting skip rather than whole-page scan.

The current fixture must change. It contains an invented anchor annotated "the last anchor
is another series", and the live survey found no Series page that carries a foreign chapter
anchor - the fixture encodes a page shape the Site does not produce, so its test passes
because of a fiction. Remove it and use real page text. It also uses a novel that is a poor
choice for two independent reasons: its Chapter Slug and series slug coincide, which is why
the defect slipped through in the first place, and its chapter numbering is the anomaly in
#79.

Seam 2 - the userscript's page detection. The existing pure-logic harness in
novel-logic.test.js, which requires the userscript under a four-object browser stub. The
stub's document.querySelector currently answers meta[property=...] and plain element
selectors returning text only; it needs to answer an attribute selector with an element
exposing getAttribute. Extend the stub rather than working around it, per the
testing-the-userscript skill. Cases: pointer present, identity comes from the pointer and
not the address; pointer absent, breadcrumb present, same result; both absent, type: "other"; a divergent novel, asserting the two slugs are different and the right one wins.

Seam 3 - the row migration. The only new seam. It is written as a pure transform:
cached list, queue and last-checked map in, the same three rewritten out, no storage access
inside. This keeps it inside the existing harness with no new stubbing, and it is the shape
worth testing precisely because the bug hides in one of the four sites being missed. Cases:
all four sites rewritten together; no stale row, nothing changes; queue entry absent, the
other three still move; the row's Progress, Favourite and Lifecycle bucket survive.

Seam 4 - the live canary. TestSmokeLnwCommentBoundary, an env-gated live test
asserting the marker still occurs exactly once and still follows the last chapter anchor.
Prior art and convention: TestSmokeKaganeImage in smoke_image_test.go, which skips when
its environment variable is unset. Not part of go test ./....

Not testable here and verified on-device instead, per the skill: the panel's button state,
the toast, and anything reachable only through init.

Out of Scope

A repair program for rows that never heal. A Reader who never opens a chapter page of an affected novel keeps a Bookmark that keeps 404ing. That is the status quo for that row, not a regression. Enumerating those rows needs production data nobody has yet.
Deleting the orphaned Series rows. They are inert; a few hundred bytes each, never polled, never displayed.
The a-will-eternal numbering anomaly. Filed as #79 and closed by decision: Latest Chapter follows the largest number. Do not add a widget or date cross-check while working here.
The other five Sites. asura, demonic, comix, kagane and novelfull keep their current scoping unchanged. The measurements behind this spec are lightnovelworld's alone.
The cover-refresh gap. Separate defect, #78.
Any change to the Poll's cadence, batching or cooldown.

Further Notes

Commands, from the testing-the-userscript skill and AGENTS.md:

node --check userscript/novel-bookmark.user.js
node --test userscript/test/novel-logic.test.js
cd backend && go test ./...            # needs Docker

Use the test file path, not the directory form - the directory form fails MODULE_NOT_FOUND
on this machine's Node.

Two facts worth carrying into the work because they cost time to establish. First, these
Series pages are large - up to about 1.18 MB - and sit mostly below the fold of any
truncating fetch, so a probe that reads the first few hundred KB will report the comment
marker as absent when it is present. Two separate investigations reached opposite
conclusions on exactly this before it was resolved by a complete fetch. Second, the old
domain lightnovelworld.com is shut down and serves a short notice page; only the .net
domain is live.

Spec for #77. Design settled in a grilling session on 2026-08-11; the decision is recorded in ADR-0008 and the vocabulary in `CONTEXT.md`. Evidence: `docs/research/lightnovelworld-chapter-vs-series-slug.md`. ## Problem Statement A Reader bookmarks a novel on lightnovelworld and it never shows a New Chapter, ever. The Series sits in the list with a Latest Chapter frozen at whatever it was on the day it was added. Nothing in the panel says anything is wrong. For a smaller group of Readers the failure is louder: the same novel appears in the list **twice**. One row was created from the novel's own page, the other from a chapter page, and only one of them ever updates. Around 7 to 10% of the novels on this Site are affected (3 of 41 sampled). The Site gives no hint that these novels are different from any other. ## Solution The userscript stops guessing a Series' address and reads it from the page instead. Every lightnovelworld chapter page carries a pointer back to the Series it belongs to - an `All Chapter` anchor, plus a microdata breadcrumb saying the same thing. The userscript reads that pointer and uses the slug in it as the Series identity. Where the pointer is absent, the page is not a page the script understands and no Bookmark is offered, rather than a Bookmark being created under an identity that was invented. Existing Bookmarks created under the old, invented identity are repaired in place the next time the Reader opens a chapter page of that novel. The Reader sees nothing: no second row, no lost Progress, no prompt. Separately, the Poll's chapter scan on this Site stops being scoped to a slug at all, so it keeps working for a novel whose chapters are published under more than one Chapter Slug. Because an unscoped scan would otherwise read the visitor comment thread at the foot of the page, the scan is cut off before that thread begins. ## User Stories 1. As a Reader, I want a novel I bookmarked from a chapter page to show a New Chapter when the Site publishes one, so that the ember accent means what it says. 2. As a Reader, I want the novel I bookmarked from a chapter page and the same novel bookmarked from its own page to be one row, so that my list is not silently duplicated. 3. As a Reader with an existing Bookmark on an affected novel, I want it repaired without being asked, so that I do not have to notice a problem I was never told about. 4. As a Reader with an existing Bookmark on an affected novel, I want my Progress preserved through that repair, so that the fix does not cost me the thing I was tracking. 5. As a Reader, I want the repair to also carry my Favourite and Lifecycle bucket across, so that a repaired row is indistinguishable from one that was never broken. 6. As a Reader whose repair happens while offline, I want the queued change to survive under the repaired identity, so that going offline mid-repair does not lose the write. 7. As a Reader, I want a Series whose chapters are published under two different Chapter Slugs to report the higher chapter number of the two, so that the Site's own split numbering does not stall my Latest Chapter at 99. 8. As a Reader, I want the Latest Chapter to be the highest chapter number the Site lists, so that the value follows the rule recorded in `CONTEXT.md` and in #79. 9. As a Reader, I want a comment left by another visitor on the Site to be unable to change my Latest Chapter, so that the New Chapter signal cannot be poisoned by a stranger. 10. As a Reader sharing a Series with other Readers, I want that same guarantee, because the Series row is shared and one poisoned value would reach every one of us. 11. As a Reader standing on a chapter page whose markup the script does not recognise, I want no Bookmark button at all, so that I am not offered an action that creates a wrong row. 12. As a Reader, I want a novel with a number in its title to resolve correctly, so that a title such as "…Not Them All Chapter 200" is not mistaken for a chapter link. 13. As a Reader on an old chapter page whose address still uses a retired Chapter Slug, I want it to resolve to the same Series as a current one, so that a deep link from a bookmark or a search result still works. 14. As a Reader, I want the userscript panel on a chapter page of a novel I already track to say "Tracked", not "+ Bookmark this", so that I do not create a duplicate by trusting the button. 15. As a Reader, I want auto-progress on dwell to keep working on an affected novel after the repair, so that reading the next chapter records it as it always did. 16. As a maintainer, I want the Poll to stop returning 404 for affected Series, so that the VPS log stops filling with a failure that never resolves. 17. As a maintainer, I want a Series whose truncation marker has vanished to be skipped and logged rather than scanned whole, so that a Site redesign degrades into staleness rather than into a wrong shared value. 18. As a maintainer, I want that skip to log the body length it saw, so that I can tell a genuine markup change from a body that was cut short by the size cap. 19. As a maintainer, I want an env-gated live test I can run on demand, so that I can check the Site still has the marker without waiting for a Reader to report staleness. 20. As a maintainer, I want the test fixtures to be real page text, so that a green suite means the code works against the Site rather than against something we made up. 21. As a maintainer, I want the affected-novel behaviour pinned by a regression test, so that the next person to touch this Site's adapter cannot silently reintroduce the derivation. 22. As a maintainer, I want the other five Sites left completely untouched, so that this change cannot regress manga or novelfull. 23. As a maintainer, I want a Reader who never opens a chapter page of an affected novel to be no worse off than today, so that the change has no downside path. ## Implementation Decisions ### Identity is discovered, never derived (ADR-0008) The `lightnovelworld` adapter's chapter branch no longer builds a Series address by string manipulation of the chapter path. It reads the page's `All Chapter` anchor, whose `href` is the Series address, and takes the slug from it. The primary selector is the `aria-label` attribute on that anchor; it was chosen over three alternatives on measurement (a generic `/novel/` href match hits the header navigation index first, a text match false-matches a novel whose title ends in "All Chapter 200", and the JSON-LD breadcrumb's second position is the chapter rather than the Series). The microdata breadcrumb's second crumb is the fallback. When neither is present the page resolves to `type: "other"`. Across 8 chapter pages measured - chapter 1, chapter 1200, the newest chapter, both slugs of the split novel, two divergent novels, and a novel with a number in its title - both pointers were present and agreed every time. ### The Chapter Slug is not stored A Chapter Slug is the slug a chapter address is built from. It is not an identity, and a Series may have several: one sampled novel serves chapters 1-99 under one Chapter Slug and chapters 100-423 under another, both resolving, both pointing back at the same Series. Storing it beside the identity was considered and rejected for that reason. The page shape is carried on the detected page object only so the migration below can recognise a stale row; nothing persists it. ### The Poll's scan is unscoped and truncated The `lightnovelworld` branch of the backend's chapter scan drops its per-Series slug scoping and matches any chapter-shaped address on the host. This is what fixes the split-slug novel, which no stored-slug approach can fix. An unscoped scan would otherwise read the wpdiscuz comment thread the Site server-renders below the chapter list, whose bodies are HTML and can carry an anchor. The scan therefore runs against the body truncated at the first occurrence of the comment-thread marker. The marker was chosen by measurement: it occurs exactly once per page and follows every chapter anchor on all four Series pages sampled, whereas the two obvious alternatives occur 111 to 143 times per page including in `<head>`, before the chapter list. A container-scoped match was considered and rejected. The research note originally proposed one container; a later probe showed that container is the hidden, empty "Latest Reading" template and the real list is classless. The backend scans raw HTML with no parser, so container extraction means a second regex against class names - more fragile than the truncation, protecting nothing extra. **Fail closed.** Marker absent means skip the Series and log. It does not mean scan the whole page. The log line carries the body length, because the marker sits at roughly 94% of these documents (measured: byte 646,329 of 685,023 on one page, 1,117,457 of 1,183,036 on another) and a body cut short by the size cap is indistinguishable from a markup change without it. The size cap has about 3.5x headroom on this Site, not the 10x its comment claims; correct that comment with the measured figure. ### Client-side migration, opportunistic A stored row is recognised as stale with no guessing: the chapter page yields both the Chapter Slug from its own address and the series slug from its pointer. If those differ and a row exists under the Chapter Slug identity, that row is the stale one. The rewrite covers four storage sites, all of which must move together: the cached row's key, identity and address; the retry-queue entry, if one exists under the old key; and the per-device last-checked map. Then it syncs. Note the queue may hold an entry under the old key whose replay still succeeds against the old server row, so the rewrite must cover the queue rather than letting the two keys coexist. A server-side migration was considered and rejected as impossible: the database holds no source for the correct slug, and no endpoint on the Site maps one slug to the other. The repaired row leaves its old shared Series row behind. Nothing deletes it, but the Poll's due-query is an inner join against Bookmarks, so a Series with no Bookmarks is never polled again - the orphan is permanently stored and permanently inert. A Reader who never opens a chapter page of an affected novel does not heal, and continues exactly as today. ### Vocabulary `CONTEXT.md` already carries the settled terms: **Series** is identified by the canonical slug the Site publishes, never by title and never by a Chapter Slug; **Chapter Slug** is a new term, defined as plural by nature and always discovered; **Latest Chapter** is the highest-numbered chapter, not a date and not the Site's own banner. ## Testing Decisions A good test here asserts a value a Reader or the Poll can observe - a resolved identity, a chapter number, a rewritten row - and would fail if the logic broke. It does not assert which selector was tried first, that a particular regex was compiled, or that a helper was called. Three of the four seams already exist and must be reused; only one is new. **Seam 1 - the backend's chapter scan.** Table-driven cases against fixture bodies, the existing prior art in `sites_test.go`. Cases: a real Series page body with a real comment block after the marker, containing a link to a high-numbered chapter of another novel, asserting the comment cannot win; the split-slug novel, asserting the maximum spans both Chapter Slugs; a body with no marker, asserting skip rather than whole-page scan. The current fixture must change. It contains an invented anchor annotated "the last anchor is another series", and the live survey found no Series page that carries a foreign chapter anchor - the fixture encodes a page shape the Site does not produce, so its test passes because of a fiction. Remove it and use real page text. It also uses a novel that is a poor choice for two independent reasons: its Chapter Slug and series slug coincide, which is why the defect slipped through in the first place, and its chapter numbering is the anomaly in #79. **Seam 2 - the userscript's page detection.** The existing pure-logic harness in `novel-logic.test.js`, which requires the userscript under a four-object browser stub. The stub's `document.querySelector` currently answers `meta[property=...]` and plain element selectors returning text only; it needs to answer an attribute selector with an element exposing `getAttribute`. Extend the stub rather than working around it, per the `testing-the-userscript` skill. Cases: pointer present, identity comes from the pointer and not the address; pointer absent, breadcrumb present, same result; both absent, `type: "other"`; a divergent novel, asserting the two slugs are different and the right one wins. **Seam 3 - the row migration.** The only new seam. It is written as a pure transform: cached list, queue and last-checked map in, the same three rewritten out, no storage access inside. This keeps it inside the existing harness with no new stubbing, and it is the shape worth testing precisely because the bug hides in one of the four sites being missed. Cases: all four sites rewritten together; no stale row, nothing changes; queue entry absent, the other three still move; the row's Progress, Favourite and Lifecycle bucket survive. **Seam 4 - the live canary.** `TestSmokeLnwCommentBoundary`, an env-gated live test asserting the marker still occurs exactly once and still follows the last chapter anchor. Prior art and convention: `TestSmokeKaganeImage` in `smoke_image_test.go`, which skips when its environment variable is unset. Not part of `go test ./...`. Not testable here and verified on-device instead, per the skill: the panel's button state, the toast, and anything reachable only through init. ## Out of Scope - **A repair program for rows that never heal.** A Reader who never opens a chapter page of an affected novel keeps a Bookmark that keeps 404ing. That is the status quo for that row, not a regression. Enumerating those rows needs production data nobody has yet. - **Deleting the orphaned Series rows.** They are inert; a few hundred bytes each, never polled, never displayed. - **The `a-will-eternal` numbering anomaly.** Filed as #79 and closed by decision: Latest Chapter follows the largest number. Do not add a widget or date cross-check while working here. - **The other five Sites.** asura, demonic, comix, kagane and novelfull keep their current scoping unchanged. The measurements behind this spec are lightnovelworld's alone. - **The cover-refresh gap.** Separate defect, #78. - **Any change to the Poll's cadence, batching or cooldown.** ## Further Notes Commands, from the `testing-the-userscript` skill and `AGENTS.md`: ``` node --check userscript/novel-bookmark.user.js node --test userscript/test/novel-logic.test.js cd backend && go test ./... # needs Docker ``` Use the test file path, not the directory form - the directory form fails MODULE_NOT_FOUND on this machine's Node. Two facts worth carrying into the work because they cost time to establish. First, these Series pages are large - up to about 1.18 MB - and sit mostly below the fold of any truncating fetch, so a probe that reads the first few hundred KB will report the comment marker as absent when it is present. Two separate investigations reached opposite conclusions on exactly this before it was resolved by a complete fetch. Second, the old domain `lightnovelworld.com` is shut down and serves a short notice page; only the `.net` domain is live.

sulthan added the ready-for-agent label 2026-08-11 09:27:48 +07:00

sulthan referenced this issue

2026-08-11 09:27:59 +07:00

lightnovelworld: chapter slug != series slug, so poller 404s on renamed novels #77

sulthan referenced this issue from a commit

2026-08-11 09:32:45 +07:00

Record the lightnovelworld series-identity decision (#77)

sulthan referenced this issue

2026-08-11 09:33:04 +07:00

Record the lightnovelworld series-identity decision (#77) #81

sulthan referenced this issue from a commit

2026-08-11 09:34:29 +07:00