pipeline_core/skills_library/all/sdlc-repo-standard/SKILL.md

name	description
sdlc-repo-standard	所有角色产出交付件前必读——各角色产出内容 + 交付件文件格式 + 通用交付约定（deliver + files 列出产出路径）。不加载会只写文档不列文件、漏产出。目录落点以 project-directory-spec 为准。

SDLC 交付件规格

⚠️ 项目目录结构（机构工作空间 projects/apps/modules 三目录、项目下 docs/ + env/ + {应用名}_spec.json、应用/模块代码落机构 apps/ modules/）以 project-directory-spec 技能为唯一权威，本技能不再定义目录结构，只定义 SDLC 交付件的内容格式与角色产出行为准则。

模块说明文件 projects/{项目名}/docs/01-design/modules/{模块名}.md

# <模块名>
- **功能**: <一句话描述>
- **仓库**: git@git.opencomputing.cn:org/<repo>.git
- **技术栈**: <语言/框架>
- **状态**: <规划中/开发中/已完成>
- **负责人**: <role>
- **依赖模块**: <列出依赖的其他模块>
- **开发顺序**: <拓扑序中的位置，被依赖的先开发>
- **关联应用**: <属于哪个应用>

模块级设计 projects/{项目名}/docs/01-design/modules/{模块名}/

每个模块是自包含、可复用的单元，数据设计放模块内而非应用级：

projects/{项目名}/docs/01-design/modules/{模块名}/
├── design.md            # 数据设计(表结构DDL) + CRUD 定义 + 处理逻辑(接口)
└── skill/SKILL.md       # 模块技能文档（develop agent 参考）

原则: 数据、CRUD、处理逻辑、skills 都属于模块本身，不放在应用级 design 里，这样模块可整体复用。

模板: design.md 用 templates/module-design.md（模块元信息 / 数据设计→models / CRUD→json / 处理逻辑→dspy / 入口菜单）；skill/SKILL.md 用 templates/module-skill.md（frontmatter / 概述 / 数据模型 / 关键接口 / 陷阱 / 依赖）。

应用说明 projects/{项目名}/{应用名}_spec.json

应用说明是 spec.json（不是 markdown 说明文件），每个 app 一个，描述引用/生成模块（格式以 project-directory-spec 第四节为准）：

{
  "app": "hrs6",
  "referenced_modules": ["apppublic", "sqlor", "ahserver", "rbac"],
  "generated_modules": ["organization", "payroll", "recruitment"]
}

• referenced_modules：引用的模块（机构 modules/ 已有的）
• generated_modules：需要生成的模块（develop 产出到机构 modules/）

通用交付约定（所有角色）

• 完成后用 deliver 交付，files 列出所有产出文件路径——这是 QC/PM 核验「实际产出」的依据，别只写文档不列文件
• git 提交由 PM 审核通过后系统统一执行，角色无需自己提交（develop 例外：模块/应用仓库本地 commit 是 QC 核验的硬证据，见下）
• 复杂度评估（所有角色必附，2026-09-14 起）：每个任务开工先自评复杂度，deliver 时必须在 summary 或交付文档末尾附「复杂度评估」段——
  1. 判定：本任务及后续派生工作是否复杂。复杂信号：涉及多个模块/应用、多个独立交付单元、 工作量超单 agent 一次产出（预估 >1 个聚焦交付件）、存在可并行的独立子工作。
  2. 简单 → 写明「复杂度评估：简单，单交付单元，无需拆分」。
  3. 复杂 → 给出建议拆分方案：子任务清单（每条 title/role/description/依赖关系， 能并行的标并行、有依赖的标 depends_on 前序），供 PM 编排派发。
  4. 执行中发现任务过大 → 立即用 ask_question/raise_problem 上报 PM 请求拆分， 禁止硬撑巨型任务导致探索死循环（30 轮耗尽无产出）。
  • 编排决策权在 PM（create_tasks/create_sub_tasks），角色只提供评估+建议，不越权派发。

各角色产出内容（落点路径见 project-directory-spec）

配图统一硬规定（2026-09-15 用户要求，全角色适用）

需求文档、设计文档（及一切 SDLC 交付文档）中出现的各种图——四张图（业务对象/生命周期/数据所有权/业务依赖）、系统架构图、模块依赖图、部署拓扑图、业务流程图、界面效果图等——必须用 invoke_model 调平台 t2i（文生图）/i2i（图生图）模型生成真实图片，以 ![图名](产物URL) 嵌入正文：

• model 留空即自动选型；task 写清画面主体/层次/风格（商务风、白底、含中文标注）/图中文字要求；改造已有图带输入图 URL 走 i2i。
• 禁止 mermaid/plantuml 代码块、ASCII 字符画、文本框线拼「示意图」代替真图。
• 文字版要点（对象关系清单/状态机描述/归属表格）可作为图的补充说明保留，但图本体必须是生成图片。
• 唯一逃逸阀：平台无任何图像生成模型（invoke_model 返回 FAIL）→ 按文字模板产出并如实标注「配图缺失：平台无可用文生图模型」，不伪造、不因此阻塞交付。
• QC/评审核对项：交付文档中的图若非真实生成图片（发现 mermaid/ASCII/文本图）= 不过，退回意见注明「图必须用 t2i/i2i 模型生成」。

requirement（需求分析师）

• 内容: 项目概述、用户角色及权限、功能列表（含验收标准）、非功能需求、业务流程
• 功能清单 + IFPUG 功能点计算: 按 function-point-counting 技能产出 docs/00-requirement/fp-report.md（功能明细/汇总 UFP/待确认/假设 四件套，fp_calc.py 规则引擎计算，禁 LLM 心算）
• 模块初步划分: 按 module-partitioning 技能（八原则+四张图）产出 docs/00-requirement/module-partition.md（四张图 + 模块清单 + 复用判定 + 开发顺序拓扑）；能用已有模块的必须复用已有模块，禁止 1~2 表一模块
• 不划分 app: 一个项目有几个 app（应用）是架构决策，由 design 阶段设计师根据需求分析划分——requirement 只描述功能、不定 app 数量、不写 {应用名}_spec.json
• 小功能点落库: 按 feature-granularity-and-testing 粒度用 propose_feature 落库 sd_features（测试/验收锚点，与 IFPUG 规模度量是两套口径都要产出）

design（系统设计师）

• 模块划分复核+细化: 以 requirement 的 module-partition.md 为上游，按 module-partitioning 八原则+四张图复核细化（调整必须写明依据，禁止无证据推翻），落定模块间接口契约 + 依赖图 + 开发顺序
• 功能细化: 把需求功能点细化到模块内可开发规格（页面交互/数据表归属/CRUD/接口契约），产出功能点→模块→接口三级追溯表，覆盖核对无遗漏
• 应用划分: 根据需求分析划分一个项目有几个 app（应用）——需求只描述功能、不定 app 数量，设计师按「部署单元 / 功能聚合 / 用户边界」划到 N 个 app（每个 app = 一个入口一个端口），产出对应的 {应用名}_spec.json
• 应用级: architecture.md（系统架构、模块划分复核结论、模块间依赖、开发顺序）+ ui-design.md（视觉风格/主页面/交互模式/弹窗规范）
• 模块级: 每个模块在 projects/{项目名}/docs/01-design/modules/{模块名}/ 下产出 design.md（数据设计/CRUD/处理逻辑）+ skill/SKILL.md
• 更新: docs/01-design/modules/ 下各模块的技术栈、依赖关系、开发顺序

develop（开发工程师）

• 源码: 应用写入机构 apps/{应用名}/、模块写入机构 modules/{模块名}/（不在项目目录下）
• 开发说明: projects/{项目名}/docs/02-develop/dev-notes.md
• 行为准则:
  1. 读 {应用名}_spec.json 确认引用的模块（referenced_modules）和要生成的模块（generated_modules）
  2. 在机构 modules/{模块名}/ 下开发模块代码，apps/{应用名}/ 下开发应用代码
  3. write_file 写代码到机构 modules/{模块名}/ 或 apps/{应用名}/
  4. run_shell 编译验证
  5. git_commit_push 提交模块/应用仓库
  6. 更新 spec.json 或模块说明状态
  7. deliver 交付

test（测试工程师）

• 内容: test-plan.md、test-cases.md、test-report.md

deploy（部署工程师）

• 内容: deploy-guide.md、release-notes.md
• 部署前: 机构 apps/ 和 modules/ 下应用使用到的仓库都要设置远程仓库（git remote add origin <远程地址>）

PM（项目经理）

• 审核要点:
  • 每个阶段检查交付件已受控提交
  • develop: 必须检查机构 apps/{应用名}/、modules/{模块名}/ 对应仓库有 git commit
  • 每个阶段检查 {应用名}_spec.json 是否随进度更新

项目复盘（PM，项目完结后的回顾任务）

• 落点: projects/{项目名}/docs/02-retrospective/retrospective.md
• 内容结构（五段，缺一不合格）:
  1. 统计：问题总数 / 可复用数 / 提议数；重做次数、冒泡次数、Bug 数、工期
  2. 问题清单：逐条列出（类型：冒泡/退回/缺口/Bug，问题，解决方法）
  3. 提议清单：每条提议的名称 + 目标技能（修改哪个/新建）
  4. 未提提议的问题及理由（一次性问题写明为何不可复用）
  5. 结论：本项目沉淀的可复用经验一句话总结