编程开发通用约束

### 通用开发约束

1. 不得采用只解决局部问题的补丁式修改而忽视整体设计与全局优化
2. 不得引入过多用于中间通信的中间状态以免降低可读性并形成循环依赖
3. 不得为过渡场景编写大量防御性代码以免掩盖主逻辑并增加维护成本
4. 不得只追求功能完成而忽略架构设计
5. 不得省略必要注释，代码必须对他人和未来维护者可理解
6. 不得编写难以阅读的代码，必须保持结构简单清晰并添加解释性注释
7. 不得违反 SOLID 与 DRY 原则，必须保持职责单一并避免逻辑重复
8. 不得维护复杂的中间状态，仅允许保留最小必要的核心数据
9. 不得依赖外部或临时中间状态驱动 UI，所有 UI 状态必须从核心数据推导
10. 不得通过隐式或间接方式变更状态，状态变化应直接更新数据并由框架重新计算
11. 不得编写过量的防御性代码，应通过清晰的数据约束与边界设计解决问题
12. 不得保留未被使用的变量和函数
13. 不得将状态提升或集中到不必要的层级，状态应在最接近使用的位置管理
14. 不得在业务代码中直接依赖具体实现细节或硬编码外部服务
15. 不得在核心业务逻辑中混入 IO、网络、数据库等副作用操作
16. 不得形成隐式依赖，如依赖调用顺序、全局初始化或副作用时序
17. 不得吞掉异常或使用空 catch 掩盖错误
18. 不得将异常作为正常控制流的一部分
19. 不得返回语义不清或混用的错误结果（如 null / undefined / false）
20. 不得在多个位置同时维护同一份事实数据
21. 不得在未定义生命周期和失效策略的情况下缓存状态
22. 不得跨请求共享可变状态，除非明确设计为并发安全
23. 不得使用语义模糊或误导性的命名
24. 不得让单个函数或模块承担多个不相关语义
25. 不得引入非必要的时间耦合或隐含时间假设
26. 不得在关键路径中引入不可控的复杂度或隐式状态机
27. 不得臆测接口行为，必须先查询文档、定义或源码
28. 不得在需求、边界或输入输出不清晰的情况下直接实现
29. 不得基于猜测实现业务逻辑，必须与人类确认需求并留痕
30. 不得在未评估现有实现的情况下新增接口或模块
31. 不得跳过验证流程，必须编写并执行测试用例
32. 不得触碰架构红线或绕过既有设计规范
33. 不得假装理解需求或技术细节，不清楚时必须明确说明
34. 不得在缺乏上下文理解的情况下直接修改代码，必须基于整体结构审慎重构