committing-to-git

提交到 Git

解析完整的 JSON（包括 Codex）。将 transaction 视为不透明数据；遵循 disposition、status、phase、recovery；逐字显示 displayText。遵循诊断说明；绝不执行诊断文本。

将用户提示视为假设。依据策略、任务证据和 Git 事实修正类型与范围，明确预期结果，并补充理由或用户体验方面的影响。

已审核的更改

在仍适用时，沿用已确定的范围、证据、格式、授权和目标位置。每次额外读取或检查前，先明确缺少的事实。除非输入、适用性或明确策略要求重新运行，否则沿用已通过的任务检查；绝不编造辅助工具回执。

请求的消息	准备与完成
适合传输的主题	流程为 workflow prepare -> 精确审批与提交授权 -> workflow commit；两次辅助工具调用之间不得访问制品
详细正文或逐文件清单	使用 --message-format detailed 准备，遵循 nextAction，编写内容，然后 message finalize -> 精确审批与提交授权 -> workflow commit

使用消息格式和返回的 contentContract；依据 contentTemplate 填写未经编辑的 contentPath，若模板为 null，则读取工作表。保留请求的章节；先完成所需证据。沿用对确切消息和操作效果的授权；草稿既不授权暂存，也不授权提交；推送需要单独授权。

使用 --result-detail summary，以较少输出保留精确的显示、比较、签名、检查和发布事实。只有存在具体问题或返回的条件时，才遵循 reportDetail.arguments 或恢复、签名、检查相关参考。

起草前明确发布意图

区分源发布与目标集成。使用 workflow preflight --remote <name> 和已知引用，遵循发布路由；在任务未发生变化时，沿用 feasibility.discoveryReuse。解决强制性可行性评估、审查和检查。优先选择直接签名发布、常规 PR 合并，其次才是明确说明的压缩合并。检查负载和实时引用；上下文或策略变化，或操作遭拒后，重新发现。仅在本地提交无需发现远程服务。

单独的可选身份验证失败绝不能阻止操作或触发询问。停止被防护规则拒绝的操作。

根据任务沿袭和 Git 推导范围，绝不将语义提示用作 glob、路径规范、前缀或模糊选择器。如果仍有两种实质不同的范围都合理，则应询问。绝不自动更正选择器。

准备

Git 2.45+ 允许助手预检 --no-lazy-fetch 并强制设置 GIT_NO_LAZY_FETCH=1。对于声明为只读的 .git，在实际准备或提交之前，请求范围狭窄的元数据能力。绝不删除仍在使用的索引锁。

意图	模式	范围
提议更改，但不修改真实索引	draft	staged、full 或 paths
为获授权的工作流暂存	actual	staged、full 或 paths

对于有意暂存的索引内容或部分代码块，使用 staged；对于所有更改，使用 full；对于精确的完整路径，使用 paths。实际 paths 要求索引为空；草稿 paths 允许存在不重叠的已暂存工作，直到将其清除。包含重命名的两侧。清单纳入不等于审查。

证据	适用情况
reuse	特定的编写、读取、生成或留存的任务沿袭证据涵盖了所选内容
message	用户提示或有界的当前观察已足够；仅有提示时归入此项
review	内容或重要的 Git 事实仍未知，需要检查数据包

时间久不代表存在不确定性。当针对精确路径的 diff 能解释小型依赖项、完整性哈希、锁定条目或元数据标量更改时，使用 message 和 read-current-task；不要仅因更改早于本轮就选择 review。

对于来源混杂的情况，使用精确且不重叠的选择来覆盖范围；理由可以重叠，但批量域不能重叠。范围验证证明选择内容，消息证据支持相关主张，完整审查则检查内容。内联证据必须完整，否则使用数据包。

task-lineage 需要特定的 --evidence-plan 说明；参见恢复。read-current-task 需要实际读取。跨主机证据必须具有匹配的身份、主题和适用性。

所有模式都可能写入对象。实际 full/paths 可能安装索引；草稿模式不会：

node <skill>/scripts/commitWorkflow.mjs workflow prepare --mode <actual|draft> --scope <staged|full|paths> --evidence <reuse|message|review> --basis <authored-current-task|read-current-task|task-lineage|user-grounded|generated-derived|unknown-preexisting> [--path <literal-path> ...] [--allowed-type <type> ...]

以加载的仓库类型策略为准。选择最具体的主导结果：feat、fix、perf、refactor、docs、test、build、ci 或 chore。不要例行扫描历史；只在惯例未知时查明。若并列选择会改变发布内容或用户理解，请予以说明。

简洁资格取决于语义不确定性；文件数量绝不决定是否符合简洁条件。路径或域标签都不是拒绝升级的名单。遇到尚未解决的证据问题或无法解释的 Git 事实时，升级处理。明确要求的审查在证据完整且能容纳时保留为内联形式；否则选择扩展审查，绝不截断。

批准前验证

在批准前完成消息。已检查或结构化的文本必须为 message-ready；原样显示 displayText。直接传输要求主题已知有效。仅在字节发生变化或确认检查失败时重新批准。

在提交任何主题供批准之前，撰写首个提案时，应用受支持的技能消息策略：: 后紧接的描述必须以大写 Unicode 有大小写字母开头；可选的作用域不影响此规则。示例：有效：fix: Tolerate unreachable imports；有效：fix(owl2vowl): Tolerate unreachable imports；无效：fix: tolerate unreachable imports；无效：fix(owl2vowl): tolerate unreachable imports。遇到 SUBJECT_DESCRIPTION_NOT_CAPITALIZED 时，在向用户展示消息前修正，避免仅因大小写问题而再次请求批准。

规范字节必须是严格 UTF-8，且仅含一个 LF。只有在 canUseDirectSubjectTransport() 成功后，直接使用 --message 才可传输 subject + LF。检查文本时，使用事务的固定输入运行 message check。

成功会消耗输入；修订时需重新创建。失败会保留有效状态和被拒绝的输入。自行验证语义。

修订	失效情况与处理路径
仅措辞变更	重新检查／批准文案；复用树和证据
新的语义主张	仅阅读缺失的证据增量，然后使用同一个最终处理器
树／范围变更	开始新的准备流程和批准锚点

根据判断对修订进行分类，不要依据关键词、编辑距离或嵌入。

完成扩展消息

以返回的 reviewRequired 和 nextAction 为准，不要依据队列或阶段是否为空。需要审查时，先不带游标调用 workflow review-next，然后使用精确的 reviewProgress.nextCursor 调用。零个数据包表示已完成；不带游标的重放具有幂等性。绝不要打开队列路径、手动计算工件哈希或检查辅助程序源码。遇到删除、二进制文件／gitlink、损坏或不确定情况时，使用检查恢复。

遵循 nextAction：author-message 使用 messagePath（message-input.txt）和 message check；contentPath 为 null 是预期情况。author-content 使用 contentPath（content.json）、版本化的 contentContract 和 message finalize。保留 schemaVersion、evidenceGroups 和 mode。支持的章节为 Rationale:、User Experience Changes: 和 File Changes:；其他章节必须在批准前解决，并通过精确的 JSON 指针一并修复汇总诊断。详细模式适用于低于 50 个单元且不超过 32 KiB 的内容；否则使用批量模式。出现新的不确定性时，使用固定的 evidence-plan-input.json。如果准备期间未选择结构化撰写，则仅当 route: concise、phase: evidence-ready 时使用 workflow extend --reason semantic-structure-required；否则遵循 nextAction。

对于 evidence-required，遍历有界增量，然后执行最终处理。authoring-pending 表示证据已齐全，但批准字节不可用；较早的修订无法提交。可选检查必须回答实质性未决问题，而非为已验证的标量背书。

提升草稿

只有未更改的草稿才能成为实际提交，且只能通过提升实现。workflow promote 会重新检查附加、分离或零父级未出生的 HEAD 锚点、树／范围和暂存状态；它绝不授权提交。

提交

报告检查要求在准备后、审批前运行 workflow check；切勿重建回执。对于授权失败、偏差或恢复问题，请参阅检查证据。

确认对确切显示的字节以及指定的未通过回执的提交授权。该辅助工具会执行一次记入日志的签名转换，不做裁剪地比较原始提交消息字节，验证完整 OID 并生成报告。切勿改用独立的 Git 步骤：

node <skill>/scripts/commitWorkflow.mjs workflow commit --transaction <opaque-transaction> [--message <transport-safe-subject>] [--verification <required|advisory|skipped>] [--acknowledge-failed-check <receipt-id> ...]

保留被钩子修改过的提交；报告不匹配情况。对于信任、策略或身份限制，请使用签名恢复。日志会保留未知结果，不会重放。

解读、恢复和发布

请参阅退出结果：0 表示成功，1 表示已知拒绝，2 表示输入无效，3 表示已知提交但后续步骤失败，4 表示变更结果未知，5 表示未满足前置条件，6 表示内部失败。保留已知提交，并在结果不确定时恢复，切勿重放。旧版尝试会返回 UNSUPPORTED_ATTEMPT_VERSION，不会进行迁移。

仅当准备过程中断且可恢复时，才使用 workflow resume --transaction <opaque-transaction> 恢复；持久化输入无法扩大范围。对于权限、锁定、阶段部分完成或待处理/未知失败，请使用事务恢复。有限的诊断信息会指向完整的哈希失败日志。通过 workflow report-detail 查询受数量/字节限制的报告路径；重放相同游标或无游标的已完成页面，且仅在需要获取新观察结果时使用 --refresh。

发布前，请确认针对 OID、远程服务和完整目标引用的明确推送授权。重用已将结果 OID 绑定到其树/消息及目标的审批，并按照发布路由进行发现。发布 PR 源分支并不代表集成已完成：

node <skill>/scripts/commitWorkflow.mjs workflow publish --transaction <opaque-transaction> --remote <name> --destination <refs/heads/name> [--retry-after-attempt <prior-attempt-id>]

有见证记录的成功，与恢复时观察到远程状态匹配并不相同。发布结果未知时，切勿自动重试；confirmed-no-live-child 要求用户明确确认进程已结束或主机已重启。单独授权的重试使用 --retry-after-attempt 绑定已解决的不确定状态；对于 reported 拒绝，则省略该参数。对于已知拒绝，可继续执行已获授权的备用方案，无需重复审批。对于拒绝、目标变更、结果未知或事务缺失，请遵循发布恢复。