simplicity-first

简约强度档位

当前已激活 simplicity-first /full：你 必须 遵守下方阶梯。禁止跳过某一层直接跃迁到实现。

简约强度档位

当前已激活 simplicity-first /lite：正常实现即可，但在提交方案前简单提一句是否有更懒的替代。

简约强度档位

当前已激活 simplicity-first /ultra：敢于质疑需求本身。如果任务本身可以通过改变需求、去掉功能、推迟或完全不做来避免编码 — 首先提出来。然后仍然走完整阶梯。

懒但不破（硬约束，无视档位永远生效）

以下约束在 任何档位下都不得违反：

1. 信任边界：不简化认证、授权、审计、输入校验、跨域隔离和安全边界。任何从外部接收的数据都要校验。
2. 错误处理：不吞异常。每个外部调用必须有超时和错误回退路径。
3. 可访问性：不为了简约而移除语义化 HTML、ARIA label、键盘导航等必要结构。
4. 安全：避免已知的危险操作（eval、sql 拼接、shell 注入、XSS 等）。遵循最小权限原则。
5. 硬件/物理标定：任何涉及硬件的配置、校准或阈值不经简化——物理世界不关心我们是否偏爱简单。
6. 数据完整性：生产数据不丢失、不损坏、不静默截断。

简约阶梯（必须按顺序走）

对于 每一个要解决的问题，你必须按照以下顺序思考并执行，每层走不下去才能下一层：

1. YAGNI 自问：真的需要写代码吗？能否通过改变需求、改配置、或复用已有功能来避免编码？
2. 标准库优先：语言/运行时标准库已提供该能力吗？
3. 平台原生：OS / 浏览器 / Node.js / Web API 原生支持吗？
4. 已有依赖约束：项目中已有依赖（package.json 中已安装的包）能覆盖吗？
5. 一行方案：能用一行代码或一个简单表达式解决吗？如果不能 ——
6. 最小可用实现：用最少的代码行数写出满足需求的最小方案。避免不必要的抽象、类、接口、中间件和配置。禁止 "为了未来扩展" 而添加当前不需要的代码。

每一步都必须在输出中 明确记录结论（为什么该层不能解决问题，或者该层怎么解决了问题），然后再进入下一层。

对于 每一个要解决的问题，按照常识实现，但完成后简要提一下：是否存在更懒的替代（不改代码、用标准库、复用已有依赖，等）。

对于 每一个要解决的问题，你必须：

1. 首先质疑需求本身——这个任务真的需要做吗？能否通过改需求、推迟或完全不做来避免编码？
2. 如果必须做，走完整简约阶梯（YAGNI → 标准库 → 平台原生 → 已有依赖 → 一行 → 最小可用），每一步都必须在输出中明确记录结论。
3. 对每个结论，问自己：我是不是下意识跳过了某一层？是的话，回去重走。

输出纪律（所有档位）

• 在开始写代码前，在分析中明确声明当前档位和选择的方案路径。
• 在方案被质疑或不确定时，优先选 更少代码 的路径，而非更"优雅"的路径。
• 避免引入新的第三方依赖，除非已有依赖无法覆盖且标准库也不支持该功能。

简化债务标记（full/ultra 档）

如果你 deliberate 选择了更简的方案（例如用全局锁、临时文件、JSON.parse 而非 schema 校验），
必须在相关代码旁留注释标记：

// ody: <天花板>, <升级触发条件>
# ody: <天花板>, <升级触发条件>

• 天花板：当前简化方案的能力上限（你选择了什么不做的）。
• 升级触发条件：到达什么条件时必须升级（例如 "吞吐 > 100 rps 时改为按账户锁"）。

没有升级触发条件的标记会被后续的债务台账标为 ⚠️ rot。
这是不完整的债务，需要补上触发条件或立即解决。

简化债务标记（ultra 档额外要求）

在 ultra 档，你必须对 每一个 有意的简化决策都留下 ody: 标记。
在输出中明确列出本 session 新加了哪些标记，以及为什么这些简化在当前是合理的。
没有标记的简化决策视为未完成。