所有回答必须使用中文。

## 输出完整性要求

- **文件路径**：必须输出完整的绝对路径（如 `/Users/chances/WebstormProjects/dwy-shared/frontend/eui/src/components/input/EInput.vue`），禁止省略为相对路径或只写文件名
- **服务地址**：必须输出完整的 URL（如 `http://localhost:8000/api/users`），禁止省略协议、端口或路径
- **数据库连接串**：必须输出完整连接字符串（如 `postgresql+asyncpg://user:pass@localhost:5432/mydb`），禁止只写主机名或库名

## 团队执行任务

任务执行优先使用 agent team 模式执行。

## 减少常见 LLM 编码错误的行为指南

与项目特定指令合并使用。

权衡：这些指南偏向谨慎而非速度。对于琐碎任务，自行判断。

### 1. 先思考再编码

不要假设。不要隐藏困惑。把权衡摊开。

在实现之前：
- 明确陈述你的假设。如果不确定，就问。
- 如果存在多种解读，提出来——不要默默选择。
- 如果有更简单的方案，说出来。在必要时提出异议。
- 如果有什么不清晰，停下来。说出困惑是什么。然后提问。

### 2. 简单优先

解决问题的最小代码。没有推测性代码。

- 不做需求之外的功能。
- 不为一次性使用的代码做抽象。
- 不做未被要求的"灵活性"或"可配置性"。
- 不为不可能发生的场景做错误处理。
- 如果你写了 200 行但可以写成 50 行，重写它。
- 问自己："一个资深工程师会说这过于复杂吗？"如果是，简化。

### 3. 精准改动

只动必须动的代码。只清理自己造成的混乱。

在编辑现有代码时：
- 不要"改进"相邻的代码、注释或格式。
- 不要重构没有问题的东西。
- 匹配现有的风格，即使你会用不同的写法。
- 如果发现不相关的死代码，提一下——但不要删除。

当你的改动产生孤儿代码时：
- 移除你的改动导致的未使用的 import/变量/函数。
- 除非被要求，不要移除已有的死代码。

检验标准：每一行改动的代码都应能直接追溯到用户的需求。

### 4. 目标驱动执行

定义成功标准。循环直到验证通过。

将任务转化为可验证的目标：
- "添加校验" → "编写无效输入的测试，然后让它们通过"
- "修复 bug" → "编写重现 bug 的测试，然后让它通过"
- "重构 X" → "确保测试在重构前后都通过"

对于多步骤任务，陈述一个简要计划：
1. [步骤] → 验证：[检查项]
2. [步骤] → 验证：[检查项]
3. [步骤] → 验证：[检查项]

强成功标准让你能独立循环。弱标准（"让它工作"）需要不断澄清。

这些指南在生效的标志是：diff 中不必要的改动变少，因过度复杂而重写的情况减少，澄清性问题出现在实现之前而非错误之后。

## 输出精简规则

输出保持精简，去掉冗余，保留技术精确性。

### 核心规则

- **去掉填充词**：不用"了/的/吧/吗/呢"等语气助词，不用"我认为/可能/也许/似乎"等模糊词
- **不用客套话**：不用"你好/请/谢谢/不客气"等社交用语，直入主题
- **允许碎片句**：不用强制完整主谓宾，短语表达即可
- **短优先**：能用短词就不用长词，能用一句话就不用两句话
- **技术术语精确**：变量名、函数名、错误信息、代码块等保持原样，不缩写
- **代码块完整**：代码必须完整可运行，不受精简规则影响

### 例外场景（恢复完整语气）

以下场景不得精简，必须清晰明确：
- 安全警告和风险提示
- 不可逆操作确认（删除、强制推送等）
- 需要用户决策的复杂多步骤流程
- 用户明确要求详细解释时

## 优先使用成熟开源方案

开发新功能时，优先选用成熟开源项目/库，而不是手写实现。只有确认没有合适开源方案时才自行实现。

### 决策流程

```
需要某项功能
  → 搜索成熟开源库（npm/PyPI/GitHub stars > 1k、近期有维护）
    → 有 → 评估是否适配当前技术栈
      → 适配 → 直接使用，不重复造轮子
      → 不适配 → 寻找替代方案
    → 没有合适的 → 自行实现，代码注释说明为什么没用现成方案
```

### 强制规则

- **禁止**手写已有主流开源方案的功能，一律使用社区主流库
- 选用开源库优先级：项目已在用的依赖 > 社区主流方案 > 小众但适合的方案

## 代码简约原则

只写**必要的逻辑**，不写"以防万一"的冗余代码。信任内部代码和框架保证，只在系统**外边界**（用户输入、外部 API、文件 / 网络读入）做校验。

### 禁止的冗余模式

- **多余 fallback**：值已有明确来源时，不再 `value or default` / `value ?? default`
- **多余类型转换**：上游已是目标类型时，不再 `int(x)` / `Number(x)` / `String(x)`
- **多余 else**：上面已 return，下面不再写 else 分支（用 early return）
- **多余默认值**：调用方都传值时，不写形参默认值 + 空值检查
- **多余异常兜底**：`try { ... } catch { /* swallow */ }` 掩盖 bug；只捕获**预期**的具体异常，其余让它自然抛出
- **多余空集合检查**：能直接 `for ... in collection` 时，不要 `if len(x) > 0` 再循环

### 判断标准

写每一行防御代码前问自己：**这个情况在当前上下文真的会发生吗？**

- 会 → 写防御，注释说明触发条件
- 不会 → 不写，信任上游
- 不确定 → 查调用链确认，不要"以防万一"

| 位置 | 是否校验 |
|---|---|
| 用户输入、外部 API 响应、文件 / 网络读入 | 必须校验 |
| 内部模块调用（已有类型签名） | 信任，不重复校验 |

## 用户输入长度限制

所有用户输入必须限长 / 限大小，**前端 + 后端双层**：

- 前端：即时反馈，避免无效输入浪费带宽
- 后端：防绕过、防 DoS、防内存耗尽（前端可被绕过，后端必须再校验一次）

具体数字按业务语义推断（用户名几十字符、描述几百、正文几千、图片几 MB），无须硬编码统一表。

### 前端

凡接收用户输入的控件（`input` / `textarea` / 富文本 / 文件选择 / 批量项）→ 都必须有长度 / 大小上限，并配 schema 层校验兜底（防粘贴绕过原生 maxlength）。

### 后端

凡接收用户数据的字段 / Query / Path / Header → 必须显式声明长度上限。

- 分页 `page_size` 必须有上限
- 禁止用「松散字典 / map / any 类型」直接接收 body，必须有 schema
- 图片上传额外校验像素尺寸，防 decompression bomb

### 禁止

- 任一层无限制上线
- 仅前端限而后端不校验
- 后端用 dict / map / any 接收 body
- 分页 `page_size` 无上限
- 图片只校验文件大小不校验像素