按约定组织一个业务模块

先确认业务边界

从一个可以验收的用例出发，明确实体归属、操作规则、查询条件和权限范围。已有的 ineed-config-category 可作为分层组织的参考，但不要照搬其中的全局数据语义到租户私有业务。

分类定义采用 GLOBAL_ONLY 语义；新的业务数据是全局共享还是租户隔离，必须按自己的业务明确。

模块如何划分

下面以已有工程为例，展示职责位置。实际创建时只选择所需技术组合，不必一次生成所有实现。

ineed-config-category/
├── ineed-config-category-core/
├── ineed-config-category-engine/
├── ineed-config-category-jpa/
├── ineed-config-category-jdbc/
├── ineed-config-category-mybatis-flex/
├── ineed-config-category-webmvc/
├── ineed-config-category-engine-reactive/
├── ineed-config-category-r2dbc/
└── ineed-config-category-webflux/

core 保留业务模型与契约；engine / engine-reactive 承载对应业务实现；各数据模块提供持久化实现；web 模块提供接口适配。

按依赖顺序实现

1. AO 与 Entity

区分输入对象与持久化实体，明确字段的含义、类型、必填约束和可变性。字段命名、注释、导入顺序与格式以 Core 仓库当前开发规范及相邻已验证实现为准。

2. Repository 契约与数据实现

明确业务需要的读写操作，并在选定的数据模块实现。新增查询字段时，必须同步实现实际过滤条件；只在查询对象里添加属性，不会自动改变 SQL 查询行为。

3. Converter 与输出对象

显式核对字段映射与对外输出边界。新增实体字段不意味着它应自动出现在所有对外响应中。

4. Manager 与 Service

Manager 放置业务对象规则；Service 编排完整用例，并承担相应事务边界。避免把 SQL 或底层数据访问细节写进 Service 和 Controller。

5. Controller

Controller 处理协议层输入输出，调用业务服务。校验失败、业务失败与正常返回应遵循当前 web 模块的既有约定。

验证不能停在编译

以一个新增查询条件为例，至少考虑：有匹配数据、无匹配数据、条件缺省、非法条件与必要的权限边界。使用真实数据实现验证过滤条件，避免测试替身让遗漏的 SQL 条件被掩盖。

检查事务内多个操作失败时的结果，核对上下文在正确边界传递。涉及租户或权限时，为不同上下文分别验证，不能用单个管理员账号代替隔离验证。

给下一位开发者留下什么

记录业务边界、所选技术组合、依赖环境、执行命令和实际验证结果。若仍有未覆盖场景，写明具体范围。

项目内的完整规范仍以 Core 仓库 docs/ 为事实来源。本篇用于理解开发顺序；开始具体任务前，继续阅读对应的 project-development、guides 与 ai 文档。