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-screens-r2.json

@@ -0,0 +1,31 @@
+{
+  "case": "h-api-sync/screens",
+  "rep": 2,
+  "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.5065946000000001,
+  "subagents": 2,
+  "work_dir": "C:\\Users\\ec10866\\AppData\\Local\\Temp\\handoff-h-api-sync-screens-456f_fnz\\project",
+  "reply": "I've written `HANDOVER.md` in the repo root, following the skill. Bot run pannala, code change edhuvum illa; written file `HANDOVER.md` mattum dhaan.\n\n| Check | Result |\n|---|---|\n| Sections | 13, template order-la |\n| Exceptions catalogued | 13 (E01\u2013E13) |\n| Failure classes | 11 covered, 1 not applicable (F2: the bot drives no windows, it just calls the billing API) |\n| Statuses | All 9 status/message combinations the bot writes are listed. CSV report, so no colours |\n| Where to look | Only the output folder and report files, as you said. The log is marked dev-only |\n| Secrets / customer data | Doc-la `.env` values, keys, customer names, IPs edhuvum illa |\n\n**Fix before handover \u2014 16 items. Top ones:**\n1. The `.env` file with the live API key was committed to git in the first commit, and there's no `.gitignore`. **Rotate the key.**\n2. When billing rejects only some lines of an invoice, the row still shows \"Synced\", and which lines were dropped isn't recorded.\n3. If billing times out during the \"does this invoice already exist?\" check, the whole run stops. The report just ends partway, with no reason.\n4. Duplicate invoices in billing are still possible.\n5. Crashes and network errors go only to the console, so ops can't tell a finished run from a stopped one.\n6. `data/output` isn't in the repo and the code doesn't create it, so the first run on a new machine stops with no report.\n\n**Also noticed:** the two \"fix\" commits only added comment lines; the actual retry and duplicate-check code was already in the first commit. So git history doesn't show when those fixes really went in.\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: what do the statuses or exceptions mean whose meaning the code doesn't make clear?",
+  "stderr": ""
+}