@pm_zhousl/xinyun-ai-init 1.4.0 → 1.5.0

package/init/xinyun-ai-init/README.md

@@ -2,7 +2,7 @@
 
 本目录是“欣芸技术开发 Agent 流”的初始化包，负责把完整 AI 执行要求下发到目标项目。
 
-当前规则版本：`1.4.0`。
+当前规则版本：`1.5.0`。
 
 ## Codex 一句话入口
 
@@ -26,7 +26,7 @@ AI 读取本文件后，必须按以下方式执行：
 
 1. 如果当前项目没有 `xinyun-ai/`，进入极速初始化模式。
 2. 如果当前项目已有 `xinyun-ai/`，进入升级检查模式。
-3. 用户发送 Codex 一句话入口后，视为已授权 AI 按本初始化包创建或补齐最小 `xinyun-ai/` 与极简 `AGENTS.md`。
+3. 用户发送 Codex 一句话入口后，视为已授权 AI 按本初始化包创建或补齐最小 `xinyun-ai/`、`xinyun-ai/team/` 与极简 `AGENTS.md`。
 4. 代码整改前必须先输出改动计划，等待用户明确确认后才能执行。
 5. 涉及 SQL / 数据库改动时，必须单独输出 SQL 执行提醒。
 6. 非项目开发内容不要沉淀。
@@ -38,8 +38,9 @@ AI 读取本文件后，必须按以下方式执行：
 12. 识别 ThinkPHP、uni-app、微信小程序时必须输出证据路径、证据类型、识别状态和覆盖范围，遵守读取预算。
 13. 多仓库 Git 只做只读索引与端口映射，不执行任何 Git 写操作。
 14. 字段新增、删除、重命名、类型 / 含义变化、API 映射或前端展示变化时，先做有边界的字段影响审视。
-15. 首次初始化不执行语言级语法检查、lint、typecheck、测试或构建命令；本机缺少运行时只记录为待确认，不展开长解释。
-16. 完成后用中文输出初始化或升级结果、项目导读、待确认问题和后续短指令。
+15. 初始化时创建 AI 项目团队责任闭环：5 个逻辑角色、5 个 JSON 配置、5 份职责确认记录和 5 份角色理解记录。
+16. 首次初始化不执行语言级语法检查、lint、typecheck、测试或构建命令；本机缺少运行时只记录为待确认，不展开长解释。
+17. 完成后用中文输出初始化或升级结果、项目导读、团队责任状态、待确认问题和后续短指令。
 
 ## 初始化授权边界
 
@@ -47,8 +48,12 @@ CLI 只负责生成 `xinyun-ai-init/`，不创建 `xinyun-ai/`，也不修改业
 
 用户发送一句话入口后，AI 可以按本 README 和 `templates/` 创建或补齐首次最小落盘清单。
 
+v1.5.0 起，首次最小 AI 工作区授权包含 `xinyun-ai/team/` 团队责任闭环控制文件：5 个逻辑角色、5 个 JSON 配置、5 份 `confirmations/<roleId>.md` 和 5 份 `understandings/<roleId>.md`。
+
 该授权只覆盖 AI 工作区初始化，不代表授权修改业务代码、配置、数据库、依赖、构建脚本、测试逻辑、API 行为、UI 行为或业务流程。
 
+团队角色是本地逻辑配置，不自动创建外部人员账号、外部 AI 会话或无限会话；未知人员、会话和确认人使用 `null`，不得虚构。
+
 ## 改动计划与执行确认
 
 用户提出“帮我改”“修复”“处理一下”“优化一下”只代表提出需求，不代表授权执行。
@@ -344,6 +349,22 @@ xinyun-ai/project/项目导读.md
 xinyun-ai/project/项目完整性检查.md
 xinyun-ai/workstreams/README.md
 xinyun-ai/index/project-index.json
+xinyun-ai/team/README.md
+xinyun-ai/team/roles.json
+xinyun-ai/team/members.json
+xinyun-ai/team/assignments.json
+xinyun-ai/team/responsibility-matrix.json
+xinyun-ai/team/file-ownership.json
+xinyun-ai/team/understandings/project-owner.md
+xinyun-ai/team/understandings/project-product.md
+xinyun-ai/team/understandings/chief-engineer.md
+xinyun-ai/team/understandings/programmer.md
+xinyun-ai/team/understandings/test-reviewer.md
+xinyun-ai/team/confirmations/project-owner.md
+xinyun-ai/team/confirmations/project-product.md
+xinyun-ai/team/confirmations/chief-engineer.md
+xinyun-ai/team/confirmations/programmer.md
+xinyun-ai/team/confirmations/test-reviewer.md
 ```
 
 首次不要创建大量规则、模板、脚本和业务沉淀目录。后续根据任务按需补齐。
@@ -481,6 +502,124 @@ xinyun-ai/global-review/
 - 验证层
 - 交接层
 
+## AI 项目团队与责任闭环
+
+初始化时必须创建 `xinyun-ai/team/`，用于记录本地 AI 协作团队、职责确认、角色理解、任务责任和文件目录责任。
+
+默认逻辑角色：
+
+- `project-owner`：项目负责人，负责需求最终确认、业务验收和发布授权。
+- `project-product`：项目产品，负责需求整理、任务拆分和产品验收建议。
+- `chief-engineer`：总工 / 技术负责人，负责技术方案、架构风险和技术最终确认。
+- `programmer`：程序员，按确认范围执行代码、配置和测试任务。
+- `test-reviewer`：测试审查员，独立测试、发布阻断判断和测试结论，不修改代码。
+
+首次必须创建：
+
+```text
+xinyun-ai/team/
+  README.md
+  roles.json
+  members.json
+  assignments.json
+  responsibility-matrix.json
+  file-ownership.json
+  understandings/<roleId>.md
+  confirmations/<roleId>.md
+```
+
+`roles.json`、`members.json`、`assignments.json`、`responsibility-matrix.json`、`file-ownership.json` 必须是有效 JSON。5 个逻辑角色各有一份 `confirmations/<roleId>.md` 和一份 `understandings/<roleId>.md`；`roleId` 必须来自 `roles.json`，不得用显示名称代替。
+
+团队入口注册：
+
+- `xinyun-ai/manifest.json` 必须包含 `capabilities.teamResponsibilityClosure: true`。
+- `xinyun-ai/manifest.json` 必须登记 `team.directory`、`roles`、`members`、`assignments`、`responsibilityMatrix`、`fileOwnership`、`understandingsDirectory`、`confirmationsDirectory` 这 8 个相对路径。
+- `xinyun-ai/index/project-index.json` 必须登记 `team.enabled`、`directory`、`roleCount=5`、`confirmationCount=5`、`status=pending-confirmation` 和同名 `paths`。
+- 注册路径必须与实际文件系统路径逐项一致。
+
+未知绑定规则：
+
+- 默认只创建逻辑角色和待绑定成员槽位，不虚构真实人员。
+- 未绑定真实人员或会话时，`personId`、`sessionId`、职责确认记录中的 `memberId`、`confirmedBy` 和 `confirmedAt` 使用 `null`。
+- `confirmations/<roleId>.md` 和 `understandings/<roleId>.md` 的 `createdAt`、`updatedAt` 必须存在且为 ISO 8601 时间；首次落盘可使用模板初始时间或替换为当前时间，但不得留空。
+- 不因为角色数量增加而自动创建多个会话或外部账号。
+
+状态分层：
+
+- 角色生命周期：`unassigned`、`assigned`、`onboarding`、`ready`、`blocked`、`disabled`。
+- 职责确认状态：`pending`、`confirmed`、`adjustment-required`。
+- 任务分配状态：`pending`、`assigned`、`accepted`、`executing`、`paused`、`blocked`、`completed`、`cancelled`。
+- `status=paused` 时必须填写 `pauseReason`，允许值至少包括 `out-of-scope`、`awaiting-confirmation`、`execution-failed`、`user-requested`；其他状态的 `pauseReason` 必须为 `null`。
+- 确认人不可用或发生成员冲突时使用 `status=blocked`，并填写 `blockedReason=approver-unavailable` 或 `member-conflict`。
+
+可执行前置条件：
+
+- 成员已绑定。
+- 角色生命周期为 `ready`。
+- 职责确认状态为 `confirmed`。
+- 角色理解记录为 `ready`。
+- 任务执行人和确认人不冲突。
+
+成员级确认冲突：
+
+- 执行人不得直接作为自己的最终确认人。
+- 最终确认关系必须在任务分配记录中落到成员 ID。
+- `memberId` 不得等于 `technicalApproverMemberId`、`businessApproverMemberId` 或 `publishAuthorizerMemberId`。
+- `roles.json` 中的默认确认角色只用于候选人推荐，不构成授权，也不能覆盖成员级冲突校验。
+- 总工为执行人时不得回落为自己确认自己。
+- 没有可用技术、业务或发布确认成员时，任务保持 `blocked` / 待分配，不得自动使用执行成员、虚构成员或空确认通过。
+- 程序员不得担任技术最终确认人、业务最终确认人或发布授权人；本版本不设置例外。
+
+角色理解记录：
+
+- 每个角色按照自己的职责读取项目内容，生成独立理解记录。
+- 理解记录必须包含 `recordId`、`roleId`、`memberId`、`status`、`readScope`、`readBudget`、`unreadablePaths`、`confirmedFacts`、`inferences`、`pendingQuestions`、`risks`、`evidence`、`coverage`、`executionEligible`、`createdAt`、`updatedAt`。
+- 理解记录状态：`pending`、`reading`、`ready`、`partial`、`blocked`。
+- 角色理解不等于代码修改授权；即使 `executionEligible=true`，仍必须有已确认任务单。
+- 不要求所有角色初始化时全量扫描业务代码。
+
+任务责任字段：
+
+```md
+- 需求负责人：
+- 技术负责人 / 总工：
+- 执行人：
+- 测试审查人：
+- 技术最终确认人：
+- 业务最终确认人：
+- 发布授权人：
+```
+
+文件目录责任和变更核对：
+
+```md
+## 预计更新文件目录
+- 文件或目录：
+- 文件类型：
+- 负责角色：
+- 执行角色：
+- 审查角色：
+- 最终确认角色：
+
+## 实际更新文件目录
+- 已修改：
+- 新增：
+- 删除：
+- 未修改：
+- 超出预计范围：
+- 是否需要重新确认：
+```
+
+- 目录记录以相对 `repoRoot` 的正斜线路径为准，跨仓库必须分别记录。
+- 文件、目录、通配符分别通过 `pathType` 标注；`pathType` 只能是 `file`、`directory` 或 `glob`。
+- 路径不得包含 `..`。
+- 删除和重命名必须记录旧路径，重命名还必须记录新路径。
+- 生成文件必须列出实际输出路径，不得只写“生成相关文件”。
+- `xinyun-ai/team/**`、`xinyun-ai/current-task.md`、`xinyun-ai/index/session-current.md`、`xinyun-ai/handoffs/**` 属于控制文件，计入实际更新记录，但与业务代码修改分栏统计。
+- 实际目录通过文件清单和 diff 只读核对。
+- 发现未授权路径后，任务状态改为 `paused`、`pauseReason=out-of-scope`，记录责任人、发现人、影响范围和重新确认人。
+- 不得使用未定义状态 `paused-out-of-scope`。
+
 ## 双会话执行闭环（MVP）
 
 复杂改动可使用一个主会话 + 一个执行会话的手工协作闭环。普通咨询、只读分析和不涉及文件修改的任务仍可使用单会话。
@@ -634,8 +773,9 @@ npx --yes @pm_zhousl/xinyun-ai-init@latest --force
 6. 数据库、API、测试体系发现情况。
 7. CodeGraph 与索引状态。
 8. Git 模式、涉及仓库、当前分支和工作区状态。
-9. 待确认问题。
-10. 后续日常开发和问题排查短指令。
+9. AI 项目团队状态：团队目录、5 个角色、5 个职责确认记录、5 个角色理解记录、manifest / project-index 路径注册。
+10. 待确认问题。
+11. 后续日常开发和问题排查短指令。
 
 交付输出要求：
 

package/init/xinyun-ai-init/rules/directory-self-completion.md

@@ -16,3 +16,7 @@
 - 识别到端口框架线索时，可按需补齐 `workstreams/<端>/`，记录 ThinkPHP / uni-app / 微信小程序识别证据、证据类型、发现预算、覆盖范围、`未在项目中发现` 或 `状态未知`。
 - 识别到多仓库 Git 结构时，可按需补齐端口 Git 只读索引，记录 `repoRoot`、`path`、`workstream`、`kind`、`parentRepo`、`branch`、`remote`、`status`、`evidence`，不得执行 Git 写操作。
 - 触发字段影响审视时，可按需补齐字段审视记录，记录字段分类、检索根目录、排除项、CodeGraph 状态、证据、可能遗漏位置、兼容方案和确认状态。
+- 首次初始化必须补齐 `xinyun-ai/team/`；升级时发现团队能力缺失，可按方案补齐团队控制文件。
+- 团队目录补齐后必须同步 `manifest.json` 和 `index/project-index.json` 的 team 路径注册。
+- `xinyun-ai/team/**` 属于控制文件，计入实际更新记录，但与业务代码修改分栏统计。
+- 超出预计目录时必须设置 `status=paused`、`pauseReason=out-of-scope`，不得使用 `paused-out-of-scope`。

package/init/xinyun-ai-init/rules/init-rules.md

@@ -18,3 +18,7 @@
 - ThinkPHP、uni-app、微信小程序轻量识别每个端口最多发现 3 层目录、读取 20 个关键文件，必须记录证据路径、证据类型、识别状态和覆盖范围。
 - 多仓库 Git 只读索引最多发现 4 层目录、20 个仓库候选和 200 个目录 / 文件条目，只读取状态与证据，不执行 Git 写操作。
 - 字段新增、删除、重命名、类型 / 含义变化、API 映射或前端展示变化时，先做字段影响审视；未确认前不得执行 SQL、migration、seed、批量数据修复或接口兼容改动。
+- 首次初始化必须创建 `xinyun-ai/team/`，包含 5 个逻辑角色、5 个 JSON 配置、5 份 `confirmations/<roleId>.md` 和 5 份 `understandings/<roleId>.md`。
+- `manifest.json` 必须登记 `capabilities.teamResponsibilityClosure: true` 和 team 的 8 个路径；`project-index.json` 必须登记 `roleCount=5`、`confirmationCount=5`、`status=pending-confirmation`。
+- 团队成员未绑定时使用 `null`，不得虚构真实人员、会话 ID 或确认人。
+- 普通咨询不强制创建完整团队任务链。

package/init/xinyun-ai-init/rules/session-workbench.md

@@ -28,6 +28,14 @@ xinyun-ai/index/session-current.md
 
 多仓库 Git 任务单还必须记录只读仓库索引：`repoRoot`、`path`、`workstream`、`kind`、`parentRepo`、`branch`、`remote`、`status`、`evidence`，以及是否存在 `状态未知` 或 `未在项目中发现`。
 
+团队责任任务单还必须记录需求负责人、技术负责人 / 总工、执行人、测试审查人、技术最终确认人、业务最终确认人、发布授权人，以及对应成员 ID：`memberId`、`reviewerMemberId`、`technicalApproverMemberId`、`businessApproverMemberId`、`publishAuthorizerMemberId`。
+
+执行人不得作为自己的最终确认人，必须按 `memberId` 判断冲突；当 `memberId` 等于 `technicalApproverMemberId`、`businessApproverMemberId` 或 `publishAuthorizerMemberId` 时，任务必须 `status=blocked`，`blockedReason=member-conflict`。
+
+确认人不可用时，任务必须 `status=blocked`，`blockedReason=approver-unavailable`。不得自动使用执行成员、虚构成员或空确认通过。
+
+任务开始前必须记录预计更新文件目录；任务完成后必须记录实际更新文件目录。发现实际修改超出预计目录时，任务必须 `status=paused`，`pauseReason=out-of-scope`，不得使用 `paused-out-of-scope`。
+
 状态机至少包含：待确认、待执行、执行中、暂停待复核、待主会话复核、已完成、失败、中断、超时、阻塞、取消、需重新确认。
 
 失败、中断、超时后不得自动重试。重试必须由主会话重新确认并增加 `attempt`，不能覆盖历史交接结果。
@@ -56,6 +64,33 @@ xinyun-ai/index/session-current.md
 
 ## 数据库 / API / UI / 配置影响
 
+## 团队责任与审批关系
+
+- 需求负责人：
+- 技术负责人 / 总工：
+- 执行人：
+- 测试审查人：
+- 技术最终确认人：
+- 业务最终确认人：
+- 发布授权人：
+- memberId：
+- reviewerMemberId：
+- technicalApproverMemberId：
+- businessApproverMemberId：
+- publishAuthorizerMemberId：
+- blockedReason：
+- pauseReason：
+- memberId 冲突检查：
+
+## 预计更新文件目录
+
+- 文件或目录：
+- 文件类型：
+- 负责角色：
+- 执行角色：
+- 审查角色：
+- 最终确认角色：
+
 ## 字段影响审视
 
 - 字段分类：
@@ -116,4 +151,16 @@ xinyun-ai/index/session-current.md
 - 可能遗漏位置：
 - 兼容方案变化：
 - 是否触发重新确认：
+
+## 实际更新文件目录
+
+- 已修改：
+- 新增：
+- 删除：
+- 未修改：
+- 超出预计范围：
+- 是否需要重新确认：
+- 控制文件：
+- 业务代码：
+- out-of-scope 处理：
 ```

package/init/xinyun-ai-init/rules/upgrade-rules.md

@@ -28,8 +28,14 @@
 - 是否需要补充框架识别证据路径、证据类型、发现预算、`状态未知` 和 `未在项目中发现` 语义。
 - 是否需要补充多仓库 Git 只读索引字段：`repoRoot`、`path`、`workstream`、`kind`、`parentRepo`、`branch`、`remote`、`status`、`evidence`。
 - 是否需要补充字段影响审视、字段任务分型和字段专项路由规则。
+- 是否需要补充 `xinyun-ai/team/` 团队责任闭环。
+- 是否需要补充 `capabilities.teamResponsibilityClosure: true` 和 team 的 8 个路径注册。
+- 是否需要补充 5 个逻辑角色、5 个 JSON 配置、5 份职责确认记录和 5 份角色理解记录。
+- 是否需要补充成员级自确认阻断、确认人缺失 `blocked`、超范围 `paused` + `pauseReason=out-of-scope` 规则。
 - 当前 `xinyun-ai/manifest.json` 的版本是否低于初始化包版本。
 
 涉及正式规则、目录结构、索引结构或旧规则合并时，必须先确认。
 
 升级不自动迁移全部旧 AI 文档，不会自动覆盖现有正式规则，也不会因为补充全局审视规则而在首次极速初始化阶段强制创建全局审视目录。
+
+升级补齐团队能力时，只允许更新 `xinyun-ai/` 内控制文件；不得修改业务代码、数据库、API、依赖、构建脚本或执行发布操作。已有团队配置不得被无确认覆盖，缺失项按方案等待用户确认后补齐。

package/init/xinyun-ai-init/templates/AGENTS.template.md

@@ -32,7 +32,7 @@
 
 只有用户明确回复“确认执行”“可以修改”“按方案改”“同意”等类似内容后，才允许在确认范围内执行。
 
-说明：用户发送 `xinyun-ai-init` 一句话入口后，视为已授权 AI 创建或补齐最小 `xinyun-ai/` 与本入口文件；该授权不包含业务代码、配置、数据库、API、UI 或业务流程修改。
+说明：用户发送 `xinyun-ai-init` 一句话入口后，视为已授权 AI 创建或补齐最小 `xinyun-ai/`、`xinyun-ai/team/` 与本入口文件；该授权不包含业务代码、配置、数据库、API、UI 或业务流程修改。
 
 执行过程中发现新增影响范围、计划外文件、计划外数据库 / API / UI / 配置影响、计划外高风险操作或验收标准变化时，必须暂停并重新确认。
 
@@ -108,6 +108,24 @@ ThinkPHP、uni-app、微信小程序轻量识别每个端口最多发现 3 层
 
 需要落盘时按需创建或更新 `xinyun-ai/global-review/`、`xinyun-ai/global-review/index.json`，并同步 `xinyun-ai/index/project-index.json`。全局审视不代替改动计划，也不会授权 AI 直接修改业务代码。
 
+## AI 项目团队与责任闭环
+
+初始化时必须创建 `xinyun-ai/team/`，包含 5 个逻辑角色：`project-owner`、`project-product`、`chief-engineer`、`programmer`、`test-reviewer`。
+
+团队配置必须包含 5 个 JSON：`roles.json`、`members.json`、`assignments.json`、`responsibility-matrix.json`、`file-ownership.json`；还必须包含 5 份 `confirmations/<roleId>.md` 和 5 份 `understandings/<roleId>.md`。
+
+`manifest.json` 必须声明 `capabilities.teamResponsibilityClosure: true` 并登记 team 的 8 个相对路径；`project-index.json` 必须登记 `team.enabled`、`roleCount=5`、`confirmationCount=5`、`status=pending-confirmation` 和同名路径。
+
+团队角色只是本地逻辑配置，不自动创建外部人员账号、外部 AI 会话或无限会话。未绑定真实人员或会话时，`personId`、`sessionId`、`memberId`、`confirmedBy` 使用 `null`，不得虚构。
+
+角色生命周期：`unassigned`、`assigned`、`onboarding`、`ready`、`blocked`、`disabled`。职责确认状态：`pending`、`confirmed`、`adjustment-required`。任务分配状态：`pending`、`assigned`、`accepted`、`executing`、`paused`、`blocked`、`completed`、`cancelled`。
+
+`status=paused` 时必须填写 `pauseReason`，超范围统一使用 `pauseReason=out-of-scope`；不得使用未定义状态 `paused-out-of-scope`。确认人不可用或成员冲突时使用 `status=blocked`，并填写 `blockedReason=approver-unavailable` 或 `member-conflict`。
+
+执行人不得直接作为自己的最终确认人，冲突必须按成员 ID 判断：`memberId` 不得等于 `technicalApproverMemberId`、`businessApproverMemberId` 或 `publishAuthorizerMemberId`。`roles.json` 中的默认确认角色只用于候选推荐，不能覆盖成员级冲突校验。程序员不得担任技术最终确认人、业务最终确认人或发布授权人。
+
+任务开始前记录预计更新文件目录，完成后通过文件清单和 diff 只读核对实际更新文件目录。发现实际修改超出预计目录时，任务必须设置 `status=paused`、`pauseReason=out-of-scope`，返回总工或主会话重新确认。
+
 AI 接手本项目时，请先读取：
 
 - `xinyun-ai/README.md`

package/init/xinyun-ai-init/templates/core-rules.template.md

@@ -26,8 +26,10 @@
 
 ## 初始化授权边界
 
-- 用户发送 `xinyun-ai-init` 一句话入口后，视为已授权 AI 创建或补齐最小 `xinyun-ai/` 与极简 `AGENTS.md`。
+- 用户发送 `xinyun-ai-init` 一句话入口后，视为已授权 AI 创建或补齐最小 `xinyun-ai/`、`xinyun-ai/team/` 与极简 `AGENTS.md`。
 - 该授权不包含业务代码、配置、数据库、依赖、构建脚本、测试逻辑、API 行为、UI 行为或业务流程修改。
+- `xinyun-ai/team/**` 属于 AI 工作区控制文件，只创建本地逻辑角色、待绑定成员槽位、职责确认记录和角色理解记录，不自动创建外部账号、外部 AI 会话或无限会话。
+- 未绑定真实人员或会话时，`personId`、`sessionId`、`memberId`、`confirmedBy` 使用 `null`，不得虚构。
 
 ## 改动计划与执行确认
 
@@ -248,6 +250,116 @@
 - 创建或更新全局审视后，应同步 `xinyun-ai/global-review/index.json` 和 `xinyun-ai/index/project-index.json`。
 - 全局审视不会授权 AI 直接修改业务代码。
 
+## AI 项目团队与责任闭环
+
+- 初始化时必须创建 `xinyun-ai/team/`。
+- 默认逻辑角色为：`project-owner`、`project-product`、`chief-engineer`、`programmer`、`test-reviewer`。
+- 首次必须创建 5 个 JSON 配置：`roles.json`、`members.json`、`assignments.json`、`responsibility-matrix.json`、`file-ownership.json`。
+- 首次必须创建 5 份职责确认记录：`confirmations/<roleId>.md`，文件名必须使用 `roleId`。
+- 首次必须创建 5 份角色理解记录：`understandings/<roleId>.md`，文件名必须使用 `roleId`。
+- `roles.json` 的 `roleId` 必须全局唯一；所有 ID 必须唯一。
+- `members.json` 未绑定时 `personId` 和 `sessionId` 必须为 `null`，不得虚构真实人员或会话。
+- `confirmations/<roleId>.md` 和 `understandings/<roleId>.md` 的 `createdAt`、`updatedAt` 必须存在且为 ISO 8601 时间；首次落盘可使用模板初始时间或替换为当前时间，但不得留空。
+- `xinyun-ai/manifest.json` 必须包含 `capabilities.teamResponsibilityClosure: true`，并登记 team 的 8 个路径：`directory`、`roles`、`members`、`assignments`、`responsibilityMatrix`、`fileOwnership`、`understandingsDirectory`、`confirmationsDirectory`。
+- `xinyun-ai/index/project-index.json` 必须登记 `team.enabled`、`directory`、`roleCount=5`、`confirmationCount=5`、`status=pending-confirmation` 和同名 `paths`。
+- 注册路径必须与实际文件系统路径逐项一致。
+
+角色职责：
+
+- 项目负责人负责需求最终确认、业务验收和发布授权。
+- 项目产品负责需求整理、任务拆分和产品验收建议，不拥有技术最终确认权或发布授权权。
+- 总工 / 技术负责人负责技术方案、架构风险和技术最终确认。
+- 程序员按确认范围执行代码、配置和测试任务。
+- 测试审查员独立测试、发布阻断判断和测试结论，不修改代码。
+
+状态分层：
+
+- 角色生命周期：`unassigned`、`assigned`、`onboarding`、`ready`、`blocked`、`disabled`。
+- 职责确认状态：`pending`、`confirmed`、`adjustment-required`。
+- 任务分配状态：`pending`、`assigned`、`accepted`、`executing`、`paused`、`blocked`、`completed`、`cancelled`。
+- `status=paused` 时必须填写 `pauseReason`，允许值至少包括 `out-of-scope`、`awaiting-confirmation`、`execution-failed`、`user-requested`；其他状态的 `pauseReason` 必须为 `null`。
+- 确认人不可用或发生成员冲突时使用 `status=blocked`，并填写 `blockedReason=approver-unavailable` 或 `blockedReason=member-conflict`。
+
+可执行前置条件：
+
+- 成员已绑定。
+- 角色生命周期为 `ready`。
+- 职责确认状态为 `confirmed`。
+- 角色理解记录为 `ready`。
+- 任务执行人和确认人不冲突。
+- 角色理解记录不等于代码修改授权；即使 `executionEligible=true`，仍必须有已确认任务单。
+
+成员级确认冲突：
+
+- 执行人不得直接作为自己的最终确认人。
+- 最终确认关系必须在任务分配记录中落到成员 ID。
+- `memberId` 不得等于 `technicalApproverMemberId`、`businessApproverMemberId` 或 `publishAuthorizerMemberId`。
+- `roles.json` 中的默认确认角色只用于候选人推荐，不构成授权，也不能覆盖成员级冲突校验。
+- 总工为执行人时不得回落为自己确认自己。
+- 没有可用技术、业务或发布确认成员时，任务保持 `blocked` / 待分配，不得自动使用执行成员、虚构成员或空确认通过。
+- 程序员不得担任技术最终确认人、业务最终确认人或发布授权人；本版本不设置例外。
+
+角色理解记录最小字段：
+
+- `recordId`
+- `roleId`
+- `memberId`
+- `status`：`pending` / `reading` / `ready` / `partial` / `blocked`
+- `readScope`
+- `readBudget`
+- `unreadablePaths`
+- `confirmedFacts`
+- `inferences`
+- `pendingQuestions`
+- `risks`
+- `evidence`
+- `coverage`
+- `executionEligible`
+- `createdAt`
+- `updatedAt`
+
+任务责任字段：
+
+```md
+- 需求负责人：
+- 技术负责人 / 总工：
+- 执行人：
+- 测试审查人：
+- 技术最终确认人：
+- 业务最终确认人：
+- 发布授权人：
+```
+
+文件目录责任和变更核对：
+
+```md
+## 预计更新文件目录
+- 文件或目录：
+- 文件类型：
+- 负责角色：
+- 执行角色：
+- 审查角色：
+- 最终确认角色：
+
+## 实际更新文件目录
+- 已修改：
+- 新增：
+- 删除：
+- 未修改：
+- 超出预计范围：
+- 是否需要重新确认：
+```
+
+- 目录记录以相对 `repoRoot` 的正斜线路径为准，跨仓库必须分别记录。
+- 文件、目录、通配符分别通过 `pathType` 标注；`pathType` 只能是 `file`、`directory` 或 `glob`。
+- 路径不得包含 `..`。
+- 删除和重命名必须记录旧路径，重命名还必须记录新路径。
+- 生成文件必须列出实际输出路径。
+- `xinyun-ai/team/**`、`xinyun-ai/current-task.md`、`xinyun-ai/index/session-current.md`、`xinyun-ai/handoffs/**` 属于控制文件，计入实际更新记录，但与业务代码修改分栏统计。
+- 实际目录通过文件清单和 diff 只读核对。
+- 发现未授权路径后，任务状态改为 `paused`、`pauseReason=out-of-scope`，记录责任人、发现人、影响范围和重新确认人。
+- 不得使用未定义状态 `paused-out-of-scope`。
+
 ## 双会话执行闭环（MVP）
 
 - 复杂改动可使用一个主会话 + 一个执行会话的手工协作闭环；普通咨询、只读分析和不涉及文件修改的任务仍可使用单会话。

package/init/xinyun-ai-init/templates/current-task.template.md

@@ -75,6 +75,40 @@
   - status：
   - 执行任务单：
   - 执行交接单：
+- 团队责任闭环：
+  - 需求负责人：
+  - 技术负责人 / 总工：
+  - 执行人：
+  - 测试审查人：
+  - 技术最终确认人：
+  - 业务最终确认人：
+  - 发布授权人：
+  - memberId：
+  - reviewerMemberId：
+  - technicalApproverMemberId：
+  - businessApproverMemberId：
+  - publishAuthorizerMemberId：
+  - blockedReason：
+  - pauseReason：
+  - memberId 冲突检查：
+  - 职责确认状态：
+  - 角色理解状态：
+- 预计更新文件目录：
+  - 文件或目录：
+  - 文件类型：
+  - 负责角色：
+  - 执行角色：
+  - 审查角色：
+  - 最终确认角色：
+- 实际更新文件目录：
+  - 已修改：
+  - 新增：
+  - 删除：
+  - 未修改：
+  - 超出预计范围：
+  - 是否需要重新确认：
+  - 控制文件：
+  - 业务代码：
 - 交付状态：
 - 未完成事项：
 - 下一步动作：

package/init/xinyun-ai-init/templates/manifest.template.json

@@ -1,6 +1,6 @@
 {
   "projectName": "",
-  "xinyunAiVersion": "1.4.0",
+  "xinyunAiVersion": "1.5.0",
   "scriptVersion": "2026.07.16",
   "schemaVersion": "1",
   "initializationMode": "fast",
@@ -30,6 +30,17 @@
     "frameworkEvidenceBudget": true,
     "readonlyGitRepositoryIndex": true,
     "boundedFieldImpactReview": true,
-    "fieldChangeRequirementRouting": true
+    "fieldChangeRequirementRouting": true,
+    "teamResponsibilityClosure": true
+  },
+  "team": {
+    "directory": "xinyun-ai/team/",
+    "roles": "xinyun-ai/team/roles.json",
+    "members": "xinyun-ai/team/members.json",
+    "assignments": "xinyun-ai/team/assignments.json",
+    "responsibilityMatrix": "xinyun-ai/team/responsibility-matrix.json",
+    "fileOwnership": "xinyun-ai/team/file-ownership.json",
+    "understandingsDirectory": "xinyun-ai/team/understandings/",
+    "confirmationsDirectory": "xinyun-ai/team/confirmations/"
   }
 }

package/init/xinyun-ai-init/templates/project-check.template.md

@@ -34,6 +34,16 @@
   - 检索根目录与排除项：待填写
   - CodeGraph 状态与降级说明：待填写
   - 证据、可能遗漏和兼容方案：待填写
+- AI 项目团队与责任闭环：待填写
+  - `xinyun-ai/team/` 是否创建：待填写
+  - 5 个 JSON 配置是否可解析：待填写
+  - 5 份 `confirmations/<roleId>.md` 是否存在：待填写
+  - 5 份 `understandings/<roleId>.md` 是否存在：待填写
+  - `manifest.json` team 路径注册：待填写
+  - `project-index.json` team 路径注册：待填写
+  - 未绑定成员是否使用 `null`：待填写
+  - 自确认 memberId 冲突阻断：待填写
+  - 超范围暂停是否为 `status=paused` + `pauseReason=out-of-scope`：待填写
 
 ## 待确认问题
 

package/init/xinyun-ai-init/templates/project-guide.template.md

@@ -105,9 +105,26 @@
 
 - 初始化模式：待填写。
 - 已创建或更新文件：待填写。
+- AI 项目团队：待填写。
+- 团队路径注册：待填写。
+- 角色数量：待填写。
+- 职责确认记录数量：待填写。
+- 角色理解记录数量：待填写。
 - 是否接管旧沉淀：待填写。
 - 是否有待确认项：待填写。
 
+## AI 项目团队与责任闭环
+
+- 团队目录：`xinyun-ai/team/`
+- 角色：项目负责人、项目产品、总工、程序员、测试审查员。
+- 当前状态：pending-confirmation。
+- 未绑定成员：待填写。
+- 职责确认：待填写。
+- 角色理解：待填写。
+- 成员级自确认阻断：待填写。
+- 文件目录责任：待填写。
+- 超范围暂停规则：`status=paused` + `pauseReason=out-of-scope`。
+
 ## CodeGraph 与索引状态
 
 待填写。

package/init/xinyun-ai-init/templates/project-index.template.json

@@ -70,5 +70,23 @@
     "fieldTypes": ["数据库字段", "API 字段", "前端展示字段", "未确认"],
     "routes": ["字段影响审视", "普通改动计划", "SQL 提醒", "业务流程理解"]
   },
+  "team": {
+    "enabled": true,
+    "directory": "xinyun-ai/team/",
+    "roleCount": 5,
+    "confirmationCount": 5,
+    "understandingCount": 5,
+    "status": "pending-confirmation",
+    "paths": {
+      "directory": "xinyun-ai/team/",
+      "roles": "xinyun-ai/team/roles.json",
+      "members": "xinyun-ai/team/members.json",
+      "assignments": "xinyun-ai/team/assignments.json",
+      "responsibilityMatrix": "xinyun-ai/team/responsibility-matrix.json",
+      "fileOwnership": "xinyun-ai/team/file-ownership.json",
+      "understandingsDirectory": "xinyun-ai/team/understandings/",
+      "confirmationsDirectory": "xinyun-ai/team/confirmations/"
+    }
+  },
   "lastUpdatedAt": ""
 }

package/init/xinyun-ai-init/templates/team/README.md

@@ -0,0 +1,40 @@
+# AI 项目团队
+
+本目录用于记录本地 AI 协作团队、职责确认、角色理解、任务责任和文件目录责任。
+
+## 初始化边界
+
+- 团队配置只创建逻辑角色和待绑定成员槽位，不自动创建外部人员账号、外部 AI 会话或无限会话。
+- 未绑定真实人员或会话时，`personId`、`sessionId`、`memberId`、`confirmedBy` 使用 `null`，不得虚构姓名或会话 ID。
+- `confirmations/<roleId>.md` 和 `understandings/<roleId>.md` 的 `createdAt`、`updatedAt` 必须存在且为 ISO 8601 时间；首次落盘可使用模板初始时间或替换为当前时间，但不得留空。
+- `xinyun-ai/team/**` 属于 AI 工作区控制文件，不授权修改业务代码、数据库、API、依赖、构建脚本或执行发布操作。
+
+## 默认角色
+
+- `project-owner`：项目负责人，负责需求最终确认、业务验收和发布授权。
+- `project-product`：项目产品，负责需求整理、任务拆分和产品验收建议。
+- `chief-engineer`：总工 / 技术负责人，负责技术方案、架构风险和技术最终确认。
+- `programmer`：程序员，按确认范围执行代码、配置和测试任务。
+- `test-reviewer`：测试审查员，独立测试、发布阻断判断和测试结论，不修改代码。
+
+## 状态规则
+
+- 角色生命周期：`unassigned`、`assigned`、`onboarding`、`ready`、`blocked`、`disabled`。
+- 职责确认状态：`pending`、`confirmed`、`adjustment-required`。
+- 任务分配状态：`pending`、`assigned`、`accepted`、`executing`、`paused`、`blocked`、`completed`、`cancelled`。
+- `status=paused` 时必须填写 `pauseReason`，超范围统一使用 `pauseReason=out-of-scope`。
+- `status=blocked` 时必须填写 `blockedReason`，确认人不可用为 `approver-unavailable`，成员冲突为 `member-conflict`。
+- 执行人不得作为自己的技术最终确认人、业务最终确认人或发布授权人；冲突必须按 `memberId` 判断。
+
+## 文件目录责任
+
+任务开始前记录预计更新文件目录，任务完成后通过文件清单和 diff 只读核对实际更新文件目录。
+
+发现实际修改超出预计目录时，任务必须设置：
+
+```md
+status=paused
+pauseReason=out-of-scope
+```
+
+不得使用未定义状态 `paused-out-of-scope`。