fix: track the runtime's yoagent-state, and say which fold produced a verdict

[yuanhao]

Fixes #2.

The skew is now active

The issue called this latent — graph.rs happened to be byte-identical across 0.4.0 and 0.5.0. That changed today: yoagent-state 0.5.1 ships the lenient fold from yologdev/yoagent#168, so the checker on 0.4 and the runtimes on 0.5.1 now disagree about the same store.

Three parts

1. The bump — yoagent-state = "0.4" → "0.5", resolving to 0.5.1.

2. Check 2 folds the way a runtime does. Since 0.5.1 an op naming a missing node is skipped rather than aborting, so a store containing one is restorable. Failing it would report non-conformance for a store every runtime can open — and it is the one verdict a user cannot act on, because an append-only log cannot have the op removed, and inserting a fix before it rewrites published history and permanently fails check 4.

The skip is reported, not swallowed. It goes to notes, which doesn't fail the check. Masking corruption is the failure mode this must not trade for.

3. The report names the fold version — the issue's second suggestion, and I agree it's worth more than the bump. The skew was previously discoverable only by reading two lockfiles:

conformance-check 0.1.0 — folding with yoagent-state 0.5.1

A build script reads the resolved version from the workspace lock, because cargo exposes no env var for a dependency's resolved version and the requirement ("0.5") isn't what was built. A missing lockfile degrades to unknown rather than failing the build.

Verified against the real store

yologdev/yoyo-gasp at 8,882 events with the one dangling UpdateNode that motivated yoagent#168 — previously failing checks 2 and 6:

conformance-check 0.1.0 — folding with yoagent-state 0.5.1
[PASS] check 1 — envelope round-trip
[PASS] check 2 — replay
       note: UpdateNode at batch index 0 skipped — node not found:
             task_run_day180_20260827T232710Z_session. The log is readable but
             malformed; a conformant runtime folds past this, and so does this check
[PASS] check 3 — vocabulary
[PASS] check 4 — append-only in git
[PASS] check 5 — causation integrity
[PASS] check 6 — restore
[PASS] check 7 — domain↔ops consistency
conformant: all checks passed

Check 4 green because nothing was rewritten — that's the point.

Regression test

a_dangling_op_is_readable_and_reported_not_failed appends a dangling op to the fixture, deriving the envelope from a real event so it tests the fold rather than the parser's required fields. Mutation-verified: reverting check 2 to the strict fold fails it with fold failed: node not found.

23 passed, clippy clean under -Dwarnings.

One judgement call worth your review

I made check 2 lenient rather than strict. My own release note for yoagent-state 0.5.1 said "conformance checkers should use replay_strict" — I now think that was wrong for this checker specifically. Its stated job is "can a conformant runtime fold and restore this store?", and strict would answer a different question than the one the badge claims.

If you'd rather check 2 assert well-formedness instead, the change is one line (replay_with_diagnostics → replay_strict) — but then the yoyo-gasp store stays non-conformant with no legal repair, which is what #168 set out to escape.

🤖 Generated with Claude Code