三个协作空间与 Feature 文档生命周期
V8 更新Feature 工作文档的存放、版本与失效治理
补充日期：2026-11-08。结合 GitLab Issue SSOT、Multica 过程记录和多源知识萃取提出建议。 本章研究了下列业内一手资料，没有迁移或删除现有业务文档，也未修改实际采集/检索配置。
推荐默认：Issue 管当前合同，Multica 管工作过程
用户进一步明确：GitLab Issue 可以按 PRD、design、tech 等命名并相互关联， 文档本身可以是一项独立交付，不是每个 Issue 都有代码或 MR。 因此推荐采用“有类型的 Issue + 关联关系 + 按类型验收”， 正式 PRD、设计和技术方案可以分别以 Issue 正文为唯一维护源；Multica 保留详细生成与讨论过程。 这些文档 Issue 可以从 draft 状态开始持续编辑，不必等 Multica 中已有完整定稿才创建。 文档当前稿在对应 Issue 中维护，逐轮讨论、工具执行和尝试记录留在 Multica。
赞成把每个 feature 的需求、PRD、design、tech、tasks 等工作文档主要放在 GitLab/Multica， 不默认长期留在业务代码主干。但需要按用途区分：同名 design.md 可以是待讨论草案， 也可以是维护当前系统所必需的架构说明；不能只按文件名或“会变化”决定位置。
可长期维护的接口契约、架构决策、测试、运行说明同样会变化，适合与实现一起版本化。 风险来自过期内容被当作当前有效事实。放到 Issue 的旧 PRD 或旧评论，如果不标状态、 不限制检索范围，同样会污染 Agent 上下文，导致错误推断；搬家本身不能解决这个问题。
推荐形成三种使用模式：当前任务的有效工作集、现行工程/业务知识、明确按历史读取的档案。 它们保留关联，但默认检索与 Agent 入口不同。
按三个实际空间分工，而非复制三份文档
用户确认的三个协作空间是 Multica issue/topic/reply、GitLab Issue/MR comment、Git 仓库。 ai-wiki 是稳定知识的聚合/发布落点，不是每个 feature 必须再维护的一份过程稿。
| 空间 | 首要职责 | 典型内容 | 不应自动推断 |
|---|---|---|---|
| Multica issue/topic/reply | 执行协作与过程追溯 | 需求讨论、方案草稿、计划、Agent 交接、尝试、运行反馈、详细过程与证据指针 | 最后一条 reply 就是已批准需求；Agent 宣布完成就验收通过 |
| GitLab Issue 正文 | 当前需求、范围与验收合同的入口 | 目标/验收标准、当前方案引用、未决问题、关联 Multica/MR | 已关闭就意味着全部文字是现行事实 |
| GitLab Issue 备注 | 跨参与者的里程碑摘要与审计 | 关键变更、阻塞、阶段结论、证据链接 | 在备注改了需求就算正文已同步 |
| GitLab MR 描述与 comment/discussion | 针对具体代码版本的交付说明、评审与问题收敛 | 变更理由、验证结果、行级意见、待处理项、处理证据 | discussion resolved 就证明风险消除；旧 SHA 上通过就代表新 SHA 通过 |
| Git 仓库内容 | 与实现版本一起演进的工程事实和维护资产 | 代码、测试、API/schema、重要 ADR、现行架构说明、runbook | 仓库里存在的文件就都具有同等权威或仍然有效 |
这是三个空间内的五种职责。具体执行步骤的状态以 Multica 为准， 需求范围与 验收标准 以 GitLab Issue 的当前合同为准，MR 评审结论绑定具体变更版本， 实现事实以目标版本代码、构建与验证结果判断；不能给所有内容指定一个通用的“最后更新优先”。
建议由执行 Agent 在已授权范围内维护摘要和链接，任务责任人对当前需求与例外负责， 评审者对评审意见的解决依据负责，长期资产维护者对知识晋升负责。 不必为每次自动写摘要增加人工审批，但改变业务目标、风险边界或验收口径仍按已有授权规则处理。
信息流转的最小规则
| 事件 | 原始细节留在哪里 | 必须更新的当前结论 | 何时更新 Git 内容 |
|---|---|---|---|
| 在 PC 或 Multica 聊清需求 | 原对话/Multica，必要摘要转入执行上下文 | GitLab Issue 目标、验收标准、当前方案指针与唯一关联 | 仅产生长期契约/工程资产时 |
| Agent 执行、试错、改计划 | Multica topic/reply | 阻塞或里程碑才写 Issue 摘要；不镜像每条 reply | 实际实现及相关测试按正常提交 |
| 开 MR 与评审 | MR 描述、行级 discussion | MR 当前变更摘要、验证依据、未决评审项；Issue 保留关联 | 修复代码和必要文档，不复制全部评审聊天 |
| 评审提出范围/验收标准 变化 | 讨论留原 MR，并回链任务 | 按授权确认后更新 Issue 当前合同，Multica 重规划受影响任务 | 契约/测试与实现一并更新；旧验证按影响失效 |
| 评审作出长期架构决策 | 原 MR 留讨论及结论链接 | MR/Issue 引用被接受的决定 | 提炼重要 ADR 或更新现行说明；普通命名意见无需一篇 ADR |
| 验证结果变化或新提交 | CI/受控证据存储及 Multica 执行记录 | MR 指向当前 SHA 的结果；重要结果回写 Issue 摘要 | 修复实现/测试；不把原始日志大量提交到仓库 |
| Feature 收尾 | 过程继续留 Multica/GitLab 历史 | Issue 最终交付与差异、MR/证据及长期资产指针 | 长期资产随交付更新；临时计划退出默认知识集合 |
同步应传递明确结论和链接，不做三套全文双向同步。 平台集成建议用 GitLab Issue 标识、Multica issue/topic/run 标识与 MR/SHA 建立关联， 对回写做去重与版本检查；遇到并发编辑不能覆盖另一人的新结论。 失败的摘要回写应可重试并显示待同步状态，不能让 Agent 误以为当前合同已经更新。 上述是接入建议，未声称现有集成全部具备这些能力。
每种产物放哪里
| 产物 | 默认维护位置 | GitLab Issue 保留什么 | 结束后怎样处理 |
|---|---|---|---|
| 需求澄清、问题背景、非目标、验收标准 | Issue 正文维护当前有效版本；讨论在 Multica | 本次最终要解决什么、验收什么、允许什么 | 冻结交付基线，关联 MR/验证与长期资料；标识历史适用范围 |
| PRD | 独立 [PRD] Issue 正文维护当前文档；探索草稿和详细讨论留 Multica |
正文、采用版本、业务规则/详细 验收标准、未决问题与责任人 | 草稿/废案归历史；持续有效的业务规则经核验进入 ai-wiki |
| design：交互稿、视觉稿 | 独立 [DESIGN] Issue 维护设计说明、决定和评审结论；引用设计工具版本/附件 |
当前采用设计、关键交互和必要快照 | 设计系统/现行组件行为另行维护；探索稿保留历史 |
| tech：技术方案、调研和备选路线 | 独立 [TECH] Issue 正文维护当前方案；试验、推演与详细过程在 Multica |
方案正文、重要取舍、风险、依赖和评审结论 | 提炼已接受 ADR、现行架构/契约；废弃方案不进入默认当前知识 |
| tasks：实现步骤、执行计划、拆单 | Multica 管执行任务；可独立验收的子交付用 GitLab 子 Issue | 当前交付范围、阻塞、子 Issue/执行计划链接 | 保留执行历史，不把完成的 checklist 当长期项目导航 |
| 评审往返、日志、实验、失败尝试 | Multica topic reply；大型原始证据留受控存储 | 阶段结论和证据指针 | 保留审计与复盘材料，提炼真正可复用的结论 |
| API/schema、有效 BDD/测试、迁移脚本 | 业务仓，与实现同 MR/版本维护 | 相关契约、用例、提交与 CI 链接 | 成为现行工程资产，由代码变更持续维护 |
| ADR、维护者所需架构说明、runbook | 项目相关部分随业务仓；跨团队知识按 ai-wiki 现行规范归属 | 本次产生/替代了哪些长期文档 | 保留明确状态与替代关系，旧 ADR 不伪装现行决策 |
不要求每个 feature 都生成五套文档。小修复可以是一段 Issue 描述、明确 验收标准 和验证结果； 跨仓或高风险需求再补 PRD、设计与技术方案。产物数量由沟通和验收需要决定。
有类型的 Issue：命名、关联与验收
标题供人识别，标签和关联供工具处理
建议标题采用 [TYPE] 业务主题 — 具体交付。例如以下均为示例，不是已创建的真实工单：
| 类型 | 标题示例 | 主要交付 | 默认是否需要代码/MR |
|---|---|---|---|
| FEATURE | [FEATURE] 字段权限 — 支持按角色控制可见性 |
目标、范围、所选产物/任务清单和整体验收 | 按列出的实际交付决定，不机械要求本 Issue 有 MR |
| PRD | [PRD] 字段权限 — 角色与权限业务规则 |
业务规则、场景、详细 验收标准、未决问题处理 | 不需要 |
| DESIGN | [DESIGN] 字段权限 — 配置页交互与异常状态 |
交互说明、设计版本、可访问性/异常状态与评审结论 | 不需要 |
| TECH | [TECH] 字段权限 — 鉴权与缓存失效方案 |
接口/数据方案、依赖、兼容性、验证和回退设计 | 不需要；若有原型代码，可另关联实验任务 |
| DEV | [DEV] 字段权限 — 后端鉴权实现 |
代码、必要测试、MR 与对应验证证据 | 按代码交付流程需要 |
| VERIFY | [VERIFY] 字段权限 — 跨端权限验收 |
测试执行、环境/版本、报告与验收结论 | 不一定；新增测试代码时再关联 MR |
| RESEARCH | [RESEARCH] 字段权限 — 大规模授权性能调查 |
调查结论、依据、可行性与未决风险 | 不一定 |
这是一份建议类型表，应复用公司已有分类；小需求无需拆齐全部类型。
可用普通标签 kind:prd、kind:design、kind:tech、kind:dev 辅助筛选与分派，
另用 state:draft、state:in-review、state:accepted、state:superseded 表示产物状态。
它们只是普通标签约定，不假定部署具备付费的互斥标签、定制 work item 类型或完整父子层级。
若已有等价标签，沿用并建立映射；若没有自动互斥能力，集成校验“一个主类型、一个当前产物状态”。
标题前缀便于人阅读，自动化读取类型与关系；发现标题/标签冲突时先报告，不从标题猜测后直接执行。
一个 Feature 入口，按需关联多个独立产物
建议用一个 FEATURE Issue 作为整项工作的入口，其中维护目标、整体验收与当前产物索引。 PRD、DESIGN、TECH Issue 各自维护对应正文，不把完整内容反复复制到 FEATURE、DEV 和 Multica。 详细业务 验收标准 以 PRD 为源，DEV 引用适用 验收标准；FEATURE 维护跨交付的整体验收条件和索引。 变更时按字段归属更新唯一正文，再同步受影响引用，避免几份 验收标准 各自漂移。
| 关联示例 | 关系含义 | 当前入口应记录什么 |
|---|---|---|
| FEATURE → PRD / DESIGN / TECH | 本次采用的需求、设计与技术产物 | Issue 完整引用、角色、采用版本/摘要、状态 |
| DEV → PRD / TECH / DESIGN | 本开发任务依据哪些具体产物 | 适用 验收标准、输入版本、必要前置条件 |
| VERIFY → DEV / 验收标准 | 验证哪些实现和需求断言 | 目标 SHA/制品/环境、覆盖项与证据 |
| DEV → MR | 某一代码交付对应哪些变更 | MR、提交、CI 和验收状态 |
| 任一产物 Issue ↔ Multica | 该产物的生成、讨论与执行过程 | Multica issue/topic/run/reply 的关联 |
优先使用部署支持的 Issue 关联能力，原生父子或阻塞关系可用时再使用。
普通 related 关联只说明有关联，不自动表示“采用”“阻塞”或“已批准”；
必要语义在 FEATURE 的产物表或结构化字段中明确，暂不支持原生关系时用双向链接和表格表达。
身份用 GitLab 实例 + project ID/path + issue IID，跨仓引用不能只写 #123。
文档 Issue 可建在对应业务仓的 GitLab 项目中，不要求仓内增加文件；跨仓 Feature 选择归属项目，
关联各实现仓任务即可，不为分类而给每种文档新建一个 Git 仓库。
文档类 Issue 也可以独立存在，例如只交付一个可评审的技术选型方案。 没有后续开发任务时，不必人为补 FEATURE、DEV 或 MR 来满足流程。
不同类型有不同完成条件
| 类型 | 建议完成依据 | 完成不代表什么 |
|---|---|---|
| PRD | 业务规则/验收标准 明确，关键未决项处理，责任人确认当前版本 | 不代表功能已实现或上线 |
| DESIGN | 设计说明/资产可访问，关键状态完整，评审意见处理 | 不代表对应界面已实现 |
| TECH | 方案、取舍、风险、验证/回退设计明确，技术评审完成 | 不代表已有代码或部署 |
| DEV | 实现及必需验证满足项目合同，MR 按流程处理 | 不自动代表生产发布或故障恢复 |
| VERIFY | 指定版本/环境的约定验证已执行，有真实报告与明确 verdict | “验证工作完成”可能得到 FAIL；不能给父任务报验收通过 |
| FEATURE | 本次约定的交付集合及整体验收满足，缺口/例外已处理 | 不要求每种类型齐全，也不能只看关联 Issue 是否全 closed |
GitLab 的 open/closed 表示工作项是否结束，文档 accepted/superseded 表示产物的使用状态， 实现/部署状态则由交付事实判断；三个维度不能混用。 文档评审通过可以按团队规则关闭 Issue，正文仍是该版产物的权威记录； 后续重要变更需重新评审和固定新基线，必要时新建替代 Issue 并更新 FEATURE 的当前指针。 旧版可以保留追溯，但不能继续当当前输入。
MR 的自动关闭引用仅用于其实际满足完成条件的开发任务。
对 PRD、DESIGN、TECH 或 FEATURE 使用普通关联，不能顺手用一个 Closes 关闭整组产物。
Agent 先识别交付类型，再选择工作流
Multica 接单时读取类型、完成条件和关联输入：文档任务进入调研/编写/评审流程， 代码任务进入实现/分层测试/CI 扫描/MR 流程，验证任务进入执行/报告流程。 不能因为创建了 Issue 就自动建分支、写代码、运行全套构建或等待 MR。 图中的 SonarLint、开发自验和人工合并泳道适用于代码交付；文档任务走对应评审与验收路径。 如果一个任务同时含设计与实现，简单场景可在同一 Issue 写清多项交付，复杂场景再拆关联任务。
Agent 默认从当前任务和 FEATURE 的显式产物索引装载输入，不遍历所有 related Issue 后混合正文。 执行前固定所采用 PRD/DESIGN/TECH 的内容版本或快照；已批准文档更新后通知依赖方， 按影响重做方案、代码或验证，不靠 Issue 的更新时间决定哪个版本适用。
一个 Issue 是当前决策入口，不必是一篇超长文档
GitLab 正文应让接手者迅速知道当前有效合同，不要求把几十页 PRD、设计图片和执行记录塞进去。 建议正文包含目标、范围/非目标、验收标准、风险/依赖、当前采用产物清单、未决事项、Multica 关联。 短文直接维护；长文保留一个权威正文，Issue 作为选择当前版本的入口，避免三处同时改同一份 PRD。
外部文档必须能固定版本或导出内容摘要，且执行者具有读取权限。 若当前 Multica 只适合追加 reply，就以明确的 reply ID 和内容摘要标定该版， 在 Issue 中切换当前指针；不要假定其已有独立文档版本 API。 附件也不能只留同名文件的“最新版”链接，需保证接手者能还原派单时的实际输入。
建议使用下面的当前产物清单；这是示例语义，不是现有 API 或强制 schema。
| 角色 | 当前采用内容 | 使用状态 | 可还原依据 |
|---|---|---|---|
| 需求 | Issue 正文中的目标与 验收标准 | 已确认、适用于本任务 | 正文基线快照或内容摘要 |
| PRD | PRD Issue 正文的特定基线 | 已批准用于本轮实现 | Issue 引用 + revision/digest 或受控快照 |
| Design | DESIGN Issue 与设计资产特定版本/节点 | 当前采用 | Issue 引用 + 版本定位或受控快照 |
| Tech | TECH Issue 当前方案基线 | 当前采用 | Issue 引用 + 内容摘要/受控快照 |
| Tasks | Multica 当前执行计划 | 执行中 | 计划版本与关联任务 ID |
阶段摘要放 Issue 备注；重大决策、范围和 验收标准 的变化必须同步到正文/当前产物清单。 不能只在第几十条备注宣布“改成方案 B”，却保留正文和入口仍指向方案 A。 Issue 正文是当前合同入口，引用文档是对应细节的唯一正文；二者的职责不同但应一致。
生命周期与读取规则比存储介质更重要
建议把三个维度分开，复用现有状态字段而非强制另造一套：
- 文档状态：draft / in-review / approved / superseded / rejected / historical。
- 交付状态：尚未实现 / 实现中 / 已验证 / 已部署 / 已回滚；不得从文档批准推断功能已上线。
- 使用范围：任务、团队、仓库、制品/源码版本、环境，以及必要的有效期与复核条件。
“已批准的 PRD”只能说明当时预期已确认，不证明代码已经实现； “Issue 已关闭”也可能是取消、重复或不修复，不证明其中所有段落都是现行知识。 时间较新、评论较后或相似度较高，都不能单独决定权威性。
| 阶段 | 推荐动作 | Agent 可以怎样使用 |
|---|---|---|
| 草拟 | 允许快速迭代，标记假设和未决事项 | 可用于当前讨论与探索，不能当公司规范 |
| 接受委托 | 责任人确认当前合同，固定产物引用与内容摘要 | 仅以这份工作集作为本轮实现依据 |
| 变更 | 更新正文/引用，旧版标替代关系，评估受影响任务与验证 | 重读受影响部分；已过期的输入不能继续支持新放行 |
| 交付 | 记录最终 验收标准、差异、SHA/制品/证据及长期资产链接 | 保留为该次交付基线，不能泛化为未来所有版本 |
| 历史化 | 归档废案和过程稿，检索上移出默认现行集合 | 仅在追溯/复盘或显式历史查询中读取，并带历史标识 |
每个 run 应能追溯所用合同和文档快照。执行中发现新版本，按影响显式升级工作集， 既避免无声使用旧稿，也避免在同一 run 内混合两个版本而不自知。 具体版本锁和失效检查需由工具/执行合同实现，单靠一段“请读最新文档”的提示不能保证。
防止旧草稿污染 repo-wiki、知识萃取和 Agent 上下文
你们已经从代码、TAPD Bug、复盘、需求 Wiki 和反馈中增量萃取知识， 因此需要在采集、发布、检索和任务装载各环节传递用途与状态。
- 采集端保留来源语义。 区分实现事实、需求意图、临时假设、已确认缺陷与历史事件； 已关闭任务不能批量自动晋升为已实现规则，转载同一来源不能算多份独立证据。
- 当前知识按准入条件发布。 人工审定规范、版本绑定的实现知识与核验过的案例分别组织； 历史库可保留原始工作稿，但要能从默认当前检索中排除。
- 任务读取采用显式工作集。 从 GitLab Issue 的当前清单读取本任务批准的 PRD/设计/方案； 草稿只有在明确讨论它时才进入上下文，不全量扫所有 feature 目录或全部 topic reply。
- 索引更新覆盖替换与撤回。 来源改版、废弃、删除、权限变化时，同步页面状态、索引与引用； 拿不到当前版本则报告缺口，不静默用旧缓存冒充最新。
- 回答暴露适用版本与冲突。 当前需求与当前实现不一致时分别陈述，不自动替业务选边； 需求是否实现需要代码/测试/部署事实，重要规范冲突由对应维护者裁决。
默认不将工作草稿写进根 AGENTS、通用 Skill 或项目永久 ai-context 导航。
需要本地文件的 Agent 可以下载任务专属工作集到独立工作目录或受控任务缓存，
带来源、版本和状态，任务结束后不再自动装载。
.gitignore 只影响 Git 跟踪，不保证 Agent 不会读它；
还需显式配置 repo-wiki 规划/排除、wiki-bot 聚合范围和检索过滤，并通过样例验证。
这些是建议的接入约定，不能在未实施前宣称现有工具已自动隔离全部草稿。
FSpec 与文件型工作流怎样兼容
FSpec 已依赖 Git 产物和 SHA 交接，不宜一刀切删掉其规格文件。 可以继续以版本化产物交付阶段内容，同时由 GitLab Issue 选择当前有效版本。 对这类团队，可用独立工作产物仓、受控制品存储，或业务仓内显式隔离且不默认聚合的路径。 选择哪种取决于现有工具能力和交接成本，关键是唯一维护源、版本锁、权限、状态与退出规则。
Git 本身适合精确 diff、review 和版本复现；若持续规格确实与实现共同维护，留在业务仓是合理选择。 但需承担同步维护和历史隔离责任，不能在 feature 完成后把过期 plan/tasks 留作默认项目指导。 不能仅靠最终删除分支保存审计；需有按保留策略可访问的产物快照、commit 或存储引用。
公司默认可以采用“过程在 Issue/Multica，长期工程资产在仓库”的路线； 允许 FSpec 等文件工作流通过同一交付合同适配，不要求全部团队重建工具。
完成 feature 时，做一次有选择的沉淀
建议把收尾列入原任务完成条件：确认最终 验收标准 与实现差异，固定交付证据， 标记废弃方案，更新当前长期文档，并给出本次应沉淀的知识与测试链接。 没有长期价值的过程稿保留历史即可，不为满足形式要求生成重复文档。
例如某字段权限 feature 交付后：工作 PRD/design/tasks 留在任务历史； 最终接口契约、租户/权限回归留业务仓；重要方案取舍形成 ADR； 跨团队有效的权限业务规则进入 ai-wiki；GitLab Issue 链接这些实际落点。 下一位 Agent 从当前规则、代码和测试出发，只有追溯设计原因时才打开历史 feature 档案。
业内一手实践与适用边界
GitLab：当前结论在 Issue 正文，评论承载讨论
GitLab 的 Product Development Flow 明确要求： “Issue descriptions shall always be maintained as the single source of truth.” 它解释，贡献者不应为了了解当前状态而阅读所有评论，DRI 应在各阶段维护描述准确性。 这直接支持你们的 GitLab Issue SSOT、Multica 过程记录和阶段摘要回写模式。 应借鉴这项职责分工，不假定公司部署已具备其当前所有状态或产品功能。
原文：GitLab Product Development Flow
Spec Kit：规格随 Git 管理也是一种有效选择
微软开发者博客对 GitHub Spec Kit 的介绍展示了 spec、plan、tasks 工作流：
生成的 Markdown 在 specs 目录，脚本帮助同一 feature 分支引用前序产物。
这与 FSpec 的文件交接有相似之处，适合需要可复现输入和代码评审的团队。
该文章介绍时明确称其为实验；不能把工具设计当成所有大型团队已验证的最佳组织模式。
其价值在明确、可审阅、可演进的规格，不代表所有历史规格都应永久注入 Agent。
原文：Spec-driven development with Spec Kit
MADR：把长期决策提炼为有状态的 ADR
MADR 建议在项目 docs/decisions 管理 Markdown 决策记录，模板包含
proposed、rejected、accepted、deprecated、superseded 等状态。
这支持从 feature 技术讨论中提炼重要决策，并显式记录替代关系；
保留“当时为什么这样决定”不意味着旧决策仍是当前指令。
原文：Markdown Architectural Decision Records
设计资产引用不依赖某个即将废弃的功能
GitLab Design Management 曾提供 Issue 内设计版本与归档能力，说明关联设计资产可以有明确版本。 但当前官方文档已标记该功能在 18.6 废弃、计划 20.0 移除， 因此本方案采用“设计工具或版本化附件 + Issue 当前引用”的通用方式，不把新方案绑定到该功能。
首批落地验收
- 文档类 Issue 可以独立创建、评审和完成，不因缺分支、代码或 MR 被代码流程误阻断。
- FEATURE 能明确选中各类文档的当前版本，related 旧稿不会被默认当作实现输入。
- 文档 accepted、任务 closed、实现 merged、生产 deployed 分别判断；MR 不误关整组文档 Issue。
- 仅打开 GitLab Issue 正文，能定位当前 验收标准、采用的方案版本、未决事项及 Multica 过程。
- 将旧方案标为 superseded 后，默认当前知识问答不再把它当作有效要求；历史查询仍能追溯。
- 只在评论里改变 验收标准 的负向样例会被识别为正文未同步，不能静默继续执行。
- 当前稿、旧稿和未实现需求同时存在时，Agent 能区分意图、实现和历史，不拼成一个答案。
- 同一 feature 从 PC 交给 Multica，得到同一个有效工作集；换版本后旧验证按影响失效。
- feature 交付后，回归/契约与必要长期文档已到正确位置，过程稿不再进入默认工程上下文。