[Feature]: Anchor Roleplay Storyboard images inline to narration blocks

[thetopham]

What problem does this solve?

Roleplay Storyboard can generate several images for different beats inside one assistant message, but the images are not displayed at the precise narration they illustrate.

Game mode already handles long narration by associating Storyboard frames with anchor text and changing the active image as the player moves through the narration. Roleplay has the same underlying need: if one response contains several text blocks or story beats, each generated frame should be visually attached to the matching block.

A contributor prototype placed an image directly inside the message with the img command. That proves the presentation is useful, but encoding the relationship as raw command text is difficult to preserve across retries, swipes, edits, regeneration, export, and loading states.

Proposed solution

Add an optional Inline in message display mode for Roleplay Storyboards.

• Reuse each Storyboard keyframe’s existing anchor text, section range, or narration beat to associate the frame with a precise location in the assistant message.
• Render the generated image inline immediately after the matching Roleplay text block.
• For multiple frames, keep them in Storyboard order and attach each one to its own matching block.
• Keep the existing Storyboard review, retry, gallery, and expanded-view behavior; clicking an inline frame should open the existing viewer/details rather than creating a separate image system.
• Store the association as Storyboard/message metadata for the active message swipe, not as visible /img or Markdown inserted into the authored response.
• Preserve the current non-inline presentation as the default or as another selectable display mode.

Example:

Roleplay text block 1
[Storyboard frame 1]

Roleplay text block 2
[Storyboard frame 2]

Acceptance criteria

• A Roleplay Storyboard frame can render at the text block identified by its anchor/range metadata.
• Two or more frames in one response render once each, in the correct narration order, without replacing or duplicating one another.
• The association is scoped to the correct message and active swipe and survives reload.
• Streaming, pending generation, failure, cancellation, and retry states have a stable inline placeholder and do not shift a frame to the wrong block.
• Editing or regenerating a message either remaps anchors safely or falls back to the existing Storyboard presentation when an anchor is no longer valid.
• Inline frames remain readable and operable on desktop and mobile, including keyboard focus and useful alt text/status labels.
• The existing Game-mode anchored Storyboard behavior is unchanged.
• The assistant response remains clean: no raw image command or hidden prompt syntax is added to the visible message text.

Alternatives considered

• Insert an img command or Markdown directly into the generated response. This gives precise placement, but it mixes presentation metadata into authored text and can become stale after swipes, edits, retries, or imports.
• Show every generated frame only above or below the complete message. This is simpler, but loses the exact relationship between a frame and the narration beat it depicts.
• Reuse the Game-mode click-through presentation unchanged. That works well for long Game narration, but Roleplay messages would benefit from seeing the corresponding image directly beside each text block.

Additional context

This came from a contributor discussion comparing a working inline img-command prototype with Game mode’s anchor-based Storyboard navigation. The useful common abstraction appears to be the existing Storyboard anchor/range metadata: Game can continue using it for click-through image changes, while Roleplay can optionally use it for inline placement.

Template check

• I DID NOT read this template and provide the requested details.