|
|
@@ -0,0 +1,92 @@
|
|
|
+# 强前置条件约束
|
|
|
+
|
|
|
+根据你的自由组合
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### 通用开发约束
|
|
|
+
|
|
|
+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. 不得在缺乏上下文理解的情况下直接修改代码，必须基于整体结构审慎重构
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### 胶水开发约束
|
|
|
+
|
|
|
+1. 不得自行实现底层或通用逻辑，必须优先、直接、完整复用既有成熟仓库与生产级库
|
|
|
+2. 不得为了方便而复制依赖库代码到当前项目中再修改使用
|
|
|
+3. 不得对依赖库进行任何形式的功能裁剪、逻辑重写或降级封装
|
|
|
+4. 允许使用本地源码直连或包管理器安装方式，但实际加载的必须是完整生产级实现
|
|
|
+5. 不得使用简化版、替代版或重写版依赖冒充真实库实现
|
|
|
+6. 所有依赖路径必须真实存在并指向完整仓库源码
|
|
|
+7. 不得通过路径遮蔽、重名模块或隐式 fallback 加载非目标实现
|
|
|
+8. 代码中必须直接导入完整依赖模块，不得进行子集封装或二次抽象
|
|
|
+9. 不得在当前项目中实现依赖库已提供的同类功能
|
|
|
+10. 所有被调用能力必须来自依赖库的真实实现，不得使用 Mock、Stub 或 Demo 代码
|
|
|
+11. 不得存在占位实现、空逻辑或“先写接口后补实现”的情况
|
|
|
+12. 当前项目仅允许承担业务流程编排、模块组合调度、参数配置与输入输出适配职责
|
|
|
+13. 不得在当前项目中重复实现算法、数据结构或复杂核心逻辑
|
|
|
+14. 不得将依赖库中的复杂逻辑拆出后自行实现
|
|
|
+15. 所有导入的模块必须在运行期真实参与执行
|
|
|
+16. 不得存在“只导入不用”的伪集成行为
|
|
|
+17. 必须确保 sys.path 或依赖注入链路加载的是目标生产级本地库
|
|
|
+18. 不得因路径配置错误导致加载到裁剪版、测试版或简化实现
|
|
|
+19. 在生成代码时必须明确标注哪些功能来自外部依赖
|
|
|
+20. 在任何情况下不得生成或补写依赖库内部实现代码
|
|
|
+21. 只允许生成最小必要的胶水代码与业务层调度逻辑
|
|
|
+22. 必须假设依赖库为权威且不可修改的黑箱实现
|
|
|
+23. 项目评价标准以是否正确、完整站在成熟系统之上构建为唯一依据，而非代码量
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+### 系统性代码与功能完整性检查约束
|
|
|
+
|
|
|
+24. 不得允许任何形式的功能弱化、裁剪或替代实现通过审计
|
|
|
+25. 必须确认所有功能模块均为完整生产级实现
|
|
|
+26. 不得存在阉割逻辑、Mock、Stub 或 Demo 级替代代码
|
|
|
+27. 必须确保行为与生产环境成熟版本完全一致
|
|
|
+28. 必须验证当前工程是否 100% 复用既有成熟代码
|
|
|
+29. 不得存在任何形式的重新实现或功能折叠
|
|
|
+30. 必须确认当前工程为直接集成而非复制后修改
|
|
|
+31. 必须核查所有本地库导入路径真实、完整且生效
|
|
|
+32. 必须确认 datas 模块为完整数据模块而非子集
|
|
|
+33. 必须确认 sizi.summarys 为完整算法实现且未降级
|
|
|
+34. 不得允许参数简化、逻辑跳过或隐式行为改变
|
|
|
+35. 必须确认所有导入模块在运行期真实参与执行
|
|
|
+36. 不得存在接口空实现或导入不调用的伪集成
|
|
|
+37. 必须检查并排除路径遮蔽、重名模块误导加载问题
|
|
|
+38. 所有审计结论必须基于可验证的代码与路径分析
|
|
|
+39. 不得输出模糊判断或基于主观推测的结论
|
|
|
+40. 审计输出必须明确给出结论、逐项判断及风险后果
|
tukuaiai