verify-and-ship

验证并交付

完成更改后，请按照以下步骤验证质量并交付成果。

1. 验收标准验证（关键）

使用问题跟踪器的 get_issue 工具获取当前问题的详细信息。从问题描述中提取所有验收标准，并验证实现是否满足每一项。如果没有明确的标准，请根据问题标题和描述中的隐含要求进行验证。

2. 质量检查

根据更改的行为、风险和现有覆盖范围选择验证方式。必须进行验证；但并非每项更改都需要新增自动化测试或运行完整测试套件。请遵循适用的仓库专属检查和 CI 门禁。

• 直接验证 — 对于常规发布脚本、打包／构建元数据、CI、文档和说明编辑，如果语法检查、安全的试运行、制品检查、隔离安装冒烟检查或一致性审查已足够，请优先采用这些方式。在 PR 中记录执行的命令及结果，或说明进行的审查；无需仅为证明工作而新增测试文件或验证报告。
• 自动化测试 — 运行相关的现有测试。只有在回归测试能够捕获具体且影响重大的故障，并且其保护价值足以抵偿维护成本时，才新增或保留此类测试。例如，发布了错误的制品、意外移动了稳定标签，或接受了无效的发布凭据。说明每项新增测试能够捕获的故障。不要对文档措辞或源文本添加脆弱断言，不要编写复刻实现逻辑的测试，也不要为低风险编辑搭建繁复的测试脚手架。仅凭脚本文件名既不代表必须测试，也不能免除对重大行为的保护。
• 范围 — 如果共享行为、故障或未解决的风险需要更广泛的验证，请扩大测试范围；不要自动运行完整测试套件或生成覆盖率报告。检查通过且足够后即可停止重复执行，除非更改或新证据表明有必要再次运行。调查相关故障，而不是原样重试未更改的命令。诚实报告所有未解决的故障。
• Lint、类型检查、构建 — 对更改的文件运行相关检查，并通过仓库要求的门禁。修复由此次更改引入的故障。
• 审查 — 检查正确性、范围和可维护性，包括拟议测试是否能提供有效保护。

如果仓库使用 F1，请在执行 drive 或请求证据前，按照其规范的 skills/f1-test-drive/SKILL.md 适用性政策进行判断。不适用的更改应进行适度检查，并在 PR 中简要说明；无需运行或报告 F1。不要仅根据此技能推断必须使用 F1。保留针对重大故障的现有保护措施。

3. 更新变更日志

检查项目是否包含变更日志文件：

ls -la CHANGELOG.md CHANGELOG.internal.md 2>/dev/null || echo "NO_CHANGELOG"

如果存在变更日志文件，请与基础分支比较差异，以检查此分支是否已添加条目：

# See what changelog lines this branch has added compared to the base branch
# Replace <base_branch> with the actual base branch from the issue context
git diff <base_branch> -- CHANGELOG.md CHANGELOG.internal.md 2>/dev/null

处理现有条目：

• 如果差异显示此分支已为当前问题添加变更日志条目（匹配问题标识符），请直接更新该条目（例如，添加 PR／MR 链接或完善描述）。不要添加重复条目。
• 如果差异显示此分支添加了其他问题的变更日志条目，或没有添加任何条目，请新增条目。

新增或更新条目：

• 将条目放在 ## [Unreleased] 下的相应小节（### Added、### Changed、### Fixed、### Removed）中
• 着眼于最终用户影响，简洁而明确
• 包含 Linear 问题标识符和 PR／MR 链接（格式：([ISSUE-ID](linear_url), [#NUMBER](PR_OR_MR_URL))）
• 遵循 Keep a Changelog 格式

4. 提交并推送

-暂存所有相关更改（包括变更日志更新）

• 按照项目的提交规范，使用清晰、具体的提交说明
• 推送到远程仓库

5. 创建或更新 PR/MR

根据仓库上下文（问题上下文中的 <github_url> 或 <gitlab_url>）确定平台，并使用相应的平台工具。

GitHub（存在 <github_url> 时）

git push -u origin HEAD
gh pr view --json url,number 2>/dev/null || gh pr create --draft --base [base_branch from context] --title "[descriptive title]" --body "Work in progress"

GitLab（存在 <gitlab_url> 时）

git push -u origin HEAD
glab mr view 2>/dev/null || glab mr create --draft --target-branch [base_branch from context] --title "[descriptive title]" --description "Work in progress"

PR/MR 描述

使用完整的描述更新 PR/MR：

• 负责人信息：如果负责人上下文中有 <github_username>，请在正文顶部添加 Assignee: @username ([Display Name](linear_profile_url))。如果只有 Linear 个人资料 URL，请使用 Assignee: [Display Name](linear_profile_url)。
• 变更摘要、实现方案和已执行的测试
• 指向 Linear 问题的链接
• Cyrus 标记：在正文末尾添加 ``，作为隐藏的 HTML 注释
• 交互提示：将此提示添加在末尾（标记之前），并使用系统提示词的 <agent_context> 块中的 <github_bot_username> 或 <gitlab_bot_username> 作为机器人用户名。如果没有 <agent_context>，默认使用 cyrusagent：

  ---
  > **Tip:** I will respond to comments that @ mention @<bot_username> on this PR/MR. You can also submit a review with all your feedback at once, and I will automatically wake up to address each comment.
  

从标题中移除任何 "WIP:" 或 "Draft:" 前缀。检查 <agent_guidance>——只有在指导中未要求将其保留为草稿时，才将 PR/MR 标记为可合并。

确认 PR/MR 的目标分支是问题上下文中 <base_branch> 指定的正确分支。