Add rpa-bot-handoff skill: ops guide for bot handover

The skill scans a bot with subagents (never runs it) and writes
HANDOVER.md, an 11-section ops guide in the operator's order: where is
what, how to run, how long to wait, after the run, how to see an
exception, exception list, how you will know, how to tell us, don'ts,
issues seen before. Dev material (check against 12 failure classes from
Tebra Auto Post, gaps with file:line, incidents) goes to HANDOVER-DEV.md.

Also adds ADR-0004, glossary terms, five fixture bots and a handoff eval
runner (--resume, --regrade) with results from 47 runs of the earlier
13-section version. The grader still expects that structure and must be
updated before the next eval run.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/adr/0004-handover-is-an-ops-guide.md

@@ -0,0 +1,13 @@
+# The handover is an ops guide in the operator's order, with dev notes kept apart
+
+`rpa-bot-handoff` writes two files:
+- `HANDOVER.md` is for the operator who runs the bot and does not read code. Its 11 sections follow the operator's own questions, in the order they ask them: where is what, how do I run it, how long do I wait, how do I read the result and the report, how do I see an exception, how will I know, how do I tell the dev team, what must I not do, what happened before.
+- `HANDOVER-DEV.md` is for developers. It holds the failure-class check and the gaps to fix before handover, with file:line.
+
+Every exception row tells ops whether to wait (the bot retries by itself), act, or call the dev team. Every wait is a number of seconds or minutes taken from the code. The skill changes no code.
+
+**Why:** the first version was one document sorted by architecture and exception type, with dev sections mixed in. Reviewing it, the user said ops need "which tab shows what, how to run, how many seconds to wait, which tab has the report, how to see an exception, how to tell us". In Tebra Auto Post's first months, most ops questions were exactly these. Ops re-ran items the bot was still retrying. They edited rows that needed a check in Tebra first ("Payment not confirmed after Save" had really posted). They couldn't tell why a batch stayed Pending. Architecture, failure classes and file:line refs don't help an operator, and they bury what does.
+
+**Lessons as a checklist:** Tebra's incidents are bundled as 12 generic failure classes. Each new bot is checked against every class in `HANDOVER-DEV.md`, and an unused class is written down as "not applicable" with a reason, so nothing is dropped silently. A scrubbed Tebra example shows both files.
+
+**Subagents are required:** in the first 47 eval runs, 8 wrote the doc without starting the scan subagents. The skill now says to always start them.