sf-debuglisted

<!-- Adapted from Jaganpro/sf-skills@ff1ab74 (MIT). This file layers Brite conventions from brite-salesforce/CLAUDE.md §Apex & Automation + §Integrations (Named Credential + Web-to-Lead specifics). --> # sf-debug: Salesforce Debug Log Analysis & Troubleshooting (Brite edition) Use this skill when the user needs **root-cause analysis from debug logs**: governor-limit diagnosis, stack-trace interpretation, slow-query investigation, heap / CPU pressure analysis, or a reproduction-to-fix loop based on log evidence. ## Brite Context Brite's diagnostic stance: - **Apex-first Brite code means the debug targets are Apex.** Flows are rare (sf-flow covers the policy); debugging focuses on Apex trigger/service execution paths. - **Queueable silent-retry is a common Brite signature.** N consecutive "Completed" `AsyncApexJob` rows for the same class in a short window = 1 original + (N-1) silent retries. It signals callout failure — almost always a Named Credential misconfiguration. Check the NC endpoint first, not the Apex. - **Web-to-Lead has an implicit BeforeUpdate cascade.** Brite's Lead Settings (default Lead Owner + "Override the existing record type") drive an UPDATE after the initial before-insert completes. A trigger that appears to fire twice on a Web-to-Lead insert is exhibiting expected behavior. - **Apex Error emails for Lead triggers go to the Web-to-Lead admin.** PII or employee emails in exception messages get redistributed broadly — use role-based descriptions ("Lead