商店发布¶

共享发布基础层使各商店之间的身份、披露声明、分发策略、资源和工件来源保持一致。它不会发布或预留上架条目。

执行顺序和平台工作者验收标准见 STORE-PUBLISHING-HANDOVER.md。

规范输入¶

• store/metadata.json：产品身份、上架文案、要求、权限和商店分类。
• store/privacy.json：本地数据和网络传输披露。
• store/compliance.json：捆绑和下载组件的审查台账。
• store/assets.json：规范图标和截图来源。
• config/distributions.mjs：每个分发的不可变运行时策略。

在任何平台打包工作之前，先运行共享检查：

node scripts/validate_store_foundation.mjs

平台工作者还必须使用其目标运行验证器，例如 --distribution=mac-app-store。失败是提交阻断项，而不是削弱共享策略的理由。

平台交接¶

Linux 实现与证据检查清单位于 Snap Store 操作手册。

构建顺序应为 Windows、Linux，然后是 macOS。Windows 复用当前已签名的安装程序和更新程序契约；Linux 引入隔离机制；macOS 的架构变化最大，因为下载的可执行代码不属于已批准的共享基础层。

每个平台工作者只负责自己的包配置、平台 CI、商店专属资产和提交操作手册。对共享身份、隐私、权限或合规记录的更改必须更新规范文件，而不是复制到仅限平台的文档中。Electron 仍然是唯一的 UI 和桌面外壳；不得恢复任何 Tauri 路线。

Microsoft Store 的打包与提交交接在 .github/workflows/microsoft-store.yml 中实现；操作步骤和待处理的负责人工作在 store/microsoft-store.md 中。

Mac App Store 的沙盒目标和私有打包工作流已在 electron/electron-builder.config.mjs 和 .github/workflows/mac-app-store.yml 中搭建好。该工作流仍受捆绑运行时合规门禁阻塞，并且永远不会提交到 App Store Connect。当前阻塞项和负责人操作见 Mac App Store 操作手册。

工件与发布契约¶

打包工作流会在安装程序旁边写入 store-artifact-manifest-<platform>-<arch>.json。它记录源版本和提交、分发策略、合规清单摘要、工件大小和 SHA-256 摘要。商店工作者必须使用其明确的分发目标生成该文件，并在提交前附加平台签名验证结果。

在所有地方使用相同的生命周期：

构建 -> 验证 -> 提交 -> 批准 -> 排期 -> 发布 -> 核验

只有负责人提供或授权商店账户、法律协议、支付/税务信息、签名凭据、年龄分级和最终发布。未经该批准，绝不提升应用版本、提交工件或发布上架条目。商店渠道只有在完成首次经验证的生产发布后，才会成为受维护的发布渠道。

基础层未决阻塞项¶

• 记录捆绑的 uv 二进制文件的确切摘要和上游声明。
• 在捆绑之前，解决已锁定的 Python/运行时再分发记录，然后才能进行捆绑。
• 除非每个模型许可证都单独获得批准，否则将默认模型权重保留在商店包之外。
• 在捆绑并批准每个可执行组件之前，Mac App Store 目标仍处于阻塞状态；且不能在那里启用运行时代码下载。