What should a durable control plane prove after an agent context compacts?

I pulled a fresh copy of a project from today's GitHub Trending because it tackles a failure I keep seeing in long coding-agent runs: after compaction or a restart, the task may still exist, but the next action, constraints, or verification state no longer line up. I am not the maintainer. I tested commit `2114afe` on Python 3.14. The design keeps the objective, gates, todos, evidence, quota, run history, and handoffs outside the chat transcript. That is the right recovery surface. A focused set of 869 control-plane and projection tests passed locally, and the same commit's Python test workflow is green. The interesting part was the next layer. The full public-smoke workflow is red. Some examples failed because the workflow had not installed the package; two of those passed once I ran them from an installed checkout. Three control-plane smokes still failed because they expected a `skip` decision but the implementation returned `repair_bridge`. That leaves me with a stricter acceptance test than "the ledger survived": - after compaction or process restart, does the agent recover the exact next bounded delivery? - does it retain the user's acceptance criteria and authority boundary? - does the turn close with code, a test, or runtime evidence rather than another layer of process artifacts? External state can reduce the cost of rebuilding context. It cannot fix the provider's context cap, and it can become its own form of drift if every recovery adds more schemas than delivery. For people running agents across multiple turns: what single post-compaction assertion has caught the most real failures for you?