Let the candidate mark interviewer lines they did not understand

Need

Candidates practicing an English interview as non-native speakers sometimes miss a few words of what Jim says. When the gap is large, they ask Jim to repeat. When it is only a word or two, they usually answer anyway to keep the conversation moving, and the line is forgotten by the time the report arrives. There is no way to note "I did not fully understand this" at the moment it happens, so the candidate cannot review those words afterward.

Present workaround

The report already ends with ## Conversation transcript (web/render.js), and the replay shows the transcript too. Reviewing it means rereading the whole conversation and trying to remember which lines were unclear, which rarely works for a 30 to 60 minute interview.

Desired outcome

During the interview, a small "Unclear" button next to Jim's caption marks the line currently on screen. After the interview, the report lists the marked lines in one place and also tags them inside the transcript, so the candidate can review both the wording and its context:

## Lines you marked as unclear

1. Jim: "And what would the time complexity look like if we used a monotonic stack here?"

## Conversation transcript

**Jim (marked unclear):** Great. And what would the time complexity look like if we used a monotonic stack here?

**You:** Sorry, could you repeat that?

Scope

• Only interviewer lines can be marked; pressing the button again on the same line unmarks it.
• Jim is not told about a mark, so the conversation is unchanged.
• No model call is added. Marks are not sent to the report model either: they are the candidate's own study notes, and treating them as evidence could lower the Communication score and discourage candidates from using the button.
• The "Lines you marked as unclear" section is omitted when nothing was marked.

Where the marks live after the interview

Marks are kept in the page during the interview and saved with the report as one new top-level field of the history entry, unclearLines: an array of the marked interviewer lines' text, in the order they were spoken, for example ["And what would the time complexity look like if we used a monotonic stack here?"]. The field is added to the entry after the report comes back, so it is never part of the report request. The same entry goes to local history (web/history.js) and to the account through /api/reports, which stores the payload as JSON, so no server change is needed.

The text is saved rather than a turn id because saved history does not keep the transcript, so an id would point at nothing once the report is reopened. For the same reason, a report reopened from Past attempts shows the "Lines you marked as unclear" section from this field but cannot tag lines inside a transcript; its Markdown export already says "(transcript was not saved)".

Local history keeps as many full reports as fit in 164 KB, so the marks need a cap to keep one report from crowding older ones out of that budget. I will measure a typical entry and a typical interviewer line, and choose the cap in the PR from those numbers.

A report saved before this change has no unclearLines field and shows exactly what it shows today. A value that is not an array of strings is treated the same way, since local storage is input that an older build or devtools can write.

Acceptance criteria

• Marking a line during an interview makes it appear in the report's marked section and tagged in the transcript, in both the web report and the Markdown export.
• Unmarking removes it from both.
• A report with no marks looks the same as today.
• The report prompt is unchanged whether or not lines are marked.

Approaches compared

1. An "Unclear" button next to the interviewer caption that marks the current line (each caption already carries a turn id in web/captions.js). Small, needs no model call, and stays invisible to Jim.
2. Detecting spoken repeat requests ("could you repeat that", "sorry?", "pardon?") and marking the preceding line automatically. This could reuse the phrase-matching approach in src/agent/turn_taking.rs, but a bare "repeat" is ambiguous in coding interviews (for example "Longest Substring Without Repeating Characters"), and the request is already visible in the transcript.

I propose 1 here and leave 2 as a possible follow-up once 1 is in.

Related

#258 proposes a "Key moments" section in the report, with moments picked by fixed rules and notes written by a model. This request differs in where the selection comes from: the candidate picks the lines during the interview, and no model call is involved. Both add a report section near the transcript, so I would place "Lines you marked as unclear" where it does not collide with "Key moments", and I am happy to follow whatever order is chosen there. Marked lines could later become one more input to the moment rules in #258, but this request does not depend on it.

#223 and #271 keep Jim's latest line readable on screen during the interview; this issue covers reviewing unclear lines after it ends.