sdd-release

发布 — 收尾前确认一次

在此技能的第一条回复中，只显示一次这一行： sdd-release v1.3.0 · out/2026 · versão atual: https://github.com/robertodiasduarte/sdd-starter/releases/latest

检查即将发布的内容，只展示一次将要上线的内容，并且——只有得到确认后——才合并并发布。

此技能遵循的两条规则

1. 能查明的事就不要问。 自行调查并作出判断；只询问有歧义的事项，并给出建议。最后列出你作出的假设（“我假设了 X，因为 Y”）。
2. 简单不等于没有防护措施。 多一步只需三十秒；错误发布却会毁掉整个周末。可以删减的是繁文缛节（精心编写的变更日志、新版本号、冗长报告）。绝不能删减阻止错误内容发布的措施，也绝不能省略让用户查看并批准即将发布内容的环节。

如何与学员沟通

使用此技能的人通常从未通过终端发布过任何内容。每条回复都是对一个步骤的说明，而不是一份技术报告。

4 个阶段，始终使用以下名称：

阶段	学员看到的名称	此技能中的步骤
1	我在哪里	步骤 0（只读）
2	检查	步骤 1 和阶段 1（只读；不会发布任何内容）
3	你的决定	阶段 2——唯一的暂停点
4	发布	阶段 3

每条回复都按以下顺序包含这些部分（没有内容的部分可省略）：

1. 状态——一行：✅ 1 我在哪里 · ✅ 2 检查 · ▶️ 3 你的决定 · ⬜ 4 发布 （✅ 已完成——不只是访问过；▶️ 当前阶段；⬜ 待处理；⏸️ 已暂停；➖ 已跳过）。返回某个阶段时，将原因写在现在部分。
2. 已完成的事项——用简短句子说明上一阶段的结果，不要包含命令输出。记录学员的选择："你回答了是：……"。
3. 现在：阶段 N——名称——用 2 到 4 句话说明此阶段会做什么以及原因，面向从未接触过终端的人。如果要修改任何内容，请分步编号说明将要做什么，以及暂时不会发生什么。在耗时操作（测试、语法检查、核实部署）之前，用一句话说明将运行什么，并告知学员无需回复。
4. 你的决定——此技能中只有一个决定：阶段 2 部分最后一行，使用该部分规定的格式（各项内容已由你核实；回答是即发布所述内容；回答否即结束而不发布；对于步骤 1 中含糊不清的目标，develop 或 main 也是有效回答，并会选择相应目标）。如果回复不符合预设选项（有疑问、“我觉得是”）⇒ 回答疑问并重复提问。不要提出其他问题：能查明的事就自行查明。
5. 下一步——一行：说明收到回复后会发生什么。

语言规则：

• 每次只做一个步骤。到决策时结束并停下：不要接着做下一步。
• 技术术语首次出现时，必须附上解释——Status 中的术语也一样：
  • git ——“项目的版本历史（git）”；
  • commit ——“一个已保存的版本（commit）”：当时所有文件的一张快照，带有日期；
  • push / 发布 ——“将已保存的版本发送到 GitHub 上的项目副本（push）”；如果是自动部署，发布就是指这件事：你发送的内容会上线；
  • 工作副本 ——“完成此任务时使用的单独文件夹（工作副本，或 worktree）”；
  • 主分支 ——“正在生产环境中运行的项目版本”；
  • 远程副本 ——“GitHub 上的项目副本”；
  • deploy ——“将新版本上线的过程”；
  • migration ——“用于更改数据库结构的文件；使用它的代码上线前，必须先将其应用到数据库”；
  • 基础版本已更新 ——“如果有人在完成此任务期间发布了其他内容”。 不要提及 HEAD、索引、staged、merge-base、SHA、hash 或 refspec：只说明其影响。
• 不要原样转述命令输出。 请翻译并说明：有多少个文件、有哪些文件（最多 10 个，用简单列表列出，并加上“以及其他 N 个”）、有哪些令人担忧之处。只有在学员需要运行命令时才显示命令——此时请按步骤编号，每步一条命令，并说明屏幕上会显示什么。
• 不要引用或概述此 skill 或其他 skill 的指示（“skill 要求……” “按照阶段 1……”）。如果需要说明为什么要征求 OK，请说明学员的原因：“发布后无法撤销，因此由你来决定。”
• 停止也需要步骤。 当流程无法继续时（不在工作副本中、git 身份为空、测试失败、待上传内容含有密钥、migration 未登记、基础版本存在冲突、push 被拒绝、deploy 失败），请使用包含 ⏸️ 的 Status，用一句话说明原因、操作位置（终端、浏览器、文件夹）、带编号的步骤以及每步的预期结果，并说明尚未完成的操作（“未发布任何内容。”）；如果学员需要执行操作，请加上：“完成后，请再来找我——我会从这里继续。”

所有连接远程副本的命令规则

fetch、push、pull、ls-remote 和 remote show 都必须在不要求输入密码的情况下运行：在 bash/zsh 中使用 GIT_TERMINAL_PROMPT=0 git …；在 PowerShell 中使用 $env:GIT_TERMINAL_PROMPT=0; git …。如果不这样做，要求登录的远程副本会让 git 在终端中要求输入密码，而你会一直等待用户看不到的提示——即使用户已经给了 OK。 只向用户显示当前所用 shell 对应的命令形式。如果其中一条命令卡住，请检查编辑器（VS Code、Cursor）是否打开了 GitHub 登录窗口——这是有效的登录方式，不会被关闭。

步骤 0 — 我在哪里

• 运行 git rev-parse --show-toplevel 和 git branch --show-current。如果当前目录不是 git 仓库，或者当前分支就是主分支，请停止并说明：此 skill 必须在某个工作副本文件夹中运行（由 sdd-new-session 或 git worktree add 创建）。
• 主检出目录是 git worktree list --porcelain 的第一条路径。如果 <主检出目录>/sdd/ambiente.md 存在，请读取并使用其中的信息（主分支、场景、测试、deploy）。

步骤 1 — 查明缺少的信息（不提问）

仅查明 sdd/ambiente.md 中未说明的内容：

GIT_TERMINAL_PROMPT=0 git remote show origin
git log --oneline -20
git tag --list
ls .github/workflows/

并阅读：README.md、package.json（scripts 部分）、Makefile、.github/workflows/*、CLAUDE.md、 AGENTS.md。

• 主分支 — 远程仓库的“HEAD branch”。
• 代码如何进入生产环境 — 最重要的发现。请如实说明：
  • 自动部署：某个工作流在推送到主分支时触发 ⇒ 推送就是部署。
  • 手动部署：存在发布命令（npm run deploy、make deploy 或某个脚本）。
  • 无：仓库只存放代码 ⇒ “发布” = 合并到主分支，不要假装已经发布。
• 测试（npm test、pytest、CI 任务）以及语法检查，针对已修改的文件执行 （node --check、php -l、python -m py_compile、tsc --noEmit）。
• 版本管理（v* 标签、package.json 中的 version、CHANGELOG.md）。如果没有这些内容， 不要编造：没有版本号的项目在发布时不会获得版本号。
• 场景（与 sdd-new-session 相同）：直接提交到主分支 ⇒ A，Trunk-Based （以推送到主分支结束）；合并 PR ⇒ B，GitHub Flow（以向主分支发起 PR 结束）； 版本标签以及 release/* 或 hotfix/* 分支 ⇒ C，GitFlow（以向 develop 发起 PR 结束）—— 与 sdd-new-session 使用相同的判断标准。若无法确定是 A 还是 B，则选 A。如果远程仓库存在 develop，但不符合 C 的标准，不要自行决定：OK 代码块的最后一行改为 “可以发布到 <recomendada> 吗？（回复 develop 或 main 以切换）”——仍然只提一个问题。 回复的目标将成为第 3 阶段的 <alvo>：develop ⇒ 此前端遵循场景 C 的路径（推送分支 + 向 develop 发起 PR），绝不能直接推送到主分支。
• 集成分支 — 此前端将合并到哪里：场景 A 和 B 为主分支，场景 C 为 develop。从此处开始，<alvo> 即为该分支。将场景 C 的前端与主分支比较或集成，会把仍在开发中的内容带入生产环境。

将查明的信息写入主检出目录中的 sdd/ambiente.md（键为 deploy、testes、sintaxe、 versionamento、banco）；如果文件不存在，则按 sdd-new-session 的格式创建。键 banco 通常已由 sdd-build 在应用 migration 时写入（工具 · 项目名称和 ref · 如何应用 · 如何验证）；没有数据库的项目 ⇒ - banco: nenhum。

阶段 1 — 验证（自行执行，不提问）

这里的所有操作都在本地进行且可撤销。按此顺序执行，首次失败时停止： 0. Git 身份信息。 git config user.name 和 git config user.email——两项都必须已填写。缺少任何一项？请停在这里，提示用户运行命令 git config --global user.name "Seu Nome" 和 git config --global user.email "[email protected]"：第 3 阶段的提交会在用户确认 之后 失败，而用户批准的内容将无法推送。

1. 究竟要推送哪些内容——包括尚未提交的内容：
   • git status --short --untracked-files=all——相对于最后一次提交的已修改和新增文件（??，每个文件单独列出，绝不能把整个文件夹合并显示）。 这是第 3 阶段的提交清单，包括已提交、之后又在工作区中撤销的文件（它不会出现在下面的摘要中，但必须纳入提交，撤销操作才会生效）。
   • git diff --stat $(git merge-base origin/<alvo> HEAD)——将当前工作区与当前分支的基准进行比较：涵盖当前分支的提交以及尚未提交的更改。
   • 不要只用 git diff origin/<principal>...HEAD：它会忽略尚未提交的内容；如果当前分支没有提交，还会显示空摘要——用户批准的内容就与实际推送的内容不同。
   • 不属于当前分支的文件？停下并展示给用户——不要擅自决定哪些内容应排除。例外情况是非当前分支内容且绝不会纳入提交的未跟踪 skill 文件夹（.claude/skills/…、.agents/skills/…）：sdd-new-session 会复制这些文件夹，以便当前分支正常工作。
   • 是否有 staged 文件，其版本与工作区中的版本不同（同一个文件同时出现在 git diff --cached --name-only 和 git diff --name-only 中）？停下并展示给用户：采用哪个版本是用户的决定，未让用户查看前，不能丢弃任何一个版本。
   • 推送内容的指纹——保存 git rev-parse HEAD（固定 push 将发送的历史记录）、git diff <base> | shasum 的结果、git diff --cached | shasum 的结果（已 staged 的内容），以及每个新增文件（??）的 shasum；在 PowerShell 中使用 Get-FileHash。其中 <base> 为 $(git merge-base origin/<alvo> HEAD)。这是用户批准的内容；第 3 阶段提交前会进行核对。用户确认后重写提交，即使最终内容相同，也会改变 HEAD。
2. Migration 和数据库必须同步。 如果要推送的内容（第 1 项中的 diff 和新增文件）包含 *.sql 或 migrations/ 中的内容，则必须确认 migration 已应用：在 sdd/ambiente.md 中填写 - banco:，并且在当前分支的 BUILD_REPORT 中填写 ## Migrations aplicadas，列出相应文件（或注明“已于 应用”）。缺少任何一项？请在 OK 确认块之前停下，说明缺少哪一处及其路径：按照 sdd-build 第 11 步应用 migration（确定项目、确认名称和 ref、应用、通过读取进行验证，并写入两处记录）。反过来也要停下：migration 已记录为已应用，但要推送的内容中没有 .sql 文件（该文件被排除在提交之外）⇒ 对该文件运行 git add，然后重新运行 sdd-release。发布调用了数据库中不存在的列的代码，或发布了更改后的数据库却没有把对应文件纳入仓库，这两种情况都会导致 git 和数据库不一致。
3. 对修改过的文件检查语法，使用步骤 1 中的工具。
4. 测试，如果有测试。测试失败则所有内容都不予通过：批准测试未通过的 diff 会让 OK 沦为盖章程序。
5. 检查密钥泄露——检查所有要推送的内容，而不是整个仓库：已修改文件的 diff，以及每个新增文件（git status 中的 ??）的完整内容；新增文件不会出现在 git diff 中，但会被提交。检查 API 密钥、token、密码、意外纳入版本控制的 .env 文件：例如带有字面值的 API_KEY=、SECRET=、PASSWORD=、TOKEN= 赋值、服务商密钥前缀以及 PRIVATE KEY 块。还要检查当前分支的历史记录（git log -p <base>..HEAD）：如果密钥在一个提交中加入，又在下一个提交中移除，它会从聚合 diff 中消失，但 push 仍会发送这两个提交。若在历史记录中发现密钥，请停下：重写历史记录必须由用户决定，绝不是此 skill 的决定。密钥一旦发布就无法撤回，即使之后删除提交也一样。
6. 基准分支有更新吗？ 运行 GIT_TERMINAL_PROMPT=0 git fetch origin <alvo> 和 git rev-list --count HEAD..origin/<alvo>。现在不要整合更新：此处运行 git merge 会在用户确认前创建提交（而且工作区有未提交更改时会拒绝操作）。只记录“基准分支前进了 N 个提交”，并写入 OK 确认块；第 3 阶段会整合最新基准分支，并在任何 push 之前重新运行测试。 如果任何一项失败：停止，说明哪一项失败、涉及哪个文件以及原因，然后不要继续。 不要自行修复， 也不要“即便如此”还请求 OK。在该回复中，不要提及 OK 区块或“可以发布吗”这个问题， 也不要把它们作为后续步骤：以需要修正的内容和“然后，再次运行 sdd-release”结束。 读者看到回复末尾的问题，就会明白你在请求 OK。

阶段 2 — 唯一的停止点

在区块之前，回复中的现在部分用两句话说明如何作答：“我已核对以下字段；你只需回复最后一行。 是表示按所述内容原样发布；否表示结束且不发布——不会有任何内容离开这里。” 然后，只展示一个区块，格式如下 （填写内容；不要添加问题）：

**O que sobe**
<quantos arquivos mudam e quais, pelo nome, em palavras — traduzido do resumo comparativo da Fase 1 (o
--stat contra a base, que inclui o que já foi commitado na frente), mais os arquivos novos marcados como
novos; até 10 nomes, "e mais N"; nunca a saída do --stat colada. O git status da Fase 1 é a lista do que
ainda precisa entrar no commit, não o que sobe>

**O que muda em produção:** <uma frase, em português — "muda o cálculo do relatório mensal da tela
inicial", não "altera handler.js">

**O push publica sozinho?** <sim, o workflow X publica ao receber o push na main | não: <por quê>>

**O deploy espera os testes?** <sim — os testes rodam no mesmo job, antes da publicação (ou: o job de
publicação tem `needs:` no de testes) | não — o workflow X publica sem esperar os testes do Y: um teste
vermelho não impede a publicação | não se aplica: o push não publica>

**Banco:** <migration `<arquivo>` aplicada em `<projeto nome (ref)>` em <data> | sem migração nesta frente>

**Verificações:** sintaxe <ok|pulada: motivo> · testes <ok|pulados: motivo> · segredo <nenhum, no
diff e nos arquivos novos> · base <atualizada | andou N commits: será integrada e testada de novo antes do push>

<só se não houver revisor humano:> Antes de responder, vale pedir à IA uma revisão do próprio código:
"isso quebra algo que já funcionava, expõe alguma senha, tem erro óbvio?"

**Posso publicar?**   ← ou "Posso publicar na <alvo>?", no único caso do destino ambíguo (Passo 1)

• 明确说明缺少某项核验，是在提供信息；保持沉默，则会造成虚假的安全感。
• **“数据库：”**来自阶段 1 第 2 项中核对过的两条记录（sdd/ambiente.md 中的 - banco: 和 BUILD_REPORT 中的 ## Migrations aplicadas）——这是陈述，不是问题。如果本次变更没有 .sql 文件， 则填写“本次变更无迁移”。
• **“部署是否会等待测试？”**通过查看 .github/workflows/* 来确认：测试是否与发布步骤位于同一个 job 中且在其之前，或者发布 job 的 needs: 是否指向测试 job？带有 continue-on-error: true、|| true 或始终以 exit 0 结束的测试 step，不会阻止发布——应填写“否”。这是陈述，不是问题：由你填写，用户无需回答。
• 区块中唯一的问题是最后一行“可以发布吗？”（如果步骤 1 中目标仍不明确，则写“可以发布到 <alvo> 吗？”）。此行之前带 ? 的各行只是供你填写的标签——“一个问题”指的是要求对方作答的请求，而不是问号的数量。审核建议是一个陈述句，不是问题——如果将其改成“要我先审核吗？”，就会造成第二个停止点，而两个停止点就成了走过场。
• 如果有任何内容不明确（哪个文件属于本次变更），请在同一个区块内、最后一行之前说明——绝不能停两次。
• 没有 OK，就到此为止：不执行 commit、merge 或 push。

阶段 3 — 发布（仅在获得 OK 后）

1. 文件夹仍然是已批准的那个吗？ 重新计算阶段 1 的指纹。若不同 ⇒ 在批准后有内容发生变化：停止，展示变更内容并请求重新批准——绝不要提交未检查过的内容。
2. 逐个提交指定文件——必须与阶段 1 的 git status 列表完全一致，不得包含其他文件。不要重置暂存区（这会删除不在文件夹中的暂存版本）。运行 git add 后，git diff --cached --name-only 必须与该列表完全一致——如果出现其他已暂存文件，提交前停止。提交后，git status --short 应为空——未纳入版本控制的 skills 文件夹除外，它们是有意排除的。 绝不要运行 git add -A，也绝不要运行 git add -u：同一台机器上有两个工作区同时打开时，这些命令会把另一个工作区的工作也带进来。
3. 基线已更新，并重新测试。 如果基线有更新：运行 GIT_TERMINAL_PROMPT=0 git fetch origin <alvo>，在工作区运行 git merge origin/<alvo>，然后重新运行测试。若有冲突或测试失败，在任何推送之前停止，说明出了什么问题——没有任何内容已发布。
4. 始终从工作区开始，按场景集成：
   • A（主干开发，<alvo> = 主分支）：GIT_TERMINAL_PROMPT=0 git push origin HEAD:<principal>。推送从工作区发起，其中恰好包含已批准的内容和远程基线——绝不要从主分支的检出目录推送，否则可能会连同无人批准的本地提交一起推送。若因基线有更新而被拒绝（non-fast-forward/fetch first），返回第 3 项（绝不强制推送）。若因权限问题（403、Permission denied、could not read Username）或受保护分支（protected branch、GH006）而被拒绝，停止并按以下顺序说明需要检查的事项：gh auth status（是否已登录，且使用的是正确的账号？）；你在仓库中的角色（发布需要写入权限）；以及主分支是否受保护——若受保护，应采用场景 B 的流程（推送分支并创建 PR），不要继续尝试直接推送。
   • B（GitHub Flow）：运行 GIT_TERMINAL_PROMPT=0 git push -u origin <branch-da-frente>，并向主分支创建 PR（如果有 gh，运行 gh pr create；如果没有，以上推送命令会打印可在浏览器中打开的 PR 链接）——到此为止。PR 经审查后合并，才算完成集成。
   • C（GitFlow）：运行 GIT_TERMINAL_PROMPT=0 git push -u origin <branch-da-frente>，并向 develop 创建 PR（流程与 B 相同，有无 gh 均可）——到此为止。工作区分支不会直接合并到主分支。
5. 如需手动部署，只能从已完成集成且已更新的主分支部署——绝不要从尚未发布的工作区分支部署。部署必须在与已发布内容完全一致的工作树中运行：场景 A 中，使用推送成功后的工作区本身——检查 git status --porcelain 为空，并且 git rev-parse HEAD 与 git rev-parse origin/<principal> 相同（运行 GIT_TERMINAL_PROMPT=0 git fetch 后）；若不一致，停止。绝不要从主分支的检出目录部署，因为那里可能有本地变更或无人批准的提交。场景 B 和 C 中，提供部署命令，要求在 PR 合并之后再运行；不要提前执行。（如果部署是自动的，推送到主分支后就会发布。）
6. 根据你发布的提交确认部署成功，而不是看最近一次运行。 不要因为命令没有报错就说“已发布”。如果通过工作流部署且有 gh：
   • gh run list --commit <SHA publicado> --branch <principal> --json databaseId,status,conclusion,workflowName,event（PowerShell 中也相同）。查看主分支上负责发布的工作流运行记录（event = push；若通过下方所述方式手动重新触发，则为 workflow_dispatch）——不要看通用列表中最新的记录（连续推送两次时，它可能属于另一个提交），也不要看同一 SHA 在其他分支或 PR 上的运行记录，因为这些记录可能跳过部署。
   • completed + success ⇒ “已上线：你的提交 <sha curto> 的部署已完成（运行 N）。”
   • queued 或 in_progress ⇒ 等待后再次检查；此时尚未上线。
   • 列表为空 ⇒ GitHub 尚未登记该次运行：等待几秒后重新查询；约 2 分钟后仍为空 ⇒ 说明未找到该提交对应的运行记录——绝不要说“无需检查”。场景 B 和 C 中，合并 PR 后到达主分支的 SHA 是合并提交的 SHA：请查询该 SHA。
   • cancelled ⇒ 如果有队列，较新的推送可能已取代你的提交。运行 GIT_TERMINAL_PROMPT=0 git fetch origin <principal>，然后运行 gh run list --workflow <arquivo do workflow> --branch <principal> --limit 20 --json databaseId,headSha,status,conclusion,createdAt。 只有在你的提交之后创建、状态为 success，且其对应提交包含你的提交的运行记录才有效（git merge-base --is-ancestor <seu SHA> <SHA dele> 返回 0）⇒ “你的提交 <sha> 已包含在 <sha dele> 的部署中（运行 N）。”返回 1 = 该次运行不包含你的提交（继续查找其他运行记录或等待）；任何其他返回码（未找到提交）= “无法确认”——绝不要说“未包含”。
   • failure ⇒ 说明失败原因。若要重试部署，绝不要对旧的运行记录执行 gh run rerun：有队列时，它会在较新的推送之后运行，并用旧代码覆盖新代码。应在最新版本重新触发（如果工作流支持手动触发，运行 gh workflow run <arquivo> --ref <principal>），或进行一次新的推送。
   • 绿色状态不代表测试通过：如果测试步骤设置了 continue-on-error、|| true，或总是以 exit 0 结束，请说明“部署已完成，但工作流在发布前未运行测试”——不要加 ✅。 有 URL 吗？检查它是否有响应。没有 gh 或无法确认？如实说明：“已发布，但无法自动验证”；没检查过就说“✅ 一切正常”，是不诚实的。
7. 检出主分支并清理，以命令形式提供（在工作树内部无法删除自身）：在主分支的检出目录中运行 GIT_TERMINAL_PROMPT=0 git pull --ff-only——如果命令拒绝执行，说明本地主分支有尚未发布的提交；你不要替用户解决。然后运行 git worktree remove "<pasta>"（务必加引号：路径可能包含空格），再运行 git branch -d <branch>（小写 -d 只会删除已集成的分支）。场景 B 和 C 中，应在 PR 合并后再清理。 最终回复：Status 已完成 ✅，以及三行内容——发布了什么、在哪里、还缺什么。

本技能不包含什么（以及原因）

• 详尽的变更日志——如果项目已有 CHANGELOG.md，写一行即可。如果没有，就不要创建。
• 新增版本管理——目前不进行版本管理的项目，不会从这里开始进行版本管理。
• 冗长的最终报告——三行即可。
• 绝不使用 --force，无论如何都不行。Push 被拒绝意味着基础版本已有更新：请拉取并集成， 绝不要强行覆盖其他人的工作（或你昨天自己的工作）。
• 绝不设置第二个暂停点——两个暂停点会变成例行打卡：人们会停止阅读。

每条规则存在的原因

• 先确认 OK，再 push：启用自动部署后，push 之后就没有可返回的“之前”状态了。
• git add 明确指定文件：同时开展两项工作时，-A 会发布尚未完成的那项工作。
• 先检查基础版本，再于 OK 后集成：如果另一项工作先合并，测试通过时所针对的状态就已不存在；但在 OK 之前集成又会创建一个未经任何人批准的提交。因此：在阶段 1 检查，在阶段 3 集成并重新测试，然后再 push。
• 从工作分支 push，而不是从主 checkout push：主 checkout 中可能有尚未通过 OK 的本地提交。
• 摘要涵盖尚未提交的内容：提交发生在 OK 之后，因此获批内容必须包括仍只存在于文件夹中的内容。
• 在 OK 之前检查身份信息：提交只会在阶段 3 发生；如果没有姓名和电子邮件地址，提交会在用户已经批准之后失败。
• 提交中的 migration 与已应用的 migration 必须同步：push 发布的是代码，而不是数据库。如果不进行检查，自动部署就会发布调用不存在列的代码——而 OK 确认区块会说“push 会自动发布吗？会”，仿佛这样就够了。
• 通过 SHA 检查部署：连续进行两次 push 时，“最近一次运行”属于另一个提交，而另一个提交的绿色运行对你的提交毫无说明。
• 绝不对旧部署运行 gh run rerun：重跑会使用该运行对应的提交——如果任务排队，它会在更新的 push 之后运行，并用旧代码覆盖新代码。
• 本技能从工作分支内部运行，无法在结束时删除自己的 worktree——清理由主 checkout 负责。

---

摘自 SDD Starter by RDD — https://github.com/robertodiasduarte/sdd-starter