launchdarkly-factory-settings

LaunchDarkly Factory 设置

你正在使用一项技能，通过 LaunchDarkly MCP 配置 Factory（GitHub App 代码自动化），或说明 PR 未被分类的原因。Factory 可以创建和更改拉取请求（自动标记），也可以驱动自动发布。请将每项写入操作都视为具有影响范围的生产自动化。

前提条件

此技能需要远程托管的 LaunchDarkly MCP 服务。

必需的 MCP 工具：

• get-factory-settings / update-factory-settings
• list-factory-github-repos（GitHub App 安装 — 可映射的仓库）
• list-factory-repo-settings（已映射的仓库）
• update-factory-repo-settings / get-factory-repo-settings / delete-factory-repo-settings

如果缺少这些工具，请停止。不要编造 REST 调用、数字形式的 GitHub ID，也不要靠猜测设置来“修复”问题。

Factory 设置目前处于 alpha 阶段：底层端点受 enable-factory-settings 标志控制。如果每个 Factory 工具都返回 404，说明该账户不在 alpha 范围内 — 请告知用户，不要重试或改用 REST。

核心原则

1. 默认拒绝。 诊断操作只读。除非用户在看到当前状态与拟议状态后确认了具体写入操作，否则绝不要更改设置来“让分类正常工作”。
2. 账户设置是总开关。 已映射的仓库无法启用账户关闭的功能。在账户级别关闭某项功能，会对所有已映射的仓库关闭该功能。在账户级别启用某项功能，会允许所有继承该设置（未单独覆盖为关闭）的已映射仓库开始自动处理 PR。
3. 每次 Factory 写入前都要确认。 账户 PATCH、映射、仓库覆盖设置和取消映射都必须遵循写入前确认。只处理用户点名的仓库。
4. 最小权限。 除非用户明确要求自动发布（这可能会发布代码），否则绝不要启用自动发布。除非用户明确要求移除审批门槛，否则绝不要关闭 approvalRequired。绝不要映射或取消映射用户未点名的仓库。绝不要遍历安装列表并映射所有仓库。
5. 先发现，再映射。 传入 owner/name。绝不要询问数字形式的 GitHub ID。用户说“这个仓库”或“这个 PR”时，优先使用当前工作区的 git remote；如果远程地址不一致（fork 与上游），请询问用户要选哪一个。owner/name 仅根据 GitHub App 安装列表解析 — App 未安装的仓库无法解析或操作，因为 Factory 通过该 App 工作。如果 404 表示仓库不在安装列表中，或 App 未安装，这就是结论；不要换其他拼写重试，也不要从其他地方查找该仓库。
6. 首次映射时需要 projectKey。 创建映射时必填；后续更新可省略。
7. 省略 autoCleanup。 目前 Factory 设置中尚不包含此项。绝不要发送它；也绝不要将响应中的值复制到 PATCH 中。
8. GitHub 连接需要通过浏览器链接完成。 如果 list-factory-github-repos 返回 githubConnectUrl，请将该确切 URL 提供给用户，并等待用户告知已完成。然后再次调用 list-factory-github-repos。不要自行安装或授权 GitHub。flow=install 表示安装 GitHub App。flow=authorize 表示授权 GitHub。两者打开的页面与集成抽屉相同。用户必须已在该浏览器中登录 LaunchDarkly。

写入前确认

停止。 在用户对本轮提案明确回复“是”之前，不得调用 update-factory-settings、update-factory-repo-settings 或 delete-factory-repo-settings。用户在较早轮次回复“是”，或含糊地说“修一下”／“继续”，但未指明设置，都不够。

1. 先读取当前状态（get-factory-settings；如果更改涉及仓库，则还要读取仓库设置或列表）。
2. 用一两句话说明当前状态与提议状态，并说明影响范围。对于映射操作，先读取 get-factory-settings，并说明继承的自动标记和自动发布状态。
3. 等待回复。不要在提出问题的同一轮工具调用中执行写入。

账户更改（对 update-factory-settings 操作任何字段，包括开启功能）：

此账户的自动标记已开启。要为所有已映射仓库关闭吗？自动标记拉取请求将停止，直到重新开启。

此账户的自动标记已关闭。要为该账户开启吗？继承此设置的已映射仓库可能开始收到自动标记拉取请求。

自动标记的 approvalRequired 已开启。要关闭吗？自动标记 PR 将不再需要此审批关卡。

自动发布也遵循相同模式，并说明自动发布可能会将更改交付上线。

映射或更改单个仓库（update-factory-repo-settings）：

提案中必须始终同时说明账户继承的两项能力。未指定的覆盖设置会继承自动标记和自动发布；如果提案只提到自动标记，不要请求确认映射。

launchdarkly/gonfalon 尚未映射。要将其映射到项目 default，并继承账户的自动标记（开启）和自动发布（关闭）吗？Factory 可以开始在该仓库中分类问题并创建自动标记 PR。除非账户或仓库级覆盖设置将其开启，否则自动发布会保持关闭。

launchdarkly/gonfalon 尚未映射。要将其映射到项目 default，并继承账户的自动标记（开启）和自动发布（开启）吗？Factory 可以开始在该仓库中创建自动标记 PR，并自动发布；自动发布可能会将更改交付上线。

launchdarkly/gonfalon 已映射到 default，自动标记的生效状态为开启，自动发布的生效状态为关闭。要仅对此仓库设置覆盖项以关闭自动标记吗？自动发布仍会继承账户设置（关闭）。

取消映射（delete-factory-repo-settings）：

launchdarkly/gonfalon 已映射到项目 default，自动标记的生效状态为开启，自动发布的生效状态为关闭。要取消映射吗？在再次映射之前，Factory 将停止对该仓库进行自动标记和自动发布。

用户确认后，只应用提案中列出的字段。然后进行验证（不要将验证用作安全检查）。

选择工作流

• “为什么 Factory 没有对我的 PR 分类／进行自动标记？”（或类似问题）→ 首先查看为什么我的 PR 没有被分类？。此工作流中不要写入设置。
• 配置／映射／开启／取消映射 → 配置设置。

为什么我的 PR 没有被分类？

当用户询问 PR 为什么没有被分类、没有被自动标记，或 Factory 为什么忽略了该 PR 时，使用此流程。**只读。**按以下顺序检查。遇到第一个失败项时停止，并告诉用户如何修复（如果用户要求你应用修复，则先确认后再写入）。

从 PR URL、git remote 或用户提供的名称中确定 GitHub 仓库（owner/name）。如果无法确定唯一仓库，请询问。不要诊断其他仓库。

1. **账户是否开启了自动标记？**使用 get-factory-settings。如果 autoFlagging.enabled 为 false，原因就在这里：账户级开关已关闭，因此没有仓库可以自动标记。停止。

2. **此仓库是否映射到了项目？**使用 repo: "owner/name" 调用 get-factory-repo-settings（或调用 list-factory-repo-settings 并找到它）。如果错误信息或 list-factory-github-repos 包含 githubConnectUrl，请查看 flow：

   • flow=install：GitHub App 尚未安装，因此 Factory 根本看不到该 PR。原因就在这里。向用户提供链接并停止。
   • flow=authorize：此成员尚未授权 GitHub，因此无法查找 owner/name。这不是 Factory 跳过该 PR 的原因。说明这一点，向用户提供链接，并在他们完成后从此步骤继续。不要将其报告为修复方法。

   已安装但未映射的仓库是另一种情况。未映射的已安装仓库不会运行 Factory。停止。

3. **此仓库是否覆盖设置，关闭了自动标记？**在仓库数据中，如果自动标记的 enabled 为 false，或 enabledOverride 为 true 且 enabled 为 false，则此仓库已选择退出，即使账户级开关已开启也是如此。停止。

如果以上三项均正常（账户已开启、仓库已映射、仓库的自动标记实际处于开启状态）：

• 不要更改设置来“试试看”。
• 请引导用户查看 Factory 运行手册。在 Factory 处于 alpha 阶段期间，这些是内部 LaunchDarkly Confluence 页面（PD 空间）；目前还没有公开的文档 URL。分类仍可能因 MCP 接口无法查看的原因而失败（GitHub App 安装在错误的组织中、PR 所在仓库未安装 App、工作流/App 权限、分类器跳过规则）。
  • 标记分类（ODD）运行手册 — 分类器本身：判定结果（not-suited、already-flagged）、升级处理，以及记录 PR 判定原因的逐 PR 台账。
  • GitHub App 运行手册 — PR 事件未到达 Factory 的情况：安装范围、权限、webhook。
• 可选检查：使用 list-factory-github-repos 确认仓库是否在安装列表中；如果用户预期会有一个 PR 且该 PR 已存在，但正在等待批准，则检查 autoFlagging.approvalRequired。

配置设置

步骤 1：读取当前设置

1. get-factory-settings
2. list-factory-repo-settings
3. list-factory-github-repos（可选 projectKey；安装范围为整个账户）

如果存在 githubConnectUrl，请向用户提供该链接，并在本轮停止。后续调用未返回该 URL 之前，不要进行映射。

步骤 2：账户默认设置（如有需要）

如果需要对账户执行 PATCH，请遵循确认后再写入，然后仅使用已确认的字段调用 update-factory-settings：

• autoFlagging.enabled / autoFlagging.approvalRequired（仅此处可设置审批选项）
• autoReleasing.enabled

不要发送 autoCleanup。需要 updateFactorySettings 权限。

步骤 3：映射或覆盖仓库设置

仅对用户指定的仓库执行。遵循确认后再写入，然后调用 update-factory-repo-settings：

1. 优先使用 repo: "owner/name"。
2. 创建映射时填写 projectKey。
3. 可选设置仓库级 autoFlagging / autoReleasing 覆盖项。未指定的功能将继承账户设置。如果账户已关闭某项功能，仓库无法启用该功能。

需要对已映射项目拥有 updateFactoryRepoSettings 权限。

第 4 步：验证（写入已确认后）

• 根据情况调用 get-factory-repo-settings / get-factory-settings。
• 实际生效的 enabled 必须与提议一致（账户已关闭 ⇒ 仓库不能开启）。
• 映射的仓库会显示在 list-factory-repo-settings 中。

要取消映射：先确认后再写入，然后调用 delete-factory-repo-settings。

不在范围内

• 自动清理
• 在工具内完成 GitHub OAuth。改为向用户提供 githubConnectUrl。
• Vega BYOK
• Observability MCP（github_repositories）——不要仅为了映射 Factory 仓库而要求启动第二个 MCP 服务
• 通过此技能更改分类规则、GitHub App 权限或组织安装范围