AirCoding/CLAUDE.md

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 审查结果

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