knowhow_v1.md 30.3 KB

Edit Raw Blame History Permalink


knowhow_v1 — h3-intake（需求受理员）FDE Phase 1 Hunt · 仓库内信源挖掘

生成者：innovator-hunt（Hunter）｜任务：T-mtfzzh08（org-innovator P1，父任务 T-mtfyrrd0 master P1）
日期：2026-08-30｜性质：仓库内信源挖掘，无外网、无爬虫，信源全部是仓库内权威件
信源登记：同目录 sources_v1.json（S1–S15，每条含 path + 逐字 excerpt + sha256 前 16 位）
证据分级：A = 仓库一手权威件（agent 本体 / 真实 run 留痕）；B = 可操作第三方（判据写法范式）；C = 构造性推断，显式标注
纪律：零凭空引文。每条引文可按 path + 行号 + excerpt 逐字回查；查不到的写「未命中」，见 §6。


§0 结论速览


#
问题
结论
证据级别


1
h3-intake 的 brd 契约正源是什么
agent.md 六段（想拍什么/主角/场景/风格/时长约束/台词音频）+「假设与待补项」，六段缺一即没写完
A（S1 L30-37）


2
真实 run 里 brd 长什么样
与六段不同构：实际成品是「五问」+ 9 条可机器执行判据 S1–S9（干系人/痛点/度量/in-out scope/硬输入透传+冲突上报）；verify 按「五问齐备」判完整性
A（S4、S6 checks[A.完整性]）


3
最重的一条真实失败路径
attempt-0 被判 impl_bug：验收判据写不完整 + 把阈值推给图上不存在的 goal-benchmark 节点，5 条 remediation 打回重写 → attempt-1 passed
A（S6 / S5 id:25 / S7）


4
brd 的措辞必须数字准确到什么程度
verify 自己写的 remediation 示例都错（写「27 字」，实点 20 字），brd 侧重写时修正；同轮又自曝 S3(a) 针短语含标点→字面上永假
A（S10 L10 / S7 L19）


5
agent.md「总时长必须给死」在真实 run 是否被遵守
没有。真实 brd.md 全文 0 处「时长/秒」（机械核验），h3-story 只能自行拍板 10 秒级并上报 D1；h3-validator 的 J2 判据（brd 时长偏差 ≤10%）因此失据
A（S4 机械核验 / S10 L12 / S3 J2）


6
agent.md 落盘路径（workspace/01-intake）与实际是否一致
不一致。实际写入边界只许项目根 /app/data/companies/h3video/projects/p-9oi5fo/01-intake/brd.md，写 workspace 越界判失败；已被 verify 裁决「留痕根=项目根」
A（S1 L28 vs S8 冲突① / S5 id:19 root_path / S4 L78）


7
入口阻塞的两种真实形态
①引擎级 body_not_ready（本体三件套缺件，非 agent 自判 blocked）；②业务级 blocked（连「想拍什么」都没有→不硬造 brd）。两者根因层不同，不可混
A（S12 / S1 L49-52）


8
本轮 Hunt 对 Digest 的最大增量
12 条真实失败路径（§2）+ 8 条口径分歧（§4），其中 4 条需要上级拍板（C-1 路径、C-2 契约形态、C-3 时长缺席、C-7 goal-benchmark 禁令），全部只列证据未替选
A


§1 brd 契约正源（S1 = /app/system/agents/h3-intake/agent.md，A 级）
1.1 身份与成功标准（L3-6）

"把玩家/上级给的原始意图或剧本，整理成一份下游不用再回来问你的结构化需求（brd）——h3-story 拿到它能直接开工写故事，一个关键空缺都不用再问你，这就是成功。"

1.2 六段必填内容契约（L30-37，逐字）


段
agent.md 原文（摘）
行号


① 想拍什么
"一段话把片子讲清楚（题材 / 事件 / 要传达什么）"
L31


② 主角
"谁 / 是什么，外观、性格、已知设定；查不出的写 UNSPECIFIED 并列为待补项，不许编"
L32


③ 场景
"地点 / 时间 / 天气 / 环境要素"
L33


④ 风格
"视觉风格（写实 / 动画 / 赛博……）、情绪基调、参考作品（如有）"
L34


⑤ 时长约束
"目标时长（秒）与可接受区间，逐镜头数如何拆分留给下游，但总时长必须给死"
L35


⑥ 台词 / 音频
"有没有对白、旁白、歌词、音效要求；没有就明写"无台词""
L36


另加
「假设与待补项」："我替用户拍板的每一处，写"我按 X 理解，理由是 Y""
L37


1.3 五条验收判据（L42-46，逐字）

"01-intake/brd.md 存在且非空，六段齐全，grep 能逐段命中"（L42）
"六段里没有 TBD / 待定 悬空占位（进了「假设与待补项」的除外，且必须带理由）"（L43）
"每个主角 / 场景要素都能追溯到原始输入的原话，或明确标注为我的假设"（L44）
"时长约束是一个具体数字 + 区间，不是形容词"（L45）
"反向自测：假装我是 h3-story，只读这一份 brd 能不能不问任何人就开写 —— 不能就打回重写"（L46）

1.4 阻塞口径与定位（L48-58）

阻塞（L49-52）："原始输入连"想拍什么"都说不出来（空串、纯表情、与视频无关的指令）→ 不硬造 brd，如实上报 blocked，写明缺的是哪一段、需要用户提供什么"；"宁可 blocked，也不交一份编满主角设定的"看起来很完整"的 brd —— 它会在 h3-validator 处爆雷，浪费整条链一整轮"
Never（L54-58）：不替用户编造核心主体外观（那是 h3-asset 的活）；不越级写故事/分镜/提示词；不把交付物写到 01-intake/ 以外；不在 brd 里写不可判定的形容词当验收标准
落盘路径（L28）："/app/data/companies/h3video/workspace/01-intake/brd.md" —— 见 §4 C-1：与真实 run 的写入边界冲突


§2 真实失败路径清单（Digest 出判据的主原料，12 条，每条带 run 证据）

本节是本轮 Hunt 的核心交付。F1–F12 全部来自 h3video 公司真实 E2E run（2026-08-30），不是方法论推演。

F1 【引擎级阻塞】本体三件套缺件 → body_not_ready，整 run 一节点即挂

证据：S12（run_2dd4e3dcfb42/stream.log id:16-19，2026-08-30T11:59:43.773Z）


node.boundary：{"missing":["agent.md","soul.md",".claude/skills/main_skill/SKILL.md"],"degraded":"body_not_ready"}
output_excerpt："本体 h3-intake 仍缺角色定义（agent.md, soul.md, .claude/skills/main_skill/SKILL.md），本节点未派发真实调用"
状态链：fail → blocked，理由 "没有可走的 fail 边或已撞熔断硬顶，等人工介入"；整 run blocked:1, pending:6

教训（Digest 可用判据）：这是引擎判的 org 装配缺口，不是 h3-intake 自判的业务 blocked——两种"阻塞"根因层不同（见 §4 C-5），brd 判据若只写"缺输入→blocked"会漏掉这一类。同型实例还有 budget-exhausted（F8）。
关联：S11 L13（CEO 排查）："7 节点中 6 个……仍是 _base 通用骨架（首行 LEMONBOSS_BASE_SKELETON 哨兵未除）……图引擎的 missingBodyDefinition 判 body_not_ready，全链必卡"

F2 【伪"已核实"反例】上游规划文档声称本体就绪，与实际相反

证据：S11 L13："orggraph-plan.md §7 声称「已从 base 继承出完整本体，可直接上岗 needsTraining=false」与实际不符，是本次阻塞的直接来源"
教训：S13（orggraph-plan.md）是权威件，但其 L116-118 的招聘记录（"已从 base 元 agent 继承出完整本体，可直接上岗"，needsTraining=false）是未经验证的书面声称——权威文件里的声明也要用哨兵 grep 实测复核，不能当作已核实事实引用。与 dream 提炼的「信源取不到就降级、不冒充已核实」同源。

F3 【核心判例】brd attempt-0 被判 impl_bug：判据写不完整 + 责任指向图上不存在的节点

证据：S6（rn_ff54bc9cfcfb/attempt-0.json，verdict=attributed，fail_reason=impl_bug）+ S5 id:25
8 条 checks 中 5 条不过，逐条摘录：


A.一致性（S6 L9）："brd.md §3-S3 写「原台词逐字见 §6-A，唯一基准」（逐字），contract.json success_metrics[2] 写「与原台词语义一致」（语义）……validator 届时可以任选宽松的一个判 pass"
A.覆盖task-goal（S6 L10）："brd.md §3 末注写「S3/S4 的具体阈值与权重由 goal-benchmark 定」，但本张 work graph……不存在 goal-benchmark 节点——阈值被推给一个不存在的产出者"
B.0形状（S6 L11）："goal-contract validate 退出 2：ERROR 没有 acceptance.json……验收三件套（benchmark/test_data/test_script）完全没有产出者"
B.1可度量（S6 L12）："S3 无任何数字门槛（ASR 识别中文台词几乎不可能逐字+标点全对，不设阈值则 pass/fail 全凭 validator 裁量）；S4「两个主体均出现」无帧数/镜头数采样规则"
B.2覆盖需求（S6 L13）："3 条硬约束指不到任何验收判据：①交付形状 F……②立绘绑定规则与 forbidden_reference_variants……③「油灯是唯一光源」「中式古风恐怖」在 S4 里没有落点"
B.3平凡通过（S6 L14）："全部判据都落在 07-validator/verdict.md 的自由裁量上……标准写成「validator 到时候看一眼」，怎么判都对"

根因（S6 L18）："规划节点自己把验收标准写进了 BRD §3，却既没写完整（漏两条硬约束的判据、缺阈值），又把补全责任指向图上不存在的节点。"
remediation「下一轮必须」5 条（S6 L18）：1) S3 改可度量写法（双短语逐字包含 + 字符一致率 ≥90%）；2) S4 补采样与计数规则（首/中/尾 3 帧、各 ≥2 帧）；3) 新增交付形状 F 与立绘绑定的确定性判据；4) 新增场景设定判据（油灯+屏风 / 风格词）；5) 全部落成 contract.json success_metrics 可判定条目并同步 brd §3。

F4 【数字口径错】验收措辞里的数字本身错了（27 字 vs 实点 20 字）

证据：S10 L10（e2e-trace.md 12:25 行）："S3 改为 ASR 短语逐字包含 + 20 字一致率 ≥90%（两处同文；修正 remediation 示例的「27 字」为实点 20 字）"
S7 L11（verify attempt-1 独立复核）："独立核算过数字：原台词去标点「对不起我不是有意闯进来的外面有东西在追我」确为 20 字、含 2 逗号 1 句号共 23 字，S3 的 90% 分母正确，90%=18 字"
S9 L36（contract.json）："player_intent_line_char_count": { "no_punct": 20, "with_punct": 23, ... }
教训：brd 里每一个数字（阈值、分母、计数口径）都必须独立核算后落盘——打回方的示例措辞同样会错，不能照抄。Digest 可直接出一条「brd 数字自核算」判据。

F5 【字面永假判例】S3(a) 针短语含标点、被检文本已去标点 → 字面上永远为假

证据：S7 L19（verify attempt-1 B.1 非阻塞 ⚠️）："S3(a) 引号内的针文本含逗号，而被检文本已去标点——针必须做同样的去标点归一（即比对「对不起我不是有意闯进来的」「外面有东西在追我」），否则 (a) 字面上永假。此句式源自上一轮 remediation 示例，责任在本岗，不记为被验产物缺陷"
后续 4 个节点交接里被反复重申（S5 id:68 / id:113 / id:143；S10 L13/L15/L17）——一个措辞瑕疵沿链条传播了 4 轮。
教训：判据句要写归一化前置条件（"双侧同去标点后再比"），否则下游每个节点都要口头补救一次。

F6 【判据违反却放行】agent.md 判据4「时长是具体数字」在真实 run 未被遵守

机械核验（本轮 Hunt 亲自做）：S4（真实 brd.md，89 行）全文 0 处「时长」「秒」（python3 逐行 grep 实测，sha256 be168e2ae0855ce8）。
下游实证（S10 L12，e2e-trace.md 12:48 行 h3-story）："上报 1 处自行拍板（D1：brd 未给数字时长，按台词 20 字≈6 秒拍板 10 秒级/4 拍，写明回退路径）"
链条后果：h3-validator J2 是"成片总时长与 brd 时长约束偏差 ≤10%"（S3 L63）——brd 无数字时长 → J2 无判据基准；brd 的 S1–S9 也没有任何时长判据，sdd 的 10.0s 台账成了事实基准（S10 L18）。
分歧定性：agent.md L35/L45 的硬要求 vs 真实 run 全链绕过且 verify 放行。这是本轮最需要上级拍板的一条（§4 C-3），我未替选。

F7 【索引簿记型失败】交付物已产出却判 missing_required_input（kind=prd 零实例）

证据：S5 id:71-72（rn_06a5e4353583 h3-story-validator）："missing_kinds":["prd"],"degraded":"missing_required_input"；id:68 verdict 本身是 passed（内容判词与引擎硬判两层不可混）
修复（S10 L14，12:58 行）："attempt-0 轮本节点私有目录只有 attempt-0.json（簿记，被排除）与 contract.json（被认领成 kind=contract），文件名一对一兜底认领失效 → 声明的 produces:[prd] 无实例 → 引擎硬判……修复：prd.md 副本落节点私有目录 rn_c4f87100bdb0/，与项目根 02-story/prd.md cmp 逐字节一致（7376 B），故事内容零改动"
复发预防：S5 id:113（h3-asset-validator 交接③）："若下游 h3-storyboard 判 missing_required_input（kind=artifact 零实例），根因在索引认领不在图形状——02-story 环节的解法是让产出者把副本落进自己私有目录，请按此口径处理，勿回炉重写资产包内容"
教训：「产物按 kind 命名 + 节点私有目录留字节一致副本」是硬纪律，否则内容再好也过不了引擎索引。

F8 【资源型阻塞】budget-exhausted 把跑到一半的链挂起（超的是 2h 墙钟，token 富余）

证据：S5 id:133（13:59:54）："run.status running→blocked，blockReason":"budget-exhausted"，summary："预算耗尽：整棵 run 树挂起等人工（不是失败）"（此时 7 节点 success 3 个，h3-storyboard 跑到一半）
续跑（S5 id:138 / S11 L29）：budget.extended wallclock_ms:14400000 后 blocked→running；"超的是 2h 墙钟，token/调用数都富余……agent 侧 internal token 在 /api/graph-runs/* 被 requireAuth 挡死，实测 401；不建议取消重跑——新 run 不继承旧节点产物且 2h 墙钟必再撞"
教训：blocked ≠ 失败；brd/判据里要区分"业务阻塞"与"资源挂起"，且挂起后的正确动作是续跑而非重跑（新 run 不继承旧产物）。

F9 【拓扑缺口】goal-contract validate 退出 2 / acceptance.json 无产出者——每轮都现、每轮都不打回

证据：S6 L11（attempt-0 判 fail 时）与 S7 L16（attempt-1 判 passed 时）同一条 B.0；S10 L11/L13/L15/L17/L19 五轮 trace 同记："B.0 goal-contract validate 退出 2（无 acceptance.json）——沿既定裁决记 org graph 拓扑缺口不再打回，代以 brd §3 S1–S9 人工三审"，并升级："请求 org 层 validator-triager 把「三件套无产出者」列入拓扑缺口清单（这是升级备注，不是 work 层归因）"（S7 L16）
教训：判据层要有「依据缺失 ≠ 产出不合格」的显式降级通道（h3-validator.md L28-29 已有同款："不许把"我读不到依据"混同成"片子不合格""）。

F10 【判据偏严风险】S4 帧采样规则可能误杀合格成片

证据：S5 id:68（h3-story-validator 交接）："S4 采样偏严风险——白衣女子按 PRD 只在 B3/B4 出现（约片长后 40%），首/中/尾等距 3 帧里她很可能只占尾帧 1 帧，严格计数会对合格成片误判 fail；PRD 已用 B3 两人同框对冲，h3-storyboard 拆镜头时请让 B3 尽量落在中帧附近，h3-validator 判 S4 时若中帧恰在 B2/B3 边界应记实测帧位而非直接 fail"
教训：brd 写采样判据时必须连同上游出现时序一起核（该主体在哪几拍在场），否则"各 ≥2 帧"这类看似客观的数字判据会系统性误判。

F11 【UNSPECIFIED 实判例】上游无设定 → 下游叙事绕开而非编造

证据：S10 L12（prd 12:48 行）："追兵全片不出现（brd 无设定，叙事绕开：惊恐由撞门/抵门/喘息/压低嗓音承担，不造形象）"
对应契约：S1 L32（intake：查不出的写 UNSPECIFIED 不许编）+ S2 L17-19（story：能绕开的绕开并写明绕法；绕不开且是叙事支柱的 blocked）。真实 run 走的是"绕开"分支且写明了绕法——契约两段咬合成功。
注意：追兵是 h3-story 层的绕开；h3-intake 层的对应判例（brd 阶段即把无设定项登记为待补项）在真实 run 中没有直接样本，见 §6。

F12 【输入冲突实判例】文字设定与参考图冲突 → 最小改动（蜡烛写明未点亮）

证据：S10 L12（D3）："油灯唯一光源 vs 参考图桌上有蜡烛——以 brd 为准，蜡烛按未点亮道具保留，请下游勿画成光源，否则干扰 S5(a)"
冲突事实源头：S9 L44 scene 参考图 role："昏暗旧屋，五扇雕花屏风，圆石面桌上一支蜡烛，右侧罗汉床，墙上挂轴"
呼应（B 级范式）：S14 L220 benchmark_v2 D8 子块 A 的"最小改动"原则："「油灯是唯一光源」+ 场景有蜡烛 → 蜡烛保留但写明未点燃，不能把两者都写成发光源"——同一判例在 h3-video-prompt 的 F3 失败模式里被独立验证过，跨 agent 复现。
教训：brd 透传硬输入时要显式登记参考图可见内容与文字设定的冲突点及裁决，否则下游每个节点各自临场裁决。


§3 下游消费方对 brd 的真实需求
3.1 h3-story 的五段 prd 契约与 brd 的逐段映射（S2，A 级）


h3-story prd 五段（S2 L25-32）
对 brd 的依赖
咬合点 / 真实 run 实证


① 故事梗概（150 字内起承转合）
brd 段①想拍什么
brd §1/§2 给了题材与痛点，prd 直接承接


② 叙事节拍（beats，编号）
brd 段⑤时长约束（"拍数要和 brd 的时长约束量级匹配：10s 级 3-5 拍，30s 级 6-10 拍，并在文末写明换算依据"，S2 L28）
brd 缺数字时长 → h3-story 只能自行拍板 D1（S10 L12），见 F6


③ 角色清单
brd 段②主角（"继承 brd，不新增设定"，S2 L29）
实证：prd 2 角色"均溯 brd §6-C/§6-D"（S10 L12）；追兵无设定→绕开（F11）


④ 场景清单
brd 段③场景（"时间/天气/环境要素（继承 brd）"，S2 L30）
实证：1 场景昏暗旧屋；D3 蜡烛冲突登记（F12）


⑤ 音频设计
brd 段⑥台词音频（"原文逐字给出（brd 说"无台词"就明写"全片无台词"）"，S2 L31）
实证："唯一台词逐字在 B4，无旁白无 BGM"（S10 L12）——brd §6-A 台词唯一基准被逐字继承


h3-story 的阻塞口径（S2 L45）："brd 缺失 / 为空 / 关键支柱标注 UNSPECIFIED 且无法绕开 → blocked 上报，不造故事" —— brd 的"不许编"纪律直接决定下游有没有活干。
h3-story 对 brd 的反向判据（S2 L39-40）："角色/场景清单与 brd 一一对应，没有引入 brd 之外的新设定（新增氛围细节须标注为创作补充）" → brd 里每一个设定项都会变成下游的约束，brd 多写一条无依据设定 = 下游多一条要么遵守要么报偏离的负担。

3.2 h3-validator 对 brd 的两个引用点（S3，A 级）

J2（S3 L63）："成片总时长与 brd 时长约束偏差 ≤10%"（前置判据）——brd 的时长数字是 J2 的唯一基准；brd 缺数字 → J2 失据（F6）。
J6（S3 L67）："音轨转写与 brd/prd 台词逐字一致（或双方均为无台词）"——brd §6-A 是台词唯一基准；真实 run 中 brd 把台词原句 + 去标点 20 字口径写死（S4 L65-66、S9 L34-36），J6 有落点。这是 brd 硬输入透传做对了的直接样本。
brd 的整体地位（S3 L24）：brd 路径 01-intake/brd.md 在 validator 输入表里标注用途 = "判"拍对了没"的原始基准"。
S1 L38 同义："brd 是全链的验收基准：h3-validator 靠它判"拍对了没"，所以它的措辞要能被逐条核对，不要写"要好看一点""有质感"这种没法判定的形容词。"
佐证（brd 自己写出了这条要求）：S4 L38 "brd 是全链的验收基准：h3-validator 靠它判"拍对了没"，所以它的措辞要能被逐条核对，不要写"要好看一点""有质感"这种没法判定的形容词。"


§4 冲突与口径分歧对照（发现即登记，不许静默择一）

每条只列双方证据与影响，裁决权留给上级 / Digest。C-1/C-2/C-3/C-7 建议进「待上级拍板」清单。

C-1 落盘路径：agent.md 写 workspace，实际写入边界只许项目根（需拍板：是否改本体）

甲方（S1 L28）："落盘路径（固定）：/app/data/companies/h3video/workspace/01-intake/brd.md"
乙方（真实 run）：S5 id:19 node.boundary root_path=/app/data/companies/h3video/projects/p-9oi5fo；S8 冲突①原文："任务原文要求每环留痕写到 /app/data/companies/h3video/workspace/，但本次调用的写入边界硬约束只允许项目根……越界会被判失败"；S4 L78 已裁决行："留痕根 = 项目根 /app/data/companies/h3video/projects/p-9oi5fo，以写入边界为准，下游照此执行，不再阻塞"
影响：agent.md 的"固定路径"在当前引擎边界下必错；每个真实 run 都要走一遍同样的冲突上报 + 裁决。
我方动作：不改 master/agent-creator 的文件（dream 倾向：修正权留给文档所有者），登记于此交上级。

C-2 brd 契约形态：agent.md 六段 vs 真实成品的「五问 + S1–S9」（需拍板：训练判据以哪个为基准）

甲方（S1 L30-37）：六段（想拍什么/主角/场景/风格/时长约束/台词音频 + 假设与待补项），判据 1 按"六段齐全，grep 能逐段命中"（L42）
乙方（S4 + S6 checks[A.完整性]）：真实 brd 是"五问"结构（"brd.md 五问齐备（干系人/痛点/度量/in-out scope/硬输入透传+冲突上报），无空标题章节"），verify 按此判完整性
影响 Digest 最直接：判据若按 agent.md 六段写 grep 命中，会对真实 pass 产物误判 fail；若按五问写，又偏离本体正源。两者不是互斥替代——真实 brd 的 §6 硬输入透传其实覆盖了六段的内容（主角 §6-C/§6-D、场景 §6-B、台词 §6-A、风格 §6-B），但没有覆盖段⑤时长（见 C-3）。
补充事实：真实 run 的产出方是 work graph 内部节点 h3-intake-brd（system agent id=brd-planning，S5 id:17），不是 org 节点 h3-intake 本体直接下场；brd-planning 自己的本体未在本轮信源内（见 §6）。

C-3 时长约束：agent.md 硬要求给死 vs 真实 brd 0 处时长、verify 放行、下游代拍板（需拍板）

甲方：S1 L35 "总时长必须给死"、L45 判据4"时长约束是一个具体数字 + 区间"
乙方：S4 全文 0 处「时长/秒」（机械核验）；S10 L12 下游自认"brd 未给数字时长，按台词 20 字≈6 秒拍板 10 秒级/4 拍"；S3 J2 因此失据
影响：h3-validator 的 J2 在本轮实际无判据基准；若 Digest 把"brd 必含时长数字"写成硬判据，会与"真实 run 已通过验收"的事实冲突——需上级裁决：是 brd 判据漏项，还是任务原文本就没给时长、brd 应当上报待补项（S1 L37 的「假设与待补项」机制在此未触发）。

C-4 verify 示例措辞自身的数字错误（27 字）与 S3(a) 标点永假——打回方的判据也要被验

证据：F4 + F5（S10 L10 / S7 L11 / S7 L19）
教训：Digest 出判据时，判据句本身要过一遍数字核算与归一化前置条件检查——本轮打回方（verify）的示例措辞两处瑕疵，一个被 brd 修正、一个沿链条传播 4 轮。

C-5 「阻塞」一词在系统里有三个不同根因层，判据必须分层写

① 引擎级装配缺口：body_not_ready（S12，本体三件套缺件）——agent 自判 blocked 判不到它
② 业务级输入不足：h3-intake 自判 blocked（S1 L49-52，连"想拍什么"都说不出来）
③ 资源级挂起：budget-exhausted（S5 id:133，"等人工（不是失败）"，续跑而非重跑）
影响：若训练判据只写"缺输入→blocked"，会把三类混为一谈；三类各自的正确动作（补本体 / 上报缺什么 / 追加预算续跑）完全不同。

C-6 引用不存在节点的禁令是运行中长出来的，agent.md 没写

甲方：S1 全文没有"不得引用图上不存在的节点"这类条款
乙方：S6 L10 判 fail 的直接原因之一就是 brd 写了"阈值与权重由 goal-benchmark 定"而图上无该节点；S6 L18 remediation 第 5 条明文"不得再引用它"；S9 L77 contract 还留了"角色越权提示"
影响：这是真实失败换来的新规则，建议 Digest 收进判据（brd 写验收口径前先核本张 work graph 有哪些节点）。

C-7 四段式 transition 命令在真实 run 中不可执行（需拍板：本体指令是否要改口径）

甲方：S1 L63-64 "每次流转按四段式（RESEARCH → PLAN → EXECUTE → VERIFY）走，用 node bin/lemon.js task transition --agentId h3-intake --phase <下一阶段> --artifact <文件> 推进"
乙方：S10 L12 "本环境 Bash 全盘 EPERM，node bin/lemon.js task transition 四段式流转命令无法执行，产出全部经文件写入工具完成，流转交引擎按图拓扑推进"；同款记录贯穿 S5 各节点 output_excerpt（12:48/12:58/13:35 等多轮）
影响：本体的 Always Rule 在当前执行环境常态性不可达，实际兜底是引擎按图拓扑推进。是否把该指令改成"命令可用则用，不可用则如实留痕并交引擎推进"由上级定。

C-8 下游对 brd §7 条目编号的引用漂移（低危，记档）

证据：S10 L18（sdd 13:54 行）"R3 H3 平台 10.0s 时长档未验证（brd §7-③）"；但 S4 L80 的 §7-③ 实际写的是"渲染 POST 请求体形状未验证过"
影响：跨节点引用 brd 编号时（sdd/交接备注）出现条目错位；判据若要求"引用 brd 须带条目编号"，要同时要求引用者复核编号语义，而不是只对编号字符串。


§5 交接 Digest 清单 + 自检清单
5.1 交接给 Digest（Phase 2）的原料索引


优先级
内容
出处


P0
§2 F3（impl_bug 五条 remediation + 8 条 checks）——判据设计的正反样本主体
S6 / S5 id:25 / S7


P0
§4 C-1/C-2/C-3/C-7 四条需拍板项
S1 vs S8/S4/S10


P1
§2 F4/F5（数字自核算、归一化前置条件）——两条可直接成判据
S10 L10 / S7 L11,L19


P1
§2 F6（brd 缺时长 → J2 失据）——判据覆盖度检查的实判例
S4 / S10 L12 / S3 J2


P1
§2 F7（kind 命名 + 私有目录副本）——索引认领硬纪律
S5 id:71-72 / S10 L14


P1
§2 F9（依据缺失 ≠ 不合格的降级通道）+ C-5（阻塞三分层）
S6 B.0 / S7 B.0 / S12


P2
§2 F10（采样判据须连同上游出现时序核）+ F11/F12（UNSPECIFIED 绕开、最小改动裁决）
S5 id:68 / S10 L12


P2
§3 映射表（brd 六段 × prd 五段 × validator J2/J6）——可作为跨 agent 契约判据骨架
S1/S2/S3


P2
判据写法范式（只学格式）：失败模式表→维度判据分档→加权和+封顶→来源对照表；双轨禁合并
S14 / S15（B 级）


5.2 本轮自检清单（对照任务书验收标准）

[x] 两文件均 _v1 后缀、非空、结构齐（§0–§6 齐）
[x] sources_v1.json 每条含 {id, path, excerpt, 行号或 sha256, note} —— 15 条
[x] §2 真实失败路径 ≥5 条且每条有 run 证据出处 —— 实际 12 条，全部带 path/行号/id
[x] 零凭空引文 —— 全部 excerpt 逐字复制自 Read 读出的原文；15 条信源均算出 sha256 前 16 位供抽查；4 处查不到的已写「未命中」（§6 + sources_v1.json not_found）
[x] 冲突只列证据未替选 —— §4 C-1～C-8 均未替上级择边
[x] 未修改任何本体/上游文件 —— 本轮只写了 /app/system/agents/h3-intake/train/hunt/ 下两个 _v1 文件


§6 诚实区块（没查到的、推断标 C 级的）

任务书「12:35 行」未命中：带「修正 remediation 示例的『27 字』为实点 20 字」的那句实测在 /app/data/companies/h3video/projects/p-9oi5fo/e2e-trace.md 的 12:25 行；12:35 行是 verify 判 passed 的记录。两句都在，只是行号与任务书表述差一行。已按实际位置登记（S10）。
brd-planning 的本体未读：真实 run 里产出 brd 的是 work graph 节点 h3-intake-brd（system agent id=brd-planning），其 agent.md/SKILL.md 不在任务书信源清单内、我也未越界去读。C-2（六段 vs 五问）因此只能定到现象层：两种契约形态并存且 verify 采用的是五问口径——哪一份是"该被训练的契约"，需上级拍板。
任务原文（master 下发的 T-mtfra5hl-61c6 原始描述）未取得：brd §6 的硬输入透传是 brd 对任务原文的转述。因此"任务原文是否给了时长"无法一手核实——F6 的定性上限是"brd 成品缺时长且下游实证自认"，不能断言"brd 漏抄了任务原文的时长"。若上级能提供任务原文，这一条可升级为 A 级。
h3-intake 层的 UNSPECIFIED 直接判例为零样本：F11 的"叙事绕开"发生在 h3-story 层；brd 阶段"查出主角信息但部分查不出→写 UNSPECIFIED 列待补项"在真实 run 里没有出现（本单主角设定在任务原文就给全了）。相关判据若要写，只能按 S1 L32 条款 + F11 的下游咬合结果间接支撑，属 C 级（构造性）。
Bash 环境受限的如实说明：本 run 里 Bash 对多数目录 ls 全盘 EPERM（与既往记录一致），目录枚举部分靠 Read 逐路径探测；nodes/rn_9d1eb5ab3a34/ 与 rn_ff54bc9cfcfb/ 下除已读文件外可能还有其他文件我未看到（无目录清单可证全）。已读 6 个文件（attempt-0/1.json ×2、contract.json、brd.md、两条 stream.log）足以支撑全部结论，但"读全了"这一点无法由我自证。
本轮证据只覆盖 h3-intake 的一张 work graph（workgraph-T-mtfra5hl-61c6）：2 节点（brd → verify）、1 次回炉。h3-intake 在其他形态的 work graph（如 run_2dd4e3dcfb42 的 h3-intake-extract）下的行为差异，只有 body_not_ready 一个阻塞样本，无成功样本。
数据源清单类交付物（knowhow_raw.md / crawl_config.json / seed_data.json）本轮不适用：任务是仓库内信源挖掘、无外网无爬虫，按任务书要求产出 knowhow_v1.md + sources_v1.json 两件；agent.md 的通用产出规范以任务书为准。