feat(webapp): the wiki lane: findable suggestions, one review flow, robust pages, search (phase 6 of v4.3.0) #527
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/phase6-wiki"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #375, closes #385, closes #395, closes #396. Phase 6 of the v4.3.0 build order (#514). Frontend only, four commits, no backend change, no migration.
#375 suggestion discovery. The
SessionDetaillink named in the issue had already been fixed by #417 (shipped as "#375, partial" in v4.2.3); it now has the regression test it never got. The wiki home's only route to the review queue lived in its phone-hidden rail; it now also sits beside "New article" in the main column, with the pending count.CampaignDetail's 105-line inline copy of the queue is gone (it omitted relationship suggestions, clamped every body, and vanished when the count was zero); in its place one always-visible row, "N suggested wiki updates" / "No pending suggestions" / "Couldn't load suggested wiki updates.", with Review going toWikiProposalsas the single page. Both fetch sites stopped swallowing errors, and both counts now include relationship proposals.#385 one review flow. The copy was rewritten from what the backend actually does:
approve_draftwritescurrent_body; a generated backstory reproduces the body plus a new section (an append in effect); stat blocks never touch the body; merge is an LLM merge, never a verbatim append. So "Approve" and "Review merge…" are separate buttons naming the destination before the click; draft kinds come from one map keyed onmodewith the pre-#130 fallback, so a generated backstory stops calling itself an LLM rephrase and each kind's approve button names its own effect; the start-draft modal promises what the review page performs. All four queue actions disable while one is in flight, report failure on their row, and the product's last fouralert()calls are gone; a direct approve leaves a receipt with a View article link.#395 robust pages. The draft poll reports non-404 failures inline, keeps trying, gives up after 3 minutes (between the banner's "usually under 30 seconds" and the backend's 15-minute stale threshold) and offers Check again. Version-history, restore and load-more failures are inline beside the failing control instead of replacing the article or storyline. "Full regenerate" confirms, matching its siblings. One gap left deliberately: the generating banner is inside the non-
convert_statslayout branch, so a stuck stat-conversion draft cannot reach Check again; that is #416's surface.#396 search and pagination. The backend already has
?search=on the list endpoint (title, body, aliases, visible fields, tested), so the search is a pure frontend addition: a debouncedWikiSearchbox, one per page, in the wiki home's main column and the article page's rail.WikiArticle's rail moves onto the paginated fetch the wiki home uses, with "Load more (X of Y)", which also widens the entry set behind wiki links and the relationship picker past the old 200 cap.vitest 616 passed (53 files, +45 on this lane), eslint clean apart from the pre-existing
CampaignDetailwarning,vite buildgreen. Rebased over phases 4 and 5 with one test-file conflict resolved by keeping both sets.🤖 Generated with Claude Code
Three routes lead to the suggestions the backend drafts from a session summary, and each one was broken in a different way. On the wiki's front page the only entry point lived inside the category rail, which is `hidden md:flex` — there was no route to the queue at all from a phone. It now sits beside "New article" in the main column, badge and all, which every breakpoint renders. The campaign page carried a second, ~110-line inline copy of the queue. It rendered only entry proposals, so suggested relationships were invisible from here; it truncated bodies to three lines, so approving from this page meant approving text you had not read; and it was gated on `count > 0`, so it vanished at precisely the moment a GM looking for "where did my suggestions go" needed an answer. Deleted in favour of one always-visible summary row that links to WikiProposals — the single page that shows the whole queue, relationships included. Both `fetchLoreProposals` call sites were `.catch(() => {})`, which renders a failed read and an empty queue identically. They now say "Couldn't load suggested wiki updates." The counts on both pages include relationship proposals, since that is what "suggested wiki updates" means in vocabulary.js. `fetchRelationshipProposals` gains an `options` argument so the campaign page can abort it with the rest of its loads. The SessionDetail link this issue also named was already fixed in #417 (it shipped as "#375, partial"); a regression test pins the destination. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>