建模实现设计

要解决的具体问题

在应用或模块的建模开发流程中，概要设计与代码实现之间往往缺少一个稳定、可追溯的中间层。需求边界如果没有被明确确认，后续的页面结构、模块身份编码和任务归属就容易发散，导致实现设计与任务清单不一致，甚至出现凭空编造页面或控件 ID 的情况。modeling-design 用于在已确认概要设计的前提下，产出结构化的实现设计包与可被外部 Skill 消费的任务清单，减少设计漂移。

核心能力与关键步骤

1. 概要设计确认

该阶段只做需求边界澄清，不产出实现细节。必须按最小需求点判定 新增类 / 修改类 / 混合类 / 平台不支持类；混合类会拆分处理。对于修改类需求，会派发 modeling-lowcode-code-trace-index 的页面入口定位模式获取真实页面入口；modeling-design 只提供定位线索并消费结果，不会用本地搜索或手工读取元数据替代。应用编码、模块分组编码和模块编码在此阶段只读获取并明确，作为后续稳定输入。

2. 实现设计包生成

只有在用户明确确认进入实现设计后，才会基于 概要设计.md 生成实现设计包。页面结构以概要设计中的信息架构和页面清单为唯一来源；如需调整，必须先回写并重新确认概要设计。修改类动作只有在页面动作服务依赖清单判定需要链路分析时，才会生成或消费前后端代码链路分析。

3. 任务编排

生成外部 Skill 可消费的任务清单，但不会执行外部 Skill。零代码元数据和页面绑定任务归入 /nocode-agent，后端实现任务归入 /lowcode-agent；人工任务只写成可直接处理和验收的事项卡，不写入执行方式或下游消费等路由字段。

4. 实现设计概览

基于已完成的 实现设计.md、代码规划包/ 和任务清单，使用 scripts/实现设计概览模板.html 与 scripts/generate_summary.js 生成 实现设计概览.html。概览只能从上述来源提炼，不会改写来源文档；来源文档未明确写出的内容会标记为待人工确认。

适用边界与注意点

• 只生成建模实现设计包和任务清单，不执行下游实现。
• 不直接修改 code/ 元数据 JSON，不编写或修改后端业务代码，也不处理移动端需求规格设计。
• 概要设计未确认前，不会创建实现设计、任务清单或实现设计概览。
• 新增类不会编造既有页面 ID、控件 ID 或按钮 ID；修改类找不到真实入口时会写 未找到，待人工确认。
• 平台不支持事项会转为人工任务，不生成页面、接口、链路分析或后端实现任务。
• code/ 下的元数据只读仅用于应用和模块身份识别，不替代页面入口定位或代码链路分析。