先给判断，再给证据
先用 Why–What–How 给出判断；需要理解冲突、决策或失败时切换到 Story；需要完整项目细节时再展开 5W2H。
- 30–45 秒：Why–What–How，快速说明价值与方法。
- 60–90 秒：故事，呈现冲突、判断、行动和结果。
- 深挖环节：5W2H，交代参与者、时间、成本与边界。
Delivery Harness Framework · Evidence Casebook
同一个案例，三种讲法。
十个来自过去两个月 Codex 会话的真实案例。每个案例先补齐上下文，再用 Why–What–How、Story、5W2H 三种结构解释；表达方式可以切换，事实、结果和证据边界保持不变。
10真实会话案例
3每例三种讲法
14DHF 分支/节点覆盖
2 mo2026-06-14 → 08-14
00 — HOW TO USE
如何选择表达结构
镜头筛选
按钮会同时筛选十个案例的解释卡，便于按一种结构连续阅读和比较。
TRUST 先回答“为什么值得做”
T — Trust & quality 质量与客户信任；R — Risk control 风险与授权控制；U — Unit productivity 运营效率与交付速度；S — Service continuity 韧性与业务连续性；T — Traceability at scale 审计、治理与规模化。三种讲法解释案例如何发生，TRUST 则帮助你先说清它创造了什么业务价值。
BRANCH COVERAGE
十个案例如何覆盖 DHF 流程
| 案例 | 入口判断 | 主路由 | 团队 | 结尾边界 |
|---|---|---|---|---|
| 01 Worktree 治理 | Governed recovery | 直接实现 | 单 agent | Checkpoint / handoff |
| 02 Upwork CV | Skip recovery | 直接实现 | 单 agent | 验证后结束 |
| 03 DHF 做减法 | 需求不清晰 | Requirements → Plan | 委员会 | Merge / handoff |
| 04 商业定位 | 需求清晰 | 产品 / 范围判断 | 单 agent | 只读建议 |
| 05 ONEART | 需求清晰 | 设计 → Prototype → Dev | 单 agent | 生产前 handoff |
| 06 ShipQ | Governed recovery | Repo adapter → Dev | 单 integrator | 冲突时 fail closed |
| 07 委员会评审 | Review | 并行 agents → Val | 多 agent | 门禁未过即 incomplete |
| 08 SimonSays | Validation | 只读数据验证 | 单 agent | 报告后结束 |
| 09 公共文档 | QA / Docs | Browser QA → Val | 单 agent | 未 push |
| 10 Startup4Chinese | Ship | 发布 → 发布后验证 | 单 agent | Repo push ≠ 社交发布 |
Case 01 · 2026-08-02 · MyCodexEnv
高风险 Git / worktree 治理
三个 worktree、多个 stash、用户未提交改动和 runtime 漂移同时存在。任务不是“把 Git 弄干净”，而是在不丢任何用户资产的前提下恢复一个可继续工作的状态。
Outcome工作树治理完成；runtime 对齐因授权边界被交接到下一任务。
governed → Recover → Env → 需求清晰 → 直接实现 → 单 agent → Val → Handoff
Why–What–How
先恢复事实，再移动状态
Why：聊天记录可能过时，任何一次 reset、rebase 或 stash 误判都可能覆盖用户工作。
What：恢复 phase、worktree、branch、stash、dirty ownership 和 next safe task。
How：读取 durable state；给每份改动建立固定 hash 恢复锚点；只做 fast-forward/rebase；用 apply 恢复；验证后在 runtime 写入前停下。
Story
“最危险的不是冲突，是自信地整理现场”
接手时，主工作树、功能 worktree 和 detached worktree 都有不同来源的修改。与其把它们当噪声清理，我先把每一处都视为用户资产。建立恢复分支和固定 stash hash 后，我才移动 main 和功能分支。最后发现下一步要碰 runtime，于是没有借着前面成功的 Git 操作扩大权限，而是留下可执行 handoff。
5W2H
治理切片
- Who
- 单一 integrator；用户拥有既有改动
- What
- 保护、更新、rebase、恢复多 worktree
- When
- 2026-08-02，跨会话接手
- Where
- MyCodexEnv 本地 checkout + linked worktrees
- Why
- 消除漂移而不丢资产
- How
- recover/env → 固定锚点 → ff/rebase → apply → verify
- How much
- 零未授权 runtime 写入；一个后续 handoff
Evidence: worktree governance completed; targeted runtime parity intentionally handed off before copying.
Case 02 · 2026-08-09 · Job Application
Upwork Agentic Engineer CV
目标、源文件和交付物都很明确：不覆盖原 CV，生成新的 Markdown 与两页 PDF，并用视觉和结构检查证明可用。
OutcomeFINAL_PASS pages=2；原底稿哈希未变。
skip Recover / Env → 需求清晰 → 可直接实现 → 单 agent → PDF / visual validation → Done
Why–What–How
轻任务也要有明确证据
Why：简历的失败不是程序崩溃，而是两页失衡、残留旧公司信息或视觉不可读。
What：把原 CV 转成 Agentic Engineer 定位的新版本。
How：先做内容重构；渲染 PDF；逐页视觉检查；两次调整分页与重复信息；最后检查页数、链接、页脚、残留和文件完整性。
Story
第一次“两页”并不等于完成
首版虽然是两页，但第一页留白太大、第二页太密。移动分页后，第二版又出现项目符号挤连。我没有继续缩小字体，而是删掉重复的指标和 MCP 描述。第三版既满足两页，也保持可读，最后才报告完成。
5W2H
交付型任务
- Who
- 求职者与 Upwork 招聘方
- What
- Agentic Engineer 专用简历
- When
- 2026-08-09
- Where
- 独立 Job Application 输出目录
- Why
- 突出 agents、MCP、HITL 与验证能力
- How
- 内容重写 → PDF → 两轮视觉修正 → 结构检查
- How much
- 2 页、4 个链接、零旧公司残留
Evidence: FINAL_PASS pages=2 links=4 required_terms=8 residue=none footers=2 metadata=pass.
Case 03 · 2026-07-12—13 · MyCodexEnv
“DHF 如何做减法”
初始问题只有方向，没有可实施边界。先把它变成 requirements、implementation contract 和 plan，再让委员会挑战方案。
OutcomePR #11 合并；最终 repo gate 85/85。
需求不清晰 → Requirements lock / validate → 工程规划 → 并行评审 → Dev → Val → Merge / Handoff
Why–What–How
做减法前，先定义不能删什么
Why：直接删流程容易把安全边界、恢复能力和验证证据一起删掉。
What：把 DHF 拆成薄核心、标准能力和按风险启用的 governed 能力。
How：先写可审查 contract 与 plan；定义 profile、升级信号和验收；委员会复核；再实施、测试和合并。
Story
从一句“做减法”到可合并的制度
问题看似是删代码，真正难点是决定哪些控制必须始终存在。我先锁定结果标准，把“所有任务都跑完整仪式”改为“风险触发治理”。委员会继续寻找被过度简化的边界，修订后才进入实施。结果不是少写几个脚本，而是让轻任务更轻、危险任务仍然可恢复。
5W2H
需求到合并
- Who
- 主 agent、评审委员会、blind reviewer
- What
- DHF 简化 contract、plan 与实现
- When
- 2026-07-12—13
- Where
- MyCodexEnv + 隔离 worktree
- Why
- 降低日常摩擦，不降低交付可靠性
- How
- Req → Plan → Committee → Implement → Gate → PR
- How much
- PR #11；85/85 最终门禁
Evidence: separate contract/plan artifacts; committee readiness; PR #11; final test_runner 85/85.
Case 04 · 2026-08-09—10 · MyCodexEnv
商业定位与 Proof Center
任务明确要求只读：不是修改网站，而是决定谁是首要客户、卖什么服务、用什么证据建立信任。
Outcome收敛为一个 ICP、一项 30 天服务、一个价值主张；暂不新建 portfolio。
需求清晰 → 产品 / 范围判断 → 证据矩阵 → 优先级建议 → Done（无实现授权）
Why–What–How
缺口不是网站，而是买方理解
Why：能力很多，但客户不知道该为什么问题购买。
What：选择一个 ICP、一项产品化服务和一句客户价值主张。
How：审阅源码、runtime、公开页面和案例授权；分开事实、推断与假设；按商业影响、信任提升和成本排序。
Story
我拒绝用“再建一个网站”掩盖证据问题
最初很容易得出“需要 portfolio”的结论。但审计发现，真正问题是现有页面对买方、服务和证明链表达不一致。于是我把建议反过来：先让 MyCodexEnv 成为旗舰 proof center，等有 2–3 个获准公开的案例后，再考虑独立站。
5W2H
产品边界
- Who
- 内部 AI/platform engineering 负责人
- What
- Agentic Engineering Reliability Sprint
- When
- 2026-08-09—10
- Where
- MyCodexEnv 公开证明面
- Why
- 把技术能力翻译成可购买结果
- How
- 证据审计 + 单一定位 + 状态边界
- How much
- 30 天；一个现有 workflow；不默认生产部署
Boundary: recommendations were not implementation, publication, customer adoption, or commercial validation.
Case 05 · 2026-07-21—22 · ONEART
匿名、私密的作品回应原型
艺术网站希望让读者回应作品，但短回应不采集邮箱，也不公开展示。任务要求先做本地原型，未经授权不得部署生产。
Outcome721 个作品页接入；5 项测试与 1786 个 HTML 检查通过；生产未部署。
设计规划 → 本地 Prototype → 单 agent → Dev → Browser / static Val → 生产前 Handoff
Why–What–How
先验证互动是否值得存在
Why：增加联系入口可能带来隐私、垃圾信息和维护成本。
What：提供匿名短回应；需要深入沟通时再转入专用邮箱。
How：先完成 user context 和视觉方案；本地原型验证；实现 D1、来源校验、蜜罐与限流；桌面和静态全站验证；生产前停止。
Story
一个“留言框”背后是数据最小化
表面需求只是增加回应入口，但如果默认收邮箱和 IP，就改变了网站的信任关系。我把短回应与深度沟通拆开：短回应保持匿名；只有用户明确需要回复，才进入邮箱渠道。原型跑通后仍没有直接部署，因为远程 D1、secret 和正式邮箱都需要新的授权与核实。
5W2H
原型学习
- Who
- 艺术读者、站点维护者
- What
- 匿名作品回应流程
- When
- 2026-07-21—22
- Where
- ONEART 静态站 + 本地 D1
- Why
- 建立私密互动，不扩大数据收集
- How
- 设计 → 原型 → Function/D1 → QA → handoff
- How much
- 721 页面；5 tests；1786 HTML；0 production deploy
Boundary: placeholder D1 ID and unconfigured remote secret made production deployment unsafe.
Case 06 · 2026-08-11—12 · ShipQ
Level 2 项目适配器与回滚
ShipQ 有专用 lifecycle harness、客户数据边界和 Level 2 默认拒绝策略。通用 DHF 只负责路由，项目 adapter 决定业务命令、授权和 readback。
OutcomePhase 0 完成；在线文档结构不一致被恢复并独立回读；后续阶段未伪称完成。
Governed → Repo adapter → Phase gate → Dev → Readback → mismatch 时 rollback → Val
Why–What–How
通用流程不能替代业务授权
Why：外部文档写入可能接触客户数据，也可能在最终断言前已经发生部分变更。
What：让 ShipQ adapter 持有 action registry、lane grant、业务 readback 和 rollback 规则。
How：先 recovery；receipt 与 State Log 冲突时停止；owner 裁定后继续；文档结构回读不一致时保留失败 receipt、恢复旧 revision，再独立读取确认。
Story
失败不是“没写进去”，而是“已经写了一半”
Phase 0 首先发现历史 receipt 与 State Log 不一致，我没有选择其中一个继续，而是等待 owner 裁定。后续 Google Docs writer 返回结构不匹配；这时盲目重试可能重复破坏文档。我保留失败证据，恢复之前 revision，再用独立 readback 验证。系统从“调用成功”转向“结果可证明”。
5W2H
项目专用治理
- Who
- Owner、ShipQ adapter、operator
- What
- Level 2 分阶段实施与在线文档恢复
- When
- 2026-08-11—12
- Where
- ShipQ repo + Google Docs/Drive
- Why
- 防止未授权和不可证明的外部副作用
- How
- grant → receipt → readback → rollback → independent readback
- How much
- Phase 0 green；后续阶段保持未完成
Key rule: recovery evidence is not permission; a successful local policy edit does not authorize a connector retry.
Case 07 · 2026-08-06 · MyCodexEnv
委员会评审：10/10 仍然不通过
高风险 runtime 计划使用专家委员会、revision worker 和独立 blind reviewer。目标不是获得漂亮平均分，而是让新版本经受独立复核。
Outcome迭代委员会 10/10；blind final 7/10；达到轮次上限，状态保持 incomplete。
Review → 并行 agents → 修订循环 → 独立 blind Val → 门禁失败 → 不宣称 Done
Why–What–How
让评分绑定 artifact，而不是团队信心
Why：同一批评审者容易对自己参与修订的版本产生确认偏差。
What：冻结 rubric、evidence、unknowns 和 append-only finding ledger。
How：委员会提出 finding；worker 修订；委员会 closure；独立 reviewer 盲审；超过 max rounds 就停，不补算平均分。
Story
最能证明治理的，是拒绝一个看似漂亮的通过
第五轮时，迭代委员会已经给出 10/10，所有 ledger finding 也已关闭。但 blind reviewer 审的是修订前版本，只给 7/10；新版本没有剩余轮次再做 blind final。因此我没有把 10 和 7 平均成“足够好”，而是把任务标为 incomplete，并明确只需增加一轮独立复核。
5W2H
证据型评审
- Who
- 专家委员会、revision worker、blind reviewer
- What
- runtime 计划只读评审
- When
- 2026-08-06
- Where
- MyCodexEnv planning surface
- Why
- 抵抗自评偏差和范围漂移
- How
- frozen rubric + ledger + max rounds + blind final
- How much
- 5 轮；10/10 iterative；7/10 blind；0 文件修改
Governance result: no calibrated pass without a fresh blind review of the current artifact.
Case 08 · 2026-08-14 · SimonSays
只读访问分析：231 请求不等于访客
自动化要求分析真实用户访问，但 Cloudflare RUM 数据断档。HTTP Traffic 仍有数据，却主要包含探测和安全噪声。
Outcome报告数据断档；不把 231 原始请求解释成真人访问；零 Cloudflare / repo 修改。
Classify=Validation → 只读查询 → 证据分层 → 数据缺口报告 → Done（无 checkpoint）
Why–What–How
指标定义比查询成功更重要
Why：原始 HTTP requests 混合真人、机器人、缓存和探测，不能作为访问人数。
What：以 bot-filtered RUM 为访客主指标，HTTP 只作安全噪声上下文。
How：固定 Toronto 时间窗；查 RUM；发现断档后停止访客推断；单独比较 HTTP、504 和 challenge；报告 exact gap。
Story
数据存在，但答案不存在
查询拿到了 231 个请求，看起来足以生成日报。但 RUM 最后记录停在 8 月 1 日，这意味着真正的访客测量链断了。与其填一个看似完整的趋势，我明确写下“无法判断，不是零访问”，并把 HTTP 数据降级为噪声和安全上下文。
5W2H
验证型分析
- Who
- 站点运营者
- What
- 每日访客与安全噪声简报
- When
- 2026-08-13 完整 Toronto 日
- Where
- Cloudflare RUM + HTTP GraphQL
- Why
- 避免把攻击/探测误判为增长
- How
- RUM 主指标；HTTP 辅助；缺口显式化
- How much
- 231 requests；8 次 504；2 次 challenge；访客数 unavailable
Key distinction: unavailable RUM cannot be reported as zero, and HTTP “visits” cannot be promoted to human visitors.
Case 09 · 2026-08-03 · MyCodexEnv
DHF 公共状态文档与浏览器 QA
公开页面需要统一说明四种不同状态：源码已实现、runtime 是否同步、公开文档是否发布、独立 DHF core 是否存在。
Outcome14/14 页面桌面与移动端通过；本地文档可发布，但未 commit/push。
QA / Docs → 页面实现 → focused gate → Browser QA → full-suite boundary → 未发布
Why–What–How
公开页面必须说明“哪一层完成了”
Why：公开页面 HTTP 200 不证明当前机器 runtime 已同步，更不证明生产 enforcement。
What：统一双语状态横幅、架构状态页和移动端布局。
How：建立状态词汇；更新 12 个既有页面并新增 2 个状态页；focused tests；桌面/375px 浏览器 QA；完整门禁保留基线失败。
Story
修好文档，同时拒绝把文档当 runtime
页面对 DHF 能力的描述彼此不一致，我先统一“source、runtime、public docs、independent core”四层状态。浏览器检查又发现英文 lifecycle 页在 375px 横向溢出，于是修复并重测。尽管页面 14/14 通过，完整测试仍有两个基线失败，所以最终只说“本地文档具备发布条件”。
5W2H
文档 QA
- Who
- 公开读者、工程团队、潜在买方
- What
- DHF 双语状态与架构页面
- When
- 2026-08-03
- Where
- MyCodexEnv docs / GitHub Pages source
- Why
- 避免状态层级误导
- How
- 状态词汇 → HTML/CSS → focused test → browser QA
- How much
- 14/14 页面；desktop/mobile overflow=0；0 push
Boundary: local documentation alignment did not establish runtime parity or public deployment.
Case 10 · 2026-08-02 · Startup4Chinese
朋友圈交付合同的发布路径
目标不是简单“生成一张图”，而是强制区分当前活动已核实、图片已生成、图片已视觉检查、图片是否真的用于朋友圈。
Outcomevalidator 212 checks；commit bf1c1c5 已 push；社交平台实际发布仍未观察。
Classify=Ship → 当前事件核实 → Contract / asset Val → Commit / Push → Remote readback → Done
Why–What–How
发布状态必须分层
Why：旧活动图片、错误 URL 或“已生成=已发布”的状态混淆会造成公开传播错误。
What：强化 current-event Moments contract，要求 generated、checked、used 三个独立 receipt。
How：核对 #96 标题、日期、地点和三条报名 URL；检查单张 1080×1350 图片；运行 validator；commit/push；比较本地与远端 SHA。
Story
Push 成功后，我仍然说“没有观察到朋友圈发布”
skill 合同、图片和当前活动链接都通过验证，代码也推到了 main。最容易犯的错误是把这一步写成“活动已发布”。但 GitHub push 只证明项目源码已发布；它不证明用户已把图片发到微信。因此最终状态明确分成 repo shipped 与 social usage not observed。
5W2H
发布后验证
- Who
- 活动运营者、内容 skill、最终发布者
- What
- #96 朋友圈文本/图片交付合同
- When
- 2026-08-02
- Where
- Startup4Chinese-artifacts GitHub repo
- Why
- 阻止旧活动证据和发布状态混淆
- How
- current event readback → asset QA → validator → push → SHA compare
- How much
- 212 checks；1 张图；commit bf1c1c5；0 observed WeChat publish
Key distinction: skill_source_implemented, asset_checked, repo_pushed, and social_post_observed are separate claims.
MODEL CAVEAT