pre-pr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Pre-PR checklist

PR前检查清单

Do this after the change works, before anyone opens the GitHub PR. Output is a filled template body — do not create the PR.

The template lives at

.github/pull_request_template.md

. Do not add extra sections.

在变更功能正常后、任何人开启GitHub PR前执行此操作。输出为填写完成的模板正文——请勿创建PR。

模板位于

.github/pull_request_template.md

。请勿添加额外章节。

1. Issue gate (hard stop)

1. Issue关卡（强制检查）

A PR without a maintainer-approved issue will be closed.

bash

gh issue view <N> --repo plastic-labs/honcho --json number,title,labels,state

Stop if any of these fail:

no issue number, or the issue is not in
```
plastic-labs/honcho
```
issue is closed (unless this PR is explicitly reopening it)
labels do not include
```
maintainer-approved
```

Say which check failed. Do not draft a PR body around it.

未获得维护者批准的Issue对应的PR将被关闭。

bash

gh issue view <N> --repo plastic-labs/honcho --json number,title,labels,state

若出现以下任一情况则停止操作：

无Issue编号，或Issue不属于
```
plastic-labs/honcho
```
仓库
Issue已关闭（除非此PR明确用于重新开启该Issue）
标签不包含
```
maintainer-approved
```

说明哪项检查未通过。请勿基于此撰写PR正文。

2. Classify the diff

2. 分类代码差异

bash

git diff main...HEAD --stat

Pick one primary kind: bug, feature, docs. Then decide layers:

Surface touched	Required
`src/` (non-prompt)	unit tests under the matching `tests/` tree
deriver / dialectic / dreamer / LLM path	unit + consider live-llm ( `tests/live_llm` )
queue, config hierarchy, multi-turn, SDK contract	unified ( `uv run python -m tests.unified.run` )
`/v3` HTTP or deriver queue behavior	`/verify` skill (runtime, not just pytest)
public API, SDK exports, `config.toml` / settings, mintlify `docs/`	documentation in the matching file

Skip a layer only with a one-line reason (e.g. "docs-only", "comment-only"). "When appropriate" is not a skip.

Invoke

/verify

when the runtime surface moved. Do not restate that skill here.

Lint/type before claiming tests are green:

uv run ruff check src/

→

uv run basedpyright

→ the pytest command for the layer.

bash

git diff main...HEAD --stat

选择一个主要类型：bug（修复）、feature（功能）、docs（文档）。然后确定需要覆盖的层级：

涉及层面	要求
`src/` （非提示词相关）	对应 `tests/` 目录下的单元测试
deriver / dialectic / dreamer / LLM路径	单元测试 + 考虑添加live-llm测试（ `tests/live_llm` ）
队列、配置层级、多轮对话、SDK契约	统一测试（ `uv run python -m tests.unified.run` ）
`/v3` HTTP或deriver队列行为	`/verify` skill（运行时测试，而非仅pytest）
公共API、SDK导出、 `config.toml` / 设置、mintlify `docs/`	在对应文件中添加文档

仅当有单行理由时可跳过某一层级（例如“仅文档变更”、“仅注释变更”）。“视情况”不能作为跳过理由。

当运行时层面发生变更时调用

/verify

。请勿在此处重复该skill的内容。

在声明测试通过前先进行代码检查和类型检查：

uv run ruff check src/

→

uv run basedpyright

→ 对应层级的pytest命令。

3. Proofs

3. 验证依据

Collect evidence that belongs in the PR, not in the commit:

command + pass/fail for what you ran
a log snippet, screenshot, or file path that shows the new behavior
for bugs: the failing case before vs after, if you have it

/verify

ran, the proofs are that session's output. Do not invent green runs.

收集应包含在PR中而非提交记录里的证据：

执行的命令 + 运行结果（成功/失败）
展示新行为的日志片段、截图或文件路径
针对bug修复：若有，提供修复前后的失败案例对比

若已运行

/verify

，则该会话的输出即为验证依据。请勿伪造测试通过的记录。

4. Write the body

4. 撰写PR正文

Fill the description, proofs, checklist portion of the pull request description template. Make sure to link the related github issue, otherwise the PR will be auto-closed.

填写PR描述模板中的描述、验证依据、检查清单部分。确保关联相关的GitHub Issue，否则PR将被自动关闭。