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

pipeline_service/agent_loop.py

@@ -405,10 +405,10 @@ ROLE_SPECIFICS = {
 产出路径: docs/00-requirement/requirement-spec.md
 同时创建（项目至少一个应用）:
   - apps/<应用名>.md: 应用描述、部署环境、端口
-  - modules/<模块名>.md: 模块功能、仓库URL(先填写规划地址)、技术栈、依赖
-  - 每个应用至少关联一个模块
-模块划分遵循模块化原则: 概念相近的功能组合成一个独立模块；apppublic、sqlor、ahserver、accounting、appbase、rbac 等基础模块已存在、可直接引用，**不必列为待开发模块**（除非需求明确要改它们）。
-内容: 项目概述、用户角色及权限、功能列表(每个功能:输入/处理/输出/验收标准)、非功能需求、业务流程。""",
+  - 每个应用至少一个（应用 = 部署单元）
+内容: 项目概述、用户角色及权限、功能列表(每个功能:输入/处理/输出/验收标准)、非功能需求、业务流程。
+
+注意: 需求阶段只识别「应用」（部署单元，含端口/环境），**不划分模块**——模块划分是架构决策，由 design 阶段的设计师完成（架构能力更强）。""",
 
     'design': """你是系统设计师。按 SDLC 仓库标准产出文档。
 
@@ -417,6 +417,9 @@ ROLE_SPECIFICS = {
   - database-design.md: ER图描述、表结构DDL
   - api-design.md: 接口列表(method/path/request/response)
   - ui-design.md: 页面结构、组件树(如适用)
+同时完成模块划分（modules/<模块名>.md）: 把应用拆成模块——概念相近的功能组合成一个独立模块，每个模块独立仓库（归入应用伞仓库 pkgs/<模块>），每个模块含: 模块功能、仓库URL(先填规划地址)、技术栈、依赖。
+同时定义模块间依赖关系 + 开发顺序: 每个模块在「依赖」字段写明它依赖哪些其他模块（被依赖方须先开发），并给出开发顺序（拓扑序）。无依赖的模块可并行开发；有依赖的模块须等其依赖的模块完成后再开发。
+模块划分遵循: apppublic、sqlor、ahserver、accounting、appbase、rbac 等基础模块已存在、可直接引用，**不必列为待开发模块**（除非需求明确要改它们）。后续 PM 按你划分好的模块 + 依赖关系派发 develop 任务，develop 按你的模块清单逐个开发。
 产出后用 result 输出文档，files 列出所有文件路径。""",
 
     'develop': """你是开发工程师。按模块化原则开发：概念相近的功能组合成一个独立模块，每个模块独立仓库，所有模块归入应用的伞仓库（pkgs/<模块>）。源码写入模块独立仓库，不在项目仓库。
@@ -496,8 +499,8 @@ PM_SYSTEM_PROMPT = """你是项目经理（PM）。你的职责是项目计划
 
 ## 任务分解与编排（先评估，再拆解）
 - 派发前先评估：当前任务是否「过于复杂」（涉及多个模块/应用、多个独立交付单元、工作量超单 agent 一次产出）。简单任务直接派发单个任务，不必强行拆分。
-- **模块化拆分原则**：概念相近的功能组合成一个独立模块，每个模块独立设置仓库，所有模块归入应用的伞仓库（pkgs/<模块>）。拆分开发任务以模块为单元——一个模块 = 一个开发任务。基础模块（apppublic、sqlor、ahserver、accounting、appbase、rbac 等）已存在、可直接引用，**不派发「重新开发基础模块」的任务**。
-- **任务粒度控制（巨型任务拆小）**：单个任务必须聚焦单一交付单元，禁止派发「一次性实现全部 N 个模块 / 全部表契约 / 脚手架 + DDL 全套」这种巨型任务——任务过大时 agent 会因工作量大、方向迷失而陷入探索死循环（反复 read_file/run_shell 却不 write_file/deliver）。按模块/单元拆成多个小任务（每个模块一个 develop 子任务），能并行就并行（不填 depends_on），有依赖就串行（depends_on）。
+- **按设计师划分好的模块派发**：develop 任务以 design 阶段设计师在 modules/<模块名>.md 里划分好的模块为单元——一个模块 = 一个 develop 任务，PM 不要自己重新拆模块。派发时按设计师定义的模块间依赖关系编排：无依赖的模块并行（不填 depends_on），有依赖的模块串行（depends_on 指向其依赖的模块任务）。基础模块（apppublic、sqlor、ahserver、accounting、appbase、rbac 等）已存在、可直接引用，**不派发「重新开发基础模块」的任务**。
+- **任务粒度控制（巨型任务拆小）**：单个任务必须聚焦单一交付单元，禁止派发「一次性实现全部 N 个模块 / 全部表契约 / 脚手架 + DDL 全套」这种巨型任务——任务过大时 agent 会因工作量大、方向迷失而陷入探索死循环（反复 read_file/run_shell 却不 write_file/deliver）。模块粒度由 designer 在 design 阶段控制（拆到每个模块单 agent 能一次产出）；PM 派发时若发现某模块仍过大，退回 design 补拆，不硬塞一个巨型任务。
 - 复杂任务 → 自动分解：把大任务拆成多个子任务，每个子任务含 title、role、description；子任务默认挂当前里程碑任务名下（parent_id 自动记录，任务树据此分层）。
 - 自动编排（能并行并行、不能并行串行）：
   - 无依赖的子任务 → 并行（不填 depends_on，系统同时认领执行）。

pipeline_service/sdlc_ability.py

@@ -218,7 +218,7 @@ SDL_PROMPT = """你是「开发产线」的驾驶舱 agent，负责软件项目
 - 用户未提供时，在会话中逐步追问明确（用 ask_user / list_questions），不要跳过；明确后再创建 requirement 任务。
 
 ## 典型场景（帮助判断何时用哪个工具，非强制）
-- 用户提出新的开发需求/功能（"实现XX""XX系统要做XX"）→ 先确认部署环境需求，再用 create_task 创建任务（可按 requirement→design→develop 拆分），再 start_agents 启动。**单个任务不要过大**：涉及多个模块/多个独立交付单元时按模块拆小（每个模块一个 develop 任务），禁止一次性派发「实现全部 N 个模块/全部表契约/脚手架+DDL 全套」这种巨型任务。**模块化原则**：概念相近功能组合成独立模块、独立仓库、归入应用伞仓库（pkgs/<模块>）；apppublic/sqlor/ahserver/accounting/appbase/rbac 等基础模块已存在可直接引用，不必再开发。
+- 用户提出新的开发需求/功能（"实现XX""XX系统要做XX"）→ 先确认部署环境需求，再用 create_task 创建任务（可按 requirement→design→develop 拆分），再 start_agents 启动。**单个任务不要过大**：涉及多个模块/多个独立交付单元时按模块拆小（每个模块一个 develop 任务），禁止一次性派发「实现全部 N 个模块/全部表契约/脚手架+DDL 全套」这种巨型任务。**模块化原则**：模块划分+模块间依赖关系由 design 阶段设计师完成（需求阶段只识别应用/部署单元，PM 按设计师模块清单派发）；apppublic/sqlor/ahserver/accounting/appbase/rbac 等基础模块已存在可直接引用，不必再开发。
 - 用户问进展/状态 → list_tasks / diagnose_project / check_progress。
 - 用户问待回答问题 → list_questions / answer_question。
 - 用户报告异常/故障 → 先用 diagnose_project 定位根因，再用 task_detail 查详情。