refactor: 模块划分下沉到design阶段——设计师定模块+依赖关系+开发顺序，PM按设计师模块清单派发develop任务

skills_library/pipelines/sdlc_general/common/task/SKILL.md

@@ -88,7 +88,7 @@ submitted ──claim──▶ running ──submit──▶ review ──approv
 PM 派发任务时先评估复杂度，复杂任务自动分解并编排执行顺序（能并行并行、不能并行串行），同时记录父子关系。
 
 1. **先评估**：判断当前任务是否「过于复杂」（涉及多个模块/应用、多个独立交付单元、工作量超单 agent 一次产出）。简单任务直接派发单个任务，不强行拆分。
-2. **模块化拆分原则**：概念相近的功能组合成一个独立模块，每个模块独立设置仓库，所有模块归入应用的伞仓库（pkgs/<模块>）。拆分开发任务以模块为单元——一个模块 = 一个开发任务。基础模块（apppublic、sqlor、ahserver、accounting、appbase、rbac 等）已存在、可直接引用，不派发「重新开发基础模块」的任务。
+2. **模块化拆分原则（design 阶段定模块，PM 按模块派发）**：模块划分由 design 阶段的设计师完成（架构能力更强）——概念相近的功能组合成一个独立模块，每个模块独立设置仓库，归入应用伞仓库（pkgs/<模块>），并在模块定义里写明模块间依赖关系 + 开发顺序。PM 派发 develop 任务时按设计师划分好的模块清单：一个模块 = 一个 develop 任务；按模块间依赖编排（无依赖并行、有依赖串行）。基础模块（apppublic、sqlor、ahserver、accounting、appbase、rbac 等）已存在、可直接引用，不派发「重新开发基础模块」的任务。
 3. **任务粒度控制（巨型任务拆小）**：单个任务必须聚焦单一交付单元，禁止派发「一次性实现全部 N 个模块 / 全部表契约 / 脚手架 + DDL 全套」这种巨型任务——任务过大时 agent 会因工作量大、方向迷失而陷入探索死循环（反复 read_file/run_shell 却不 write_file/deliver，30 轮耗尽无产出）。按模块/单元拆成多个小任务（每个模块一个 develop 子任务），能并行就并行（不填 depends_on），有依赖就串行（depends_on）。
 4. **自动分解**：复杂任务 → 拆成多个子任务，每个子任务含 title、role、description；用 `create_tasks` 一次批量派发。子任务默认挂当前里程碑任务名下（`parent_id` 由系统自动记录），任务树（/task）据此分层显示。
 5. **自动编排**：