ln-62-repository-publisher

仓库发布

目标： 仅发布用户授权的更改，然后从远程源验证结果。

执行约定： 按顺序排列的复选框即为完成定义。内部将每项跟踪为 PENDING、有具体证据证明的 PROVEN、有证据证明其条件不存在的 CLEARED，或存在缺口的 UNPROVEN；阅读、委派或工具故障都不算证据。每完成一节后，重新核对各项。返回前，解决所有 PENDING，并且只统计 PROVEN 和 CLEARED；针对每个缺口，遵循技能的判定和审批规则。 保留用户意图、范围和现有授权。继续已获授权的工作；仅针对尚未解决且后果重大的选择或必需的外部审批进行询问。根据实质风险调整检查深度，不得悄然跳过检查。保留依赖关系和安全顺序；除此之外，针对每项义务选择恰当的验证方法。

工具路由

需求	首选能力	后备方案
范围、暂存、历史记录和同步	原生 Git CLI	如果无法获得等效的 Git 证据，则停止
仓库验证	项目原生命令和已安装的验证器	有记录的手动检查
远程分支和 CI 状态	已认证的托管平台 CLI 或连接器	Git 远程证据及直接工作流 URL
干净源验证	当分发渠道发生变化时，使用临时克隆和隔离的主机配置	远程原始文件，并将所需的安装证据标记为 BLOCKED
静态站点验证	部署工作流及直接 HTTP 请求	托管平台 API 的部署状态
当前市场行为	主机官方文档	标记假设，避免破坏性重试

优先查看精简的 Git 输出，然后再打开将要暂存文件的完整差异。切勿通过隐藏失败退出码的方式管道传递命令。

远程事实使用托管平台 API 核实，仓库事实使用 Git 核实。本地分发或部署状态无法证明远程使用方更新有效。

检查清单

确认范围和证据

• 确认用户明确要求提交并推送，并确定目标分支。
• 修改前阅读仓库说明、发布规则和当前分支策略。
• 检查 git status -sb、已暂存和未暂存的差异、未跟踪文件、远程仓库及近期提交风格。
• 识别与任务无关的用户更改；未经明确授权，不得暂存这些更改。
• 对删除内容和生成文件进行与编辑文本同等仔细的检查。
• 检查行为、安装命令、目录、布局或公共网站是否需要同步更新文档。
• 常规发布期间不得更改版本、标签或发布元数据，除非请求或仓库策略明确要求这样做。
• 对于市场相关编辑，确认每个稳定标识符均未更改，除非已批准有意进行迁移。
• 当存在多个主机目录且仓库策略要求保持一致时，确认它们包含相同的分发单元，且顺序符合要求。
• 当多个清单或目录中存在重复元数据时，确认描述和源路径与规范源一致。

验证路由

• 先发现并运行仓库原生验证命令，再运行通用检查。
• 对于已更改的技能，运行仓库要求的或宿主原生的技能验证器，或执行其文档说明的手动替代方案。
• 对于已更改的插件或软件包，运行仓库要求的验证器，或执行其文档说明的手动替代方案。
• 运行分发形式存在且已更改，或仓库策略要求的所有宿主原生严格验证器。
• 仅运行仓库及受影响分发形式要求的目录一致性、清单解析、过时引用、本地链接和空白字符检查。
• 仅运行相关产品测试；若仓库策略没有要求，不要擅自设置繁重的发布门槛。
• 如果确认某项必需检查失败，提交前应停止，除非用户明确接受该失败。
• 记录跳过的检查，并注明确切缺失的依赖项或环境。

同步与提交

• 提交前获取目标远程，并比较本地 HEAD 与远程分支。
• 如果本地落后或发生分歧，检查双方内容，并在授权的分支工作流中协调，同时保留用户更改；遇到未解决的语义冲突或必须重写历史时，应停止。切勿隐式强制推送。
• 工作区包含混合更改时，暂存明确指定的路径；只有用户批准所有更改时，才暂存整个工作区。
• 暂存后检查暂存区差异和差异统计。
• 从暂存内容中排除机密信息、本地缓存、临时产物和非预期凭据，不要删除用户拥有的文件；如果预期更改中包含机密信息，应阻止发布并报告已脱敏的证据。
• 遵循仓库的提交消息规范，并概述全部暂存更改。
• 遵守已配置的提交签名和署名策略；不要编造贡献者身份，也不要禁用必需的签名。
• 创建提交并记录完整 SHA。
• 推送到授权分支，不得更改分支保护设置或使用强制推送。

远程验证

• 通过 Git 或托管平台 API，在授权远程上验证已发布的提交；仅在身份或同步状态不确定时使用第二个来源。
• 以有限等待时间跟踪已推送提交所需的 CI，并提供直接运行链接。如果无法继续等待，应将待处理状态报告为 PARTIAL；不得将待处理等同于成功。
• 如果静态网站有更改，应等待部署完成，并使用绕过缓存的请求验证线上内容。
• 如果安装内容或市场内容有更改，应将授权且使用者可访问的远程仓库克隆到干净的临时目录中，并验证受影响的分发形式。
• 安装或更新行为发生变化时，至少从文档所述的分发来源安装一个受影响的软件包或插件，并在隔离的宿主配置中进行测试。
• 如果存在稳定的分发标识符或版本号，应验证已安装产物解析出的标识符和版本符合预期。
• 将临时宿主配置与用户当前使用的设置隔离，并在之后安全地清理。
• 重新检查本地工作区和 HEAD 是否与已发布的提交一致。如果远程发生并发更新，应验证其中仍包含已发布的提交，并报告两个 SHA；不得通过覆盖较新的工作来恢复一致。

安全门禁

• 绝不在输出中泄露身份验证令牌或凭据值。
• 除非明确收到请求，否则绝不创建发布、标签、软件包发布、讨论或拉取请求。
• 绝不因此删除远程分支或更改默认分支。
• 如果需要绕过分支保护、身份验证或必需检查，应返回 BLOCKED。

判定

• PUBLISHED — 提交、推送、必需的 CI 和适用的远程验证均已成功。
• PARTIAL — 推送已成功，但非破坏性的远程检查仍待完成或已失败。
• BLOCKED — 因授权、同步、验证或远程访问失败，发布未能完成。

自检

• 返回前完成核对。 检查各项证据、需求覆盖情况、矛盾、范围、判定和适用的清理工作。更正报告或获授权的产物。重用有效证据；不要自动重新扫描仓库或重新运行已成功的命令。仅在相关内容发生变化、检查失败或证据尚未解决时重复检查。披露仍存在的缺口。

输出约定

使用用户的语言，并按以下顺序报告；保留全部五个字段，且每项事实只陈述一次。结果简短时，每个字段可占一行；省略空表格，不要复制所链接的产物：

1. 结果： 技能专属判定及有证据支持的结果。
2. 范围： 已审查／更改的范围、排除项、基线及重要假设。
3. 证据： 以下技能专属字段；区分事实、推断和未经验证的声明。链接相关产物；适用时使用表格。
4. 验证： 检查结果、无法取得的证据，以及适用的清理工作／外部状态。
5. 完成情况： Checklist: X/Y complete；Incomplete: None，或列出每项 UNPROVEN 内容的原因、对结果的影响及明确的后续操作；剩余风险和待定决策。

技能专属证据： 已发布／排除的路径、分支、完整提交 SHA、远程 URL、验证结果、CI／部署 URL，以及适用的干净源码安装／更新证明。对于 PARTIAL，说明推送的提交是否可安全保留，以及能够完成验证的可观察事件。只有在确认远程提交和所有适用的必需工作流均已完成后，才能使用 PUBLISHED。