Update user questions document

Author: alex-rawlings-yyc

user-questions.md

@@ -90,7 +90,7 @@ Decisions made during development that we'd like reviewed:
 ## User-defined segment boundaries
 
 Segments were previously fixed to verses (rebuilt from USJ on every load). Users can now define
-their own segment boundaries: a **Edit segment boundaries** view toggle exposes per-slot **merge**
+their own segment boundaries: an **Edit segment boundaries** view toggle exposes per-slot **merge**
 (combine a segment into the one before it) and **split** (start a new segment at a token) controls,
 and linking a phrase across a verse boundary pulls the adjacent segment's **edge** token into the
 focused segment (only the immediate adjacent-edge link buttons are active for this). Boundaries are
@@ -104,11 +104,16 @@ Decisions made during development that we'd like reviewed:
    scriptio continua (Chinese, Thai, …) and for cases where the USFM implied a different break.
    Should the separator be configurable per project/writing system, or derived from the source?
 
-2. **Split-segment baseline display.** A segment created by splitting a verse currently keeps the
-   **whole verse's** baseline text (token offsets unchanged; the invariant holds trivially). In the
-   baseline-text display mode this duplicates the verse text under each half. The alternative is to
-   trim each half's baseline to just its tokens' span (cleaner, but drops edge whitespace and
-   punctuation). Current choice: keep the full-verse baseline for simplicity and safety.
+2. **Split-segment baseline display.** A segment created by splitting a verse currently keeps only
+   the baseline text spanning **its own tokens** — `buildSegment` slices the verse baseline from the
+   first token's `charStart` to the last token's `charEnd` and shifts each token's offsets into the
+   new string, so the `baselineText.slice(charStart, charEnd) === surfaceText` invariant still holds.
+   The trade-off is that any whitespace or punctuation sitting between the split boundary and the
+   adjacent token's edge is dropped from both halves (e.g. the space at position 5 between "Alpha"
+   and "beta" in "Alpha beta." belongs to neither half). The alternative — keeping the whole verse's
+   baseline text under each half — avoids dropping edge characters but duplicates the verse text in
+   the baseline-text display mode. Current choice: trim each half to its own span, accepting the
+   dropped edge whitespace.
 
 3. **Free translation when merging.** A segment's free translation is keyed by segment id. An
    untouched or merged segment keeps the **leading** verse's id (so its free translation survives);
@@ -124,3 +129,23 @@ Decisions made during development that we'd like reviewed:
 5. **Boundary editing is a transient mode.** The **Edit segment boundaries** toggle is local UI
    state (off on reload), not a persisted project setting, since it changes what the link slots do
    rather than a display preference. Confirm this is the right treatment.
+
+6. **Chapter superscriptions are a hard wall (interim).** A chapter heading (a `d` descriptive
+   title, e.g. a Psalm superscription) is extracted as a synthetic **verse 0** segment that sits in
+   document order between the previous chapter's last verse and the new chapter's verse 1. As an
+   interim fix, verse 0 is treated as a **hard wall**: no merge, split, move, or cross-segment link
+   may touch either of its boundaries, so its tokens always stay together and no neighboring token
+   is ever pulled into or across it. The cost is a lost capability — you **cannot currently draw a
+   segment boundary that spans a superscription** (e.g. group the end of one chapter with the start
+   of the next when a heading sits between them). The stated goal is for verse 0 to be _invisible_ to
+   boundary redrawing (a redraw acts on the real verses on either side as if the superscription
+   weren't there, while the heading stays its own intact segment), but that conflicts with the
+   contiguous-run segment model and needs a design decision before implementation. Options and the
+   recommendation are worked out in
+   [design-verse-0-agnostic-segmentation.md](design-verse-0-agnostic-segmentation.md). Two questions
+   for stakeholders:
+   - Is the hard wall acceptable as the shipped behavior for now, or is spanning-a-superscription a
+     blocker that must be resolved before release?
+   - When a segment _does_ eventually absorb tokens across a superscription, **where should the
+     heading render and how should its free translation be handled?** (This parallels item 3 above —
+     "Free translation when merging.")