@pm_zhousl/xinyun-ai-init 1.3.0 → 1.5.0

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

@@ -2,7 +2,7 @@
 
 本目录是“欣芸技术开发 Agent 流”的初始化包，负责把完整 AI 执行要求下发到目标项目。
 
-当前规则版本：`1.3.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. 非项目开发内容不要沉淀。
@@ -35,8 +35,12 @@ AI 读取本文件后，必须按以下方式执行：
 9. 复杂改动可使用双会话执行闭环，主会话负责计划和复核，执行会话只按任务单执行。
 10. 需求模糊、涉及改动或出现高风险词时，先做中文需求解析和任务分型；普通咨询不强制输出完整解析结构。
 11. 新功能、大改、重构、跨端、规则或索引调整时，先做全局影响审视；首次极速初始化不强制创建全局审视目录。
-12. 首次初始化不执行语言级语法检查、lint、typecheck、测试或构建命令；本机缺少运行时只记录为待确认，不展开长解释。
-13. 完成后用中文输出初始化或升级结果、项目导读、待确认问题和后续短指令。
+12. 识别 ThinkPHP、uni-app、微信小程序时必须输出证据路径、证据类型、识别状态和覆盖范围，遵守读取预算。
+13. 多仓库 Git 只做只读索引与端口映射，不执行任何 Git 写操作。
+14. 字段新增、删除、重命名、类型 / 含义变化、API 映射或前端展示变化时，先做有边界的字段影响审视。
+15. 初始化时创建 AI 项目团队责任闭环：5 个逻辑角色、5 个 JSON 配置、5 份职责确认记录和 5 份角色理解记录。
+16. 首次初始化不执行语言级语法检查、lint、typecheck、测试或构建命令；本机缺少运行时只记录为待确认，不展开长解释。
+17. 完成后用中文输出初始化或升级结果、项目导读、团队责任状态、待确认问题和后续短指令。
 
 ## 初始化授权边界
 
@@ -44,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`，不得虚构。
+
 ## 改动计划与执行确认
 
 用户提出“帮我改”“修复”“处理一下”“优化一下”只代表提出需求，不代表授权执行。
@@ -123,6 +131,10 @@ CLI 只负责生成 `xinyun-ai-init/`，不创建 `xinyun-ai/`，也不修改业
 
 任务类型至少包括：问题排查、新功能开发、UI 调整、API / 接口调整、数据库 / SQL、商业逻辑、Git / 发布、文档沉淀、规则调整、临时咨询。
 
+字段变更类任务还必须细分为：数据库字段新增 / 删除 / 重命名、字段类型或含义变更、API 字段调整、字段展示或渲染调整。
+
+字段相关需求必须输出字段分类和专项路由：字段影响审视 / 普通改动计划 / SQL 提醒 / 业务流程理解。信息不足时最多追问 1-3 个关键问题，不得直接脑补并修改代码。
+
 高歧义表达包括：优化一下、处理一下、不对、怪怪的、照之前、顺便、差不多、参考一下。
 
 高风险词包括：订单、支付、退款、优惠券、会员、权益、金额、积分、分润、提现、结算、权限、删除、批量、发布、回滚。
@@ -237,6 +249,75 @@ rules/frameworks/frontend/wechat-miniprogram.md
 
 未识别到对应框架时，不强行套用该框架规则。
 
+框架识别默认预算：
+
+- 每个端口从端口根目录向下最多发现 3 层目录。
+- 每个端口最多读取 20 个关键文件。
+- 正向识别必须列出证据路径和证据类型，如依赖、配置、入口、目录结构、代码特征。
+- 只有单一线索时标注 `推断` 或 `待确认`。
+- 预算内无证据时标注 `未在项目中发现`。
+- 超预算、权限不足或路径不可读时标注 `状态未知`，并写明 `覆盖范围：部分` 和未检查范围。
+- 不把 uni-app 规则套到原生微信小程序，也不把微信小程序规则套到 uni-app。
+
+识别输出建议：
+
+```md
+## 轻量框架识别
+- workstream：
+- 框架候选：
+- 识别状态：已确认 / 推断 / 待确认 / 未在项目中发现 / 状态未知
+- 覆盖范围：完整 / 部分
+- 发现预算：目录深度 3 层、关键文件 20 个
+- 证据：路径、证据类型、命中内容摘要
+- 未检查范围：
+```
+
+## 字段变更影响审视
+
+当需求涉及字段新增、删除、重命名、类型变化、含义变化、API 映射变化或前端展示变化时，AI 必须先做字段影响审视，再进入改动计划。
+
+字段影响审视必须区分数据库字段、API 字段和前端展示字段。
+
+默认审视范围：
+
+- 数据库表结构、migration、Model、Entity、ORM、查询和写入。
+- Service、DAO、参数校验、状态流转、计算、缓存和队列。
+- API 请求、响应、DTO、Serializer 和接口文档。
+- 各端表单、列表、详情、表格、筛选、状态、格式化、图表、导出和打印。
+- Mock、Seed、测试数据、空值、旧值、默认值、历史数据和兼容性。
+
+默认预算：
+
+- 检索根目录为项目根目录和已确认端口 / workstream 根目录。
+- 每个端口最多检查 300 个候选文件、1000 条匹配结果和 50 条证据记录。
+- 排除 `node_modules`、`dist`、`build`、`vendor`、`.git`、`.codegraph`、`storage`、`runtime`、`unpackage`、`coverage`、二进制文件和明确生成目录。
+- CodeGraph 可用时，结构性影响优先使用 CodeGraph；CodeGraph 不可用时，降级为入口文件、配置文件、结构化检索和限定范围文本检索，并标注降级状态。
+- 动态 SQL、动态字段名、序列化、反射和生成代码无法确认时，列为 `待确认` 或 `可能遗漏位置`。
+- 超过预算时停止扩展检索，标注 `审视状态：部分覆盖`、`状态未知` 和 `可能遗漏位置`。
+
+字段影响审视输出契约：
+
+```md
+## 字段影响审视
+- 审视状态：完整覆盖 / 部分覆盖 / 状态未知
+- 字段分类：数据库字段 / API 字段 / 前端展示字段
+- 字段名称与原含义：
+- 调整后含义：
+- 检索根目录：
+- 排除目录与文件：
+- CodeGraph 状态：可用 / 不可用 / 降级
+- 降级原因：
+- 工具预算：
+- 证据列表：路径、位置、匹配内容、判断状态
+- 已覆盖范围：
+- 可能遗漏位置：
+- 旧数据兼容方案：
+- 最终风险：
+- 是否需要用户确认：
+```
+
+只改展示方式时，不得顺手修改数据库和 API。未确认前不得执行 SQL、migration、seed、批量数据修复或接口兼容改动。
+
 ## 执行模式
 
 如果项目没有 `xinyun-ai/`：
@@ -268,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
 ```
 
 首次不要创建大量规则、模板、脚本和业务沉淀目录。后续根据任务按需补齐。
@@ -325,6 +422,24 @@ AI 可以读取 Git 状态、总结 diff、建议 commit message 和 tag；未
 
 多端多仓库改动后，应按仓库分别输出交付摘要和建议 commit message，不要混成一个提交建议。
 
+### 多仓库 Git 只读索引与端口映射
+
+AI 可以建立“项目 → 端口 / workstream → Git 仓库”的只读索引，但全程禁止 Git 写操作。
+
+默认发现预算：
+
+- 从项目根目录向下最多发现 4 层目录。
+- 最多记录 20 个仓库候选和 200 个相关目录 / 文件条目。
+- 覆盖根仓库、嵌套 `.git`、子模块和 worktree。
+- 超过预算、权限不足、路径不可读或状态无法确认时，标注 `状态未知`，不得判断为无 Git。
+- 预算内完成检查且无 Git 证据时，标注 `未在项目中发现`。
+
+仓库索引字段：`repoRoot`、`path`、`workstream`、`kind`、`parentRepo`、`branch`、`remote`、`status`、`evidence`。
+
+`kind` 取值为：`root` / `nested` / `submodule` / `worktree`。
+
+只读 Git 操作范围：读取状态、分支、remote、diff 摘要和配置证据。禁止 `commit`、`tag`、`push`、`pull`、`merge`、`rebase`、`reset`、`checkout`、`switch`、回滚和切分支。
+
 ## 按需补齐
 
 后续识别到新端、模块或能力时，只在 `xinyun-ai/` 内补齐对应目录和说明文件。
@@ -387,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）
 
 复杂改动可使用一个主会话 + 一个执行会话的手工协作闭环。普通咨询、只读分析和不涉及文件修改的任务仍可使用单会话。
@@ -540,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

@@ -13,3 +13,10 @@
 - 首次极速初始化不强制创建 `xinyun-ai/global-review/`。
 - 创建或更新全局审视后，必须同步 `xinyun-ai/global-review/index.json` 和 `xinyun-ai/index/project-index.json`。
 - 全局审视最小字段包括：`reviewId`、触发原因、关联任务、影响层、已确认内容、推断内容、待确认内容、风险点、后续动作、创建时间、更新时间。
+- 识别到端口框架线索时，可按需补齐 `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/frameworks/README.md

@@ -27,3 +27,19 @@ frameworks/frontend/<framework>.md
 - 如需进一步确认，放到后续任务按需补齐。
 - 未识别到对应框架时，不强行套用该框架规则。
 - 多端项目应分别说明每个端口的框架、入口、启动线索和请求链路线索。
+- 每个端口从端口根目录向下最多发现 3 层目录，最多读取 20 个关键文件。
+- 正向识别必须列出证据路径和证据类型，证据类型包括依赖、配置、入口、目录结构和代码特征。
+- 预算内无识别证据时标注 `未在项目中发现`。
+- 权限不足、路径不可读或超过预算时标注 `状态未知`，同时写明 `覆盖范围：部分` 和未检查范围。
+- 单一线索只能标注 `推断` 或 `待确认`。
+- 不把 uni-app 规则套到原生微信小程序，也不把微信小程序规则套到 uni-app。
+
+## 输出字段
+
+- workstream
+- 框架候选
+- 识别状态：已确认 / 推断 / 待确认 / 未在项目中发现 / 状态未知
+- 覆盖范围：完整 / 部分
+- 发现预算：目录深度 3 层、关键文件 20 个
+- 证据：路径、证据类型、命中内容摘要
+- 未检查范围

package/init/xinyun-ai-init/rules/frameworks/backend/php/thinkphp.md

@@ -27,3 +27,8 @@
 - 首次初始化不为确认 ThinkPHP 做全量 grep。
 - 不把 ThinkPHP 规则套到其他 PHP 框架。
 - 不默认生成大量 ThinkPHP 说明文件。
+- 每个端口从端口根目录向下最多发现 3 层目录，最多读取 20 个关键文件。
+- 正向识别必须输出证据路径和证据类型：依赖、入口、目录结构、配置或代码特征。
+- 预算内无 ThinkPHP 证据时标注 `未在项目中发现`。
+- 超预算、权限不足或路径不可读时标注 `状态未知` 和 `覆盖范围：部分`，并列出未检查范围。
+- 单一线索不能直接确认 ThinkPHP，只能标注 `推断` 或 `待确认`。

package/init/xinyun-ai-init/rules/frameworks/frontend/uni-app.md

@@ -29,3 +29,8 @@
 - 只发现单一线索时，标注为 `推断` 或 `待确认`，不得直接当作已确认 uni-app 项目。
 - 首次初始化不为确认 uni-app 做全量 grep。
 - 不把 uni-app 规则套到原生微信小程序。
+- 每个端口从端口根目录向下最多发现 3 层目录，最多读取 20 个关键文件。
+- 正向识别必须输出证据路径和证据类型：依赖、配置、入口、目录结构或代码特征。
+- 预算内无 uni-app 证据时标注 `未在项目中发现`。
+- 超预算、权限不足或路径不可读时标注 `状态未知` 和 `覆盖范围：部分`，并列出未检查范围。
+- 不把原生微信小程序规则反向套到 uni-app。

package/init/xinyun-ai-init/rules/frameworks/frontend/wechat-miniprogram.md

@@ -29,3 +29,8 @@
 - 只发现单一线索时，标注为 `推断` 或 `待确认`，不得直接当作已确认微信小程序项目。
 - 首次初始化不为确认微信小程序做全量 grep。
 - 不把微信小程序规则套到 uni-app。
+- 每个端口从端口根目录向下最多发现 3 层目录，最多读取 20 个关键文件。
+- 正向识别必须输出证据路径和证据类型：配置、入口、页面结构、目录结构或代码特征。
+- 预算内无微信小程序证据时标注 `未在项目中发现`。
+- 超预算、权限不足或路径不可读时标注 `状态未知` 和 `覆盖范围：部分`，并列出未检查范围。
+- 不把 uni-app 规则反向套到原生微信小程序。

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

@@ -15,3 +15,10 @@
 - 首次极速初始化不强制创建 `xinyun-ai/global-review/`。
 - 需求模糊、涉及改动或出现高风险词时，先做中文需求解析；普通咨询不强制输出完整解析结构。
 - 中文需求解析最多追问 1-3 个关键问题。
+- 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

@@ -24,6 +24,18 @@ xinyun-ai/index/session-current.md
 
 双会话交接单至少记录：执行前 Git 或文件状态、实际修改文件、diff 摘要、测试结果、未完成事项、新风险和是否存在超范围修改。
 
+字段变更任务单还必须记录字段分类、专项路由、字段影响审视状态、检索根目录、排除项、CodeGraph 状态、证据预算、允许修改文件、禁止修改范围、SQL / migration / seed 禁止项和用户确认状态。
+
+多仓库 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`，不能覆盖历史交接结果。
@@ -52,6 +64,47 @@ xinyun-ai/index/session-current.md
 
 ## 数据库 / API / UI / 配置影响
 
+## 团队责任与审批关系
+
+- 需求负责人：
+- 技术负责人 / 总工：
+- 执行人：
+- 测试审查人：
+- 技术最终确认人：
+- 业务最终确认人：
+- 发布授权人：
+- memberId：
+- reviewerMemberId：
+- technicalApproverMemberId：
+- businessApproverMemberId：
+- publishAuthorizerMemberId：
+- blockedReason：
+- pauseReason：
+- memberId 冲突检查：
+
+## 预计更新文件目录
+
+- 文件或目录：
+- 文件类型：
+- 负责角色：
+- 执行角色：
+- 审查角色：
+- 最终确认角色：
+
+## 字段影响审视
+
+- 字段分类：
+- 专项路由：
+- 审视状态：
+- 检索根目录：
+- 排除目录与文件：
+- CodeGraph 状态：
+- 工具预算：
+- 证据列表：
+- 可能遗漏位置：
+- 旧数据兼容方案：
+- 是否需要用户确认：
+
 ## 验证命令
 
 ## 验收标准
@@ -90,4 +143,24 @@ xinyun-ai/index/session-current.md
 ## 是否执行过高风险操作
 
 ## 是否发现新影响范围
+
+## 字段影响审视交接
+
+- 审视状态：
+- 实际证据数量：
+- 可能遗漏位置：
+- 兼容方案变化：
+- 是否触发重新确认：
+
+## 实际更新文件目录
+
+- 已修改：
+- 新增：
+- 删除：
+- 未修改：
+- 超出预计范围：
+- 是否需要重新确认：
+- 控制文件：
+- 业务代码：
+- out-of-scope 处理：
 ```

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

@@ -25,8 +25,17 @@
 - 是否需要补充中文需求解析和任务分型规则。
 - 是否需要补充 `xinyun-ai/global-review/` 按需创建规则。
 - 是否需要补充轻量框架适配识别规则。
+- 是否需要补充框架识别证据路径、证据类型、发现预算、`状态未知` 和 `未在项目中发现` 语义。
+- 是否需要补充多仓库 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 / 配置影响、计划外高风险操作或验收标准变化时，必须暂停并重新确认。
 
@@ -58,6 +58,8 @@
 
 任务类型至少包括：问题排查、新功能开发、UI 调整、API / 接口调整、数据库 / SQL、商业逻辑、Git / 发布、文档沉淀、规则调整、临时咨询。
 
+字段变更类任务必须细分为：数据库字段新增 / 删除 / 重命名、字段类型或含义变更、API 字段调整、字段展示或渲染调整，并路由到字段影响审视 / 普通改动计划 / SQL 提醒 / 业务流程理解。
+
 高歧义表达包括：优化一下、处理一下、不对、怪怪的、照之前、顺便、差不多、参考一下。
 
 高风险词包括：订单、支付、退款、优惠券、会员、权益、金额、积分、分润、提现、结算、权限、删除、批量、发布、回滚。
@@ -82,6 +84,12 @@
 
 未获用户明确确认前，AI 不得自动执行 `commit`、`tag`、`push`、`pull`、`merge`、`rebase`、`reset`、`checkout` 回滚或切分支。
 
+多仓库 Git 只读索引最多向下发现 4 层目录、记录 20 个仓库候选和 200 个目录 / 文件条目；仓库索引必须包含 `repoRoot`、`path`、`workstream`、`kind`、`parentRepo`、`branch`、`remote`、`status`、`evidence`。预算内无证据标注 `未在项目中发现`；超预算、权限不足、路径不可读或状态无法确认标注 `状态未知`。
+
+ThinkPHP、uni-app、微信小程序轻量识别每个端口最多发现 3 层目录、读取 20 个关键文件。正向识别必须输出证据路径和证据类型；预算内无证据标注 `未在项目中发现`；超预算、权限不足或路径不可读标注 `状态未知` 和 `覆盖范围：部分`；不得混用 uni-app 与原生微信小程序规则。
+
+字段新增、删除、重命名、类型变化、含义变化、API 映射变化或前端展示变化时，必须先做字段影响审视，区分数据库字段 / API 字段 / 前端展示字段，说明检索根目录、排除项、CodeGraph 状态、证据列表、覆盖范围、可能遗漏、旧数据兼容方案、风险和确认状态。每个端口最多检查 300 个候选文件、1000 条匹配结果和 50 条证据记录；未确认前不得执行 SQL、migration、seed、批量数据修复或接口兼容改动。
+
 复杂改动可使用双会话执行闭环。主会话负责理解中文需求、识别任务类型和影响范围、生成改动计划、等待用户确认、生成执行任务单、复核执行结果并输出最终交付结论。执行会话负责读取任务单、只在确认范围内执行、进行必要验证、输出执行交接单、不创建第三个会话、不自行扩大范围。
 
 双会话文件契约：`xinyun-ai/current-task.md` 由主会话维护；`xinyun-ai/index/session-current.md` 是主会话创建的临时执行任务单，执行会话只读；`xinyun-ai/handoffs/current-execution.md` 是执行会话写入的执行交接单，主会话只读复核。
@@ -100,6 +108,24 @@
 
 需要落盘时按需创建或更新 `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`