主题
发布与版本管理
Desktop、Desktop Core、Browser 与 LMCP 的首次正式版本及 Git 标签统一为 1.0.0。组织首页和文档站随这组版本更新内容，不单独打产品标签；Dictionary 继续使用已发布的 v0.0.3 词包和 release.json，不随应用重打标签。
1.0.0 发行说明汇总正式下载、安装、完整对应源码、标签流水线与验收范围。四个软件仓库的正式标签触发测试和 Release 发布；日常 main / PR 只运行检查。文档站另从检查通过的静态产物部署 Pages，不打软件标签。
六个仓库各自交付什么
| 仓库 | 交付与权威说明 | 首发标签 |
|---|---|---|
| Desktop | 桌面安装载荷、Core/JRE/词包/Native Host、对应源码和物料摘要；打包指南 | 1.0.0 |
| Desktop Core | Java核心、许可与依赖说明；由Desktop固定gitlink使用；发布验收 | 1.0.0 |
| Browser | 原样生产扩展ZIP、词包来源和校验结果；发布指南 | 1.0.0 |
| LMCP | 正式规范、Schema、示例、机器合同和参考验证；发布维护 | 1.0.0 |
.github | 组织首页、共用贡献与支持入口 | 不打产品标签 |
| 文档站 | 此站根docs正文和VitePress构建 | 不打产品标签 |
推送前完成的检查
- 工作区干净，产品版本与锁文件一致；Core实际提交等于Desktop gitlink。
- LMCP规范原字节、逐文件摘要、两端冻结与来源一致；同步DTO和业务适配，不能只替换摘要字符串。
- 运行各仓格式、文档、类型/单元/集成检查，再串行运行隔离的真实生产UI、连接、安装载荷检查。
- 正式安装载荷和扩展包的版本与来源可核对，保留SHA-256、许可和对应源码；原始测试资料不进入仓库。
- 核对Actions语法、固定依赖与可干净构建性；本地成功不等于远端工作流已经成功。
测试必须使用专用资料、回环端口和无头浏览器，不使用日常浏览器、系统剪贴板或修改系统日期。模拟时钟只作用于隔离测试环境。
GitHub 与 Gitee 平级发布
词遇在 GitHub 和 Gitee 使用同名仓库。源码、文档和贡献可以从任一平台开始；版本身份由 Git 提交、标签和发行物摘要确定，不由平台名称决定。
| 内容 | 两个平台共同要求 | 需要分别确认 |
|---|---|---|
| main | 使用相同历史与最终提交 | 远端是否接收了本次提交 |
| 软件标签 | 同一个 1.0.0 标签对象指向同一提交 | 每个仓库、每个平台是否实际存在 |
| 发行包 | 相同平台与架构使用同一构建的文件及 SHA-256 | Release 附件是否上传完整、下载是否可用 |
| 协作 | 适用相同规范与测试要求 | Issue / Pull Request 的讨论与评审状态 |
| 自动化 | 本地验证命令不依赖来源平台 | 当前已有 GitHub Actions；Gitee 未配置等效流水线 |
同一个问题优先在一个平台跟进，跨平台引用原讨论。任何一边接受的改动都先整合到同一条 main，再同步另一个远端；不能分别修改后强制覆盖另一边，也不要在两个平台各构建一个来源不同的同版本包。
是否需要每次推送两个平台
可以自动同步，但需要明确同步范围。两个平台平级是指源码、版本和贡献受到同等维护，不要求同时启用两个方向的自动覆盖。
| 方式 | 适用情况 | 词遇的选择 |
|---|---|---|
本地分别推送 main | 尚未配置自动化，或需要人工处理两边差异 | 当前可直接使用；必须分别检查结果 |
| Gitee 仓库镜像 | 目标仓库允许按来源覆盖分支、标签和提交 | 不用于当前只同步 main、暂不发布标签的阶段 |
GitHub CI 成功后同步 main | 需要检查通过后自动更新 Gitee，遇到分叉停止 | 推荐方案；启用前配置独立自动化身份与权限 |
Gitee 官方支持从 GitHub 拉取、向 GitHub 推送以及双向镜像，但镜像包含标签，且会覆盖目标引用。官方也提示双向镜像存在代码丢失风险。因此，不把镜像当成自动合并冲突的工具。Gitee 镜像说明、官方功能介绍
推荐的受控同步流程
- 维护者将整合后的
main推送到 GitHub；在 Gitee 接受的改动也先取回、审查并整合到同一条历史。 - 当前仓库所有必需检查通过后，取得实际通过检查的提交 SHA。同步前再次确认它仍是 GitHub
main，避免较早的流水线覆盖较新的结果。 - 读取 Gitee
main。只有 Gitee 提交是待同步提交的祖先，才普通推送该 SHA 到refs/heads/main；已一致则直接结束。首次空仓可创建main，已有独立初始化提交则先人工整合。 - Gitee 出现独立提交或分叉时，流水线明确失败并保留两边历史，由维护者合并、重新验证后重试。网络失败可以重试，不使用强制推送解决。
- 记录两边提交 SHA 和同步结果。标签、Release 附件、Issue、Pull Request、Wiki、Pages 与商店发布不在此流程内。
自动化只使用单个 SHA:refs/heads/main 引用，明确禁用附带标签；不使用 --mirror、--force、--all、--tags 或 --follow-tags。Desktop 需要先让其固定的 Core 提交可从 Gitee 取得，再同步 Desktop。
在 GitHub Actions 中接入
优先在现有主 CI 中增加独立、无矩阵的同步任务，只允许本仓 push 到 main 触发。按下表设置 needs，等待对应任务的全部矩阵实例成功；不要在任一矩阵实例的最后一步执行同步。
| 仓库 | 现有主 CI 文件 | 同步任务的 needs | 必须全部通过的范围 |
|---|---|---|---|
| 文档站 | .github/workflows/docs.yml | verify | 文档、构建、开发服务与页面测试 |
| Desktop | .github/workflows/ci.yml | desktop | 当前桌面完整主 CI |
| Desktop Core | .github/workflows/ci.yml | core | Linux、macOS、Windows 三平台 |
| LMCP | .github/workflows/ci.yml | verify | Node 22、24 两组合同检查 |
| Browser | .github/workflows/ci.yml | browser | 当前插件完整独立 CI |
这张表用于日常 main 源码同步。手动候选安装、跨仓连接、升级替换和视觉验收各自记录结果，不作为每次源码同步的默认前置条件；主 CI 成功也不能代替这些发行验收。Desktop 同步仍须先确认其 Core gitlink 在 Gitee 可取得。
若使用独立的 workflow_run，必须检查触发来源、分支、仓库与 conclusion == 'success'，并使用上游的 head_sha。workflow_run 的多个工作流名称是“任一完成即触发”，不能据此认定全部检查已经通过；它还能取得 Secrets，不能执行未受信任 PR 的代码或产物。GitHub 触发规则
同步身份只授予目标仓库所需的写权限，独立保存在 GitHub Actions Secrets；使用经官方指纹核验的 Gitee 主机密钥。不要上传维护者日常 SSH 私钥，也不要把凭据写入远端 URL、仓库、命令输出或日志。为每个目标仓库串行执行同步，并使用普通推送保留最后一刻的分叉保护。GitHub Secrets 说明
以上是接入方案，当前仓库尚未启用远程自动同步。 本机可以推送 Gitee 的 SSH 配置不会自动出现在 GitHub Runner 中；维护者完成独立身份、Secrets 与工作流配置后，才能通过一次真实同步验证启用结果。
发布顺序与标签
Desktop 依赖 Core 的精确提交。先让该提交在两个平台都可取得，再发布引用它的 Desktop；推荐依赖顺序是 LMCP → Core → Browser → Desktop → 组织与文档站。文档站和组织仓库不打产品标签。
- 读取两个远端的 main 与标签，确认已知差异。尚未整合的提交先审查，不能用强推代替整合。
- 完成修改和检查，记录每仓最终提交、合同来源、Core gitlink 与发行物摘要。只推送已确认的 main，不公开开发历史备份。
- 修改仍在进行时可以暂不保留本地
1.0.0标签。只有确认两个远端都没有该标签，才可撤销未发布的本地标签；任一平台已有正式标签时，不移动或删除它，应采用后续修复版本。 - 最终确认发布后，在各软件仓创建一次
1.0.0标签，再将同一个标签对象显式推送到两个远端。不得分别创建同名但内容不同的标签。 - 分别核对源码、标签、自动化结果和发行物。若一边失败，修复该平台的发布步骤，保留另一边已经发布的版本；不要重新打包覆盖同版本文件。
本地可以把两个远端命名为 github / gitee，也可以保留 origin 表示已有平台，再增加另一远端；远端名称只是本地别名，不表示主从。推送时明确写出目标远端与引用，不使用 git push --all 或 git push --tags。
源码托管、GitHub / Gitee Release、浏览器商店与 GitHub Pages 是分别执行的动作。已有工作流只代表配置能力，不代表它们已经成功运行或发布。任何外部推送、创建 Release、商店提交和站点部署都由维护者审阅并明确授权。
已公开历史与来源
首次公开整理保留各仓原始 init commit，以及当时直接以 init 为父提交的结果提交。已公开后正常追加提交，不因补充 Gitee 或修订文档重新压缩历史。Dictionary 既有资源标签和历史保持独立。
完整开发历史、备份分支与 Git bundle 只用于私有恢复，不推送到公开仓。向任一平台推送前审查结果树、提交信息和明确的引用，排除个人路径、过程报告、测试资料与凭据；若远端出现未审查提交，先整合再继续。
正式来源以最终软件标签、消费端冻结清单、Desktop 的 Core gitlink 和发行物附带的源码、构建、发布 manifest 为准；安装载荷使用 BUILD-MANIFEST.json 核对实际物料。标签尚未发布时使用精确提交 SHA，不以一个尚不存在的标签证明验收。历史候选报告保留当时的版本、源码与验收事实，不能改写成新提交的验证。
1.0.0之后的资料保护
正式1.0.0起维护真实用户资料的升级承诺。后续结构变化需要明确版本、迁移或安全拒绝策略，以及备份、重开、升级与恢复测试；禁止为了通过测试清空旧正式库。首发前的0.x/rc试验库不是已承诺兼容的正式格式，遇到不识别的资料应保留原文件并提示独立工作区。
连接后的浏览器仍封存独立资料A，使用桌面B+C，明确断开恢复A。账号和独立设备云同步属于2.0.0，不能把1.0.0本机连接称为云同步。
本页描述发布方法；具体平台、签名、公证、商店与远端检查状态，必须查看对应发行记录，不能从版本号推断。