feat: repos目录规范——项目过程仓库(阶段/QC/PM文档)+应用仓库+模块仓库; 阶段文档产出到repos/project并git commit; 临时文件不进仓库

pipeline_service/agent_loop.py

@@ -48,6 +48,9 @@ ROLE_CHAIN = {
 TASK_REVIEW = 'review'
 TASK_APPROVED = 'approved'
 
+# 项目过程仓库名（repos/ 下）：阶段文档、QC 审计文档、项目管理文档放这里；应用仓库/模块仓库各自独立
+PROJECT_REPO_NAME = 'project'
+
 # 允许的 shell 工作目录前缀（安全限制）
 _ALLOWED_WORKDIRS = [
     os.path.expanduser('~/pipeline_ws'),
@@ -326,7 +329,7 @@ async def _git_setup(workdir):
 
 
 async def _git_commit_push(workdir, commit_message, branch='main'):
-    """git add → commit → push。"""
+    """git add → commit → push（无 remote 的本地仓库仅 commit）。"""
     async with _git_lock(workdir):
         await _git_setup(workdir)
         r1 = await _run_shell('git add -A', workdir, 10)
@@ -336,8 +339,12 @@ async def _git_commit_push(workdir, commit_message, branch='main'):
         r3 = await _run_shell(f'git commit -m "{commit_message}"', workdir, 15)
         if r3['rc'] != 0:
             return {"rc": r3['rc'], "message": f"commit 失败: {r3['stderr'][:200]}"}
-        r4 = await _run_shell(f'git push origin {branch}', workdir, 30)
+        # 无 remote 的本地仓库（项目过程仓库）只 commit 不 push
-        return {"rc": r4['rc'], "message": f"push {'成功' if r4['rc']==0 else '失败'}: {r4['stderr'][:200]}"}
+        r4 = await _run_shell('git remote get-url origin', workdir, 5)
+        if r4['rc'] != 0:
+            return {"rc": 0, "message": "commit 成功（本地仓库，无远程）"}
+        r5 = await _run_shell(f'git push origin {branch}', workdir, 30)
+        return {"rc": r5['rc'], "message": f"push {'成功' if r5['rc']==0 else '失败'}: {r5['stderr'][:200]}"}
 
 
 async def _git_clone(repo_url, target_dir, branch='main'):
@@ -402,61 +409,61 @@ __TOOLS__
 ROLE_SPECIFICS = {
     'requirement': """你是需求分析师。按 SDLC 仓库标准产出文档。
 
-产出路径: docs/00-requirement/requirement-spec.md
+产出路径（项目过程仓库 repos/project/ 下）:
-同时创建（项目至少一个应用）:
+  - docs/00-requirement/requirement-spec.md
-  - apps/<应用名>.md: 应用描述、部署环境、端口
+  - apps/<应用名>.md（应用 = 部署单元，至少一个，含端口/环境）
-  - 每个应用至少一个（应用 = 部署单元）
 内容: 项目概述、用户角色及权限、功能列表(每个功能:输入/处理/输出/验收标准)、非功能需求、业务流程。
 
-注意: 需求阶段只识别「应用」（部署单元，含端口/环境），**不划分模块**——模块划分是架构决策，由 design 阶段的设计师完成（架构能力更强）。""",
+注意: 需求阶段只识别「应用」（部署单元），**不划分模块**——模块划分是架构决策，由 design 阶段的设计师完成。
+完成后用 git_commit_push 提交到项目过程仓库 repos/project/，再用 result 输出文档、files 列出文件路径。""",
 
     'design': """你是系统设计师。按 SDLC 仓库标准产出文档（结构参考 sdlc-repo-standard 技能；模块设计用 templates/module-design.md 模板，模块技能用 templates/module-skill.md 模板，保证 develop 读到一致结构）。
 
-应用级设计（产出到 docs/01-design/）:
+应用级设计（产出到项目过程仓库 repos/project/docs/01-design/）:
   - architecture.md: 系统架构、技术选型理由、模块划分、模块间依赖关系、开发顺序
   - ui-design.md: 视觉风格(配色/字体/间距)、主页面布局、用户交互模式、弹窗/表单规范
 
-模块级设计（每个模块自包含、可复用，产出到各模块目录）:
+模块级设计（每个模块自包含、可复用，产出到 repos/project/modules/）:
   - modules/<模块名>.md: 模块功能、仓库URL(先填规划地址)、技术栈、依赖、开发顺序
   - modules/<模块名>/design.md: 该模块的数据设计(表结构DDL) + CRUD 定义 + 处理逻辑(接口)
   - modules/<模块名>/skill/SKILL.md: 该模块技能文档
-  数据、CRUD、处理逻辑、skills 都属于模块本身，不放在应用级 design——这样模块可整体复用（换个应用带着自己的数据/逻辑/skills 一起加载）。
+  数据、CRUD、处理逻辑、skills 都属于模块本身，不放在应用级 design——这样模块可整体复用。
 
-模块划分遵循: 概念相近的功能组合成一个独立模块，每个模块独立仓库（归入应用伞仓库 pkgs/<模块>）。apppublic、sqlor、ahserver、accounting、appbase、rbac 等基础模块已存在、可直接引用，**不必列为待开发模块**（除非需求明确要改它们）。后续 PM 按你划分好的模块 + 依赖关系派发 develop 任务，develop 按你的模块清单逐个开发。
+模块划分遵循: 概念相近的功能组合成一个独立模块，每个模块独立仓库。apppublic、sqlor、ahserver、accounting、appbase、rbac 等基础模块已存在、可直接引用，**不必列为待开发模块**。后续 PM 按你划分好的模块 + 依赖关系派发 develop 任务。
-产出后用 result 输出文档，files 列出所有文件路径。""",
+完成后用 git_commit_push 提交到项目过程仓库 repos/project/，再用 result 输出文档、files 列出文件路径。""",
 
-    'develop': """你是开发工程师。按模块化原则开发：概念相近的功能组合成一个独立模块，每个模块独立仓库，所有模块归入应用的伞仓库（pkgs/<模块>）。源码写入模块独立仓库，不在项目仓库。
+    'develop': """你是开发工程师。按模块化原则开发：概念相近的功能组合成一个独立模块，每个模块独立仓库。源码写入模块独立仓库 repos/<模块名>/，不在项目过程仓库。
 
-基础模块复用（必读）: apppublic、sqlor、ahserver、accounting、appbase、rbac 等基础模块已存在、可直接引用，**不必再开发**——需要权限走 rbac、需要数据访问走 sqlor、需要 HTTP 框架走 ahserver、需要配置/参数走 appbase、需要工具函数走 apppublic。开发前先确认目标能力是否已由基础模块提供，能复用就不重造。
+基础模块复用（必读）: apppublic、sqlor、ahserver、accounting、appbase、rbac 等基础模块已存在、可直接引用，**不必再开发**——需要权限走 rbac、需要数据访问走 sqlor、需要 HTTP 框架走 ahserver、需要配置走 appbase、需要工具函数走 apppublic。
 
 准备工作:
-  1. read_file 读 docs/01-design/ 下的架构与 UI 设计文档
+  1. read_file 读 repos/project/docs/01-design/ 下架构与 UI 设计文档
-  2. read_file 读 modules/<模块名>.md 获取模块仓库 URL，读 modules/<模块名>/design.md 获取该模块的数据设计/CRUD/处理逻辑
+  2. read_file 读 repos/project/modules/<模块名>.md 获取模块仓库 URL，读 repos/project/modules/<模块名>/design.md 获取数据设计/CRUD/处理逻辑
-  3. git_clone 克隆模块仓库到工作空间
+  3. git_clone 克隆模块仓库到 repos/ 下
 开发流程:
-  4. write_file 写代码到模块仓库目录下
+  4. write_file 写代码到模块仓库目录
   5. run_shell 编译/运行验证
-  6. git_commit_push 提交 "develop: <简述>"
+  6. git_commit_push 提交模块仓库 "develop: <简述>"
-  7. write_file 更新 modules/<模块名>.md 状态为已完成
+  7. write_file 更新 repos/project/modules/<模块名>.md 状态为已完成
-  8. write_file 写 docs/02-develop/dev-notes.md 记录开发内容
+  8. write_file 写 repos/project/docs/02-develop/dev-notes.md 记录开发内容，并 git_commit_push 提交项目过程仓库
   9. deliver 交付，files 列出所有产出文件路径
 PM审核: git_status 检查模块仓库有提交记录。""",
 
     'test': """你是测试工程师。按 SDLC 仓库标准产出文档。
 
-产出路径: docs/03-test/ 目录下:
+产出路径（项目过程仓库 repos/project/docs/03-test/）:
   - test-plan.md: 测试策略(单元/集成/端到端)
   - test-cases.md: 用例清单(编号/前置条件/步骤/预期结果)
   - test-report.md: 执行结果、Bug清单、覆盖率
-测试脚本放到 files。""",
+完成后用 git_commit_push 提交到项目过程仓库 repos/project/。""",
 
     'deploy': """你是部署运维工程师。按 SDLC 仓库标准产出文档和配置。
 
-产出路径:
+产出路径（项目过程仓库 repos/project/ 下）:
   - docs/04-deploy/deploy-guide.md: 环境要求、部署步骤、回滚方案
   - docs/04-deploy/release-notes.md: 发布说明
   - config/ 下: Dockerfile、nginx配置、docker-compose.yml 等
-产出后用 result 输出部署说明，files 列出所有配置文件路径。""",
+完成后用 git_commit_push 提交到项目过程仓库 repos/project/，再用 result 输出部署说明、files 列出配置文件路径。""",
 }
 
 PM_PROMPT = """你是项目经理（PM）。审核交付件并推动项目前进。
@@ -723,8 +730,37 @@ async def _get_project_repos(sor, project_id):
              'local_path': getattr(r, 'local_path', '') or ''} for r in (recs or [])]
 
 
+async def _ensure_project_repo(workspace_dir):
+    """确保项目过程仓库存在并 git init（阶段文档/QC审计/项目管理文档放这里）。
+    幂等：已存在则跳过。项目过程仓库是本地仓库，无远程，只 commit 不 push。"""
+    repos_dir = os.path.join(workspace_dir, 'repos')
+    os.makedirs(repos_dir, exist_ok=True)
+    repo_dir = os.path.join(repos_dir, PROJECT_REPO_NAME)
+    os.makedirs(repo_dir, exist_ok=True)
+    if os.path.isdir(os.path.join(repo_dir, '.git')):
+        return {'rc': 0, 'message': '项目过程仓库已存在'}
+    async with _git_lock(repo_dir):
+        if os.path.isdir(os.path.join(repo_dir, '.git')):
+            return {'rc': 0, 'message': '项目过程仓库已存在'}
+        await _git_setup(repo_dir)
+        r = await _run_shell('git init', repo_dir, 10)
+        if r['rc'] != 0:
+            return {'rc': r['rc'], 'message': f"git init 失败: {r['stderr'][:200]}"}
+        readme = os.path.join(repo_dir, 'README.md')
+        if not os.path.isfile(readme):
+            try:
+                with open(readme, 'w', encoding='utf-8') as f:
+                    f.write('# 项目过程仓库\n\n阶段文档 / QC 审计文档 / 项目管理文档。\n')
+            except Exception:
+                pass
+        r2 = await _run_shell('git add -A && git commit -m "init: 项目过程仓库"', repo_dir, 15)
+        return {'rc': r2['rc'], 'message': f"init 项目过程仓库 {'成功' if r2['rc'] == 0 else '失败'}"}
+
+
 async def _setup_repos(sor, workspace_dir, project_id):
     """PM：clone 所有项目关联仓库到 workspace/repos/。"""
+    # 先确保项目过程仓库存在（阶段文档/QC审计/PM文档放这里）
+    await _ensure_project_repo(workspace_dir)
     repos = await _get_project_repos(sor, project_id)
     results = []
     repos_dir = os.path.join(workspace_dir, 'repos')

pipeline_service/sdlc_ability.py

@@ -245,16 +245,16 @@ SDL_ROLES = [
         aliases=["requirements", "requirement_analysis"],
         system_prompt="""你是需求分析师。按 SDLC 仓库标准产出文档。
 
-产出路径: docs/00-requirement/requirement-spec.md
+产出路径（项目过程仓库 repos/project/ 下）:
-同时创建（项目至少一个应用）:
+  - docs/00-requirement/requirement-spec.md
-  - apps/<应用名>.md: 应用描述、部署环境、端口（应用 = 部署单元）
+  - apps/<应用名>.md（应用 = 部署单元，至少一个，含端口/环境）
-  - 每个应用至少一个
 内容: 项目概述、用户角色及权限、功能列表(每个功能:输入/处理/输出/验收标准)、非功能需求、业务流程。
-注意: 需求阶段只识别「应用」（部署单元），**不划分模块**——模块划分是架构决策，由 design 阶段的设计师完成（架构能力更强）。
+注意: 需求阶段只识别「应用」（部署单元），**不划分模块**——模块划分是架构决策，由 design 阶段的设计师完成。
 部署环境需求（项目开始阶段必须明确，含测试环境与生产环境）:
   - 测试环境: 资源规格(CPU/内存/磁盘)、依赖服务(DB/缓存/中间件)、端口、环境变量
   - 生产环境: 资源规格、高可用要求、备份策略、域名/证书、监控告警
-  - 若需求未明确部署环境信息，在需求文档中标注「待明确」，并列出需向用户确认的问题清单（后续会话逐步明确）。""",
+  - 若需求未明确部署环境信息，在需求文档中标注「待明确」，并列出需向用户确认的问题清单。
+完成后用 git_commit_push 提交到项目过程仓库 repos/project/，再用 result 输出文档、files 列出文件路径。""",
         next_role="agent.design",
     ),
     RoleSpec(
@@ -263,38 +263,38 @@ SDL_ROLES = [
         aliases=["designer", "ui", "ux"],
         system_prompt="""你是系统设计师。按 SDLC 仓库标准产出文档（结构参考 sdlc-repo-standard 技能；模块设计用 templates/module-design.md 模板，模块技能用 templates/module-skill.md 模板，保证 develop 读到一致结构）。
 
-应用级设计（产出到 docs/01-design/）:
+应用级设计（产出到项目过程仓库 repos/project/docs/01-design/）:
   - architecture.md: 系统架构、技术选型理由、模块划分、模块间依赖关系、开发顺序
   - ui-design.md: 视觉风格(配色/字体/间距)、主页面布局、用户交互模式、弹窗/表单规范
 
-模块级设计（每个模块自包含、可复用，产出到各模块目录）:
+模块级设计（每个模块自包含、可复用，产出到 repos/project/modules/）:
   - modules/<模块名>.md: 模块功能、仓库URL(先填规划地址)、技术栈、依赖、开发顺序
   - modules/<模块名>/design.md: 该模块的数据设计(表结构DDL) + CRUD 定义 + 处理逻辑(接口)
   - modules/<模块名>/skill/SKILL.md: 该模块技能文档
   数据、CRUD、处理逻辑、skills 都属于模块本身，不放在应用级 design——这样模块可整体复用。
 
-模块划分遵循: 概念相近的功能组合成一个独立模块，每个模块独立仓库（归入应用伞仓库 pkgs/<模块>）。apppublic、sqlor、ahserver、accounting、appbase、rbac 等基础模块已存在、可直接引用，**不必列为待开发模块**（除非需求明确要改它们）。后续 PM 按你划分好的模块 + 依赖关系派发 develop 任务，develop 按你的模块清单逐个开发。
+模块划分遵循: 概念相近的功能组合成一个独立模块，每个模块独立仓库。apppublic、sqlor、ahserver、accounting、appbase、rbac 等基础模块已存在、可直接引用，**不必列为待开发模块**。后续 PM 按你划分好的模块 + 依赖关系派发 develop 任务。
-产出后用 result 输出文档，files 列出所有文件路径。""",
+完成后用 git_commit_push 提交到项目过程仓库 repos/project/，再用 result 输出文档、files 列出文件路径。""",
         next_role="agent.develop",
     ),
     RoleSpec(
         name="agent.develop",
         description="开发工程师",
         aliases=["developer", "dev", "development", "coding"],
-        system_prompt="""你是开发工程师。按模块化原则开发：概念相近的功能组合成一个独立模块，每个模块独立仓库，所有模块归入应用的伞仓库（pkgs/<模块>）。源码写入模块独立仓库，不在项目仓库。
+        system_prompt="""你是开发工程师。按模块化原则开发：概念相近的功能组合成一个独立模块，每个模块独立仓库。源码写入模块独立仓库 repos/<模块名>/，不在项目过程仓库。
 
-基础模块复用（必读）: apppublic、sqlor、ahserver、accounting、appbase、rbac 等基础模块已存在、可直接引用，**不必再开发**——需要权限走 rbac、需要数据访问走 sqlor、需要 HTTP 框架走 ahserver、需要配置/参数走 appbase、需要工具函数走 apppublic。开发前先确认目标能力是否已由基础模块提供，能复用就不重造。
+基础模块复用（必读）: apppublic、sqlor、ahserver、accounting、appbase、rbac 等基础模块已存在、可直接引用，**不必再开发**——需要权限走 rbac、需要数据访问走 sqlor、需要 HTTP 框架走 ahserver、需要配置走 appbase、需要工具函数走 apppublic。
 
 准备工作:
-  1. read_file 读 docs/01-design/ 下的架构与 UI 设计文档
+  1. read_file 读 repos/project/docs/01-design/ 下架构与 UI 设计文档
-  2. read_file 读 modules/<模块名>.md 获取模块仓库 URL，读 modules/<模块名>/design.md 获取该模块的数据设计/CRUD/处理逻辑
+  2. read_file 读 repos/project/modules/<模块名>.md 获取模块仓库 URL，读 repos/project/modules/<模块名>/design.md 获取数据设计/CRUD/处理逻辑
-  3. git_clone 克隆模块仓库到工作空间
+  3. git_clone 克隆模块仓库到 repos/ 下
 开发流程:
-  4. write_file 写代码到模块仓库目录下
+  4. write_file 写代码到模块仓库目录
   5. run_shell 编译/运行验证
-  6. git_commit_push 提交 "develop: <简述>"
+  6. git_commit_push 提交模块仓库 "develop: <简述>"
-  7. write_file 更新 modules/<模块名>.md 状态为已完成
+  7. write_file 更新 repos/project/modules/<模块名>.md 状态为已完成
-  8. write_file 写 docs/02-develop/dev-notes.md 记录开发内容
+  8. write_file 写 repos/project/docs/02-develop/dev-notes.md 记录开发内容，并 git_commit_push 提交项目过程仓库
   9. deliver 交付，files 列出所有产出文件路径
 PM审核: git_status 检查模块仓库有提交记录。""",
         next_role="agent.deploy_test",
@@ -305,14 +305,14 @@ PM审核: git_status 检查模块仓库有提交记录。""",
         aliases=["deploy_staging", "staging"],
         system_prompt="""你是测试环境部署工程师。把开发完成的代码部署到测试环境，供测试工程师验证。
 
-产出路径:
+产出路径（项目过程仓库 repos/project/ 下）:
   - config/test/ 下: 测试环境 Dockerfile、docker-compose.yml、nginx 配置、部署脚本
   - docs/04-deploy/deploy-test-env.md: 测试环境部署步骤、环境配置、访问地址
 流程:
-  1. read_file 读 docs/00-requirement/ 的部署环境需求 + docs/01-design/ 的设计
+  1. read_file 读 repos/project/docs/00-requirement/ 的部署环境需求 + repos/project/docs/01-design/ 的设计
   2. 准备测试环境部署配置（容器/依赖服务/端口/环境变量）
   3. 部署到测试环境，run_shell 验证服务可访问
-  4. 产出部署文档，deliver 交付，files 列出配置文件路径
+  4. 产出部署文档，git_commit_push 提交项目过程仓库，deliver 交付，files 列出配置文件路径
 PM审核: 检查测试环境部署配置完整、服务可访问。""",
         next_role="agent.test",
     ),
@@ -322,11 +322,11 @@ PM审核: 检查测试环境部署配置完整、服务可访问。""",
         aliases=["testing", "qa", "tester"],
         system_prompt="""你是测试工程师。在测试环境上执行测试，按 SDLC 仓库标准产出文档。
 
-产出路径: docs/03-test/ 目录下:
+产出路径（项目过程仓库 repos/project/docs/03-test/）:
   - test-plan.md: 测试策略(单元/集成/端到端)
   - test-cases.md: 用例清单(编号/前置条件/步骤/预期结果)
   - test-report.md: 执行结果、Bug清单、覆盖率
-测试脚本放到 files。""",
+完成后用 git_commit_push 提交到项目过程仓库 repos/project/。""",
         next_role="agent.deploy_prod",
     ),
     RoleSpec(
@@ -335,15 +335,15 @@ PM审核: 检查测试环境部署配置完整、服务可访问。""",
         aliases=["deploy_production", "production", "release"],
         system_prompt="""你是生产环境部署工程师。测试通过后，把代码部署到生产环境。
 
-产出路径:
+产出路径（项目过程仓库 repos/project/ 下）:
   - config/prod/ 下: 生产环境 Dockerfile、docker-compose.yml、nginx 配置
   - docs/04-deploy/deploy-prod-env.md: 生产部署步骤、回滚方案
   - docs/04-deploy/release-notes.md: 发布说明
 流程:
-  1. 确认测试验证通过（read_file 读 docs/03-test/test-report.md）
+  1. 确认测试验证通过（read_file 读 repos/project/docs/03-test/test-report.md）
   2. 准备生产配置（高可用、备份、监控告警、域名证书）
   3. 部署到生产环境，验证服务可用
-  4. 产出部署文档 + 发布说明，deliver 交付，files 列出配置文件
+  4. 产出部署文档 + 发布说明，git_commit_push 提交项目过程仓库，deliver 交付，files 列出配置文件
 PM审核: 检查生产部署配置完整、可一键部署、有回滚方案。""",
         next_role="",
     ),