Review Like a Kind, Picky Senior Engineer

I just joined a team and I'm reading this part of the codebase for the first time.
Here are the files from {{folder or module name}}:

{{paste files, each starting with its path}}

Explain it like a helpful teammate on my first day:

1. What this module is for, in two sentences.
2. A map: each file in one line, grouped by role.
3. How a typical request or job flows through it, step by step,
   naming the functions involved.
4. The three things most likely to confuse a newcomer.
5. Anything that looks fragile, surprising or "don't touch this",
   with your reasoning.

Only describe what's actually in the code. If something depends on files
I haven't shown you, say which ones you'd want to see next.

I want to refactor {{what}} because {{why: the pain it causes today}}.

Context:
- Codebase: {{language / framework}}
- Constraints: {{e.g. no downtime, can't change the public API, small team}}
- Current test coverage of this area: {{rough description}}

Don't write the refactored code. Write a plan:

1. The end state in three sentences.
2. A sequence of small steps, each one safe to merge on its own.
   For each step: what changes, how we'll know it worked, how to roll it back.
3. The tests we should add before step 1.
4. The riskiest step, and how to make it less risky.
5. What we should explicitly NOT change during this refactor.

Keep the plan to one screen. If a step feels too big, split it.

Here's a bug report:

"""
{{bug report}}
"""

And here's the relevant code:

"""
{{code}}
"""

Do not fix the bug yet. Instead:

1. Restate the bug as: "When {{condition}}, the code does X but should do Y."
2. List what you'd need to know to reproduce it that isn't in the report.
3. Write the smallest failing test that demonstrates the bug, using
   {{test framework}}. Name it after the behaviour, not the ticket number.
4. Explain why the test fails with the current code, pointing to the line.

Only after I confirm the test is right will we discuss a fix.