Mortis 内部标识迁移方案（2026-04-19）

1. 目标

本方案只设计 Multica / multica / golutra 相关内部命名的迁移边界、分层规则与实施顺序，不直接落代码。

当前外显品牌已经逐步收口到 Mortis，但仓库、协议、运行时、服务名、历史路径、生态坐标中仍保留多层旧标识。若继续无边界硬改，极易打断以下能力：

• 现网服务启动与升级
• CLI / Desktop / Web 之间的互联
• 历史数据、Cookie、深链、缓存目录兼容
• 上游仓库、包名、构建脚本、镜像名、运维脚本

因此迁移必须按层处理，而不是全局搜索替换。

2. 结论先行

结论分三条：

1. Mortis 应继续作为“品牌层 / 用户可见层 / 文案层”的统一名称。
2. multica 现阶段应保留在“协议层 / 包名层 / 启动层 / 生态坐标层”，不能直接硬改。
3. golutra 应优先从“旁路可见品牌层”清理；若已经进入内部系统标识、主机名、邮箱、部署目录或历史数据键，则需单独设计兼容迁移，不可直接替换。

3. 分层模型

3.1 品牌层

定义：用户第一眼看到的名称、图标、文案、标题、帮助说明、页面标签、欢迎语、空态提示、README 叙述、产品名露出。

这一层应统一到：

• 产品名：Mortis
• 域名：mortis.tengokukk.com
• 站点图标：Mortis 图标体系

这一层是最适合优先迁移的部分，且已经完成一部分收口。

3.2 用户可见功能层

定义：Web 页面按钮、标签页、Toast、对话框、帮助文字、桌面端壳层文案、Docs 展示页文案。

建议：

• 全量改为中文 + Mortis 品牌
• 允许保留技术词原文，例如 CLI、Token、Daemon ID
• 命令、协议、包名仅在必须原文展示时保留原样

3.3 协议层

定义：深链、URL scheme、Cookie 名、localStorage key、API header、runtime handshake、桌面端唤起协议、浏览器存储键。

这一层现阶段禁止硬改。原因：

• 一旦修改，已有登录态、标签页状态、桌面唤起、CLI 回调都可能失效
• 这类字段往往跨 Web / Desktop / CLI / 后端 / 浏览器状态同步传播

3.4 内部实现层

定义：包名、workspace 名、二进制入口、服务名、镜像名、容器名、数据库字段、迁移脚本、目录名、环境变量名前缀、内部事件名。

这一层必须按“兼容迁移项目”处理，不能借着品牌切换直接改。

3.5 外部生态层

定义：GitHub 仓库路径、NPM 包名、上游 import path、release 拉取地址、第三方回调、脚本依赖的固定坐标。

这一层短期应视为外部依赖，不在当前品牌迁移中动手。

4. 可迁移 / 慎迁移 / 禁改清单

4.1 可直接迁移

以下内容可以继续直接改成 Mortis：

• Web / Desktop / Docs 的标题与副标题
• README、说明文档中的产品名称露出
• 页面内“Multica / Golutra”品牌文案
• Logo、favicon、Open Graph 标题
• 默认工作区说明文案、欢迎文案、空态文案
• 用户可见菜单项、对话框标题、按钮文字

4.2 可迁移，但要保留技术原文

以下内容可在解释层替换，但原始技术值要保留：

• 命令提示中的 multica daemon start
• 页面说明里的 CLI
• 调试信息中的 Daemon ID
• release / provider / package 技术字段

推荐写法：

• 文案写“运行命令 multica daemon start”
• 不要把命令本体直接改成 mortis daemon start

4.3 绝对不能硬改

以下是当前阶段的禁改项：

• @multica/*
• multica://
• ~/.multica
• multica_auth
• multica_csrf
• multica_token
• multica_tabs
• multica-locale
• server/cmd/multica
• github.com/multica-ai/multica
• release 拉取地址里的 multica-ai/multica
• compose / service / container / image / volume / network 里的既有内部名
• runtime 注册协议中的既有字段名
• 数据库存量表结构、主键、历史记录字段

禁改理由：

• 这些内容已经参与运行时互通、数据持久化或上游生态解析
• 改动会引发“品牌改完了，但程序起不来 / 状态丢了 / 升级断了 / 登录失效”的系统性问题

5. golutra 的处理原则

golutra 与 multica 不同，它更像阶段性品牌 / 部署残留，不一定承担公开生态兼容责任，因此处理优先级更高。

建议按三类拆：

A. 旁路可见品牌残留

可直接清理：

• README 里的 Golutra
• 页面帮助文案
• docs 示例名称
• 用户能看见的默认字符串

B. 部署识别残留

不要直接硬改，要先核对：

• 主机名
• 邮箱
• 证书名
• 反代 upstream 名
• systemd service 名
• compose project 名

这类内容若改名，需同步所有引用链。

C. 数据与脚本残留

禁止无计划替换：

• .env 键值
• 历史脚本中的路径常量
• 构建脚本里的镜像名
• 自动化脚本里的服务选择器

6. 建议的新命名边界

6.1 对外统一名称

• 对外产品：Mortis
• 对外站点：mortis.tengokukk.com
• 对外视觉：Mortis 图标与文案

6.2 对内短期保留

• 包名：继续 @multica/*
• CLI 命令：继续 multica
• 深链：继续 multica://
• 本地目录：继续 ~/.multica
• GitHub 上游：继续 multica-ai/multica

6.3 中期可评估的“别名层”

若后续确实要把 multica 进一步改成 mortis，建议只在中期引入“兼容别名层”，而不是现在直接动底层：

• mortis 作为新 CLI 外壳
• multica 作为兼容别名继续存在一个迁移周期
• 新页面文档优先展示 mortis，技术兼容说明中保留 multica

但这一步必须单开项目，不应混入当前品牌收口工作。

7. 推荐迁移顺序

第一阶段：品牌面彻底收口

目标：用户看到的几乎全部是 Mortis

执行范围：

• Web 常用页面
• Desktop 外壳文案
• README / docs / 帮助页
• 图标、标题、空态、引导页

状态：正在进行，属于低风险高收益阶段。

第二阶段：旁路可见残留清点

目标：把仍可能暴露给用户或旁观者的 Golutra / Multica 清单化

执行范围：

• 非主路径 docs
• About / Changelog / 更新提示
• 错误提示与调试浮层
• 安装器、桌面端窗口名、下载文件名

输出物：

• 一份“旁路可见残留清单”
• 一份“可立即替换 / 需兼容迁移 / 禁改”分类结果

第三阶段：协议与内部标识迁移设计

目标：只设计，不实施

必须先回答：

• CLI 是否要从 multica 迁到 mortis
• 深链是否要双轨兼容
• Cookie / localStorage 是否允许保留旧前缀
• @multica/* 是否长期保留
• GitHub 上游是否要 fork 后改坐标

在这些问题没有统一结论前，不进入代码层硬改。

8. 哪些层最值得继续做

如果接下来只想低风险推进，优先级建议如下：

1. 用户常用页中文化与品牌清理
2. README / Docs / Desktop 壳层品牌清理
3. 旁路可见残留审计
4. 内部标识迁移方案设计
5. 协议兼容迁移 PoC

不要反过来从第 5 步开始。

9. 风险说明

最常见的误区有四类：

9.1 把品牌层和协议层混为一谈

后果：

• 页面看上去更“统一”了，但桌面唤起失效
• 登录态丢失
• 现有链接失效

9.2 把 import path 当成普通字符串替换

后果：

• 编译失败
• release 检查失败
• 依赖分发断裂

9.3 先改服务名，再补运维

后果：

• compose、反代、监控、日志采集一起断

9.4 把历史数据键直接改名

后果：

• 用户已有状态、缓存、标签、偏好、登录信息丢失

10. 回滚思路

当前阶段推荐的回滚原则：

• 品牌层回滚：直接回退对应前端 / docs 变更
• 用户文案层回滚：直接回退页面字符串
• 协议层与内部层：如果未做，不存在回滚成本；如果未来进入实施，必须先准备“双写 / 双读 / 别名 / 数据迁移”方案，再允许动手

11. 最终建议

现阶段最合理的策略不是“把所有 multica 全部消灭”，而是：

• 对外：坚定使用 Mortis
• 对内：承认 multica 仍是技术内核标识
• 对 golutra：优先清理旁路可见残留，谨慎处理部署与脚本层

一句话总结：

Mortis 统一品牌，multica 保留内核，golutra 分层清残。