# 短示例

这些例子只展示写法，不是新流程。

## direct / patch

用户说：“把 README 里的拼写修一下。”

可直接处理：

```text
路由：direct。
原因：单文件文案、可逆、验收显然。
最小验证：rg 确认旧拼写不存在，人工读一遍上下文。
```

如果是小 patch：

```text
路由：patch。
原因：范围清楚，影响有限。
快速 verifier：npm run build 或目标单测通过；说明未覆盖的人工抽检项。
```

## 目的与验收证明

用户说：“让登录失败提示更清楚。”

不要只写：

```markdown
| 目的 | 验收证明 |
|------|----------|
| 修改 LoginError.tsx | 文件已修改 |
```

更好的写法：

```markdown
| 目的 | 验收证明 |
|------|----------|
| 用户输错密码时能知道下一步该做什么 | Playwright 输入错误密码，断言提示包含原因和下一步；截图无遮挡 |
| 不泄露账号是否存在 | 同一测试分别输入不存在账号和错误密码，断言提示不区分账号存在性 |
```

## 项目本地 SOP

如果一个项目反复接入外部供应商 API，每次都容易漏文档、测试和回滚，可以沉淀本地 SOP：

```text
.ys_team/rules.md：声明供应商接入必须查官方文档、保存字段事实、补测试和回滚说明。
.ys_team/templates/checklist.md：增加“供应商文档证据”“最小验证”“文档质量”检查项。
.ys_team/memory/provider.md：记录反复踩过的字段映射、鉴权和错误处理模式。
```

SOP 留在项目本地。ys-team 核心只负责路由、verifier 卡、执行和验收纪律。