Files
Rpa_Skills/tests/evals/results/handoff/h-desktop-poster-full-r2.md
VasanthandClaude Opus 5.5 3942fad6cd 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>
2026-10-28 15:01:42 +05:30

222 lines
27 KiB
Markdown

# ClaimDesk Poster - ops handover
Version 1.4.2 · Written 2026-10-23 · Escalation: RPA dev team, Teams channel **#rpa-support**
## 1. What the bot does
ClaimDesk Poster posts remittance payments into the **ClaimDesk** desktop app, one clinic at a time. It reads the input Excel file (sheets **Login**, **Clinics** and **Settings**). For every clinic it signs in to ClaimDesk, opens that clinic, goes through the list of unposted remittances, and posts each ACH payment that is dated on or before the cutoff date. Every remittance it looks at becomes one row on the **Report screen** of the "ClaimDesk Poster" launcher. It runs when ops start it from the launcher. It drives one desktop app: **ClaimDesk**.
## 2. How it works
```
ClaimDesk Poster launcher (the window you use; title bar shows the version)
└─ starts → Posting bot ──drives──> ClaimDesk desktop app
│ (do not touch it while the bot runs;
│ the bot force-closes it after every clinic)
├─ writes → Report screen (one row per remittance)
├─ writes → logs/run_<date>_<time>.log (one file per run)
└─ watchdog: stops the whole run after 5 minutes with no new row
```
- **Launcher:** where you start a run and read the Report screen. The title bar shows the version.
- **Posting bot:** a background program with no window of its own. It does all the clicking.
- **ClaimDesk:** the bot opens it, signs in, and force-closes it again after every clinic, whether the clinic worked or not.
- **Report screen:** one row per remittance: Clinic, Check No, File Status (coloured), Comments. It can be filtered by batch.
- **Run log:** one text file per run in the `logs` folder. It is the only place that shows clinic-level problems, retries and watchdog stops.
- **Watchdog:** if no new Report row appears for 5 minutes, it stops the whole bot at once.
**One run, step by step:**
1. The bot checks that no earlier batch is still open (Pending). If one is, it refuses to start (E01).
2. It reads the input Excel file and creates a new batch. Each clinic in it starts as Pending.
3. For each clinic, it opens ClaimDesk and signs in with the Login sheet's username and password.
4. It clicks the clinic's name in ClaimDesk's clinic list and checks that the window title now shows that clinic.
5. It waits for the remittance list (grid) to load.
6. For each row in the grid:
- not ACH → **Skipped**
- dated after the cutoff → **Deferred**
- otherwise it clicks Post Payment, then Save, and waits for "Payment saved"
7. It writes one Report row per remittance, closes ClaimDesk, and moves on to the next clinic. If anything goes wrong at clinic level, it retries that clinic up to 3 times in total.
8. At the end the batch is marked Completed only if every clinic finished and no Report row is red (Error) or amber (Pending). Otherwise the batch stays **Pending**, and that blocks the next run (E01, E10).
## 3. Before a run
- [ ] **Check the previous batch finished.** Open the last run log. Its last line must be `[RUN SUMMARY] batch <n> done`, and it must have no `left Pending` line. Then on the Report screen, that batch must have no red Error rows. If it fails any of these checks, the new run will refuse to start (E01). Raise it with dev first.
- [ ] The settings file (`.env`) is in the bot's folder. You never need to open or edit it. Without it, every clinic fails (E03).
- [ ] The input Excel file is the one the launcher uses (`data/input/input.xlsx`) and has all three sheets:
- **Login:** username in A2, password in B2.
- **Clinics:** clinic names in column A, starting at row 2.
- **Settings:** the cutoff date in B1.
- [ ] **One clinic per row in the Clinics sheet. No commas or semicolons anywhere in the cell.** The bot splits a cell at every comma and semicolon.
- Bad: `North Clinic, South Clinic` in one cell, or a clinic whose real name contains a comma, like `Smith, Jones Family Care`.
- Good: `North Clinic` in A2 and `South Clinic` in A3.
- A clinic whose real ClaimDesk name contains a comma **cannot be posted by this version** (Fix item 7). Post it by hand.
- [ ] Clinic names are spelled exactly as ClaimDesk's clinic list shows them, including `&`, dots and spaces.
- Bad: `St Marys & Co` when ClaimDesk shows `St. Mary's & Co.`
- Good: `St. Mary's & Co.`
- [ ] The cutoff date in Settings B1 is a real date. The bot compares dates as text, so check a few Deferred rows after the run (E15).
- [ ] The machine stays unlocked for the whole run, and the screen saver and sleep are off. The bot moves the real mouse.
- [ ] The launcher title bar shows version **1.4.2** (see section 10).
## 4. During a run
- **Hands off this machine.** Don't use the mouse or keyboard. The bot clicks with the real mouse, so your clicks and its clicks get mixed up.
- **Close every window whose title contains "ClaimDesk"** before you start, except the launcher: SQL or database browsers, a second ClaimDesk, documents or emails with "ClaimDesk" in their title. The bot takes the first window whose title contains "ClaimDesk", and it has driven the wrong one before (section 9).
- **Don't open or use ClaimDesk yourself on this machine during a run.** The bot force-closes ClaimDesk after every clinic, and anything unsaved is lost.
- **To stop the bot:** the code has no Stop button, and closing the launcher or ClaimDesk is not confirmed to stop it.
- If you must stop it, end the Python process running the bot in Task Manager, then close ClaimDesk.
- The batch then stays Pending and blocks the next run, so tell dev (E01).
- **A run looks stuck** when no new Report row and no new log line appears for several minutes. Don't act yet:
- A clinic that keeps failing can take up to about 7-8 minutes: 3 attempts, each with up to 60 s for the login window, 10 s for the clinic link and 60 s for the grid.
- The watchdog stops the whole run after **5 minutes with no new Report row**.
- Wait at least 10 minutes before you treat it as stuck. Then check the log for `[WATCHDOG]` (E16).
## 5. Where to look when something goes wrong
| Question | Where to look |
|---|---|
| Did the run finish? | Last line of `logs/run_<date>_<time>.log` is `[RUN SUMMARY] batch <n> done`. **"done" only means the run reached the end. It does not mean everything posted.** If the log stops without that line, the run died (E16). |
| Which batch number was it? | The `[RUN SUMMARY] batch <n>` line in the log. Use that number as the batch filter on the Report screen. |
| Which remittances failed? | Report screen, filter by batch: File Status **red (Error)**. Also read the green rows whose Comments are not "Posted successfully" (see section 6). |
| Which clinics failed completely? | **Not on the Report screen.** Search the run log for `left Pending`. A failed clinic may have no Report rows at all. |
| Why did one remittance fail? | Report screen, Comments column. |
| Why did one clinic fail? | Run log: search for `Clinic '<name>'`. The reason is on the `[ERROR]` line. |
| Did the bot already retry? | Run log: `[AUTO-RERUN] attempt 2` / `attempt 3` lines for that clinic. |
| Why did the run refuse to start, or end at once? | The new log file is empty. See E01 and E02. |
| Which version is running? | Launcher title bar. |
| Is the batch Pending or Completed? | **Ops cannot see this** (it is in the database only). Use the first-row check in section 3, or ask dev. |
## 6. Statuses
Report screen, File Status column, with the Comments text that goes with it:
| Status (File Status - Comments) | Colour | Meaning | What ops does |
|---|---|---|---|
| Completed - "Posted successfully" | green | Payment posted and ClaimDesk showed "Payment saved". | nothing |
| Completed - "Remittance Errors on posting" | green | **NOT posted.** ClaimDesk showed its Remittance Errors screen and the bot cancelled. **Needs follow-up despite the green colour.** | Review and post it in ClaimDesk by hand (E13). |
| Completed - "Payment method '<method>' - not posted" | green | Not ACH, so skipped on purpose. **Not posted.** | Nothing, unless the client wants non-ACH payments posted by hand (E14). |
| Deferred - "Check date <date> is after the cutoff - deferred" | grey | Dated after the cutoff in Settings B1. Not posted. | Nothing. A later run picks it up. Spot-check the date (E15). |
| Error - "Save button not found" | red | The payment screen had no Save button. Not saved. **Blocks the batch.** | E11 |
| Error - "Payment not confirmed after Save" | red | Save was clicked but "Payment saved" did not appear within 20 s. **It may really have posted.** Blocks the batch. | E12. Check in ClaimDesk first. |
| Pending (any comment) | amber | Fallback for a result the bot does not recognise. The current version never writes it. Blocks the batch. | Send to dev. |
Clinic and batch statuses (stored in the database, **not shown to ops**):
| Status | Meaning | How ops can tell |
|---|---|---|
| Clinic Pending | The clinic failed 3 attempts or the run died before reaching it. It blocks the batch. | Log line `[DB] Clinic '<name>' left Pending after 3 attempts`, or no rows for that clinic on the Report screen |
| Clinic Success | The clinic was processed. It can have 0 rows if ClaimDesk listed nothing. | No `left Pending` line for it |
| Batch Pending | At least one Pending clinic, or a red or amber row. **The next run refuses to start.** | Section 3 first check; E01 |
| Batch Completed | Everything finished with no red or amber row | Section 3 first check passes |
## 7. Exception catalogue
| ID | What you see | How the bot identifies it | Where it is recorded | Type | Who acts | What to do | Escalate when |
|---|---|---|---|---|---|---|---|
| E01 | You start a run, nothing happens, and the new log file is empty. | Before reading the Excel file, the bot looks for any earlier batch still Pending and refuses to start if it finds one: "A Pending batch exists - finish or clear it before a new upload". | Not in the log. The message only goes to the bot's console. | System | **Dev** | First rule out E02: check the input file. If the input is fine, the previous batch is blocking. Ops cannot clear it. | Always, once E02 is ruled out. Send: the previous run's log file name and its batch number, the time of the failed start, "E01". |
| E02 | Same as E01: nothing happens and the new log file is empty. | The input file is missing the Login sheet, the username or password in Login row 2, or the Clinics or Settings sheet. Messages: "'Login' sheet not found" or "UserName/Password missing in Login sheet (row 2)". | Not in the log. Console only. | Business | Ops | Fix the input file (section 3) and start again. | The input file is correct and it still fails. Treat it as E01. |
| E03 | Every clinic fails. The log shows `[ERROR] Clinic '<name>' : 'CLAIMDESK_EXE'` | The bot cannot find where ClaimDesk is installed: the settings file is missing or incomplete. | Run log; every clinic `left Pending` | System | Ops, then Dev | Check the `.env` file is in the bot's folder. Don't open it or send it. | The file is there. Send: log file name, "E03". |
| E04 | Log: `[ERROR] Clinic '<name>' : Login window not found` | ClaimDesk's login window did not appear within 60 s of starting ClaimDesk. | Run log | System | Bot, then Ops | The bot retries the clinic up to 3 times. After that, open ClaimDesk by hand once to check it starts and signs in, close it, and tell dev the clinic needs a re-run. | Every clinic fails like this. Send: log file name, batch number, "E04". |
| E05 | Log: `[ERROR] Clinic '<name>' : ClaimDesk window not found` | After sign-in, no window title contained "ClaimDesk". | Run log | System | Bot, then Dev | Wait for the 3 attempts. | It ends in `left Pending`. Send: log file name, batch number, "E05". |
| E06 | Log: `[ERROR] Clinic '<name>' : Clinic '<name>' not found in list` | The clinic's name did not appear as a link in ClaimDesk's clinic list within 10 s. | Run log; after 3 attempts, `left Pending` | Business (usually) | Bot, then Ops | Check the Clinics sheet against ClaimDesk: exact spelling, one clinic per row, no commas or semicolons. If **every** clinic shows this, check the Login username and password: a failed sign-in shows up as this message. | The spelling is exact and the clinic is visible in ClaimDesk. Send: log file name, batch number, "E06". |
| E07 | Log: `[ERROR] Clinic '<name>' : Wrong clinic opened, leaving Pending: <name>` | After clicking the clinic, the ClaimDesk title bar did not contain the clinic name exactly. Names with `&` or other special characters have caused this. | Run log | System | Bot, then Ops | Compare the name in the Clinics sheet with ClaimDesk's title bar for that clinic. | The spelling is already exact. Send: log file name, batch number, "E07". |
| E08 | Log: `[ERROR] Clinic '<name>' : Remittance grid did not load` | The remittance list did not appear within 60 s of opening the clinic. | Run log | System | Bot, then Ops | The bot retries 3 times. ClaimDesk may be slow. Tell dev the clinic needs a re-run. | The same clinic fails like this in 2 runs. Send: log file name, batch number, "E08". |
| E09 | Log: `[ERROR] Clinic '<name>' : <any other text>` | An unexpected failure inside the clinic, for example the Post Payment button was not found. | Run log | System | Bot, then Dev | Wait for the 3 attempts. | It ends in `left Pending`. Send: log file name, batch number, the full `[ERROR]` line, "E09". |
| E10 | Log: `[DB] Clinic '<name>' left Pending after 3 attempts`. The clinic has few or no rows on the Report screen. | All 3 attempts for the clinic failed (E03-E09). | Run log only. **Not on the Report screen.** | System | Dev | Read the `[ERROR]` lines above it for the reason, and fix input causes (E06, E07). The batch stays Pending and **blocks the next run**. Ops cannot release it. | Always. Send: log file name, batch number, clinic name, the reason from the `[ERROR]` line, "E10". |
| E11 | Report: red **Error** - "Save button not found" | After Post Payment, no Save button appeared within 10 s. Not retried. | Report screen | System | Ops, then Dev | Check in ClaimDesk that the payment was **not** posted. If it needs posting, post it by hand. The red row blocks the batch. | Always, so dev can correct the row. Send: batch number, clinic, check number, time, log file name, "E11". |
| E12 | Report: red **Error** - "Payment not confirmed after Save" | The bot clicked Save and waited 20 s for "Payment saved", which never appeared. Not retried. **The payment may have posted anyway.** | Report screen | System | **Ops**, then Dev | **Check the payment in ClaimDesk before doing anything.** If it posted, do not post it again: a second post creates a duplicate payment. If it did not post, post it by hand. Either way the red row blocks the batch. | Always, so dev can correct the row. Send: batch number, clinic, check number, "posted: yes/no", "E12". |
| E13 | Report: green **Completed** - "Remittance Errors on posting" | ClaimDesk showed its "Remittance Errors" screen within 5 s of Post Payment. The bot pressed Cancel. | Report screen | Business | Ops | **Not posted, despite the green colour.** Review the remittance's errors in ClaimDesk and post it by hand or follow the client's process. | ClaimDesk shows no error for it. Send: batch number, clinic, check number, "E13". |
| E14 | Report: green **Completed** - "Payment method '<method>' - not posted" | The method in ClaimDesk is not ACH. | Report screen | Business | Ops | Nothing, unless the client wants non-ACH payments posted. Then post them by hand. | Never. This is by design. |
| E15 | Report: grey **Deferred** - "Check date <date> is after the cutoff - deferred" | The check date is later than the cutoff in Settings B1. The bot compares the dates **as text**. | Report screen | Business | Ops | Nothing; the next run picks it up. Spot-check a few rows: if a date clearly on or before the cutoff was deferred, or a later one posted, report it. | A deferred or posted row has the wrong date. Send: batch number, clinic, check number, the cutoff value, "E15". |
| E16 | The run stops part-way. The log's last line is `[WATCHDOG] no progress for 300s - killing run`, with no `[RUN SUMMARY]` line. ClaimDesk may still be open. | No new Report row for 5 minutes. A clinic retrying, or several clinics in a row with no remittances, can trigger it even when the bot is still working. | Run log | System | Dev | Close ClaimDesk. The batch stays Pending and **blocks the next run**. Clinics after the stop were never processed. | Always. Send: log file name, batch number, time, last clinic in the log, "E16". |
| E17 | Log: `[AUTO-RERUN] attempt 2 for '<name>'` (or attempt 3). ClaimDesk closes and reopens. | A clinic-level failure (E03-E09) triggers a fresh ClaimDesk start and sign-in. | Run log | System | Bot | Wait. At most 3 attempts per clinic. | The same clinic shows more than 3 attempts in one run. Send: log file name, "E17". |
| E18 | The same check number appears twice for one clinic on the Report screen. | When a clinic fails part-way and is retried, remittances still in ClaimDesk's list are written again. | Report screen | System | Ops, then Dev | Count each check once. Use the latest row. A red row from the first attempt still blocks the batch even if the retry posted it. | There is a red row from an earlier attempt. Send: batch number, clinic, check number, "E18". |
| E19 | The bot clicks in a window other than ClaimDesk, or ClaimDesk you had open closes suddenly. | The bot takes the first window whose title contains "ClaimDesk". It also force-closes ClaimDesk after every clinic. | Not recorded. Usually shows up as E06 or E09 in the log. | System | Ops | Follow section 4: close other "ClaimDesk" windows and keep hands off. Let the run finish, then check the Report screen. | It happens with only the launcher and ClaimDesk open. Send: log file name, a screenshot of what was open, "E19". |
## 8. What the bot recovers by itself
| Problem | What the bot does | Limit | After the limit |
|---|---|---|---|
| Any clinic-level failure (E03-E09) | Force-closes ClaimDesk, restarts it, signs in again and redoes the clinic from the start | 3 attempts per clinic, each up to about 2.5 min of waiting | Clinic left Pending (E10), next clinic. The batch stays Pending. |
| No progress | Watchdog stops the whole run | 5 min without a new Report row | Run ends, batch Pending, ClaimDesk may stay open (E16) |
| Save button missing / save not confirmed | **No retry** | - | Row red Error, next remittance (E11, E12) |
| ClaimDesk "Remittance Errors" screen | Presses Cancel | waits 5 s for the screen | Row green "Remittance Errors on posting" (E13) |
| Run died or was stopped | **No resume.** A new run starts a new batch, but only after dev releases the old Pending batch. | - | E01 |
## 9. Known incidents
Newest first. The git history has no real dates, so dates are unknown unless a log shows one.
| When / version | What ops saw | Cause | What to do now | Ops could handle? |
|---|---|---|---|---|
| After 1.3.0 | The launcher still showed and ran 1.3.0 after an update | The launcher kept the old program folder until it was restarted | Fully close and reopen the launcher after every update, then check the title bar (section 10). The fix is not in this repo, so it is unverified. | Yes |
| Before 1.4.2 | Red rows "Payment not confirmed after Save" that had really posted | Save took longer than the 10 s wait | Wait raised to 20 s. A slower save still produces this. **Always check ClaimDesk first** (E12). | Partly |
| Before 1.4.2 | Clinics never processed; "not found in list" for pieces of a name | Names with commas were split into pieces | One clinic per row, no commas. A name that really contains a comma still can't be posted (Fix 7). | Partly |
| Before 1.4.2 | The bot drove a SQL browser window instead of ClaimDesk, then closed the real ClaimDesk | That window's title contained "ClaimDesk" | Close every other "ClaimDesk" window before a run (section 4). The code is **not** fixed. | Partly |
| 2026-09-01 run log (older build) | A clinic whose name contains `&` failed "Wrong clinic opened", was re-run, and the run was then stopped by the watchdog | Exact title match on a special-character name; the watchdog fired during retries | E07, E16 | Partly |
| 2026-09-01 run log (older build) | "could not bring window to foreground" warning | Someone used the machine, or another window held focus | Hands off the machine (section 4) | Yes |
## 10. Releases and version check
- **How an update arrives:** through the launcher. The update code is not in this repo, so dev must confirm the exact steps.
- **How to confirm it applied:** after an update, **close the launcher completely and reopen it**. The title bar must show the new version number. This is version 1.4.2.
- **If the version did not change:** close the launcher again and make sure no launcher window or process is left running, then reopen it. If it still shows the old number, tell #rpa-support with the version you see and the version expected.
- Each machine keeps its own batch history. A Pending batch on one machine blocks only that machine.
## 11. Escalating to dev
Post in the Teams channel **#rpa-support** (RPA dev team).
Send:
- the exception ID from section 7
- the batch number (from the `[RUN SUMMARY]` line or the Report screen filter)
- the time of the failure
- the run log file name `logs/run_<date>_<time>.log`
- the clinic and check number if it is about one row
- a screenshot of the Report screen or of ClaimDesk if it helps
Never send: the Login sheet or its password, the `.env` settings file, or patient data. Logs can contain clinic names, so attach the file rather than pasting lines into chat.
## 12. Failure-class check
- **F1** Missing prerequisite: covered in section 3 (settings file, input sheets) and in E02 and E03. Fix 13 and 15 cover the unlogged startup errors and missing database tables.
- **F2** Wrong window or focus: covered in section 4, E19 and section 9. Fix 5 and 6.
- **F3** Slow or different target app: covered in E04-E09, E11 and E12, with timeouts in section 8. Fix 4 and 18.
- **F4** Input read differently: covered in section 3 (commas, spelling, cutoff date) and in E06, E07 and E15. Fix 7, 8 and 14.
- **F5** Marked done when nothing was done: the clinic name is checked against the title bar (E07). But a clinic is marked Success with 0 rows if the grid is empty or not yet filled. Fix 16.
- **F6** Action happened but not confirmed: covered in E12 ("check in ClaimDesk first"). Fix 4.
- **F7** Business exception shown as success: covered in section 6 and in E13 and E14. Fix 2.
- **F8** Endless re-runs or watchdog kills: covered in section 8 and in E16 and E17. Fix 9.
- **F9** Stopping the wrong way: covered in section 4. Fix 17.
- **F10** One stuck item blocks the queue: covered in E01, E10, E11, E12 and E18. Fix 1.
- **F11** Cause hidden from ops: covered in section 5 (clinic failures are in the log only). Fix 10, 11, 12 and 13.
- **F12** Update didn't arrive: covered in section 10. Fix 19. Not applicable to shared resources: nothing is written to a shared database or server on start; each machine uses its own local database.
## 13. Fix before handover (dev team)
| # | Gap | Why it hurts ops | Where (file:line) |
|---|---|---|---|
| 1 | Any Pending batch blocks every new run. There is no Clear, Resume or row-edit option, and ops cannot open the DB. | One red row or one watchdog kill stops all posting until a dev edits the DB | bot.py:167-168, bot.py:150-154 |
| 2 | "Rejected by app" (not posted) is stored as Completed, green | Ops reads unposted payments as done | bot.py:29 |
| 3 | "Skipped" non-ACH is also green Completed | Not posted, but looks done; at least needs a distinct colour | bot.py:30 |
| 4 | "Payment not confirmed" does no second check (e.g. re-read the grid). 20 s is still a fixed wait. | False red rows, a duplicate-posting risk, and the batch is blocked | bot.py:117-118, bot.py:21 |
| 5 | Window match is by substring "ClaimDesk". It also matches the launcher ("ClaimDesk Poster") and "ClaimDesk Login". The SQL-browser "fix" is only a comment. | The bot can drive the wrong window and kill the real ClaimDesk | bot.py:66-70, bot.py:185 |
| 6 | No wait after clicking Sign in, so the bot may grab the login window. A failed sign-in surfaces as "Clinic not found in list". | Misleading cause, 3 wasted attempts per clinic | bot.py:82-83 |
| 7 | Clinic cells are split on `,` and `;`. A real name with a comma can never be posted. The fix was README text only. | Clinics silently skipped | bot.py:62, README.md:8 |
| 8 | The clinic check needs the exact name in the title bar. `&` and other special characters have failed it. | Clinics left Pending | bot.py:91 |
| 9 | The watchdog heartbeat only runs per remittance row. Login, grid waits, retries and 0-row clinics never beat. A kill leaves ClaimDesk open and the batch Pending. | Healthy runs killed; next run blocked | bot.py:39-49, bot.py:137 |
| 10 | Clinic-level failures write no Report row | Failed clinics are invisible on the Report screen | bot.py:143-147 |
| 11 | The technical-detail column is written but not shown on the Report screen | Ops lacks the dev-level cause | report_screen.py:6 |
| 12 | The batch status is not shown anywhere ops can see. `[RUN SUMMARY] ... done` prints even when the batch stays Pending. | Ops can't tell if a run really completed | bot.py:177-180 |
| 13 | Startup failures (Pending batch, input sheets, missing DB tables) are raised before or outside logging, so the log file is empty | Ops sees "nothing happened" | bot.py:161-169, bot.py:52-63 |
| 14 | A clinic retry re-logs rows already written, so duplicates appear. A stale Error row from attempt 1 keeps blocking. | Confusing Report screen; batch blocked | bot.py:136-139 |
| 15 | DB tables are never created by the code. A fresh machine fails at the Pending check. | A new install can't run, and nothing is logged | bot.py:166-167 |
| 16 | A clinic is marked Success with 0 rows without confirming the grid finished loading | A clinic could be "done" with nothing posted | bot.py:96-101, bot.py:140 |
| 17 | No Stop mechanism. The launcher-to-bot process link and its behaviour on close are unknown (launcher code not in repo). | Ops has to kill processes in Task Manager | bot.py:157-180 |
| 18 | The "Remittance Errors" popup is only waited for 5 s. A slower popup ends as "Save button not found" with the popup left open. | Wrong cause; the next row may misfire | bot.py:110 |
| 19 | Launcher/updater code is not in this repo. The 1.3.0 "fix" is only a comment and can't be verified. | Update failures can't be diagnosed | report_screen.py:8, report_screen.py:14 |
| 20 | `.env` is committed to git and holds an unused password-fallback key and an unused alert setting. | Credential exposure; no alerts actually sent | .env |
| 21 | The committed run log (older build) contains a patient name | PHI in the repo; purge it from history | logs/run_20260901_101500.log:3 |
| 22 | The cutoff is compared as text, not as a date | Wrong Deferred/Posted decisions | bot.py:107 |
| 23 | The Login password is stored in plain text in the input Excel | The credential sits in an ops-handled file | bot.py:56 |
| 24 | The log prefix is doubled: `[ERROR] [ERROR]` | Noise when ops searches the log | bot.py:144 |