go

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Go

Close out the current work in three steps, then stop. Do not run the full local validation pipeline; that is CI's job on the PR. If CI fails, the reviewer kicks it back and it comes around again.

分三步完成当前工作，然后停止。无需运行完整的本地验证流水线；这是PR提交后CI的工作。如果CI校验失败，评审者会打回，之后再重新处理。

1. Test end-to-end

1. 端到端测试

Prove the change works as a user would see it, not just that units pass.

Run the tests relevant to the change locally (Vitest
```
related
```
on the touched files, plus any e2e spec that exercises the touched surface). They must pass.
If the change has a user-facing surface, exercise it for real: UI through the repo's browser verification rules (Chrome extension, agent browser), backend by hitting the running service. Fix what you find before moving on.

证明变更在用户视角下可用，而不只是单元测试通过。

在本地运行与变更相关的测试（对修改文件执行Vitest
```
related
```
命令，加上任何覆盖修改范围的e2e测试用例），测试必须通过。
如果变更涉及用户可见的界面，实际进行验证：UI部分通过仓库的浏览器验证规则（Chrome扩展、agent浏览器），后端部分通过调用运行中的服务。在进入下一步前修复发现的问题。

2. Simplify

2. 简化代码

Make one reduction pass over the full diff before it ships: delete anything that does not earn its place (single-caller abstractions, unused branches, speculative handling, leftovers from abandoned approaches). Behavior must not change. Use the code-simplifier agent for a large diff; do it inline for a small one. Re-run the step 1 tests if the pass changed code. If nothing comes out, say so and move on.

在代码提交前对完整差异做一次精简：删除所有非必要内容（仅被单次调用的抽象、未使用的分支、推测性处理、废弃方案的遗留代码）。不能改变原有功能。如果差异较大，使用code-simplifier agent处理；如果差异较小，直接在代码中精简。如果精简修改了代码，重新运行步骤1的测试。如果没有可精简的内容，说明情况后继续下一步。

3. Open a PR

3. 提交PR

Branch from the current work (
```
feature/<slug>
```
or
```
bug/<slug>
```
; include the ticket identifier if there is one), commit, push.
```
gh pr create
```
with a body that says what changed and how it was verified; "Closes <ID>" when a ticket exists.
Stop. Never merge your own PR; CI gates it and the reviewer merges or kicks it back. If the card exists on a board, move it to In Review.

基于当前工作创建分支（
```
feature/<slug>
```
或
```
bug/<slug>
```
；如果有工单ID，需包含在内），提交代码并推送。
使用
```
gh pr create
```
命令创建PR，PR描述需说明变更内容及验证方式；如果存在工单，需包含“Closes <ID>”。
停止操作。绝不要合并自己的PR；CI会进行校验，评审者负责合并或打回。如果看板上有对应卡片，将其移至“In Review”状态。