第七章：总结与后续工作

7.1 本次取证的确定性边界

7.1.1 确定性等级划分

本文所有结论按证据强度分为三级：

7.1.2 本文未使用的推断方式

为避免虚构，本文刻意回避了以下三种常见但不可靠的做法：

1. 不基于 naming 推断行为：例如 cds-pill-roll-out 的命名暗示「滚出」，但本文只记录关键帧数值，不描述其触发条件与视觉轨迹
2. 不基于 v2 文档补全 v3：v2 的基线已失效（见 第一章），其结论不能直接继承
3. 不基于「合理推测」填零值：例如 utility_processes = 1 与本文实测的「0 个 fork 调用点」冲突时，本文标注为 unknown 而非二选一

7.2 已完成的结论清单

7.2.1 版本与取证基础

7.2.2 Electron 架构

7.2.3 设计系统底座

7.2.4 骨架屏机制（issue #25 的核心）

7.2.5 open-claude-ui 差异

7.3 明确的未知项

以下各项本文无法确定，列出原因与可用的进一步手段。

7.3.1 已全部解决

原列的两项「需运行时观测」已通过 Claude 自带的 Enable Main Process Debugger 取得运行时事实（见 6.7）。

7.3.1.1 已在第六章解决

以下项原本列在未知清单中，第六章完成后已给出确定答案：

7.3.2 需要历史版本

7.3.2.1 第六章 6.10 新增的待验证项

7.3.3 需要组件源码

7.4 建议的后续工作

7.4.1 对 open-claude-ui 仓库

第一优先（P0，4 项）

1. 修复 .cds-skeleton-sweep 独立类把元素移出视口
2. 修正 --cds-clay-emphasized 为 #c6613f
3. 修正骨架屏暗色 base/sheen 为 hsl(from var(--cds-neutral-900) h s l / 7.5%)
4. 修正 CI 门禁在判断消费前剥离注释

第二优先（P1，3 项）

5. 补 RTL 的 animation-direction: reverse
6. 实现 data-hold 三态揭示时序
7. 修正 wave 模式用 cds-skeleton-breathe 而非 sweep

第三优先（P2，3 项）

8. 补 cds-placeholder-reveal 关键帧
9. 补 9 个 cds-pill-* 关键帧
10. 用 :where() 降低 .cds-skeleton 的 border-radius 特异性

详见 5.5 修复优先级总表。

7.4.2 文档层面

v2 文档处理

建议在 docs/v2/ 各文件的 frontmatter 增加：

status: historical
superseded_by: "docs/v4.29.0-4.4212.0/"
verified_against: "2026-10-15"

不要在 v2 里补充 3.6556.2 的数字——基线已不同，混写会产生新的错误。

v1 文档

docs/v1/ 同样引用了 2.37337.1（共 16 个文件 36 处），需做同样处理。

7.4.3 对 REA 工具

本次取证暴露 REA 6.8.0 的三个问题：

问题 1：--source-path 在 inventory 部分失效时不可用

rea analyze-javascript-application app.asar --source-path ".vite/build/index.pre.js"
→ invalid_value: "Select an exact relevant file path from the artifact inventory"

但从 REA 自己的 asar-entry 节点取出的路径就是 .vite/build/index.pre.js。

原因（源码 src/artifacts/javascript/JavaScriptArtifactFiles.ts:104）：

const issues = (sourcePaths ?? []).flatMap((path, index) =>
  expected.has(path) || inventory.unavailableFiles.has(path) ? [] : [...]
);

expected 来自本次运行的 inventory。当 inventory 因预算截断而不完整时，选中的路径恰好落在失效部分，导致定向补全这条恢复路径被完全切断。

问题 2：utility_processes 与 resolved_utility_entrypoints 语义冲突

summary.utility_processes            = 1
summary.resolved_utility_entrypoints = 0

实测代码中 utilityProcess 仅 3 处，全部是对 fork 的 Proxy 包装，无实际调用点。两个字段并列时读者会误以为「有 1 个 utility process 但入口未知」，而实际可能是「Proxy 包装被计数了」。

问题 3：context_bridge_apis 的口径不明确

同一份取证中：

四个数字都对，但口径不同且未在文档中说明。

7.4.4 下一步技术验证

若要继续深入，建议按以下顺序：

7.5 本文的可复现性声明

本文所有 A 级结论都可通过以下三条命令的任意组合复现：

# 1. 确认版本与摘要
shasum -a 256 "/Applications/Claude.app/Contents/Resources/app.asar"

# 2. 抽取主样式表（ASAR header: uint32LE@12 = JSON 长度，JSON 从偏移 16 开始）
node -e '
const fs=require("fs");
const p="/Applications/Claude.app/Contents/Resources/app.asar";
const fd=fs.openSync(p,"r");
const h=Buffer.alloc(16); fs.readSync(fd,h,0,16,0);
const hs=h.readUInt32LE(12);
const jb=Buffer.alloc(hs); fs.readSync(fd,jb,0,hs,16);
const J=JSON.parse(jb.toString("utf8"));
const n=J.files[".vite"].files.renderer.files.main_window.files.assets.files["MainWindowPage-BjVtjJFx.css"];
const b=Buffer.alloc(n.size); fs.readSync(fd,b,0,n.size,16+hs+Number(n.offset));
fs.writeFileSync("/tmp/MainWindowPage.css", b);
'

# 3. 验证任意一条清单
grep -o "@keyframes [a-zA-Z0-9_-]*" /tmp/MainWindowPage.css | sort -u | wc -l    # 55
grep -o "\[data-cds=[A-Za-z-]*\]" /tmp/MainWindowPage.css | sort -u | wc -l      # 45
grep -o "@property --cds-[a-zA-Z0-9_-]*" /tmp/MainWindowPage.css | sort -u | wc -l  # 24
grep -c "\--cds-clay-emphasized:" /tmp/MainWindowPage.css                        # 1

若 Claude Desktop 升级，MainWindowPage-*.css 的文件名 hash 会变化，上述路径需按 ASAR 目录树重新定位。ASAR 根摘要也会变化，本文所有结论需重新验证。

本章证据索引

本文为总结章，不引入新事实。所有断言均指向前述章节，前述章节各自带有代码证据。