RFC: Help test RECOVERY.md against real agent failures

[HadjievK]

A kill switch can stop an AI agent's next action, but it cannot determine whether a timed-out operation already changed external state, prevent a duplicate retry, repair the business state, or decide when work can safely resume.

Agent Recovery proposes RECOVERY.md: a declarative, portable recovery plan interpreted by a trusted controller.

We would especially value feedback on three questions:

1. Can the format describe a real side-effecting workflow you operate?
2. Which recovery state, verification result, or escalation rule is missing?
3. What is the smallest interoperable contract between a tool, Action Ledger, and recovery controller?

Please share a concrete scenario, even if the current draft cannot represent it. That is exactly the evidence this RFC needs.

Start with the v0.1.0 RFC: https://github.com/HadjievK/AgentRecovery/releases/tag/v0.1.0

[salahmakboul]

Here is a concrete scenario for question 2, based on the README and principles, not on a full read of the spec, so tell me if the draft already covers it.

Scenario: the old worker isn't dead. A worker stalls past its lease while calling a tool. The controller sees an unknown outcome, verifies, finds nothing, and resumes. Then the old worker wakes up and finishes its call.

I measured that in plain Python with two real processes and a shared SQLite record, 20 runs each:

	sends
lease only	2
each attempt carries a generation number, and a stale one is refused at the record	1

And a second one on verification: with a fake provider whose reads lag 200 ms behind commits, reading back at 0 or 100 ms found nothing and the retry made 2 commits, in 20 of 20 runs. Reading back at 300 ms gave 1.

So two things may be missing as first-class fields: a generation or fencing token that recovery has to advance before it acts, and a statement of how much a "not found" is worth for each verifier. Principle 4 says verify first, and this is the case where verifying can itself mislead.

Disclosure: I maintain Call4Agents, a Python library on the same problem, and this comment was written with AI assistance. If it helps your tests/ folder, I can turn these two into failure-injection cases. Would that be useful?