v1.9.3

v1.9.3 — 首图比同排高 20px

症状

1.9.1 修完「四列 + 文字乱入」后，十张图横向成行了，但第一行第 1 张卡顶边 y=26，第 2、3 张 y=46 —— 首图独自高出 20px。

根因

瓦片成行靠「零高 <p> + float 跨父级连成一条 float 流」。但 <p> 仍拥有行盒：只要段落里残留任何行内幸存者（零尺寸 span、空灯箱槽、Fragment 留下的兄弟节点），该段就不再零高，它的行盒会把之后整条 float 流往下推。

修复

• 新增 CSS .dsh-ig-tileline：只归零承载瓦片的那个段落的盒模型与字体度量，让它彻底不拥有行盒
• tickThumb() 在拿到 dsh-ig-tilewrap 的同一分支里调 markTileLine(host)；untickThumb() 调 unmarkTileLine(host)
• 三重门禁防回归：tileLineOwner 必须是段落且拒绝 body/documentElement；tileLineIsDirect 要求恰好 1 个瓦片子元素；tileLineIsSafe 有散文即拒绝

回归

新增 test/probe-tileline.mjs（23 项）；node test/run-all.mjs → 12/12 全绿。

生效条件

替换已安装包的 JS 必须完全退出 DSH 进程再启动（Ctrl+R 不重载 client bundle）。

v1.9.2

v1.9.2 — 正文里一张图都没有

症状

模型调 display_image 一切正常（十张图全部正确返回 markdown），但回复正文里一张图都没有。

根因

不是插件不稳定，是规则放的位置不对。铁律是常驻 system prompt section，离「刚拿到返回值」那一刻太远；工具结果被界面折叠成一行「已调用工具」，用户滚动正文时什么都看不到，而模型的注意力在工具返回那一刻最集中。

修复

lib/index.js 的 render() 从「只返回 value.markdown」改为在返回值最上方加一条投递 banner，明确要求模型把 markdown 原样复述进正文。

生效条件

替换已安装包的 JS 必须完全退出 DSH 进程再启动。

v1.9.1

v1.9.1 — 混合图文容器被判九宫格

症状

混合图文容器（图片与文字混排）被误判为九宫格，自动排成 4 列且文字乱入。

根因

列数判定只看容器内图片数量，没有排除「容器里同时有散文」的情况，于是文字块被当成瓦片参与排布。

修复

• 列数判定增加散文检测：容器内只要存在非图片的文字节点，就不按九宫格处理
• 文字块恢复为正常段落流，不再参与瓦片 float 流

生效条件

替换已安装包的 JS 必须完全退出 DSH 进程再启动。

v1.9.0

Full Changelog: v1.8.9...v1.9.0

v1.8.9

v1.8.9：与 npm 同版本发布（GitHub 源码 + npm 包 + 本 Release 三处对齐）。

v1.7.9

历史版本补建 Release（tag 复用仓库既有 tag）；该版本已发布至 npm。

v1.7.8 — root-relative image URLs (desktop fix) + resident image-delivery law

1.7.7 — desktop images did not render at all

Symptom: in the DSH desktop app a display_image picture collapsed into a Tool call · display_image row instead of the image, while the very same file loaded fine through a root-relative /images/?abs=... URL.

Root cause: the desktop shell serves the conversation from the custom protocol dsh-app://app/ (location.origin === "dsh-app://app", location.port === ""). The host half emitted absolute http://127.0.0.1:<port>/images/... URLs, i.e. a cross-ORIGIN request from a non-HTTP origin, which Chromium refuses in the renderer — no request ever reached the webServer (host logs showed zero /images hits).

Measured with an in-page probe, same file and same query:

form	result
/images/?abs=... (root-relative)	fetch 200 image/webp, img.onload 200x355
http://127.0.0.1:<port>/images/?abs=... (absolute)	fetch TypeError: Failed to fetch, img.onerror

Fix: emit root-relative URLs everywhere the browser consumes them. baseUrl() returns ""; igImageUrls() accepts both https?:// and / prefixes (backwards compatible); igDiag() posts to a relative path.

Note: Chrome additionally blocks the loopback hop from a custom-scheme origin as an insecure private-network request, so "just pass the port" cannot be repaired — only a same-origin relative path works.

1.7.8 — enforce delivery in the conversation body

Even with rendering fixed, a display_image picture only lived inside the tool call row, which is collapsed by default. Scrolling the transcript a user sees no image and reasonably concludes nothing was sent.

The host half now registers a resident system-prompt section (image-gallery:delivery-law, order 1500, 503 chars) requiring the model to:

1. put every delivered image in the reply body as ![](…);
2. paste them one by one when sending several (no "see above" / "sent N images");
3. never pass off a file path or a bare link as a delivered image;
4. paste the tool's markdown verbatim.

A prompt section is used rather than a skill because skills load on demand while a section is resident — installing the plugin is enough.

• inject: ["webServer","tools"] → ["webServer","tools","systemPrompt"]
• apply(ctx) → apply(ctx, config); opt out with config.injectImageLaw: false
• registration goes through ctx.effect() so it is disposed with the plugin; a missing systemPrompt service degrades to logger.warn instead of throwing

Verification

• mock ctx run registers the section (order 1500, 503 chars) alongside the 5 routes and the display_image tool
• after restart the log shows image-gallery: image delivery law registered (order 1500, 503 chars)
• three images render in the reply body, including a 5464x7650 file whose name contains spaces, parentheses, @ and an emoji

Upgrade

dsh plugin --profile desktop add dsh-chat-image-lightbox@1.7.8

Restart DSH afterwards — the host half only takes effect on restart.

v1.7.5 - fix: image sending broken by sharp version conflict

⚠️ If sending images in DSH failed for you, this is the fix. / 如果你在 DSH 里发图片失败过，这个版本就是修复。

症状 · Symptom

发图片时报错（纯文字对话不受影响）：

prompt rejected: Could not load the "sharp" module using the win32-x64 runtime
ERR_DLOPEN_FAILED: The specified procedure could not be found.
(session/agent-busy)

Sending an image fails with the above; plain-text chat was never affected.

根因 · Root cause

DSH 内核自带 sharp ^0.35.3（自首个版本起），而 1.7.4 及更早把本插件的 sharp 精确锁定在 0.34.4，于是同一个进程里出现了两个不同版本的 sharp。

两者加载的 DLL 同名（都叫 libvips-42.dll），但各自需要不同的配套文件：

sharp	需要
0.34.x	libvips-42.dll + libvips-cpp-8.17.2.dll
0.35.x	libvips-42.dll + libvips-cpp-8.18.3.dll

Windows 按文件名解析 DLL —— 谁先加载谁占住这个名字，后来者报 the specified procedure could not be found。

The kernel ships sharp ^0.35.3; this plugin pinned 0.34.4, so two sharp builds landed in one process. Both load a DLL named libvips-42.dll but need different companions, and Windows resolves DLLs by filename — the first one to load wins, and the other fails.

报错末尾的 agent-busy（会话忙）是 DSH 对无法分类的错误套用的通用标签，与实际是否繁忙无关 —— 这也是真因难以一眼看出的原因。
The trailing agent-busy is a generic wrapper for unclassified errors, unrelated to actual concurrency.

修复 · Fix

• sharp 依赖改为 ^0.35.3（原为精确锁定 0.34.4）。用区间而非再次精确锁版，可让该依赖跟随内核，避免再次分叉。
• sharp is now ^0.35.3 instead of an exact pin, so it follows the kernel instead of drifting out of sync again.

升级 · Upgrade

pnpm add dsh-chat-image-lightbox@latest

然后完整重启 DSH（进程内已载入旧 DLL，不重启不生效）。
Then fully restart DSH — the old DLL is already loaded in-process.

老包名 @loyalchiiina/dsh-chat-image-lightbox 也同步发布了 1.7.5（历史版本已标记弃用并提示迁移）。
The legacy scoped package @loyalchiiina/dsh-chat-image-lightbox also received 1.7.5; older versions are deprecated with a migration notice.

兼容性验证 · Compatibility

插件代码零改动。已逐项实测本插件用到的全部 6 个 sharp API 在 0.35.3 下行为一致：

metadata · rotate · resize({width, withoutEnlargement}) · png({compressionLevel}) · webp({quality}) · toBuffer

其中 TIFF→PNG 无损链路经像素级比对确认完全一致（这是本插件存在的意义：Fluent 图表等 TIFF 导出的高清直显）。

No plugin code changed. All six sharp APIs used here were verified against 0.35.3, and the TIFF→PNG path was confirmed pixel-identical (lossless) by raw-byte comparison.