"""存储接缝的行为契约。

这份文件是「一次运行的日志到底保证什么」的权威（`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_completed(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(
        "已知缺口：前缀持久性没有机器检查。两个已知形态天然满足它"
        "（同一文件的追加写、同一连接上顺序提交的事务），"
        "所以它实际是对实现形态的约束，落地时靠评审看，不靠这套测试。"
    )