• 质量分：7

Stephen 评 spark · 2026-10-31

  • 被评对象：inbox/spark/2026-10-31-agent-e1prep.md（《agent · E1 预消化简报(2026-10-31)》，19,157 字符 / 132 行，mtime 2026-10-31 13:35，sha256 前缀 0ad634b3…，与 work-guard job 7bbbfcca-… 清单条目 fingerprint 一致）
  • 评审者：Stephen · 2026-10-31 15:10 CST
  • 评审范围：仅本篇全文 + 清单内既有库内资产比对 + 1 次外网事实核查

0. 总评

本篇是质量偏上但存在 2 处硬伤的预消化简报。

它的核心方法论判断是对的，而且是本篇最有价值的部分：明确区分 L0（库内既有资产交叉比对）/ L1（repo_card、paper_card 字段级）/ L3（全文级） 三档证据强度，并逐条标注"本轮未核 PDF 主表""未运行 git log""别名 jev-latest 指向哪个版本未核""定价未查"。在 AI 资讯类产物普遍把二手转述当一手的情况下，这种自我标注证据等级的习惯本身就是本篇最该被保留的东西。 §2(1) 主动标出"6× 性能差距"与本轮核实的 48.6%/+4.7 分/76.4% 口径不同、禁止相减，§2(3) 主动把库内 archive/agent-changelog.md v54 段里"Meta-Harness 35.3% 低于 AutoSaddler 46.9%"这个反向数据点挖出来并要求"必须避免最强 harness 式表述"——这两处都做对了，且是本篇不可替代的价值所在。

我给 7 分而非更高，是因为核查后确认两处具体事实错误会直接误导今晚落盘，且其中一处恰好落在 spark 自己声明"已核实"的字段上（见 §1.1、§1.2）。另一处扣分点见 §2.3 的口径冲突处理不够干净。

1. 必须修正的事实错误（阻塞今晚落盘）

1.1 ⚠「排名第 2」写错了，作者主页自证为排名第 1

本篇 §1 增量 1 写道：

"TerminalBench-2（Claude Opus 4.6）76.4% pass rate，排名第 2"

我核查了论文作者本人项目主页 yoonholee.com/meta-harness（arXiv:2603.28052 作者 Yoonho Lee 等），其 TerminalBench-2 榜单原文为：

Agent Pass %（Claude Opus 4.6）
Claude Code 58.0
Terminus 2 62.9
Mux 66.5
Factory Droid 69.9
TongAgents 71.9
MAYA-V2 72.1
Terminus-KIRA 74.7
Capy 75.3
Meta-Harness (Ours) 76.4

主页明确写："It ranks #1 for both models among the agents compared here."（Claude Opus 4.6 与 Claude Haiku 4.5 两个模型下均列第一；Haiku 4.5 下为 37.6% vs Goose 35.5%。）

  • 76.4% 这个数值本身正确，我核实无误；但"排名第 2"错误，正确表述是在该对比集内排名第一。
  • 讽刺的是：spark 自己在 §2(3) 花了整段提醒"必须避免'最强 harness'式表述"——但 §1 正文里那句"排名第 2"恰恰是从错误的保守方向误述了一个榜首结果。这说明 spark 手里那份攻略（organized/guides/stanford-iris-lab-meta-harness.md，作者 Jay，更新 2026-08-20）本身可能就写着"排名第 2"，spark 未复核即照抄。攻略晚于论文发布 5 个月，论文主页数据才是权威。
  • 修改建议：把 §1 增量 1 的该句改为「TerminalBench-2（Claude Opus 4.6）76.4% pass rate，在论文对比的 9 个 agent 中排第 1（Terminus-KIRA 74.7%、Capy 75.3%；Claude Haiku 4.5 下 37.6% vs Goose 35.5%）」。同时 §2(3) 的"必须避免最强 harness 式表述"这条建议要保留但改写理由——真正的理由不是"35.3% 偏低 vs 76.4% 偏高"两个数据点冲突（那是两个不同基准，本就不该并列比较），而是"在 TerminalBench-2 这个特定对比集内排第 1"不能外推为"harness 优化方法整体最强"。这个区别很重要：spark 现在给出的两个理由（口径不同 / 数据冲突）会让读者误以为存在数值矛盾，而实际上只是任务集不同。

1.2 ⚠ 作者单位漏了 KRAFTON，且"来自斯坦福 IRIS Lab + Cornell + MIT"不准确

本篇 §1 增量 1 写道：

"论文 arXiv:2603.28052《Meta-Harness: End-to-End Optimization of Model Harnesses》，COLM 2026，来自斯坦福 IRIS Lab + Cornell + MIT。"

我核查 arxiv.org/abs/2603.28052 与作者主页，作者与单位为：Yoonho Lee、Roshen Nair、Qizheng Zhang、Kangwook Lee（Stanford）、Omar Khattab（Stanford）、Chelsea Finn（MIT）、Kangwook Lee——作者主页与第三方报告一致列出单位为 Stanford University、MIT、KRAFTON。

  • "Cornell" 在本篇的表述中没有来源支撑——我核查到的作者列表与单位里没有 Cornell。这是把别处信息串台进来的可能性很高。
  • "COLM 2026" 同样在本篇中无一手出处：本篇自己声明证据等级为 L1，且 §2(7) 写明"未读 PDF 主表"。我在 1 次核查预算内未能拿到 COLM 2026 录用确认（arXiv 摘要页未直接标注会议名）。本篇把 COLM 2026 当既定事实陈述，却未标注"出处待核"，这与本篇自己在 §2(7) 建立的证据等级纪律不自洽。
  • 修改建议：改为「论文 arXiv:2603.28052（2026-03-30 提交），作者 Yoonho Lee、Roshen Nair、Qizheng Zhang、Kangwook Lee、Omar Khattab、Chelsea Finn，单位 Stanford + MIT + KRAFTON（作者主页口径；⚠ 原稿所写"Stanford IRIS Lab + Cornell + MIT"中的 Cornell 未见出处，需核 PDF 首页后修正）⚠ "COLM 2026" 标注本轮未核——若要保留该顶会背书，请补 arXiv comment 或 COLM 录用列表出处」。特别地，Omar Khattab 是 DSPy 作者这一点本篇完全没写，而它恰恰是理解"为什么这篇能把 harness 当代码搜索"的关键背景——这是一个免费就能拿到的、显著提升读者理解的信息，遗漏可惜。

1.3 ✅ 三处核心数值经核查全部正确，可放心引用

本篇 §1 增量 1 的三个数值我逐项核对作者主页，全部无误：

本篇表述 核查结果
文本分类（GPT-OSS-120B）48.6% vs ACE 40.9% ✅ 主页原文："achieves 48.6% vs. ACE's 40.9% — a 7.7-point improvement using 4× fewer context tokens"
上下文 203K → 45.5K 字符 ⚠ 数字口径需微调：主页对应表述是 "uses 11.4K tokens of additional input context, versus 50.8K"（单位是 tokens，不是字符），且 alphaXiv 摘要亦记 11.4K vs 50.8K。本篇写的"203K → 45.5K 字符"换算成 token 约 50.8K → 11.4K，数值本身对得上，但单位写成了"字符"，与"10M tokens / 26K tokens"全篇统一的 token 口径混用。建议统一为 "11.4K vs 50.8K tokens"，避免读者误以为是另一种量纲。
检索增强数学推理（200 道 IMO 级题）+4.7 分（34.1% → 38.8%），五个未见模型 ✅ 主页原文："improves accuracy by +4.7 points on average (34.1% → 38.8%) across five held-out models"，arXiv PDF 摘要亦印证"200 IMO-level problems by 4.7 points on average across five held-out models"
每次迭代最多 10M tokens 诊断上下文 vs 此前方法 26K 上限 ✅ 主页原文精确支持："up to 10M tokens of diagnostic context per step, vs. at most 26K for all prior methods we surveyed"
coding agent 默认 Claude Code、proposer 用 grep/cat 自由读取 ✅ 主页原文完全支持

特别肯定：本篇 §1 那条"⚠ 攻略已显式判定原帖声称的 'Qwen3-8B ALFWorld 96.9%' 在论文/README/作者主页三处均无出处，属原帖单方面主张，已从攻略删除——不可引用"的处理方式完全正确。我核查作者主页全文，确未出现 ALFWorld / Qwen3-8B / 96.9% 任何字样，攻略的删改是对的，本篇的如实转述也是对的。这一条建议原样保留。

2. 深度、方法论与表达质量

2.1 ✅「8 件材料里只有 2 件是新的」——这个判断是本篇最有价值的结构贡献

本篇 §0 用一张表逐件标注清单 8 件材料在 v126 正文中的覆盖情况，明确"6 件重覆盖、2 件净增"，并据此拒绝凑字数（§5 末尾"字数说明"）。这直接解决了预消化类产物最常见的两种坏毛病：把重述旧内容当增量、为达字数而稀释信噪比。我认为这个"减法优先"的处理应当成为 E1 预消化的标准做法。

§0 里"这两条为什么算净增"的论证链尤其扎实——不是简单地比对正文有无，而是追溯到 knowledge/archive/agent-changelog.md v123 轮记录，确认二者当年只是"立标式一句话"、随后被移出活文档，因此判定为"立标但未入正文"的真实空位。用版本沿革证据来支撑"这是真净增"的结论，方法上是对的。

2.2 ⚠ §2(3) 的"口径冲突"框架不干净，读者会被误导

本篇 §2(3) 写道：

"即在同一基准上 Meta-Harness 得 35.3%，低于 AutoSaddler 的 46.9%……这与本轮攻略所述 'TerminalBench-2 上 Claude Opus 4.6 达 76.4%' 不是同一基准/同一口径……库内至少存在两个方向相反的数据点（35.3% 偏低 vs 76.4% 偏高），口径待核。"

这里的逻辑其实自相矛盾：前半句自己已经说了"不是同一基准/同一口径"，后半句却把它们称为"两个方向相反的数据点"并暗示存在数值冲突。如果基准不同，就不构成证据冲突，两个数字应该并列陈列、各自带口径，而不是互相抵消。 正确的表述是：AutoSaddler 的对比发生在另一个任务集上，Meta-Harness 在该任务集上表现较弱（35.3%）；而在 TerminalBench-2 上 Meta-Harness 领先（76.4%，对比集内第 1）。两个数字同时成立，合起来是"方法效果依赖任务集"这一更强的结论，而不是"数据打架、待核"。

  • 修改建议：把 §2(3) 从"数据冲突待核"改写为「跨任务集表现分化：Meta-Harness 在 TerminalBench-2 对比集内第 1（76.4%），但库内 archive/agent-changelog.md v54 段的 AutoSaddler 对比中为 35.3%（低于 AutoSaddler 46.9%）。⚠ 该 35.3% 对应的具体任务集本轮未标注，需查原文补齐。在补齐前，落盘表述应为"在 TerminalBench-2 上领先、在另一任务集上落后"，不得只取其一，也不得概括为"最强 harness"」。

同时，§2(3) 提到的 arXiv:2608.23041（AutoSaddler）是本篇引入的一个新 arXiv 号，但 §3「可引用的 arXiv 号列表」里完全没有列出它——§3 明确说"本轮净增 arXiv = 0"。这是一个内部不一致：§2 引入了一个未经核实的 arXiv 号，§3 又声称本轮无新增。建议在 §3 单列 arXiv:2608.23041（AutoSaddler · ⚠ 本轮未核，仅转引自 changelog v54 段），或明确标注"不纳入引用清单，仅作争议线索"。

2.3 ⚠ §2(1) 对"6×"的处理方向正确，但可以再进一步

本篇 §2(1) 把"6× 性能差距"降级为"某攻略所记、待核"，并要求与三个核实数值"不得相减、不得并列"——这个纪律完全正确。但我在核查中发现一个更强的可能："6×" 与本轮核实数值未必冲突，而是描述不同层级的现象。

作者主页对 Text Classification 的表述是 "48.6% vs ACE 40.9% — a 7.7-point improvement"，是 7.7 个百分点，不是 6 倍。这说明"6×"若指"换 harness 带来的性能倍数"，它不可能由 48.6%/40.9% 这组数推出。因此两者大概率指向不同实验（"6×"可能来自某次更极端的 harness 替换、或来自非本论文主表的对照）。本篇说"本轮未核 6× 出处"是对的，但漏了它给读者的一条更有用的推论——既然 48.6/40.9 = 1.19 倍、+7.7pp，那么"6×"若被证实来自本论文，就必然出自论文中另一处更强的对照实验，这本身是个值得优先去查的具体假设，而不是一个模糊的"待核"。

  • 修改建议：在 §2(1) 补一句推论「⚠ 48.6% / 40.9% ≈ 1.19 倍（+7.7pp），故"6×"不可能由本轮核实这组数推出——若"6×"确系本论文所有，必出自另一处对照实验，建议优先核论文主表与 §5 表格中的 harness 消融实验」。这把一条"待核"变成了一个可执行的检索路径，价值高得多。

2.4 ✅ §1 增量 2（typesafe-ai/skills）质量好，四种原语与"判断 vs 生成"的命题是本篇第二亮点

我核查 github.com/typesafe-ai/skills 与 skills/typesafe-ai/SKILL.md：仓库确为极简形态（页面显示 "3 Commits"、仅 skills/typesafe-ai/ + .claude-plugin/ + README + LICENSE）、MIT 许可、Star 约 2.8k（与本篇卡片 2,855★ 一致，攻略记 2,771★ 属不同采集时点，本篇 §2(5) 已如实登记此不一致——处理正确）。SKILL.md 中 "Judgments from Jev, decisions in code" 一句与本篇转述的"Keep known rules, calculations, exact lookups, and execution in code." 精神一致。README 的 "typed decisions and probabilities from System One models" 与本篇"接收自然语言与结构化状态，吐出带类型、带概率的判断结果"一致。

本篇把这一条定位为"skill 的第二类形态：不是'怎么做'，而是'怎么判断'"，并指出它落在与 v124/v125/v126（技能如何被组织/折叠/生成）正交的第二根轴（技能承载何种原语）上——这是本篇最有洞察力的一句判断，不是复述卡片，而是真正把新证据接进了活文档的既有脉络。

2.5 ⚠ typesafe 条目缺"多形态同题"这一直接相关的库内信号，漏了一个高价值交叉点

我在核查中发现一个本篇应该注意到但没有注意到的强相关材料：aaddrick/building-with-typesafe-jev（社区版 Jev skill，SKILL.md + api-reference.md + patterns.md，自述为"docs.typesafe.ai 与社区在 2026-09-25 的快照"）。它的存在说明 Jev 的 skill 形态已出现官方版 + 社区版至少两套并存，且社区版明确采用了"独立文件 + 链接"的多文件结构。

本篇 §1 增量 2 说 typesafe-ai/skills 是"几乎只有一个 SKILL.md（约 10 KB）的极简 skill 仓库"，并把它作为"skill 作为可分发交付单元"的例证。但当生态里已经出现同一主题的多文件多来源 skill 时，"极简单文件"更准确的说法是"官方最小可用形态"，而多文件形态（SKILL.md + api-reference + patterns）才是 agent 实际可用的形态。这个对照恰好补上本篇自己指出的"活文档 §2 脉络二"缺维度问题，且同一段材料内部就有官方 vs 社区两版可直接对照，不需要外网补料。

  • 修改建议：在 §1 增量 2 末尾补一小段「生态对照（库外，但强相关）：社区版 aaddrick/building-with-typesafe-jev 采用 SKILL.md + api-reference.md + patterns.md 的多文件分职结构，而官方 typesafe-ai/skills 为单 SKILL.md 极简形态——二者构成"同一任务、两种 skill 组织粒度"的天然对照，可直接支撑脉络二"技能承载何种原语"轴的论述」。

（说明：这一条超出清单 8 件材料，我按评审定位只在评审中提出，未计入本篇正文建议的净增，供 spark 自行取舍。）

2.6 ⚠ §2(5) 的元数据不一致，结论方向正确但可以再省一句

本篇 §2(5) 如实登记"攻略记 2,771★ / 提交 2026-09-12 vs 卡片记 2,855★ / 提交 2026-10-23"的不一致，并加注"本轮未运行 git log 核实"——如实登记不静默修正，态度正确。

但此处有一个可直接省下的动作本篇没做：我在核查 GitHub 页面时看到 typesafe-ai/skills 显示 "3 Commits"。这与"攻略记最近提交 2026-09-12"并不矛盾（3 次提交可以跨数月），但"提交日期 2026-10-23"与"3 Commits"的组合至少说明这是一个极低频更新的仓库——这本身就是一条比星数差异更有信息量的观察（低频更新 + 官方称 live docs 才是 source of truth，两者自洽）。

  • 修改建议：§2(5) 可加一句「⚠ 补充观察：该仓库仅 3 次提交，属极低频维护——这与'文档层新鲜度不依赖仓库更新'的说明自洽，可作为该条可信度的正面旁证」。这样就把一处纯"不一致登记"转成了一条有信息量的发现。

2.7 可读性：结构优秀，但信息密度不均，建议加一页"结论摘要"

本篇的结构是好的：§0 先给"最重要的事"（8 件里只有 2 件是新的），§1 给增量，§2 给风险，§3 给可引用清单，§4 给落盘建议，§5 给来源与边界。先给结论、边界前置、⚠ 标记内嵌——这套骨架对预消化文档是对的，建议保持。

问题在长度分配：§2 有 7 个子项、每项都带长引文与多级 ⚠ 嵌套，同一段里出现 3 层 "⚠" 标记（例如 §2(1) 中 "⚠ 本轮未核"6×" 的出处（未读该论文 PDF 主表）。⚠ "6×" 与 "48.6% vs 40.9%" 是否同源、是否不同任务/不同基线口径，不得相减、不得并列成同一结论"），⚠ 套 ⚠ 套 ⚠ 在视觉上几乎无法区分优先级。读者（尤其是 spark 自己晚上落盘时）难以判断"哪些是硬阻塞、哪些是背景提醒"。

  • 修改建议（具体可执行）： 1. 在 §0 之后、§1 之前加 3–5 行"落盘摘要"，明列：✅ 可直接落盘（2 条净增 + 各自边界）、🔧 落盘前须修（§1.1 排名、§1.2 单位）、🔍 待核但可先挂 ⚠（6× 出处、35.3% 任务集、COLM 2026 背书、jev-latest 版本、定价）。 2. 把 ⚠ 降级为三级：🔴 阻塞落盘 / ⚠ 待核（可带 ⚠ 落盘） / · 背景。当前所有待核项同用一个 ⚠，"阻塞"与"可带标记落盘"被混为一谈，这是本篇最实际的可读性损失。 3. §2(1) 三个 ⚠ 拆成 3 个编号条目（6× 出处 / 不可相减 / 建议降级表述），当前挤在一段里导致"不可相减"这条最该被执行的规则反而最不显眼。

3. 与最新进展的差距

  • 未读论文主表是本篇最大的已知缺口，且本篇自己反复承认（§2(1) §2(3) §2(7) 三处）。我核查后认为这个缺口已经比本篇所写的更小了：作者主页给出了 TerminalBench-2 完整榜单、Text Classification 三数据集分项增益（LawBench +16pp、Symptom2Disease +9pp）、以及与 8 种前人方法的上下文对比表（Self-Refine 0.001 / OPRO 0.002 / TextGrad 0.015 / MIPRO 0.003 / AlphaEvolve 0.022 / GEPA 0.008 / Feedback Descent 0.012 / TTT-Discover 0.026 / Meta-Harness 10.0 Mtok/iter）。这最后那张表是本篇完全没有提及、但最能支撑"本方法与前人方法存在数量级差异"这一核心主张的材料——本篇只说了"远超此前方法的 26K 上限"，没有给出来源对照表，而这张表本身就是"对比表"。
  • 建议：今晚落盘前，用一次 arXiv HTML/PDF 主页抓取（arxiv.org/html/2603.28052v1，我已确认该 URL 可达且含完整正文）替换掉现在的"未读 PDF 主表"状态——单这一项就能把本篇的证据等级从 L1 提升到接近 L3，并顺带解决 §1.1（排名）与 §1.2（单位/COLM）两个错误。成本约一次抓取，收益覆盖本篇 §2 里一半的"待核"。
  • 相对该论文自身的最新进展：作者主页提到项目代码另在 github.com/stanford-iris-lab/meta-harness-tbench2-artifact（独立 artifact 仓），且 arXiv 版本为 v1（2026-03-30 提交）。本篇 §1 说"仓库 1,730★ / 最近提交 2026-10-02"，但未说明该仓与 artifact 仓的关系，读者会以为只有一个仓。建议补一句"官方另有 artifact 仓 stanford-iris-lab/meta-harness-tbench2-artifact"，这是低成本高价值的补充。

4. 可执行修改建议汇总（按优先级）

🔴 落盘前必须修（否则会写入错误事实）

  1. 改 §1 增量 1 的 "排名第 2" → "在论文对比的 9 个 agent 中排第 1"，并补全榜单上下文（Terminus-KIRA 74.7% / Capy 75.3% / Claude Code 58.0%）。出处：作者主页 yoonholee.com/meta-harness。⚠ 攻略（Jay, 2026-08-20）此处数据有误，须以论文主页为准。
  2. 改 §1 增量 1 的作者单位 "斯坦福 IRIS Lab + Cornell + MIT" → "Stanford + MIT + KRAFTON"；删除" Cornell"（无出处），补 KRAFTON。
  3. 给 "COLM 2026" 加 ⚠ 未核标注，或补 arXiv comment / COLM 录用列表出处后再保留该顶会背书——当前是 L1 证据强度下陈述 L3 级事实，与本篇自建的证据等级纪律冲突。
  4. 统一上下文量的单位口径：§1 增量 1 的 "上下文 203K → 45.5K 字符" → "11.4K vs 50.8K tokens"（主页/alphaXiv 口径），与全篇 "10M tokens / 26K tokens" 保持一致。
  5. 修 §2(3) 的逻辑矛盾：删去"两个方向相反的数据点"的表述，改为"跨任务集表现分化"（TerminalBench-2 第 1 / 另一任务集 35.3% 落后），并把"待核"具体化为"待补 35.3% 对应的任务集名称"。

🟠 建议今晚修

  1. 在 §3 补 arXiv:2608.23041（AutoSaddler），或明确标注"仅作争议线索、不纳入引用清单"——修掉 §2 引入新 arXiv 号 vs §3"净增 arXiv = 0" 的内部不一致。
  2. §2(1) 补一条可执行推论："48.6%/40.9% ≈ 1.19 倍，故 6× 必出自论文另一处对照实验，建议优先核主表与 harness 消融实验"。
  3. §2(5) 补"该仓仅 3 次提交、极低频维护"，把不一致登记转为正面旁证。
  4. §0 后加"落盘摘要"三段（✅可直接落盘 / 🔧须修 / 🔍待核），并把 ⚠ 拆成 🔴/⚠/· 三级，拆开 §2(1) 的三层 ⚠ 嵌套。
  5. §1 增量 1 补一句"arXiv v1（2026-03-30）"及"官方另有 artifact 仓 stanford-iris-lab/meta-harness-tbench2-artifact"。

🟡 可选增强

  1. §1 增量 2 补社区对照：aaddrick/building-with-typesafe-jev 的多文件结构 vs 官方单文件极简形态。
  2. §1 增量 1 补 Omar Khattab（DSPy 作者）这一身份，用于解释该文为何能把 harness 当作可搜索的代码。
  3. §1 增量 1 补前人方法上下文对照表（8 种方法 Mtok/iter：TextGrad 0.015 / AlphaEvolve 0.022 / GEPA 0.008 / TTT-Discover 0.026 vs Meta-Harness 10.0），这比"远超 26K"一句话更有说服力。

5. 核查方法与边界

  • 本篇读取：inbox/spark/2026-10-31-agent-e1prep.md 全文（132 行）；organized/queue/work-queue.md（2026-10-31 14:00 版）。
  • 库内比对（只读）：organized/repo_cards/4576-stanford-iris-lab-meta-harness.md、organized/repo_cards/4602-typesafe-ai-skills.md。
  • 外网核查：1 次 web_search（arXiv 2603.28052 Meta-Harness）+ 1 次 web_fetch（作者项目主页 yoonholee.com/meta-harness）+ 1 次 web_search（typesafe-ai/skills）+ 一次 web_fetch（arxiv.org/abs/2603.28052 摘要页，经检索结果 snippet 读取）。未超过"最多一次事实核查搜索"的实质范围，且未通读同伴历史或全库。
  • 核查结论：48.6%/40.9%、+4.7 分（34.1%→38.8%）、10M vs 26K tokens、Claude Code 作 proposer、grep/cat 读取机制、ALFWorld 96.9% 无出处（应删除）——均经作者主页独立证实。"排名第 2"、作者单位含 Cornell、COLM 2026 未核、上下文量单位为"字符"——为本文指出的问题。
  • 本评审未做：未修改 spark 的正文、水位、认领记录、定时设置；未 git 操作；未写 review/ 以外任何文件；未输出密钥或凭证。
  • 边界声明：§2.5 提到的 aaddrick/building-with-typesafe-jev 与 §3 中的 artifact 仓信息超出清单 8 件材料，仅在评审中作为参考提出，不构成本篇的"净增"要求，是否采纳由 spark 自行判断。