更新 llms-full.txt

llms-full.txt

@@ -1440,44 +1440,5 @@ requestParams为请求参数列表，response为返回结构，requestParams中
     - 本章节描述的是参数选择的**优先级原则**，不是绝对限制
     - API参数的绝对限制请参考2.14章节
     - "优先使用QTO/BTO"意思是在满足规范的前提下，根据场景选择最合适的参数类型
-
-### 5. 本地代码阅读和编写指南
-#### 路径处理规范
-- **所有子模块文件路径必须以 `modules/` 开头**
-- 当工具返回的路径为 `src/main/java/...` 格式时，需要根据文件内容识别模块名并补充完整路径
-- 完整路径格式：`modules/{模块名}/src/main/java/...`
-- 示例：`modules/room_management/src/main/java/com/bnb/room_management/...`
-
-#### 5.1 代码阅读
-- 根据**设计元素到代码的映射规则及修改建议**，在约读代码的时候，你可以识别出对应的TOCO设计元素，通过工具获取TOCO设计元素信息，辅助理解代码语义，特别是对于ReadPlan，WritePlan的设计元素
-- 读取类文件时，应该同时读取继承的基类文件（但注意不要去阅读BaseBOService里的代码）
-- 不要去读VoConverter、DtoConverter、 BaseDtoConverter、BaseVoConverter的代码
-- 如果一个类或者一个函数上面有@AutoGenerate的注解，说明该函数、该类是由TOCO设计元素生成的，你需要使用工具`getItemDefinition`获取设计元素，辅助理解代码含义
-#### 5.2 代码修改
-**代码修改安全检查流程**：
-在执行任何代码修改之前，必须严格遵循以下步骤：
-- **强制代码检查**：使用 readClassMethod 或 findJavaClass 读取目标代码完整内容
-- **修改策略选择**：
-   如果需要修改设计元素本身的实现，应修改对应的TOCO设计，不应直接修改代码
-- **禁止行为**：严禁跳过检查步骤、严禁直接修改TOCO生成的代码
-- **完整流程**：设计元素修改 → draftConfirm → designToCode → 必要时再用editFile补充
-
-记住：TOCO生成的代码占项目90%，大部分修改需求都应通过设计元素工具完成。
-#### 5.3 代码编写
-- 对于校验规则，先判断是否为业务不变性规则，如果是，则将代码写在BO对象的聚合校验函数中即可实现校验功能，不需要在Controller或Service中单独调用校验方法。聚合校验函数中适合做内存中数据的规则校验，不适合做很重的外部存储数据的获取或RPC调用，乐观锁字段由系统维护，无需校验
-- 编写代码前需仔细分析当前代码所属模块和其中需要调用的方法是否属于同一模块，特别注意**跨模块方法调用必须通过XxxRpcAdapterInXxx**，**禁止**直接使用其他模块的类名来调用，其通过@Resource注入的变量名必须为类名的首字母小写，如@Resource private UserServiceRpcAdapterInMeeting userServiceRpcAdapterInMeeting
-- 需要着重考虑单一职责原则、复用性，如Controller中更适合做参数校验及简单的不可复用的逻辑分支处理，不适合实现复杂的或通用的业务逻辑
-- 在循环中需要尽量避免执行调用数据库的操作，如查询数据库、写数据库等，尽量在循环外层先获取数据，在循环里面进行数据处理或读取
-- 提高代码的可以读性，复杂的业务逻辑需要拆解成多个函数，一个函数的代码一般不要超过30行；
-- 如果代码中需要抛出异常，则统一抛出IgnoredException(code, "message")异常，如throw new IgnoredException(400, "xxx");，code=400一般表示参数错误，code=500一般表示处理出现错误。注意IgnoredException属于已有的包com.vs.ox.common.exception，需要import com.vs.ox.common.exception.IgnoredException;
-- 写代码时请注意，BOService一般是用于写，QueryService一般是用于读
-- 输出代码前请仔细检查是否有错误的import，如果有则将其修正
-- 对于无法识别或直接生成的参数和逻辑，请增加一个相关的//TODO注释，把从需求中解析到的可能的处理逻辑以java伪代码的形式写在注释中
-- BOService 函数中的 boResult.getRootBo() 一定存在，不要添加判断null的情况的代码;  不要添加调用rootBo.persist()的代码（该方法的触发由生成的代码负责），在BOService的函数中不要修改和注销系统生成的代码（通过/** This block is generated by vs **/注释标注部分)
-- 在函数中的不同片段逻辑，使用 {} 标注分块，附上注释，提升代码的可读性，如果分块超过3个，必须拆分成函数，并且放到一个独立的Service类中；**禁止** 由大量分块组合而成的面条式代码。
-- 以准确性作为第一优先级（不产生编译错误），不要直接生成不存在的函数、字段的调用； 如果逻辑上必须依赖，可以使用注释来表达
-- 写代码时，如果发现有用户指定的上下文，则优先判断是否有可用的代码；如果用户有编写代码的特殊要求，则优先满足用户需求；如果前面已经有过规划信息，则尽量按照之前的规划来做，比如业务不变性的分析等
-- 对于写服务的代码插入遵循如下规则： 1、 controller里插入入参的校验部分逻辑和参数重组逻辑 2、其他的逻辑在主BoService的主函数里，为了增加代码可读性，可以在BoService里新增函数
-- 请在最后对所有你新增或修改的代码进行一次review，重点关注是否存在编译错误；代码可读性（是否需要对大的函数进行拆分重构）
 -----------------------------------------------------------------------------
 </TOCO知识库>