docs-stack-release

文档发布问题（elastic/dev 中的 [Docs release] X.Y.Z）是事实来源，而不是工程团队的 [Release] 问题。创建缺失的文档问题（§1.1），或向用户收集日期。缺失的问题 URL：(issue TBD)。

操作手册： v9 -- v8。模板： 次要版本 -- 9.x 补丁版本 -- 8.x 补丁版本。

系列	仓库	配置文件	部署监控
9.x+	elastic/docs-builder	config/assembler.yml, config/versions.yml	docs-internal-workflows 升级 PR + 生产环境版本升级（§0.3）
8.x / 7.x	elastic/docs	shared/versions/stack/*.asciidoc, conf.yaml	无 -- 不要使用 docs-internal-workflows

不变规则

• ID、日期、PR URL、@提及：必须来自 gh、文档问题、Slack 或用户。绝不可编造。缺失时 → (issue TBD) 或 [@handle] 并询问。
• 不要在一个 PR 中混合 8.x 和 9.x。8.x/7.x：仅使用 elastic/docs；不要使用 docs-internal-workflows。
• 检查清单是步骤索引。仅实时查询未完成的工作。RN 合并不是复选框——始终对阻塞性 RN URL 运行 gh pr view。
• RN 表中的 PR URL 在合并前都具有阻塞性。仅跳过 No changes / N/A。不要按名称豁免 Fleet、Agent 或任何产品。
• 勾选本技能刚刚完成的项目。不要勾选他人完成的工作（包括 docs-eng）。不要等别人要求。
• Slack：起草或发送前，先阅读 slack-templates.md。发送前确认；在 FF 公告的线程中跟进。
• 仅在关卡（§0.3）通过且用户检查过网站后，才能发布 Slack 消息。关卡通过前不要起草。
• 参数为空 / “我的发布进展如何”：会话状态 → 活跃的文档问题。如果有正在进行的版本发布，不要询问版本。关闭问题清理后若没有剩余问题，则停止——不要重新查找。
• 清理 = 文档问题状态为 CLOSED。404 = 丢弃该 ID 并重新查找。无 TTL。
• RC 因每次发布而异——从 #mission-control 协调线程或工程问题中读取。绝不要硬编码名称。
• 不要提出发送 Slack 提醒或创建 PR（其问题复选框已勾选），也不要提出用户已表示自己发送过的内容。

---

输入

$ARGUMENTS 是以空格分隔的语义化版本号和/或 elastic/dev 问题编号列表（例如 9.4.0 9.3.4 8.19.15 或 #1234 #1235）。如果为空：加载会话状态（§0.1）。如果其中有活跃发布（预定日期为今天、过去 2 天内或明天，且文档问题状态不是 CLOSED），则使用该发布。否则询问用户。

“我的发布进展如何” / “我的发布进行得怎么样”（未提供版本）：按空参数状态处理。加载会话状态并运行 §0。如果会话状态中有活跃发布，不要询问版本。如果清理后没有剩余版本，则说明已跟踪的问题均已关闭，并停止。

将用户请求匹配到相关部分（状态、PR、提醒）——用户可能会跳过完整流程。

---

0. 检查状态（每次调用都运行）

已知版本或问题编号时（来自 $ARGUMENTS 或会话状态），在提出操作建议前检查状态。

0.1 会话状态（快速通道）

路径： ~/.elastic-docs/stack-release-state.json。本地协调器缓存——切勿提交。

每次调用时：

1. 读取文件。如果文件缺失、无法读取、JSON 无效、没有匹配的版本，或用户说“重新开始”，则回退到临时状态。
2. 缓存的仅 ID用于跳过发现：docsIssue、engIssue、coordinatorPrs.{repo:{number,sha,url}}、rnPrs[].{product,url}、slack.{docsChannelId,docsFfThreadTs,missionControlChannelId,coordinationThreadTs,beginPublishingTs,handles}、deploys（仅限 9.x：configSha、stagingBumpPr、prodBumpPr、stagingRunId、prodRunId）。还有 line、type、anticipatedDate。
3. 仅实时刷新文档 issue 中仍未完成的内容（§0.2）。不要对已勾选的行重新运行 gh pr view / gh run view。始终实时刷新 RN PR 的合并状态（表格存储的是 URL，而不是合并状态）。绝不要依据缓存的 JSON 判断合并/部署结论；但可以信任已勾选且引用了 PR 或运行 URL 的 issue 行。
4. 缓存 ID 返回 404 / 缺少消息时，丢弃该字段，只重新发现该部分。在 Buildkite/机器人父级消息（begin publishing、release build declared）上，slack_read_thread 返回空内容不代表 404。
5. §0 结束时：丢弃已关闭的文档 issue，然后写入或删除文件。

deploys 仅限 9.x。8.x / 7.x 不要包含此项。

已关闭 issue 清理： 只有 state 为 CLOSED 时才算完成。本轮报告状态，然后从 releases 和 active 中移除该版本。issue 仍为 OPEN 时，即使已 announced 也不够。404 不代表已完成——丢弃 docsIssue 并重新发现（步骤 4）。

• 仍有部分版本未关闭： 写入剩余条目和当前的 updatedAt。说明移除了哪个版本。
• 没有剩余版本： 删除该文件。不要写入 { "active": [], "releases": {} }。说明本地状态已清除。

0.2 从文档 issue 确定阶段（在额外获取前执行）

读取会话状态后，第一次 GitHub 调用必须是 gh issue view。立即解析复选框，并跳转到对应阶段。不要遍历 §1–§5。不要重新验证已勾选的行。

gh issue view <N> -R elastic/dev --json body,state

如果 issue 显示	阶段	仅实时获取
文档 issue CLOSED	完成 / 清理	无。报告已关闭，然后执行已关闭 issue 清理（§0.1）。
发布前一天的提醒或协调器 PR 复选框未勾选	发布前	搜索协调器 PR（如果没有缓存的编号）+ RN 表格 URL。跳过 #mission-control 和 §0.3。
协调器 PR 已勾选，合并 RN 提醒未勾选	等待通知写作者	RN PR 状态 +（仅发布当天）缓存的 #mission-control 线程。
配置合并 / 生产 bump（9.x）/ elastic/docs PR（8.x）未勾选	等待发布基础设施	该 PR/部署（9.x 参见 §0.3）+ RN PR 状态 + 缓存的 #mission-control 线程。
生产 bump 行已勾选且带有运行 URL（9.x），或 elastic/docs 合并已勾选（8.x）	等待 RN / 发布公告	**仅 RN PR 合并状态。**跳过协调器 gh pr view、bump PR、gh run view。
网站确认和 #mission-control 实时复选框已勾选	已发布公告	报告完成。除非用户要求，否则不要额外获取信息。

**RN 合并状态从不作为复选框。**始终对每个阻塞中的 RN URL 运行 gh pr view。

如果已勾选行引用的 URL 返回 404，只重新发现该行对应的信息。

利益相关者确认（§ 下文）：仅在某一行仍有占位符、“指定负责人”的脚注，或有 2 位及以上具名人员时执行。若每行都已有一位具名利益相关者，则跳过 #docs FF 线程搜索。

GitHub 状态

如果会话状态中有文档 issue 编号，直接运行 gh issue view 查看。否则搜索 [Docs release] <version>。如果 issue 或会话状态中已有协调者 PR URL，不要按版本运行 gh pr list。

仅当 §0.2 仍需要查找协调者 PR 时才搜索，且只在对应版本线的仓库中搜索（9.x → docs-builder，8.x → docs）。对于仅涉及 9.x 的批次，绝不要在 elastic/docs 中运行 gh pr list。

gh pr list -R elastic/docs-builder --search "<version>" --json number,title,state,url
gh pr list -R elastic/docs --search "<version>" --json number,title,state,url

• **Issue 复选框：**如果某项尚未勾选，但此技能已完成该事项（例如你发送了 Slack 消息或打开了 PR），现在使用 §4 将其勾选。无需询问。不要勾选此技能未完成的事项。
• **RN PR 状态：**对 Release Notes 表格中的每个 PR URL，使用一个 shell 循环：

gh pr view <url> --json state,mergedAt,title

**跳过与阻塞：**仅跳过 No changes / N/A。PR URL 都会造成阻塞，直到合并为止——不要按名称豁免 Fleet、Agent 或任何其他产品。已具名的相关方就是负责人；具名行后不要添加 ?。

报告：已合并 X/Y 个（跳过 N/A 行），尚有 Z 个未完成。所有阻塞的 RN PR 合并后，报告："All RN PRs merged."

然后，按版本线处理——仅当 §0.2 显示发布基础设施仍未完成时：

• 9.x：docs-builder 协调者 PR 合并且prod-bump issue 行仍未勾选后，继续执行 §0.3。如果该行已勾选且附有运行 URL，则跳过 §0.3。
• **8.x / 7.x：**跳过 §0.3。配置位于 elastic/docs 中。无需在 docs-internal-workflows 中更新版本或部署。

确认相关方分配

仅当某一行仍需确认时才执行（§0.2）。适用情况：反引号占位符（例如 `Beats point person`）或“指定负责人”的脚注；有 2 位或更多具名人员且其中一位已在讨论串中确认；具名相关方不在岗，且其他人已确认代为负责。

1. 查找 FF 公告讨论串（在 #docs 中使用 slack_search_public 搜索该版本，然后使用 slack_read_thread）。
2. 扫描回复：“I can handle [product]”、“I'll do [product]”、“I'm drafting the X.Y.Z [product] release notes”或明确表示代为负责。
3. 通过 issue 附录查找表，将 Slack 显示名称反向对应到 GitHub 用户名。如果查找表中没有，使用 slack_search_users，并询问用户 GitHub 用户名。
4. 更新 issue 正文（§4）：替换占位符、将负责人缩小到已确认的人选，或改为代为负责的人选。
5. 报告：“已更新 [Product] 相关方： [old] → @new-handle（已在讨论串中确认）。”

未获确认：保持原样并标记出来。不要猜测。表述含糊（例如只说“我可以帮忙”，未说明产品）：询问。

#mission-control（仅限发布日）

如果会话状态中有讨论串时间戳，先对其使用 slack_read_thread。

不要对整个 #mission-control 使用 slack_read_channel。不要在没有版本号且没有 after: 当日日期的情况下，使用 slack_search_public 搜索 "begin publishing"。

beginPublishingTs / releaseBuildDeclaredTs 对应的空讨论串是预期情况，因为 Buildkite 机器人会发帖。以父消息为准；不要重复查找。

仅当缺少必需的缓存时间戳时才搜索（而不是仅因为讨论串为空）：使用类似 9.5.2 in:#mission-control after:YYYY-MM-DD 的 slack_search_public 查询，限制 5 条。

与所跟踪版本匹配的信号（在状态报告中为每个讨论串添加链接）：

1. 协调讨论串：“Coordination for ... release, scheduled on”——安排时间、谁是 RC（绝不要自行假定）以及回复中的日程变更。
2. “release build declared”：“We are officially declaring X.Y.Z as the release build”。
3. “begin publishing”：“All pre-finalize steps for X.Y.Z are complete. Please begin the publishing process.”——文档操作触发信号。阅读讨论串，确认 RC 本人是否表示继续或暂停（参见第 1 步）。

0.3 关注 docs-internal-workflows（仅限 9.x）

8.x / 7.x 请跳过本节。 不要搜索该仓库，不要轮询 bump PR 或版本 bump 运行，也不要要求 8.x 的线上消息必须有生产版本 bump。

如果文档议题已勾选“关注生产版本 bump 部署”这一项（或类似表述），并附有成功的生产运行 URL，请跳过 §0.3。不要重复列出 bump PR 或重新查看运行。

对于 9.x，在 docs-builder 协调者 PR 合并且该议题中的相应项目仍未勾选时：

协调者会合并 docs-builder 配置 PR，并关注生产版本 bump。无需等待文档工程团队。合并协调者 PR（配置 SHA = 合并提交的短 SHA）后，会自动创建：

• [bump] [staging] docs-builder configuration: <sha>
• [bump] [prod] docs-builder configuration: <sha>

合并这些 PR 会启动 Staging / Docs / Deploy / version-bump / ... 和 Prod / Docs / Deploy / version-bump / ...。

只需关注两件事：

1. Bump PR 已合并——staging 和 prod 的 [bump] ... <sha> 均为 MERGED。
2. Prod 版本 bump 部署成功，且对应相同 SHA。staging 版本 bump 失败会阻塞流程——立即报告；不要将 prod 视为已完成。

除非用户提出要求，否则忽略无关工作流（edge、AI enrich、zizmor、dependabot、assembler ingest、link-index）。prod 成功后，只要 staging 没有失败，就无需等待 staging 成功。

gh pr list -R elastic/docs-internal-workflows --state all \
  --search "[bump] docs-builder configuration: <sha>" \
  --json number,title,state,mergedAt,url
gh run list -R elastic/docs-internal-workflows --limit 20 \
  --json name,conclusion,status,displayTitle,url,databaseId,createdAt

通过运行名称中的 version-bump 和 bump PR 合并后的时间来匹配运行。缓存 bump PR 编号和运行 ID。

当 prod 版本 bump 状态为 completed/success 且 staging 未失败时，发送：“Prod deploy succeeded for 。”

门槛——满足以下所有要求前，不要起草“文档已上线”/“文档已发布”消息：

Line	Gate
9.x	所有阻塞性 RN PR 均已合并，且 prod 版本 bump 已成功（staging 未失败）
8.x / 7.x	所有阻塞性 RN PR 均已合并，且 elastic/docs 协调者 PR 已合并

达到门槛前：不要起草这些消息，不要询问“可以发送了吗？”，不要勾选 website-confirm 或 #mission-control 复选框。

达到门槛后：请用户查看网站，然后执行 §6.5。发送前必须进行视觉检查。8.x 的“文档已发布”仍需包含抓取一行。

建议下一步操作

总结 §0.2 阶段、仍存在哪些阻塞，以及唯一的下一步操作。不要提议发送 Slack 消息或创建 PR（如果对应复选框已勾选或用户已发送）。

---

1. 收集输入

• Semver 列表。
• 文档发布议题——[Docs release] X.Y.Z，不是工程发布议题。gh issue list -R elastic/dev --search "[Docs release] <version>" --json number,title,url。
• 工程发布议题——RC 的上级议题（[Release] X.Y.Z、X.Y.Z release 等）。规范的时间安排（FF、GA），通常会链接到文档议题，并标明 RC。文档议题尚不存在时，用于确认日期、哪些版本共用同一 GA，以及 RC 名称。
• 如果文档议题尚不存在，请参阅 §1.1。

1.1 创建文档发布问题（如果尚不存在）

1. 模板：9.x 次版本 → docs-release.md；9.x 补丁版本 → docs-patch-release.md；8.x → docs-patch-release-8.x.md。
2. 日期取自工程发布问题（功能冻结、预计 GA 日期）。如果没有，请只向用户询问这两个日期。发布说明合并截止日期 = 预计 GA 日期的前一个日历日（[DAY_BEFORE_RELEASE_DATE]）。不要询问合并截止日期或代码冻结日期。
3. gh issue create -R elastic/dev --template <template-file> --title "[Docs release] <version>"
4. 填写 Overview（版本、日期），并使用工程问题中列出的发布协调员。其余模板内容保持原样——不要照搬之前发布的利益相关者。
5. 报告：“已为 X.Y.Z 创建 #NNNN。已根据工程问题 #MMMM 填写日期。请审核。”
6. 如果工程问题尚未引用新的文档问题：gh issue comment <eng-issue> -R elastic/dev --body "Docs tracking: https://github.com/elastic/dev/issues/<new-docs-issue>"

用户提供的计划优先于工程问题。

---

2. 对各版本进行分类

如果补丁号 > 0，则为补丁版本；如果是 V.R.0，则为次版本；如果是 V.0.0，则为主版本（遵循开发问题和 v8/v9 操作指南）。然后按 §3 路由。

---

3. PR 路由（决策）

8.x / 7.x（补丁版本或次版本）

遵循 elastic-stack-v8.md。协调员的 PR 仅以 elastic/docs 为目标（按照模板修改 shared/versions*、conf.yaml）。

9.x —— 独立补丁版本（批次中只有一个 9.x，或没有 GA 日期相同的更高次版本）

• 补丁版本：创建一个 elastic/docs-builder PR：更新 config/versions.yml，使 versioning_systems.stack.current 与要发布的次版本线一致（例如，9.3.4 -> 次版本 9.3）。在 versions.yml 检查清单行添加链接。
• **时间门槛：**如果同一次版本线在 GA 前预计还会发布更多补丁版本，不要创建此 PR。如果当前已发布版本落后超过一个补丁版本（例如，当前为 9.3.2，要发布 9.3.4），可能会先发布中间补丁版本——请等待或向用户确认。

9.x —— 次版本（9.x.0）

创建两个单独的草稿 PR（对应两条检查清单）：

时间	分支 / 更改	在开发问题中添加链接的位置
FF 之后	仅修改 config/assembler.yml：将 shared_configuration.stack.next 更新为即将发布的次版本（例如，9.4）	FF 后的行——PR 或合并提交（格式）
GA 前（参见下方时间安排）	assembler.yml：将 stack.current 更新为该次版本；将 stack.next 更新为 main。versions.yml：将 versioning_systems.stack.current 更新为该次版本。	嵌套的 versions.yml 条目——在行末添加 PR URL

**versions.yml PR 的时间安排（次版本）：**不要过早创建——FF 到 GA 之间可能会有很多补丁版本发布。等到预计 GA 前不会再有补丁版本时再创建（通常提前 1–2 天）。请查看 #mission-control，或询问是否还排有其他补丁版本。

协调员会在合适时机合并每个 docs-builder PR；版本更新 PR 和部署会自动完成。不要用一个 PR 替代 FF 后的 assembler 步骤和 GA 前的 versions.yml 步骤。

同一日历日 GA：多个 9.x（例如 9.3.4 + 9.4.0）

其中只有一个会是次版本——其他都是补丁版本。同一天不会有两个次版本。

1. **Assembler PR：**次版本仍需单独创建 FF 后的 assembler.yml PR（更新 stack.next）。
2. versions.yml PR：仅创建一个——目标版本为批次中最高的版本。
3. 规范问题 = 最高的 9.x 次版本（负责 versions.yml PR）。
4. 较低版本线的问题 = semver 较低的补丁版本：仍用于发布说明（RNs）；不要重复更新 versions.yml——请按 §4 将其标记为被取代，并指向规范问题。

---

4. 编辑 elastic/dev 问题正文

• 主要跟踪信息放在描述中，而不是评论里。
• 不要删除模板占位符、脚注或利益相关方表格——只添加勾选标记、链接、删除线和简短的交叉引用。
• 使用 gh 或用户提供的真实 # / PR URL——绝不猜测编号。
• 边做边勾选。 每当执行与某个清单项匹配的技能流程操作后，立即勾选该项。同一操作对应的嵌套复选框应同时勾选。不要等别人提醒。不要将该项报告为待处理。
• 不要勾选尚未完成的项目。 其他团队（包括 docs-eng）的步骤、用户在此技能之外完成的工作，以及未来发布日的项目，都保持未勾选。
• **此技能每打开一个协调者 PR 后：**勾选父项和嵌套项，并粘贴 PR URL（小版本中，post-FF 与 version-bump 有不同的 URL，应分别放在不同的行）。

根据清单措辞匹配，不要假定所有模板都相同：

技能操作	清单项
已发送 Outstanding-RNs / day-before #docs 提醒	在 #docs 中发帖，提醒……尚未打开和/或获批的 PR
已打开协调者 PR	打开 PR……以及嵌套的 versions.yml / assembler.yml / conf.yaml 项
已发送 Merge-RN #docs 提醒	在 #docs 中发帖，告知……他们可以合并发布说明 PR
已合并协调者 PR	合并 docs-builder 配置 PR（或 8.x 对应项）
Prod version-bump 部署成功（仅限 9.x）	观察 prod version-bump 部署——仅在 §0.3 prod 部署成功（staging 未失败）后勾选。8.x 不要使用此项。
用户确认已查看网站	确认更新后的文档已显示在网站上——仅在满足门槛（§0.3）且用户表示网站看起来正确后勾选
在 #mission-control 回复“docs are live”	在 #mission-control 发帖告知文档已上线——仅在满足门槛且用户已查看网站后；发送 Slack 前仍须确认

gh issue view <N> -R elastic/dev --json body -q .body > /tmp/dev-issue.md
gh issue edit <N> -R elastic/dev --body-file /tmp/dev-issue.md

同一 GA 的替代处理（较低版本线的问题）

• 利益相关方区块：superseded by #<canonical>（真实编号）。
• 由规范版本问题负责的清单区块：用 ~删除线~ 包裹，并添加标记，例如 [not needed: superseded by 9.4.0 -- #<canonical>]。
• 可选页脚：Crossed out instructions superseded by https://github.com/elastic/dev/issues/<canonical>
• 仅限 RN 的协调者步骤可以在较低版本线的问题中保持未勾选（“验证/发布此版本的发布说明”）；仅将与规范版本重复的部署工作划掉。

如果 PR 针对了错误问题的路径：关闭，并注明 Superseded by owner/repo#N。

---

5. 打开协调者 PR（elastic/docs / elastic/docs-builder）

分支：stack-<version>（例如 stack-9.5-post-ff、stack-9.5、stack-8.19.16）——不要添加 docs/ 前缀，也不要在名称中使用 pre-ga /“day before”。如果有现成的检出目录就使用；否则克隆到临时目录。

gh pr create -R elastic/<repo> --draft --base main --head <branch> \
  --title "<concise title -- no Draft prefix>" \
  --body "## Refs\n\n- https://github.com/elastic/dev/issues/<N>"

仅在合适的时间窗口将 PR 标记为就绪。取消草稿状态：gh pr ready <num> -R elastic/<repo> --undo。

PR 创建后立即勾选 docs 问题中的对应项，并粘贴 PR URL（§4）。

---

6. 提醒与消息（#docs、Slack）

从 docs 问题（或用户提供的计划）中复制日期、问题链接、产品和未完成的 PR 状态。绝不编造版本、PR 状态或 @提及。

如果 §0 中尚无正文内容，使用 gh issue view <N> -R elastic/dev --json title,url,body。解析：从标题 / Overview 获取版本；从 Overview 获取预计 GA / FF / 合并截止时间；从 Release Notes 表格获取利益相关方和 RN PR 列。按 §0 处理跳过与阻塞。存在 URL = 在合并前均为阻塞状态。

**分组：**8.x 和 9.x 表格通常有所不同——有差异时，分别设置“Ping for ...”部分；同一利益相关方适用于多个版本时，合并重复的产品行。

尚未解决的利益相关方以及 Slack 消息的发送 / 预览方式：slack-templates.md。

模板、提及、发送

请阅读 slack-templates.md，了解模板、用户查找和 OOO 检查。如果用户未指定提醒类型，请提供以下选项：功能冻结、未完成的 RN、文档已发布或其他。

文档已发布： 一个版本 → 单数模板（version / are released）；两个或更多版本 → 复数模板（versions / are all released）。单个版本时，绝不要使用 "versions" / "all"。仅包含 9.x 的批次中，省略 8.x 抓取行。

发送（即使跳过模板文件，也要执行以下步骤）：

1. 在围栏代码块中预览（slack-templates.md），以保留换行。然后询问“发送吗？”
2. 等待确认。“Send it” / “looks good”算作确认。“Update the thread” / “check the boxes”不算。
3. 负载中的提及：人员 <@U…>；用户组 <!subteam^S…>。绝不要猜测 ID。
4. 后续消息：回复功能冻结公告所在的线程（docsFfThreadTs），并且设置 reply_broadcast: true。
5. 发送后：勾选对应的 docs issue 项（§4）。

6.5 在 #mission-control 线程中回复（发布日）

只有满足门槛（§0.3）后才能开始：9.x = 阻塞性 RN 已合并 + 生产环境版本升级；8.x = 阻塞性 RN 已合并 + elastic/docs 协调员 PR 已合并。如果尚未满足，请说明还有哪些事项未完成，然后停止——不要起草上线／已发布消息。

满足门槛后：

1. 请用户查看网站（9.x：当前文档／此版本的发行说明；8.x：v8 操作手册页面）。
2. 用户确认后：勾选“文档已显示在网站上”复选框（§4）。起草 #mission-control 回复（X.Y.Z docs are live.）和 #docs“文档已发布”通知（仅当批次中包含 8.x 版本时才添加 8.x 抓取行）。展示两条消息；只有在用户确认后才发送（slack-templates.md）。
3. 用户确认后：在开始发布的线程中回复（thread_ts 来自 §0），发送 #docs 通知，并勾选 #mission-control 复选框。

---

7. 后台轮询器（会话内）

当用户说“监视 PR”“监视部署”或“全部合并后告诉我”时：

7.1 发行说明 PR

1. 从 issue 表中获取阻塞性 RN PR URL（仅跳过 N/A / No changes）。
2. 每 5 分钟运行一次后台 shell（block_until_ms: 0）：gh pr view <url> --json state -q .state。
3. 全部状态为 MERGED → 发出 ALL_RN_PRS_MERGED（notify_on_output）。
4. 报告：“所有 RN PR 均已合并。”保存到会话文件。

7.2 docs-internal-workflows 部署（仅限 9.x）

8.x / 7.x 跳过。

9.x 的 docs-builder 协调员 PR 合并后（或用户要求监视 9.x 部署时）：

1. 配置 SHA + staging／prod 升级 PR + 版本升级运行 ID（§0.3）。优先使用会话状态。
2. 每 30 秒轮询一次 gh run view <id>。发出 DEPLOY_STAGING_FAILED（会阻塞；立即告警）、DEPLOY_PROD_FAILED、DEPLOY_PROD_DONE（prod 为 completed/success 且 staging 未失败）。
3. 收到 DEPLOY_PROD_DONE 时：“Prod 部署成功。”如果阻塞性 RN PR 仍未合并，列出这些 PR——不要提供上线／已发布的 Slack 消息。如果它们已全部合并，请用户查看，然后遵循 §6.5。
4. 将运行 ID 和结论写入会话状态。

轮询器仅在当前会话中运行。下一个会话：遵循 §0.1 + §0，不要重新完整发现。

对于此处未指定的事项（API 文档、Buildkite）：遵循 docs issue 清单和操作手册。