Compare commits
24
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 weichen
|
73bbb4cea6 | ||
 weichenandCursor
|
945db355fc | ||
|
weichen
|
f01aefa4eb | ||
|
weichen
|
5f411499c5 | ||
|
weichenandCursor
|
034faa4021 | ||
|
weichen
|
d668a3e0ac | ||
|
weichenandCursor
|
2a8deac89d | ||
|
weichen
|
87b88018b9 | ||
|
weichen
|
136534ce0d | ||
|
weichen
|
19aa34efe6 | ||
|
weichen
|
a665c2d0b9 | ||
|
weichen
|
28c4ceb173 | ||
|
weichen
|
8e3b5b0d28 | ||
|
weichen
|
77c8cc2548 | ||
|
weichen
|
aa4d372f01 | ||
|
weichen
|
5909cb37cf | ||
|
weichen
|
46506aec34 | ||
|
weichen
|
9062445db8 | ||
|
weichen
|
6619835a65 | ||
|
weichen
|
fdca353097 | ||
|
weichen
|
2d35cd49c2 | ||
|
weichen
|
3e0cdae1bf | ||
|
weichen
|
c256558ca8 | ||
|
weichen
|
8e9587ca1d |
@@ -7,15 +7,13 @@ artifact_contract: rdm-increment-plan/v1
|
||||
product_contract_source: legacy-requirements
|
||||
---
|
||||
|
||||
# RDM 设置归属、成员、文档职责与权限矩阵完善增量方案 r1（附 r1.1 修订，2026-10-14 评审通过）
|
||||
# RDM 设置归属、成员、文档职责与权限矩阵完善增量方案 r1
|
||||
|
||||
负责人：weichen；编制：ZCode；核对日期：2026-10-13（北京时间）。
|
||||
上游方案：[2026-10-12 RDM 功能、实现与计划矩阵及整改方案](2026-10-12-rdm-function-implementation-plan.md)（下称"总案"），本增量承接其本稿 U3、U4、U6，涉及职责一致性的部分衔接 U5。
|
||||
|
||||
评审状态：2026-10-13 用户评审通过（同意方案及技术评审意见），并授权按本方案实施（P1–P8 两批推进；正式验收与清理回收节点保留人工确认）。技术评审对源码声明的逐项核查结论见文末「评审核查记录」。
|
||||
|
||||
2026-10-14 增补的 r1.1 为两项阶段 4 修订，**已于 2026-10-14 获用户人工评审通过**（连同阶段 6 实施候选一并批准；依据见文末「评审核查记录」之后的评审结论）。r1.1 不改变 P1–P8 范围或正式验收门禁。
|
||||
|
||||
## Goal Capsule
|
||||
|
||||
以现有 RDM 实施总案的一个完整增量，先厘清设置归属和服务端权限，再补齐搜索、选择、职责分配与权限矩阵交互，保证界面显示、保存结果和实际执行一致。终点：创建者、普通成员、职责人员在真实账号浏览器流程中完成成员添加、职责分配、权限查看与设置保存，且服务端边界（受管设置、成员校验、原子职责变更、权限范围）全部经真实请求验证。
|
||||
@@ -83,6 +81,10 @@ product_contract_source: legacy-requirements
|
||||
|
||||
## 四、文档查找与职责分配
|
||||
|
||||
> 2026-10-15：本节的职责页交互（文档清单加选中详情、章节级入口、整文审签）已被
|
||||
> [文档职责矩阵整改 r2](2026-10-15-rdm-duty-matrix-rework.md) 取代。成员校验、版本冲突、
|
||||
> 在途审签确认和历史保全仍然有效。下文保留作被取代前的记录。
|
||||
|
||||
文档职责页面采用“**文档清单＋选中文档的职责详情**”：
|
||||
|
||||
- 上方提供统一搜索框，支持文档 ID 精确检索、标题精确／模糊匹配。
|
||||
@@ -164,9 +166,9 @@ product_contract_source: legacy-requirements
|
||||
| P2 系统设置闭环 | Core 设置描述、Backend 设置 API／存储／生效链／模型及密钥解析；系统管理入口 | P1；**基座发版与 RDM/Dev 升 pins**（见评审补充 1） | 系统受管项只能由有权管理员配置，旧个人／项目值不能覆盖 |
|
||||
| P3 人员与成员接口 | 扩展公开账号搜索；RDM 专业角色摘要、成员查询、项目身份调整与提交校验 | P1；姓名来源核实（见评审补充 3） | 账号／姓名／角色过滤同源，添加与身份调整明确分离 |
|
||||
| P4 文档与职责接口 | 专用文档目录、当前职责读取、统一职责服务、版本校验、变更失效及成员移除联动 | P1、P3 | 跨项目／非成员指派被拒，职责与审签变更全成或全败 |
|
||||
| P5 通用选择器 | UI 仓搜索选择、单／多选、键盘操作、分页与状态；Frontend 人员／文档适配 | P1，接线依赖 P3、P4 | 三类使用场景共享交互，无自由文本误提交 |
|
||||
| P5 通用选择器 | UI 仓搜索选择、单／多选、键盘操作、分页与状态；Frontend 人员适配。文档职责页的文档选择器改由 r2 三视图承接 | P1，接线依赖 P3、P4 | 人员选择共享交互，无自由文本误提交。职责页交互见 r2 |
|
||||
| P6 权限解释与矩阵 | RDM 项目动作目录、单人／批量解释、覆盖三态、来源与拒绝原因 | P1、P3 | 矩阵与执行规则一致，系统动作无法写入项目覆盖 |
|
||||
| P7 项目设置集成 | 重构现有项目页，连接四个页面、能力状态、读取回填与保存结果 | P2—P6 | 创建者、普通成员、职责人员均有对应可用流程 |
|
||||
| P7 项目设置集成 | 重构现有项目页，连接设置、成员与权限页。文档职责页改为 r2 的三视图，不再包含整文审签 | P2—P6 | 创建者、普通成员、职责人员均有对应可用流程。职责页验收以 r2 为准 |
|
||||
| P8 迁移与组合验收 | 旧配置处置、真实数据库与浏览器验收、精确组件组合验证、证据回填 | P2—P7 | 需求到证据闭合，无越权、隐私泄露或数据丢失 |
|
||||
|
||||
前端主要改动落在现有 `ProjectSettingsModal`、`adminRdmSections`、`rdmManagement`、`api` 和 `store`；按业务拆分成员、职责及权限组件，避免继续扩大一个管理组件文件。
|
||||
@@ -238,29 +240,8 @@ product_contract_source: legacy-requirements
|
||||
| 职责目标未校验成员 | `rdmReviewAssign` handler 注释“数据，非身份”——按 G1-5 旧裁定绕过成员校验；**本方案 P4 推翻该裁定，属规则变更，在 P1 契约中记录** |
|
||||
| 职责更新与审签失效分步 | 文档级 assign 先写职责再调 `InvalidateActiveDocSubmission`，两步顺序非原子；**章节级 assign 完全未接失效** |
|
||||
|
||||
## 阶段 4 修订 r1.1（2026-10-14 编制，2026-10-14 人工评审通过）
|
||||
|
||||
### 旧项目配置冲突的来源选择
|
||||
|
||||
r1 评审补充 2 已批准“同键取最近写入时间”为默认合并规则。实施核查发现旧 `(owner, project)` 设置行没有逐键修改时间；行或快照时间不能证明每个键最后由谁写入。若按该时间自动决定来源，就会把无法证明的先后顺序当作数据事实，可能覆盖另一成员的项目策略。
|
||||
|
||||
候选修订：先按项目和路径列出旧副本及脱敏冲突状态，不自动选择冲突值。有权配置该项目的人在预览中逐路径选来源；观察记录绑定操作者、项目、来源和目标版本，应用时重新鉴权、复验记录与版本，并在事务中写入共享项目配置。旧行保留作只读恢复依据，受管系统项和个人秘密不自动提升为共享配置。无冲突路径也须在预览中明确来源，不能把行时间冒充逐键时间。失败不部分迁移；相同观察重试保持幂等。生产迁移及正式验收尚未执行。
|
||||
|
||||
备选是补造逐键时间或以固定成员优先级自动覆盖；前者没有历史依据，后者会静默丢弃其他成员选择，因此本候选采用显式裁定。用户于 2026-10-14 评审通过本修订：以逐路径显式来源选择替代 r1 评审补充 2 的“同键最近写入”默认规则；生产迁移仍 **NOT_RUN**，待正式组合验收时按本修订执行。
|
||||
|
||||
### 项目设置写入的公开授权合同
|
||||
|
||||
共享配置改为以项目为权威后，Backend 必须由宿主项目判断读者和配置者。现有 `ResourceAuthorizerV2` 只覆盖资源读取，`ProjectLifecycle.Work` 只说明成员可工作，二者均不能推断项目设置写权限。候选增设可选的 `ProjectSettingsRegistry.RegisterProjectSettingsAuthorizer`，由与项目生命周期相同的提供者按受信 actor、宿主 projectID 和读／写动作作出判定；缺失提供者或拒绝均失败关闭，HTTP 请求不能自报其他主体或项目来绕过。
|
||||
|
||||
该公开扩展点保留旧插件兼容：未注册回调的插件不能因此获得共享项目设置能力；基座其他个人／系统设置仍走原有各自授权。用户于 2026-10-14 评审通过该模块职责与接口；正式基座扩展发版仍属高后果操作，按双钥匙由用户亲手执行，随后 RDM/Dev 升正式 pins 并做组合验收。具体请求、版本和失败语义见 [接口与验证记录](../records/2026-10-14-rdm-settings-completion-contract.md)（当前 r0.3；受评版本 r0.2）。本阶段只完成源码与隔离 SELF 自检，没有发布版本或升级正式 pins。
|
||||
|
||||
## 评审结论（2026-10-14）
|
||||
|
||||
评审人：weichen（用户）。评审对象：Documents 主方案 r1.1 两项修订（受评提交 `62c2e2347e7656ee5a07900d77968ecbea415bbd`）、接口记录 r0.2、阶段 6 实施候选（Dev 任务 HEAD `3336bcb` 组件组合，RDM `931fc4c33aceb7105b319a886d6ee817896200fd`）。用户结论：“请分别评审：①以逐路径显式选择来源替代旧配置‘最近写入’规则；②新增缺失即拒绝的项目设置授权回调；③阶段 6 实施候选。……评审通过，推进下一阶段。”三项均记为**通过**；阶段 7 正式测试与验收据此进入，其人工节点仍按 `policy/delivery.md` 保留给用户。
|
||||
|
||||
## 主记录与推进
|
||||
|
||||
- 主记录：本文件（唯一方案正文）；历史任务卡 `.task/archive/feature-rdm-increment-settings-duties.md` 仅保留原增量记录，当前完成性修复由 Dev/RDM 同名 `feature-rdm-settings-completion` 任务卡承载证据与阶段结论。
|
||||
- 主记录：本文件（唯一正文）；任务卡 `.task/feature-rdm-increment-settings-duties.md` 承载需求表、证据与阶段结论。
|
||||
- 来源：`.tmp/Discussion-Meetings/2026-10-08_12-24/.tmp/user-supplement.txt`（原始用户补充）、2026-10-13 会话评审。
|
||||
- 当前进展：P1–P8 的源码候选及阶段 6 SELF 自检记录在 Dev/RDM 同名任务卡；r1.1 的两项阶段 4 修订和阶段 6 产物已于 2026-10-14 获用户评审通过。基座正式发版、RDM 正式 pin 升级、阶段 7 正式验收与后续 Review／合入尚未完成。
|
||||
- 下一步：按本方案的发版依赖进入阶段 7 正式测试与验收：先由用户按双钥匙完成基座公开扩展发版，RDM/Dev 升正式 pins 后执行正式组合验收（含生产迁移预演决策、真实多身份浏览器与真实模型任务级对照）；发布版本的双钥匙边界不变。
|
||||
- 下一步：P1 已随本稿固定；按两批顺序进入 P2（基座受管设置契约扩展申请）与 P3/P4/P6 服务端实现。
|
||||
|
||||
@@ -0,0 +1,313 @@
|
||||
---
|
||||
title: DHF 模板接入 RDM 文档生成管线 - Plan
|
||||
type: feat
|
||||
date: 2026-10-14
|
||||
artifact_contract: ce-unified-plan/v1
|
||||
product_contract_source: legacy-requirements
|
||||
origin: 2026-10-11-rdm-template-dialog-generation.md
|
||||
execution: code
|
||||
---
|
||||
|
||||
# DHF 模板接入 RDM 文档生成管线 - Plan
|
||||
|
||||
## 批准与实施进展（2026-10-14 后续附注）
|
||||
|
||||
本节记录批准后的状态；下方 r0.1 主文保留批准前评审快照，原对象 SHA256 为 `f99e1424a9bb86f68ad6de91657102a36004c61fb0f36c8427e913d9e0cf9643`。主文中的“草案”“待批准”“本轮 NOT_RUN”指当时状态，不代表今日仍未获实施授权。
|
||||
|
||||
- owner 已批准 r0.1 的需求、方案和实施计划并授权 U1–U6 按阶段推进，另批准 E1-R1 隔离追加试验。U1 当前增量已走完阶段 6–10：阶段 6/7 获 owner 人工结论，独立 Review 闭合整改，最终 HEAD 的 GATE 与独立重放核验记录在案，三份交付 PR 均已合入。
|
||||
- RDM 已封装 44 个逻辑原件，owner 分别接受项目建议书、F01、F02、DI 四份确切四哈希包（内容与版式接受，正式发布授权仍未给出）；全部 44 项仍 `needs-review`，正式发布数 0。E1/E1-R1 使 14 DOC 均有转换候选，但逐项 Word 保真 **NOT_PASSED**；其余 40 项待包级裁定。F01/F02 的正式类型/存量字典升级及 U2–U6 真实产品流程仍未完成。
|
||||
- U1 当前增量的终态以归档任务卡为准：Dev 仓 `.task/archive/feature-dhf-template-pipeline-plan.md`（随 Dev #542 归档合入）。合入记录：[Documents #102](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/102) merge `9062445db808`、[RDM #365](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-RDM/pulls/365) merge `57d2214feb0a`、[Dev #540](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/540) merge `11aa76a3bc1c`，三个 main 树各自与受测 head 一致。U1 剩余 40 项包级裁定、14 DOC 保真对照、类型合同与 U2–U6 按本方案顺序继续；此前 WIP/待整改表述与旧 GATE 不再作为放行依据。
|
||||
- **2026-10-14 收口（本轮）**：批量 1–5 包级裁定获 owner「全部按推荐」批复并落档（RDM `docs/records/dhf/package-review-decision-2026-10-14.md`）；其余 DOC 11 份（#377）与 DOCX 17 份（#381）四哈希候选包合入，44/44 具备候选包；owner 同轮授权 catalog 翻转，#383 将 44 项全部置 `published`＋confirmed＋绑定四哈希＋issues 全清。U5 交付命令接线与实例播种随 #385 落地，真实产品二进制全链路试点 PASS；U6 逐项验收矩阵随 #387 完成——44/44 入账＝41 PASS＋2 EXPECTED_BLOCKED（F01/F02 字典门禁，owner 裁定暂缓）＋1 EXPECTED_LIMITED（无槽位确认报告，空填充 fail-closed 拒绝实测），0 FAIL；过程中修复 F05/F06 封面双层嵌套缺陷并补登记 11 个批量裁定 docType。卡片 #379/#382/#384/#386/#388/#390/#392 全部归档，RDM main `c5ea0f5`。交接文档 [u6-replay-handoff.md](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-RDM/src/branch/main/docs/records/dhf/u6-replay-handoff.md) 固化 owner 侧三项动作：①部署发布包＋三用户真实试点（回传导出 Word SHA256 与审签元数据）；②独立审阅者以一键驱动 `scripts/dhf-u6-replay.sh` 完成 R1–R4 重放并签署（作者 SELF 试运行全绿，审阅者重跑方为 REPLAY）；③提供带附件/页眉页脚的真实原件路径以启动 U4。独立 REPLAY 与真实环境试点完成前，本方案 DoD 的「试点交付/全量交付」两项维持 owner 阻塞态。
|
||||
|
||||
修订 r0.1；需求负责人 weichen；方案编制 Codex；各仓实施负责人待立项指定。
|
||||
本文件是 DHF 接入专项的评审草案，授权终点为源码/资产调查、方案和计划文档、记忆归档。
|
||||
需求取舍、设计、实施和测试计划仍须按 Dev `policy/delivery.md` 逐阶段评审；本文不授予业务实施、转换试验、迁移、发布或部署权限。
|
||||
文件路径以目标仓为准：`Dev:` 为 Agent-System-Dev，`RDM:` 为 Agent-System-RDM，`Frontend:` 为 Agent-System-Frontend；无前缀为 Documents 仓。
|
||||
|
||||
## Goal Capsule
|
||||
|
||||
用户能在 RDM 项目对话中，按提供的 DHF 标准模板编制文档，取得内容有依据、格式可核查、审签版本一致的 Word 文件。
|
||||
采用现有 RDM 模板、两树一网、持久提案和三权流程，补齐 Word 资产解析、固定绑定和模板填充导出。
|
||||
本批最终覆盖 Dev `.templates/DHF 文件模板/` 全部 44 份逻辑资产；试点成功只代表试点完成。
|
||||
首选下一步是评审范围及解析试验 E1；E1 的 DOC 保真结果是全量接入的前置条件。
|
||||
|
||||
---
|
||||
|
||||
## Product Contract
|
||||
|
||||
### Summary
|
||||
|
||||
将 44 份 Word 原件转为可审核发布的模板包，使其内容结构、填写规则和原始版式共同约束文档生成。
|
||||
先用真实 DHF 项目建议书完成一条用户闭环，再按文档族接入全部资产；设计输入规格书和验证确认报告同时作为结构与示例语义的压力样本。
|
||||
登录恢复为已收官基线；本专项不把部署增强或账户恢复重新列作遗留实现项。
|
||||
|
||||
### Problem Frame
|
||||
|
||||
RDM 当前注册量不能代表标准模板可用量。
|
||||
已有模板选择、章节实例化和导出器缺少共同的模板身份，新增 Word 文件后仍可能生成错误用途的正文，或者丢失原件的表格与排版。
|
||||
模板中的示例测试结果和签署意见还可能被误当作本项目已经发生的事实。
|
||||
|
||||
### Current State
|
||||
|
||||
本轮源码/资产观察为 SELF，业务测试、DOC 转换、真实模型、浏览器验收、CI 和部署均为 NOT_RUN。
|
||||
调查对象：Dev R0 `add097d06137c4912a4ed9279e98ca353e4e4cf1`；RDM `6fcb256205c2384abed35d3b6ab96ca7216e9297`；Documents 草案从本轮 SSH/API 同值的 main `7bd4e17827d4c7c88647bf3c9199c495b60cb107` 建立。
|
||||
RDM 正式产品的 Frontend gitlink 与实际检出均为 `eb2d6d32f9323094d568bc9d80b4e5ed4f0af25b`；该源码基线用于定位当前预览行为，不代表组合浏览器验收。
|
||||
Dev 固定 Documents 的 `a7ff466…` 与本轮 Documents main 不同；本轮只保存规划，不推进 gitlink，未来集成须处理两条历史及规范差异。
|
||||
源码/资产原始输出与完整 SHA 由 Dev 任务卡的 evidence 段记录；以下是静态分析，不是运行通过声明。
|
||||
|
||||
| 对象 | 当前事实 | 接入含义 |
|
||||
|---|---|---|
|
||||
| DHF 原件 | 44 份：30 DOCX、14 DOC，7 阶段；41 个不同 SHA256 | 同内容不同阶段仍保留独立逻辑用途 |
|
||||
| RDM 目录 | 69 个 docType，73 项 registry：4 定制 Markdown＋69 骨架 | 骨架含“内容要求待补”，不算 69 份标准正文已迁入 |
|
||||
| Word 原件 | RDM 未跟踪 DOC/DOCX 原模板 | 需要可脱离 Dev 工作目录的正式资产包 |
|
||||
| 现有解析 | DOCX 主要读 document.xml，DOC 不支持 | 不能用文本抽取代替完整内容和版式解析 |
|
||||
| 模板选择 | Compose 按适用列表首项选 key；rd_proposal 首项为 weekly-report | 必须消除注册顺序决定正文用途 |
|
||||
| 结构实例化 | 独立 structure YAML 建文档/章节，无公开的按模板实例化命令 | 模板发布、文档创建与生成入口需要接成一条路径 |
|
||||
| 固定版本 | Doc/Section/Version 未存真实模板绑定；提交的 TemplateVersion 实为字典版本 | 当前快照无法证明 Word 模板身份不漂移 |
|
||||
| 审签与提案 | 有事务采纳、幂等、持久提案及整文三权 | 扩展既有机制，不重写审批和项目权限 |
|
||||
| DOCX 导出 | 新建最小 OOXML，不消费原件版式；未按指定整文审批轮次导出 | 需要原模板填充和批准快照再现 |
|
||||
| 用户入口 | 自然语言写文档 intent 用错 docType 且仅查询模板；正式 Web 使用 Frontend pin | 真实对话、工具 schema 与正式 React 产品均需验证 |
|
||||
|
||||
资产阶段分布：商务 1、策划 3、设计输入 15、设计输出 9、设计验证 8、设计转换 3、设计确认 5。
|
||||
四份输出/验证/转移/确认评审原件字节相同，但不能合并为一份逻辑模板。
|
||||
候选适配为 32 份映射既有类型、12 份新增或细分用途待评审；不等同于批准新增 12 个类型。
|
||||
|
||||
### Requirements
|
||||
|
||||
资产与内容约束：
|
||||
|
||||
| ID | 要求 | 可判定验收条件 | 来源 |
|
||||
|---|---|---|---|
|
||||
| R1 | 44 份原件逐份登记来源、用途、版本和状态 | 每个路径有完整 hash 和处置；重复内容保留逻辑用途；未验证项不可标可用 | 本轮范围；TT-T01/T04 |
|
||||
| R2 | 保留真实多级结构、表格、填写规则与关键版式 | 对照每份原件无关键静默丢失；DOC 的解析/转换差异有人工裁定 | TT-T01/T02；现有模板方案 R3/R11 |
|
||||
| R3 | 示例、说明、占位符与固定文本分别处理 | 无真实证据时不预填验证成功、样本量或签署；模板内产品示例不进入项目事实 | 原件填写说明；原方案 R6 |
|
||||
| R4 | 模板用途和项目适用性明确 | 选择显式正文模板；计划/报告、验证/确认用途不混用；不适用部分注明理由 | TT-T03；原方案 R1/R3 |
|
||||
|
||||
生成与受控交付：
|
||||
|
||||
| ID | 要求 | 可判定验收条件 | 来源 |
|
||||
|---|---|---|---|
|
||||
| R5 | 新实例及历史内容固定实际模板身份 | templateId/version 与原件、结构、渲染包的完整 hash 可复核；升级不改旧版本 | TT-T04；原方案 R3/R9 |
|
||||
| R6 | 用户能从项目对话创建或更新模板文档 | 真实认证总线到实例化、生成、提案、采纳；歧义先澄清；总结请求不触发写入 | 原方案 R2/R7/R13 |
|
||||
| R7 | 生成和下载遵守现有项目、资源和文档职责 | 仅指定编制人生成/采纳；检索与模型输入授权；恢复、撤权及下载再次核验 | 原方案 R4/R9/R11 |
|
||||
| R8 | 模板、正文、依据和审签使用同一冻结对象 | 旧卡片/并发/模板退役均不能覆盖新内容；正式导出读取指定批准快照 | 原方案 R5/R7/R8/R9/R11 |
|
||||
| R9 | 完成状态以实际 Word 与用户流程验收为准 | 每个发布模板至少一个正常样例及一个空缺/冲突样例；44 份全部有结果 | 原方案 R12；TT-V01–03 |
|
||||
|
||||
### Scope Boundaries
|
||||
|
||||
本专项承接在途 `feature/rdm-two-trees-latest-templates` 的 TT-T01–04，依赖其 TT-D01–04 的递归结构、结构提案和版本保护。
|
||||
该任务已形成阶段 2 评估；本轮读取的记录仍待人工评审，不把其文字升级为实施批准。
|
||||
两个任务只能有一处权威模板/内容块契约和一份 44 资产台账；实施立项前指定契约 owner，按共同 R0 分工，禁止各做一套树或升级机制。
|
||||
原两树一网任务其余需求继续由其主记录维护，本专项的聚焦不削减那 28 项完整范围。
|
||||
|
||||
### Deferred to Follow-Up Work
|
||||
|
||||
未提供新标准原件的其余 37 个既有类型保留兼容和明确状态；不以本批 44 份宣称覆盖全部 69 类型。
|
||||
历史报价 XLSX 不在本批 Word 接入范围；全局项目字典扩展、默认成员工作上下文、完整审计展示继续归原两树专项。
|
||||
`-open-existing` 修复和 U2/U3 部署增强保持独立新需求。
|
||||
旧项目批量改绑、运行库迁移和上线需独立方案与授权，本轮不启动。
|
||||
|
||||
### User Flow
|
||||
|
||||
用户在可信项目对话中提出“按 DHF 模板生成项目建议书”；系统确认目标文档、用途和已发布模板。
|
||||
已有同类文档时展示更新目标；缺职责时等待负责人分配，由指定编制人接续。
|
||||
模板不适用、资料不足或用途歧义时保留待处理状态，不能退回任意骨架继续生成。
|
||||
生成任务使用已固定且有权使用的项目依据，返回逐块内容、来源、差异和缺项；编制人采纳后才形成内部版本。
|
||||
审核和批准绑定整文快照；草稿与正式版可区分地预览/下载，正式 Word 从指定批准快照和固定模板包生成。
|
||||
|
||||
---
|
||||
|
||||
## Planning Contract
|
||||
|
||||
### Key Technical Decisions
|
||||
|
||||
KTD1. 将原件、结构合同、渲染包组成同一个不可变模板发布版本；登记阶段/用途、适用规则和来源谱系。
|
||||
原件永久保存；DOC 转换产物是派生件，记录转换器版本/配置及产物 hash。
|
||||
默认模板只能从人工确认的显式绑定取得；语义版本比较替代字符串最大值，骨架显示“待标准模板”，不得混成已发布 DHF。
|
||||
共享模板/默认绑定治理沿用[原模板方案 KTD1](2026-10-11-rdm-template-dialog-generation.md#ktd1-template-contract-and-authority)的获批仓库发布边界；本专项不开放运行时模板管理权限。
|
||||
|
||||
KTD2. Word 在资产准备阶段规范化为 DOCX，运行时不新增 LibreOffice 服务依赖。
|
||||
先复用在途 E1 的隔离试验，验证 DOC→DOCX 的可行性与损失；不得直接把 DOC 二进制当字符串或重命名扩展名。
|
||||
建议方法受官方格式与转换接口支持，但本批保真尚未验证：[MS-DOC 格式](https://learn.microsoft.com/en-us/openspecs/office_file_formats/ms-doc/ccd7b486-7881-484c-a137-51170af7cc22)、[LibreOffice 转换参数](https://help.libreoffice.org/latest/en-US/text/shared/guide/start_parameters.html)、[格式过滤器](https://help.libreoffice.org/latest/en-US/text/shared/guide/convertfilters.html)。
|
||||
E1 先检验用户需求、软件测试用例、采购技术说明三种 DOC 样本，再覆盖全部 14 份；失败项保留未验证，不能降低 R2。
|
||||
本轮 PATH 未找到 LibreOffice/soffice；固定工具版本、隔离环境和试验授权仍是前置条件。
|
||||
E1 使用独立转换器 profile、只读原件和隔离临时输出，禁用宏、外部内容加载和网络；转换进程不得访问用户凭证或运行库。
|
||||
|
||||
KTD3. 结构合同采用原两树专项的递归内容块，模板只定义其约束和 Word 槽位映射。
|
||||
块具有稳定 ID、层级、顺序、填写语义、字段/重复行/合并关系、依据需求、适用性和附件引用；显示标题不作为身份。
|
||||
解析综合样式继承、outlineLvl、自动编号、正文顺序和表格关系，人工确认其业务含义。
|
||||
蓝字、斜体、黑字只是分类线索；预填的 IQ/OQ/PQ 成功、样本量 22 和“同意”意见必须按 R3 处理。
|
||||
|
||||
KTD4. 扩展现有领域对象、事件 payload 和 replay，固定模板绑定及每次生成的内容/依据基线。
|
||||
增加 RDM 领域的按模板实例化与生成编排入口；既有 compose/propose/adopt 适配到同一约束，不建立第二个提案或审批库。
|
||||
实例化事务创建文档、内容块和模板绑定；确认/采纳使用预期版本、opId 幂等和事务内复验。
|
||||
生成任务保存输入清单与候选，失败可恢复；恢复重新验证权限及模板可用性，缺少依赖时返回明确待处理结果。
|
||||
|
||||
KTD5. DOCX 采用固定原模板包的槽位填充渲染，结构化内容是业务正文权威。
|
||||
保留原件的封面、页眉页脚、样式、编号、图片和非填充部件，确定性填充已标记的段落/单元格/重复行。
|
||||
发布检查识别会自动读取外部内容的关系；派生渲染包禁止保留外链图片加载，普通引用链接保持可审查的文本/超链接语义。
|
||||
本批《原材料进货检验规范》的图片同时有内嵌 rId11 和外链 rId12；派生包保留内嵌图片，移除 rId12 关系及对应 r:link，原件不变，处置进入差异台账。
|
||||
只有外链而无可保全本地内容时阻止发布，不能静默删图或自动下载补齐。
|
||||
原模板包不得直接把示例结论保留为实例结果；签署区域只映射真实审签元数据，不生成手写签名。
|
||||
提交快照冻结真实模板 binding、内容块/章节版本、依据和渲染器版本；导出明确选择草稿或某一批准快照，不能读取各章当前最新版拼装。
|
||||
批准 Word 首次生成后，字节、完整 hash、固定输入与精确批准快照持久关联，随批准历史保留；现有短期导出工件的 24 小时寿命不能作为该文件的保留策略。
|
||||
采用 RDM 自有的受控导出产物仓储，复用现有文件/hash 完整性机制，下载权限使用 `doc_export_visibility.go` 的受控正文授权，区分短期导出和批准历史文件；下载链接可短期失效，批准文件不能因此删除。
|
||||
批准后排队生成并保存该交付物，生成失败不回滚已批准的文档状态，文件状态保持待生成或失败；固定输入的幂等重试保存完整文件及关联后才可声明文件就绪。
|
||||
同一快照再次取得文件返回原批准字节；首次生成或获准重建只能使用可执行的固定渲染版本，相关模板包/槽位映射缺失、原件 hash 不符或旧渲染路径不可执行时明确阻塞，禁止自动改用新版渲染器。
|
||||
软件升级和例行清理必须保全批准文件及关联；结构化内容仍是业务权威，存档 Word 是对应快照的固定交付物。
|
||||
现有仅含字典版本的历史快照不补造模板身份；继续按旧导出路径提供并标明历史格式，不能宣称新 DHF 保真。
|
||||
|
||||
KTD6. RDM 持有领域模板与生成/导出逻辑，Frontend 持有正式用户界面。
|
||||
对话、工具及工作区消费同一服务端对象和状态；修正错误 intent 参数，并公开合法的模板绑定和提案 schema。
|
||||
正式产品必须检验 Frontend 发布版本和 RDM pins 的组合；仅修改 RDM `web/app.js` 不算正式产品交付。
|
||||
按 Dev DESIGN 复用三栏、卡片与唯一文件预览，界面消费令牌和已有原语；文档纸面保留原件自己的字体和颜色。
|
||||
预览明确区分页式视图、版式降级的内容视图和无法读取；页式渲染失败时显示“版式预览不可用，当前仅展示内容”，保留同一 Word 文件的下载入口供核对，不把内容视图当作格式验收。
|
||||
仅当已批准路径无法由公开扩展点实现时，向基座提交四要素扩展申请；禁止改 RDM pins 或导入 Backend internal。
|
||||
|
||||
### High-Level Technical Design
|
||||
|
||||
以下图示规定权威和流向；具体类型名、函数及路径由实施时确定。
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
O[44份只读原件] --> N[DOC规范化与差异核对]
|
||||
N --> T[固定模板包: 原件/结构/槽位]
|
||||
T --> I[可信项目与按模板实例化]
|
||||
K[授权知识与原文版本] --> G[逐块生成和校验]
|
||||
I --> G
|
||||
G --> P[持久提案和差异]
|
||||
P --> A[编制人采纳: 事务/CAS]
|
||||
A --> S[整文提交/审核/批准快照]
|
||||
T --> E[固定模板填充导出]
|
||||
S --> E
|
||||
E --> F[同一文件预览和下载]
|
||||
```
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> Imported
|
||||
Imported --> NeedsReview: 结构/语义/版式待确认
|
||||
NeedsReview --> Published: 资产评审通过
|
||||
NeedsReview --> Blocked: 关键丢失或用途不明
|
||||
Blocked --> NeedsReview: 有依据的修正
|
||||
Published --> Retired: 受控退役
|
||||
```
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
actor A as 编制人
|
||||
participant C as 对话/工具
|
||||
participant R as RDM领域服务
|
||||
participant D as 事务与事件库
|
||||
participant E as Word导出
|
||||
A->>C: 指定项目/目标/模板
|
||||
C->>R: 可信主体与明确绑定
|
||||
R->>D: 实例化及生成输入快照
|
||||
R-->>A: 候选、差异、缺项与来源
|
||||
A->>R: 采纳固定提案
|
||||
R->>D: 权限/版本复验，原子提交
|
||||
Note over R,D: 三权审签后冻结整文及真实模板
|
||||
A->>R: 导出指定批准快照
|
||||
R->>E: 固定内容与模板包
|
||||
E-->>A: 经授权的文件预览/下载
|
||||
```
|
||||
|
||||
### Dependencies and Open Questions
|
||||
|
||||
实施启动阻塞项：本轮范围与取舍评审、在途两树任务契约 owner、44 份逐项阶段/type/用途映射、E1 授权与 DOC 保真结果、原件内容分类及导出槽位合同。
|
||||
特别是 F02《验证确认报告》虽位于设计验证目录，正文是过程 IQ/OQ/PQ 确认，须由业务负责人裁定用途，不按目录自动映射。
|
||||
导出关键版式以 R2 为底线；允许的字体替代和跨 Office 分页差异在 E1/样例评审中逐项确认，不承诺像素一致。
|
||||
源模板中的企业信息、示例产品名和标识需人工分类为企业固定项或项目替换项；无人确认时保持待发布。
|
||||
具体 helper 名称、序列化细节和测试夹具目录由实施者确定；不得用这些细节延后上述业务裁定。
|
||||
|
||||
---
|
||||
|
||||
## Implementation Units
|
||||
|
||||
以下 U-ID 只属于本专项；均为待批准工作，不代表 E1 或任何业务实施已启动。
|
||||
|
||||
### U1. Asset Contract and Conversion Proof
|
||||
|
||||
覆盖 R1–R4；先与 TT-T/TT-D 的 owner 固定共享契约与台账。
|
||||
Files：RDM `internal/rdmapp/templates/`、`templates.go`、`templates_embed.go`；新增 `docs/records/dhf/` 台账及 `template_asset_contract_test.go`（拟定）；Dev 原件保持只读。
|
||||
产物为 44 份完整谱系、用途/适用性映射、内容分类、保真差异台账和已评审结构/槽位规范。
|
||||
先用项目建议书 DOCX 完成内容模型；设计输入规格书及 F02 报告校验多级结构与示例语义，复用 E1 覆盖全部 DOC。
|
||||
验证场景：损坏/加密/不支持对象拒绝发布；重复 hash 不吞用途；混合标题/编号正确；黑字假结论不能成为项目结果；每个 DOC 关键差异有判定；外链图片处置后内嵌图完整且导出无自动外部内容读取。
|
||||
出口：44 份处置明确，全部 14 DOC 方法可核验；未通过资产保持阻塞，不能进入全量发布。
|
||||
|
||||
### U2. Published Template Binding and Instantiation
|
||||
|
||||
依赖 U1 共享契约；覆盖 R1/R4/R5/R8。
|
||||
Files：RDM `templates.go`、`structure.go`、`internal/domain/doctree.go`、`payloads.go`、`replay.go`、`plugins/rdm/plugin.go`；新增 `dhf_template_instance_test.go`（拟定）。
|
||||
增加发布模板包与明确默认用途，原子创建文档/块/真实模板 binding；内容块复用 TT-D，不按标题去重代替身份。
|
||||
验证场景：v2/v10 选择、周报与建议书同 docType、缺包/hash 错误、退役、重复创建、跨项目、更名同名章、失败回滚及重启重放；模板升级不会覆盖旧实例。
|
||||
出口：无 Dev 源码目录的构建制品可实例化试点模板；新对象与历史对象有明确兼容路径。
|
||||
|
||||
### U3. Evidence-Based Generation and Confirmed Adoption
|
||||
|
||||
依赖 U2；覆盖 R3/R6–R8。
|
||||
Files：RDM `compose.go`、`draft.go`、`draftproposal.go`、`plugins/rdm/plugin.go`；扩展 `compose_test.go`、`draftproposal_test.go`、`plugins/rdm/intents_test.go`。
|
||||
修正 intent 和总线 schema；按块要求组织有权依据，结构化生成并校验，复用持久提案/事务采纳；同时落实 Compose 的指定编制人门禁。
|
||||
验证场景：真实自然语言请求从正确模板到提案；无资料、示例黑字、适用条件冲突均诚实留缺；未分配职责、非编制人和私人未发布资料拒绝；并发采纳、重复点击、取消、断连/恢复及撤权结果可查且不重复生效。
|
||||
出口：项目建议书有固定来源的完整候选和内部版本；无证据的测试/验证字段仍空缺或注明未执行。
|
||||
|
||||
### U4. Approved Snapshot and Word Fidelity
|
||||
|
||||
依赖 U2/U3；覆盖 R2/R3/R5/R8/R9。
|
||||
Files：RDM `docsubmission.go`、`docx.go`、`doc_export_visibility.go`、`export_artifact.go`、领域快照 payload/replay；扩展 `docx_test.go`、`plugins/rdm/doc_submission_test.go`；新增 `dhf_docx_fidelity_test.go`（拟定）。
|
||||
冻结真实模板及渲染版本，补整文快照选择；实现原 OOXML 槽位填充、重复行和附件映射及批准 Word 持久关联，旧导出语义独立兼容。
|
||||
验证场景：审核中改正文被拒、提交后模板更新/退役、批准后当前章变化、历史批准轮次重导出、槽位重复/缺失、长表格跨页、合并关系、编号、图片、页眉页脚、中文字体、非法 XML；无真实签署不填意见；下载撤权立即拒绝。
|
||||
跨版本验收：旧版批准/导出→超过短期工件 TTL→升级并更换渲染实现→取得同一轮次 Word，字节 hash 与原批准文件一致；下载仍按当前权限判断。原批准文件损坏或丢失且固定渲染版本不可执行时明确阻塞，不生成外观相近的新文件冒充历史产物。
|
||||
故障验收：生成失败不改变审批结论；写文件与关联记录部分失败不发布就绪文件，重启后可查并幂等恢复；文件下载采用正文职责权限，普通审计权不扩大文件读取范围。
|
||||
出口：三用户完成试点审签，Word 内容/依据与批准快照相同，关键版式对照通过；ZIP 非空或可打开仅为辅助检查。
|
||||
|
||||
### U5. Formal Product Path and Offline Package
|
||||
|
||||
依赖 U3/U4；覆盖 R6/R7/R9。
|
||||
Files：RDM `scripts/build-product.sh`、`scripts/pack-release.sh`、`templates_embed.go`、`templates_embed_test.go`；Frontend `src/previewsetup.ts`、真实对话卡片/文件预览/API 与相关浏览器用例（其余路径实施前按当前发布版定位）。
|
||||
统一包内模板路径、读取路径和 hash 校验；对话与辅助工作区复用同一任务/提案/快照，交付正式 Frontend 版本后由 RDM 正常消费。
|
||||
验证场景：真实 auth-on 两项目三用户，关闭右栏完成编制，刷新/重启/撤权/旧卡片；脱离源码运行同一制品，资产缺失/摘要错误拒绝；原模板字体/颜色在预览保留；页式渲染失败明确降级，完全无法读取显示错误及下载入口；证明浏览器使用精确 Frontend SHA。
|
||||
出口：项目建议书在正式产品完成全流程，固定组合 CI 与独立重放齐备；静态工作台或桩测试不能替代。
|
||||
|
||||
### U6. Complete All DHF Families
|
||||
|
||||
依赖 U1–U5 试点通过；覆盖 R1–R9。
|
||||
Files：RDM 模板包、registry、映射台账及每文档族的内容/Word 回归样例，复用 U1 的唯一资产台账。
|
||||
顺序为策划/输入→输出→验证/确认→商务/转换及剩余评审；DOC 规范化与 DOCX 内容整理可在同一契约下并行，发布仍逐批评审。
|
||||
每份模板至少运行一个有材料的完整样例和一个缺证据/冲突样例；报告类只使用实际提供的验证记录，不能生成执行记录。
|
||||
出口：44 份逐资产结果齐全，声明可用者通过真实生成/采纳/审签/导出；未解决项显式保留，本目标不能标全量完成。
|
||||
|
||||
---
|
||||
|
||||
## Verification Contract
|
||||
|
||||
验证在后续批准的阶段执行；本轮只能做原件/源码阅读和文档一致性检查。
|
||||
实施期先补关键链路的行为测试，再扩展原有实现；正式验收遵循 Dev evidence、精确组件 SHA、CI GATE 与独立 REPLAY 门禁。
|
||||
|
||||
| 证据层 | 对象与方法 | 硬判据 |
|
||||
|---|---|---|
|
||||
| 资产 | 44 份路径、原件/派生/结构/渲染 hash、DOC 差异和业务分类 | 44/44 可追溯；原件不变；关键结构/语义/格式无静默丢失 |
|
||||
| 领域 | RDM 模板/实例/提案/审签/事件重放测试 | 固定绑定、CAS/幂等、失败全回滚、历史再现，负向越权为零 |
|
||||
| 真实总线 | 意图→schema→认证主体→实例化/生成/采纳/导出 | 用合法 docType/templateRef；工具暴露参数和处理器一致 |
|
||||
| 模型行为 | 固定真实素材、原件和任务，人工审核正文与引用 | 不编造事实、样本量、执行记录、结论或签署；缺项明确 |
|
||||
| Word | OOXML 核对＋真实 Office/LibreOffice 打开＋人工原件对照＋升级后历史文件重取 | 内容/表格/合并/编号/图片/页眉页脚/关键样式与固定快照一致；批准历史文件不受短期 TTL 清理 |
|
||||
| 正式浏览器 | 真实 auth-on 三用户两项目、对话/卡片/预览/下载、重启/撤权 | 完整用户流程，文件可读可下载，职责/私域隔离有效 |
|
||||
| 安装制品 | 固定 RDM/Frontend/Backend pins 与模板包，源码外运行 | 无 cwd 依赖；读/打包路径同值；错包拒绝，不回退到骨架 |
|
||||
|
||||
RDM 的现有 `make test`、product build、模板/提案/审签测试用于回归；Frontend 使用相关浏览器测试；Dev 有 gitlink 改动时执行组合 `make test` 和 `make build`。
|
||||
正式以各 PR 当前 HEAD 的必需 CI 为准；原件盘点 SELF、模型自评和历史绿色 CI不能代替当前验收。
|
||||
生成耗时、费用和人工修订量先建立试点基线，再确认目标；本轮不编造工期或质量评分。
|
||||
|
||||
## Definition of Done
|
||||
|
||||
规划交付：范围、源码基线、44 资产特点、技术决策、依赖、工作包、验证和阻塞项可审查；未批准及未执行阶段明确。
|
||||
试点交付：真实 DHF 项目建议书在正式产品，经三用户完成生成/采纳/审签/按快照 Word 导出，精确组合证据齐备。
|
||||
全量交付：U6 达到 44 份逐资产验收，原两树任务的共同契约和台账同步；试点或 registry 数量不能替代。
|
||||
上线交付：另行确认实例、制品和迁移范围，按批准窗口部署并运行验收；本方案完成不等于上线。
|
||||
|
||||
## Appendix
|
||||
|
||||
主要源码：RDM `internal/rdmapp/templates.go`、`templates_gen.go`、`templates_embed.go`、`structure.go`、`parse.go`、`compose.go`、`draftproposal.go`、`docsubmission.go`、`docx.go`、`plugins/rdm/plugin.go`、`scripts/build-product.sh`。
|
||||
本轮资产证据索引：[44 份原件的路径/hash/结构特征及源文件摘要](../records/2026-10-14-dhf-assets.json)；完整命令输出以 Dev 任务卡 evidence 为准。
|
||||
上游来源：[原模板生成方案](2026-10-11-rdm-template-dialog-generation.md)、[最终目标方案](2026-10-11-rdm-final-target-completion.md)、[两树一网方案](2026-10-11-rdm-two-trees-trace-audit-integration.md)及在途 `feature/rdm-two-trees-latest-templates` 阶段 1/2 记录；旧“四模板”盘点只作历史。
|
||||
登录收官来源：Dev `docs/svc-deploy/2026-10-13-login-recovery-contract.md` 的最后一项为“完成”，PR #516 已合入；owner 于 2026-10-13 自行在浏览器确认通过，密码不经 Agent。本轮不重做该验收。
|
||||
@@ -0,0 +1,113 @@
|
||||
# Dev main 第二轮 manual 合入调度实施与测试计划
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** 让第二轮三个已授权真实任务在同一人工窗口中按序完成最终同步、审核、CI 与智能体合入，同时把所有已知 Dev main 写入及失败退出记录在唯一调度 Issue；正常排队推进不使等待分支反复重跑最终 CI。
|
||||
|
||||
**Architecture:** 保留现有 Gitea 分支保护、三项 PR 检查和 `task-sync`；Dev `policy/` 仅说明项目采纳、写者覆盖、记录字段及停止条件。Issue #518 是动态窗口唯一来源，原任务卡保留授权与阶段结论。只读对账从实际 main PR/合入列表反查 #518 的先前领取与事后释放；无原子锁、无自动调度服务。
|
||||
|
||||
**Tech Stack:** Git/Gitea 1.27 API、Dev `make precheck`/`make evidence`/`make task-sync`、Markdown 规范与 JSON 收据、现有 `.gitea/workflows/ci.yaml`。
|
||||
|
||||
**Spec:** [已批准的阶段 4 设计](2026-10-14-merge-queue-manual-phase2.md)，Documents PR #104（合入 `8e3b5b0d2838f89430683ec731a15b32b4fa5eae`）；[首轮报告](../records/2026-10-14-merge-queue-trial.md)与 Dev #518 是历史与动态证据，不能以本计划代替实时回读。
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- 范围仅为 Dev 仓库 ID=29、`refs/heads/main`；普通、闭卡、紧急和机器人目标写入都纳入同一记录。组件仓按自身目标协调。
|
||||
- 第二轮样本为**随后实际就绪的三个已授权真实任务**；闭卡单列。#482、#512、#537 不因本计划自动取得接管或合入授权。
|
||||
- 现有 Gitea 保护、必需检查、CI workflow 和 runner 全局配置保持不变；最终 PR HEAD 的 `test`、`test-pg`、`svc-realcombo` 均须取得真实 GATE。
|
||||
- 采用单一协调者维护的 `manual` 窗口。Issue 编辑、评论、`content_version` 和本地锁都不是平台原子互斥；旧执行者未确认退出时不得接管。
|
||||
- 无进展 20 分钟、单窗口 90 分钟、已知基础设施失败最多额外重试一次、队列每 30 分钟复核；领取前当场核对 runner 容量。
|
||||
- 阶段 5–7 依 `policy/delivery.md` 分别取得人工结论；阶段 8–9 由智能体审阅、核验精确 HEAD 与平台准入并合入。阶段 5 批准不等于第二轮已启用。
|
||||
- 所有通过断言区分 GATE、REPLAY、SELF；本地输出经 `make evidence` 写入，固定后收据置于源码外；未知结果先读回，不盲目重复副作用请求。
|
||||
|
||||
## Review Focus
|
||||
|
||||
1. **已知写者仍从另一入口推进 main：**任务 2 的对账应查到实际合入但缺先前领取，暂停新领取并标记受影响候选失效。
|
||||
2. **Issue 中只有事后补记：**任务 2 的对账应区分先前领取与事后释放；#539 不能被算作合格覆盖。
|
||||
3. **候选固定后内容或 base 变化：**任务 3 的核验应建立新尝试，并拒用旧 Review/CI；同基线重复 `task-sync` 应保持 HEAD 不变。
|
||||
4. **合入响应未知或协调者失联：**任务 3 应先回读 PR/main 并保持 `reconciling`，确认前执行者退出后才释放/交接。
|
||||
5. **没有三个已就绪任务：**任务 4 应保持 `waiting`，不接管 #482/#512 或制造生产 PR，不把缺样本写为通过。
|
||||
|
||||
| 设计验收 | 计划中的主要验证 |
|
||||
|---|---|
|
||||
| M2-1 | 任务 2 入队字段、任务 4 三个真实任务与等待期间最终 CI 清单 |
|
||||
| M2-2 | 任务 2 的逐合入只读对账、任务 4 每次 main 推进后的覆盖核对 |
|
||||
| M2-3 | 任务 3 的同基线无变更与变更后新尝试重放 |
|
||||
| M2-4 | 任务 3 的精确 HEAD 三项 GATE/智能体合入、任务 4 的每任务对象记录 |
|
||||
| M2-5 | 任务 4 对正常排队造成的最终 CI 废弃数和所有 CI 成本分类 |
|
||||
| M2-6 | 任务 2/3 的异常决策表与任务 4 的自然退出/`NOT_RUN` 记录 |
|
||||
|
||||
---
|
||||
|
||||
### Task 1: 固定实施范围与 Dev 规范入口（M2-1、M2-3）
|
||||
|
||||
**Files:**
|
||||
- Modify: Dev `policy/merge-queue.md` 的状态、项目调度记录、启动与同步、采纳顺序及验收表。
|
||||
- Modify: Dev `policy/adoption.md` 中合入调度采纳行。
|
||||
- Modify: Dev `policy/tool-adaptation-matrix.md` 的 A10/A11 行。
|
||||
- Read only: Dev `AGENTS.md`、`policy/delivery.md`、`policy/governance.md`、Guidelines 固定版 `standards/merge-queue.md`。
|
||||
|
||||
**Interfaces:** 仅细化已固定通用规范，不改 `task-sync`、`make evidence` 或 CI 接口。规范链接指向 Documents 阶段 4 设计和 #518；`policy/adoption.md` 区分“规范已合入”“第二轮待启用”“manual 能力”；A10 说明 Issue 协作与平台准入的不同强度。
|
||||
|
||||
- [ ] 在 Dev 当前 main 创建未占用收据路径，运行下列启动门禁并确认 READY；按输出读必读规范。新任务用同一收据建独立工作区，记录 R0 与写者归属；若任务已登记则在原 worktree 改用 `make task-resume PRECHECK_RECEIPT="$mq_receipt"`，不重复开卡。BUSY、SYNC_REQUIRED、REMOTE_UNVERIFIED 先排除。
|
||||
|
||||
```bash
|
||||
mq_receipt="/tmp/mq-phase2-stage6-precheck-$(date -u +%Y%m%dT%H%M%SZ)-$$.json"
|
||||
RECEIPT="$mq_receipt" CMD='make precheck' make evidence
|
||||
make task-start NAME=feature/merge-queue-manual-phase2 PRECHECK_RECEIPT="$mq_receipt"
|
||||
```
|
||||
- [ ] 对照当前 Dev main、Guidelines gitlink、#518 与已合入设计。把 `policy/merge-queue.md` 首轮“本轮三个任务待完成”“本分支”等已过期时态改为历史结果，把第二轮规则明确标为 `approved/pending-activation`，并逐项写明 `ready_at`、`queue_entered_at`、`attempt_id`、`initial_base_sha`、`source_head_sha`、`sync_base_sha`、`frozen_head_sha`、组件/检查定义、Review 与 GATE、实际合入/释放。动态值只在 #518，不复制静态队列表。
|
||||
- [ ] 在 `policy/adoption.md` 与 A10/A11 中指向同一设计及项目规则：保留首轮原始证据范围；第二轮标 `manual`、`pending-activation`，不可升级成 `enforced` 或声称自动互斥；现有源码外收据能力保持原样。
|
||||
- [ ] 检查 `AGENTS.md` 与 `policy/delivery.md` 对合入窗口及阶段 7–9 的指向。若现有入口已覆盖，只记录无需修改；若确有入口断链，按文档范围补链接并将变化列入 Review。
|
||||
- [ ] 运行 `git diff --check`、Markdown 相对链接检查和规则一致性检查：阶段 5 批准后尚未启用、缺写者覆盖时必须保持 waiting、三个必需检查没有删减。若动到治理脚本或任务卡模板，另运行 `CMD='make test-governance' make evidence`；纯文档不制造新脚本测试。
|
||||
- [ ] 将本单元源码与 SELF 检查收据写入原任务卡并提交；阶段 6 人工评审前不把 #518 标为第二轮 active。
|
||||
|
||||
### Task 2: 建立 #518 入队模板与只读覆盖对账（M2-1、M2-2、M2-6）
|
||||
|
||||
**Files:**
|
||||
- Modify: Dev `policy/merge-queue.md` 的记录示例、写者覆盖、异常与暂停规则。
|
||||
- Prepare then update after Stage 6 approval: Gitea Dev Issue #518 正文的第二轮入口与追加式评论模板；不建立第二份队列状态文件。
|
||||
- Save outside source: 每次只读 Gitea API 对账的原始脱敏 JSON/`make evidence` 收据；必要结论只引用对象和链接。
|
||||
|
||||
**Interfaces:** #518 条目至少包含 `entry_id`、目标、PR/任务卡、owner/协调者、授权与阶段版本、依赖、`queue_entered_at`、`ready_at`、状态；领取评论补 Task 1 的 attempt 字段；释放评论补实际 PR/main SHA、合入结果及 GATE 链接。`ready_at` 未知标 `NOT_MEASURED`，不足条件标 `blocked`。
|
||||
|
||||
- [ ] 只读查询 Dev 当前 main SHA、开放 PR、仓库协作者、可写工作区 owner、机器人/webhook/workflow 入口、#518 正文与评论，生成带观察时间和对象 SHA 的 SELF 清单；无法查到的写者类别标“未核验”，不推断不存在。
|
||||
- [ ] 在 Task 1 规范中给出普通、闭卡、紧急、机器人共同的入队/领取/释放字段，规定 `blocked` 不占窗口；跨仓组件未就绪不占 Dev 窗口。未知来源与旧执行者未退出必须暂停或 `reconciling`，不得靠 20 分钟超时接管。
|
||||
- [ ] 固定只读对账步骤：枚举观察区间内实际合入 Dev main 的 PR/merge SHA；逐个在 #518 找**合入前**同目标同 attempt 的领取和**合入后**释放；同时反查 Issue 中仍占用但 PR 已关闭/合入的窗口。分列“合格、仅事后补记、未找到、结果不明”，保留 API 原始响应与分页范围。
|
||||
- [ ] 用 [阶段 4 SELF 快照](../records/2026-10-14-manual-phase2-source-audit.json) 回放对账口径：#539 属“仅事后补记”，#540/#542 能找到领取/释放，其余七个仅可记“在该次 #518 观察中未找到”；不得倒推出其他渠道绝无协调。源记录更新后另取实时快照，不用历史快照证明当前覆盖。
|
||||
- [ ] 将模板与覆盖清单先作为 Dev PR/任务卡可审附件；Stage 6 人工确认后才更新 #518 的**待启用**入口。写入前读回 `content_version` 与活动窗口，遇到别人更新先重算差异；请求结果未知先 GET 对账，不重复 PATCH/POST。
|
||||
- [ ] 当场向每位**已知目标写者**核实采用同一窗口的确认；未确认类别逐项留记录。没有全体已知写者覆盖，不转 active、不领取三个样本。人工确认不等于 Gitea 执行端隔离。
|
||||
|
||||
### Task 3: 用现有门禁交付 Dev 规则并验证异常边界（M2-3、M2-4）
|
||||
|
||||
**Files:**
|
||||
- Modify: Task 1/2 的 Dev 规则差异及原任务卡（仅在候选固定前）。
|
||||
- Save outside source: 最终 precheck、task-sync、直接相关检查、Review 和 CI 的原始收据及对象索引。
|
||||
|
||||
**Interfaces:** 复用 `make task-sync`、`make evidence`、Gitea PR/Actions 与现有分支保护；不新增自动队列或跳过 CI 的入口。
|
||||
|
||||
- [ ] 在阶段 6 人工通过后，正式测试前对 Dev 规则 PR 执行一次 `make task-sync`，处理真实冲突、确认组件不回退，先写完任务卡和需提交证据，再固定并推送 PR HEAD。若有脚本/模板改动跑 `make test-governance`，Dev 组合按变更影响跑 `make test`/`make build`，由 `make evidence` 保存完整 SELF 输出。
|
||||
- [ ] 在临时真实 Git 场景复核同 base/head 重复 `task-sync` 的 HEAD、索引和组件不变；目标前进或候选内容变时，新 attempt 的 base/head 与旧 CI/Review 不同，旧结果不能放行。若本增量未改同步脚本，引用现有治理回归并做最小重放，不重复整个历史试行。
|
||||
- [ ] 用只读或隔离模拟验证异常决策表：未登记 main 推进→暂停及候选失效；合入 API 超时/断连→`reconciling` 并先读 PR/main；代码/Review 失败→当前条目 blocked 并安全释放；未发生真实生产故障的路径只标模拟或 `NOT_RUN`。
|
||||
- [ ] 阶段 7 人工审阅固定候选与测试映射后，由智能体完成阶段 8 Review 与影响重放；阶段 9 合入前再次同步核对最新 base/head/组件及当次要求的 GATE 身份、SHA、三项结果。合入请求固定 `head_commit_id` 且 `force_merge=false`，回读 PR/main 树与合入 SHA。若候选改变，重新测试及受影响评审，不沿用旧绿灯。
|
||||
- [ ] 把实际阶段 6/7/8/9 结果及 GATE/REPLAY/SELF 来源写入原任务记录；规则 PR 合入并不自动启用第二轮任务窗口。
|
||||
|
||||
### Task 4: 第二轮启用、三任务试行与收口（M2-1–M2-6）
|
||||
|
||||
**Files:**
|
||||
- Update dynamically: Gitea Dev Issue #518 与每个**原任务**的任务卡/PR。
|
||||
- Create after actual observation: Documents `docs/records/<实际日期>-merge-queue-manual-phase2-trial.md`；与 #518 互链，不复制动态队列状态。
|
||||
- Update only after result review: Dev `policy/adoption.md`、`policy/tool-adaptation-matrix.md` 的实际能力和状态（若有变化）。
|
||||
|
||||
**Interfaces:** Task 2 的 #518 模板；每个任务原有人工阶段与接管授权；固定 PR HEAD 的三项 GATE；智能体合入入口。此任务不承担其他任务业务代码实现。
|
||||
|
||||
- [ ] 在规则 PR 合入、#518 模板已登记、已知目标写者确认覆盖、无活动/未知窗口、runner 容量当场核验后，由负责人审阅启用条件与当前清单，再把第二轮从 `pending-activation` 切为 `manual active`。缺任何条件保持 `waiting`，继续独立局部开发。
|
||||
- [ ] 只让三个**实际就绪且已有自身实施/合入授权**的任务依 `queue_entered_at`/`ready_at` 顺序入队；协调者在领取前核对原卡阶段结论、PR head、依赖、组件与其他写者退出。#482/#512 只有重新满足这些条件才可参与，不能因本计划自动接管。
|
||||
- [ ] 每次领取后按 Task 3 固定并通过当前 HEAD 必需检查、Review 与人工阶段结论，智能体串行合入并释放；闭卡 PR 使用独立窗口，成本单列。每 30 分钟复查等待队列，记录 runner 等待与人的依赖/准备等待；时间缺失记 `NOT_MEASURED`。
|
||||
- [ ] 每次 main 实际推进后运行 Task 2 只读覆盖对账；发现未登记合入、并行窗口、对象不符、旧执行者未退出接管或来源伪造时立即暂停新领取，先核清受影响候选和写者。未知合入结果不重发 POST。已合入成果不自动回退。
|
||||
- [ ] 三项完成或触发停止条件时，按 M2-1–M2-6 列每个真实任务的最终 base/head、同步/新尝试原因、Review、GATE、合入树、开发/最终/main push/组件/闭卡 CI 次数与耗时、废弃原因；仅正常已登记顺序推进造成的最终 CI 废弃数作为目标指标。没有可比历史基线时不报告节省百分比，未发生的退出路径记 `NOT_RUN`。
|
||||
- [ ] 用户评审第二轮报告后决定继续 manual、调整预算、停止或另立自动准入；仅实际合入与经核验的能力可更新 Dev 采纳/矩阵。阶段 10 的安全回收按工作区 owner 和 `task-finish` 现场检查执行，任务闭合经有授权的 `task-close` 与智能体 PR 合入；保留所有原始收据。
|
||||
|
||||
## Stage 5 decision and stop rule
|
||||
|
||||
2026-10-14，负责人 weichen 在本任务会话中对 Documents 草稿 PR #105 的计划稿 `28c4ceb17315e1bb06f8e39c8407eb525effb8fe` 回复“通过阶段 5”，并选择由当前智能体逐项实施。批准覆盖本计划的阶段 6 候选编制与自检，不替代阶段 6–7 的人工结论，也不等于 #518 第二轮 active。任何实施中发现原子互斥、角色隔离或执行端 fencing 被要求为通过条件，应停止扩围并回到阶段 4 重设计，不能靠文字提升 `manual` 能力。
|
||||
@@ -0,0 +1,74 @@
|
||||
# Dev main 合入调度第二轮 manual 扩围设计
|
||||
|
||||
状态：**阶段 4 方案设计与[阶段 5 实施计划](2026-10-14-merge-queue-manual-phase2-implementation-plan.md)均已通过；阶段 6 实施待评审**。2026-10-14，负责人 weichen 在本任务会话中对 Documents 草稿 PR #104 的规范稿 `aa4d372f01d0473928c570aa69c09ca771f2de45` 明确回复“通过阶段 4”，随后对 PR #105 的计划稿 `28c4ceb17315e1bb06f8e39c8407eb525effb8fe` 回复“通过阶段 5”，选择由当前智能体实施。这些批准不等于启用第二轮窗口或接管其他任务。执行协调者须在每个窗口明确登记。本文只设计 Dev 仓 `refs/heads/main` 的下一轮人工调度，不启用自动队列。
|
||||
|
||||
主记录：[Dev 调度 Issue #518](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/issues/518)；既有规则：[Development-Guidelines 固定版合入调度](https://git-home.u1680832.nyat.app:30319/weichen/Development-Guidelines/src/commit/2f5b19872be2a4597838a4131ad75d1be089ee5e/standards/merge-queue.md)、[Dev 项目细化](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/src/branch/main/policy/merge-queue.md)；首轮结果：[三任务试行报告](../records/2026-10-14-merge-queue-trial.md)。本稿为下一轮范围与验收设计；动态队列状态只维护在 #518，不复制第二份任务进度表。
|
||||
|
||||
## 1. 评审结论与问题
|
||||
|
||||
首轮 #489、#488、#486 在同一协调者下顺序合入，每个真实任务只有一次最终 PR CI，三项各自合入后的 main CI 另计；没有因首轮正常顺序合入废弃的最终 CI。首轮报告将 MQ1、MQ5–MQ7 的未覆盖部分及自动原子领取、旧执行者拒绝列为部分满足或 `NOT_RUN`，不得据此宣布全仓自动约束已就位。
|
||||
|
||||
2026-10-14 22:13（Asia/Shanghai）对 #518 当前正文/评论和 Dev PR #539–#548 的只读 API 对照（[SELF 观察快照](../records/2026-10-14-manual-phase2-source-audit.json)，原始本机文件 `/tmp/mq-manual-expansion-audit-20261014.json`）显示：这十个 PR 均已合入；[#540](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/540)、[#542](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/542) 有窗口领取与释放记录；#539 只有合入后的事实记录；其余七个在当前 #518 正文与所返回的评论中找不到对应 PR 的窗口记录。这是**记录覆盖缺口**，不等于断言这些合入未经其他人工协调。它使“所有 Dev main 写入者都受同一 manual 窗口控制”的结论无法成立。
|
||||
|
||||
[#537](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/537) 曾取得旧候选绿色 GATE，但 Stage 8 审阅判为 `NOT READY`，窗口释放，后由用户取消且 PR 未合入；该例证明 CI 与人工阶段结论须分别核验。[#542](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/542) 的归档文字变化使旧候选作废，run 3100 不能放行新 head，run 3107 才属于实际合入对象。两者是应保留的正常失败/恢复事实，不计为“因正常排队 main 移动而浪费的 CI”。
|
||||
|
||||
目前 Dev 开放 PR 只有 #482 与 #512：#482 非草稿但落后 main、平台回读不可合入；#512 为草稿。两者的既有绿色状态均属于旧对象，且未取得本轮写者接管确认。因此**当前没有可直接领取的第二轮任务**，不得为凑满数量生成生产 PR、自动同步它们或把队列扩围理解为接管授权。
|
||||
|
||||
平台当前只读回读（SELF）：Dev `main` 禁直推/强推，拒绝落后分支，要求三个 PR 检查上下文 `ci / test`、`ci / test-pg`、`ci / svc-realcombo`，管理员不可绕过合入。它仍不能区分共用账号下的人与智能体，也未把 #518 的窗口写入变成原子锁或执行端 fencing。本轮不变更保护、批准数、CI workflow 或 runner 全局设置。
|
||||
|
||||
## 2. 目标、范围与非目标
|
||||
|
||||
**目标：**在保留人工阶段评审和现有平台准入的前提下，将首轮单一协调者的经验扩展为可供多个已授权任务 owner 依次使用的 **manual** 窗口；在候选固定后减少因正常排队合入而造成的无效同步和完整 CI；准确统计没有节省的成本与退出案例。
|
||||
|
||||
**范围：**仅 Dev 仓库 ID=29、托管实例 `git-home.u1680832.nyat.app:30319` 的 `refs/heads/main`。普通 PR、任务卡闭合、紧急和机器人目标写入均须出现在同一调度记录；不同组件仓按各自目标协调。候选任务原卡仍是需求、授权、阶段和证据的主记录。第二轮以随后实际就绪的三个已授权真实任务为观察样本，闭卡 PR 单列成本与窗口，不充作三个业务任务。
|
||||
|
||||
**非目标：**自动优先级、合并列车、批量/预测合并、复制旧 CI 状态、降低必需检查、调整分支保护、发布/部署、代替其他任务 owner 编写业务代码。#482、#512 和已取消的 #537 不因本设计自动变为就绪或重新授权。
|
||||
|
||||
取舍：立即把所有 PR 宣称为受控 manual，管理成本最低，却与七条找不到 #518 窗口记录的实际合入不符；只点名三个任务而放任其他 main 写入，不能解决等待者因外部推进失效的问题；直接建设自动队列需要真实原子领取和执行端旧代次拒绝，超出用户选择的 manual 范围。本设计选择先确认已知写者覆盖与记录完整性，再接收三个真实就绪任务；覆盖不足时诚实标记并暂停，保留以后另立自动机制的边界。
|
||||
|
||||
## 3. 第二轮 manual 协议
|
||||
|
||||
### 3.1 入队与覆盖
|
||||
|
||||
任务 owner 在最终同步之前登记目标仓库/分支、任务卡与 PR、授权范围及阶段结论、源 HEAD、依赖/组件、现有写者和预计最小重放集。`ready_at` 只在依赖已落主干、必要人工结论与写者排他确认均齐备时记录。尚缺任一条件的条目标 `blocked`，可以继续自己的局部开发，不领取窗口；入队不要求提前合入不断移动的 main。组件仓未交付时不占 Dev 窗口，也不持有一个目标窗口等待另一个目标。
|
||||
|
||||
第二轮启用前，协调者核对当时的开放 PR、可推进 main 的工作区 owner、仓库协作者、机器人/webhook 和 workflow 入口，并取得**已知目标写者**采用同一窗口的确认。普通、闭卡、紧急及机器人合入均须走 #518；仍有未接入写者时如实登记其范围，不能声明全写者覆盖，也不能保证等待任务免于外部 main 移动。
|
||||
|
||||
协调者按就绪时间与已批准的紧急理由安排顺序，领取前读回 #518、实际 Dev main/PR、分支保护和 runner 资源。#518 的当前窗口字段只写一个目标尝试；评论保留追加式时间线。领取后再读回核对，无匹配或发现另一执行者时停止。Issue 的 `content_version`、本地锁和评论均**不等于平台原子互斥**；本模式依靠明确写者遵约和受保护分支的最终准入。协调者换手时须确认前执行者退出及未知合入结果，不能凭 20 分钟超时自动接管。
|
||||
|
||||
### 3.2 固定、检查与合入
|
||||
|
||||
一个窗口以 `attempt_id` 标识：`target`, `owner/coordinator`, `claimed_at`, `last_progress_at`, `initial_base_sha`, `source_head_sha`, `sync_base_sha`, `frozen_head_sha`, 组件清单、检查定义、Review 对象、GATE 运行与真实结果。新增 `ready_at` 与 `queue_entered_at`，使任务等待时间和 runner 等待时间分开计算；时间未知时记 `NOT_MEASURED`，不倒推填造。
|
||||
|
||||
窗口领取后执行一次真实 `task-sync`，处置冲突、物化已合入组件并完成应提交的任务卡/收据；此时才固定父仓候选。目标未变的验收、Review、合入节点只做同基线核验，不生成记录提交或重复完整 CI。最终 CI 仍由现行 workflow 在**固定 PR HEAD**上运行 `test`、`test-pg`、`svc-realcombo`；独立 Review、人工阶段结论与 CI 分别审查。合入前再次核对最新 base/head、组件、保护和三个 GATE 作业身份与结果；智能体使用固定 `head_commit_id`、`force_merge=false` 经 PR 合入，回读实际 main 树、合入 SHA、组件和后续 main push CI。
|
||||
|
||||
源 HEAD、目标 base、组件、检查定义或相关环境改变时建立新尝试，并按影响补测/复审。旧结果保留其对象范围；不为减少 CI 次数制造绿色状态。开发期 CI、最终 PR CI、合入后 main CI、组件 CI 和闭卡 CI 分开统计。
|
||||
|
||||
### 3.3 失效、异常与未登记推进
|
||||
|
||||
发现 #518 未登记的 main 推进时，协调者先读回目标、PR、运行和活动窗口；将受影响的固定候选标失效，记录缺口来源与对象，暂停本轮新领取，待写者覆盖和影响范围核清后恢复。不得把“记录中没有”推断为平台阻断已生效。代码或 Review 失败、依赖不满足、需要人工决定超时：保存现场与原始证据，受影响条目 `blocked` 并安全释放；其它目标和局部开发继续。合入请求超时、断连或结果不明：保持目标 `reconciling`，查询 PR/main 真实状态；未确认旧执行者退出前不重发有副作用的请求，也不移交窗口。
|
||||
|
||||
预算沿用首轮：无进展 20 分钟、单窗口 90 分钟、已知基础设施失败最多额外重试一次、等待队列每 30 分钟复核一次。领取前重新核对当时 runner 容量，不把首轮的 capacity=12 当作永久事实；资源不足先等待，不在窗口中空占名额。预算变化必须在实际成本复盘后另行评审。
|
||||
|
||||
## 4. 验收、观察和停止条件
|
||||
|
||||
| ID | 可判定条件 | 证据与边界 |
|
||||
|---|---|---|
|
||||
| M2-1 | 第二轮的三个真实任务均有原卡授权、阶段结论、owner 确认和先行组件；等待期间不为追 main 重跑最终 CI | 每任务原 R0、入队/就绪/领取时间、固定 base/head、源外收据；缺任务时保持等待，不制造 PR |
|
||||
| M2-2 | 每次 Dev main 实际合入在 #518 可找到同对象的先前领取和事后释放；闭卡、紧急、机器人同样登记 | 以实际 main merge/PR 列表对照 Issue 正文/时间线；遗漏即覆盖失败，不能声称“全写者受控” |
|
||||
| M2-3 | 稳定候选同基线重复 `task-sync` 不改 HEAD；对象变化拒用旧 Review/CI | 独立重放及精确运行 SHA；本轮记录每次新尝试原因 |
|
||||
| M2-4 | 三个真实任务各自取得当前 HEAD 三项必需 GATE 后由智能体合入，实际树与候选一致 | PR/run/job/actor/runner 链接及合入后 main 回读；平台仍是最终准入 |
|
||||
| M2-5 | 正常已登记任务顺序合入造成的最终 CI 废弃数为 0；候选整改、外部推进和基础设施失败另计 | 完整列出开发、最终、main push、组件、闭卡运行次数/耗时与废弃原因；无可比基线不报告节省百分比 |
|
||||
| M2-6 | 自然发生的 blocked/withdrawn/reconciling 均如实记录并安全处理；某类未发生则标 `NOT_RUN` | 不制造生产故障凑数；#537 历史可作设计参考，不冒充第二轮执行 |
|
||||
|
||||
若有未登记 main 合入、并行窗口、对象不匹配仍合入、伪造来源、旧执行者未退出即接管，立即暂停扩围并先对账；这是试行停止条件，不自动回退已经合入的成果。三个条目及闭卡均核验后形成第二轮报告，人工评审是否保持 manual、调整预算或另立自动准入项目。本轮即使全部满足，也只证明声明范围内的**人工协作**；自动锁、所有角色的执行端隔离和旧代次 fencing 继续 `NOT_RUN`。
|
||||
|
||||
## 5. 采纳顺序与阶段 4 决定
|
||||
|
||||
1. 阶段 4 已由用户按规范稿 `aa4d372` 批准；智能体完成本设计的 Review 与 Documents PR 合入。阶段 5 计划获批前不改 Dev 规则/Issue 状态，不领取新任务。
|
||||
2. 另编实施/测试计划：对账 `policy/merge-queue.md`、`policy/adoption.md`、`policy/tool-adaptation-matrix.md` 的首轮历史快照与当前动态入口，确定 #518 第二轮条目模板和只读合入覆盖核对方法；有脚本变更时运行 `make test-governance`。规范源码、项目采纳及 Issue 记录分别标阶段，不把计划写入视作已启用。
|
||||
3. 经计划阶段评审后，按 Dev 首次 precheck、独立工作区、Review、当前 HEAD CI 与智能体 PR 合入流程交付必要规范更新。高后果保护变更若将来必要，仍由用户亲手执行，本设计不要求该动作。
|
||||
4. 各真实任务 owner 在自己的授权与阶段下自愿入队；协调者确认全写者覆盖、同目标唯一窗口和资源，再领取。当前 #482/#512 不满足这一步。
|
||||
5. 第二轮达到三个真实任务或触发停止条件后，按本设计 M2 指标复盘；由用户作继续、调整或回退的阶段决定。
|
||||
|
||||
**阶段 4 决定：**用户已批准以“先补全 Dev main 合入记录覆盖、后接收三个真实就绪任务”的受控扩围作为第二轮设计，遗漏目标推进立即暂停、现有预算不变、闭卡单列成本，当前无就绪任务时保持 `waiting`。这一决定只批准设计；#518 与仓库规则的第二轮启用仍受阶段 5–7 评审及实际写者覆盖核验约束。
|
||||
@@ -0,0 +1,80 @@
|
||||
# svc 插件组合部署（--with）方案 r1
|
||||
|
||||
状态：**待评审**。日期：2026-10-14。负责人：weichen。
|
||||
任务卡：Dev `.task/feature-svc-plugin-compose.md`。
|
||||
需求来源：部署时用交互或参数选择把哪些插件与基座编译成同一个二进制服务，并在服务中激活这些插件。
|
||||
|
||||
## 1. 范围
|
||||
|
||||
做：
|
||||
|
||||
- 每次 `svc.sh` 的 agent deploy 可以选择零个或多个已登记插件。
|
||||
- 被选中的插件与 `--from` 指定的 Dev 基座编译成一个仍名为 `agent-system` 的二进制。
|
||||
- 部署后校验这些插件已注册且命令面处于启用；失败走现有 release 回退。
|
||||
- 插件清单来自 Dev 仓 `plugins/registry.json`，不自动发现。
|
||||
|
||||
不做：
|
||||
|
||||
- 不做 sidecar，不把插件部署成独立服务。
|
||||
- 不让插件自带基座 pin。基座就是本次 `--from` 的 Dev 提交；对不上就构建失败并报原因。
|
||||
- 第一版最多一个带静态工作台（`web`）的插件。
|
||||
- 不删除旧的 `--from rdm`。它仍用 RDM 仓自己的 `pins/` 构建，与 `--with` 互斥。
|
||||
|
||||
## 2. 步骤 0 试验结论（不留代码）
|
||||
|
||||
2026-10-14 在 `/tmp/svc-compose-spike` 复制当前 Dev 的 backend 模块，空白导入
|
||||
`agent-system-rdm/plugins/rdm`（指向 `~/.cache/agent-system-svc/rdm-src`），
|
||||
`go mod edit -require/-replace` 后执行 `CGO_ENABLED=0 go build -mod=mod`。
|
||||
|
||||
- 构建成功。产物约 40MB，`version` 仍是基座的 `agent-system 0.1.0-dev`。
|
||||
- `go version -m` 显示主模块 `agent-system-backend`，依赖 `agent-system-rdm v0.0.0`。
|
||||
- 二进制内可见 `rdm.project.create` 与 `rdm.ping`。
|
||||
- 聚焦依赖（`golang.org/x/*`、`github.com/jackc/*`、`modernc.org/sqlite`、`gopkg.in/yaml`）版本无变化。
|
||||
- 新增模块只有 `agent-system-rdm`、`github.com/kr/text`、`github.com/rogpeppe/go-internal`。
|
||||
- 默认 `-mod=readonly` 会拒绝更新 `go.mod`/`go.sum`，组合构建必须使用 `-mod=mod`。
|
||||
- 依赖模块自己的 `replace` 不生效，插件按主模块（Dev 基座）解析 `agent-system-backend`。这正是“基座以 Dev 提交为准”所要的结果。
|
||||
|
||||
试验目录是一次性的，不进入任何仓库。
|
||||
|
||||
## 3. 行为
|
||||
|
||||
### 3.1 选择
|
||||
|
||||
- `--with rdm,foo` 选择插件；`--with rdm@<sha>` 钉住单个插件提交；`--with none` 明确不带插件。
|
||||
- 标准输入是终端且没有 `--with` 时，按登记表给出编号勾选。默认勾选上次 `svc.env` 的 `plugins=`；第一次默认不选。回车接受默认，`none` 清空。
|
||||
- 非交互且没有 `--with`：沿用上次选择，没有则不带插件。已有脚本和 CI 的行为不变。
|
||||
- `--dry-run` 打印基座提交和每个插件的提交，不构建。
|
||||
- `--from rdm` 与 `--with`（除 `none`）互斥。`--from release` 不能再注入插件。
|
||||
|
||||
### 3.2 构建
|
||||
|
||||
1. 物化 Dev 提交的隔离 worktree，并完成前端构建，使嵌入资源就绪。`--from local` 不改主检出的 `go.mod`：把 backend 模块复制到 `runtime/.worktrees/` 再构建。
|
||||
2. 每个插件使用独立源仓缓存（`~/.cache/agent-system-svc/plugin-<id>`，`repoEnv` 可覆盖克隆地址）并物化 worktree。
|
||||
3. 在这份一次性 backend 副本里生成 `cmd/agent-system/zz_plugins_gen.go`（空白导入 `entryPackage`），并用 `go mod edit` 增加 `require` 与 `replace`。
|
||||
4. `go build -mod=mod` 产出 `agent-system`。基座的 `version`、身份和 `user` 等子命令保持不变。
|
||||
5. 测试可设 `SVC_COMPOSE_STUB=1`，跳过真实 `go build`，只记录插件选择。这不是生产路径。
|
||||
|
||||
### 3.3 激活与记录
|
||||
|
||||
- `GET /api/plugins` 与 `GET /api/registry` 的 `compiled` 列表必须包含每个所选插件。
|
||||
- `GET /api/commands` 中该插件 `commandPrefix` 下至少有一条 `enabled` 命令。
|
||||
- 插件在而命令全部禁用时，用与设置播种相同的临时管理员 key 调用 `POST /api/plugins/{id}/enabled`，再复查。失败则 `svc_rollback_deploy`。
|
||||
- `svc.env` 写 `plugins=id@sha,id@sha`。`source` 形如 `dev@<sha>+rdm@<sha>`。release 目录的 `release.json` 带同一 `plugins` 字段。
|
||||
- `update` 把基座升到远端最新，并原样带上已记录的 `--with`，不再询问。`recover` 只拉起已有二进制，不重新选择。
|
||||
- 插件 id 集合变化（含从无到有、从有到无）与源种类变化一样，需要 `--allow-source-switch`。只改提交不需要。
|
||||
|
||||
### 3.4 工作台
|
||||
|
||||
登记表里 `web` 非空的插件，沿用现有伴生 static 服务（`<name>web`）。多于一个带 `web` 的插件直接拒绝。
|
||||
|
||||
## 4. 跨仓
|
||||
|
||||
- Backend：`extension.InProc` 增加可选 `HostOptions` 与 `CLI`。布尔默认按“任一为 true”合并，不覆盖显式 serve 旗标。`GET /api/registry` 增加 `compiled`。
|
||||
- RDM：`plugins/rdm` 在 `InProc` 上声明 `HostOptions`（含关闭上传自动索引、会话卡镜像、执行原语）和 `-bootstrap-admin` 钩子。RDM 自己的 `main.go` 继续可用，旧 `--from rdm` 不依赖这次钩子。
|
||||
- Dev：`scripts/svc.sh`、`plugins/registry.json`、`docs/svc.md`、`help plugins`、`tests/test_svc_plugins.py`，并推进 backend 与 documents 的 gitlink。
|
||||
|
||||
## 5. 验收
|
||||
|
||||
- 登记、选择、换源门禁、dry-run、stub 部署与激活走 `tests/test_svc_plugins.py`。
|
||||
- Backend 的合并与 CLI 钩子走 `go test ./pkg/extension/`。
|
||||
- 真实 `go build` 组合（Dev 提交 + RDM 提交）在步骤 0 已证实可编译。带网络的完整 `svc deploy --with rdm` 与 `make test-lifecycle` 不在本增量的 stub 套件里，未在本机再跑时标 NOT_RUN。
|
||||
@@ -0,0 +1,108 @@
|
||||
# 分层 Python 环境方案 r1
|
||||
|
||||
状态：待评审（收录不是批准）。编制：2026-10-15。
|
||||
触发：dev 8788 会话 `cnv_7936c0a799ff` 中，智能体无法把已有 Markdown 摘要渲染成 docx，并向用户报告「没有 Python 对应的包」。
|
||||
|
||||
## 1. 已核实的故障（不是「缺包」本身）
|
||||
|
||||
8788 的 `run_python` / `run_shell` 跑在 bwrap 沙箱里（只读根、`--tmpfs /home`、`--unshare-net`）。同一台宿主机的 `~/.local` 里其实已经有 python-docx、lxml、openpyxl、python-pptx。失败来自四件事叠在一起：
|
||||
|
||||
1. **依赖层没有接线。** 代码已有 `--exec-deps-dir`（F3），但 `scripts/svc.sh` 与 8788 的启动参数都没有传入它。沙箱把 `/home` 遮掉之后，`~/.local` 不可见。
|
||||
2. **解释器解析到会被遮掉的路径。** 服务进程的 `PATH` 里 linuxbrew 在 `/usr/bin` 之前，`python3` 被解析成 `/home/linuxbrew/.linuxbrew/bin/python3`。沙箱里这条路径不存在，`run_python` 得到 `exit=127`。
|
||||
3. **工具说明指向一条走不通的安装路径。** `run_python` 描述和 `base.deliverables` 都写「缺库先 `pip install --user`」。沙箱断网、根只读、家目录是空 tmpfs，这条命令必然失败。
|
||||
4. **没有向系统申请包的通道。** 智能体只能探测、报错、让用户选择，再派一个后台任务去轮询一个永远不会出现的依赖。
|
||||
|
||||
同一次会话里还有多次模型网关 `401 invalid_api_key`。那是密钥问题，不在本方案范围内。
|
||||
|
||||
## 2. 目标
|
||||
|
||||
每个工作区和沙箱都能直接使用系统提供的 Python 能力（解释器 + 办公与数据处理基础包），不必各自新建虚拟环境。某个工作区需要额外的包时，向系统申请；系统决定装不装，并只把结果挂给这个工作区。
|
||||
|
||||
成功标准：
|
||||
|
||||
- 沙箱内 `import docx, openpyxl, pptx` 成功，`python3 -m housestyle.build` 能产出通过结构自检的 docx。
|
||||
- 两个工作区要同一包的不同版本时，互不影响，基础层版本不变。
|
||||
- 沙箱仍然断网。安装只发生在宿主侧的构建器里，并且只接受带哈希的预编译 wheel。
|
||||
- 白名单内的包自动批准；白名单外、要改基础层版本、体积超限、用户上传的 wheel，弹审批卡。sdist 与黑名单直接拒绝。
|
||||
|
||||
## 3. 不采用的两条路
|
||||
|
||||
- **每个工作区一个 venv。** 贵的是重复下载、解析和安装，不是 venv 目录本身。同样的包会被装很多遍。
|
||||
- **所有包装进一个可变的系统环境。** 一个工作区的需求会改变所有工作区的行为，版本冲突无法隔离，也无法复现「当时用的是哪一套包」。
|
||||
|
||||
## 4. 采用的结构
|
||||
|
||||
所有环境层不可变，按内容哈希命名，按会话挂载。系统只新增层，不改已经发出去的层。
|
||||
|
||||
```text
|
||||
<envroot>/ 默认 runtime/envs/，各服务实例共享
|
||||
python/cpython-<ver>/ 系统托管的 CPython（只读）
|
||||
python/current -> 上述目录
|
||||
layers/base-<hash>/site-packages
|
||||
layers/x-<hash>/site-packages 扩展层：相对基础层的增量闭包
|
||||
layers/iso-<hash>/site-packages 完整隔离层：仅在审批通过「覆盖基础层版本」时使用
|
||||
wheelhouse/ 按 sha256 去重的 wheel
|
||||
locks/<hash>.json
|
||||
catalog.json 白名单、黑名单、单包体积上限
|
||||
current -> layers/base-<hash>
|
||||
bin/pip 垫片：提示改用 python_env，不以安装成功退出
|
||||
```
|
||||
|
||||
层键 = 锁文件内容 + Python 标签 + 平台的哈希。同一份需求在任何工作区都命中同一层。
|
||||
|
||||
基础层由系统策划，首批为：python-docx、openpyxl、python-pptx、lxml、Pillow、numpy、matplotlib、pypdf、reportlab、markdown、pdfplumber，以及它们的传递依赖。名单可以在评审时增减；锁文件在第一次 `env ensure` 时生成并应入库，之后构建按锁复现。
|
||||
|
||||
解释器优先使用托管前缀（python-build-standalone 的 install_only 包）。下载失败时，退化为用系统 `python3 -m venv` 做一份唯一的托管前缀，并在 `python/SOURCE` 里写明这是退化，不是每个工作区各做一份。沙箱里的 `python3` 永远是这个前缀的绝对路径；找不到托管前缀时才用 `/usr/bin/python3`，不再走会落到 `/home` 下的 `PATH` 查找。
|
||||
|
||||
## 5. 一次执行如何看到这些包
|
||||
|
||||
沙箱参数在 `--tmpfs /home` 之后，只读挂载：托管解释器前缀（如果它位于会被 tmpfs 遮住的路径上）、基础层、该会话绑定的扩展层。`PATH` 固定为 `<托管 bin>:<envroot>/bin:/usr/local/bin:/usr/bin:/bin`，不再继承宿主 `PATH`。`PYTHONPATH` 是这些层再加上 house-style。`PIP_NO_INDEX=1`。
|
||||
|
||||
扩展层与基础层来自同一次以基础层为约束的解析，每个发行名只有一个版本，所以叠放顺序不影响导入。隔离层例外：它替换基础层，而不是叠在上面，用来满足「这个工作区必须要 numpy<2」这类与基础层冲突的需求。
|
||||
|
||||
## 6. 申请（工具 `python_env`）
|
||||
|
||||
动作：`status`、`request`、`wait`。
|
||||
|
||||
- `status` 返回基础层包清单、本会话已绑定的层、未完成的申请。
|
||||
- `request` 带包规格或工作区内的 `.whl`。解析以基础层锁为约束（等价于带 constraints 的 `pip install --dry-run --report`）。分级：
|
||||
- 全部在白名单内、纯 wheel、未超体积：自动批准并构建。命中已有层时只是多挂一个目录。
|
||||
- 白名单外、要覆盖基础层已固定的版本、超体积、用户上传的 wheel：写入 `exec_env_requests`，发一张选择卡（批准 / 拒绝；覆盖基础层版本时多一个「建隔离层」）。系统管理员或该会话的属主可以批。决定写入 `audit_events`。
|
||||
- 只有 sdist、命中黑名单、解析失败、哈希不符：拒绝，并说明原因。
|
||||
- 构建在宿主侧进行：`--only-binary=:all:`，校验 sha256，只用解包 wheel，不执行 setup.py。这是唯一有网络的步骤，并且不在沙箱里。
|
||||
- 构建完成后把层 ID 写进 `exec_env_bindings`。下一次 `run_python` / `run_shell` 挂上这些层。`wait` 在短超时内轮询申请状态。
|
||||
|
||||
## 7. 三个顾虑如何被挡住
|
||||
|
||||
- **成本。** 基础层覆盖常见办公和数据场景。wheel 与层按哈希缓存，第二个工作区要同一套包时不再下载、不再解析。
|
||||
- **冲突。** 不存在共享的可变环境。冲突需求要么被拒绝并说明卡在基础层的哪一个版本，要么经审批得到一份只属于该会话的隔离层。基础层哈希不变。
|
||||
- **包都堆进系统环境。** 基础层只放策划过的包。扩展层按会话绑定，其他会话看不见。升级基础层生成新的 `base-<hash>` 并移动 `current`；已经绑定旧基础层的会话保持不动，直到显式 rebase。
|
||||
|
||||
## 8. 安全
|
||||
|
||||
- 沙箱断网、根只读、家目录遮蔽，这些都不放宽。
|
||||
- 不在宿主上执行第三方构建脚本。
|
||||
- 只挂当前会话绑定的层。
|
||||
- 申请记录含会话、包、wheel 哈希、批准人。
|
||||
- 任务封存时应能读到基础层哈希与层 ID（绑定表就是这份清单）。
|
||||
|
||||
## 9. 实施切片
|
||||
|
||||
- **P0** 解释器与 `PATH` 不再指向会被沙箱遮住的 linuxbrew；`svc.sh` 在环境根存在时传入 `AGENT_SYSTEM_EXEC_ENV_ROOT` 与基础层 `AGENT_SYSTEM_EXEC_DEPS_DIR`；工具说明与提示词改为 `python_env`，去掉 `pip install --user`；配置了依赖层时启动做真实导入探针。
|
||||
- **P1** 环境根、锁、层、wheelhouse、托管解释器，以及 `agent-system env ensure|lock|gc|doctor|rebase|python`。
|
||||
- **P2** 表 `exec_env_requests`、`exec_env_bindings`，工具 `python_env`，分级审批，pip 垫片，按会话挂载。
|
||||
- **P3** 管理区「Python 环境」页（层、申请、批准/拒绝、rebase、gc、上传 wheel）。
|
||||
|
||||
## 10. 验收
|
||||
|
||||
- `sandboxArgv` 覆盖多层只读挂载、固定 `PATH`、`PIP_NO_INDEX`。
|
||||
- 离线解析夹具：冲突、白名单、sdist 拒绝、哈希不符。
|
||||
- 有 bwrap 时：沙箱内能导入层里的模块，`pip` 垫片给出申请指引，外网不可达。
|
||||
- 两个会话分别要 `foo==1` 与 `foo==2`，各得一层，基础层哈希不变。
|
||||
- 在基础层可用时，`housestyle.build` 产出的 docx 通过既有 OOXML 结构自检。
|
||||
|
||||
## 11. 已定与未定
|
||||
|
||||
已定（2026-10-15 对话）：白名单内自动批准，其余弹审批卡；解释器由系统托管，而不是长期绑死宿主 `/usr/bin/python3`。
|
||||
|
||||
未定，留在评审：基础层最终包名单是否增减；审批人除系统管理员和会话属主外，是否还要接项目角色。本实施先只认系统管理员与会话属主，避免在基座里发明第二套项目角色判断。
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: 文档职责矩阵整改
|
||||
date: 2026-10-15
|
||||
type: feature
|
||||
execution: code
|
||||
artifact_contract: rdm-duty-matrix/v1
|
||||
product_contract_source: legacy-requirements
|
||||
---
|
||||
|
||||
# 文档职责矩阵整改 r2
|
||||
|
||||
负责人：weichen；编制日期：2026-10-15。
|
||||
本记录是文档职责整改的唯一主记录。它取代
|
||||
[r1 增量方案](2026-10-13-rdm-settings-members-duties-perms-increment.md)
|
||||
第四节，以及该方案 P5、P7 中“文档职责页”的交互；r1 的设置归属、成员、权限矩阵与其余工作包继续有效。
|
||||
|
||||
候选分支 `feature/rdm-settings-completion` 里的文档职责界面暂停合入。系统设置、成员选择、权限矩阵和已落地的后端安全能力不在本暂停范围内。本任务从当时的 `origin/main` 另起兄弟分支 `feature/rdm-duty-matrix`，不把该候选当作父分支。
|
||||
|
||||
## 四项领域裁定
|
||||
|
||||
1. 职责只到文档级。项目设置不再新增章节级职责；历史章节审签只读保留。
|
||||
2. 项目设置只分配已有受控文档的编制、审核、批准职责。不创建文档、不从模板生成、不提交审核、不审核通过、不驳回、不终批。
|
||||
3. 每份文档恰好一名编制、至少一名审核、恰好一名批准。同一人在同一文档上只担一个职责。审核可以有多人。
|
||||
4. 与文档职责完全一致的旧章节覆盖可以归并为文档级。同一文档下章节人员不一致的，列出清单，由项目负责人逐文档确认，不自动覆盖。
|
||||
|
||||
项目负责人可以分配职责，但不因负责人身份自动成为编制、审核或批准人。当前职责与已冻结的审签名单分开保存；修改当前职责不改写已批准版本和历史名单。
|
||||
|
||||
姓名来源仍按 r1 评审补充第 3 条待证。本页用账号标识展示，不把未证实的姓名字段写进契约。
|
||||
|
||||
## 契约
|
||||
|
||||
读：`rdm.duty.matrix`。`view` 为 `member`、`document` 或 `matrix`。筛选在分页之前。文档页上限 20。响应给出文档完整性、`dutyVersion`、章节覆盖数、在途轮次、成员资格、单元格 `none|author|reviewer|approver`，以及当前操作人是否可分配。单元格只投影当前文档级职责。没有 `duty.assign` 的调用直接拒绝，避免矩阵列头泄露不可见文档。
|
||||
|
||||
写：唯一入口仍是每份文档的完整目标，`rdm.review.assign.doc` 与 `rdm.review.assign.doc.batch`（1–20 项，整批原子）。带 `expectedDutyVersion` 与 `confirmInvalidation`。`rdm.review.assign` 只返回“章节级职责已停用，请在文档级设置”。
|
||||
|
||||
预览：`rdm.duty.preview` 与写载荷相同，只读返回替换对象、在途失效和缺人原因，不写数据。保存时服务端重新校验。
|
||||
|
||||
迁移：`rdm.duty.legacy.scan` 只读；`rdm.duty.legacy.apply` 只清除与文档职责完全一致的章节覆盖。
|
||||
|
||||
## 三视图
|
||||
|
||||
按人员、按文档、成员×文档矩阵共享同一份服务端数据和同一份未保存草稿。单元格由文档三权反推。把唯一编制或批准改成其他值可以继续编辑，但在指定接替人前不能保存。替换已有编制或批准时提示“将替换某某”，保存时一次替换。窄屏不压缩整张矩阵，改走前两个视图。一次保存最多 20 份文档。请求带递增序号，过期响应丢弃。写入结果未知时重读，不自动重放。
|
||||
|
||||
页面顶部写明：本页只分配已有文档的职责，不创建或生成文档。
|
||||
|
||||
## 验收
|
||||
|
||||
单文档三权恰好、多审核人、一人一责、三视图草稿一致、替换提示与原子替换、缺人禁止保存、成员失效保存被拒、版本冲突、批量整批失败不写、影响预览与历史不变、无私密文档列头泄露、无创建/生成/审签按钮、迟到响应不覆盖、design-guard、`make test` 与 `make build`。部署和真实账号浏览器验收另行授权。
|
||||
+11
-2
@@ -4,6 +4,9 @@
|
||||
本索引负责导航与差异提示，规划正文、批准范围和验收条件仍以链接的主记录及其批准版本为准。
|
||||
合入授权不批准新方向、不调整里程碑范围、不启动新的业务任务。
|
||||
|
||||
待评审（收录不是批准）：[svc 插件组合部署（--with）方案 r1](2026-10-14-svc-plugin-compose-deploy.md)；
|
||||
[分层 Python 环境方案 r1](2026-10-15-layered-python-env.md)（8788 无法生成 docx 的环境层；白名单自动批准，其余审批）。
|
||||
|
||||
## 先看哪一份
|
||||
|
||||
- [IAM I1 权限边界与公开扩展合同 r1](2026-10-13-iam-i1-permission-contract.md)：
|
||||
@@ -180,7 +183,11 @@ RDM 总案把库分期作为支撑与依赖，不覆盖库分期的原始范围
|
||||
|
||||
- [最终验证与合入调度实施计划 r1](2026-10-13-merge-queue-implementation-plan.md)：阶段 5 已于 2026-10-13 经用户「批准」确认，原生逐项实施；U1–U3 源码与自检在 Dev 任务分支推进，U4 待启用记录及规则已准备，U5 平台所有者操作与 U6 真实三任务 CI 试行仍 NOT_RUN。实际对象、证据和进度回链 Dev 任务卡，不把本索引当第二进度权威。
|
||||
|
||||
- [RDM 设置归属、成员、文档职责与权限矩阵完善增量方案 r1](2026-10-13-rdm-settings-members-duties-perms-increment.md)：承接总案 U3/U4/U6（衔接 U5）的完整增量——设置作用域与受管项、可搜索人员选择器、文档清单＋职责分配、单成员/多人权限矩阵与三态项目覆盖；含服务端一致性修复（职责目标成员校验推翻 G1-5 旧裁定、职责变更与审签失效原子化）与 P1–P8 工作包。**2026-10-13 用户评审通过并授权实施**（两批推进；正式验收与清理回收保留人工节点）；P1 契约随本稿固定，P2 基座契约扩展按总案发版顺序排队。
|
||||
- [RDM 设置归属、成员、文档职责与权限矩阵完善增量方案 r1](2026-10-13-rdm-settings-members-duties-perms-increment.md)：承接总案 U3/U4/U6（衔接 U5）的完整增量——设置作用域与受管项、可搜索人员选择器、单成员/多人权限矩阵与三态项目覆盖；含服务端一致性修复。**2026-10-13 用户评审通过并授权实施**。第四节及 P5/P7 的文档职责页交互已被下方 r2 取代，其余部分继续有效。
|
||||
|
||||
## 2026-10-15 规划补充
|
||||
|
||||
- [文档职责矩阵整改 r2](2026-10-15-rdm-duty-matrix-rework.md)：项目设置只分配已有文档的编制、审核、批准；按人员、按文档、成员×文档三视图共享一份草稿。章节级新指派停用，有歧义的旧章节职责逐文档确认。2026-10-15 按实施方案执行；部署与真实账号验收未授权。收录不把其余未完成增量自动标成已验收。
|
||||
|
||||
## 2026-10-12 规划补充
|
||||
|
||||
@@ -192,7 +199,9 @@ RDM 总案把库分期作为支撑与依赖，不覆盖库分期的原始范围
|
||||
|
||||
- [RDM 两树一网集成、完善与追溯审计展示方案 r1](2026-10-11-rdm-two-trees-trace-audit-integration.md)：对应 P3/MS3，源码已有部分实现；优先补项目绑定、创建者/管理员读取隔离与历史完整性，再接统一展示。用户确认范围为 RDM 与必要基座能力；r1 已获用户评审通过（2026-10-11，五阶段一并，含 KTD4 双层管理员裁定）。U1–U5 全部实施合入（RDM PR #195/#197/#201/#213；Dev PR #368，2026-10-11；超管槽待基座能力接线，见 RDM 仓 U1 基座扩展申请）。U6 团队存储独立后续；运行验收属部署环境。
|
||||
|
||||
- [RDM 模板与两树一网对话文档生成方案 r1.1](2026-10-11-rdm-template-dialog-generation.md)：69 类旧资产、4 个当前注册模板的盘点及生成闭环设计；待评审，实施/迁移/模型试验/运行验收 NOT_RUN。与两树一网集成方案共用项目授权、原子事件与历史能力。 首批项目建议书/竞品分析、随后扩展全部文档已确认（2026-10-11），其余方案与实施仍待评审。
|
||||
- [DHF 模板接入 RDM 文档生成管线 r0.1](2026-10-14-dhf-template-generation-plan.md)：用户于 2026-10-14 批准本方案并启动实施。RDM 的首批资产合同与 44 份原件目录已在独立任务分支保存；14 份 DOC 均有自动转换候选，E1 内容与版式保真仍待人工评审，正式模板发布数为 0。真实《项目建议书》的结构/槽位评审候选已形成；U1 整体、U2–U6 用户流程、正式验收与部署尚未完成。与在途两树任务沿用同一 TT-T/TT-D 契约；每阶段仍按既有人工评审门禁推进。
|
||||
|
||||
- [RDM 模板与两树一网对话文档生成方案 r1.1](2026-10-11-rdm-template-dialog-generation.md)：69 类旧资产、2026-10-11 四个注册模板的历史盘点及生成闭环设计；待评审，实施/迁移/模型试验/运行验收 NOT_RUN。与两树一网集成方案共用项目授权、原子事件与历史能力。 首批项目建议书/竞品分析、随后扩展全部文档已确认（2026-10-11），其余方案与实施仍待评审；2026-10-14 资产和源码刷新见 DHF 专项。
|
||||
|
||||
- [RDM 最终目标核对与完整交付方案 r1](2026-10-11-rdm-final-target-completion.md)：本轮用户确认系统级唯一项目、管理员上限内覆盖、私域与三权读取边界；覆盖 34 UR／68 SR／10 F、全部69类模板及现有XLSX，当前源复核 RDM d8d7e743。总体方案待评审，实施/迁移/运行验收 NOT_RUN；模板方案为子方案。
|
||||
|
||||
|
||||
@@ -0,0 +1,589 @@
|
||||
{
|
||||
"source": "SELF",
|
||||
"dev_sha": "add097d06137c4912a4ed9279e98ca353e4e4cf1",
|
||||
"rdm_sha": "6fcb256205c2384abed35d3b6ab96ca7216e9297",
|
||||
"rdm_frontend_sha": "eb2d6d32f9323094d568bc9d80b4e5ed4f0af25b",
|
||||
"rdm_frontend_preview_sha256": "0f53735a5b58d4c7c545ceb56ce02d0305af47f379f16d92295323a68dd5f13d",
|
||||
"summary": {
|
||||
"count": 44,
|
||||
"formats": {
|
||||
"docx": 30,
|
||||
"doc": 14
|
||||
},
|
||||
"unique_content": 41,
|
||||
"phases": {
|
||||
"0. 商务阶段": 1,
|
||||
"1. 策划阶段": 3,
|
||||
"2. 设计输入阶段": 15,
|
||||
"3. 设计输出阶段": 9,
|
||||
"4. 设计验证阶段": 8,
|
||||
"5. 设计转换阶段": 3,
|
||||
"6. 设计确认阶段": 5
|
||||
}
|
||||
},
|
||||
"assets": [
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/0. 商务阶段/0.1初始要求申请表.docx",
|
||||
"format": "docx",
|
||||
"bytes": 17137,
|
||||
"sha256": "eb9d287014911a18c5589a0b9e7b7f63ad535178cf7cf29a3a269dcf46118391",
|
||||
"tables": 2,
|
||||
"gridSpan": 0,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/1. 策划阶段/1.1、731QCP29-F01 项目建议书 02.docx",
|
||||
"format": "docx",
|
||||
"bytes": 25114,
|
||||
"sha256": "3f54f060d9c528e3fd4e7b7c606f352fbabe9488a25ad95a7341fa7901518b29",
|
||||
"tables": 2,
|
||||
"gridSpan": 4,
|
||||
"vMerge": 10,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/1. 策划阶段/1.2、731QCP29-F02 设计开发计划任务书 02.docx",
|
||||
"format": "docx",
|
||||
"bytes": 36248,
|
||||
"sha256": "d152b0b4d2bb1aa30c60aaec19e331a05a552d7d119f5a6f4cc4177f163159fb",
|
||||
"tables": 7,
|
||||
"gridSpan": 6,
|
||||
"vMerge": 106,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/1. 策划阶段/1.3、731QCP29-F07 设计开发（策划）评审记录 02.docx",
|
||||
"format": "docx",
|
||||
"bytes": 26043,
|
||||
"sha256": "d6f3cca9c3c1f7ed1ea60322c5435f8410d6cf7ca2096b04a367fc8255ee1330",
|
||||
"tables": 5,
|
||||
"gridSpan": 35,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.10.1、731QCP29-F13 配置管理计划 02.docx",
|
||||
"format": "docx",
|
||||
"bytes": 58902,
|
||||
"sha256": "94e8e7fc868d76c62199fdeb30ea0aab7db3c58a36ef94aef15d629f4930b11a",
|
||||
"tables": 5,
|
||||
"gridSpan": 4,
|
||||
"vMerge": 10,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.10.2、软件维护计划模板.docx",
|
||||
"format": "docx",
|
||||
"bytes": 166962,
|
||||
"sha256": "76fc4d4fddecc04e533aceb930aab9b82f4956c6bf5fb3d04f19150003c7932e",
|
||||
"tables": 2,
|
||||
"gridSpan": 4,
|
||||
"vMerge": 10,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/footer2.xml",
|
||||
"word/footer3.xml",
|
||||
"word/footer4.xml",
|
||||
"word/footer5.xml",
|
||||
"word/footer6.xml",
|
||||
"word/header1.xml",
|
||||
"word/header2.xml",
|
||||
"word/header3.xml",
|
||||
"word/header4.xml",
|
||||
"word/header5.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.11.1、731QCP29-F16设计输入规格书模版.docx",
|
||||
"format": "docx",
|
||||
"bytes": 68678,
|
||||
"sha256": "3fef2ed7d0aa5e0ac8c01b92571b0ce9dbe3a8191a06d7a79d799fb62fe5e613",
|
||||
"tables": 17,
|
||||
"gridSpan": 4,
|
||||
"vMerge": 10,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.12、731QCP29-F05 设计开发输入清单 02.docx",
|
||||
"format": "docx",
|
||||
"bytes": 20681,
|
||||
"sha256": "de990de6bf13e4c692a9664719f508cf2d34765b14ddd77fbb58879c99dee6da",
|
||||
"tables": 2,
|
||||
"gridSpan": 4,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.13、RDDHF0213-xxxx产品系统设计方案.doc",
|
||||
"format": "doc",
|
||||
"bytes": 419499,
|
||||
"sha256": "8168ea37c7ca5f32f5d57527d0c8ff5c2d583998167e30ed713937c95e9e82d4",
|
||||
"header_hex": "d0cf11e0a1b11ae1"
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.14、731QCP29-F07 设计输入评审记录.docx",
|
||||
"format": "docx",
|
||||
"bytes": 28675,
|
||||
"sha256": "a3677cb06a3946769e501f906669f57c4cd21769109ad5e27697d76320fa8686",
|
||||
"tables": 5,
|
||||
"gridSpan": 35,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.1、731QCP29-F14 用户需求模板.doc",
|
||||
"format": "doc",
|
||||
"bytes": 115712,
|
||||
"sha256": "2f9c6795f81188797018ef7e2ba4c7e693db0f3fabaa2eb5a9478fb2e2b1a6ac",
|
||||
"header_hex": "d0cf11e0a1b11ae1"
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.2、RDDHF0202-xxxx 医疗器械法规和标准清单.docx",
|
||||
"format": "docx",
|
||||
"bytes": 29384,
|
||||
"sha256": "2b36daeedc8c54a7975ece49102d279584bb80a5ff262912db2941edf009feec",
|
||||
"tables": 3,
|
||||
"gridSpan": 5,
|
||||
"vMerge": 10,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.3、RDDHF0203-xxxx 同类产品不良事件信息.docx",
|
||||
"format": "docx",
|
||||
"bytes": 29958,
|
||||
"sha256": "f7cd69b08c1ec1bea04ec8a30aaa54f6d8bed90a6e9544c3b9264341ac299edc",
|
||||
"tables": 3,
|
||||
"gridSpan": 4,
|
||||
"vMerge": 10,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml",
|
||||
"word/header2.xml",
|
||||
"word/header3.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.4、731QCP29-F15 系统需求规格书模板.doc",
|
||||
"format": "doc",
|
||||
"bytes": 119296,
|
||||
"sha256": "b58d1b900c951f8c20b5f301cb75e072a91c98ab3d71b172128b51dc84c8bff3",
|
||||
"header_hex": "d0cf11e0a1b11ae1"
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.5、731QCP29-F07 需求评审记录表.docx",
|
||||
"format": "docx",
|
||||
"bytes": 27823,
|
||||
"sha256": "102ed2b6418b51b383de97a735b8a183d025af9da139152d92715e44ba860b1b",
|
||||
"tables": 6,
|
||||
"gridSpan": 42,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.6、731QCP29-F03 风险管理计划 02.docx",
|
||||
"format": "docx",
|
||||
"bytes": 31626,
|
||||
"sha256": "0c1484d6b29595077c9b60e08a69c73d008216744e7df59f83c0e7054f1e51c9",
|
||||
"tables": 7,
|
||||
"gridSpan": 8,
|
||||
"vMerge": 13,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.7.3、731QCP29-F04 风险管理报告 02.docx",
|
||||
"format": "docx",
|
||||
"bytes": 29910,
|
||||
"sha256": "d4f18eb817dae8b655715c6832b591299d0e5c7c1196e777cf9e48e79b4f3544",
|
||||
"tables": 6,
|
||||
"gridSpan": 8,
|
||||
"vMerge": 13,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.8、731QCP29-Fxx 软件开发计划-模板.doc",
|
||||
"format": "doc",
|
||||
"bytes": 300544,
|
||||
"sha256": "2dee0e085113adc4868546b2469eab89c076b6c8613417b3897e975a2adb4e29",
|
||||
"header_hex": "d0cf11e0a1b11ae1"
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/2. 设计输入阶段/2.9、软件需求规格书模板.docx",
|
||||
"format": "docx",
|
||||
"bytes": 48903,
|
||||
"sha256": "aa12be2b8158439c91b77df5a90fd2d71aa658186e37332c54a6766b572b4a30",
|
||||
"tables": 10,
|
||||
"gridSpan": 4,
|
||||
"vMerge": 10,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/3. 设计输出阶段/3.12、原材料进货检验规范-模版.docx",
|
||||
"format": "docx",
|
||||
"bytes": 995696,
|
||||
"sha256": "34608b520ebff384cdb613818271a04d3e7fc9a71da693cdd51550ab0b38bf0c",
|
||||
"tables": 18,
|
||||
"gridSpan": 124,
|
||||
"vMerge": 10,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/footer2.xml",
|
||||
"word/header1.xml",
|
||||
"word/header2.xml"
|
||||
],
|
||||
"linked_images": [
|
||||
{
|
||||
"part": "word/document.xml",
|
||||
"link": "rId12",
|
||||
"embed": "rId11"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/3. 设计输出阶段/3.15、产品技术要求.doc",
|
||||
"format": "doc",
|
||||
"bytes": 16896,
|
||||
"sha256": "b787295c6c66089cb0895a1f9ebd77058091bb85355910f84d014613470b2512",
|
||||
"header_hex": "d0cf11e0a1b11ae1"
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/3. 设计输出阶段/3.17、731QCP29-F06 设计开发输出清单 02.docx",
|
||||
"format": "docx",
|
||||
"bytes": 22792,
|
||||
"sha256": "f53a2f271bf2782ab12cba1f26a141d5560e7e7aa905a0a74b46b10bbf43e84b",
|
||||
"tables": 1,
|
||||
"gridSpan": 4,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/header1.xml",
|
||||
"word/footer1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/3. 设计输出阶段/3.18、731QCP29-F07 设计输出评审记录.docx",
|
||||
"format": "docx",
|
||||
"bytes": 28214,
|
||||
"sha256": "e37ab2828e647ffee84068d8c4ce6520c70b3a3849d37d946cb7bd52bd28efe9",
|
||||
"tables": 5,
|
||||
"gridSpan": 35,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/header1.xml",
|
||||
"word/footer1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/3. 设计输出阶段/3.6.2、软件详细设计模板.docx",
|
||||
"format": "docx",
|
||||
"bytes": 51735,
|
||||
"sha256": "e1089b1de6d2c06e5468adfa7f28b9cfaa13b3382f299e9e0af204543d221c20",
|
||||
"tables": 30,
|
||||
"gridSpan": 0,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/3. 设计输出阶段/3.8、RDDHF0213-xxx采购技术说明-结构&硬件.doc",
|
||||
"format": "doc",
|
||||
"bytes": 7791188,
|
||||
"sha256": "77fd422be6f37632052d47a05490312a8e36098eceb6d529653f59dde8fe51ef",
|
||||
"header_hex": "d0cf11e0a1b11ae1"
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/3. 设计输出阶段/3.9.1、731QCP29-Fxx 工艺流程图模板.doc",
|
||||
"format": "doc",
|
||||
"bytes": 199173,
|
||||
"sha256": "1d702e1cdbdca52fe7957b01d13f15f77d447d78498a78e332d4646e27ee014c",
|
||||
"header_hex": "d0cf11e0a1b11ae1"
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/3. 设计输出阶段/3.9.2、RDSOP00xx-00xx xxx作业指导书.docx",
|
||||
"format": "docx",
|
||||
"bytes": 6312572,
|
||||
"sha256": "e2d5e596ee1fa24ddd4166f41575167ed054451beb6fdbd1d1bccd15a709ef48",
|
||||
"tables": 7,
|
||||
"gridSpan": 1,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/footer2.xml",
|
||||
"word/footer3.xml",
|
||||
"word/header1.xml",
|
||||
"word/header2.xml",
|
||||
"word/header3.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/3. 设计输出阶段/731QCP33-F01 软件可追溯性分析报告 02.docx",
|
||||
"format": "docx",
|
||||
"bytes": 24006,
|
||||
"sha256": "23d6402dc8511a1ed7815082cc00822f9d62e3b74509bd75302987bfdf538f8a",
|
||||
"tables": 3,
|
||||
"gridSpan": 4,
|
||||
"vMerge": 10,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/4. 设计验证阶段/24.产品有效期验证.doc",
|
||||
"format": "doc",
|
||||
"bytes": 144292,
|
||||
"sha256": "425e993090eb84c5a88fbc6fe2d664d788d4879a7e173bd8a235b6aa0589311d",
|
||||
"header_hex": "d0cf11e0a1b11ae1"
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/4. 设计验证阶段/41.软件单元测试用例-模板.doc",
|
||||
"format": "doc",
|
||||
"bytes": 57249,
|
||||
"sha256": "02f41e0770380332105851d620fbcfc470dbef93d2e7fa55c4b1dad441a7fcc0",
|
||||
"header_hex": "d0cf11e0a1b11ae1"
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/4. 设计验证阶段/42.软件集成测试用例-模板.doc",
|
||||
"format": "doc",
|
||||
"bytes": 60369,
|
||||
"sha256": "1a373f9bec235d6771fceec15341c858412737298fad696dd68cb9bf262a5dec",
|
||||
"header_hex": "d0cf11e0a1b11ae1"
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/4. 设计验证阶段/43.软件系统测试用例-模板.doc",
|
||||
"format": "doc",
|
||||
"bytes": 60915,
|
||||
"sha256": "22b211453d734668bd8b6a5948a5612ec93bde41838ee0fe0535551124566062",
|
||||
"header_hex": "d0cf11e0a1b11ae1"
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/4. 设计验证阶段/49. 软件配置管理报告-模板.doc",
|
||||
"format": "doc",
|
||||
"bytes": 63121,
|
||||
"sha256": "243993a6ab53b475139afbeef04c9be0d593956bb2ae4e90f77c22b2e38b0063",
|
||||
"header_hex": "d0cf11e0a1b11ae1"
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/4. 设计验证阶段/731QCP29-F07 设计验证评审记录.docx",
|
||||
"format": "docx",
|
||||
"bytes": 28214,
|
||||
"sha256": "e37ab2828e647ffee84068d8c4ce6520c70b3a3849d37d946cb7bd52bd28efe9",
|
||||
"tables": 5,
|
||||
"gridSpan": 35,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/header1.xml",
|
||||
"word/footer1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/4. 设计验证阶段/731QCP29-F08 设计开发验证记录 02.docx",
|
||||
"format": "docx",
|
||||
"bytes": 24111,
|
||||
"sha256": "c5b84546e647259f25b9445358ff93ecf61e047075d83a87b1f0f928df32f69a",
|
||||
"tables": 1,
|
||||
"gridSpan": 14,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/header1.xml",
|
||||
"word/footer1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/4. 设计验证阶段/756QCP26-F02 验证确认报告 V03-.docx",
|
||||
"format": "docx",
|
||||
"bytes": 42712,
|
||||
"sha256": "f5bbe7816e79a62e7bbbf297014be98a63b9ec306999a09723bef1a78d60b3fd",
|
||||
"tables": 12,
|
||||
"gridSpan": 2,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/footer2.xml",
|
||||
"word/header1.xml",
|
||||
"word/header2.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/5. 设计转换阶段/731QCP29-F04 风险管理报告 02.docx",
|
||||
"format": "docx",
|
||||
"bytes": 31234,
|
||||
"sha256": "8a17e5b4cff1d4a7d51a8ee5d4cc6b5e4da9c91f3a501cbe91bc3409d3f7b0b9",
|
||||
"tables": 6,
|
||||
"gridSpan": 8,
|
||||
"vMerge": 13,
|
||||
"headers_footers": [
|
||||
"word/header1.xml",
|
||||
"word/footer1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/5. 设计转换阶段/731QCP29-F07 设计转移评审记录.docx",
|
||||
"format": "docx",
|
||||
"bytes": 28214,
|
||||
"sha256": "e37ab2828e647ffee84068d8c4ce6520c70b3a3849d37d946cb7bd52bd28efe9",
|
||||
"tables": 5,
|
||||
"gridSpan": 35,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/header1.xml",
|
||||
"word/footer1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/5. 设计转换阶段/731QCP29-F09+试产总结报告+03-20250730.docx",
|
||||
"format": "docx",
|
||||
"bytes": 31901,
|
||||
"sha256": "7600083fa8675a95f2365267801cb3d712bcb0d0534b49371bf12c2abda9a66b",
|
||||
"tables": 4,
|
||||
"gridSpan": 23,
|
||||
"vMerge": 30,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/header1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/6. 设计确认阶段/53. 使用错误评估报告-模板zlx.doc",
|
||||
"format": "doc",
|
||||
"bytes": 136224,
|
||||
"sha256": "75cafe0c4c26edb2d9430f3c9839c5217106acdb5f205f12dcf3d728a67f5ed8",
|
||||
"header_hex": "d0cf11e0a1b11ae1"
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/6. 设计确认阶段/731QCP29-F07 设计确认评审记录.docx",
|
||||
"format": "docx",
|
||||
"bytes": 28214,
|
||||
"sha256": "e37ab2828e647ffee84068d8c4ce6520c70b3a3849d37d946cb7bd52bd28efe9",
|
||||
"tables": 5,
|
||||
"gridSpan": 35,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/header1.xml",
|
||||
"word/footer1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/6. 设计确认阶段/731QCP29-F11 设计开发确认记录 02.docx",
|
||||
"format": "docx",
|
||||
"bytes": 23026,
|
||||
"sha256": "d01ff3c568416c81d7729fe35c4fe0820513dcbf74e2e33c3a6bf7db1453d609",
|
||||
"tables": 1,
|
||||
"gridSpan": 9,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/header1.xml",
|
||||
"word/footer1.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/6. 设计确认阶段/756QCP20-F01 计算机软件确认报告 02.doc",
|
||||
"format": "doc",
|
||||
"bytes": 114176,
|
||||
"sha256": "45e57b363abf14a19e6ef26af23f33b42095e68c1516f1af13f7b73f1f21050d",
|
||||
"header_hex": "d0cf11e0a1b11ae1"
|
||||
},
|
||||
{
|
||||
"source": ".templates/DHF 文件模板/6. 设计确认阶段/756QCP26-F01 验证确认方案 V03-.docx",
|
||||
"format": "docx",
|
||||
"bytes": 44029,
|
||||
"sha256": "525b2c40d74e09318188216b1cbc3d62ca410cdb55008fa7996ed9bdbc36e3f0",
|
||||
"tables": 14,
|
||||
"gridSpan": 33,
|
||||
"vMerge": 0,
|
||||
"headers_footers": [
|
||||
"word/footer1.xml",
|
||||
"word/footer2.xml",
|
||||
"word/header1.xml",
|
||||
"word/header2.xml"
|
||||
],
|
||||
"linked_images": []
|
||||
}
|
||||
],
|
||||
"rdm_source_sha256": {
|
||||
"internal/rdmapp/templates.go": "3defc58f0e20dc15d8cee9d846da0d998ca3caf659af2cca2603b6d8f1741419",
|
||||
"internal/rdmapp/templates_gen.go": "8d4a68a31b69ab1834e66acc583211614d8177d23e1844bd4aa61c98ff57547c",
|
||||
"internal/rdmapp/templates_embed.go": "26c940d94639b283fec2add2f2312931321d0bc0cd5e6ebb95c3c3b1c4f188c1",
|
||||
"internal/rdmapp/compose.go": "b2da219785cbf44ee53d1408e56628f44619c8dd93fb4415f2daa9013b591349",
|
||||
"internal/rdmapp/structure.go": "116a25bf5e76f940f54ba67b87b855c5953b944a4ca4f088953766a35563fa86",
|
||||
"internal/rdmapp/parse.go": "9db5e576496b60f54b6be1c6601df14b776075edefd1f712bc78d22d86bb4dc3",
|
||||
"internal/rdmapp/draftproposal.go": "85c638e9ac5b8c9c81974af6eb33b8e86053d3997ab718169a64cd987d1376a6",
|
||||
"internal/rdmapp/docsubmission.go": "e8070350ad794b46d226cba3acb9ff78bfed58113f766cf845d194bb6f3d686f",
|
||||
"internal/rdmapp/docx.go": "7ed609f658cc31ad216464fcea5dbdaa4e25cb56b3de205bc464e9848964db3d",
|
||||
"internal/rdmapp/export_artifact.go": "07a1a4fe537674e1413e38425a36af3c02e29c9e041f6478f96c45769328b2ce",
|
||||
"internal/rdmapp/doc_export_visibility.go": "e4fd051ffb643ae3f002b797ee4175b8b3b2a698012c411021492cab372e7580",
|
||||
"plugins/rdm/plugin.go": "25382894886fef7e9015d254fc416766d9cd7ce355671c088d2c34b0870a2eb8",
|
||||
"scripts/build-product.sh": "70041237df111f064257a8ba95e463de1db6c734d71a77f0f20efa3fa812de97",
|
||||
"scripts/pack-release.sh": "ebeb2b6728fb964aa9983c07e022b52e11be7d2efb76c5bbb6941ce13547d360"
|
||||
},
|
||||
"business_test": "NOT_RUN",
|
||||
"doc_conversion": "NOT_RUN"
|
||||
}
|
||||
@@ -0,0 +1,210 @@
|
||||
{
|
||||
"source": "SELF",
|
||||
"observed_at_utc": "2026-10-14T14:13:54.776253+00:00",
|
||||
"repo": "weichen/Agent-System-Dev",
|
||||
"main_sha": "e1bc2602e18a89e4d75a4bf6cd80bc7f9b4d2164",
|
||||
"queue_issue": 518,
|
||||
"issue_content_version": 34,
|
||||
"issue_updated_at": "2026-10-14T13:41:21Z",
|
||||
"active_window": "- 当前窗口：无（mq-dev-20261014-537-01 因独立 Stage 8 Review 的三项 Important 整改与安全设计重审，于 2026-10-14T06:06:23.872984+00:00 主动释放）。旧固定 head=6a2f7cd3e610a263b6348efe9084e386dc88f30c / base=4f84c2e1630cd0311643529fae1c3a99f1dd5d64 的 GATE run3076/3077、阶段7人工批准均只对应旧对象；PR #537 已按用户撤销指示关闭，迁移专用远端与本地分支已删除；该任务不再排队。旧 GATE 和阶段结论仅为历史记录。",
|
||||
"branch_protection": {
|
||||
"enable_push": false,
|
||||
"enable_force_push": false,
|
||||
"block_on_outdated_branch": true,
|
||||
"enable_status_check": true,
|
||||
"status_check_contexts": [
|
||||
"ci / test (pull_request)",
|
||||
"ci / test-pg (pull_request)",
|
||||
"ci / svc-realcombo (pull_request)"
|
||||
],
|
||||
"required_approvals": 0,
|
||||
"block_admin_merge_override": true
|
||||
},
|
||||
"post_trial_prs": [
|
||||
{
|
||||
"number": 539,
|
||||
"merged": true,
|
||||
"merge_sha": "d40579ed7fe3bbca68d3c6fcd1bce6707688d59e",
|
||||
"merged_at": "2026-10-14T06:40:54Z",
|
||||
"head_sha": "3b0e100fba149dbb29066c2ca3d2a74bbe1d4443",
|
||||
"issue_body_ref": false,
|
||||
"issue_comment_refs": [
|
||||
{
|
||||
"id": 6017,
|
||||
"created_at": "2026-10-14T06:42:12Z",
|
||||
"head": "<!-- facts-539-merge-record-20261014T0700Z -->"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"number": 540,
|
||||
"merged": true,
|
||||
"merge_sha": "11aa76a3bc1c5047791f9a2de154e451634b6567",
|
||||
"merged_at": "2026-10-14T08:08:07Z",
|
||||
"head_sha": "889f64f88167a5314ebfa42a41f9c7a57f91b404",
|
||||
"issue_body_ref": false,
|
||||
"issue_comment_refs": [
|
||||
{
|
||||
"id": 6025,
|
||||
"created_at": "2026-10-14T07:02:56Z",
|
||||
"head": "<!-- dhf-u1-stage7-wip-20261014-01a137f8 -->"
|
||||
},
|
||||
{
|
||||
"id": 6059,
|
||||
"created_at": "2026-10-14T08:04:24Z",
|
||||
"head": "<!-- mq-dev-20261014-dhf-u1-01-claim -->"
|
||||
},
|
||||
{
|
||||
"id": 6066,
|
||||
"created_at": "2026-10-14T08:09:12Z",
|
||||
"head": "<!-- mq-dev-20261014-dhf-u1-01-release -->"
|
||||
},
|
||||
{
|
||||
"id": 6097,
|
||||
"created_at": "2026-10-14T08:32:38Z",
|
||||
"head": "<!-- mq-dev-20261014-dhf-cardclose-01-claim -->"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"number": 541,
|
||||
"merged": true,
|
||||
"merge_sha": "d23fb4363dcc0a206e71e47f9cd23a644c7e1c70",
|
||||
"merged_at": "2026-10-14T07:33:18Z",
|
||||
"head_sha": "221afaeb169b826ecd38567296319c20c0e94b18",
|
||||
"issue_body_ref": false,
|
||||
"issue_comment_refs": []
|
||||
},
|
||||
{
|
||||
"number": 542,
|
||||
"merged": true,
|
||||
"merge_sha": "7e9ebdea5055a63c713ccc0fb1f938ffe35a6b9d",
|
||||
"merged_at": "2026-10-14T08:46:12Z",
|
||||
"head_sha": "60d48e0580a36b2e6f93c77bb1edbe9bd0be342e",
|
||||
"issue_body_ref": false,
|
||||
"issue_comment_refs": [
|
||||
{
|
||||
"id": 6097,
|
||||
"created_at": "2026-10-14T08:32:38Z",
|
||||
"head": "<!-- mq-dev-20261014-dhf-cardclose-01-claim -->"
|
||||
},
|
||||
{
|
||||
"id": 6106,
|
||||
"created_at": "2026-10-14T08:35:39Z",
|
||||
"head": "<!-- mq-dev-20261014-dhf-cardclose-02-replacement -->"
|
||||
},
|
||||
{
|
||||
"id": 6117,
|
||||
"created_at": "2026-10-14T08:47:12Z",
|
||||
"head": "<!-- mq-dev-20261014-dhf-cardclose-02-release -->"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"number": 543,
|
||||
"merged": true,
|
||||
"merge_sha": "da93edf23408ca871ae489ac2123e10734c24413",
|
||||
"merged_at": "2026-10-14T09:24:42Z",
|
||||
"head_sha": "deac1025f1810d7a535c44a16dd6368eb652c979",
|
||||
"issue_body_ref": false,
|
||||
"issue_comment_refs": []
|
||||
},
|
||||
{
|
||||
"number": 544,
|
||||
"merged": true,
|
||||
"merge_sha": "2dbe11c5d970e7d6a71d0ce1a00eb399bfbbd427",
|
||||
"merged_at": "2026-10-14T09:00:43Z",
|
||||
"head_sha": "b926c701f261995b6e1acabf277bbfdfa47829ca",
|
||||
"issue_body_ref": false,
|
||||
"issue_comment_refs": []
|
||||
},
|
||||
{
|
||||
"number": 545,
|
||||
"merged": true,
|
||||
"merge_sha": "c8eead49c5e68b2e295927c0e82cc57bcb04bad5",
|
||||
"merged_at": "2026-10-14T09:10:29Z",
|
||||
"head_sha": "00b35c5e6f5e0a0bc8072ff5c8c56378e6641d85",
|
||||
"issue_body_ref": false,
|
||||
"issue_comment_refs": []
|
||||
},
|
||||
{
|
||||
"number": 546,
|
||||
"merged": true,
|
||||
"merge_sha": "3538d40f45ad5a7c779426eb3322f79751db380c",
|
||||
"merged_at": "2026-10-14T09:40:57Z",
|
||||
"head_sha": "4a15fa0ceadf716fb93cc2966f099f3915b5f9d9",
|
||||
"issue_body_ref": false,
|
||||
"issue_comment_refs": []
|
||||
},
|
||||
{
|
||||
"number": 547,
|
||||
"merged": true,
|
||||
"merge_sha": "bcf225d0b981dcd69f8c736010c69b6a92d04341",
|
||||
"merged_at": "2026-10-14T09:53:34Z",
|
||||
"head_sha": "8522502e6e6db7a438a8f6fd391e1aa334c7a161",
|
||||
"issue_body_ref": false,
|
||||
"issue_comment_refs": []
|
||||
},
|
||||
{
|
||||
"number": 548,
|
||||
"merged": true,
|
||||
"merge_sha": "e1bc2602e18a89e4d75a4bf6cd80bc7f9b4d2164",
|
||||
"merged_at": "2026-10-14T10:05:47Z",
|
||||
"head_sha": "b89dd1c20ef4aa5c93a144f00e722a81dee87a50",
|
||||
"issue_body_ref": false,
|
||||
"issue_comment_refs": []
|
||||
}
|
||||
],
|
||||
"open_prs": [
|
||||
{
|
||||
"number": 512,
|
||||
"draft": true,
|
||||
"mergeable": false,
|
||||
"head_sha": "89125b8dda5f8f988a8a760ed64bf00827e1de5c",
|
||||
"base_sha": "e1bc2602e18a89e4d75a4bf6cd80bc7f9b4d2164",
|
||||
"title": "[WIP] Deliver progressive U2/U3 work with reliable sourced checkpoints"
|
||||
},
|
||||
{
|
||||
"number": 482,
|
||||
"draft": false,
|
||||
"mergeable": false,
|
||||
"head_sha": "d5e8d6ab7a368f08b29e968b6f65f8898f2b28f5",
|
||||
"base_sha": "e1bc2602e18a89e4d75a4bf6cd80bc7f9b4d2164",
|
||||
"title": "Pin the SQLite activity guard and document its refusals"
|
||||
}
|
||||
],
|
||||
"selected_runs": [
|
||||
{
|
||||
"run": 3088,
|
||||
"head_sha": "6463ef430640c56940b82776adb504ee272f030c",
|
||||
"status": "completed",
|
||||
"conclusion": "success",
|
||||
"started_at": "2026-10-14T07:02:04Z",
|
||||
"completed_at": "2026-10-14T07:09:41Z"
|
||||
},
|
||||
{
|
||||
"run": 3092,
|
||||
"head_sha": "889f64f88167a5314ebfa42a41f9c7a57f91b404",
|
||||
"status": "completed",
|
||||
"conclusion": "success",
|
||||
"started_at": "2026-10-14T07:49:37Z",
|
||||
"completed_at": "2026-10-14T07:58:00Z"
|
||||
},
|
||||
{
|
||||
"run": 3100,
|
||||
"head_sha": "7dd8d0f52ed930fbcabc05f5c4b1fb2b41b10bc5",
|
||||
"status": "completed",
|
||||
"conclusion": "success",
|
||||
"started_at": "2026-10-14T08:28:25Z",
|
||||
"completed_at": "2026-10-14T08:43:31Z"
|
||||
},
|
||||
{
|
||||
"run": 3107,
|
||||
"head_sha": "60d48e0580a36b2e6f93c77bb1edbe9bd0be342e",
|
||||
"status": "completed",
|
||||
"conclusion": "success",
|
||||
"started_at": "2026-10-14T08:33:36Z",
|
||||
"completed_at": "2026-10-14T08:45:31Z"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,51 @@
|
||||
# 合入调度首轮受控试行（2026-10-14）
|
||||
|
||||
状态：三个真实任务已由智能体依次合入；本报告记录 **manual** 模式的实际观察。是否扩大试行、调整预算或建设自动领取，仍待用户评审。依据为[已批准的实施计划](../proposals/2026-10-13-merge-queue-implementation-plan.md) U5–U6、[Dev 项目规则](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/src/branch/main/policy/merge-queue.md)和[唯一调度记录 #518](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/issues/518)。本报告不代表发布、部署或运行服务验收。
|
||||
|
||||
## 范围与证据口径
|
||||
|
||||
用户授权由当前智能体接管已有的 Dev #489、#488、#486，确认三者没有其他活动写者；所有实际 PR 合入由智能体执行。Dev `refs/heads/main` 的仓库 ID=29，协调者和窗口在 #518 登记。原任务 R0 各自不同，未伪称共同启动 SHA。组件先按自身目标交付，再固定 Dev 父仓组合；等待的 Dev 源分支没有随前一个正常合入反复同步、推最终候选或跑最终 CI。
|
||||
|
||||
证据分层：本机 `make evidence`、API 读取及隔离夹具输出是 **SELF**；`/root/merge_queue_review` 或 `/root/docs_delivery_review` 对固定对象的独立重放另记 **REPLAY**；Gitea Actions 的实际运行链接、作业身份和精确 SHA 才作为 **GATE**。原始 SELF 收据保存在各任务卡、#518 所指 `/tmp/mq-*` 路径及本轮私人状态目录；本文件只列对象、结论和索引，不转写命令输出。未执行的负例继续标 `NOT_RUN`。
|
||||
|
||||
平台前置使用用户亲手设置的私有夹具仓库 repoID38 `main` 保护规则。用户修正字段后，Root 只读回读六字段；隔离实测缺检查、失败检查、陈旧绿色候选、匿名请求及已认证绿色候选直推拒绝，合法固定候选由智能体合入。原始 SELF 收据和独立 REPLAY 索引在 #518。该夹具证明所测入口的拒绝/合法路径，不证明 Dev 所有角色、全部写者的机器隔离或旧执行者 fencing。Dev 三项业务检查仍须逐候选运行。
|
||||
|
||||
## 三个真实条目
|
||||
|
||||
| 顺序 | 原任务 R0 | 先行组件 | Dev 最终 base → head | 独立 Review 与当前 HEAD GATE | 实际合入 main |
|
||||
|---|---|---|---|---|---|
|
||||
| [#489](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/489) | `cd61bbb112eea6a210a64e84f2cef00b0d64bfc1` | [Documents #89](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/89) → `7bd4e17827d4c7c88647bf3c9199c495b60cb107` | `add097d06137c4912a4ed9279e98ca353e4e4cf1` → `5e6bf4aa0546d68fb3f872158f22b2791c301a60` | `/root/docs_delivery_review` PASS；[run 3038](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3038) 三作业成功 | `f00165e8d71e4dc8ba0ceb7dc50c1a8a3deb6d60` |
|
||||
| [#488](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/488) | `99048dda1f48bccb3d5d798050d7beeea2907177` | [Frontend #73](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Frontend/pulls/73) → `5313cfad4e633d0909ed40dcdfa28a11bc1902c0`；[RDM #301](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-RDM/pulls/301) → `ef5100a020abdd8ba8712c3d15c04c28bcac6e84` | `f00165e8d71e4dc8ba0ceb7dc50c1a8a3deb6d60` → `a70de2c54a74e175ad12c8d52ac29d0bafce9491` | `/root/merge_queue_review` PASS、隔离浏览器 7/7；[run 3050](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3050) 三作业成功 | `d852c159b6b3387a2f418a42ab6d3696ac873d01` |
|
||||
| [#486](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/486) | `4d362537d0e8755a03b1757b5bad92779a064b33` | [Backend #185](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Backend/pulls/185) → `8e80e2618eb7471dd12d5f172ff3cd23622b7d2f` | `d852c159b6b3387a2f418a42ab6d3696ac873d01` → `d805cc1697ae7f49d371a56a6a55191f00897b8c` | `/root/merge_queue_review` PASS；[run 3067](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3067) 三作业成功 | `05b997b84db26c517604c48d12676f0eb2b86e18` |
|
||||
|
||||
三个 Dev 合入都用固定 `head_commit_id`、`force_merge=false`，合入后从远端重新读取 PR/main 并核对完整 tree 与已审候选一致；组件 gitlink 没有回退。#489 首个合入响应后的本地指针统计出错，Root 先从 PR/main 重新对账再释放窗口，未重发合入请求。#488 的独立浏览器验收使用临时二进制/私有环境，未操作 live 服务。#486 的 U7 安全审阅先发现 B1–B7，Backend 在推最终源 HEAD 前修复并以隔离 PostgreSQL 真实交叠、跨进程、SIGTERM/SIGKILL 重放；Dev 最终组合继续通过本地 `make test`、隔离 PostgreSQL/Redis `make test-backend-pg` 和 `make build` 的 SELF 检查，GATE 另见表内 run 3067。
|
||||
|
||||
## 同步、CI、等待与恢复
|
||||
|
||||
每条 Dev 任务对其本轮最新目标仅发生一次真实纳入；固定后同基线 `task-sync` 核验不生成提交。#489 为纠正旧启动状态，在正式窗口前完成源码/组件整改与目标纳入；这与理想的“领取窗口后才第一次纳入”不同，不能抹去。#488、#486 都在领取最终窗口后才执行 `changed=1`，随后成功的固定 HEAD 检查为 `changed=0`。#486 一次无变更检查被嵌套 Git 的短暂 `index.lock` 拒绝，未删锁；持锁操作结束后原对象复核通过。原始失败和成功收据都在 #518。
|
||||
|
||||
| Dev PR | 目标纳入次数 | 固定后成功的无变更核验 | 本轮最终 PR CI | 作业运行时长（test / test-pg / svc-realcombo） | runner 等待 |
|
||||
|---|---:|---:|---|---|---|
|
||||
| #489 | 1（启动整改期） | 至少 3 次，均未改 HEAD | [3038](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3038)：1 次、3/3 成功 | 5:10 / 7:22 / 1:46 | 每作业 3 秒 |
|
||||
| #488 | 1（最终窗口） | 2 次，均未改 HEAD | [3050](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3050)：1 次、3/3 成功 | 5:12 / 8:42 / 1:54 | 每作业 3 秒 |
|
||||
| #486 | 1（最终窗口） | 1 次成功；另 1 次锁拒绝未推进 | [3067](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3067)：1 次、3/3 成功 | 5:01 / 7:19 / 1:54 | 每作业 3 秒 |
|
||||
|
||||
三次最终 PR CI 共 3 个 run、9 个必需作业，**因本轮正常排队任务移动 main 而废弃的最终 run 为 0**；没有拿旧绿色检查放行新 HEAD。合入后 main push CI 单列：[run 3040](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3040) 对 #489 合入树、[run 3053](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3053) 对 #488 合入树、[run 3068](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/3068) 对 #486 合入树，各自另有 3/3 作业成功；共 3 个 push run、9 个作业，不能省略这部分实际 CI 成本。3068 在 04:43:55Z 完成，精确对象为 `05b997b84db26c517604c48d12676f0eb2b86e18`。组件仓的 GATE/N/A 与 RDM #301 任务卡闭合 [PR #364](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-RDM/pulls/364) 的 CI 不计入上述 Dev 目标 run。
|
||||
|
||||
自 2026-10-12 起查询到三个 PR 另有 13 次**试行前开发** Actions run（#489 2、#488 7、#486 4；6 成功、7 失败），其对象与本轮最终候选不同；原始只读清单 `/tmp/mq-trial-ci-history-20261014.json`。这些运行既不能当本轮最终准入，也不能归因于本轮 main 移动。runner 作业等待时间以各 GATE job 的 `created_at`→`started_at` 计算；人的准备/依赖等待没有统一的入队就绪时间戳，本轮不填造净等待时长。仅可复核首次最终同步到合入的可观测下界：#489 19:49、#488 24:20、#486 18:46；它们含测试、Review 和平台等待，不等同完整窗口耗时。三条目均未重新领取最终目标窗口；启动整改、#488 的 E2E 夹具失败、#486 的一次锁拒绝分别保留，不计成 CI 废弃或窗口接管成功。
|
||||
|
||||
## 验收与下一步边界
|
||||
|
||||
| 验收 | 本轮结论 | 依据及限制 |
|
||||
|---|---|---|
|
||||
| MQ1 | 部分满足 | 三任务顺序合入且后继未提前最终同步；最终 CI 0 次因正常排队合入废弃。#489 的目标纳入发生在启动整改期，严格“领取后首同步”未由该例满足。 |
|
||||
| MQ2 | manual 已登记；原子互斥 `NOT_RUN` | 单协调者与目标窗口记录有效；重复领取的执行端拒绝及旧代次 fencing 未实现/未测。 |
|
||||
| MQ3 | 本轮通过 | 三个固定对象有同基线无变更核验；#486 短暂锁失败被拒绝且重验不改 HEAD。 |
|
||||
| MQ4 | 本轮通过 | 三个最终 HEAD 各跑实际新 CI；隔离夹具的陈旧绿色候选被拒。没有把组件/旧分支检查当父仓 GATE。 |
|
||||
| MQ5 | 部分满足 | #486 活动锁阻断并自行恢复，#489/#488 源码和夹具问题在固定前整改；人工超时释放及无依赖任务并行负例 `NOT_RUN`。 |
|
||||
| MQ6 | 部分满足 | 组件先合入，后继父仓保留其他能力；紧急插队导致候选失效的真实路径 `NOT_RUN`。 |
|
||||
| MQ7 | 部分满足 | #489 合入后本地异常先对账，未重复 POST；未知请求结果与旧执行者失联接管 `NOT_RUN`。 |
|
||||
| MQ8 | manual 范围通过 | 私有夹具正负例、Dev 精确 GATE 和合法智能体合入均有对象证据；全部角色/自动 fencing `NOT_RUN`。 |
|
||||
| MQ9 | 待文档 PR Review | 权威规范、Dev 采纳、调度记录、实际 PR/运行互相链接；本报告的最终交叉检查需随文档 PR 完成。 |
|
||||
|
||||
建议维持单协调者的 **manual** 模式，按目标串行领取，把组件准备与父仓最终 CI 分开。首次试行证明“等待分支不因正常合入反复重跑最终 CI”在这三项中成立；没有可比历史基线，**不报告节省百分比**。自动模式须另行建设并验证原子持久领取、执行端旧代次拒绝、角色覆盖和异常接管，不能从本轮人工遵约推导已具备。扩大试行与预算调整留待用户阶段评审决定；本报告不替代该决定。
|
||||
@@ -1,65 +0,0 @@
|
||||
# 项目设置完成性修复：接口与验证记录 r0.3
|
||||
|
||||
本记录承接已批准的 `../proposals/2026-10-13-rdm-settings-members-duties-perms-increment.md` r1 及 r1.1（两项阶段 4 修订于 2026-10-14 获用户评审通过，权威结论见该方案「评审结论」节），不改变 P1–P8 和 R1–R5 的交付范围。当前是阶段 7 输入的已批准候选，正式验收、发布、部署与清理均不由本记录代签。
|
||||
|
||||
修订：r0.3（2026-10-14）仅更新评审状态与阶段表述；r0.2 为受评接口记录版本，合同内容不变。
|
||||
|
||||
当前权限边界遵循已合入的 `../proposals/2026-10-13-iam-i1-permission-contract.md`：系统管理身份不代替业务成员、动作、资源或文档职责授权；停用角色不回落为无绑定默认。
|
||||
|
||||
## 恢复与完成性差距
|
||||
|
||||
恢复前共享检出只有 Documents/Guidelines 的已保存提交漂移。核对内部无未提交文件、detached HEAD、当前提交已在登记历史保存之后，恢复登记 gitlink、快进本任务收尾分支并物化新 Documents。随后 Dev 启动检查返回 READY，独立任务为 `feature/rdm-settings-completion`；初始主干 R0 是 `add097d06137c4912a4ed9279e98ca353e4e4cf1`。RDM 独立任务同名，初始 R0 是 `6fcb256205c2384abed35d3b6ab96ca7216e9297`。
|
||||
|
||||
旧任务的归档与通过叙述保留为历史。当前源码核对发现角色过滤、文档搜索/树、共享配置和模型/密钥其他覆盖入口缺项；旧接受脚本场景 9 没有执行检查、场景 10a 只比较 UI 默认值。这些内容不能证明原方案完整完成，新的验证必须检查真实动作和结果，不修改旧收据。
|
||||
|
||||
## P2 基座公开扩展申请与候选合同
|
||||
|
||||
场景：项目成员应读取同一业务配置；只有目标项目的合法配置者可以修改。个人在项目中的偏好仍须私有。
|
||||
|
||||
现有 `ResourceAuthorizerV2` 的公开合同只覆盖读取，不能将其复用为项目配置写授权。`ProjectLifecycle.Work` 是成员工作资格，不是配置资格。新增可选 `ProjectSettingsRegistry.RegisterProjectSettingsAuthorizer`；回调别名为 `func(context.Context, actor, projectID string, write bool) error`。主体和宿主项目 ID 由执行端解析，不能由请求自报；提供者必须与项目生命周期提供者一致，缺失或拒绝时失败关闭。
|
||||
|
||||
这是一项向后兼容的可选公开能力，候选扩展面为 `2.13.0-experimental`。RDM 以窄接口消费，不修改 `pins/`，不导入 Backend 私有包，不用反射或缓存的他人 Host 身份恢复授权。新基座发版与组合采用仍是完成条件；发版双钥匙由用户执行。
|
||||
|
||||
设置描述的归属词汇为 `system`、`user`、`project`、`project-personal`。空的旧插件 scope 仅保留个人兼容，不能推断共享策略资格。模型、运行参数、系统工具与插件目录属于系统；交付物默认样式等项目业务配置共享；主题、个人指令与跨会话个人开关不变成全员共享。
|
||||
|
||||
公共接口候选：
|
||||
|
||||
| 接口 | 合同 |
|
||||
|---|---|
|
||||
| `GET /api/settings` | 仅个人 schema/default/user |
|
||||
| `GET /api/settings?project=<宿主ID>` | 共享 schema/default/project、projectRevision、projectCanConfigure；个人项目偏好另列 personalSchema/personalDefaults/personalUser/personalProject |
|
||||
| `PUT /api/settings/project/<宿主ID>` | `{values,expectedRevision,unset?}`；只更新明确变更的项目叶子，旧版本 409 |
|
||||
| `PUT /api/settings/project/<宿主ID>/personal` | 私有合并补丁；声明的非秘密叶子 null 表示移除覆盖 |
|
||||
| `GET /api/settings/system` | 系统 schema/default/system、systemRevision；管理员保护 |
|
||||
| `PUT /api/settings/system` | `{values,expectedRevision,unset?}`；管理员保护与版本比较 |
|
||||
| `PUT /api/settings/user` | 个人合并补丁；声明的非秘密叶子 null 表示移除覆盖 |
|
||||
|
||||
`unset` 只接受当前作用域已声明的非秘密叶子；父路径、未知路径、内部策略、重复或与 values 重叠的路径拒绝。未修改的掩码不提交；秘密撤销显式写空字符串，不能通过移除让旧部署凭据恢复。画像模型路由、个人服务密钥、环境 AuthRef 与所有运行解析同样受系统边界约束。
|
||||
|
||||
## P3/P4/P6 领域合同
|
||||
|
||||
人员检索共用 query/match/roleId/projectRole/cursor/limit；姓名缺失回退账号，重名使用稳定账号区分，过滤后分页。`rdm.role.options` 仅返回有资格使用的角色名称和 ID，不下发全部绑定账号或权限上限。
|
||||
|
||||
成员目录返回当前成员的姓名、有效性、专业角色及请求者的实际管理能力。缺失账号目录时有效性是未知，不伪造有效。职责资格还须对应动作的上限；专业角色筛选不授予身份或职责。
|
||||
|
||||
文档目录/树共用同一受授权裁剪的检索结果；仅文档节点可提交 docId。当前职责与冻结名单分别返回。文档、章节和批量写入均要求 expectedDutyVersion，实际作废在途审签还要求 confirmInvalidation；无版本、缺账号校验或不合资格的旧命令同样拒绝。变更、作废、事件全成或全败，历史名单保留。
|
||||
|
||||
章节沿用文档默认职责时，`expectedDutyVersion` 的有效值随文档默认版本变化；单独指派后则随章节版本变化。当前只读与写入使用同一数值：继承为 `2 × 文档职责版本`，覆盖为 `2 × 章节职责版本 + 1`，两类数值互不混淆。该值由事件重放结果计算，不迁改既有职责或历史审签。原始版本继续保存在领域事件中；客户端必须读取当前职责，不能假定新章节版本恒为 0。
|
||||
|
||||
成员移除先读取 `rdm.project.member.impact`，只给该成员职责关系的必要元数据；没有正文或职责目录权限不因此获得全项目目录。实际移除重新检查影响与最后负责人，并与成员删除/事件写入同事务。
|
||||
|
||||
项目权限只返回项目动作；系统创建权限不混入项目矩阵或项目覆盖。解释返回 defaultAllowed/capAllowed/override 与可读来源/原因；控制组件消费请求者真实能力，不从被查询成员身份推算。项目动作允许不代表任意文档读取或签字资格。
|
||||
|
||||
## P8 迁移与验证边界
|
||||
|
||||
迁移清单只返回来源、路径与状态，不返回秘密值或摘要。旧表没有逐键更新时间，不能伪造“最近写入”权威；冲突必须明确裁定。显式预览选择生成受保护、绑定主体与项目的观察记录，应用时重新鉴权、核对来源与目标版本、保留旧行、原子写目标与结果；相同观察重试幂等。系统迁移只采用管理员明确提供的新值，不自动提升他人的私有凭据。
|
||||
|
||||
配置来源/目标在同一存储事务中检查；跨数据库的身份与业务授权回调在进入操作时独立核验，不声称它们属于同一个 SQL 事务。模板的实际使用仍重验实时资源授权。
|
||||
|
||||
隔离 PostgreSQL 自检复现了两个实例之间的旧职责覆盖、移除新职责人员，以及两个进程同时降级负责人。RDM 项目写事务读取同一个可序列化数据库快照中的领域事件和成员策略；序列化冲突返回错误，客户端重读状态，不盲目重试写入。此处只证明对应隔离用例，不能推断所有跨数据库状态已原子化。
|
||||
|
||||
验证包含领域/公共契约红测、SQLite/PostgreSQL 事务和竞争、真实 React 浏览器机制、隔离实例完整行为、Core/UI/Frontend/Backend/RDM 精确组合。mock/接口 fixture 只证明相应机制，不能替代真实组合、模型任务级证据、正式验收或当前 HEAD CI。
|
||||
|
||||
实施与自检的实际对象、命令、输出及剩余项维护在 Dev/RDM 同名任务卡和源码外原始收据；本记录不手抄命令输出、不提升 SELF 为 REPLAY/GATE。未执行的正式验证保持 NOT_RUN。
|
||||
|
||||
本轮旧验收脚本的首次实施前 RED 曾在两项负例中对默认 8788 使用测试身份尝试准备流程；旧脚本没有保存各请求响应码，因此是否发生写入无法由该次收据确认。原始收据保留在 `/tmp/rdm-settings-acceptance-red-20261014.json`。新验证入口要求显式隔离地址、保护文件和有效真实文档，不把请求失败或未执行的浏览器场景报告为通过；隔离业务实例的完整运行仍待后续固定组合。
|
||||
Reference in New Issue
Block a user