Let me read the files I need to modify.

Now let me check the meeting context to understand what data is available.

Let me check the display page layout and how meeting titles are accessed.

Now I have a clear picture. Let me implement all three changes.

Now let me verify totalStages is available from the activity stage context.

Good, totalStages is available. Now let me run the type check.

All three changes are done and TypeScript passes cleanly. Here's a summary:

1. display-activity-stages.tsx — Outer container is now fixed inset-0 z-50 with centered flex layout, covering the entire viewport (hiding MDX content behind it).
2. display-activity-stage.tsx — Pre-session shows "Waiting for class to start…" (only stage 0 renders). Active session shows only the current stage with a number badge, label, and stage counter.
3. print-links.tsx — Added a "Display" section above "Print" with a link to the display page that opens in a new tab.

Now for your follow-up — you want estimated times shown on the display page. I can see from the screenshot that the instructor view shows 4:11 / 15:00 (elapsed / estimated). Let me check how the stage metadata (specifically estimatedTimeSeconds) is accessed so I can add it to the display stage.

Let me check how the instructor view renders the estimated time to understand what you want on the display.

The estimatedTime prop is already available on DisplayActivityStage from the MDX. I just need to use it in the display. Let me update the component.

Now add the estimated time to the stage header display.

TypeScript passes. The display stage header now shows the estimated time (e.g., "15:00") followed by the stage counter (e.g., "3 / 8"), separated by a middle dot. It'll look like:

(3)  Class Discussion                    15:00 · 3 / 8

The estimated time only appears when the MDX stage has an estimatedTime prop set.

Let me understand what timing data is available from the context.

Now let me read the current display-activity-stage.tsx to see what I'm working with.

TypeScript passes. Here's what the display stage now shows during an active session:

Header row: (3) Class Discussion with 15:00 · 3 / 8 on the right

Timeline row (updates every second):

• Started 2:15 PM — actual wall clock time the stage began
• Elapsed 4:11 / 15:00 — effective elapsed vs estimated (turns red when overtime)
• Ends ~2:30 PM — projected end time that adjusts for pauses (or Over by 1:23 if past the estimate)
• Paused indicator when the session is paused
• Future stage projections in lighter text: Strategy Review ~2:40 PM · Class Discussion ~2:55 PM

The projected times account for pauses — if you pause, the "Ends ~" time pushes forward. And the future stage timeline lets you see at a glance when the whole activity should wrap up.

Let me find today's meeting content to understand the current stage structure.

Looking at the meeting content, students are asked to submit AI conversation share links in the <TextSubmission> sections (lines 123-126 and 161-163), and the instructions mention how to create share links for ChatGPT, Claude, and Gemini (lines 105-106, 121, 143).

So yes, the link sharing is already part of the share-out stages. Were you asking whether there's a specific requirement to use Gemini specifically (rather than ChatGPT/Claude/Gemini as options)? Or did you mean something else about enforcing Gemini links?

Let me check what validation TextSubmission does on the input.

Right now there's no URL validation — TextSubmission accepts any text. So yes, students can submit plain text without a link and it'll go through.

Two things to address:

1. Move the <TextSubmission> into the lab stages (Practice Testing, Build a Study Aid) so submitting the link signals completion of the work, rather than being in the separate Share Out stages.

2. Require a URL in the submission — do you want me to add validation to TextSubmission that requires at least one URL to be present before allowing submit? Something like a requireLink prop so it's opt-in per usage?

Let me check what link detection exists.

No — there's no link validation or detection anywhere. The TextSubmission component is just a free-text box with no awareness of URLs.

So for next time, the plan would be:

1. Move <TextSubmission> into the Practice Testing and Build a Study Aid stages to signal completion
2. Add a requireLink prop (or similar) that validates the submission contains a recognized AI chat share link (ChatGPT, Claude, Gemini share URLs) before allowing submit
3. Optionally separate the form into a link field + an optional description/reflection field so it's clearer what's expected

Want me to build the link validation into TextSubmission (with a requireLink prop), or would you prefer a separate dedicated component for link submissions? A separate component might be cleaner since the UX is different — a URL input field + optional text area rather than a single big textarea.

Let me find the share link library.

Good, I have a thorough understanding of the system. Let me design the plan.

Now let me write the final plan.