{
  "case": "h-api-sync/full",
  "rep": 5,
  "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.3559016000000002,
  "subagents": 2,
  "work_dir": "C:\\Users\\ec10866\\AppData\\Local\\Temp\\handoff-h-api-sync-full-h9gb7d_4\\project",
  "reply": "I wrote `HANDOVER.md` in the repo root (UNVERIFIED in the sense that, as the skill says, I didn't run the bot; it's all from reading the code, git history and the log).\n\n| Item | Count |\n|---|---|\n| Sections | 13 (template order apdiye) |\n| Exceptions catalogued | 13 (E01\u2013E13) |\n| Failure classes | 11 covered, 1 not applicable (F2: bot entha window-um drive pannala, it only calls the billing web API) |\n| Fix before handover | 18 items |\n\nUnga answers use pannen: escalation #rpa-support, and \"Where to look\" only points at the output and logs folders. Bot-ku screens ethuvum illa, so screens row skip pannen. Database-um illa.\n\n**Fix before handover (dev team):**\n1. The `.env` file (API key) is committed to git. Rotate the key, then untrack the file.\n2. The `data/output` folder isn't in the repo and the code doesn't create it, so a fresh install crashes every run.\n3. A network drop while the bot checks billing after a failed send crashes the whole run.\n4. If billing sends a reply the bot can't read, the run crashes, and it crashes at the same invoice every hour, so every invoice after it is blocked.\n5. Crash and network error messages only go to the console, so they're lost under Task Scheduler.\n6. \"Some lines rejected\" (partly rejected) invoices are stored as Synced.\n7. \"Confirmed after retry\" only checks the invoice number, so an older invoice with the same number can hide a send that never happened.\n8. Wrong-key and bad-request errors are retried 5 times like temporary errors.\n9. A missing API key or URL fails silently instead of stopping with a clear error.\n10. An Excel \"CSV UTF-8\" export makes every row show \"missing invoice_no\".\n11. Nothing stops two runs from overlapping, and the report file name only goes to the minute, so one can overwrite the other.\n12. `sync.log` doesn't record the reason, error code or number of tries.\n13. Ops can't see the version anywhere, and stray commit messages are pasted into the README and the code.\n14. The Task Scheduler setup isn't in the repo.\n15. Nobody gets an alert when an invoice fails or the run crashes.\n16. The bot waits 32 s after the 5th try before giving up.\n17. The purpose of the `BOT_WAS_RUN` marker file isn't documented.\n18. There are no regression tests for the two incident fixes.\n\n**Also noticed:** rendu \"fix\" commits-um code-la oru comment mattum thaan add pannudhu. Retry logic already first import-laye irundhuchu.\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": ""
}