1.5 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| feedback_refresh_session_history_first | Before touching an in-flight client incident, read the existing session logs/reports first; never re-remediate an account without checking it wasn't already handled. |
|
When picking up an in-flight client incident (especially one worked across multiple/concurrent sessions), grep + read clients/<slug>/session-logs/ and clients/<slug>/reports/ FIRST, before investigating the live tenant. This session's context does NOT carry other sessions' work.
Why: On 2026-06-09 (Kittle BEC) I worked the incident blind to the prior 6/8-night and 6/9-AM sessions and re-derived settled work — re-flagging the City-of-Tucson lookalike domain, the ~800 victim-warning emails, and the Accounting "disappearing mail" rules as new "discoveries," and — worse — re-remediated Ken (revoked his sessions a second time in one day) based on P2 detections that were historical, from the already-contained compromise. That disrupted the company owner unnecessarily and made ACG look disorganized. Mike: "Did you forget half of the work you did? ... That makes me look bad."
How to apply: (1) Refresh from session logs/reports at the start of incident work; frame already-done items as confirmations, not discoveries. (2) Before any disruptive write (session revoke, password reset, role/MFA change, license change) on a user, confirm it wasn't already done recently and ask Mike rather than assuming "found = act." Pair with feedback_syncro_preview_mandatory.