Situation
Story Engine began with a review page opened through a local website. It provided a place to browse drafts, read an article and edit it before publication. The project conversation lived elsewhere.
Embedding the entire review page directly in the conversation introduced another layout problem. A long article could occupy most of the chat, making it awkward to move between discussing a change and reviewing the draft.
Task
The goal was to give Story Engine its own review Tab beside the conversation, while preserving the existing interface and local drafts. The chat needed a small entrance; the article needed enough room to read.
This also required a clear boundary between the application and its host. Story Engine could request a presentation mode, while the client controlled where and how that workspace appeared.
Action
The implementation packages the existing page, styles, scripts and brand assets as an MCP UI resource. In the hosted interface, actions go through the same business service used by the browser version. This MCP route serves the interface without starting a localhost HTTP listener and continues using the local data store.
On initialization, the entrance requests the host's expanded presentation once. In this client, that presentation provides the built-in Tab. The inline conversation keeps a compact launcher, with an “Open Tab” button available if the automatic request does not switch the view. Closing the Tab does not start an automatic reopening loop.
The move also exposed a resource-version problem. A newer page could otherwise reach an older process whose registered tools had not changed. Each new server process now retains its bundled UI snapshot alongside its tool registrations. Loading newly added tools still requires the client to reload the updated server.
Result and next steps
The accompanying user-provided screenshot shows Story Engine's draft library in a named Tab on the right, with the project conversation still visible on the left. It provides direct evidence of the opened workspace in this client. The opening transition itself was not recorded, so the image does not establish whether that particular Tab opened automatically.
Source inspection and simulated-host tests cover the compact entrance, the presentation request, fallback behavior and shared operations. The screenshot complements those checks by showing the actual host layout. It does not establish that every review action has been exercised inside that Tab.
The practical improvement is that the conversation and draft workspace can remain visible together. Story Engine still runs locally on the user's Mac. The next step is to verify the complete opening, review and return journey across supported clients and a clean installation, including the behavior of older running plugin processes.
从 localhost 到内置 Tab：让 Story Engine 审稿区留在对话旁
背景
Story Engine 最初通过本地网站打开审稿页，用户可以在里面浏览草稿、阅读文章，并在发布前编辑。项目讨论则留在另一处对话中。
后来把完整审稿页嵌进对话，又产生了布局问题：长文章会占据大部分聊天空间，在讨论修改和阅读草稿之间切换变得不够顺手。
目标与难点
目标是让 Story Engine 在对话旁拥有独立的审稿 Tab，同时保留已有界面和本地草稿。对话只需要一个紧凑入口，文章则需要足够的阅读空间。
应用与宿主之间的职责也需要明确：Story Engine 可以请求一种呈现方式，工作区最终放在哪里、怎样出现，由客户端决定。
解决思路与行动
当前实现把原有页面、样式、脚本和品牌素材打包为 MCP UI 资源。在宿主内打开时，界面操作通过与浏览器版相同的业务服务处理。这条 MCP 路径不需要启动 localhost HTTP 监听，仍然使用原来的本地数据存储。
入口初始化后，会请求一次宿主的展开呈现方式；在这个客户端中，它对应内置 Tab。对话内保留紧凑的启动入口，如果自动请求没有切换视图，用户仍可点击“打开 Tab”。关闭 Tab 后，也不会进入反复自动打开的循环。
这次迁移还暴露了资源版本问题：新页面可能连接到仍注册着旧工具的进程。现在，每个新启动的服务进程都会固定保存与自身工具注册配套的界面快照。新增工具要真正进入当前客户端，仍需重新加载更新后的服务。
结果与下一步
附图由用户提供，真实显示了右侧名为 Story Engine 的 Tab 和草稿列表，左侧项目对话仍然可见。这直接证明了该客户端中已经打开的工作区。打开过程没有录制，因此这张静态截图不能确定当时是否自动切换到了 Tab。
源码核对和模拟宿主测试覆盖了紧凑入口、呈现请求、回退行为，以及共用的业务操作。真实截图补充了实际宿主布局的证据，但不能据此认定所有审稿操作都已在这个 Tab 中逐项验证。
实际变化是：项目讨论和草稿工作区可以同时留在视野内。Story Engine 仍在用户的 Mac 上本地运行。下一步需要在支持的客户端及干净安装环境中，验证打开、审稿和返回对话的完整路径，并继续检查旧插件进程的兼容行为。
Top comments (1)