Upcoming post
Extension-first cover recovery is the next priority
LoreKeep needs a stronger no-AI-cost cover recovery pipeline for entries saved from reading pages, especially when the extension can only capture fallback artwork.
Post links
Keep browsing
Move between upcoming work, shipped updates, and the editor from the same reading surface.
What is coming
A concise summary of the work planned for this upcoming item.
- Extend the browser extension Quick Save payload with canonical URLs, source domains, meta images, JSON-LD images, headings, descriptions, breadcrumbs, chapter signals, and poster-like image candidates.
- Add backend cover verification so missing, broken, tiny, banner-like, logo-like, or known fallback images create a cover recovery job instead of becoming permanent bad covers.
- Create CoverRecoveryJob and CoverCandidate storage for recovery status, candidate image URLs, source URLs, confidence, dimensions, hashes, accepted/rejected state, and retry history.
- Build source-specific recovery adapters that turn chapter URLs into likely series pages and extract cover candidates from high-value reading sites first.
- Score cover candidates using title similarity, source-domain match, synopsis overlap, poster aspect ratio, image health, catalog reuse, accepted-user history, and fallback-image penalties.
- Auto-apply only high-confidence covers, show medium-confidence suggestions for user review, and keep low-confidence results as pending without replacing the fallback.
- Feed accepted and rejected choices back into source/domain scoring so the system improves without paid AI calls or model training as the first dependency.
Why it matters
How this planned work should improve the experience once it ships.
- Entries saved from the extension should stop feeling broken when the original page does not expose a clean cover image.
- Good covers can be recovered automatically or suggested without charging for external AI usage on every failed save.
- Users keep control when confidence is uncertain through review, reject, retry, and manual cover URL actions.
- The shared catalog becomes cleaner because accepted cover matches can be reused while weak or unverified candidates stay out of discovery.
- The system becomes more reliable over time as source adapters, cached matches, and user feedback improve candidate scoring.
More detail
Additional roadmap context, scope notes, or rollout expectations for this upcoming post.
Most entries start in the browser extension, so cover recovery needs to begin there too. The planned system will collect richer page evidence during Quick Save, verify covers on the backend, create recovery jobs when a cover is missing or looks like fallback art, and use source-page recovery, provider APIs, catalog reuse, candidate scoring, and user feedback before falling back to manual review. The goal is not to pay for AI on every broken cover. The goal is to build a practical discovery engine that gets better from accepted matches, source adapters, and cached catalog knowledge.
Post status
Current state
A quick snapshot of how this upcoming post is categorized and published.
Category
Extension
Status
Live
Published
2026-05-17 14:30 UTC