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>

tests/evals/results/handoff/h-api-sync-full-r4.json

@@ -0,0 +1,31 @@
+{
+  "case": "h-api-sync/full",
+  "rep": 4,
+  "passed": true,
+  "checks": {
+    "HANDOVER.md written": true,
+    "no other file changed": true,
+    "bot never run": true,
+    "no placeholders left": true,
+    "13 sections in order": true,
+    "used subagents": true,
+    "every status listed": true,
+    "catalogue: 4+ complete rows": true,
+    "F1-F12 all accounted for": true,
+    "no code refs in ops sections": true,
+    "fix-before-handover has file refs": true,
+    "no secrets or personal data": true,
+    "where-to-look respects ops access": true,
+    "asks escalation": true,
+    "asks ops access": true,
+    "known incidents from history": true,
+    "misleading status flagged": true,
+    "retry limit": true,
+    "console-only crash output flagged": true
+  },
+  "cost_usd": 1.259045,
+  "subagents": 2,
+  "work_dir": "C:\\Users\\ec10866\\AppData\\Local\\Temp\\handoff-h-api-sync-full-mf49pa7c\\project",
+  "reply": "I've written `HANDOVER.md` in the repo root. Your three answers were used, so I didn't ask anything. I only read the code and history; the bot was never run, and no code was changed.\n\n| Item | Count |\n|---|---|\n| Sections | 13 |\n| Exceptions catalogued | 13 (E01\u2013E13) |\n| Failure classes | 10 covered, 2 not applicable (F2: the bot drives no windows; F10: one bad invoice never blocks the others) |\n| Fix before handover items | 14 |\n\n**Fix before handover, main items:**\n1. The reason an invoice failed is only printed to the screen, never logged. Every Failed row just says \"No success after 5 tries\".\n2. Duplicate invoices can still happen. The 504 fix still has a timing gap, and there is no idempotency key.\n3. An error while the bot checks \"does this invoice exist\" crashes the whole run, and the crash isn't saved anywhere. A run where every invoice failed still exits as success.\n4. The \"some lines rejected\" case is shown as **Synced**, so those rows hide when ops filter on Status.\n5. Every row is resent every hour, and nothing stops two runs at once. Ops will see Duplicate noise every hour, and overlapping runs risk duplicates.\n6. The code doesn't create the `data/output/` folder, and it isn't in the repo. A fresh machine crashes before the first invoice.\n7. Other items are in the doc: an expired key is retried slowly instead of failing fast, input checks have gaps, the version isn't shown anywhere, the Task Scheduler job isn't documented, the report holds customer names, and an unused `BOT_WAS_RUN` file is written in the bot folder.\n\n**Checks on the doc:**\n- All 4 statuses and 9 messages are listed.\n- No file:line references or code terms outside section 13.\n- No customer data or keys; I never opened the `.env` file or the input file.\n- Every Dev row says what to send.\n- The one path that doesn't exist yet is `data/output/`; it's item 6 above.\n\n**Assumptions to confirm:**\n- The bot has no screens, so for \"ops access\" I took the output and logs folders. The doc doesn't assume ops can open Task Scheduler.\n- On a re-run, I read **Duplicate** as \"already synced in an earlier hour\".\n- The git diff commands were denied, so the incident causes come from the commit messages and the current code, not the actual diffs.\n\nQUESTIONS: Escalation: who does ops call for a dev issue (team or role), and how (ticket, chat channel)? | Ops access: which of the bot's places can ops open - the app's screens, the output folder, the log folder, the database? | Unknowns: any statuses or exceptions whose meaning the code doesn't make clear?",
+  "stderr": ""
+}