Add the Paratext 9 import WebView experience with a first-open offer

[jasonleenaylor]

The UI half of the PT9 import, stacked on #273 (converter: #272).

• The select modal gains the Import from Paratext 9 button, shown only when
  the source serves convertible data (usePt9ImportAvailability probes the
  manifest through the projectInterface).
• Pt9ImportModal carries the run, its report, and its failures - including
  the too-large refusal, recognized by the RESOURCE_EXHAUSTED platform error
  code with the documented message marker as fallback (pt9-import-error).
• An import opens read-only: editing affordances stay away, the banner
  carries manual sync and copy-to-editable, and CopyToEditableModal clones an
  import into an editable project through the normal draft-open flow.
• First-open offer: opening a source that has convertible PT9 data and no
  stored interlinearizer state asks "This project has Paratext 9 interlinear
  data. Would you like to convert it now?" Yes runs the import as the only
  project created; No (or dismissing) persists the empty draft so the offer
  never repeats. Recorded in user-questions.md for outside review.

---

This change is 

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Team

Run ID: 1812e35d-0292-4ca5-aa8e-e61e7f7478f9

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[imnasnainaec]

❓ report.senses.{entryRefs,senseRefs}{Resolved,Unresolved} is write-only: foldReport doesn't fold it and nothing else reads it. Since no resolver ever runs today, it's 0 resolved / all unresolved on every import. Just checking: is that deliberate (rather than a gap in the fold)?

[jasonleenaylor]

Deliberate. No resolver runs during import yet, so folding the sense counters would show zero resolved and everything unresolved on every run, which reads as a failure for work that is not wired up. The counters are populated and pinned on the converter side so they are ready when a resolver lands. Folding and rendering them belongs with the resolver work tracked in #280, which now lists it as a scope point; ReportTotals carries a TODO pointing there (ccb28ea).

--drafted by Claude--

[alex-rawlings-yyc]

I've pushed a review-fixes branch for this PR: review-fixes/pt9-parsed-webview (branched off pt9-parsed-webview at ef8e70b, #295). Five defects, all with regression tests that fail against the current head.

Read-only enforcement had three holes. The PR guards BoundaryControl and PhraseStripParts, but three parallel mutation routes stayed live in an import view:

1. SegmentListView.tsx:428 — the between-rows merge button. Clicking it dispatches segmentationDispatch.merge, which writes boundaries into the user's editable draft and flips the dirty indicator. Nothing visible happens in the import, because book is computed with resegmentBook(verseBook, undefined) there — so it silently corrupts an unrelated draft.
2. SegmentView.tsx:191 — Alt+click on a baseline-text split gap. Same silent draft write, in continuous-scroll mode. The Alt-gated SplitMarker in PhraseStripParts is covered; this is its baseline-mode twin.
3. ArcOverlay.tsx:291 — the arc split button. analysisMerger.ts:401 does emit phraseAnalysisLinks, so imports draw arcs; hovering one reveals Link2Off and a click deletes a 2-token phrase outright. With PhraseBox's pill and TokenLinkIcon both gated, this was the only surviving route that visibly mutates the import.

For ArcOverlay I used a readOnly prop rather than the hook — it's a presentational leaf whose tests render it bare, so the hook would have forced a provider onto every call site.

The offer mode never reached the modal. InterlinearizerLoader.tsx:1261 collapsed pt9Mode === 'offer' into 'import', which made Pt9ImportModal's entire mode === 'offer' branch dead outside its own unit test. Two consequences, both contradicting the spec added in user-questions.md ("a single Open (dismissing the report also opens…)"): the offer report rendered Close + Open, and dismissing it routed through handlePt9Close → setModal('none'), so a successful conversion was never opened — the user had to go find it in Select. The test "returns to the plain view when an offer-run report is closed" locked that in; I replaced it with two tests asserting the documented behavior.

A failed import-analysis load rendered a blank pane. Once the book has loaded and neither book error applies, all three of loadingOrErrorPanel's conditionals are falsy, so the user got an empty content area plus a toast. Reachable via openImportedProject's :718 fallback. Added an importLoadFailed state, an on-screen message, and a new localized string.

handlePt9Open wrote state after the user backed out. The report stays dismissable during fetchSummary, so Escape → back to Select → resolve closed the Select modal and switched the active project anyway. Added a modalRef in-flight guard.

One reported finding I investigated and rejected, in case it comes up: a claim that a manual sync remounts the store seeded with the pre-sync analysis (initialAnalysis being a non-reactive lazy-ref seed while the key carries updatedAt). I instrumented the actual mount sequence with and without the proposed fix and got identical seeds both ways — React's batching means the remount already happens after the fresh analysis lands. No code change; I kept a test asserting the correct behavior, since nothing covered it before.

Also verified clean, so nobody needs to re-check: savePt9Import's buildNew() spread is field-for-field equivalent to the literal it replaced; the openRequest effect's exhaustive-deps disable has no stale closure; hasDraft/hasNoInterlinearizerState handle ENOENT correctly; and __setMockAnalysisReadOnly's module state is reset in every file that touches it.

Two things left for your judgment. isPt9TooLargeError calls error.message.includes(...) after isPlatformError, whose real guard only checks for platformErrorVersion — a platform error without message would throw out of the catch in runPt9Import. I couldn't verify whether any producer omits it, so I left it as a robustness question rather than guessing. And the on-open auto-sync path had no test at all; I added one covering the sync wording, which is worth a look to confirm that's what you want users to see.

Beyond the fixes: a comment-rules pass (four fixes — two mock docs naming the wrong lifecycle hook, one over-long doc, and one mechanism-explaining inline).

@alex-rawlings-yyc reviewed 48 files and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on jasonleenaylor).

[alex-rawlings-yyc]

@alex-rawlings-yyc reviewed 21 files and all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on jasonleenaylor).

[alex-rawlings-yyc]

@alex-rawlings-yyc reviewed 7 files and all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on jasonleenaylor).

[jasonleenaylor]

All five landed, but through #292 rather than through me, so I checked them against the current head (160aee6) rather than taking either of your words for it.

Read-only holes: the merge control in SegmentListView, the Alt+click split gap in SegmentView, and the arc split button in ArcOverlay are all gated now, and segmentationDispatch is NO_OP_SEGMENTATION_DISPATCH while an import is the view, so the fourth route you'd have hit next is closed too. Offer mode: :1301 passes pt9Mode through instead of collapsing it, so the modal's mode === 'offer' branch is live. Blank pane: :1090, gated !hasError && !showLoading && importLoadFailed, which is tighter than what #292 first had. handlePt9Open: modalRef at :608 and the guard at :770, from 4263d1592.

You spotted the overlap yourself and closed #295 within half an hour of opening it, which saved everyone the reconciliation. Thanks for that.

One difference worth naming rather than letting the merge decide it silently. You used a readOnly prop on ArcOverlay and gave the reason: it's a presentational leaf whose tests render it bare, so the hook forces a provider onto every call site. The merged version uses useAnalysisReadOnly. Your instinct was the better one and the cost showed up where you said it would: the hook needed the manual AnalysisStore mock, which made a third copy of the same twelve lines of type-guard boilerplate, and I raised that as a nit on #292. It's since been pulled into src/__tests__/analysis-store-read-only-mock.ts, so it's fine now, but that shared test module exists because of the hook and wouldn't have been needed with the prop. Not asking for a change; recording it so the next leaf component doesn't repeat the reasoning from scratch.

Your two judgment items and the rejected finding I'll answer separately.