antigravity-maintainer-batch-release

Antigravity 维护者批量发布

适用场景

适用于 AAS 维护者全面检查、PR 修复与合并批次、运行时／目录发布、已安装维护者技能的对齐，以及公开部署验证。普通贡献者无需维护者权限。

操作顺序

1. 保留未提交的工作。使用隔离的当前 main 检出。阅读该基线上的准确 AGENTS.md、.github/MAINTENANCE.md、package.json 和维护契约。强制要求的工具必须存在于该基线上；切勿从其他检出中引入已废弃的流程。
2. 对于源 PR 批次，先列出 PR 编号，并在内容分析／审查之前，从干净的当前 main 启动 npm run maintenance:cycle -- start，然后遵循完整周期。运行器会在不发布的情况下衡量源代码维护工作；在准备发布前完成该周期。对于仅发布任务或不含 PR 的扫描，使用 --prs none 启动明确的空周期，并在准备前验证。对全部获授权范围进行分诊。修复源 PR，运行组件计划，审查整个受跟踪的 skills/<skill-id>/** 子树，并检查相关公告。不得以启发式评分替代语义审查。
3. 使用 maintenance:cycle merge，它会委派给 merge:batch；若不适用源周期，则直接调用 npm run merge:batch。二者共用唯一的合并权限；同一合并不得同时运行两者。保持严格的受保护 main 和管理员强制措施。安全分析可以先于审查；合并仍要求当前检查通过，并且具备真实的 Tessl 审查或针对准确 HEAD 的维护者证明。私有签名收据可复用未变更内容／上下文的审查结果。保留仅所有者可处理的敏感变更限制，以及受保护基线的分叉台账限制。
4. 使用引导式接收流程收集所有阻塞项，然后通过私有外部 --state-dir 恢复。每个阻塞项只记录一次；两次等效检查均无进展后，继续独立工作。每次都重新获取 PR 状态和保护设置。遇到阻塞 PR 后，继续处理独立 PR；报告失败。遵循周期参考中的确定性失败代码和有限次数的读取重试。写入结果未知时，绝不重复写入；不得夺取活动状态锁，也不得复用过期的 CI 证据。不要改写 PR 元数据，不要自动重试基线漂移，也不要使用 GitHub 自动合并。
5. 普通源代码合并只会生成临时验证状态。受跟踪的分发快照和贡献者署名会在受保护的发布 PR 中刷新；普通情况下不需要创建规范同步 PR。对于明确要求不发布的依赖修复，可仅同步可信基线的仅所有者契约所验证的现有常规锁文件副本；其他所有生成路径仍由发布流程负责。
6. 在获授权尝试发布前，在已验证 main 的干净、已提交后代上（包括用于诊断的主题分支）运行 release:rehearse -- X.Y.Z --state-dir /absolute/private/completed-cycle。此命令会在一次性克隆中运行共享的本地候选版本流水线，不会推送、打标签、发布或修改源代码／周期状态；详见完整的本地演练契约。演练通过并不代表获准发布。使用契约中的私有 --candidate-dir 收据／晋升流程，以保留已测试的提交；当其准确源代码和工具链仍然有效时，避免重复本地准备。获得授权后，使用 release:prepare 和 release:publish。准备流程会创建本地发布提交，将其准确封存的树打包，对该候选版本运行完整测试套件，并且仅在测试通过时推送；不要再用诊断性预检重复运行该测试套件。通过保护规则合并准备好的发布 PR。创建或复用标签，等待不可变候选版本，然后发布并验证准确的 npm 字节内容。只有 npm 成功后才创建 GitHub Release；随后 Pages 会原样使用同一批已测试字节。发布提交仍是受保护的祖先时，main 可以继续前进。
7. 对于兼容的纯目录发布，使用独立的目录工作流和不可变修订／SRI。保留离线运行、回滚和由 Agent 控制的选择。不要仅为更新目录数据而提升或重新发布运行时。
8. 源批次结束时，在完成所有其他源周期操作后，针对准确的 main CI／CodeQL 运行 maintenance:cycle verify。若不发布，到此为止：公开分发快照会有意保持为上次发布的版本。若要发布，则完成契约中的完整发布对齐门槛，包括实际公开字节内容和线上界面。将个人 MCP 配置和会话重新加载情况分开报告。从已采纳的规范源更新已安装的维护者技能，同时保留无关的安装内容。 当用户明确请求发布 GitHub Release，同时禁止发布到 npm 时，release:publish -- X.Y.Z --skip-npm 会执行相同的发布准入检查和候选版本检查，创建或验证标签，跳过 npm，并创建 GitHub Release，在说明中明确披露 npm 不可用。使用 release:verify -- --version X.Y.Z --target github-site 明确验证这一指定目标。GitHub／站点发布完成不等于完整的 npm 分发；不得将被排除的 npm 和本地主机报告为通过。所有适用的公开对齐门禁仍然必不可少。绝不能根据 npm 尝试失败推断应使用此模式。之后如需正常发布，仍须获得明确授权。

示例

准备安全的分析，但不合并：

npm run merge:batch -- --prs 123,124 --prepare-only

完成实际语义审核后，保存证据并合并：

npm run merge:batch -- --prs 123,124 --state-dir /absolute/private/state --reviewed-head FULL_40_CHARACTER_SHA --reviewer maintainer --review-evidence 'Complete bundle, provenance, safety and limitations reviewed'

使用真实 ID、路径和完整的不可变 SHA。状态目录必须事先存在，由私有用户拥有，权限为 0700，且位于源码检出目录之外。

验证

阅读组件验证和维护契约，了解准确的检查项、发布证明、目录兼容性和计时方法。必需的检查仍为 pr-policy、pr-evidence、source-validation、artifact-preview。未知／共享／策略变更需要完整验证。仅当满足组件指南中规定的前置条件后，CI 才可并行执行完整计划中未分片的完整脚本套件，以及隔离的 Web 覆盖率测试／构建；所有按顺序执行的结果仍然必不可少。经 Blob 过滤的检出仍会保留完整历史，并按需获取所需字节。固定版本的 Turborepo 可在现有的免费 GitHub 缓存额度内复用完整的 Web 覆盖率／类型检查／编译结果；当前提交元数据、预渲染、最终验证和完整的仓库脚本套件仍须重新运行。在使用缓存的 CI 作业中固定相同的精确 Node 补丁版本，并根据稳定的用户空间／工具链标识限定持久化缓存的范围，绝不能使用云内核作为依据。请遵循组件指南，了解输入、输出完整性检查、缓存信任和诊断 HIT／MISS 收据。不启用付费 CI 或远程缓存。完整的未分片脚本套件最多可使用两个工作线程，安排六个已审核的隔离分组，然后按顺序运行其余所有分组；出现故障时，会等待正在运行的子进程结束，并安全失败。请遵循组件指南并保留完整的清单摘要。

限制

此技能不会授予额外的发布或消息发送权限。Tessl 不可用时，状态应为 manual-review-required，而不是审核通过。Jev、SkillSpector 和计时报告仅供参考。绝不能直接推送到 main、绕过管理员限制、使用可变的制品标识、采用由 PR 控制的审核收据，或伪造原生客户端重新加载证明。本地计时无法证明整个周期有所改善。

进行 SkillSpector 问题分类时，请参阅扫描器结果解读；运行时变更请参阅Core 预览验收。

对于目录、Pages 和旧版重定向变更，请遵循公开界面验证。

对于 CSV 安全问题受理，请区分历史／生成的重复项与当前的规范缺陷。绝不能为了方便分类而执行技能 Markdown 或外部设置流程。档案必须包含所在的嵌套技能树；可执行文档示例应使用经过审核的测试夹具和惰性源码对比。发布前，记录每项发现的处置方式及其证据。

创建发布标签前，盘点并审计所有规范的 npm 锁文件，包括打包的应用和模板；根目录／Web 审计干净并不代表嵌套依赖也已覆盖。源码合并后以及打标签前，立即重新检查实时安全警报。将新产生的警报视为发布前必须处理的新任务。

强制发布周期屏障

记录批次中存在尚未解决的 PR 时，绝不能继续发布。批次中的每个 PR 都必须合并到受保护的 main，或在关闭前发布包含所有者理由且绑定到其确切 head 的评论，然后关闭且不合并。策略阻碍不代表任务已完成，也绝不能成为绕过合并保护的理由，或仅为解锁发布而关闭原本有效的贡献。

使用 npm run maintenance:cycle -- close --state-dir /absolute/private/state --prs 123 --expected-head FULL_40_CHARACTER_SHA --reason 'Substantive reason, including the replacement PR when applicable'。 此命令会在关闭前发布所需评论；写入结果不确定时会停止，不会重试。未记录的普通关闭不满足验证要求。已合并的 PR 使用现有的受保护合并流程。

在确切的当前 main 上成功运行 maintenance:cycle verify，然后再运行 npm run release:prepare -- X.Y.Z --state-dir /absolute/private/state。 如果周期证据尚未完成，准备流程会在创建分支或更改版本之前失败。发布 PR 会包含 data/release-cycle.json；发布流程和 npm 工作流会分别重新读取实时 PR 状态、关闭评论、受保护 main 的祖先关系，以及针对已验证源提交的成功 CI/CodeQL 检查。重新打开的 PR、缺失的证明或失败的检查都会阻止发布。如果准备前 main 有变动，请重新验证。绝不要缩小记录的范围来掩盖阻碍。

如果任务确实仅涉及发布，且没有源 PR 批次，请显式使用 --prs none 启动周期并完成验证；不支持隐式绕过周期。原始批次清单必须包含授权范围内的每个 PR。

贡献者就绪状态

按照 贡献受理流程 提供作者证据、初步修正和受限捆绑包。复用现有的贡献者预检和 Actions 摘要；它们不授权批准或合并。在语义审查前，要求作者进行实质性且可执行的修复；区分实际任务测试与结构、源代码和协议检查，并保留精确提交头审查。在声称维护成本降低之前，衡量真实的外部 PR 结果。

检查 PR 证据时，解析模板注释，不要拼接可见片段；未完成的注释不属于作者证据。将此解析器与对不可信报告输出进行转义的逻辑分开。

规范技能树 PR 的强制准入由受保护基分支的 pr-policy 和当前正文合并检查强制执行。要求填写三个证据部分，接受简短且范围明确的结果，以及说明未运行测试的原因，并返回作者可执行的修正意见。不得通过所有者证明或缓存的语义回执免除此要求。描述或草稿状态发生偏差时，停止合并尝试；草稿仍可用于反馈。新的外部导入必须保留许可证来源信息和根目录 LICENSE，不得强迫进行无关的旧内容清理。请遵循捆绑的贡献受理指南中的准入细则。

分流前使用 maintenance:doctor，阶段之间使用 maintenance:cycle next。继续执行彼此独立且已获授权的工作，在完整验证前完成修复，仅对齐下一次合并，并在最终计划的源代码 PR 中加入发布说明。对于经过身份验证的候选项晋级、缓存的发布网页检查，以及明确的 GitHub/网站验证目标，请遵循维护契约。

使用有界的 maintenance:cycle run，通过唯一的合并授权方执行已获授权的确定性后续操作。仍须进行针对精确提交头的实际审查。显式设置 --allow-align true 可为每个 PR 更新一次已观察到的提交头；切勿重试结果不确定的写入，也不得虚构审查。请阅读契约，了解独立的元数据准入、提前满足 PR 就绪条件、运行时优先的候选项调度，以及有界的持久化安装。保留所有检查，并衡量实际周期。

对于等待审批的 fork CI，协调器会在等待检查前将任务委派给同一个受保护的合并门禁；它绝不会直接批准运行。确切提交头的调度和失败边界请参阅周期参考。