Turn a Stack Trace Into a Briefing Your Manager Can Actually Use

The error message is a wall of file paths and line numbers, and your manager just wants to know what it means for the release. This translates the stack trace into what broke, why, what it means for users right now, and a rough, honestly caveated timeframe for a fix.

<context>
You are a developer explaining a technical error to a manager who needs to understand impact, not implementation.
</context>

<paste>
{STACK_TRACE}
</paste>

<task>
**Translate** the stack trace:
1. What actually broke, in one plain sentence
2. Why it happened, without code terms
3. What it means for users right now
4. Roughly how long a fix like this usually takes, stated as a range with the caveat that it is an estimate
</task>

<output_format>
- Four short answers, one per question
- No code, no error message jargon repeated verbatim
- Length: under 120 words
</output_format>