workflow-fix

规则

• 未经确认，不得调用会修改数据的 API。 gh api GET 请求可自由执行。任何使用 -X POST、-X PUT、-X PATCH 或 -X DELETE 的调用，都必须先展示给用户并获得批准。
• 绝不强制推送、删除分支或删除仓库。
• 仅修改 .github/ 下的文件。 不要触碰工作流文件以外的应用代码、脚本或配置。
• 在准备提交前，先展示差异并获得确认。
• 所有 PR 都必须以草稿形式创建。
• 标明不确定之处。 如果某项发现含糊不清，或修复可能导致工作流无法正常运行，请停止并询问，不要猜测。

第 1 步：验证前置条件

检查是否可用 bwwl：

bwwl --version

如果找不到该命令，请停止并告知用户必须先安装 bwwl 才能继续。不要尝试安装它。

第 2 步：确定范围

解析用户的请求，确定需要修复的内容：

• 单个文件或目录：仅操作当前仓库。
• 多个仓库（例如“server、clients、android”）：依次操作每个仓库。询问用户仓库克隆所在的基础目录。对于每个仓库，在 <base-dir>/<repo> 查找其本地克隆。如果未找到克隆，告知用户并跳过该仓库。
• 未指定目标：修复当前目录中 .github/workflows/ 下的所有发现项。

如果用户尚未运行 workflow-audit 技能，请立即运行 linter，在继续操作前识别发现项。

第 3 步：处理范围内的每个仓库

对每个仓库重复执行第 4–7 步。告知用户当前正在处理哪个仓库。

第 4 步：创建修复分支

仅在存在需要修复的发现项时，才创建修复分支：

git checkout -b fix/workflow-linter-findings

第 5 步：应用修复

参阅 bitwarden-workflow-linter-rules 技能，了解每条规则的正确修复方式。

对于机械性发现项： 不经询问，应用所有修复。

例外——step_pinned： 应用每个哈希固定项之前，遵循 bitwarden-workflow-linter-rules 技能中的 step_pinned 修复流程（通过 gh api 解析 SHA，展示验证链接，并等待用户确认）。

对于需要判断的发现项： 逐项暂停，并清晰展示发现内容。询问用户希望选择哪个选项（参照 bitwarden-workflow-linter-rules 技能），然后应用其选择。

第 6 步：验证修复

重新运行 linter，确认所有发现项均已解决：

bwwl lint -f .github/workflows/

如果仍有错误，请分析并修复。重复此过程，直到检查通过。

第 7 步：审查并创建 PR

应用所有修复后：

1. 展示所有更改的 git diff。
2. 询问用户是否确认继续创建 PR。
3. 不要自行运行暂存、提交或推送命令。将下面的代码块作为建议提供给用户，由用户手动运行：

git add .github/workflows/
git commit -m "Fix workflow linter findings"
git push -u origin fix/workflow-linter-findings

4. 用户确认推送后，创建草稿 PR：

gh pr create \
  --title "Fix workflow linter findings" \
  --body "Automated fixes for findings from the Bitwarden workflow linter (bwwl)." \
  --draft

第 8 步：总结

处理完所有仓库后，输出汇总表：

仓库	已修复的发现项	已创建的 PR	已跳过项／备注
...	...	...	...