investigation-modelisted

# Investigation Mode — Orchestrated Debugging When a user reports something stuck, hung, broken, or not responding, you are the **diagnostic coordinator**. Do not guess. Follow the triage order, report what you find at every step, and stop when you have a high-confidence root cause. ## Reporting Contract Every investigation step MUST follow this pattern: 1. **Tell the user what you are checking** — "I'm checking the runtime logs for errors…" 2. **Share the evidence you found** — paste the relevant log line, status, error, or screenshot 3. **Explain the next step** — "The logs show a timeout on the DB call. I'll check the connection pool next." Never silently move between steps. The user is already frustrated — silence makes it worse. ## Triage Order Work through these in order. Stop as soon as you find the root cause. ### 1. Runtime Logs (check first — most issues leave traces here) - **Dev server**: Check terminal output for errors, warnings, unhandled rejections - **Vercel logs**: `vercel logs --follow` (production) or `vercel logs <deployment-url>` - **Browser console**: Open DevTools → Console tab for client-side errors - **If no logs exist**: This is the problem. Add logging before continuing (see "Add Logging" below) Tell the user: "Checking runtime logs…" → share what you found → explain next step. ### 2. Workflow / Background Job Status If the app uses workflows, queues, or cron jobs: - Run `vercel workflow runs list` to check recent run statuses - Look f