@givolt/i3-composer-agent 3.2.1 → 4.0.1

package/skills/i3-enterprise-sop/SKILL.md

@@ -43,13 +43,13 @@ Skill/Command/Agent 标识、文件路径、命令参数、代码/API 名称、
  |
  +-- spec -> T2
  |   显式调用 i3-spec-driven-development Skill -> 默认读取 spec/handoff.json
- |   -> 检查当前主题的 BRD、PRD、AD
+ |   -> 检查当前PBC的 BRD、PRD、AD
  |      +-- 缺项 -> 提示 T1 对应操作或补充已有文档 -> 停止等待
  |      +-- 齐备 -> 读取正文及工程依据
- |          -> 保存 spec/SPEC-{PBC名称}-{主题名称}.md -> 落盘完整性检查 -> 交人审阅 -> 停止
+ |          -> 保存 spec/SPEC-{PBC名称}.md -> 落盘完整性检查 -> 交人审阅 -> 停止
  |
  +-- plan -> T3
-     显式调用i3-planning-and-task-breakdown skill + 选定工程 SPEC 及必要来源
+     显式调用i3-planning-and-task-breakdown Skill + 选定工程 SPEC 及必要来源
      -> Plan 和任务 -> 落盘完整性检查 -> 交人审阅 -> 停止
 ```
 
@@ -60,7 +60,7 @@ Skill/Command/Agent 标识、文件路径、命令参数、代码/API 名称、
 | 意图 | 操作 |
 | --- | --- |
 | `brd`、`prd`、`ad`、`testcase` | T1：确定类型及对象，保存文稿或选用同类已有稿，自动登记路径 |
-| `spec` | T2：检查清单及当前主题 BRD／PRD／AD，齐备后生成工程 SPEC |
+| `spec` | T2：检查清单及当前PBC BRD／PRD／AD，齐备后生成工程 SPEC |
 | `plan` | T3：选择工程 SPEC，生成实施计划和任务 |
 | 未给动作或意图不明 | 交互选择“企业文档（再选四类）／工程 SPEC／项目计划／退出” |
 
@@ -89,8 +89,8 @@ T1／T2 写作意图明确后，先通过宿主正式机制显式加载原 `i3-s
 - **安装定位：**确有需要时局部核包身份、版本、布局、作用域、宿主和当前 Skill 的精确路径；不通读资产列表，也不以安装记录替换项目采用。
 - **澄清：**沿原 Spec 先核来源、已采用规约及真实答复，问清尚未决定且影响本次输出的关键缺口或实际冲突，并等待真人答复。提问说明已有事实及尚缺的差异，已定技术版本不与未定部署范围混问；不重复询问已有决定，也不把一般 Q 全部变成前置审批。资料充分就拟稿，一般未决项保留 Q、有依据的推荐／备选及影响；已有允许保留 Q 的约定时不再泛问能否保留，实际阻断事项仍须说明。多个独立决定分别表达，选项不捆绑额外限制、期限或技术选型。交互工具不可用时用会话文本等待；收到答复后绑定原问题及当前文档继续，来源改变才重核受影响事项。预选和工具授权不算业务答复，未答项保持未确认，不用候选覆盖既有决定。
 - **交互回执：**交互工具的接口未确认时先查实际工具定义，按其必填字段提问；向执行会话返回工具的真实答案或错误，不用自造的成功标记替代。工具报错先纠正调用，未取得真实答复就保持等待，不推定用户已选择。
-- **写入：**确定真实业务项目根及唯一文档目标，先读现稿和人工修改，保留修改前版本及影响。保持各文档独立版本、能力／主题身份与 FT／US／FR／AC，不按最大版本或同号猜配套。只写本次获准文档及按第4节登记的清单，保留来源、历史和未处理意见。
-- **长文写入与恢复：**长文从首次就按章节或可独立核对的小段写入，每次控制在当前工具可完整接收的范围内，确认实际结果后再续写。使用宿主写入能力将正文作为数据传递，避免把整稿嵌入可执行代码。调用失败先核目标文件现状，区分未写入、部分写入和已写入但回执失败；依据实际已保存正文确定续写点，仅补缺失或修复受影响段，不清空重写整稿或盲目重复追加。同类错误经针对修正仍重复，或无法确定续写边界时，保留稿件和原清单，说明已完成／缺失范围与原因并停下。
+- **写入：**确定真实业务项目根及唯一文档目标，先读现稿和人工修改，保留修改前版本及影响。保持各文档独立版本、能力／PBC身份与 FT／US／FR／AC，不按最大版本或同号猜配套。只写本次获准文档及按第4节登记的清单，保留来源、历史和未处理意见。
+- **长文写入与恢复：**按完整模板确定已完成和剩余范围，分批分析、生成并及时保存，不攒齐整稿才首次落盘，也不缩减整体内容。长文从首次就按章节或可独立核对的小段写入，每次控制在当前工具可完整接收的范围内，确认实际结果后再续写。使用宿主写入能力将正文作为数据传递，避免把整稿嵌入可执行代码。调用失败先核目标文件现状，区分未写入、部分写入和已写入但回执失败；依据实际已保存正文确定续写点，仅补缺失或修复受影响段，不清空重写整稿或盲目重复追加。同类错误经针对修正仍重复，或无法确定续写边界时，保留稿件和原清单，说明已完成／缺失范围与原因并停下。
 
 **保存检查：**核对目标路径、非空正文、实际版本与本次拟交付内容一致；文件存在或标题数量只作辅助。正常保存不要求再次全文加载。分段写入按实际各段核对顺序及全部接缝，检查重复或遗漏；报错涉及的段须复核。工具可比对待保存文本与落盘内容，按需读取差异或受影响正文。完整性不能确认时保留稿件和原清单，说明原因并停下，不自动登记或推进。
 
@@ -101,21 +101,21 @@ T1／T2 写作意图明确后，先通过宿主正式机制显式加载原 `i3-s
 | 动作／完整模板 | 业务输入 | 自动带入及输出 |
 | --- | --- | --- |
 | BRD：[brd.md](references/templates/brd.md) | 业务诉求或外部 BRD；已有项目背景和约束 | 本模板；输出一个 EBC 的 BRD，明确目标、范围、场景、BR及 PBC 划分 |
-| PRD：[prd.md](references/templates/prd.md) | BRD及当前主题，或外部 PRD及业务依据 | 本模板和真实答复／适用规则；输出一个 PBC 的一个独立主题 PRD，保留完整行为、权限、状态、字段、AC及依赖 |
+| PRD：[prd.md](references/templates/prd.md) | BRD及本次PBC，或外部 PRD及业务依据 | 本模板和真实答复／适用规则；输出一个PBC的完整PRD，保留完整行为、权限、状态、字段、AC及依赖 |
 | AD：[ad.md](references/templates/ad.md) | 选定 PRD，或外部 AD及需求依据 | 本模板、默认具体规约与目录规范（项目明确资料优先）、必要契约及工程事实；输出对应 PRD 的三图与完整工程详设 |
-| TestCase：[testcase.md](references/templates/testcase.md) | 选定 PRD／配套 AD，或外部 TestCase及产品、技术依据 | 本模板、必要采用资料及适用测试条件（按模板“来源选择”处理）；输出对应主题／AD 的覆盖、用例、预期和 TestReport 要求，不执行测试 |
+| TestCase：[testcase.md](references/templates/testcase.md) | 选定 PRD／配套 AD，或外部 TestCase及产品、技术依据 | 本模板、必要采用资料及适用测试条件（按模板“来源选择”处理）；输出对应PBC／AD 的覆盖、用例、预期和 TestReport 要求，不执行测试 |
 
-一个业务项目对应一个 EBC，一个 EBC 一份逻辑 BRD；一个 PBC 可有多个主题 PRD，各自独立演进。AD绑定准确 PRD，TestCase绑定准确 PRD／AD，文档不强制同号。关键依据缺失先说明受限范围；企业文档已交审不代表工程规格已齐备。
+一个业务项目对应一个 EBC，一个 EBC 一份逻辑 BRD；一个PBC一套逻辑PRD／AD／TestCase，PRD覆盖该PBC当前明确的完整需求，功能分组在正文内展开，文档各自通过版本持续迭代。AD绑定准确 PRD，TestCase绑定准确 PRD／AD，文档不强制同号。关键依据缺失先说明受限范围；企业文档已交审不代表工程规格已齐备。
 
-四类文档明确记录 `ebcId`、`ebcName`；PRD／AD／TestCase再记录 `pbcId`、`pbcName`、稳定 `prdId`及主题名称，BRD在PBC分配表记录各能力的编号、名称和边界。各稿保留自己的 `documentId`、文档版本、实际路径、状态和采用模板版本。编号沿用已确认业务来源，名称变化不换编号、不自动迁移目录；身份未明先澄清，不从目录名或文件名猜编号。
+四类文档明确记录 `ebcId`、`ebcName`；PRD／AD／TestCase再记录 `pbcId`、`pbcName`、各自文档身份，BRD在PBC分配表记录各能力的编号、名称和边界。各稿保留自己的 `documentId`、文档版本、实际路径、状态和采用模板版本。编号沿用已确认业务来源，名称变化不换编号、不自动迁移目录；身份未明先澄清，不从目录名或文件名猜编号。
 
-**统一命名：**目录名、文档文件名及本稿标题／身份信息、`handoff.json`中的名称和文档路径，统一复用本次同一份已确定的EBC／PBC名称和主题名称，不分别取名、缩写或替换同义名称。AD、TestCase和工程SPEC沿用对应PRD的PBC名称和主题名称；已有名称直接沿用，缺失或冲突时先澄清。清单仍使用现有字段，主题名称体现在文档及其路径中，不新增字段；既有明确采用路径和外部原件保持实际位置，不自动改名或搬迁。
+**统一命名：**目录名、文档文件名及本稿标题／身份信息、`handoff.json`中的名称和文档路径，统一复用本次同一份已确定的EBC／PBC名称，不分别取名、缩写或替换同义名称。AD、TestCase和工程SPEC沿用对应PRD的PBC名称；已有名称直接沿用，缺失或冲突时先澄清。名称在Schema 3中按EBC／PBC身份对应；既有明确采用路径和外部原件保持实际位置，不自动改名或搬迁。
 
 按各模板现有身份／输入／采用表记录引用ID与类型、来源身份、准确路径或URL、正文版本或固定提交及条款、采用范围与落实位置、实际状态与缺口，摘要按需记录。直接依据和跨PBC参考分别标明角色与提供方；主链身份与版本须一致，关联资料可来自其他能力。原型由PRD／AD固定引用，规约、目录规范、实际骨架与契约由AD记录采用及权威位置，TestCase承接适用版本和判据；不另建平行引用清单，也不因资料从JSON移出而省略必要正文读取。
 
 四类文档分别操作。用户明确选用同类已有文档时，读取原件并登记路径，不重复生成或覆盖原件；作为上游、参考或待整理／修订输入时，仍按本次委托写稿。
 
-新建企业文档默认按职责分目录：BRD直接保存在`spec/`根目录，完整路径为`spec/{EBC名称}-BRD_v{业务版本}.md`；PRD、AD、TestCase保存在各自PBC目录，完整路径为`spec/{PBC名称}/{PBC名称}-{主题名称}-{PRD|AD|TestCase}_v{各自版本}.md`。项目明确采用的位置或选用外部原件时登记实际路径，已有文档不因本规则自动移动。仅在生成权限和目标明确后创建必要目录。初始业务版本可建议v0.0.1，已有项目不机械改名或升版，模板版本与业务版本分开。
+新建企业文档默认按职责分目录：BRD直接保存在`spec/`根目录，完整路径为`spec/{EBC名称}-BRD_v{业务版本}.md`；PRD、AD、TestCase保存在各自PBC目录，完整路径为`spec/{PBC名称}/{PBC名称}-{PRD|AD|TestCase}_v{各自版本}.md`。项目明确采用的位置或选用外部原件时登记实际路径，已有文档不因本规则自动移动。仅在生成权限和目标明确后创建必要目录。初始业务版本可建议v0.0.1，已有项目不机械改名或升版，模板版本与业务版本分开。
 
 **EARS 使用：**适用行为写清责任系统及可观察响应，有前置条件或触发事件时明确写出，并核对异常和副作用。保留原文的条件、例外及“必须／应／可”的含义；关键缺口先澄清，一般未决项列为待确认问题（Q）。按当前模板使用，不为句式额外读取其他模板。
 
@@ -129,81 +129,48 @@ T1／T2 写作意图明确后，先通过宿主正式机制显式加载原 `i3-s
 
 没有可读、适用的具体技术规约时，先提示用户根据[通用技术规约模板](references/technical-baseline/templates/technical-baseline.md)生成。取得该技术文档的写入委托后，在当前准备环节起草规约并交审；用户确认后继续 AD，不用空模板代替实际规约，也不自行编选型。已选项目规约失效时先说明，不静默切回默认副本。
 
-结合项目 CONSTRAINTS、ADR、正式契约和工程事实落实设计。目录规范不等于已经生成代码，已有与拟建位置分别写明，实际创建留给后续任务。原型按需，可与 AD并行；共享契约、数据责任、版本兼容和变更影响落实到 AD。
-
-### 4. 自动登记与清单读取
-
-T1 交稿时自动创建／更新 handoff.json，登记本次保存的文档；用户明确选用的同类已有文档同样登记实际路径。仅提供参考稿不视作选用成稿。先核所选文档的EBC身份、文档类型及PBC／PRD主题，身份不明时询问，不猜配套。一个业务项目对应一个EBC，新建清单保存在业务项目的`spec/`根目录，路径为`spec/handoff.json`；其中BRD引用`spec/`根目录文件，PRD／AD／TestCase引用各自`spec/{PBC名称}/`内的文件。路径和参数由主会话显式传入，既有明确采用的清单保留实际位置，不自动迁移。
-
-登记前读取原清单并保留历史，仅处理本次明确资料及输出，保留其他主题；登记后回读结果。实际更新时，旧清单保存在清单同级的`history/`目录，新位置对应`spec/history/`；已有历史不自动搬迁。登记记录所选资料路径，不表示文档获批、内容无缺口或允许开工。只读审查、状态查询和退出不创建或修改清单。
-
-新版顶层仅 `schemaVersion`（整数2）、`scope`、`selected`。以下编号、版本和路径为结构示例，不是已形成或已批准的业务资料：
-
-```json
-{
-  "schemaVersion": 2,
-  "scope": {
-    "ebcId": "EBC-PM",
-    "ebcName": "项目管理"
-  },
-  "selected": {
-    "brd": "spec/项目管理-BRD_v1.1.md",
-    "topics": [
-      {
-        "pbcId": "PBC-PRJINIT",
-        "pbcName": "立项管理",
-        "prdId": "PRD-PRJINIT-001",
-        "prd": "spec/立项管理/立项管理-立项申请与评审-PRD_v0.1.0.md",
-        "ad": "spec/立项管理/立项管理-立项申请与评审-AD_v0.2.0.md",
-        "testCase": "spec/立项管理/立项管理-立项申请与评审-TestCase_v0.1.0.md"
-      }
-    ]
-  }
-}
-```
+结合项目 CONSTRAINTS、ADR、正式契约和工程事实落实设计。目录规范不等于已经生成代码，已有与拟建位置分别写明，实际创建留给后续任务。原型按需，由用户另行发起 `i3-ui-demo`，可与 AD 并行；共享契约、数据责任、版本兼容和变更影响落实到 AD。
+
+**UI Demo 交接：**SOP 场景使用已选 PRD 的准确路径、版本及已确定的 EBC／PBC、PBC身份作为输入；`i3-ui-demo` 保持自身制作和验证方法。PRD／AD 固定引用实际实例路径、版本、`HANDOFF.md`、设计规则、QA 资料及认可范围。SPEC、TestCase 和 Plan 沿这些引用读取必要原型；前端任务把适用设计、交互与验证要求带入工程计划，后续仍按原 Build 和前端工程方法执行。已有旧原型及其明确采用的资料保持原位置，不自动迁移；不要求旧索引或基线文件，不增加清单字段，也不自动进入下一阶段。
+
+### 4. 名称、路径与交接清单
 
-- 一份清单对应一个EBC，`scope.ebcId`、`scope.ebcName`为非空字符串；每条主题必有 `pbcId`、`pbcName`、`prdId`。`pbcId`＋`prdId`在本清单内唯一，同一 `pbcId` 的名称须一致。
-- `selected.topics`始终为数组，无主题时为`[]`；`brd`及主题中的`prd`／`ad`／`testCase`仅在实际形成并选用后登记非空文件路径。主题至少有一份已选资料，缺项省略，不填null、空串、未来路径或虚构配套。
-- 相对路径始终基于业务项目根，不随清单位置变化；脚本将新登记的项目内文档引用统一写成以`/`分隔的业务根相对路径，因此JSON中的BRD路径为`spec/{EBC名称}-BRD_v{业务版本}.md`，PRD／AD／TestCase路径为`spec/{PBC名称}/{PBC名称}-{主题名称}-{文档类型}_v{各自版本}.md`。主会话传入实际已保存的文件路径，脚本不猜目录、不移动文件；已有明确采用位置按实际路径登记，明确选用的外部原件可使用绝对路径。各文档自行记录版本及准确来源，SPEC和Plan继续记录自身来源。
-- 清单不保存 `work`、`capabilityId`、`technicalBaseline`、`engineeringSkeleton`、`prototype`、`contracts`；移出资料的准确引用由第3节及模板承接。v2未知字段先报错并保留原件，不静默删字段。
+一个项目对应一个EBC。T1先从BRD／选定资料和真实答复确定EBC、PBC编号及名称；只有一个明确PBC就沿用，多个PBC且未指定时才请人选择，不再选择独立PRD主题。文件名、正文身份、目录及清单统一使用同一组名称，不以目录猜编号或重新起名。
 
-可按实际CLI使用 [handoff.py](references/handoff.py)（Python 3.9+）：T1无清单时先`init`，再`select`；T2用`resolve`只读取得当前主题引用。T1写稿或明确选用文档的委托包含登记，不另问一次。所有操作必须显式传入预期`--ebc-id`，清单模式还须传同一业务根及实际清单位置；预期编号由当前任务与所选BRD／PRD确定，不能把清单里的值机械回填当作正文核验。
+使用 [handoff.py](references/handoff.py)（Python 3.9+）处理名称、路径及登记。写稿前用只读`prepare`取得本次名称和目标：新稿传实际业务版本；已有登记优先沿用选定路径，自改模板和外部原件保留实际位置。`prepare`不建目录、不写清单或正文，文件存在不授权覆盖；新版本或另存目标须来自本次明确委托，再用`--path`传入。目录仅在目标及写入权限明确后创建。脚本检查名称、身份、路径及清单结构，不证明业务范围完整；正文与选定来源仍按第2／3节核对。
 
-`init`须提供`--ebc-name`；`select`主题资料须提供成对的`--pbc-id`、`--prd-id`，新建主题还须提供`--pbc-name`，已有主题可复用已登记名称。传入名称与已登记身份冲突时报告原文差异，不静默改名。`resolve`只有一个主题时可自动定位，多个主题必须显式选择，不能按最大版本猜选。返回结果含`scope`、所选`topic`身份与名称及各文档实际路径，只证明已读取路径，正文语义及配套仍由主会话核对。
+T1保存并核对完整性后自动创建／更新`spec/handoff.json`，登记本次文稿或用户明确选用的同类已有文档，不另问登记口令；仅作参考不视作选用。`init`创建本EBC清单，`select`登记准确角色和路径，T2用只读`resolve`解析选定PBC。参数由主会话取得，不要求用户填写内部路径。实际清单位置已有明确约定时沿用，不自动搬迁。
 
-以下为新项目的内部调用示意，清单路径显式传入`spec/handoff.json`；既有明确采用的清单替换为其实际位置。其余参数由实际已选资料取得，不要求用户填写内部路径：
+Schema 3顶层仍仅`schemaVersion`、`scope`、`selected`：`scope`含`ebcId`、`ebcName`；`selected.brd`保存BRD路径，`selected.pbcs[]`每个`pbcId`唯一，含`pbcName`及实际形成的`prd`、`ad`、`testCase`路径。缺项不造路径；不再登记`topics`或`prdId`，文档自身`documentId`与版本保留在正文。原型由PRD／AD固定引用；技术规约、目录规范、骨架、契约及测试依据继续由AD／TestCase承接，不放回清单。
+
+主会话内部的AD示例；各占位值来自实际资料，新稿尚无清单时补`--ebc-name`，首次登记先`init`：
 
 ```text
-python3 "<Skill>/references/handoff.py" init --project-root "<业务根>" --manifest "spec/handoff.json" --ebc-id "<ebcId>" --ebc-name "<ebcName>"
-python3 "<Skill>/references/handoff.py" select --project-root "<业务根>" --manifest "spec/handoff.json" --ebc-id "<ebcId>" --role brd --path "<已选BRD路径>"
-python3 "<Skill>/references/handoff.py" select --project-root "<业务根>" --manifest "spec/handoff.json" --ebc-id "<ebcId>" --role prd --path "<已选PRD路径>" --pbc-id "<pbcId>" --pbc-name "<pbcName>" --prd-id "<prdId>"
-python3 "<Skill>/references/handoff.py" select --project-root "<业务根>" --manifest "spec/handoff.json" --ebc-id "<ebcId>" --role ad --path "<已选AD路径>" --pbc-id "<pbcId>" --prd-id "<prdId>"
-python3 "<Skill>/references/handoff.py" resolve --project-root "<业务根>" --manifest "spec/handoff.json" --ebc-id "<ebcId>" --pbc-id "<pbcId>" --prd-id "<prdId>"
+python3 "<Skill>/references/handoff.py" prepare --project-root "<业务根>" --manifest "spec/handoff.json" --ebc-id "<ebcId>" --ebc-name "<ebcName>" --pbc-id "<pbcId>" --pbc-name "<pbcName>" --role ad --version "<业务版本>"
+python3 "<Skill>/references/handoff.py" select --project-root "<业务根>" --manifest "spec/handoff.json" --ebc-id "<ebcId>" --pbc-id "<pbcId>" --pbc-name "<pbcName>" --role ad --path "<已保存AD路径>"
 ```
 
-已有v2清单不重复初始化。BRD登记不带PBC／PRD身份；主题资料仅使用`prd`／`ad`／`testCase`角色。EBC不匹配、名称冲突、旧版或未知字段均保留原件并说明原因；失败按实际参数、路径及范围核对，不盲重试、不另造清单规避。
-
-旧v1不自动迁移，也不把`work`当作EBC编号。只有明确处理具体业务清单时，先回读BRD／PRD核实身份，确认原型引用已由PRD／AD、规约／骨架／契约引用已由AD及适用TestCase承接，再按本次授权补齐文档及v2清单并保留原件／历史；引用未承接或授权不足时保留待处理，不仅删字段。
+`init`须有`--ebc-name`；清单模式每次显式传业务根、实际`--manifest`和`--ebc-id`校验范围，PBC资料按`--pbc-id`定位，新PBC提供`--pbc-name`。`resolve`仅一个PBC时可自动定位，多个PBC先选择，不猜最新版本。回执返回名称、实际路径和读取范围，不代表已审、批准或允许开工。
 
-`select`支持`brd`／`prd`／`ad`／`testCase`四类文档换路径。主会话先回读新旧文档，核实EBC、PBC／PRD主题和文档类型，再登记本次明确使用的路径；脚本在清单模式的每次操作校验`--ebc-id`与`scope.ebcId`，不能省略。只更新指定字段，保留旧文档、清单历史、同主题其他引用及其他主题；回执中的`updatedSelection`提供旧／新路径，不写入业务JSON。
+登记前读原清单，脚本保留准确旧内容到同级`history/`并检查并发变化；重复登记不重复写入。只更新本次角色，保留其他PBC、旧文稿、人工修改及同PBC其他引用；失败保留稿件与原清单并报告。PRD更新后不自动改AD／TestCase，T2核对配套版本。只读分析、状态查询和退出不创建清单。
 
-PRD更新后保留原AD／TestCase引用，由T2检查是否配套，不自动改稿或删除引用。身份或范围不明、其他资料换选、清单并发变化及登记失败时，保留文稿与原清单，说明原因并停下；不绕过保护。T2只读解析不创建或修改清单。
+旧Schema 1／2或未知字段保持原件并停下说明，不自动转成Schema 3，更不能把局部主题PRD改名当完整PBC需求。用户明确处理旧项目后，先按BRD核对完整PBC范围和引用承接，另存／修订后交审，再登记新清单；本流程不自动合并业务稿。
 
-T2默认读取已登记路径；用户仍可明确选择手动传递，不强制补JSON。`resolve --manual`只接受四类文档：有清单时仍核`--ebc-id`，覆盖仅对本次读取生效；无清单时提供`--ebc-id`、`--ebc-name`，主题资料另提供`--pbc-id`、`--pbc-name`、`--prd-id`，形成临时上下文。两种手动方式都不创建目录、清单或历史；主会话同样核BRD／PRD／AD身份、版本及必要引用。
+保留`resolve --manual`的只读传递：有清单时校验EBC，仅临时覆盖本次明确角色；无清单时提供实际EBC及PBC编号／名称和BRD／PRD／AD路径，不建目录或清单。两种方式均执行同样的身份、版本、来源与缺项检查；既有外部原件不自动迁移。
 
 ### 5. T2：工程 SPEC
 
-1. 确定预期EBC和PRD主题，优先沿用已明确采用的清单，否则默认定位并读取`spec/handoff.json`；显式传入实际`--manifest`及`--ebc-id`校验范围：从`selected.brd`取BRD，从当前`pbcId`＋`prdId`对应主题取PRD、AD。多个主题／版本不明先交人选择，不猜最新。无清单且未明确提供手动输入时，提示回T1生成并登记，或由用户补充已有文档；停下等待。
-2. 检查BRD、PRD、AD三份文档的路径、可读正文、EBC／PBC名称编号、主题身份与各自版本，以及AD引用的直接PRD是否与当前选定版本一致。生成稿与用户明确选用的外部稿均可使用。缺少任一项或无法读取时，列出具体缺项及T1对应的`brd`／`prd`／`ad`操作，提示生成或补充现有文件；停止本轮，不先写工程SPEC。PRD更新而AD仍引用旧版、身份名称冲突或其他来源矛盾时，先说明并提示处理，不继续写SPEC，也不用其他主题或旧稿代替。TestCase保持可选。
-3. 使用第2节已显式加载的原Spec，完整读取选定BRD、本主题PRD、配套AD，并沿文档的固定引用读取必要原型、实际采用规范／契约／骨架和相关配置；已有且适用的TestCase读取准确版本。直接依据须与本主题一致，跨PBC参考须明确提供方、用途及准确版本；缺少必要附件时说明受限范围，不因JSON精简而跳过。复用已确认业务事实，只澄清新增工程缺口或冲突。
+1. 确定预期EBC和PBC，优先沿用已明确采用的清单，否则默认定位并读取`spec/handoff.json`；显式传入实际`--manifest`及`--ebc-id`校验范围：从`selected.brd`取BRD，从当前`pbcId`对应PBC取PRD、AD。多个PBC／版本不明先交人选择，不猜最新。无清单且未明确提供手动输入时，提示回T1生成并登记，或由用户补充已有文档；停下等待。
+2. 检查BRD、PRD、AD三份文档的路径、可读正文、EBC／PBC名称编号、PBC身份与各自版本，以及AD引用的直接PRD是否与当前选定版本一致。生成稿与用户明确选用的外部稿均可使用。缺少任一项或无法读取时，列出具体缺项及T1对应的`brd`／`prd`／`ad`操作，提示生成或补充现有文件；停止本轮，不先写工程SPEC。PRD更新而AD仍引用旧版、身份名称冲突或其他来源矛盾时，先说明并提示处理，不继续写SPEC，也不用其他PBC或旧稿代替。TestCase保持可选。
+3. 使用第2节已显式加载的原Spec，完整读取选定BRD、本PBCPRD、配套AD，并沿文档的固定引用读取必要原型、实际采用规范／契约／骨架和相关配置；已有且适用的TestCase读取准确版本。直接依据须与本PBC一致，跨PBC参考须明确提供方、用途及准确版本；缺少必要附件时说明受限范围，不因JSON精简而跳过。复用已确认业务事实，只澄清新增工程缺口或冲突。
 4. 按原 Spec 结构形成完整六项：Objective来自BRD／PRD；Commands、Project Structure、Code Style、Boundaries来自AD及实际规范／骨架／工程配置；Testing Strategy来自AD、已有用例或项目测试规范。写明精确技术版本、成功条件、Q及来源，关键设计落实为可实施和可验收条款，不只写“见AD”，也不编造工程事实。
-5. 新建工程SPEC保存在业务项目的`spec/`根目录，路径为`spec/SPEC-{PBC名称}-{主题名称}.md`；项目已有明确采用位置时沿用实际位置，不自动迁移或覆盖旧稿。记录主题身份、准确来源路径／版本及条款。通常一主题一份SPEC；涉及多个独立能力时按原Spec先划分并交人确认，不将PBC／prdId自动当技术module id。多选目标仍遵守各次审阅停点。
+5. 新建工程SPEC保存在业务项目的`spec/`根目录，路径为`spec/SPEC-{PBC名称}.md`；项目已有明确采用位置时沿用实际位置，不自动迁移或覆盖旧稿。记录PBC身份、准确来源路径／版本及条款。默认每个PBC一份工程SPEC；涉及多个独立能力时按原Spec先划分并交人确认，不将PBC身份自动当技术module id。多PBC目标仍遵守各次审阅停点。
 6. 按第2节核验工程SPEC的落盘完整性并做内容自查，说明六项当前依据、未决影响与可交审范围，请人认可或修改并立即停轮，不自动生成Plan。
 
 ### 6. T3：原规划
 
-1. 选择实际工程SPEC；未明确路径时，默认从业务项目的`spec/`根目录定位当前主题的`SPEC*.md`，既有明确采用位置沿用实际路径。多个范围／版本不明先问。无SPEC时提示T2或退出；普通文档、模板和JSON不当作工程规格。用户另行选择原Plan的等效规格方式，仍沿原能力处理。
-2. 显式调用原 `i3-planning-and-task-breakdown`并按第2节取得完整方法；宿主提供原Plan命令时读取正文并履行产物／停点约定，无命令包装时按原规划Skill执行。加载失败停下说明。
+1. 选择实际工程SPEC；未明确路径时，默认从业务项目的`spec/`根目录定位当前PBC的`SPEC*.md`，既有明确采用位置沿用实际路径。多个范围／版本不明先问。无SPEC时提示T2或退出；普通文档、模板和JSON不当作工程规格。用户另行选择原Plan的等效规格方式，仍沿原能力处理。
+2. 宿主提供原Plan命令时，先定位并完整读取其正文，明确产物和停点约定，再真实显式调用原 `i3-planning-and-task-breakdown`并按第2节取得完整方法；不将命令正文当成已调用Skill，也不额外启动第二次规划。无命令包装时直接调用原规划Skill。所需正文或方法加载失败就停下说明，不先写Plan或任务。
 3. 读取完整选定SPEC及相关代码，按其引用补读规划必要的AD／契约／采用依据，核六项、关键设计、来源变化、直接上游和原方法要求的实际认可。
 4. 输出原 `tasks/plan.md` 及唯一任务目标（默认 `tasks/todo.md`，或项目指定tracker）。将需求／AC和关键设计映射到任务、预计文件、结构与行为验收及验证步骤，记录准确来源。TestCase可选；已有适用版本就用，没有则从真实规格安排验证及必要用例设计任务，不豁免测试策略。
 5. 保留原方法的未完计划保护和依赖／切片规则，不覆盖其他工作未完成的计划。按第2节核验产物落盘完整性并做内容自查，交人审阅后停下；Plan获批后由用户按原Build及后续入口继续，遵守各原方法的权限和停点。
@@ -218,16 +185,16 @@ T2默认读取已登记路径；用户仍可明确选择手动传递，不强制
 
 ## Red Flags
 
-- 模板／项目副本被静默换版，或尚未明确的主题被自动选定。
+- 模板／项目副本被静默换版，或尚未明确的PBC被自动选定。
 - 来源、权限、状态、关键工程约束在文档和任务间不一致。
 - 文件名／正文版本不符，覆盖人工修改，或把建议、预选和工具授权当成业务决定。
 - 没有原Skill实际加载结果，或作者自查被当作独立审查、业务认可或运行通过。
 
 ## Verification
 
-- [ ] 实际调用原方法，输入、模板、来源及主题／版本可定位，未读和缺失范围如实说明。
+- [ ] 实际调用原方法，输入、模板、来源及PBC／版本可定位，未读和缺失范围如实说明。
 - [ ] 输出覆盖完整模板／原方法要求，事实、建议、决定、工程现状和运行结果分别表达。
 - [ ] 长文按段保存，实际段间衔接及失败续写范围已核对；已核验输出落盘完整性，内容自查覆盖来源、身份版本、权限／状态／AC、结构约束及表格，汇报范围与实际检查相符。
 - [ ] 修改前版本、人工编辑、未处理意见和失败记录保留，只写本次授权目标。
-- [ ] T1已保存并核验完整性或读取选定原件，并如实报告清单登记结果；T2已核对同一主题的BRD、PRD、AD，缺项或冲突时未写工程SPEC。
+- [ ] T1已保存并核验完整性或读取选定原件，并如实报告清单登记结果；T2已核对同一PBC的BRD、PRD、AD，缺项或冲突时未写工程SPEC。
 - [ ] 汇报真实路径、版本、自查、Q及影响，按原方法交审停轮，不代签认可或自动推进。

package/skills/i3-enterprise-sop/references/engineering-skeleton/directory-standard.md

@@ -17,7 +17,7 @@
 - 规范约定外层职责；工程内部遵循项目已采用的语言／框架惯例，具体位置由 AD 和真实配置明确。
 - 只采用当前需要的工程类别；实际有内容时再建目录。空目录不等于已交付工程，Git 也不保存空目录。需要先说明预留位置时可写有意义的 README，无需到处添加占位文件。
 - 新建工程标识使用稳定、可区分的小写短横线名称，例如 admin-web、business-api。语言内部包名／模块名遵循其自身规则；现有项目保留原名并建立映射。
-- 工程标识与 PRD 主题、版本分开。同一工程可承接多主题；新增或修订 PRD 不自动复制工程。同一路径不得指向两个不同工程身份。
+- 工程标识与 PBC、版本分开。同一工程可承接多个PBC的功能；新增或修订 PRD 不自动复制工程。同一路径不得指向两个不同工程身份。
 - 目录不是进程、服务、仓库或部署边界。AD 明确源码工程、业务模块、运行应用和部署单元之间的实际关系。
 
 ## 2. PBC 组合工程：pbc-composite
@@ -30,9 +30,9 @@ project/
 ├── spec/                         文档及交接资料
 │   ├── {EBC名称}-BRD_v{业务版本}.md  EBC的BRD直接放在spec根目录
 │   ├── handoff.json              本项目EBC的交接清单
-│   ├── SPEC-{PBC名称}-{主题名称}.md  当前主题工程SPEC
+│   ├── SPEC-{PBC名称}.md  本PBC的工程SPEC
 │   ├── history/                  清单实际更新时保留的历史
-│   └── {PBC名称}/                 本PBC各主题的PRD／AD／TestCase及版本历史
+│   └── {PBC名称}/                 本PBC的一套PRD／AD／TestCase及版本历史
 ├── tasks/
 │   ├── plan.md                   原 Plan 的默认计划
 │   └── todo.md                   仅在采用默认文件任务目标时维护
@@ -56,7 +56,7 @@ project/
 
 使用现有 SOP JSON 时沿用其已采用位置；不要求为了目录规范再创建 .i3/project.yaml、templates.lock、contracts.lock 或生成记录库。已有项目或工具确有这些文件时按其真实用途保留。
 
-BRD默认直接保存到`spec/`根目录，路径为`spec/{EBC名称}-BRD_v{业务版本}.md`；PRD、AD、TestCase默认保存到各自PBC目录，路径为`spec/{PBC名称}/{PBC名称}-{主题名称}-{PRD|AD|TestCase}_v{各自版本}.md`。交接清单保存在`spec/handoff.json`，工程SPEC保存在`spec/SPEC-{PBC名称}-{主题名称}.md`；清单内相对路径均基于业务项目根，实际更新清单时保留的历史位于清单同级`history/`（新位置为`spec/history/`）。一个项目对应一个EBC，其BRD识别相关PBC，同一PBC的多个主题独立维护PRD及配套AD／TestCase版本，配套版本号可以不同。既有明确采用位置、历史及外部原件保留实际路径，不因本规范自动迁移。
+BRD默认直接保存到`spec/`根目录，路径为`spec/{EBC名称}-BRD_v{业务版本}.md`；PRD、AD、TestCase默认保存到各自PBC目录，路径为`spec/{PBC名称}/{PBC名称}-{PRD|AD|TestCase}_v{各自版本}.md`。交接清单保存在`spec/handoff.json`，工程SPEC保存在`spec/SPEC-{PBC名称}.md`；清单内相对路径均基于业务项目根，实际更新清单时保留的历史位于清单同级`history/`（新位置为`spec/history/`）。一个项目对应一个EBC，其BRD识别相关PBC，同一PBC只维护一套逻辑PRD及配套AD／TestCase，各文档通过独立版本迭代，配套版本号可以不同。既有明确采用位置、历史及外部原件保留实际路径，不因本规范自动迁移。
 
 ## 3. 独立 Agent：agent-standalone
 
@@ -68,9 +68,9 @@ agent-project/
 ├── spec/
 │   ├── {EBC名称}-BRD_v{业务版本}.md
 │   ├── handoff.json
-│   ├── SPEC-{PBC名称}-{主题名称}.md
+│   ├── SPEC-{PBC名称}.md
 │   ├── history/                  清单实际更新时保留的历史
-│   └── {PBC名称}/                 本PBC各主题的PRD／AD／TestCase
+│   └── {PBC名称}/                 本PBC的一套PRD／AD／TestCase
 ├── tasks/                       原 Plan 和唯一任务目标
 ├── docs/engineering/            按需：项目规范与工程记录
 ├── <框架构建／配置入口>
@@ -128,6 +128,6 @@ AD 至少映射本次需要的源码／业务模块、配置、测试、契约
 
 已有 web、services、server 等工程组织先按现状映射到逻辑职责，不要求立即重命名。例外要写清实际路径、原因和适用范围；不能一边把旧结构认定有效，一边在新规范目录里生成第二套同名源码。
 
-新增需求优先落到原工程的相应模块。撤销未实施需求不自动删除工程或契约；功能退役通过明确的移除、迁移和回归任务处理，保留已完成历史及其他主题的共享依赖。目录规范变更不自动扩大已有任务授权。
+新增需求优先落到原工程的相应模块。撤销未实施需求不自动删除工程或契约；功能退役通过明确的移除、迁移和回归任务处理，保留已完成历史及其他PBC的共享依赖。目录规范变更不自动扩大已有任务授权。
 
 采用后的项目副本、人工源码与原始失败记录保留。升级资源不覆盖项目自改内容；实际迁移先评估导入、构建、测试、CI／部署和消费者影响，不用重建目录宣布迁移完成。