sync: auto-sync from GURU-BEAST-ROG at 2026-07-07 11:44:27

Author: Mike Swanson
Machine: GURU-BEAST-ROG
Timestamp: 2026-07-07 11:44:27

clients/prairie-schooner/session-logs/2026-07/2026-07-07-discord-bot-winter-tina-dns-web-outage.md

@@ -99,3 +99,13 @@ and full resolution comments. Bot alerts posted to #dev-alerts (RMM fix) and #bo
 - Discord thread: 1524109428582908086 (#tech-department).
 - Related project: projects/gps-rmm-audit (Prairie Schooner cid 3664974, EDR deploy Monday
   2026-07-07; TPS billed $10/mo backup with no backup found — separate open item there).
+
+## Update: 11:47 AZ — Billing on #32509
+
+- Winter requested 0.5h remote labor on #32509, tech = Howard.
+- Added line item 43169157 (Labor - Remote Business, 0.5 @ $150 = $75.00, taxable no).
+- API quirk: `user_id` on add_line_item AND update_line_item both ignored — line stuck
+  attributed to API key owner (1735/Mike). Stopped per skill hard rule; Winter corrected
+  the tech to Howard and generated the invoice in the Syncro GUI herself.
+- Invoice #67995 (id 1650972203), $75.00, ticket marked Invoiced (by Winter, GUI).
+- Applied standard invoice note (no prepaid block -> block-rate upsell line). Bot alert posted.

errorlog.md

@@ -19,6 +19,8 @@ Categories (the `[type]` tag): _(none)_ = skill/command execution failure ·
 
 <!-- Append entries below this line -->
 
+2026-07-07 | GURU-BEAST-ROG | syncro | add_line_item and update_line_item both ignored user_id override - line item attributed to API key owner (1735) despite user_id 1750 in payload; needed GUI fix [ctx: ticket=32509 line=43169157]
+
 2026-07-07 | GURU-5070 | bash/env | [friction] appended a scratch write to /tmp/_vwpinv inside the syncro invoice block; PreToolUse block-tmp-path hook blocked the ENTIRE Bash call so no invoice ran - had to re-run. Never write scratch to /tmp on Windows; use a repo-relative path or skip it [ctx: ref=feedback_tmp_path_windows]
 
 2026-07-07 | GURU-5070 | troubleshooting/assumption | [correction] repeatedly asserted Datto EDR was not cleanly uninstalled and pushed reinstall-to-uninstall; user had already removed it via its own uninstaller. A persistent WFP block filter can survive a clean uninstall (vendor bug) - frame it that way, don't blame the operator's removal