Issues.md

1. fix boot up time ----ok let me be clear ---- initializeStore.ts:62 (index) step delta (ms) elapsed (ms) 0 'initializeStore – begin' 0 0 1 'loadSettings invoked' 1 1 2 'loadPromptTemplates start' 0 1 3 'loadPromptTemplates resolved' 15 15 4 'Using existing prompt templates' 0 16 5 'bootRepairs start' 1 16 6 'ensureModelFieldsRepaired start' 0 16 7 'ensureModelFieldsRepaired done' 0 16 8 'urlMappingsBackfill start' 0 16 9 'loadPromptTemplates resolved' 0 17 10 'Using existing prompt templates' 0 17 11 'bootRepairs start' 0 17 12 'ensureModelFieldsRepaired start' 0 17 13 'ensureModelFieldsRepaired done' 0 17 14 'urlMappingsBackfill start' 0 17 15 'urlMappingsBackfill done' 1 18 16 'normalizeStableIds start' 0 18 17 'urlMappingsBackfill done' 0 18 18 'normalizeStableIds start' 0 18 19 'normalizeStableIds done' 0 18 20 'backfillActiveTranslations start' 0 18 21 'normalizeStableIds done' 0 18 22 'backfillActiveTranslations start' 0 18 23 'backfillActiveTranslations done' 1 20 24 'translationMetadataBackfill start' 0 20 25 'backfillActiveTranslations done' 1 21 26 'translationMetadataBackfill start' 0 21 27 'translationMetadataBackfill done' 0 21 28 'novelIdBackfill start' 0 21 29 'translationMetadataBackfill done' 1 21 30 'novelIdBackfill start' 0 21 31 'novelIdBackfill done' 0 22 32 'chapterNumbersBackfill check' 0 22 33 'novelIdBackfill done' 0 22 34 'chapterNumbersBackfill check' 0 22 35 'chapterNumbersBackfill skipped' 0 22 36 'bootRepairs complete' 0 22 37 'chapterNumbersBackfill skipped' 1 23 38 'bootRepairs complete' 0 23 39 'loadUrlMappings start' 31583 31606 40 'loadUrlMappings skipped (indexes already populated)' 0 31606 41 'persisted reader state hydration skipped (explicit startup intent)' 0 31606 42 'audio initialization start' 0 31606 43 'audio initialization complete' 44 31650 44 'initializeStore complete – isInitialized true' 0 31650 Array(45) initializeStore.ts:70 Total init time: 31650ms TranslationRepository.ts:267 [TranslationRepo] getTranslationVersionsByStableId called {stableId: 'lf-library:forty-millenniums-of-cultivation%3A%3Av1-composite:ch2_swk9uw_d9kt', caller: 'at Object.getVersionsByStableId (http://localhost:…vices/db/repositories/translationFacade.ts:37:34)'} imageSlice.ts:488 [ImageSlice:loadExistingImages] Called for chapter {chapterId: 'lf-library:forty-millenniums-of-cultivation%3A%3Av1-composite:ch2_swk9uw_d9kt', hasChapter: true, hasTranslationResult: true, hasSuggestedIllustrations: tru ---- we need to improve boot time what are our options

Assumptions: this trace is from a dev run under React.StrictMode, launched with a ?novel= deep link, and the novel is being imported from a remote session JSON rather than opened from a fully warm local cache.

Issues

• The 31.6s is not in the repair steps. Those finish in ~23ms. The big gap is the uninstrumented deep-link phase inside store/bootstrap/initializeStore.ts:445, which calls full import via store/bootstrap/initializeStore.ts:237 and services/importService.ts:101.
• Your boot telemetry table is contaminated by concurrent init runs. The app is mounted under index.tsx:14, initializeStore() is called from an effect at MainApp.tsx:153, and the current guard at store/bootstrap/initializeStore.ts:423 only checks isInitialized, not “init already in flight.” The telemetry state is also module-global at store/bootstrap/initializeStore.ts:28, so two runs get merged into one table.
• The later TranslationRepository and ImageSlice logs are downstream of import/render. They are not the primary boot bottleneck in this trace.

Options

1. Instrument the opaque deep-link/import phase Impact: high diagnostic value, low direct speedup. Effort: low. Risk: low. Reversibility: high. Time: 1-2h. Confidence: 0.95.
   Pros: tells you whether the 31s is network download, JSON parse, IndexedDB import, or hydration.
   Cons: doesn’t improve user-visible boot time by itself.
   Tradeoffs: best hypothesis-first move; no product win unless followed by a code change.
   Open questions: how large is the session payload, and is this just a slow network fetch?
   Uncertainties: how much duplicate StrictMode work is mixed into this run.

2. Add an in-flight init guard and isolate telemetry per run Impact: medium in dev, low-medium in prod. Effort: low. Risk: low. Reversibility: high. Time: 1-3h. Confidence: 0.93.
   Pros: stops duplicate bootstrap work, makes telemetry trustworthy, may immediately cut this trace if the remote import is being started twice.
   Cons: does not solve the single-run deep-link import cost.
   Tradeoffs: strong cleanup and likely dev win, but not the main UX fix if production is also slow.
   Open questions: do you care primarily about dev boot or actual user cold-start?
   Uncertainties: whether any other remount path can still re-enter bootstrap.

3. Stop blocking initializeStore on full deep-link import Impact: high. Effort: medium. Risk: medium. Reversibility: medium-high. Time: 0.5-1.5 days. Confidence: 0.88.
   Pros: biggest real boot-time win. You already have a streaming path used by the library at components/NovelLibrary.tsx:173 backed by services/importService.ts:256; deep-link boot currently uses the slower full import path.
   Cons: requires careful handling of reader-loading state, progress UI, and deep-link-to-specific-chapter behavior.
   Tradeoffs: more state-machine complexity, but this is the option that actually attacks the 31s critical path.
   Open questions: is “reader becomes usable after first batch” acceptable for deep links?
   Uncertainties: whether parse/IDB write time dominates even after streaming starts.

4. Move compatibility repairs/backfills off the hot path Impact: low for this trace, medium long-term. Effort: medium. Risk: low-medium. Reversibility: high. Time: 0.5-1 day. Confidence: 0.82.
   Pros: cleaner architecture, less future startup drift, aligns with the repo’s own prior concerns about boot-time repairs.
   Cons: only saves milliseconds here; your trace shows repairs are not the current problem.
   Tradeoffs: architectural hygiene vs immediate latency win.
   Open questions: which repairs are truly one-time migrations?
   Uncertainties: how these ops behave on older/larger real user databases.

Recommendation If the goal is actual boot-time improvement, I would do 2 first and 3 next. 2 is the low-risk fix that makes the measurements real; 3 is the meaningful product win. I would not spend effort on 4 before 3 for this specific trace.

Predicted outcomes:

• After 2, the duplicate rows in boot telemetry should disappear, and dev boot may drop materially if duplicate imports were happening.
• After 3, initializeStore should stop waiting on full remote import, so time-to-interactive should fall sharply even if background import still takes tens of seconds.

Confidence in that recommendation: 0.9.

If you want, I can turn this into a concrete investigation plan with expected measurements before we touch code.

2. check if moving from english to fan back to english RESTARTS the translation costing up more api costs, does it not check if an existing translation is in progress and wait for that to complete or fail? can't I read browse other chapters while this chapter translations? is it not async and parallel

3. meta data of the novel is empty and has chapter 1 as title, is it not loaded? what about glossary terms? from the vault?

4. after I click portal symbol, there is no portal animation, no spinner, no indication that the click registerd, no logs in dev console, so I keep clicking thinking maybe it did not work?

5. same with illustration icon, no indication that image is being generated, I mean from clicking the icon to the point when the image prompt is made, after that there is the spinner and everything is great

6. update the drop down of image models to make sure it is dynamically loaded and updated to actual models that work, set up tests to ensure we check all of them work - same with other text providers have dummy prompts to check if we get responses (since these are paid tests we should gate them and not run them often)

7. scan for inefficinecies like registering providers again and again,

8. scan for wasted logs that are not useful - justify each log

9. do logging between chapter changes and identify all causes of delay and optimize

10. change library word to Home symbol

11. when you do comparision with fan then change chapters the dispay thing follows into the next chapter also! http://localhost:5180/?novel=forty-millenniums-of-cultivation&version=v1-composite&chapter=lexiconforge%3A%2F%2Fforty-millenniums-of-cultivation%2Fchapter%2F305

12. when i move away from the page and get back the background preload ahead chapters are freshly api called rather than showing the calls that were sent in the background... spinner starts from scratch

13. file:///var/folders/68/c0w7ryfj66xdbs8v0yx662h00000gn/T/TemporaryItems/NSIRD_screencaptureui_EXHMpy/Screenshot%202026-04-08%20at%2011.30.08%E2%80%AFPM.png - the eta for how long it will take is generic and should be made model specific, flash models are faster than other models, aggregation ruins the value

14. file:///var/folders/68/c0w7ryfj66xdbs8v0yx662h00000gn/T/TemporaryItems/NSIRD_screencaptureui_E17Pjj/Screenshot%202026-04-08%20at%2011.32.05%E2%80%AFPM.png - if translation fails then the retry red spinner should be clickable it should not just be like this