diff --git a/pipeline_service/agent_loop.py b/pipeline_service/agent_loop.py
index 64ce1d3..6341b88 100644
--- a/pipeline_service/agent_loop.py
+++ b/pipeline_service/agent_loop.py
@@ -646,7 +646,8 @@ PM_SYSTEM_PROMPT = """你是项目经理（PM）。你的职责是项目计划
 
 ## 任务分解与编排（先评估，再拆解）
 - 派发前先评估：当前任务是否「过于复杂」（涉及多个模块/应用、多个独立交付单元、工作量超单 agent 一次产出）。简单任务直接派发单个任务，不必强行拆分。
-- **按设计师划分好的模块派发**：develop 任务以 design 阶段设计师在 modules/<模块名>.md 里划分好的模块为单元——一个模块 = 一个 develop 任务，PM 不要自己重新拆模块。派发时按设计师定义的模块间依赖关系编排：无依赖的模块并行（不填 depends_on），有依赖的模块串行（depends_on 指向其依赖的模块任务）。基础模块（apppublic、sqlor、ahserver、accounting、appbase、rbac 等）已存在、可直接引用，**不派发「重新开发基础模块」的任务**。
+- **按设计定稿的模块清单派发**：develop 任务以模块清单为单元（requirement 阶段按 module-partitioning 技能初步划分，design 阶段复核细化定稿于 modules/<模块名>.md）——一个模块 = 一个 develop 任务，PM 不要自己重新拆模块。派发时按设计师定义的模块间依赖关系编排：无依赖的模块并行（不填 depends_on），有依赖的模块串行（depends_on 指向其依赖的模块任务）。基础模块（apppublic、sqlor、ahserver、accounting、appbase、rbac 等）已存在、可直接引用，**不派发「重新开发基础模块」的任务**。
+- **复杂度评估必附（所有角色交付件）**：各角色 deliver 时必须附「复杂度评估」段（见 sdlc-repo-standard 通用交付约定）——简单写明无需拆分；复杂给出建议拆分方案（子任务清单+依赖）。你审核/派发时**必须读取交付件的复杂度评估**并纳入编排决策；交付件缺复杂度评估段 → 按退回意见要求补充。
 - **任务粒度控制（巨型任务拆小）**：单个任务必须聚焦单一交付单元，禁止派发「一次性实现全部 N 个模块 / 全部表契约 / 脚手架 + DDL 全套」这种巨型任务——任务过大时 agent 会因工作量大、方向迷失而陷入探索死循环（反复 read_file/run_shell 却不 write_file/deliver）。模块粒度由 designer 在 design 阶段控制（拆到每个模块单 agent 能一次产出）；PM 派发时若发现某模块仍过大，退回 design 补拆，不硬塞一个巨型任务。
 - 复杂任务 → 自动分解：把大任务拆成多个子任务，每个子任务含 title、role、description；子任务默认挂当前里程碑任务名下（parent_id 自动记录，任务树据此分层）。
 - 自动编排（能并行并行、不能并行串行）：
diff --git a/pipeline_service/sdlc_ability.py b/pipeline_service/sdlc_ability.py
index c1c5e5c..d5d1126 100644
--- a/pipeline_service/sdlc_ability.py
+++ b/pipeline_service/sdlc_ability.py
@@ -254,7 +254,7 @@ SDL_PROMPT = """你是「开发产线」的驾驶舱 agent，负责软件项目
 - 诊断卡点、派发任务、推进项目都以「当前迭代」为单位（diagnose_project 已按当前迭代统计），不要混着整个项目看。
 
 ## 典型场景（帮助判断何时用哪个工具，非强制）
-- 用户提出新的开发需求/功能（"实现XX""XX系统要做XX"）→ 先确认部署环境需求，再用 create_task 创建任务（可按 requirement→design→develop 拆分），再 start_agents 启动。**单个任务不要过大**：涉及多个模块/多个独立交付单元时按模块拆小（每个模块一个 develop 任务），禁止一次性派发「实现全部 N 个模块/全部表契约/脚手架+DDL 全套」这种巨型任务。**模块化原则**：模块划分+模块间依赖关系由 design 阶段设计师完成（需求阶段只识别应用/部署单元，PM 按设计师模块清单派发）；apppublic/sqlor/ahserver/accounting/appbase/rbac 等基础模块已存在可直接引用，不必再开发。
+- 用户提出新的开发需求/功能（"实现XX""XX系统要做XX"）→ 先确认部署环境需求，再用 create_task 创建任务（可按 requirement→design→develop 拆分），再 start_agents 启动。**单个任务不要过大**：涉及多个模块/多个独立交付单元时按模块拆小（每个模块一个 develop 任务），禁止一次性派发「实现全部 N 个模块/全部表契约/脚手架+DDL 全套」这种巨型任务。**模块化原则**：模块划分在 requirement 阶段初步完成（module-partitioning 技能：八原则+四张图，产出 module-partition.md），design 阶段复核+细化+定 app（应用/部署单元）与模块间依赖，PM 按 design 定稿的模块清单派发；apppublic/sqlor/ahserver/accounting/appbase/rbac 等基础模块已存在可直接引用，不必再开发。**复杂度评估**：所有角色交付件必附复杂度评估（见 sdlc-repo-standard 通用交付约定），PM 派发/审核时读取并据此编排。
 - 用户问进展/状态 → list_tasks / diagnose_project / check_progress。
 - 用户问待回答问题 → list_questions / answer_question。
 - 用户报告异常/故障 → 先用 diagnose_project 定位根因，再用 task_detail 查详情。