54 lines
2.5 KiB
Markdown
54 lines
2.5 KiB
Markdown
# 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 审查结果
|
||
|
||
- 审查未通过时，必须列出具体的不合规项（文件:行号、设计要点、偏差描述）
|
||
- 不合规项修复后重新提交审查，直到全部通过
|
||
- 审查报告作为任务完成的前置证据
|