实现图谱 v2 · 需求完整性终报
轮次报告全文 · 逐字真源投影
本页是轮次报告的逐字投影（仅隐私清洗，零改写）。渲染不了的元素退化为代码块原文。
时点提示：本页是仓内文件 adhoc_jobs/context_infra_base_tooling_buildout_20260615/implementation_atlas_v2_20260618/requirement_completeness/final_report.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。
报告元数据（frontmatter）
schema_version: fa-3
task_id: implementation_atlas_v2_20260618
domain: final_report
phase: IA2-P1-requirement-completeness
session_id: (main-agent direct run)
created_at: 2026-06-18
method: MC1-MC4 盲抽
baseline_file: requirements/design/final_report.md
status: done需求补全报告：final_report
§1 Session 全集
| session | 说明 | 关联材料 |
|---|---|---|
| b74c2ff8 | 发起 session，报告可视化三维度 + 两轮 Q&A（Mermaid 复杂架构 + Final Report workflow 联动） | adhoc_jobs/native_report_visualization_20260615/ORIGINAL_PROMPT.md；raw turns 从 JSONL 抽取（real_user=6） |
| 1c0c7409 | RPT-01 报告书写规范（含四点：术语/原文/逻辑/变更对比） | adhoc_jobs/landing_requirement_decomposition_20260531/REQUIREMENTS_ORIGINAL_TEXT.md（RPT-01） |
| 8f91b7e1 | 报告矩阵/易读性/绘图优先/格式内容分离（W-02/W-03/SR-068/REF-005），7 个 real user turn | adhoc_jobs/session_task_taxonomy_20260610/data/extracts/8f91b7e1_user_turns.md |
| 9d362dae | HTML 展示/画图诉求（SR-072），modal 术语交互，11 个 real user turn | adhoc_jobs/session_task_taxonomy_20260610/data/extracts/9d362dae_user_turns.md |
| 26c48576 | 流程图/架构图类比（SR-085）：人类直觉对图像，3 个 real user turn | adhoc_jobs/session_task_taxonomy_20260610/data/extracts/26c48576_user_turns.md |
§2 盲抽摘录（不看 baseline，独立摘设计需求）
以下按 session 逐一提取设计需求，不看 requirements/design/final_report.md。
b74c2ff8 — 发起 session（报告可视化任务原始 prompt + 两轮 Q&A）
Turn 1（2026-06-15T00:22:51）— 三维度主 prompt
从原始 prompt 盲抽的设计需求候选：
绘制清晰的架构图，特别是变更前后的对比
对关键变化部分进行特殊标注
体现迭代过程中具体的修改内容
包含必要的名词介绍
明确说明是如何满足各项需求的
参考我下面提供的一些资料，并自行寻找其他相关的参考案例。你最好一定要去找到一些 reference，包括一些软工的。现在我的这个仓库里面有很多相关的书籍，我觉得都可以考虑使用一下它们。
在安排报告结构时，要从宏观的逻辑（道）和微观的技巧（术）两个层面去考虑。但里面更关键的可能还是高层的原则。
提升写报告的相关 skill。
思考如何去掉文章里的"AI 味"，让内容更自然。
这些可能并不适合我们当前仓库的情况，更多的是要去产生一个我们仓库 native 的写报告的方式。
Turn 2（2026-06-15T11:08:45）— Q&A 追加 prompt
关于绘图功能的记录处理。在画图之前，系统确实有一个"冻结"或是类似的机制。我想确认，在完全空白的状态下，或者在已有一定实现基础上去做这种记录时，它能否处理好这些情况？
我想知道 Final Report 的书写现在是否有触发机制？因为在我们的 Phase 安排中，最后应该是做一个 Report 的书写。那么这个环节是否与我们整个 Workflow 联动起来了？即它能否合理地安排这些 Phase，并自动联动最后的 Final Report 书写。
Turn 3（2026-06-15T20:17:28）— 整理+迁移+补全 prompt
等一下，上一次的 Prompt 有点问题。我想知道 Mermaid 架构图是否能够处理复杂架构的绘制？我对此稍微有点质疑，不知道能不能完成。
把剩下的、尚未完成的实现部分补齐。最终完整地完成这一项 Tooling 的构建。
Turns 4-6（Stop hook + FA FLAG 处理）
Turn 4-5 是 Stop hook 系统注入（phase 驱动器反馈），不含用户设计需求。Turn 6（2026-06-15T21:15:41）是关于 FA gate FLAG 的确认，不含新设计需求。
1c0c7409 — RPT-01 报告书写规范
Turn U1（2026-06-03T15:12:34）— RPT-01 嵌套 prompt
专业术语解释：报告首先要对涉及的专业术语进行解释说明。在术语出现的地方，需要提供类似"注释"的说明，方便我理解该术语在当前系统中的具体定义及独特实现。
基于 Prompt 的实现记录：报告必须明确写出最初 Prompt 中给出的原始需求。
实现逻辑说明：基于需求做了哪些具体的实现，并解释为什么这些实现是有效的。
变更对比：清晰地展示实现前后具体内容的对比与变化。
Turns U2-U3（2026-06-03T16:04-16:07）
关于 handoff prompt 格式和 workflow 安排。无新 final_report 设计需求。
8f91b7e1 — 报告矩阵 / 易读性 / 绘图优先 / 格式内容分离
Turn U1（2026-05-31T17:51:58）
分享去 AI 味 gist，要求将其融入 COMMUNICATION.md 约束。无新 final_report 专属设计需求（已由通用语言纪律层覆盖）。
Turn U3（2026-05-31T18:16:28）
目前的思路更多是从"道"的层面……可以专门创建一个用于"写报告及做检查"的 skill……将这个 skill 放在 Draft 里面。
现有的 communications.md 更多是在"道"的层面进行宏观限制。新 skill 则从"术"的方法论层面，为 agent 提供具体的检查思路和思考方向。
你可以再考虑一下，如何将我们的 communication 文档与具体的 skill 结合，形成一种矩阵式的覆盖。
Turn U4/U5（2026-05-31T18:35-18:36）
它应该在我们整个变化过程中有更完整的说明，包括：1. 任务是怎么做的 2. 做了哪些修改 3. 之前与之后具体都做了哪些事情
关于报告书写，人天生对图像的阅读和理解能力更好。在这样的基础上，我觉得报告中可以直接通过绘图来表现"之前与之后"的变化。
写报告时应该有一定的自检机制，可以查看具体完成任务过程中的记录。比如查看聊天记录，或者像 Loop 这种专门记录文件的工具。
格式处理的 skill：具体到任务上，比如 HTML 或 MD 文档具体怎么写，这属于格式上的 skill。(a) HTML 内部有一些格式处理，但目前做得不够好。例如在展示文档历史变化的过程中，它倾向于直接把 MD 内容放进去，缺乏摘录，且 MD 在 HTML 中无法得到很好的渲染。这些是 HTML 处理中需要避免的。
整个过程最终希望形成一个 communications 矩阵：一部分是规则性的实现，不需要过多考虑内容，主要负责格式处理；另一部分是在报告组织内容时，负责具体的检查和 survey session。
Turns U6-U7（2026-05-31T18:54）
关于 Final Report 的部分，我觉得还是由你来做决定。你可以考虑一下具体的使用方式，从我们作为 skill creator 的角度，以及不同 skill 中任务分离的角度去思考：1. 如何在 AI 写入报告时，在不同情况下提供清晰的引导。2. 任务分离的具体逻辑和实施角度。
这是授权 AI 决定细节，非新设计状态需求。
9d362dae — HTML 展示/画图诉求（SR-072）
Turn U1（2026-05-16T21:28:56）
画图非常关键。
说到底，就是让 agent 能够"说人话"，并展示出具体任务是怎么做的。
Turn U4（2026-05-17T09:39:34）— modal 术语交互设计
我希望通过一种类似 Modal（模态框）的对象，让我在阅读原文时能快速查看到具体的定义或说明；同时，也要能非常方便地在原文中找到对应的描述和介绍，以便结合上下文来理解。
这个功能不局限于术语……写完一段内容后，在不给任何上下文的情况下，让另一个 LLM 实例来判断：(a) 哪些内容在缺乏相关背景知识时是难以理解的？(b) 哪些地方存在指代不明或介绍不充分的情况？
Turns U5-U11（2026-05-17 至 2026-05-18）
关于 HTML 前端细节、bug 修复（点击 modal 遮挡原文）、Kimi 版本对比。这些是 HTML 报告的格式迭代，不在仓库 native / markdown 范畴内。
26c48576 — 流程图/架构图类比（SR-085）
Turns U1-U2（2026-05-30T22:11）
对于人类来说，如果有一个详细的图像，包括数据变换的流程图或架构图，比起纯文字，图像往往能让人类更直观地理解事物。
注：SR-085 主体诉求是 native 范式研究，图像类比是引子，非 final_report 专属设计需求。
Turn U3（2026-05-31T09:23:55）
写入 memory，无新 final_report 设计需求。
§3 三层对账表
对账：将盲抽候选与 baseline FR-01~FR-13 逐一映射，并对疑似漏项 grep 复核全域。
| 候选（盲抽来源） | baseline 锚 | 层级 | grep 复核 |
|---|---|---|---|
| 变更前后架构图对比（b74c2ff8 T1） | FR-01 | covered | final_report.md:52-57 逐字 |
| 关键变化特殊标注（b74c2ff8 T1） | FR-02 | covered | final_report.md:59-62 逐字 |
| 体现迭代过程具体修改（b74c2ff8 T1） | FR-03 | covered | final_report.md:64-67 逐字 |
| 必要名词介绍（b74c2ff8 T1） | FR-06 | covered | final_report.md:87-93 逐字 |
| 明确说明如何满足各项需求（b74c2ff8 T1） | FR-07 | covered | final_report.md:94-99 逐字 |
| 参考软工资料+仓库书籍（b74c2ff8 T1） | FR-08 | covered | final_report.md:101-106 逐字 |
| 道/术两层安排报告结构（b74c2ff8 T1） | FR-09 | covered | final_report.md:110-115 逐字 |
| 提升写报告 skill（b74c2ff8 T1） | FR-10 | covered | final_report.md:117-122 逐字 |
| 去 AI 味（b74c2ff8 T1） | FR-11 | covered | final_report.md:124-130 逐字 |
| 仓库 native（b74c2ff8 T1） | FR-13 | covered | final_report.md:146-152 逐字 |
| Mermaid 复杂架构拆视图（b74c2ff8 T3 Q&A） | FR-05 | covered | final_report.md:78-83 逐字 |
| Final Report 与 workflow 联动（b74c2ff8 T2 Q&A） | FR-12 | covered | final_report.md:133-142 逐字 |
| 画图前"冻结"/look-back 记录机制（b74c2ff8 T2 Q&A） | FR-04 | covered（look-back 取证） | final_report.md:69-76 含看聊天记录/Loop 的自检机制 |
| RC5 检测器须正确处理 greenfield（空白）报告——不误判（b74c2ff8 T2 Q&A 核心能力确认） | 未收录 | 候选 CLEAN-NEW | grep 全域：final_report.md 无"空白状态/greenfield/不误判/false-flag"；cross_cutting/runtime 域均无此条目 |
| RPT-01 (a) 术语注释（1c0c7409 U1） | FR-06 / cross_cutting XC-40 | covered（cross-ref） | final_report.md:87 + cross_cutting.md:XC-40 |
| RPT-01 (b) 基于 Prompt 的实现记录（1c0c7409 U1） | FR-07 / cross_cutting XC-40 | covered（cross-ref） | final_report.md:94 + cross_cutting.md:XC-40 |
| RPT-01 (c) 实现逻辑说明（1c0c7409 U1） | FR-07 / cross_cutting XC-40 | covered（cross-ref） | final_report.md:94 + cross_cutting.md:XC-40 |
| RPT-01 (d) 变更对比（1c0c7409 U1） | cross_cutting XC-40 | covered（cross-ref） | cross_cutting.md:XC-40 逐字 |
| 道术矩阵 + 写报告查矩阵路由（8f91b7e1 U3） | cross_cutting XC-41 | covered（cross-domain） | cross_cutting.md:XC-41 |
| 易读性自检=完整记录变化（8f91b7e1 U4/U5） | cross_cutting XC-42 | covered（cross-domain） | cross_cutting.md:XC-42 |
| 绘图表现前后变化（8f91b7e1 U4/U5） | FR-01 / FR-04 | covered | final_report.md:52 + final_report.md:69 |
| look-back 自检（8f91b7e1 U4/U5） | FR-04 | covered | final_report.md:69-76 |
| 格式与内容 skill 分离（8f91b7e1 U4/U5） | cross_cutting XC-06 | covered（cross-domain） | cross_cutting.md:XC-06 |
| HTML 格式特定失格问题（8f91b7e1 U4）——直接塞 MD 入 HTML、缺乏摘录、MD 不渲染 | 未收录 | 候选 CLEAN-NEW | grep 全域：缺乏摘录/MD.HTML.渲染/直接把.*MD 零命中 |
| 画图关键+说人话（9d362dae U1） | FR-01~03 / FR-06/07 | covered（精神） | final_report.md:52-99 |
| HTML Modal 术语交互设计——hover/click 浮层不遮挡原文（9d362dae U4） | 域边界外 | cross-domain → 路由到 HTML 报告格式域（FR-13 已明确 HTML 视图延后） | final_report.md:151 FR-13 落地明确延后 |
| 流程图/架构图类比 图像优先于纯文字（26c48576 U1-U2） | FR-01 历史耦合 SP-FR-4 | covered | final_report.md:57 SR-085 耦合项 |
§4 clean-new 漏项
clean-new 数量：2 条
CAN-FR-A：RC5 检测器须正确处理 greenfield（首次实现、无 before 状态）报告——不误判
来源：b74c2ff8 T2（2026-06-15T11:08:45）用户追加 Q&A
逐字原话：
关于绘图功能的记录处理。在画图之前，系统确实有一个"冻结"或是类似的机制。我想确认，在完全空白的状态下，或者在已有一定实现基础上去做这种记录时，它能否处理好这些情况？
分析：用户在确认 look-back 机制（已覆盖 FR-04）之外，明确追问了一个设计状态目标：RC5 检测器必须正确处理两种态——(1) greenfield（完全空白、首次实现、无 before 记录可画）和 (2) 有历史实现基础（能提供 before/after 结构）。这是 RC5 检测器的不误判约束（not false-flag greenfield），是 FR-04 的邻域能力，但 FR-04 仅描述「绘图必须先 look-back 取证」，未说「没有 before 可 look-back 时，RC5 不能 FLAG 报告为不合格」。
grep 复核：final_report.md 全文无「空白状态/greenfield/不误判/两种态」；其他域同样零命中。
实现现状：b74c2ff8 session 已验证了此能力（greenfield 报告 RC5 has_mermaid: false → PASS + regulator 判），但该能力保证从未作为设计需求被明确记录。
拟补条目（建议追加为 FR-14）：
#### FR-14 RC5 检测器不误判 greenfield 报告（两态兼容：有历史基础 vs 首次实现）
源 SP-FR-1 · provenance b74c2ff8 Q1（2026-06-15T11:08:45）· baseline none(NEW)
> 在完全空白的状态下，或者在已有一定实现基础上去做这种记录时，它能否处理好这些情况？
约束：RC5 检测器须正确处理两种报告态：
(1) 有历史实现基础（有 before）：要求报告的 (d) 段包含真实 before/after mermaid 双 subgraph，否则 FLAG。
(2) Greenfield（首次实现、无前态）：(d) 段中没有 before/after 图是合法的（无历史结构可取证），RC5 须 PASS，不误判。只有「有 mermaid 图但只写了 after 侧（after-only）」时才确定性 FLAG。
这一区分使 RC5 成为能实际使用的门，而非每次 greenfield 任务都需要手工规避的假警报。CAN-FR-B：HTML 格式特定失格问题——直接塞原始 MD 内容入 HTML、缺乏摘录、MD 不能正确渲染
来源：8f91b7e1 U4（2026-05-31T18:35:29）用户追加
逐字原话：
格式处理的 skill。具体到任务上，比如 HTML 或 MD 文档具体怎么写，这属于格式上的 skill。(a) HTML 内部有一些格式处理，但目前做得不够好。例如在展示文档历史变化的过程中，它倾向于直接把 MD 内容放进去，缺乏摘录，且 MD 在 HTML 中无法得到很好的渲染。这些是 HTML 处理中需要避免的。(b) 如果是用 MD 写作，在图像处理上则需要一些独特的内容。
分析：这是用户针对格式 skill 的 HTML 特定失格约束：HTML 报告不得直接嵌入原始 MD 块（不渲染 + 缺摘录），须单独处理（摘录 + 适当渲染）。baseline 的 cross_cutting XC-06 只说「格式 skill 与内容组织 skill 分离」，FR-13 只说「show-me HTML 视图延后」——均未捕获这条 HTML 格式的具体能力约束。
域归属判断：此条关于 HTML 格式处理，属于 final_report 域的格式 skill 范畴（报告写什么格式 = Final Report 交付物的形式定义）。FR-13 已明确 HTML 视图「延后」，但未说「当 HTML 格式启用时需避免此失格」。建议作为跨域路由条目记录：final_report 域列条目（HTML 格式启用时的避坑约束），路由到 cross_cutting 的 HTML 格式 skill 落地。
grep 复核：缺乏摘录/MD.HTML.渲染/直接把.MD.放进去 全域零命中，确认未记录。
拟补条目（建议追加为 FR-15，标注为跨域路由）：
#### FR-15 HTML 格式报告须避免三类失格（启用时约束，当前延后）
源 SP-FR-3 · provenance REQUIREMENTS_ORIGINAL_TEXT.md（W-04(a) session 8f91b7e1）· baseline none(NEW) · 路由 → cross_cutting HTML 格式 skill
> HTML 内部有一些格式处理，但目前做得不够好。例如在展示文档历史变化的过程中，它倾向于直接把 MD 内容放进去，缺乏摘录，且 MD 在 HTML 中无法得到很好的渲染。这些是 HTML 处理中需要避免的。
三类失格（当 HTML 格式报告启用时须避免）：
(a) 直接嵌入原始 MD 块——须摘录或渲染，不原样 copy；
(b) MD 在 HTML 中无法正常渲染——须使用渲染库（marked.js 等）或转为 HTML；
(c) 缺乏摘录——在展示文档历史变化时，须从 commit/diff 提炼精要，不做原文 dump。
状态：此条约束在 FR-13「仓库 native / HTML 视图延后」裁定下处于待启用（deferred）状态。HTML 视图基础稳定后激活。路由：格式 skill 落地属 cross_cutting XC-06 的子需求。§5 cross-domain 路由
以下候选在盲抽中发现、已归入其他域或需指针，不作为 final_report 域漏项，但应有路由说明：
| 关联内容 | 指向 | 说明 |
|---|---|---|
| RPT-01 (a)~(d) 全部四点（1c0c7409 U1） | cross_cutting XC-40 | FR-06/07 已显式 cross-ref，无遗漏 |
| 道术矩阵写报告路由（8f91b7e1 U3） | cross_cutting XC-41 | FR-09/10 已引用，无遗漏 |
| 易读性自检=完整记录变化（8f91b7e1 U4） | cross_cutting XC-42 | FR-04 + 域边界说明已引用，无遗漏 |
| 格式/内容 skill 分离（8f91b7e1 U4） | cross_cutting XC-06 | FR-13 + 域边界说明已引用，无遗漏 |
| HTML Modal 术语交互（9d362dae U4）——hover/click 浮层 | 无现有域（FR-13 延后同类 HTML 功能） | 暂时属于 HTML 视图延后范畴；如 HTML 视图激活，需建独立 HTML 报告格式域或在 final_report 域扩充 |
| SR-085 图像优先 workflow 类比（26c48576 U1-U2） | FR-01 历史耦合 SP-FR-4 | 已收录为历史耦合，无遗漏 |
路由数量：6 条（均已在 baseline 处理或标注延后）
§6 覆盖结论
覆盖判断：基本覆盖，但存在 2 条可信漏项（clean-new），覆盖置信度：高（12/13 baseline 项逐字验证）+ 2 条追加建议。
证据链
- session 全集确认：5 个建设 session（b74c2ff8/1c0c7409/8f91b7e1/9d362dae/26c48576）全量抽取。b74c2ff8 通过
extract_session_text.py核验（977 行 JSONL，real_user=6）；其余 4 session 从session_task_taxonomy_20260610/data/extracts/预抽文件直接读取。
- baseline 覆盖完整性：FR-01~FR-13 共 13 条，对账结果全部找到原始来源 session 的对应 turn，逐字 provenance 链完整。
- 两条 clean-new 发现：
- CAN-FR-A（RC5 greenfield 不误判）：来自 b74c2ff8 的追加 Q&A turn，是已实现但从未作为设计需求被明确记录的能力约束。
- CAN-FR-B（HTML 格式失格三类）：来自 8f91b7e1 的追加 turn，跨越 XC-06 的格式/内容分离通则，是 HTML 格式的具体失格约束（延后条件下仍应记录）。
- 边界内零遗漏：9d362dae 的 HTML modal 交互需求（U4）和 HTML 前端迭代（U5-U11）经 FR-13 域边界判断属于「HTML 视图延后」范畴，不属于 final_report 域当前职责，不计漏项。
- cross-domain 引用完整：FR-06/07 引用 XC-40、FR-09/10 引用 XC-41、FR-04 引用 XC-42、FR-12 引用 RT-45/UP-08——经 grep 复核，cross_cutting + runtime 域均已收录对应原文。
诚实边界
- CAN-FR-A 的能力已实现（b74c2ff8 session 实测验证过），但从未作为设计需求条目被写入。将其补入是设计文档的忠实性问题，而非实现补全。
- CAN-FR-B 是延后条件下的约束记录。当前 HTML 视图未激活，补入属于前瞻性需求锚定，使将来启用 HTML 时不会丢失此约束。
- 未覆盖来源：
bestpractice_chat_history_retrieval类工具的调用日志（非 final_report 建设 session）、BG-1 补录 session（仅状态勘误，非设计需求追加）。
结论：final_report 域 FR-01~FR-13 基本完整。发现 2 条 clean-new 漏项（CAN-FR-A / CAN-FR-B），建议补入为 FR-14 / FR-15。6 条 cross-domain 路由均已在 baseline 处理或标注延后，无路由遗漏。