`side_panel` cannot load or preview local image artifacts

Summary

There is currently no supported way for an agent to display an existing local image artifact in the TUI side panel.

side_panel action="load" rejects PNG and other non-Markdown files. Writing a Markdown page containing a local image reference succeeds, but the TUI renders the image syntax/link as text instead of displaying the image.

This surfaced while recovering a /productivity dashboard that had been generated successfully on disk but was not shown in the transcript.

Environment

• Jcode: v0.78.1 (03ddbcfc8)
• OS: Windows x86_64
• Interface: remote/shared-server TUI
• Artifact: valid 1200×1440 PNG, 385.5 KB

Steps to reproduce

1. Have an existing local PNG, for example:

C:\Users\<user>\.jcode\generated-images\productivity-20260819-165101.png

2. Ask the agent to load it into the side panel:

side_panel action="load"
file_path="C:\Users\<user>\.jcode\generated-images\productivity-20260819-165101.png"

3. Observe the error:

side_panel load only supports markdown files (.md, .markdown, .mdown, .mkd, .mkdn)

4. As a fallback, create a Markdown page containing:

![Productivity report](file:///C:/Users/<user>/.jcode/generated-images/productivity-20260819-165101.png)

5. Observe that the side panel shows the Markdown image notation or link as text rather than rendering the image.

6. Read the same PNG with the read tool. It renders successfully inline in chat, proving the image is valid and the TUI already has a functional image pipeline.

Current implementation

The restriction is explicit rather than accidental:

• crates/jcode-side-panel-types/src/lib.rs defines only one page format:

pub enum SidePanelPageFormat {
    Markdown,
}

• crates/jcode-base/src/side_panel.rs::validate_markdown_source_path rejects every extension except Markdown variants.
• SidePanelPage contains text content but no image payload or artifact reference.

The TUI already supports images through a separate path:

• ServerEvent::GeneratedImage
• ServerEvent::SidePaneImages
• RenderedImage
• inline image rendering and image protocol fallback

Those facilities are not available through the side_panel tool’s page model.

Expected behavior

The agent should have a supported way to preview a local image artifact for the user without requiring an external viewer.

Reasonable product options include:

1. Add an Image side-panel page format.
2. Add a dedicated side_panel action="image" or preview action.
3. Let load recognize common image MIME types and publish them through the existing RenderedImage pipeline.
4. If the product direction is to keep images inline rather than in the side panel, let the tool explicitly attach the image to the transcript instead of failing and forcing the agent to discover the read workaround.

Suggested approach

Reuse the existing image transport and renderer rather than embedding raw image bytes in Markdown page content.

For remote/shared-server sessions, avoid relying on a client-side file:// URI. The server and client may not share the same filesystem namespace. Resolve and validate the file on the tool host, then transfer a bounded image payload or an artifact handle through the existing image protocol.

Suggested constraints:

• supported MIME types: PNG, JPEG, WebP, GIF where renderer support exists
• explicit maximum byte and dimension limits
• no SVG execution without sanitization
• clear missing-file and unsupported-format errors
• image metadata or path shown as a caption
• preserve current Markdown behavior

Regression tests

• Loading a valid PNG creates a visible image preview.
• Remote mode transfers image content rather than assuming the client can read the server path.
• Missing and unsupported files produce actionable errors.
• Oversized images are rejected or resized predictably.
• Markdown pages continue to work unchanged.
• Terminals without a native image protocol receive the existing safe fallback.

Acceptance criteria

• An agent can display a valid local PNG through a documented tool action.
• The image is visible in the TUI without launching an external viewer.
• The behavior works in the normal shared-server TUI.
• The tool response accurately states whether the image was displayed inline or in the side panel.

Classification

This is an enhancement / UX gap, not a regression. The current Markdown-only rejection is consistent with the implemented side-panel contract, but it leaves no direct artifact-preview path through the side-panel tool.

Start by reading crates/jcode-side-panel-types/src/lib.rs and crates/jcode-base/src/side_panel.rs, especially the page format and source-path validation. Then trace ServerEvent::GeneratedImage, ServerEvent::SidePaneImages, and RenderedImage to understand the existing image path. Done means a documented preview action works in shared-server TUI mode, preserves Markdown behavior, handles errors and limits, and has the listed regression tests.