test(contract): 落成五个接缝的契约骨架，用它逼出七个设计洞

第 ④ 阶段的核心交付物。这套测试不针对任何具体实现，写的是「不管你怎么实现都必须满足这些行为」，下游写完自己的实现接到 fixture 上跑一遍即可，是任何新适配器的准入标准（CLAUDE.md §0）。现在全部跳过，因为公共类型与 Protocol 还没落地。价值不在跑，在写：写一条契约要求把每次调用逐字写出来——方法叫什么、参数填什么、返回值怎么取，而散文里读着通顺的地方，落到这一步就露出来了。三轮文档评审没报出的七个洞，写这套测试时全部撞了出来：没有动作的步 result_id 填什么；三个 ActionStatus 取值的触发条件；动作被拒绝时观察的来源（执行器与 SyntheticObservations 两处都有）；解释器能不能抛异常；Event 没有字段所以事件出口的契约只写得出一半； read_log 读不存在的运行必须返回空日志而不是抛异常；以及原子性与前缀持久性这两条 0005 的承诺根本没有机器兜底—— 写这套测试之前我们默认它们会被契约测试接住。洞标成 xfail(strict=True) 而不是常驻 fail：一个永远红的套件会训练所有人忽略红。它们都不带 fixture，否则会被「实现还没有」那个跳过挡住，于是「答不上来」就伪装成了「还没轮到」。补上之后 XPASS 会报错，逼人回来删标记。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 23:37:13 -04:00
parent e017160c45
commit a14bf8d288
6 changed files with 614 additions and 0 deletions
@@ -0,0 +1,234 @@
+"""存储接缝的行为契约。
+
+这份文件是「一次运行的日志到底保证什么」的权威（`CLAUDE.md` §0）。两个已知实现形态差别
+很大——一个逐行追加本地文件，一个写关系数据库——所以下面每一条都只说行为，不碰形态。
+
+**行为的理由不在这里。** 崩溃恢复为什么这么设计见 `design/0002`，写入粒度与前缀持久性见
+`design/0005`。这里只断言结果。
+
+## 写这份文件时撞出来的、`design/0006` 还答不上的问题
+
+每一条都在下面对应的测试里标成 `xfail`，摘要里每次都看得见，但不把套件拖红——**一个永远
+红的套件会训练所有人忽略红**。它们也都不带 fixture，否则会被「实现还没有」那个跳过挡住，
+于是「答不上来」就伪装成了「还没轮到」。
+
+`strict=True` 是配套的：哪天这个洞被补上、测试真的能过了，它会以 XPASS 报错，逼人回来把
+这个标记连同这段说明一起删掉。
+
+1. 没有动作的那些步，`StepCompleted.result_id` 填什么。
+2. 「重放」是把动作再执行一次，还是把上次的结果填回去。
+3. 原子性与前缀持久性能不能写成契约测试。
+"""
+
+import pytest
+
+pytestmark = pytest.mark.contract
+
+
+# --------------------------------------------------------------------------
+# 一、写进去的读得回来
+# --------------------------------------------------------------------------
+
+
+async def test_written_intent_is_readable(store, records):
+    """写一条意图，读回整份日志时它必须在里面。
+
+    这是全套最基本的一条：意图日志的全部意义是「比进程活得久」，写了读不回来，后面每一条
+    恢复语义都建立在空气上。
+    """
+    intent = records.model_call_intent(run_id="r1", call_index=0, result_id="m0")
+    await store.write_intent(intent)
+
+    log = await store.read_log("r1")
+
+    assert intent in log.intents
+
+
+async def test_log_of_unknown_run_is_empty_not_an_error(store):
+    """读一个从没写过的运行标识，得到一份空日志，而不是异常。
+
+    `run` 在开工前要判断「这个标识是不是已经有日志了」，靠的就是这一条。如果读不存在的
+    运行会抛异常，那个判断就得写成捕获异常——而捕获异常来做流程控制，会把真正的存储故障
+    一起吞掉。
+    """
+    log = await store.read_log("never-written")
+
+    assert log.started is None
+    assert log.intents == ()
+    assert log.finished is None
+
+
+async def test_two_runs_do_not_leak_into_each_other(store, records):
+    """两个运行标识各写各的，互相看不见对方的记录。
+
+    端口不持有「当前运行」的隐式状态，这条测试是那个要求的外部可观测形式。一个有隐式当前
+    运行的实现会在并发下把 A 的意图写进 B 的日志，而那种错在单线程测试里永远不出现。
+    """
+    a = records.model_call_intent(run_id="run-a", call_index=0, result_id="m0")
+    b = records.model_call_intent(run_id="run-b", call_index=0, result_id="m0")
+    await store.write_intent(a)
+    await store.write_intent(b)
+
+    assert (await store.read_log("run-a")).intents == (a,)
+    assert (await store.read_log("run-b")).intents == (b,)
+
+
+# --------------------------------------------------------------------------
+# 二、四态：恢复靠「意图有没有 / 结果有没有」判定
+# --------------------------------------------------------------------------
+
+
+async def test_intent_without_result_is_readable_as_such(store, records):
+    """写了意图、没写结果，读回来必须能看出「这个 ID 没有结果」。
+
+    这是四态表里「状态未知」那一档的输入。存储不负责判定，但它必须让判定问得出口——恢复
+    要按预分配的 ID 精确地问，而不是模糊匹配去猜哪条结果对应哪次执行。
+    """
+    intent = records.action_intent(run_id="r1", call_index=0, result_id="a0")
+    await store.write_intent(intent)
+
+    log = await store.read_log("r1")
+
+    assert intent in log.intents
+    assert all(step.result_id != "a0" for step in log.steps)
+
+
+async def test_result_without_intent_is_visible_to_the_reader(store, records):
+    """只写结果不写意图，读回来必须原样可见，存储自己不许修复也不许拒收。
+
+    「有结果没意图」是日志损坏，处置是拒绝续跑——但那个判断归恢复逻辑，不归存储。存储在
+    这里悄悄补一条意图或者拒绝这次写入，都会让损坏变得不可见，而不可见的损坏会被当成
+    正常数据继续用下去。
+    """
+    result = records.model_call_result(run_id="r1", result_id="orphan", reply=records.reply())
+    await store.write_model_call_result(result)
+
+    log = await store.read_log("r1")
+
+    assert log.model_results == (result,)
+    assert log.intents == ()
+
+
+async def test_failed_model_call_is_recorded_as_a_result_not_as_nothing(store, records):
+    """模型调用失败也要落一条结果记录，否则恢复会把它读成「状态未知」。
+
+    失败这件事是确定的：调用发出去了、失败了、库记了一条步。如果这时不写结果条目，恢复
+    只看见「意图有、结果无」，走重放策略——而这次调用的状态一点都不未知。下游按停止原因
+    做的统计会照单收下这个错误。
+    """
+    result = records.model_call_result(run_id="r1", result_id="m0", reply=None, failure="连接超时")
+    await store.write_model_call_result(result)
+
+    (readback,) = (await store.read_log("r1")).model_results
+
+    assert readback.reply is None
+    assert readback.failure == "连接超时"
+
+
+# --------------------------------------------------------------------------
+# 三、原子写
+# --------------------------------------------------------------------------
+
+
+async def test_action_result_and_step_land_together(store, records):
+    """动作结果与步记录一次原子落地：读回来要么两者都在，要么都不在。
+
+    不原子的话，崩在两者之间会让那一步的历史文本永远丢失，而恢复判定会把它读成「执行完了，
+    跳过」——恢复出来的消息序列比不中断跑完时少一轮，后面每一步都跟着偏。
+
+    **这条测试只能验「一起可见」，验不了「一起不可见」。** 见本文件末尾那条。
+    """
+    step = records.step_completed(
+        run_id="r1", result_id="a0", action_outcome=records.outcome(), step=records.step(step_idx=0)
+    )
+    await store.write_step(step)
+
+    log = await store.read_log("r1")
+
+    assert log.steps == (step,)
+    assert log.steps[0].action_outcome is not None
+
+
+@pytest.mark.xfail(reason="design/0006 答不上，见 docstring", strict=True)
+def test_step_without_an_action_is_still_recorded():
+    """没有动作的步照样留痕：解析失败、模型调用失败、环境故障三种都算一步。
+
+    dissect 的预算对等要求它们计入步数——它们确实消耗了一次模型调用。丢掉那一步还会丢掉
+    模型在出故障时说了什么，而那正是排查「环境坏了还是模型写了危险代码」最需要的。
+
+    **这条现在写不出来。** 这一步没有写过动作意图，所以没有预分配的结果 ID，而
+    `StepCompleted.result_id` 在 `design/0006` 里是必填的字符串。照那个形状写，恢复会读到
+    一条对不上任何意图的记录，按 `design/0002` 四态表最后一行判为「日志损坏，拒绝续跑」
+    ——而这本该是一次恢复成 `llm_error` 正常终止的运行。
+
+    **它不带 fixture，所以不会被「实现还没有」那个跳过挡住。** 挡住了它就看起来像「还没
+    轮到」，而它是「答不上来」，两者要分得开。
+    """
+    pytest.fail("StepCompleted.result_id 对没有动作意图的步没有定义")
+
+
+# --------------------------------------------------------------------------
+# 四、运行的开始与结束
+# --------------------------------------------------------------------------
+
+
+async def test_run_finished_is_visible_before_the_result_is_returned(store, records):
+    """「这次运行结束了」这个标记由库写下，而且写在把结果交给调用方之前。
+
+    另一条路有个具体的失败场景：结果由项目落盘的话，「跑完了、库返回了、项目存的时候崩了」
+    这种情况下，重启后日志显示最后一步有结果、没有结束标记，而项目那边什么都没有。续跑会
+    重复执行最后一步的副作用，不续跑就丢掉一次已经花完钱的运行。歧义来自结果跨了两个存储。
+    """
+    finished = records.run_finished(run_id="r1", result=records.result(run_id="r1"))
+    await store.write_run_finished(finished)
+
+    assert (await store.read_log("r1")).finished == finished
+
+
+async def test_run_started_carries_the_parameter_snapshot(store, records):
+    """运行开始记录带着这次的参数快照，续跑时拿它与当前装配比对。
+
+    没有它，用同一个运行标识换一份定义续跑，前几步与后几步会来自两个不同的配置而全程零
+    报错——那正是要到统计阶段才分不清哪些行是真的那类损坏。
+    """
+    started = records.run_started(run_id="r1", parameter_snapshot={"model": "m-1"})
+    await store.write_run_started(started)
+
+    assert (await store.read_log("r1")).started.parameter_snapshot == {"model": "m-1"}
+
+
+# --------------------------------------------------------------------------
+# 五、这套测试**验不了**的两条承诺
+# --------------------------------------------------------------------------
+
+
+@pytest.mark.xfail(reason="已知缺口：这条承诺没有机器兜底", strict=True)
+def test_atomicity_under_crash_is_not_checkable_here():
+    """原子性的另一半——「崩在中间时两者都不可见」——这一层验不了。
+
+    要验它得在写入过程中把进程杀掉，而契约测试跑在一个进程里、面对的是一个已经装配好的
+    实现，没有位置插入那次崩溃。给端口加一个「故意在这里失败」的钩子能验，但那个钩子会
+    变成公共 API 的一部分，而它只为测试存在。
+
+    结论是这条承诺**没有机器兜底**，只能靠 `CLAUDE.md` §3 那轮对抗审查看实现。把这件事
+    写成一条会失败的测试而不是一句注释，是为了让它在每次跑套件时都被看见。
+    """
+    pytest.fail(
+        "已知缺口：原子写的「一起不可见」这一半没有机器检查。"
+        "落地时要在 stores 的 unit 测试里用可注入的故障点覆盖，"
+        "并在 design/0005 决策二登记这条契约测试覆盖不到。"
+    )
+
+
+@pytest.mark.xfail(reason="已知缺口：这条承诺没有机器兜底", strict=True)
+def test_prefix_durability_is_not_checkable_here():
+    """前缀持久性同样验不了，理由更硬一层。
+
+    它说的是「第 k 次写入被确认持久时，前 k-1 次也已经持久」，而「已经持久」是掉电之后
+    才看得出来的性质。在一个进程里读得回来，不等于它落了盘。
+    """
+    pytest.fail(
+        "已知缺口：前缀持久性没有机器检查。两个已知形态天然满足它"
+        "（同一文件的追加写、同一连接上顺序提交的事务），"
+        "所以它实际是对实现形态的约束，落地时靠评审看，不靠这套测试。"
+    )