MYCODEXENV × SHIPQ · DEVELOPMENT HISTORY · 2026-08-16

DHF 不是流程模板，
而是被业务风险逼出来的交付控制系统。

它从 ShipQ 的跨会话交付、Gmail 询价抽取、工作簿报价、人工审核与受保护运行时中生长出来：先解决“下次从哪里继续”，再解决“凭什么说完成”，最后解决“谁有权让真实世界发生变化”。

方法层 · DHF决定任务走哪条路径：恢复、规格、实现、验证、评审、发布或交接。
控制层 · SAFE检查一次状态变化是否有契约、授权、事实证据与错误恢复。
价值层 · TRUST把工程控制翻译成质量、风险、效率、连续性与规模化价值。
ShipQ lane = local_dev active_lane_grant = null worktree = clean snapshot = 2026-08-16T12:13Z
01 · EXECUTIVE READING

三条演进主线：CAP

Continuity · Accuracy · Permission：从“Agent 能做”到“业务敢让它做”。每一阶段都来自 ShipQ 的实际阻塞，并保留了上一阶段的能力。

CAP · C

Continuity · 连续性

跨分支、worktree、会话和多日任务时，事实不能只留在聊天里。于是产生 durable state、recovery、checkpoint 和 next_safe_task。

CAP · A

Accuracy · 正确性

货运邮件中的路线、箱型、客户身份、CBM/重量和门到门地址都可能歧义。于是产生规格契约、fixtures、人工审核、确定性规则与 fresh evidence。

CAP · P

Permission · 授权

本地测试通过不等于可以调用 Gemini、替换报价 SQLite、发布 Pages、创建 Drive/Docs 或发送 Gmail。于是产生 lane、Level 0/1/2、action binding、readback 与 fail-closed。

02 · SIX-STAGE EVOLUTION

六个演进阶段：BRIDGE

Baseline · Receipts · Inspection · Decoupling · Grading · Enforcement。SAFE/TRUST 不属于历史阶段，而是对全部阶段持续适用的指导原则。

B
PHASE 0 · 2026-05-20 — 05-31

Baseline · 种子期

先让复杂任务不断线：Lifecycle harness 恢复；ShipQ Gmail 本地后端、工作簿报价与 Phase 1 handoff 同时成形。
业务痛点

报价引擎、Gmail UI、Gemini、SQLite 与工作簿并行变化；会话一断就要重新考古。

关键机制

harness state、阶段交接、受限本地 lane、初始 skill 路由。

业务价值

把“聊天记忆”变成“项目记忆”，降低重复定位与误接手。

SAFE 重点E · Error-recovery支撑：S · Specification先恢复现场，再明确可续接状态。
9d163ce25315b32235622c3ec270
R
PHASE 1 · 2026-06-01 — 06-14

Receipts · 骨架期

把“完成”改写成可验证切片：Recovery、env probe、checkpoint、report、requirements 与 agent-team validators 成为工具链。
业务痛点

测试、分支清理、fixture 与文档各自“看似完成”，但没有统一证据和下一步。

关键机制

Definition of Done；command / exit_code / key_output / timestamp；append-only checkpoint。

业务价值

负责人无需信任语气，只需核对可复现回执；绿色切片可独立交接。

SAFE 重点F · Facts支撑：S · Specification把完成声明变成可复核事实。
d9c506c40cb715f8e180fe2be7a0019ea7c9…
I
PHASE 2 · 2026-06-03 — 07-11

Inspection · 领域可信期

把 AI 输出降级为可审核草稿：ShipQ 用 spec-safe source rules、11-case fixture、manual review 与 operator UI 验证真实询价链路。
业务痛点

邮件转发头、路线、客户身份、总量与明细、FCL/LCL、Door Delivery 容易被模型猜错。

关键机制

canonical payload、确定性 resolver、来源证据、draft-first、人工修订审计、禁止自动晋升。

业务价值

减少错价与返工；让 operator 看见“为什么需要审核”，而非得到一个不可解释的答案。

SAFE 重点S · Specification支撑：F · Facts先定义 ShipQ 的业务正确性，再用来源证据验证。
ff7368fdebfca7019eb6a6…081456a277a2fb
D
PHASE 3 · 2026-06-15 — 07-11

Decoupling · 产品化期

从 ShipQ 做法提炼可移植核心：DHF 留在 MyCodexEnv 孵化；ShipQ 成为明确的 consumer adapter。
业务痛点

通用治理与 ShipQ 专属 fixture、quote/workbook/demo gate 混在一起，难复用也容易泄漏上下文。

关键机制

DHF core / local runtime / ShipQ adapter 三分；consumer matrix；portable DHF_PACKET。

业务价值

其他项目可复用生命周期与证据合同，同时保留 ShipQ 的领域自治和最小 token 成本。

SAFE 重点S · Specification支撑：E · Error-recovery明确 core、runtime 与 ShipQ adapter 的责任及交接合同。
4cf3a39019ecd3f…dhf-packet.schema.json
G
PHASE 4 · 2026-07-12 — 07-27

Grading · 减负期

让治理强度与风险匹配：DHF 从统一重流程收敛为 light / standard / governed，并加入通用 prompt dispatcher。
业务痛点

如果普通解释、小修复和高风险发布都走同一流程，业务等待与 token 成本过高。

关键机制

风险分层、渐进式加载、opt-out、薄核心、source/runtime promotion 分离。

业务价值

简单工作更快，常规开发保留验证，高风险工作才承担完整治理成本。

SAFE 重点A · Authorization支撑：S · Specification按风险决定需要多强的门禁、评审与授权。
b11db05327c9fe44cf6ba019f5789…
E
PHASE 5 · 2026-07-28 — 至今

Enforcement · 执行控制期

从流程建议进入动作授权：ShipQ DHF Sol audit 暴露旧 grant 不可信；Level 0/1/2、中央 consumer、journal、readback 与 runtime guard 逐步落地。
业务痛点

“用户说过可以”无法证明这一次、这个目标、这个动作仍被授权；失败重试还可能重复产生副作用。

关键机制

closed action registry、action binding、single-use、TTL、fail-closed、reconciliation、三层验证。

业务价值

本地绿灯不再被误当生产权限；可以受控推进 Drive/Docs/Gmail 草稿等精确动作，同时阻断未知副作用。

SAFE 重点A · Authorization支撑：F · Facts / E · Error-recovery把授权变成不可绕过、可回读、可恢复的执行控制。
2d0aaf8172da84ac4b31b00f8f80019fbae3…
CROSS-STAGE GUIDING PRINCIPLE

CAP 是主线，BRIDGE 是路径，SAFE 控制过程，TRUST 检验价值

四组助记词分别回答不同问题：CAP 关注什么，BRIDGE 如何演进，SAFE 如何可信推进，TRUST 最终创造什么价值。

038f30a80a4ee02bc459c01a005d7…
03 · SHIPQ BUSINESS LOOPS

DHF 为什么必须围绕 ShipQ 业务边界，而不是围绕代码目录设计

ShipQ 有两个相连但风险不同的闭环：询价录入负责把不确定邮件变成可审核事实；报价计算负责把受控数据变成确定性价格。

Gmail 询价录入闭环

客户邮件 → sanitized message → AI/规则抽取 → side panel 人工审核 → canonical payload → Get Rate handoff
原始痛点模型可能把转发人当客户、把正文噪声当路线、把总量拆成虚假明细，或在歧义时自信输出。
DHF 价值把 AI 定位为候选生成器；用 fixture、来源证据、manual review、状态机与审计事件，把错误阻断在报价之前。

工作簿到报价闭环

MGF workbook → policy scan → canonical artifacts → approval → guarded SQLite → deterministic quote
原始痛点工作簿含敏感、破损公式与多种业务表；本地 smoke 成功不代表可以替换真实报价运行时。
DHF 价值把 source、canonical、staging、runtime promotion 与 quote result 分层；变更需审批、回滚和独立 readback。
CURRENT BUSINESS PROOF

2026-08-16 的一个小切片，浓缩了完整演进

当前 durable state 表示 Phase 2 数据请求草稿已创建，下一步是 owner 在 Gmail Drafts 审核；没有单独、精确的发送指令就不得发送。早期 DHF 只会记住“下一步”；当前 DHF 还定义“下一步是谁的权力”。

04 · CONTROL KERNEL → BUSINESS VALUE

SAFE 是状态变化的控制内核，TRUST 是业务结果记忆法

三者不是同一层：DHF 路由工作；SAFE 判断这次推进是否可信；TRUST 说明为什么值得为这些控制付出成本。

S
Specification范围、需求、验收、状态定义
A
Authorization所有权、权限、人工批准、fail-closed
F
Factsfresh tests、receipt、readback、事实分层
E
Error-recoverycheckpoint、rollback、handoff、reconcile
controls
create
→
T
Trust & quality客户相信字段与价格可核对
R
Risk control副作用与授权边界清晰
U
Unit productivity减少返工、等待与重复考古
S
Service continuity跨会话、失败与人员切换可恢复
T
Traceability at scale证据可审计、机制可复制
S + F → T规格加事实，减少抽取歧义与错价。
A + F → R授权加回执，阻止“本地绿灯即生产权限”。
S + F → U清晰验收和最小反馈回路减少返工。
E + F → S恢复锚点与 fresh readback 保持连续性。
SAFE → T统一合同、证据和 adapter 支持规模化治理。
05 · STAGE VALUE MATRIX

每个阶段解决的痛点与可观察业务价值

“价值”只写可由机制合理支持的结果；未出现客户采用、生产收益或商业验证证据时，不把它们写成已实现。

阶段ShipQ 具体痛点引入能力业务价值当前证据性质
B · Baseline多模块、多会话后无法恢复真实现场state / handoff / phase减少重复考古与错误接手repo + history
R · Receipts“测试过”无法复核；绿色切片没有下一步fresh evidence / checkpoint / CI gate完成声明可审计，切片可交接repo + session
I · Inspection货运邮件字段歧义会直接放大为错价canonical schema / fixtures / manual review降低错误进入报价链路的概率local validation
D · Decoupling通用治理与 ShipQ 领域规则耦合core / runtime / adapter / packet复用而不牺牲项目自治compatibility proof
G · Grading简单任务承担完整高风险流程成本light / standard / governed更短响应与更低治理成本source + runtime proof
E · Enforcement历史批准、自然语言 token 与重试不足以保护外部动作Level 0/1/2 / central consumer / readback控制副作用，保留精确低风险自动化Level 2 remains gated
06 · CURRENT MATURITY & FRONTIER

当前不是“全自动”，而是“知道哪里必须停下”

这是成熟度而不是缺陷：DHF 已能区分本地工作、受约束外部动作与默认拒绝动作；尚未有证据的生产强制、客户采用和商业结果仍保持未声明。

已具备

可恢复、可验证、可审计

  • phase / lane / dirty ownership 恢复
  • fresh evidence 四元组
  • checkpoint 与 next safe task
  • ShipQ adapter 与项目级门禁
仍受限

真实 Level 2 自动执行

  • active_lane_grant=null
  • unknown action 默认拒绝
  • source/test 不等于 runtime rollout
  • 没有 owner go/no-go 就不扩大授权
下一价值证明

从工程证据到业务证据

  • 三案例轻量 pilot
  • time-to-recover 与返工率
  • manual-review 命中与错价逃逸
  • 授权阻断与 readback 完整率
推荐的单一北极星：把 DHF 定义为“让 Agent 驱动的业务流程在每次状态变化时都可恢复、可授权、可验证”的交付控制系统。SAFE 是其可复用控制合同，TRUST 是对业务负责人的价值汇报结构。
07 · EVIDENCE & CLAIM BOUNDARY

分析依据与结论边界

页面使用当前 checkout、Git 历史、DHF/ShipQ 文档、当前只读 recovery 输出与本机会话索引。历史成功不自动升级为当前生产状态。

主要 repo 证据
  • MyCodexEnv：docs/delivery-harness-framework-manual-cn.md、docs/DHF_SIMPLIFICATION_PRODUCT_GUIDE.md、docs/HARNESS_RUNTIME.md、docs/dhf-consumer-compatibility.json、SAFE/TRUST 三个公开页面。
  • ShipQ：docs/project-handbook.md、docs/HARNESS_RUNTIME.md、Gmail source-rule / fixture / workbook / lane-grant plans 与 contracts。
  • 当前只读状态：MyCodexEnv HEAD e11919f；ShipQ HEAD 162b7af，local_dev，active_lane_grant=null。
代表性会话证据
  • 019ea7c9-d4be-78f0-aed4-d4cf8440a847：CI green gate、checkpoint 与 next-safe-task。
  • 019eb6a6-82e8-7602-83fe-6a217fcbd5ae：ShipQ 11-case Gmail fixture validation。
  • 019ecd3f-041d-7d61-a58f-b2eb1040436f：DHF 孵化边界与 ShipQ consumer compatibility。
  • 019f5789-9d07-7cf1-bd25-c47e67c2f4b0：DHF simplification 与 runtime activation 边界。
  • 019fbae3-46e4-7972-aa43-0159319ca6fa：lane-grant redesign 起点。
  • 019ff1a9-bfd0-7a31-a5d9-af34269f6025 / 019ff1eb-49e2-72c2-91f7-6ca2209eee46：Phase 2 discovery workspace 与 data-request draft。
  • 01a005d7-106d-7833-bdaf-2a8a561898ad：SAFE/TRUST 跨阶段指导原则的业务表达与发布。
事实、推断与尚未证明
  • 事实：阶段工件、提交、helper、fixtures、授权分类和当前 recovery 状态在 repo/会话中存在。
  • 分析性推断：六阶段划分和“业务风险逼出控制能力”的主线，是对证据的归纳，不是 repo 内既有官方版本号；SAFE/TRUST 是贯穿阶段的指导原则。
  • 尚未证明：生产级完整执行覆盖、客户采用、节省金额、错价下降百分比、商业验证。需要后续 pilot 数据。