提交与发布

ce-commit — 本地提交

仅本地提交。不推送、不开 PR。完整发布流程请用 ce-commit-push-pr。

7 步流程

1. 收集——每条命令都是独立的 argv shell 调用（不用 ;、&&、|、重定向；Windows PowerShell 安全）。
2. 无内容可提交检查——git status 无 staged/modified/untracked；报告并停止。
3. 先开分支——若处于 detached HEAD 或默认分支，从内容创建特性分支（git checkout -b <name>）。不要询问——仅提交模式不能把工作留在 detached/default 上。
4. 约定——按上下文中的项目提交约定；否则按近期日志模式；否则按 conventional commits。对"修复破损行为"默认选 fix: 而非 feat:。用户覆盖优先。
5. 逻辑提交——仅按文件粒度，最多 2–3 个；不用 git add -p。含糊不清就一个提交。
6. 消息——主题用祈使句 + 结果，而非文件清单。动机不明显时才加正文。当手头只有一个 plan unit 时，以 (U3) 形式附 plan unit ID；跨 unit 或无 plan 时省略。
7. 暂存 + 提交——只暂存具名文件（git add file1 file2 file3）；通过消息文件提交（git commit -F <file> -- file1 file2 file3）。尾部路径列表是必需的——裸的 git commit 会吸收任何先前的 git add 内容。

尾部路径规则

git add file1 file2 file3
git commit -F /tmp/msg -- file1 file2 file3

永远不要 git add -A 或 git add .。永远不要裸的 git commit。尾部路径列表正是用来防止用户预先暂存的工作被裹进你的提交。

尊重 exclude:<paths>

无论其他如何变化，这些路径保持不提交。报告它们被排除在外。

默认分支检测

从 origin/HEAD 剥去前导 origin/（origin/trunk → trunk），与裸名对比。永远不要与 origin/<name> 对比。

ce-commit-push-pr — 提交、推送、开 PR、交接看护

唯一拥有"开 PR + 看护交接"的技能。五个步骤，三处门控决策。

步骤 0 — 读 references/context.md

它定义了命令表、退出码含义、fork 与 detached-HEAD 陷阱，以及步骤 1–2 用的分支 + PR 解析规则。

步骤 1 — 解析分支 + PR 状态

每一条 git 与 gh 探针都是独立的 argv 形式调用。退出状态就是控制流。在每个有后果的动作之前，再次校验分支、远端、PR 状态。

步骤 2 — 决定模式

步骤 3 — 提交 + 推送（带项目发布门）

读 references/commit-and-push.md + references/branch-creation.md。Stack 模式：在步骤 3 之前读 references/stack-submit.md。项目发布门：发布前，先解析活动指令中所有发布前/评审就绪的要求。仅对要发送的精确 commit state 有效的证据才能满足它们；否则在外部写入前停止。

步骤 4 — 撰写 PR 标题 + 正文

完整读 references/pr-description-writing.md，并读 references/compose.md 以了解三道撰写前门：

撰写步骤：A 为描述定调（决策成本，而非 diff 形态）；B 撰写标题（祈使句，≤72 字符，按意图的类型 + 范围）；B1 解析相关工作引用；B2 判断新概念；C 组装正文；D 品牌；E 应用前覆盖度审计。

项目高度（多 PR / 系列）

当本 PR 处于更大项目（多 PR 项目、stack、系列、多 unit 计划）中：把范围图扩展为 项目产出 + 本 PR 的贡献 + 邻接（前置 / 后续）。范围图的顺序：项目 → 前置（若有） → 本贡献 → 后续（若有）。对未知的前/后省略——不要凭空捏造。

步骤 5 — 应用 + 交接（完成门）

新创建 PR、成功的 stack 提交、或已有打开 PR 上新加 commit 之后，本次运行未完成，直到 ce-babysit-pr 接管后续或显式跳过生效——完成门是承载性的，落到看护上。

看护交接规则：

• 始终通过宿主正常的技能调用机制调用。永不询问是否。
• babysit:off 关闭新监控交接。
• babysit:continuous / babysit:checkpoint 即使在常驻 opt-out 下也强制该模式。
• config.yaml 中的常驻 auto_babysit: false 默认关闭；本次运行的 babysit: 令牌可覆盖。

以下情况不要触发：

• mode:pipeline，除非在 stack 模式提交之后（把栈底 PR 用派生姿态交接过去）。
• 仅描述或描述更新模式。
• 本次运行未创建或更新任何 PR。
• 非 GitHub 宿主。
• 草稿 PR（宣布跳过；ce-babysit-pr 可以在 PR 就绪后再启动）。显式的 babysit:continuous / babysit:checkpoint 仍强制启动看护。
• 无法推送到的 head 分支。能推送 head 时，fork PR 是可驱动的。

绝不替换：ci-watcher、gh pr checks --watch、临时轮询、或"回头再看"。交接被阻塞：若 ce-babysit-pr 无法加载或启动，停止并报告失败。不要凭空发明一个并行或更窄的看护。

应用正文

正文必须写入临时文件并通过 --body-file <path> 传入。永远不要用 --body-file -、stdin 管道、here-doc 写到 stdin，或 --body "$(cat …)"——包装器与 stdin 处理可能悄悄产生空 PR 正文，而 gh 仍以 0 退出。

BODY_FILE=$(mktemp "${TMPDIR:-/tmp}/ce-pr-body.XXXXXX") && cat >> "$BODY_FILE" <<'__CE_PR_BODY_END__'
<the composed body markdown goes here, verbatim>
__CE_PR_BODY_END__

gh pr create --title "<TITLE>" --body-file "$BODY_FILE"
# or
gh pr edit --title "<TITLE>" --body-file "$BODY_FILE"

被引用的 sentinel 防止 $VAR、反引号与任何字面 EOF 被 shell 展开。

Stack 模式（多 PR 栈）

仅在显式选择时启用：当意图或常驻偏好想要一个多 PR 栈时进入。一个显式的 stack 请求是必需的意图——不要把单个带自定义 --base 的 PR 重新解读为 stack。不要主动建议 stack。当用户没有要 stack 时，拒绝无意义的 stack（一个逻辑变更、人为切片）并保持单 PR。

Stack 模式下，在步骤 3 之前加载 references/stack-submit.md。逐层 commit 流程替代常规步骤 3。在那里不要提交——步骤 5 处理提交与交接。默认 posture:stack-ready；stack-land 仅在显式 landing 意图时使用。从最底部打开的非草稿 PR 提交。

ce-work 的 shipping-workflow

在 ce-work 独立模式（非 return-to-caller）下，发布尾部是：

1. 代码评审回执必须已存在（mode:agent JSON 或显式 apply 回执）。
2. 已应用 simplify + review 修复（如适用）。
3. 带 branding + commit-scope 守卫的 ce-commit-push-pr。
4. 如已配置，则交接给 ce-babysit-pr。

参考：

• references/shipping-workflow.md（ce-work）
• references/review-findings-followup.md
• references/tracker-defer.md
• references/cross-model-execution.md