# 三产品集成契约

状态：冻结用于 Context Continuity `0.2.0-beta.2`。
适用对象：Intent Loop、Context Continuity、Execution Fidelity Guard 与宿主 Agent。

这份契约只有一个目的：避免三插件和宿主各自维护“最终真相”。当前发行只冻结所有权
和 wire shape，不宣称跨仓库实时桥接已经实现。

## 唯一有效状态的所有权

| 组件 | 拥有 | 不拥有 |
| --- | --- | --- |
| Intent Loop | 规范化的当前用户语义意图、`contract_ref`、`contract_version`、实质变更判断与用户消息来源 | 连续性快照、Guard 决策、执行收据、宿主权限与运行状态 |
| Context Continuity | 有损转换事件、恢复阶段、开放承诺、工作对象与版本、完成/证据引用、快照与 handoff 运输 | 已绑定 provider 的意图改写、授权判断、Guard 策略、完整 transcript |
| Execution Fidelity Guard | Hook 动作分类、继续/提醒/询问/阻止判断、自身事件/收据/证据和 Stop 计数 | 意图写入、provider 版本、连续性状态写回、Agent 循环与宿主审批 |
| 宿主 Agent / Harness | 实际工具执行、生命周期投递、UI、沙箱、信任、权限审批和运行时 Goal 状态 | 把平台摘要升级为权威意图，或把 Guard 收据当作用户授权 |

语义目标与运行时 Goal 状态必须分开：Intent Loop 拥有用户意图合同，宿主拥有它实际
创建和执行的 Goal 对象及状态。

最终有效状态按 namespace 投影：

- 存在安全 Intent Loop 绑定时，它是 intent namespace 的唯一 owner；Continuity 只
  引用该合同并拥有 operational/lifecycle namespace。
- 没有绑定时，Continuity 只能用自己的精确用户确认协议维护 standalone intent；这
  是独立模式，不是第二份 Intent Loop 真相。
- Guard 只读判断，Host 只执行与审批。
- 平台摘要、检索拼装、模型记忆、handoff 和子 Agent 输出只是缓存或候选。

## Intent Loop 到 Continuity

未来自动绑定必须同时提供：

- 稳定且不可变的 `contract_ref`；
- 仅在经用户授权的实质变更时严格递增的 `contract_version`；
- provider 规范化投影的 `snapshot_sha256`；
- 最小状态项及其原始 source refs；
- 映射后状态项的规范 `items_digest`。

当前核心已测试版本回退、同版本碰撞和 hash 不一致，但 Codex MCP 与 DSH tools 都不
暴露 provider/token 字段。模型、用户或 Skill 不得自行提供 token，也不得调用内部
方法绕过身份边界。

截至本版本，Intent Loop 仍没有一条同时满足不可变单调 revision、规范 hash、来源
完整且模型不可伪造身份的已发布 producer 通道。因此，同时安装两个插件不会自动形成
共享真相。实时适配器只能运行在模型不可见的受信宿主进程中。

预定最小映射：

| Intent Loop facet | Continuity kind |
| --- | --- |
| outcome | objective |
| hard_constraint | hard_constraint |
| unknown | open_question |
| disagreement | dispute |

`success_signal`、`failure_signal`、`soft_constraint` 与 `tradeoff` 保持
provider-owned reference；未经协议版本迁移不能偷偷变成新的 Continuity kind。

## Continuity 到 Execution Fidelity Guard

本节与
[Execution Fidelity Guard v0.2.2 契约](https://github.com/rrrrrredy/execution-fidelity-guard/blob/v0.2.2/docs/integration-contract.md)
及独立的
[DeepSeek Harness Guard adapter v0.1.0-alpha.2](https://github.com/rrrrrredy/dsh-execution-fidelity-guard/releases/tag/v0.1.0-alpha.2)
对齐。

### Guard 读取的用户意图合同

Intent Loop 若可用，Guard 读取 provider envelope 与恰好七个顶层字段的只读
projection：

```json
{
  "envelope": {
    "schema_version": "1.0",
    "contract_ref": "intent:stable-task-id",
    "contract_version": 1,
    "source": "user-intent-plugin",
    "source_message_refs": [],
    "snapshot_sha256": "canonical projection 的小写 SHA-256",
    "updated_at": "2026-09-01T00:00:00.000Z"
  },
  "projection": {
    "objective": "用户要求的结果",
    "primary_object": "被修改或交付的对象",
    "delivery_surface": ["repository"],
    "scope": {
      "include": ["workspace"],
      "exclude": []
    },
    "must_and_must_not": {
      "must": [],
      "must_not": []
    },
    "authorization": {
      "allowed": [],
      "requires_user": [],
      "forbidden": []
    },
    "completion_evidence": []
  }
}
```

七个 projection 字段固定为 `objective`、`primary_object`、
`delivery_surface`、`scope`、`must_and_must_not`、`authorization` 和
`completion_evidence`；多余字段直接校验失败。Guard 递归排序对象键、保留数组
顺序后计算 projection hash。

- `contract_ref` 是一个用户意图的稳定身份。
- `contract_version` 是正整数；目标、对象、交付面、范围、约束、授权或完成证据发生
  经用户授权的实质变化时，Intent owner 必须递增版本。
- 同一 `(contract_ref, contract_version)` 对不可变；同一投影可重序列化，内容变化
  必须提高版本。
- `snapshot_sha256` 只证明当前文档与投影一致。Guard `0.2.2` 没有全局版本
  ledger，不能证明已被擦除的历史中从未复用版本，也不能保证跨机器全局单调。
- provider 无效时 Guard 保持未绑定和 advisory，不升级平台摘要补齐缺口。
- 没有 Intent Loop 时，可读取同一七字段 TaskContractLite；Guard 用内容派生身份和
  fallback version 1。它不是 provider-owned truth，也不能携带调用者自选的旧
  envelope。

Context Continuity 不生成或修改这份 provider envelope，也不把 Guard receipt 当作
用户授权。

### Wire 版本

- provider envelope、TaskContractLite、Continuity snapshot 与 Guard decision
  receipt 使用 wire `1.0`。
- Guard normalized event 与 evidence record 使用 wire `2.0`；其中 `facts` 是已
  声明的开放扩展点。
- shadow-pilot summary 使用 wire `1.1`。
- 包版本与 wire `schema_version` 相互独立；不兼容 shape 需要新的 major，兼容字段
  增加需要记录新的 minor。

### 保留的 Continuity snapshot

Context Continuity 不伪装成 intent provider。它只保留另一份只读、最小交换 shape：

```json
{
  "schema_version": "1.0",
  "contract_ref": "intent:stable-task-id",
  "contract_version": 1,
  "phase": "implementation",
  "open_commitments": ["next:verify-release"],
  "evidence_refs": ["artifact:sha256:..."],
  "captured_at": "2026-09-01T00:00:00.000Z"
}
```

字段规则：

- `schema_version` 只接受 `1.0`；
- `contract_ref/version` 只引用 Intent owner，不由 Continuity 递增；
- `phase` 必须是非空字符串，只取当前 verified 的 operational phase，否则为
  `unknown`；
- `open_commitments` 只含 open_question/dispute 稳定 ID 和 verified
  `next_action`；stale/unverified 动作不导出为可执行承诺；
- `evidence_refs` 只含当前 verified 引用，不复制正文；
- `captured_at` 只表示捕获时间，不决定优先级。

本项目 producer 对两个数组额外要求 `uniqueItems: true`；这是 Guard v0.2.2 接收
shape 的更严格子集，不放宽 Guard 的 tagged schema。

Guard `0.2.2` 不会加载该 snapshot；不存在实时 Continuity producer 或 consumer
bridge。独立的非官方 DSH Guard adapter `0.1.0-alpha.2` 以 DeepSeek Harness
`0.1.2-alpha.2` 为兼容目标，遵守相同的无写回边界，但也不加载该 snapshot。它与
本项目面向 DSH `0.1.1-rc.2` 的 Continuity adapter 是两个独立插件，不能混装后
推定为自动集成。

## 写回和冲突规则

- Guard 永不写回 Intent Loop 或 Context Continuity。
- Continuity 不通过 Guard 的 deny/ask/receipt 修改用户意图。
- Guard 收据若未来成为 evidence，只能由模型不可见的受信适配器作为候选导入，并保留
  原 `contract_ref/version`；模型不能自行标为 verified。
- 新用户纠正高于旧快照；standalone Continuity 仍要求完整提案的第二次精确确认。
- provider 不可用或契约无效时保持未绑定或最后已验证引用，并标记陈旧风险；不得用
  平台摘要补齐缺口。
- 合同版本、工作对象或高风险承诺不一致且无法从可靠证据修复时，暂停相关高风险动作，
  只问一个必要问题。
- Codex Guard 的 `requires_user` 只有 Intent owner 发布更高合同版本，或人工审查后
  修改 bare TaskContractLite、使内容派生身份变化，才能解除；聊天回答不会被 Guard
  自行消费。
- DSH native ask 只授权当前那一次 pending call；它不修改合同、不写入 Intent 或
  Continuity，也不授权后续相似调用。

## 实时集成退出门槛

市场文案只有同时满足以下条件后才能从“协议边界已对齐”改为“自动集成”：

1. Intent Loop 提供稳定 revision、规范 hash、完整来源和模型不可伪造的 producer。
2. 宿主提供模型不可见的 adapter 身份与凭据边界。
3. Continuity 对真实 provider 完成成功、回退、同版本碰撞、hash 错误和缺失测试。
4. Guard 从真实 Continuity producer 读取 snapshot，验证 exact shape 且无写回。
5. Codex 和 DSH 分别完成组合测试，证明只有一个有效 intent owner。
6. 禁用任一插件时其余宿主仍可 fail-open 工作。
7. 文档明确版本兼容、升级、删除和错误恢复路径。

在此之前，三个项目可以共享协议和测试夹具，不能共享一份由谁都能改写的状态文件。