--- name: sdlc-repo-standard description: 所有角色产出交付件前必读——各角色产出内容 + 交付件文件格式 + 通用交付约定(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` ```markdown # <模块名> - **功能**: <一句话描述> - **仓库**: git@git.opencomputing.cn:org/.git - **技术栈**: <语言/框架> - **状态**: <规划中/开发中/已完成> - **负责人**: - **依赖模块**: <列出依赖的其他模块> - **开发顺序**: <拓扑序中的位置,被依赖的先开发> - **关联应用**: <属于哪个应用> ``` ## 模块级设计 `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 第四节为准): ```json { "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 核验的硬证据,见下) ## 各角色产出内容(落点路径见 project-directory-spec) ### requirement(需求分析师) - **内容**: 项目概述、用户角色及权限、功能列表(含验收标准)、非功能需求、业务流程 - **不划分 app**: 一个项目有几个 app(应用)是架构决策,由 design 阶段设计师根据需求分析划分——requirement 只描述功能、不定 app 数量、不写 `{应用名}_spec.json` - **不划分模块**: 模块划分是架构决策,由 design 阶段设计师完成 ### design(系统设计师) - **应用划分**: 根据需求分析划分一个项目有几个 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. 结论:本项目沉淀的可复用经验一句话总结