Document unified renderer architecture and delivery plan

Why: Define the approved direction for one rule-driven Word renderer, all-template onboarding, human-readable traceability, and review-aware delivery before implementation starts. Evidence: SELF documentation checks passed for relative links, balanced code fences, JSON parsing, manifest SHA256 coverage, and git diff whitespace. Impact: Adds a 12-document review set and immutable review manifest; no runtime code, migration, deployment, or published rule changes. Refs: feature/rdm-two-trees-latest-templates
2026-10-15 09:23:44 +00:00
parent af5093dbd7
commit 647da98577
13 changed files with 1399 additions and 0 deletions
@@ -0,0 +1,93 @@
+# 01 需求与范围
+
+## 1. 用户目标
+
+成员和智能体能够以 Markdown 编制公司项目文档，由系统根据声明式渲染规则生成 Word。文档可使用专用公司模板，也可在未指定专用模板时使用公司通用规则。用户可以下载 Markdown、Word 或包含全部交付物的归档包。
+
+渲染结果不是一次性文件，而是 2 树 1 网的一部分：文档树保存文档、章节、小节和段落；笔记树保存对话、文件、网络搜索和工具结果等依据；追溯网连接内容节点、来源、修订、批注、审签决定、规则版本和最终文件。
+
+## 2. 第一阶段范围
+
+- 统一文档模型和 Markdown 解析。
+- 声明式 RenderProfile schema、校验器、注册表和版本生命周期。
+- Word 格式适配器。
+- 公司通用 Word 规则包。
+- 44 份现有模板的规则包及受控资产绑定。
+- 文档实例级规则选择及四级回退策略。
+- 工作稿、预览稿、批准稿和审阅留痕稿。
+- Markdown、DOCX、清单及归档包下载。
+- Word 书签/内容控件与文档树节点的双向锚定。
+- 规则预览、发布、退役、升级提案和回滚。
+- SQLite 与 PostgreSQL 的规则、版本和交付物持久化。
+- 真实浏览器中的选择规则、预览、审阅和下载流程。
+
+## 3. 后续范围
+
+后续格式适配器消费同一 `CanonicalDocument`：
+
+- PDF：固定版式发布和打印交付。
+- PPT：按幻灯片规则映射章节、图表和演讲者备注。
+- 用户上传参考文档，智能体分析后生成候选 RenderProfile。
+
+后续功能必须沿用本阶段的规则审查、预览、发布和权限生命周期。上传参考文档不会直接生成已发布规则。
+
+## 4. 角色
+
+| 角色 | 权限与职责 |
+|---|---|
+| 文档编制人 | 编辑 Markdown、选择允许的规则、生成工作稿和提交审阅 |
+| 审阅人 | 查看来源和差异、添加批注、提出修改或通过审阅 |
+| 批准人 | 对冻结提交作最终决定，批准后生成批准稿 |
+| 项目创建者/授权管理员 | 管理项目默认规则和项目内可用规则 |
+| 系统管理员 | 发布公司规则、受控资产和格式适配器 |
+| 普通项目成员 | 按项目内容权限查看和下载文档；无审计权时不见审计信息 |
+| 智能体 | 生成 Markdown 候选、提出规则选择和结构映射；不得伪造审签或发布规则 |
+
+## 5. 功能要求
+
+### 5.1 规则选择
+
+选择顺序固定为：
+
+1. 文档实例显式绑定的 `profileId@version`。
+2. 文档类型的已发布默认规则。
+3. 项目已发布默认规则。
+4. 公司通用 Word 规则。
+
+受控文档一旦声明专用模板，任何缺包、失配、退役或必填字段缺失都必须阻止生成，不进入第 3 或第 4 级回退。
+
+### 5.2 双格式与清单
+
+每次交付至少包含：
+
+- `document.md`
+- `preview.docx`、`approved.docx` 或 `review.docx` 中的适用文件
+- `manifest.json`
+
+清单记录内容哈希、规则和模板版本、资产哈希、生成主体、生成时间、审签轮次、输出哈希、诊断结果及文档树根节点。
+
+### 5.3 可追溯性
+
+每个可渲染内容节点必须有稳定 `nodeId`。Markdown 解析范围、DOCX 书签/内容控件、来源引用、内容版本、批注和交付物均绑定该 ID。仅靠标题或段落顺序不得作为稳定身份。
+
+### 5.4 审阅和批准
+
+系统分别保存内容版本、批注和审签决定。批准稿接受已批准修订并隐藏普通批注；审阅留痕稿保留修订、批注、回复及解决状态。签署区只读取可信审签数据。
+
+## 6. 非功能要求
+
+- 确定性：同一 Markdown、元数据、规则版本和资产生成相同有效内容；时间戳等非确定字段必须来自冻结提交。
+- 安全：规则不含脚本、宏、外部 URL 运行、任意 OOXML 或任意文件路径。
+- 隔离：规则执行无网络，资产只从已验证包读取，输出写入限定目录。
+- 兼容：未知规则版本、未知节点、旧二进制或新 schema 均 fail-closed。
+- 性能：普通 100 页以内文档在交互预览预算内完成；大文档进入后台任务并显示进度。
+- 可解释：失败返回具体字段、规则路径、文档节点和修复建议。
+
+## 7. 完成判据
+
+- 44/44 模板在适用项目中完成“Markdown→预览→审阅→批准→批准稿/留痕稿→下载”的逐项验证；当前两个字典阻塞清零。
+- 公司通用规则可生成无专用模板的普通文档。
+- Markdown 与所有 Word 输出均可下载，清单中的哈希可复核。
+- 页眉、页脚、页码、文件控制字段、Logo、标题、表格及签署区符合已批准规范。
+- 私人来源和无权批注不进入共享文件。
+- 规则升级不改变旧批准文件，旧版本仍可重放生成或取回冻结字节。
@@ -0,0 +1,141 @@
+# 02 总体架构与方案
+
+## 1. 推荐架构
+
+采用“统一内容模型＋统一渲染内核＋格式适配器＋版本化规则包”。第一阶段提供 Word 适配器，后续 PPT/PDF 不改变上游内容和规则生命周期。
+
+本方案建议把渲染内核放入独立的 `Agent-Document-Renderer` Go 模块。该模块边界是本次待评审的架构决策；在评审通过和任务启动门禁完成前，不创建新仓库、不改变现有模块 pin，也不迁移现有生产路径。若评审决定先以内嵌包落地，公开接口、依赖方向和后续独立化条件仍须保持与本文一致。
+
+```text
+Markdown + metadata + source links
+              │
+              ▼
+      MarkdownParser
+              │
+              ▼
+      CanonicalDocument
+              │
+      ProfileResolver
+              │
+              ▼
+        RenderProfile
+              │
+      DocumentRenderer
+              │
+              ▼
+       WordAdapter v1
+              │
+      ┌───────┼────────┐
+      ▼       ▼        ▼
+  DOCX bytes  diagnostics manifest
+```
+
+## 2. 模块边界
+
+### 2.1 CanonicalDocument
+
+格式无关的不可变输入，包括：
+
+- 文档身份、标题、语言、项目和文档类型。
+- `section/heading/paragraph/list/table/image/callout/attachment/signature` 节点。
+- 稳定节点 ID、层级、文本、样式意图和数据类型。
+- 来源引用、置信度、可见范围和内容版本。
+- 批注、修订集合和审签快照引用。
+
+Markdown 只负责表达内容；页面、字体、Word 样式名和 OOXML 不进入内容模型。
+
+### 2.2 RenderProfileRegistry
+
+保存规则包元数据、版本、适用范围、状态、资产和 schema 版本。职责：
+
+- 精确解析 `profileId@version`。
+- 执行四级规则选择。
+- 验证文档类型、项目范围、发布状态和资产哈希。
+- 返回不可变规则快照。
+
+### 2.3 DocumentRenderer
+
+格式无关调度器：验证输入、解析规则、构建渲染计划、调用格式适配器、运行输出校验并生成清单。它不读项目数据库、不判断用户权限、不访问网络。
+
+### 2.4 WordAdapter
+
+唯一允许操作 Word 包结构的模块。负责样式、编号、分节、表格、页眉页脚、图片、书签、内容控件、批注、修订、签署区和 OPC 完整性。
+
+### 2.5 RDM 编排层
+
+RDM 负责项目权限、文档树、审签、规则选择、冻结提交、交付物保存和追溯关系。它把已经授权和冻结的输入交给渲染器，不让渲染器反查项目数据。
+
+### 2.6 Backend 工作区交付
+
+普通会话交付使用同一公开渲染入口：先保存 Markdown，再提交受限的 RenderRequest。现有 `house-style` 能力逐步迁移为公司通用规则包和 WordAdapter，不维持第二套独立语义。
+
+## 3. 关键接口
+
+```go
+type RenderRequest struct {
+    Document       CanonicalDocument
+    Profile        RenderProfileSnapshot
+    Review         ReviewSnapshot
+    Mode           RenderMode
+    FrozenAt       time.Time
+    RequestedBy    string
+}
+
+type RenderResult struct {
+    Artifact       []byte
+    MIME           string
+    FileName       string
+    Manifest       RenderManifest
+    Diagnostics    []Diagnostic
+}
+
+type Renderer interface {
+    Validate(context.Context, RenderRequest) ([]Diagnostic, error)
+    Render(context.Context, RenderRequest) (RenderResult, error)
+}
+```
+
+`RenderMode` 第一阶段固定为 `working`、`preview`、`review`、`approved`。
+
+## 4. 生成流程
+
+1. RDM 冻结 Markdown 版本、节点映射、来源和审签状态。
+2. ProfileResolver 选择确切规则；受控文档不存在确切规则则失败。
+3. Parser 生成 CanonicalDocument，并验证稳定节点 ID。
+4. Renderer 编译声明式规则为 RenderPlan。
+5. WordAdapter 克隆受控模板包或公司通用底稿。
+6. 按 RenderPlan 写入内容和受控元数据。
+7. 运行 OPC、样式、锚点、字段、回读和安全校验。
+8. 保存字节、清单、诊断和追溯边。
+
+## 5. 确定性与缓存
+
+缓存键：
+
+```text
+SHA256(
+  canonicalDocumentHash ||
+  renderProfileSnapshotHash ||
+  reviewSnapshotHash ||
+  renderMode ||
+  adapterVersion
+)
+```
+
+相同键返回同一冻结交付物。规则发布、内容修改、审签变化或适配器升级会形成新键，不覆盖旧文件。
+
+## 6. 失败策略
+
+- `profile_not_found`：无确切规则。
+- `profile_not_published`：规则未发布或已退役。
+- `asset_hash_mismatch`：模板、Logo、字体或图片资产漂移。
+- `required_field_missing`：文件号、版本或规则必填元数据缺失。
+- `mapping_unresolved`：Markdown 节点不能映射到模板槽位。
+- `review_state_invalid`：导出模式与审签状态不匹配。
+- `word_validation_failed`：DOCX 包、样式、锚点或回读失败。
+
+错误不得触发受控文档向默认规则回退。
+
+## 7. 扩展格式
+
+后续 `PdfAdapter` 和 `PptAdapter` 只消费 CanonicalDocument 与各自 RenderProfile format section。跨格式共用来源、权限、版本、审签和清单；格式特有能力由适配器声明 capability，规则引用未知 capability 时拒绝发布。
@@ -0,0 +1,151 @@
+# 03 RenderProfile 渲染规则规范
+
+## 1. 安全模型
+
+RenderProfile 是声明式数据，不是程序。禁止：
+
+- Shell、Python、JavaScript、VBA 或宏。
+- 任意 OOXML、HTML 或 XML 注入。
+- 外部 URL 下载及运行时网络请求。
+- 绝对路径、父目录跳转和未登记资产。
+- 动态反射、表达式求值和任意函数调用。
+
+复杂能力必须先作为渲染器中经过测试的安全原语发布，规则只能按名称引用。
+
+## 2. 顶层结构
+
+```yaml
+schemaVersion: render-profile/v1
+profileId: company.dhf.project-proposal
+version: 1.0.0
+format: docx
+state: published
+appliesTo:
+  documentTypes: [rd_proposal]
+  stages: [RD]
+baseTemplate:
+  assetId: dhf.2750fbaf1f67d10c
+  assetVersion: 1.0.0
+  sha256: <64-hex>
+assets:
+  logo: company.logo.primary@1
+selection:
+  controlled: true
+  allowDefaultFallback: false
+page: {}
+styles: {}
+numbering: {}
+headers: []
+footers: []
+mappings: []
+review: {}
+validation: {}
+```
+
+实际发布对象必须存规范化 JSON 和 SHA256；YAML 仅作为人工编辑输入。
+
+## 3. 规则选择
+
+每个文档实例保存：
+
+```json
+{
+  "profileId": "company.dhf.project-proposal",
+  "profileVersion": "1.0.0",
+  "selectionSource": "document-explicit",
+  "snapshotHash": "..."
+}
+```
+
+优先级：`document-explicit > document-type > project-default > organization-default`。`controlled=true` 时 `allowDefaultFallback` 必须为 false。
+
+## 4. 页面与样式
+
+`page` 支持固定安全字段：纸张、方向、页边距、装订线、分节、首页不同、奇偶页不同。
+
+`styles` 以语义样式为键：
+
+- `documentTitle`
+- `heading1` 至 `heading6`
+- `body`
+- `caption`
+- `quote`
+- `warning`
+- `tableHeader`
+- `tableBody`
+- `signature`
+
+每个样式只允许字体族、字号、粗斜体、颜色令牌、对齐、缩进、行距、段间距、分页约束及 Word style name。
+
+## 5. 映射规则
+
+```yaml
+mappings:
+  - selector:
+      nodeKind: section
+      semantic: purpose
+    target:
+      kind: content-control
+      part: word/document.xml
+      anchor: purpose
+    render:
+      primitive: paragraphs
+      empty: block
+```
+
+选择器只能基于规范字段：节点 ID、节点类型、语义、标签、文档路径。目标只能引用已在模板包清单登记的书签、内容控件、表格行、页眉页脚字段或图片槽位。
+
+## 6. 表格与重复块
+
+表格原语支持：列宽、表头重复、对齐、边框、底色、单元格跨度、行禁止跨页、重复行模板及空值策略。合并单元格由规则明确声明，不从 Markdown 空单元格猜测。
+
+```yaml
+render:
+  primitive: repeat-table-row
+  rowAnchor: risk-row
+  columns:
+    risk: risk.statement
+    cause: risk.cause
+    control: risk.control
+```
+
+## 7. 页眉页脚和公司资产
+
+页眉页脚规则区分：
+
+- `fixed`：机密声明、公司名称、静态标签。
+- `field`：PAGE、NUMPAGES、日期等 Word 字段。
+- `slot`：文件号、版本、项目名称等实例数据。
+- `asset`：Logo、认证标志和受控图片。
+
+Logo 必须引用资产注册表中的版本化对象，不允许规则携带 data URL 或任意文件。
+
+## 8. 审阅配置
+
+```yaml
+review:
+  trackChanges: supported
+  comments: supported
+  commentReplies: supported
+  approvedOutput: accept-all
+  reviewOutput: preserve
+  signatureBindings:
+    author: document.author
+    reviewer: submission.reviewers
+    approver: submission.approver
+    decidedAt: submission.decidedAt
+```
+
+真实身份字段来自 ReviewSnapshot。规则只能决定显示位置和格式，不能提供值。
+
+## 9. 校验规则
+
+发布前校验：schema、能力、资产哈希、模板锚点唯一性、样式引用、循环上限、映射覆盖和安全字段。
+
+生成前校验：文档类型、必填元数据、节点映射、审签状态和可见范围。
+
+生成后校验：ZIP/OPC、XML、安全对象、样式、页眉页脚、书签、批注关系、修订关系、字段、回读结构和输出哈希。
+
+## 10. 生命周期
+
+`draft → validated → published → retired`。只有系统管理员可发布公司规则；项目创建者可选择已发布规则或管理项目默认绑定。发布对象不可修改，退役不删除旧资产和旧交付物。
@@ -0,0 +1,72 @@
+# 04 公司 Word 设计规范
+
+## 1. 目的
+
+本规范定义公司通用 Word 输出的统一设计，并规定专用受控模板与公司通用规则之间的关系。专用模板可声明经过评审的例外；没有例外时继承公司规范。
+
+## 2. 当前已证实的模板共性
+
+- 41/44 存在页眉或页脚部件。
+- 40 份包含文件名称、文件号、版本等文件控制字段。
+- 已识别 78 个文件号/版本槽位。
+- 企业机密声明和自动页码域属于固定版式。
+- 部分模板包含表格编号、复杂合并、重复行、签署区和旧 DOC 转换差异。
+- 统一 Logo、主题字体、封面系统、色板和全部标题层级尚无经过逐模板审核的统一结论，不能依据局部样本直接定为公司标准。
+
+## 3. 视觉普查产物
+
+实施第一项生成 `CorporateStyleInventory`，对 44 份模板逐项记录：
+
+- 页面尺寸、方向、页边距、分节、首页及奇偶页规则。
+- 中文/西文字体、字号、字重、颜色、行距和段间距。
+- 标题层级、编号、多级列表和目录。
+- 表格边框、底色、列宽、合并、表头重复和跨页规则。
+- 页眉页脚文本、字段、控制表及位置。
+- Logo、图片、形状、OLE、关系和裁剪尺寸。
+- 封面、签署区、版本记录和文件控制表。
+- 专用模板例外及证据截图/部件锚点。
+
+每项标记 `common`、`family-rule`、`template-exception` 或 `unverified`。`unverified` 不进入已发布公司规则。
+
+## 4. 公司通用规则结构
+
+通用规则最终必须明确下列值并经视觉评审后发布：
+
+- A4 纵向为普通文档默认页面；横向表格由显式分节规则启用。
+- 正文、标题、表格、题注、引用、警示和代码的语义样式。
+- 标题编号与目录层级。
+- 公司 Logo 的版本化资产、最小尺寸、留白和允许位置。
+- 页眉中的公司/文件身份信息。
+- 页脚中的机密声明、页码和总页数。
+- 文件名称、文件号、版本、发布日期和状态的控制表。
+- 图片题注、表格题注、交叉引用和分页规则。
+
+本文不预填尚未审核的具体字体、字号、Logo 文件或颜色值；这些值由 `CorporateStyleInventory` 的人工评审结果写入首个发布规则，而不是在代码中硬编码。
+
+## 5. 专用模板继承
+
+每个模板配置包声明：
+
+```text
+company common profile
+    └── document family profile
+          └── exact template exceptions
+```
+
+继承在规则发布时展开并冻结成完整快照；运行时不动态追随父规则。父规则升级不会改变已发布子规则。
+
+## 6. 内容设计原则
+
+- 一页只承担清晰的信息任务，避免纯装饰元素。
+- 标题层级由文档结构决定，不以字号模拟层级。
+- 表格用于对比和结构化数据，不用空表格模拟页面布局；专用受控模板例外需登记。
+- 颜色不作为唯一状态提示。
+- 图片必须有题注、来源和替代说明。
+- 空缺、冲突、未核实和待确认内容不得伪装成正式结论。
+- 审阅稿可以显示提示和批注，批准稿只显示已批准内容及正式控制信息。
+
+## 7. 保真与例外
+
+旧 DOC 以原件保全、转换件、规范化件和渲染件四层身份管理。转换导致的图形、字体或分页差异必须列入模板例外；不能以“能够打开”替代视觉保真结论。
+
+专用模板的固定表格、签署区和监管格式优先于通用视觉偏好，但必须继续满足可读性、来源和审签真实性要求。
@@ -0,0 +1,104 @@
+# 05 生命周期与流程
+
+## 1. 文档生命周期
+
+```text
+source-md draft
+  → render preview
+  → submit review
+  → reviewer comments / tracked changes
+  → author revision
+  → review accepted
+  → approval decision
+  → approved + review artifacts frozen
+  → superseded or retired by explicit change
+```
+
+文档内容、渲染规则和审签轮次是三个独立版本维度。任何一个变化都会生成新的 RenderRequest 和交付物，不覆盖先前批准文件。
+
+## 2. 起草流程
+
+1. 成员或智能体创建 Markdown 候选。
+2. 系统为标题、段落、表格等节点分配稳定 ID。
+3. 来源材料进入笔记树，内容节点进入文档树，来源边进入追溯网。
+4. ProfileResolver 根据四级优先级选择规则并显示选择原因。
+5. 生成前检查必填字段、映射、来源权限和风险。
+6. WordAdapter 生成预览稿和诊断。
+7. 用户在阅读器和 Word 预览中检查内容与版式。
+
+## 3. 提交审阅
+
+提交动作冻结：
+
+- Markdown 内容版本及哈希。
+- CanonicalDocument 哈希。
+- RenderProfile 快照及哈希。
+- 模板和资产哈希。
+- 文档树节点集合。
+- 来源可见范围。
+- 编制、审阅和批准职责。
+
+冻结后发生的新编辑进入下一草稿，不改变本轮审阅对象。
+
+## 4. 审阅循环
+
+审阅人可以：
+
+- 对节点或文本范围添加批注。
+- 回复批注。
+- 提出插入、删除、替换或移动建议。
+- 将批注标记为已处理、拒绝或仍待处理。
+- 退回修改或通过审阅。
+
+编制人处理建议时形成新内容版本；系统保留修改前后、操作者、时间、原因、批注和来源关系。重新提交生成新审阅轮次或同轮修订，具体由项目策略配置，但不得覆盖旧修订。
+
+## 5. 批准和双 Word 交付
+
+批准人只能批准已经通过必需审阅、没有阻塞项且规则校验成功的冻结对象。批准事务完成后生成：
+
+- 干净批准稿：接受已批准修订，显示正式文件控制和签署信息。
+- 审阅留痕稿：保留修订、批注、回复、作者和时间。
+- Markdown 源文件。
+- 生成清单。
+
+输出生成失败时批准决定仍保留，但交付状态为 `generation-failed`，不得伪装成已经交付；修复渲染问题后以同一冻结输入幂等重试。
+
+## 6. 规则升级流程
+
+1. 提出规则升级提案，绑定旧规则、新规则、示例文档和影响分析。
+2. 生成新旧规则对照预览和诊断差异。
+3. 人工确认后发布新规则版本。
+4. 新文档默认使用新版本。
+5. 已有草稿可以显式升级；批准文档不自动升级。
+6. 升级后的文档重新进入审阅与批准。
+
+## 7. 默认规则流程
+
+普通文档未绑定专用规则时使用公司通用规则。系统必须在 UI 和清单中显示“公司通用规则”，不能让用户误认为采用了某个专用受控模板。
+
+## 8. 用户上传参考文档生成规则（后续）
+
+```text
+上传原件
+ → 安全解析与原件保全
+ → 样式/结构/资产分析
+ → 生成候选规则与识别报告
+ → 样例 Markdown 预览
+ → 人工对照和修正规则
+ → 自动校验
+ → 管理员发布
+```
+
+候选规则始终是 `draft`。模型分析结果附置信度和未识别项；宏、外链、嵌入对象和未知 XML 明确隔离。没有人工评审和校验不得进入 `published`。
+
+## 9. 下载体验
+
+用户可选择：
+
+- 下载 Markdown。
+- 下载当前 Word。
+- 下载批准稿。
+- 下载审阅留痕稿。
+- 下载全部交付包。
+
+下载前重新检查当前权限。已撤权用户不能凭旧链接继续下载；历史交付物字节不因撤权而改变。
@@ -0,0 +1,113 @@
+# 06 修订、批注与审签设计
+
+## 1. 独立数据模型
+
+Markdown 正文不嵌入 Word 批注语法。系统保存独立对象：
+
+```go
+type Annotation struct {
+    ID           string
+    DocumentID   string
+    NodeID       string
+    Range        TextRange
+    Author       ActorSnapshot
+    BodyMarkdown string
+    CreatedAt    time.Time
+    State        string // open|resolved|rejected
+    ParentID     string // reply
+}
+
+type Revision struct {
+    ID         string
+    NodeID     string
+    Kind       string // insert|delete|replace|move
+    BeforeHash string
+    AfterHash  string
+    Actor      ActorSnapshot
+    At         time.Time
+    Reason     string
+}
+
+type ApprovalSnapshot struct {
+    SubmissionID string
+    Author       ActorSnapshot
+    Reviewers    []DecisionSnapshot
+    Approver     DecisionSnapshot
+    DecidedAt    time.Time
+}
+```
+
+`ActorSnapshot` 保存当时显示名、账号稳定 ID、项目职责及可信身份来源。当前改名不重写历史。
+
+## 2. 锚定方式
+
+批注优先绑定稳定 `nodeId + textStart + textEnd + textHash`。节点内容变化后：
+
+- 哈希和范围仍匹配：保持精确锚点。
+- 节点存在但范围漂移：标记 `needs-reanchor`，显示旧摘录。
+- 节点删除：保留孤立批注并指向删除修订。
+
+不得只用段落序号绑定。
+
+## 3. Word 映射
+
+WordAdapter 负责：
+
+- `w:ins`、`w:del` 及作者/时间属性。
+- `comments.xml`、批注范围、批注引用及关系。
+- 支持的批注回复模型。
+- `trackRevisions` 设置。
+- 节点书签与内容控件。
+
+Word 内作者、时间和审批字段只来自 ReviewSnapshot；模板示例、模型输出或请求参数不能覆盖。
+
+## 4. 工作稿
+
+工作稿可以显示：
+
+- 未解决批注。
+- 缺项、冲突和未核实来源提示。
+- 当前草稿修订。
+- 非正式水印或状态标志。
+
+工作稿不能显示批准签署，文件控制状态必须为草稿。
+
+## 5. 审阅留痕稿
+
+审阅留痕稿包含：
+
+- 相对于本轮基线的全部受支持修订。
+- 批注、回复和解决状态。
+- 作者、审阅人和时间。
+- 审阅决定摘要。
+- 版本差异附录及来源引用。
+
+无权查看的私人来源正文不写入文件；只显示“存在受限依据”及允许披露的摘要。
+
+## 6. 批准稿
+
+批准稿默认接受全部已批准修订并隐藏普通批注。它包含：
+
+- 干净正文。
+- 文件名称、文件号、版本和批准日期。
+- 真实编制、审核、批准信息。
+- 模板/规则身份及必要的文件控制记录。
+
+如监管流程要求保留批注意见，必须由专用规则明确映射到批准记录附录，不能直接携带私人批注线程。
+
+## 7. 双 Word 交付
+
+一次批准产生两个独立工件及哈希：
+
+- `approved.docx`
+- `review.docx`
+
+两个文件绑定同一 SubmissionID、内容版本和规则快照。清单说明模式差异，避免将留痕稿误当批准稿。
+
+## 8. 验证
+
+- 打开 Word 后修订作者、时间、插入和删除可见。
+- 批注范围准确，回复关系完整。
+- 接受全部修订后正文与批准稿一致。
+- 批准稿不含未授权批注、私人对话或模型隐藏分析。
+- 没有真实审签数据时签署区为空且生成批准稿被阻止。
@@ -0,0 +1,76 @@
+# 07 权限、安全与审计
+
+## 1. 权限分层
+
+| 能力 | 最小权限 |
+|---|---|
+| 查看 Markdown/Word | 当前文档读取权限 |
+| 生成工作稿 | 文档编制权限 |
+| 添加批注 | 审阅参与权限及节点可见性 |
+| 提交审阅 | 当前编制职责 |
+| 审阅通过/退回 | 冻结轮次中的审阅职责 |
+| 批准 | 冻结轮次中的批准职责 |
+| 选择项目默认规则 | 项目设置权限 |
+| 发布公司规则 | 系统管理员 |
+| 查看渲染审计 | `audit.read` 加对象内容权限 |
+
+项目成员身份不等于所有内容、私人来源或审计权限。
+
+## 2. RenderProfile 安全边界
+
+- schema 白名单字段。
+- 资产路径必须来自包内清单且通过 SHA256。
+- 不执行脚本、宏、外部关系和任意 XML。
+- ZIP 解压限制文件数、单文件大小和总展开大小。
+- 拒绝 ActiveX、OLE、VBA、远程模板和未知可执行关系。
+- 图片解码、字体和 XML 解析设置资源上限。
+- 渲染执行无网络，输出只写会话或交付目录。
+
+## 3. 用户上传参考文档
+
+上传后立即保全原字节和哈希。分析在隔离进程中进行；任何宏、外链、嵌入对象或损坏部件列入报告。生成的候选规则不继承上传文件的代码、宏或外部关系。
+
+候选规则发布需要：原件权限、来源声明、分析报告、预览对照、自动校验及管理员决定。
+
+## 4. 私域与共享输出
+
+渲染请求逐节点计算披露权限：
+
+- 公开项目事实可进入项目文档。
+- 私人对话、个人草稿和未分享原件默认不进入共享输出。
+- 受限来源可以贡献经授权的结论，但文件中只显示允许披露的引用。
+- 审阅留痕稿同样执行权限裁剪，不能因为“审计”而绕过正文权限。
+
+个人对话生成的思维导图、流程图和解释卡片只属于本人会话；分享必须是单独明确操作。
+
+## 5. 审签真实性
+
+- 请求参数不能提交 `approvedBy`、`confirmed` 或签名图片来冒充决定。
+- 审核、批准和签署区读取冻结审签记录。
+- 决定绑定用户、项目、文档、SubmissionID、内容哈希和规则快照。
+- 同一决定证明一次消费；重试返回原交付回执。
+- 撤权、职责变化、过期或规则漂移在提交前重新检查。
+
+## 6. 审计事件
+
+至少记录：
+
+- Markdown 创建、修改和版本冻结。
+- 规则选择及选择来源。
+- 渲染请求、诊断、成功、失败和重试。
+- 预览、下载和归档包下载。
+- 批注创建、回复、解决和删除。
+- 修订接受或拒绝。
+- 提交、审阅、批准和退回。
+- 规则创建、验证、发布、退役和升级。
+- 模板、Logo 和其他资产变更。
+
+人类界面展示时间、人物、对象路径、动作、前后版本、原因、影响、来源和结果；原始 JSON 仅供受控诊断，不作为业务页面。
+
+## 7. 防数据泄露验证
+
+- 两项目、两成员、私人会话和共享文档交叉测试。
+- 批注正文权限与审计权限交叉测试。
+- 撤权后下载、缓存、历史链接和重试测试。
+- 个人流程图/思维导图不可被同项目其他成员枚举。
+- DOCX ZIP 中不存在无权正文、批注、隐藏文本、自定义属性或关系残留。
@@ -0,0 +1,58 @@
+# 08 模板接入与迁移
+
+## 1. 当前 44 份模板
+
+第一阶段逐份生成 RenderProfile，不按文件名硬编码渲染逻辑。每个配置包绑定：原件、转换派生、规范化 DOCX、结构合同、渲染底稿、规则快照、资产和人工评审结论。
+
+当前 42 PASS、2 EXPECTED_BLOCKED。完成前必须补齐对应文档类型字典登记和存量数据库迁移，并在 SQLite、PostgreSQL 与真实产品链重放；不能把“预期阻止”计为已接入。
+
+## 2. 接入步骤
+
+1. 原件保全：文件名、格式、大小、SHA256、来源和许可。
+2. 安全检查：宏、OLE、外链、嵌入对象、损坏部件。
+3. 规范化：旧 DOC 生成受控 DOCX 派生并记录转换器版本和输入输出哈希。
+4. 结构分析：章节、段落、表格、重复块、图片、页眉页脚和签署区。
+5. 视觉普查：字体、页面、标题、编号、颜色、Logo 和模板例外。
+6. 锚点化：把可填写位置转换成书签或内容控件。
+7. 规则生成：建立 RenderProfile 和 Markdown 节点映射。
+8. 正反样例：完整输入、缺字段、超长内容、复杂表格和权限拒绝。
+9. 预览对照：原模板、空模板、填充结果和回读结构。
+10. 人工发布：内容、格式、安全和适用范围全部通过后进入 `published`。
+
+## 3. 公司通用规则
+
+通用规则不是 44 份模板中的任意一份。它由公司视觉普查结论生成，服务于没有专用受控模板的普通报告、纪要、说明和分析文档。
+
+## 4. 字典门禁迁移
+
+对两份阻塞模板：
+
+- 明确对应文档类型、阶段和用途。
+- 新增版本化字典迁移，而不是只修改新库种子。
+- 迁移前生成备份和对账清单。
+- 存量项目不自动创建文档；只增加可选择类型。
+- 旧二进制遇到新字典/schema 时拒绝写入。
+- 迁移后重新执行 44 份全链矩阵。
+
+## 5. 规则版本迁移
+
+已发布规则不可改写。模板修订、Logo 更新或样式调整创建新版本；旧交付物和旧规则包永久可取。文档升级保存旧/新预览、内容映射差异和影响分析，经真人确认后应用。
+
+## 6. 用户上传规则生成（后续）
+
+分析器输出：
+
+- 候选 RenderProfile。
+- 资产清单和哈希。
+- 识别到的样式、锚点和结构。
+- 未识别/低置信度项。
+- 安全风险。
+- 样例 Markdown。
+- 预览 DOCX。
+- 原件与预览的结构/视觉差异报告。
+
+候选规则只能保存为 `draft`。用户可在规则编辑器中修改允许字段；复杂新能力提交为渲染器原语需求，不允许嵌入代码绕过。
+
+## 7. 回滚
+
+回滚是把默认绑定指回旧发布版本，不删除新版本。已经用新规则生成的草稿保留；批准文件永不重新渲染覆盖。规则包、字典和资产迁移分别拥有对账及恢复记录。
@@ -0,0 +1,299 @@
+# Unified Document Renderer Implementation Plan
+
+> **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:** Build a declarative, versioned Word renderer that converts Markdown-backed project documents into validated working, review, and approved DOCX artifacts using either one of 44 controlled templates or the company default profile.
+
+**Architecture:** Subject to architecture review, introduce an independent `Agent-Document-Renderer` Go module containing the canonical document model, RenderProfile compiler, renderer coordinator, and Word adapter. RDM owns project authorization, content/source trees, review state, profile binding, and immutable deliveries; Backend consumes the same module for ordinary workspace deliverables. Profiles and assets are versioned data packages, never executable code. Do not create the repository or change dependency pins until this boundary is approved and the implementation task passes its startup gate.
+
+**Tech Stack:** Go, YAML/JSON schema input with canonical JSON snapshots, ZIP/OPC and XML processing, existing RDM DHF assets, SQLite/PostgreSQL integration, React/TypeScript UI, Playwright browser acceptance.
+
+**Spec:** `docs/records/2026-10-15-unified-document-renderer/02-architecture-and-solution.md`
+
+## Global Constraints
+
+- Phase 1 implements DOCX only; PDF and PPT adapters are interface compatibility tests, not production implementations.
+- RenderProfile is declarative and rejects scripts, macros, arbitrary XML, external URLs, absolute paths, and undeclared assets.
+- Controlled documents never fall back to the company default profile.
+- Published profiles are immutable; updates create new versions.
+- Markdown is the editable source; review and approval data remain separate structured records.
+- Approval identity comes only from trusted frozen review data.
+- Private conversation/source data is excluded unless explicitly authorized for the target document.
+- 44/44 templates must pass the applicable full chain; the current two dictionary blocks must be removed through versioned migration.
+
+## Review Focus
+
+- Old DOC conversions containing OLE, drawings, merged cells, and headers must fail safely or preserve the approved derivative without silently dropping content.
+- A profile selected for the wrong document type must be rejected before any delivery row or blob is committed.
+- A review export with stale text ranges must preserve orphaned comments without attaching them to the wrong paragraph.
+- A revoked member or changed duty must not obtain a new render/download after the authorization change.
+- A profile/asset hash change during rendering must roll back the whole delivery and preserve the prior approved bytes.
+
+---
+
+### Task 1: Freeze the corporate style inventory
+
+**Files:**
+- Create: `Agent-System-RDM/docs/records/renderer/corporate-style-inventory.json`
+- Create: `Agent-System-RDM/docs/records/renderer/corporate-style-inventory.md`
+- Create: `Agent-System-RDM/scripts/render-profile-inventory.py`
+- Test: `Agent-System-RDM/tests/test_render_profile_inventory.py`
+
+**Interfaces:**
+- Consumes: 44 published entries from `internal/rdmapp/templates/dhf/catalog.json` and their normalized/render DOCX packages.
+- Produces: a schema-validated inventory with one row per template and explicit `common|family-rule|template-exception|unverified` findings.
+
+- [ ] Write a failing fixture test that scans one header, one footer, one merged table, one image, and one legacy-converted package and asserts page/style/asset findings.
+- [ ] Run `python3 -m unittest tests.test_render_profile_inventory -v`; expect missing inventory module failure.
+- [ ] Implement bounded ZIP/XML inspection without executing macros or external relationships.
+- [ ] Generate the 44-row JSON and human summary; fail if any catalog identity is absent or duplicated.
+- [ ] Run the test and compare generated output byte-for-byte with the committed inventory.
+- [ ] Commit with the catalog SHA and generator version in the record.
+
+### Task 2: Create the renderer module and canonical model
+
+**Files:**
+- Create: `Agent-Document-Renderer/go.mod`
+- Create: `Agent-Document-Renderer/model/document.go`
+- Create: `Agent-Document-Renderer/model/review.go`
+- Create: `Agent-Document-Renderer/render/renderer.go`
+- Create: `Agent-Document-Renderer/render/diagnostic.go`
+- Test: `Agent-Document-Renderer/model/document_test.go`
+
+**Interfaces:**
+- Produces: `model.CanonicalDocument`, `model.Node`, `model.Annotation`, `model.Revision`, `model.ReviewSnapshot`, `render.Request`, `render.Result`, and `render.Renderer`.
+- Depends only on the Go standard library.
+
+```go
+type Node struct {
+    ID       string
+    Kind     NodeKind
+    Semantic string
+    Text     string
+    Children []Node
+    Sources  []SourceRef
+}
+
+type Request struct {
+    Document    model.CanonicalDocument
+    Profile     profile.Snapshot
+    Review      model.ReviewSnapshot
+    Mode        Mode
+    FrozenAt    time.Time
+    RequestedBy string
+}
+```
+
+- [ ] Write failing tests for duplicate node IDs, cycles, invalid source spans, missing review actors, and immutable clone behavior.
+- [ ] Run `go test ./model ./render`; expect undefined types.
+- [ ] Implement the model and validators with deterministic canonical JSON hashing.
+- [ ] Add serialization round-trip tests and reject unknown schema versions.
+- [ ] Run `go test ./...` and `go vet ./...`.
+- [ ] Commit the deep public model before adding Word code.
+
+### Task 3: Implement RenderProfile schema, compiler, and registry
+
+**Files:**
+- Create: `Agent-Document-Renderer/profile/schema.go`
+- Create: `Agent-Document-Renderer/profile/compile.go`
+- Create: `Agent-Document-Renderer/profile/registry.go`
+- Create: `Agent-Document-Renderer/profile/testdata/*.yaml`
+- Test: `Agent-Document-Renderer/profile/profile_test.go`
+
+**Interfaces:**
+- Consumes: YAML editing form plus an asset reader limited to manifest paths.
+- Produces: immutable `profile.Snapshot`, canonical JSON, snapshot hash, declared capabilities, and compiled mappings.
+
+- [ ] Add failing tests for script fields, arbitrary XML, parent paths, remote assets, duplicate anchors, unknown primitives, unsafe recursion, and controlled fallback.
+- [ ] Implement strict decoding that rejects unknown fields.
+- [ ] Compile inheritance into a complete snapshot; runtime never follows mutable parent profiles.
+- [ ] Implement selection precedence and return `SelectionReceipt{Source, ProfileID, Version, Hash}`.
+- [ ] Add lifecycle tests for `draft→validated→published→retired` and immutable published versions.
+- [ ] Run `go test ./profile -count=1` and commit.
+
+### Task 4: Parse Markdown into CanonicalDocument
+
+**Files:**
+- Create: `Agent-Document-Renderer/markdown/parser.go`
+- Create: `Agent-Document-Renderer/markdown/frontmatter.go`
+- Create: `Agent-Document-Renderer/markdown/directives.go`
+- Test: `Agent-Document-Renderer/markdown/parser_test.go`
+
+**Interfaces:**
+- Consumes: UTF-8 Markdown, required stable node markers, front matter, and a bounded directive set.
+- Produces: `model.CanonicalDocument` without Word-specific styles.
+
+- [ ] Write failing tests for headings, paragraphs, lists, tables, images, callouts, signatures, duplicate IDs, malformed tables, hidden HTML, and oversized documents.
+- [ ] Implement front matter keys for document/profile metadata and reject arbitrary keys in controlled mode.
+- [ ] Implement node ID preservation and deterministic IDs only for first import; later saves persist IDs.
+- [ ] Implement directives for repeat rows, controlled fields, page breaks, and signature placeholders without expression evaluation.
+- [ ] Run `go test ./markdown -count=1` and commit.
+
+### Task 5: Implement the Word adapter and validation pipeline
+
+**Files:**
+- Create: `Agent-Document-Renderer/word/adapter.go`
+- Create: `Agent-Document-Renderer/word/opc.go`
+- Create: `Agent-Document-Renderer/word/styles.go`
+- Create: `Agent-Document-Renderer/word/mappings.go`
+- Create: `Agent-Document-Renderer/word/tables.go`
+- Create: `Agent-Document-Renderer/word/headers.go`
+- Create: `Agent-Document-Renderer/word/validate.go`
+- Test: `Agent-Document-Renderer/word/*_test.go`
+
+**Interfaces:**
+- Consumes: validated render request and declared package assets.
+- Produces: deterministic DOCX bytes, node anchor map, diagnostics, and output hash.
+
+- [ ] Write a minimal valid-DOCX RED test asserting content, style, numbering, bookmark, header, footer, page field, image and table output.
+- [ ] Implement safe OPC cloning with entry-count and expanded-size limits.
+- [ ] Implement semantic styles and numbering without inline style duplication.
+- [ ] Implement exact template anchors, repeated table rows, merged cells, section/page configuration and fixed assets.
+- [ ] Implement post-render validation: OPC relationships, XML parse, missing anchors, forbidden objects, external links, macros and round-trip text structure.
+- [ ] Run `go test ./word -count=1 -race` and commit.
+
+### Task 6: Add review changes, comments, and dual Word output
+
+**Files:**
+- Create: `Agent-Document-Renderer/word/revisions.go`
+- Create: `Agent-Document-Renderer/word/comments.go`
+- Create: `Agent-Document-Renderer/word/approval.go`
+- Test: `Agent-Document-Renderer/word/review_test.go`
+
+**Interfaces:**
+- Consumes: `ReviewSnapshot`, node/range anchors and mode `working|preview|review|approved`.
+- Produces: clean approved DOCX or revision/comment-preserving review DOCX.
+
+- [ ] Write failing tests for insert/delete/replace, comment ranges, replies, stale ranges, deleted nodes and real actor/time metadata.
+- [ ] Implement `w:ins`, `w:del`, comments parts, relationships and tracking settings.
+- [ ] Implement orphan-comment appendix instead of incorrect reattachment.
+- [ ] Implement approved mode that accepts approved revisions, removes ordinary comments and fills signatures only from ApprovalSnapshot.
+- [ ] Assert that accepting all revisions in the review file yields the approved document text.
+- [ ] Run `go test ./word -run 'TestReview|TestApproval' -count=1` and commit.
+
+### Task 7: Publish the company default profile
+
+**Files:**
+- Create: `Agent-Document-Renderer/profiles/company-default/1.0.0/profile.yaml`
+- Create: `Agent-Document-Renderer/profiles/company-default/1.0.0/assets.json`
+- Create: `Agent-Document-Renderer/profiles/company-default/1.0.0/review.json`
+- Test: `Agent-Document-Renderer/profiles/company_default_test.go`
+
+**Interfaces:**
+- Consumes: approved CorporateStyleInventory decisions and versioned Logo/font assets.
+- Produces: first organization-default published profile.
+
+- [ ] Convert only approved common findings into the profile; keep template exceptions out.
+- [ ] Render a report containing all supported node types and a 30-page pagination fixture.
+- [ ] Compare page settings, styles, headers, footers, Logo and file-control fields with approved reference values.
+- [ ] Run accessibility/readability and DOCX validation checks.
+- [ ] Commit the profile and exact visual-review receipt.
+
+### Task 8: Convert all 44 DHF assets into profiles and remove dictionary blocks
+
+**Files:**
+- Create: `Agent-System-RDM/internal/rdmapp/templates/dhf/profiles/<template-id>/1.0.0/profile.json` (44 packages)
+- Modify: `Agent-System-RDM/internal/domain/data/labels_seed.json`
+- Create: `Agent-System-RDM/internal/domain/store/dictionary_renderer_migration.go`
+- Create: `Agent-System-RDM/scripts/generate-render-profiles.py`
+- Test: `Agent-System-RDM/internal/rdmapp/dhf_render_profiles_test.go`
+
+**Interfaces:**
+- Consumes: published DHF packages and CorporateStyleInventory.
+- Produces: 44 exact profiles and versioned dictionary migration for the two blocked types.
+
+- [ ] Write a RED matrix requiring 44 unique profiles, exact package hashes and applicable document types.
+- [ ] Generate profile candidates; do not infer unverified Logo/font/style values.
+- [ ] Add explicit template-exception sections and human review records.
+- [ ] Implement dictionary migration for fresh and existing SQLite/PostgreSQL databases with rollback tests.
+- [ ] Run the 44-document normal/negative render matrix; require 44 PASS and 0 BLOCKED/FAIL.
+- [ ] Commit generated profiles separately from human review decisions.
+
+### Task 9: Integrate rendering with RDM documents, reviews, and traceability
+
+**Files:**
+- Create: `Agent-System-RDM/internal/rdmapp/render_profile.go`
+- Create: `Agent-System-RDM/internal/rdmapp/render_request.go`
+- Create: `Agent-System-RDM/internal/rdmapp/document_source.go`
+- Create: `Agent-System-RDM/internal/rdmapp/render_delivery.go`
+- Modify: `Agent-System-RDM/plugins/rdm/plugin.go`
+- Test: `Agent-System-RDM/internal/rdmapp/render_delivery_test.go`
+
+**Interfaces:**
+- Consumes: Markdown content version, exact profile snapshot, review snapshot and current permissions.
+- Produces: persisted Markdown, preview/review/approved DOCX, manifest, diagnostics and trace edges.
+
+- [ ] Add migrations for source versions, profile bindings, render jobs, delivery manifests and blobs.
+- [ ] Write RED tests for selection precedence, controlled fallback refusal, stale rules, revocation, retry and rollback.
+- [ ] Implement project-authorized transactions that freeze inputs before rendering and commit outputs atomically.
+- [ ] Create Word bookmarks/content controls for every rendered document-tree node and persist the anchor map.
+- [ ] Add commands for validate, preview, submit, review export, approve export, status and download.
+- [ ] Run SQLite/PostgreSQL restart, concurrency and migration tests; commit.
+
+### Task 10: Replace the separate Backend Markdown Word path
+
+**Files:**
+- Modify: `Agent-System-Backend/internal/docgen/`
+- Modify: `Agent-System-Backend/internal/prompts/library/base-deliverables.md`
+- Modify: `Agent-System-Backend/internal/skills/recipes/house-style/`
+- Test: `Agent-System-Backend/internal/docgen/renderer_integration_test.go`
+
+**Interfaces:**
+- Consumes: shared renderer module and organization-default profile.
+- Produces: workspace Markdown plus DOCX and manifest artifacts through the same renderer contract.
+
+- [ ] Write a RED test proving the existing Markdown deliverable produces the same canonical nodes through the new entry.
+- [ ] Route ordinary Word generation through the shared renderer; retain old path only behind a migration comparison flag.
+- [ ] Ensure project controlled documents call RDM and cannot use Backend default fallback.
+- [ ] Compare old/new samples and close documented differences before removing the old path.
+- [ ] Run Backend `go test ./...` and `go build ./...`; commit.
+
+### Task 11: Add profile selection, preview, review, and download UI
+
+**Files:**
+- Create: `Agent-System-Frontend/src/components/DocumentRenderWorkspace.tsx`
+- Create: `Agent-System-Frontend/src/documentRenderPresentation.ts`
+- Modify: document reader/tree and artifact download components
+- Test: `Agent-System-Frontend/test/document-render-workspace.test.ts`
+- Test: `Agent-System-Frontend/e2e/document-renderer.playwright.ts`
+
+**Interfaces:**
+- Consumes: server-cropped profile, render status, diagnostics, review and delivery DTOs.
+- Produces: profile choice, preview status, readable failures and Markdown/approved/review/package downloads.
+
+- [ ] Add component tests for four-level rule selection, controlled fallback refusal, long diagnostics and stale async responses.
+- [ ] Build the two document-tree views already approved: structure canvas and traditional reader, sharing selected node and filters.
+- [ ] Show source, confidence, conflict, author/time, change before/after and impact on each readable node.
+- [ ] Add review comments and revision display without exposing raw OOXML or private sources.
+- [ ] Run design guards, all frontend tests, build, knip and real-product Playwright; commit.
+
+### Task 12: Reserve uploaded-template analysis without auto-publication
+
+**Files:**
+- Create: `Agent-Document-Renderer/analyzer/report.go`
+- Create: `Agent-Document-Renderer/analyzer/candidate.go`
+- Create: `Agent-System-RDM/internal/rdmapp/render_profile_candidate.go`
+- Test: candidate lifecycle tests
+
+**Interfaces:**
+- Produces only draft profile candidates, analysis reports and previews; no publish method is exposed to the analyzer.
+
+- [ ] Define typed findings for styles, structures, assets, unsafe parts, confidence and unresolved items.
+- [ ] Persist candidate/report/original hashes and require an administrator publication command.
+- [ ] Add negative tests proving candidate analysis cannot execute content or publish itself.
+- [ ] Commit the dormant contract and lifecycle; defer automated rule inference implementation.
+
+### Task 13: Complete full acceptance and delivery evidence
+
+**Files:**
+- Update: RDM/Backend/Frontend task cards
+- Create: `Agent-System-RDM/docs/records/renderer/phase1-acceptance.md`
+- Create: machine-readable 44-template and browser receipts
+
+- [ ] Run renderer module tests and race checks.
+- [ ] Run RDM full test/build, isolated PostgreSQL tests and 44-profile product matrix.
+- [ ] Run Backend full test/build and Markdown/DOCX artifact verification.
+- [ ] Run Frontend full test/build/design guard/knip and real-product Playwright in light/dark/narrow layouts.
+- [ ] Reopen representative DOCX files with Word-compatible tooling and verify text, styles, headers, comments, revisions and signatures.
+- [ ] Perform independent review against this spec and resolve all Critical/Important findings.
+- [ ] Fix the exact candidate SHAs and record SELF/GATE/REPLAY sources honestly before any PR or merge.
@@ -0,0 +1,120 @@
+# 10 测试与验收计划
+
+## 1. 验收层级
+
+| 层级 | 目的 |
+|---|---|
+| Schema | 规则、模型、清单和迁移的确定性及兼容性 |
+| Renderer unit | Markdown 节点到 Word 原语的正确映射 |
+| DOCX integrity | OPC、XML、关系、样式、字段、锚点、批注和修订 |
+| RDM integration | 权限、冻结提交、审签、交付物和追溯原子性 |
+| Template fidelity | 44 份模板逐份内容与格式对照 |
+| Browser | 规则选择、预览、审阅、下载和错误体验 |
+| Security/privacy | 恶意规则、恶意 DOCX、撤权和私域泄露 |
+| Recovery | SQLite/PG 重启、并发、失败和迁移回滚 |
+
+## 2. RenderProfile 测试
+
+- 未知字段、schema、primitive 或 capability 拒绝。
+- 脚本、宏、任意 XML、外链、绝对路径和父目录拒绝。
+- 资产缺失、哈希失配和重复锚点拒绝。
+- 受控文档 `allowDefaultFallback=true` 拒绝发布。
+- 继承展开后快照确定，父规则修改不改变已发布子规则。
+- 同 ID/版本不同字节冲突，同字节重放幂等。
+
+## 3. Markdown 与统一模型
+
+- 标题、段落、列表、表格、图片、引用、警示和签署节点。
+- 稳定 ID、重复 ID、深度/节点数/文本长度上限。
+- 无效 UTF-8、HTML、危险链接和未知指令。
+- 来源范围、置信度、冲突和权限标签保留。
+- 修改 Markdown 后节点身份和批注锚点保持或明确漂移。
+
+## 4. Word 基础能力
+
+- 页面、分节、方向、页边距和分页。
+- 语义样式、标题编号、目录和列表。
+- 表格列宽、合并、重复表头、重复行和跨页。
+- 图片、题注、Logo 和替代说明。
+- 页眉、页脚、PAGE/NUMPAGES、文件控制字段。
+- 节点书签/内容控件及反向映射。
+- 生成后 ZIP/OPC/XML/关系/回读和哈希验证。
+
+## 5. 审阅与批准
+
+- 插入、删除、替换和移动修订。
+- 批注范围、回复、解决、拒绝和孤立批注。
+- Word 作者、时间与系统快照一致。
+- 审阅稿接受全部修订后的正文等于批准稿。
+- 批准稿不含普通批注、未接受修订或私人来源。
+- 无真实审核/批准记录时阻止批准稿。
+- 相同冻结提交重试返回同一交付物。
+
+## 6. 44 份模板矩阵
+
+每份模板至少包含：
+
+- 一个完整正常样例。
+- 一个缺必填字段样例。
+- 一个超长或多行内容样例。
+- 一个表格/重复块样例（适用时）。
+- 页眉页脚和文件控制字段检查。
+- Logo/图片/形状检查（适用时）。
+- 原件、规范化件、规则、输出和回读哈希。
+- 人工视觉结论及例外说明。
+
+总门槛：44 PASS、0 EXPECTED_BLOCKED、0 LIMITED、0 FAIL。
+
+## 7. 公司通用规则
+
+使用会议纪要、分析报告、技术说明、周报和无专用类型的自由报告验证。检查长标题、中文/英文混排、多页表格、图片、目录、页眉页脚和下载清单。
+
+## 8. 权限矩阵
+
+- 项目创建者、普通成员、编制人、审阅人、批准人、管理员。
+- `doc.read/write/publish`、`review.participate`、`project.settings`、`audit.read` 交叉。
+- 私人来源、共享项目事实、受控正文和批注分别裁剪。
+- 撤权发生在解析前、渲染中、提交前和下载前。
+- 另一个项目或成员不能通过 ID、缓存、历史 URL、审阅稿或 DOCX 隐藏内容读取数据。
+
+## 9. 安全矩阵
+
+- 带宏、ActiveX、OLE、外链和远程模板的 DOCX。
+- ZIP bomb、重复名称、路径穿越、超大图片和深 XML。
+- 规则中的脚本、任意 OOXML、远程资产和表达式注入。
+- Markdown 中的 HTML、危险 URI 和超限结构。
+- 输出 DOCX 不含宏、外部关系、无权自定义属性或隐藏文本。
+
+## 10. 数据库与恢复
+
+SQLite 与隔离 PostgreSQL 均覆盖：
+
+- 规则注册、发布、退役和选择。
+- 内容/规则/审签冻结。
+- 渲染成功、失败、超时和取消。
+- 同键重试、异参冲突和两实例竞争。
+- 生成中撤权和规则退役。
+- 迁移中断、回滚、备份恢复和旧二进制拒绝。
+- 批准字节在重启和规则升级后不变。
+
+## 11. 浏览器验收
+
+真实产品、auth-on、至少两个项目和三种职责：
+
+1. 文档树选择结构画布和传统阅读器。
+2. 选择专用规则与公司通用规则。
+3. 查看规则来源、版本和禁止回退说明。
+4. 生成预览并定位诊断到具体节点。
+5. 添加批注和修订，完成审阅与批准。
+6. 下载 Markdown、批准稿、留痕稿和完整包。
+7. 查看追溯网中的来源、规则、修订、审签和交付物。
+8. 无权限用户的页面与网络响应均无受限内容。
+9. 浅色、深色、窄屏、长文档和长文件名可用。
+
+## 12. 性能和容量
+
+记录而非预设通过：10/50/100/300 页等价内容，1/10/50 MB 图片集，100/1,000/5,000 节点，100/1,000 批注。分别测解析、编译、渲染、校验、保存和下载时间及峰值内存。容量阈值根据实测和产品要求另行评审，不用无证据数字放行。
+
+## 13. 证据要求
+
+每项通过断言绑定命令、完整对象 SHA、组件 pin、配置、输出和来源等级。SELF 本地记录不能冒充 CI/GATE；浏览器截图不能替代网络权限断言；能够打开 DOCX 不能替代格式保真或审签真实性。
@@ -0,0 +1,59 @@
+# 11 需求追踪与评审清单
+
+## 1. 使用方式
+
+本表把本轮用户要求映射到设计文档、实施任务和验收证据。评审通过表示同意需求和方案边界，不表示代码已实现、测试已通过或系统已部署。实施后只有附带命令、对象 SHA 和完整输出的证据才能把状态从 `DESIGNED` 更新为 `IMPLEMENTED`、`VERIFIED` 或 `ACCEPTED`。
+
+## 2. 需求追踪矩阵
+
+| ID | 用户结果要求 | 设计位置 | 实施任务 | 主要验收 | 当前状态 |
+|---|---|---|---|---|---|
+| RDR-01 | Markdown 作为权威源，可同时下载 Markdown 和 Word | 01 §2/5.2；02 §2.1 | 2、4、9、10 | 10 §3/11 | DESIGNED |
+| RDR-02 | 一个渲染器按规则生成多种文档，不为每种文档复制代码 | 02 §1–2；03 | 2、3、5 | 10 §2/4 | DESIGNED |
+| RDR-03 | 文档可选择专用规则，未指定时使用公司默认规则 | 01 §5.1；03 §3 | 3、7、9、11 | 10 §2/7/11 | DESIGNED |
+| RDR-04 | 受控文档失配时阻止生成，不能静默套默认样式 | 01 §5.1；02 §6 | 3、8、9 | 10 §2/6 | DESIGNED |
+| RDR-05 | 44 份现有模板全部接入并能正常生成 | 08 §1–4 | 1、8、13 | 10 §6 | DESIGNED |
+| RDR-06 | 归纳公司页面、字体、标题、表格、页眉页脚和 Logo 规范 | 04 §2–4 | 1、7 | 10 §6–7 | DESIGNED；具体值待普查评审 |
+| RDR-07 | 每份文档可配置渲染方式，规则版本化且无需改代码扩展 | 03 §2–10 | 3、7、8 | 10 §2 | DESIGNED |
+| RDR-08 | Word 第一阶段完成，后续同架构扩展 PDF/PPT | 01 §3；02 §7 | 2、5；后续适配器 | 公共接口兼容测试 | DESIGNED；PDF/PPT NOT_RUN |
+| RDR-09 | 用户上传参考文档后可分析生成候选规则 | 05 §8；07 §3；08 §6 | 12 | 候选生命周期与恶意输入测试 | CONTRACT_ONLY |
+| RDR-10 | 支持修订模式、批注、回复和真实审签信息 | 06 | 6、9、11 | 10 §5/11 | DESIGNED |
+| RDR-11 | 默认交付干净批准稿和审阅留痕稿 | 05 §5；06 §7 | 6、9 | 10 §5 | DESIGNED |
+| RDR-12 | 渲染结果进入文档树、笔记树和追溯网 | 01 §1/5.3；02 §2.5；05 §2 | 2、4、9 | 10 §3/9/11 | DESIGNED |
+| RDR-13 | 文档树支持结构画布和传统阅读器两种视图 | 09 Task 11 | 11 | 10 §11 | DESIGNED |
+| RDR-14 | 页面展示来源、置信度、冲突、修改前后、影响、人物和时间 | 07 §6；09 Task 11 | 9、11 | 10 §8/11 | DESIGNED |
+| RDR-15 | 追溯网和审计受权限保护，个人流程图/思维导图保持私域 | 07 §1/4/7 | 9、11 | 10 §8–9 | DESIGNED |
+| RDR-16 | 规则、模板、资产和输出可重放且旧批准文件不被覆盖 | 02 §5；03 §10；05 §6 | 3、7–9 | 10 §2/10/13 | DESIGNED |
+| RDR-17 | 规则与上传文件不能执行脚本、宏、外链或任意 XML | 03 §1；07 §2–3 | 3、5、12 | 10 §2/9 | DESIGNED |
+
+## 3. 阶段评审点
+
+### A. 需求与范围
+
+- [ ] 确认第一阶段以 DOCX 为唯一生产格式。
+- [ ] 确认 44/44 全链通过是完成条件，两份字典阻塞不能作为例外保留。
+- [ ] 确认上传参考文档只生成候选规则，本阶段只保留合同和安全边界。
+
+### B. 架构与模块边界
+
+- [ ] 确认采用独立 `Agent-Document-Renderer` 模块；或记录选择内嵌包的替代决定及独立化条件。
+- [ ] 确认 RDM 负责权限、冻结、审签和追溯，渲染器不反查项目数据库。
+- [ ] 确认 Backend 普通交付与 RDM 受控交付最终共用同一渲染合同。
+
+### C. 规则与公司设计
+
+- [ ] 确认规则为声明式数据，发布后不可原地修改。
+- [ ] 确认先完成 44 份视觉普查，再发布字体、字号、Logo、颜色等具体公司值。
+- [ ] 确认专用模板例外优先，但必须登记证据和适用范围。
+
+### D. 审阅、权限和交付
+
+- [ ] 确认批准稿与审阅留痕稿双 Word 默认交付。
+- [ ] 确认审签身份只来自冻结的可信流程记录。
+- [ ] 确认追溯网和审计仍按对象权限加审计权裁剪，个人解释图不进入项目共享面。
+
+## 4. 实施放行条件
+
+评审通过后，实施仍按项目交付策略分阶段启动。第一批只放行 Task 1–3：固定公司样式普查、统一模型和 RenderProfile 合同。第一批产物通过评审后再放行 Word 适配器与 44 模板迁移，避免在规则和模块边界未稳定时批量生成不可维护的配置。
+
+每批实施必须记录：目标分支、基线 SHA、组件 pin、变更文件、测试命令、SELF/GATE/REPLAY 来源、未运行项、迁移与回滚边界。真实数据库迁移、部署和发布仍分别受各自门禁约束。
@@ -0,0 +1,45 @@
+# 统一文档渲染器方案文档集
+
+日期：2026-10-15。状态：设计与实施计划待人工评审。范围：第一阶段只实现 Word；PPT、PDF 作为同一架构的后续格式适配器，不在本阶段实施。
+
+## 目标
+
+建立一个由声明式规则驱动的统一文档渲染平台。智能体和成员以 Markdown 及结构化元数据维护内容，系统按文档实例、文档类型、项目或公司默认规则选择渲染配置，输出可下载、可审阅、可批准、可追溯的 DOCX。新增文档类型通过发布新的规则包和受控资产完成，不需要为每种文档编写独立渲染器。
+
+## 文档导航
+
+| 文档 | 用途 |
+|---|---|
+| [01 需求与范围](01-requirements-and-scope.md) | 产品目标、角色、范围、验收口径和非目标 |
+| [02 总体架构与方案](02-architecture-and-solution.md) | 统一文档模型、渲染内核、格式适配器及系统边界 |
+| [03 渲染规则规范](03-render-profile-spec.md) | RenderProfile、规则选择、版本和声明式安全边界 |
+| [04 公司 Word 设计规范](04-corporate-word-design-standard.md) | 页面、字体、标题、表格、页眉页脚、Logo、编号和例外规则 |
+| [05 生命周期与流程](05-lifecycle-and-workflows.md) | 起草、预览、审阅、批准、导出、升级及回滚流程 |
+| [06 修订、批注与审签](06-review-comments-approval.md) | Word 审阅模式、批注、回复、修订与双 Word 交付 |
+| [07 权限、安全与审计](07-security-permissions-audit.md) | 私域、项目权限、资产安全、审计及防伪造要求 |
+| [08 模板接入与迁移](08-template-onboarding-and-migration.md) | 44 份模板接入、字典门禁清零及未来上传模板生成规则 |
+| [09 实施计划](09-implementation-plan.md) | 可执行的分阶段任务、接口、文件、测试和提交边界 |
+| [10 测试与验收计划](10-test-and-acceptance-plan.md) | 单元、保真、迁移、浏览器、权限及全模板验收矩阵 |
+| [11 需求追踪与评审清单](11-traceability-and-review-checklist.md) | 用户要求、设计、实施任务、验收证据和待评审决策的逐项对应 |
+
+`document-manifest.json` 固定本次评审文档的文件名、大小和 SHA256。评审意见导致任一正文变化时，必须重新生成清单，旧清单不得继续作为相同评审对象。
+
+## 当前事实基线
+
+- DHF 目录登记 44 份已发布模板，其中 30 份原生 DOCX、14 份旧 DOC 的受控转换链。
+- 41/44 含页眉或页脚部件。
+- 40 份存在文件名称、文件号、版本等控制字段；现已登记 78 个页眉/页脚槽位。
+- 企业机密声明及 PAGE/NUMPAGES 域属于固定内容，不是项目可填写槽位。
+- 当前逐项产品链为 42 PASS、2 EXPECTED_BLOCKED、0 FAIL；两份阻塞来自字典登记/迁移边界，第一阶段必须清零后才能声明 44/44 可生成。
+- 当前 RDM 已有冻结模板槽位填充能力，Backend 已有独立 `house-style` Markdown→DOCX 工具；两者尚未共享统一文档模型和 RenderProfile 合同。
+
+以上为当前工作分支源码和既有 SELF 记录中的事实基线，不代表部署环境验收或 CI/GATE 结论。44 份视觉共性仍须按 [04 公司 Word 设计规范](04-corporate-word-design-standard.md)执行逐模板普查。
+
+## 统一原则
+
+1. Markdown 是可编辑的权威内容源，DOCX 是由确切规则版本生成的交付物。
+2. 一个渲染内核消费多个规则包；不得为每个文档类型复制渲染器代码。
+3. 受控文档指定规则失配时阻止生成，不静默回退公司默认规则。
+4. 发布规则不可原地修改；新规则生成新版本，旧文档继续绑定旧版本。
+5. 审核、批准、签署和批注作者只能来自系统可信身份及真实流程。
+6. 原件、规则、Markdown、输出文件和清单均保留哈希与追溯关系。
@@ -0,0 +1,68 @@
+{
+  "schemaVersion": "document-review-manifest/v1",
+  "documentSet": "unified-document-renderer",
+  "reviewDate": "2026-10-15",
+  "status": "pending-human-review",
+  "files": [
+    {
+      "path": "01-requirements-and-scope.md",
+      "bytes": 4847,
+      "sha256": "c2c5ae8ca3e6ad657de59ba0338cee8e9c4115fc4e189be6e14803a5954fc913"
+    },
+    {
+      "path": "02-architecture-and-solution.md",
+      "bytes": 5216,
+      "sha256": "5b5bdad20ff88c3114b448385706a0ddcc82f5ce68c27acbcbc82512c10d16e2"
+    },
+    {
+      "path": "03-render-profile-spec.md",
+      "bytes": 4241,
+      "sha256": "5c896649851de88d7c7ff48a2eb5bd7be70e7c6b12bb26858da126605ac0aa13"
+    },
+    {
+      "path": "04-corporate-word-design-standard.md",
+      "bytes": 3563,
+      "sha256": "3c4cfc36b01b80ec3ae2e48a42c96bc1e7aee97b5f5e614a498d484102b8236d"
+    },
+    {
+      "path": "05-lifecycle-and-workflows.md",
+      "bytes": 3681,
+      "sha256": "a3d8737a2af100c93af1efbdfec6193e06c7283978e5fc68d8a3d49c12959831"
+    },
+    {
+      "path": "06-review-comments-approval.md",
+      "bytes": 3262,
+      "sha256": "8722f02e69b4664b3e13a56cafa70d12e170190df56c8b91b5564f42ed52e114"
+    },
+    {
+      "path": "07-security-permissions-audit.md",
+      "bytes": 3268,
+      "sha256": "b48406b8d9d9a6eb3faf7caaf8be64fdae10b0f49f937cfe81e29114832d6923"
+    },
+    {
+      "path": "08-template-onboarding-and-migration.md",
+      "bytes": 2867,
+      "sha256": "c8f8add79ab2979b23bb0e701e8a6b71d5a015988fdeedd02677236b7145b404"
+    },
+    {
+      "path": "09-implementation-plan.md",
+      "bytes": 17660,
+      "sha256": "731aca8fabc919a0130e6b75258401401b50b34f91ef36c008029f61733d97b5"
+    },
+    {
+      "path": "10-test-and-acceptance-plan.md",
+      "bytes": 5327,
+      "sha256": "0e14dd940e70bd53730fd4255acdb569dacbe6cba37d23efb0ab4b9419e63304"
+    },
+    {
+      "path": "11-traceability-and-review-checklist.md",
+      "bytes": 4632,
+      "sha256": "ef898cfbd58d12288946aecb731ccf0d4821ee669830c6ea4d209062788b4d0a"
+    },
+    {
+      "path": "README.md",
+      "bytes": 3907,
+      "sha256": "05ed7f9ba727f1ba854dc38ca32b881dd0ee91de882d683f781c60fcca061970"
+    }
+  ]
+}