# Aircoding — 约束铁律

## 1. 调度器约束

调度器（Scheduler）禁止以下行为：

- **禁止降级兜底**：不得以「先这样实现」「先跑通再说」「以后再改」「以后再补」「先回退」「先这样」等理由，使用简化逻辑、mock 实现、硬编码路径、或任何偏离设计方案的替代品。
- **必须完全遵循设计方案**：调度器的任务拆分、依赖图、执行序列、重试策略、错误传播等全部行为必须严格按照设计文档实现。设计方案未覆盖的场景，必须先更新设计方案再实现，不得在代码中自行裁决。

## 2. 执行器约束

执行器（Executor）禁止以下行为：

- **禁止降级兜底**：不得以「先这样跑通」「以后优化」「暂时绕过」「先硬编码」等理由，跳过或简化任何设计规定的执行步骤、工具调用链路、权限检查、日志落库、事件上报。
- **必须完全遵循设计方案**：执行器的工具链、Agent Loop、权限门控、结果验证等全部行为必须严格按照设计文档实现。任何偏离 = 未完成。

## 3. 审查器约束

审查器（Reviewer）是**强制调用**的关卡，不可跳过、不可默认通过、不可降级为静默占位。

### 3.1 禁止的判定依据

以下理由**不得**作为通过审查的依据：

- 「测试 pass」「测试全绿」
- 「实现存在」「函数存在」「文件存在」
- 「typecheck 通过」「build 通过」「lint 通过」
- 「看起来正确」「逻辑应该是对的」

### 3.2 强制审查流程

审查器必须按以下三层逐项执行，全部通过才能放行：

1. **Code-to-Design 逐行对照**
   - 将代码实现逐行/逐函数与设计方案和用户需求对照
   - 确认每个设计要点在代码中有对应的实现
   - 确认代码中没有超出设计范围的自行发挥
   - 确认没有以「先这样」为名的降级实现

2. **静态审查**
   - 安全性：注入、越权、敏感数据泄露、输入校验
   - 正确性：边界条件、空值处理、并发安全、资源释放
   - 合规性：架构铁律（仅调度层可自研，其他用 OpenCode 现有实现）

3. **测试通过**
   - 仅在上述两关通过后，测试通过才有意义
   - 测试本身必须覆盖用户需求的核心路径

### 3.3 审查结果

- 审查未通过时，必须列出具体的不合规项（文件:行号、设计要点、偏差描述）
- 不合规项修复后重新提交审查，直到全部通过
- 审查报告作为任务完成的前置证据