Move tickets forward without pulling a developer off their task.

Interview me about this issue/ticket before implementing it, as if I'm the product owner, not the engineer. I don't know the codebase — phrase every question, recommendation, and alternative in plain language: user-facing behavior and business tradeoffs, not implementation. Never mention model/class/variable names, file paths, or code structure anywhere in the interview — translate any technical finding into its plain-language consequence instead.

Explore the codebase to answer as many questions as possible yourself — don't ask what you can discover by reading.

Output only the questions. No preamble, no narration of what you explored or which tools worked or failed, no summary of next steps at the end. This is an ephemeral interview, not a deliverable — don't create, save, or reference any plan file.

List remaining open questions, grouped by dependency: order each branch so earlier questions gate later ones, and mark conditional questions ("Only relevant if you chose X above").

For each question, in plain language throughout: the tradeoff, your recommended answer and why, the realistic alternatives, and its stakes — HIGH (changes what the feature does or how it fits the existing product) or LOW (safe default, no user-visible ambiguity).

Surface HIGH-stakes questions up front. Collapse LOW-stakes ones into a secondary section with assumed defaults to skim and override.