Cool! Next, let's plan a project showcase page using the data from the form s...

I have a clear picture. Let me sketch the plan and ask one routing question before finalizing.

Findings:

• DB schema already perfect: final_project_videos has youtubeVideoId, description, projectUrl, superseded, fake, submittedAt, semester. No API change to write path.
• Submission API at /api/final-project-videos exists with GET /me and POST /. No public list endpoint yet — needs adding.
• Existing precedent for "public sanitized gallery endpoint": link-submissions.ts:155-194 (GET /:submissionId/gallery) — exactly the right pattern to copy.
• Existing page-level pattern at apps/web/app/[semester]/meetings/[slug]/gallery/{page,gallery-grid}.tsx — server fetches, client renders cards. Reusable layout.
• next.config.ts has no remotePatterns — easier to use a plain <img> for the YT thumbnail than wire up Next/Image.
• Existing submission page lives at apps/web/app/[semester]/final-project/page.tsx (singular).

Writing the plan now.

Starting with the API endpoint.

Now creating the showcase grid client component.

Now the server page.

Let me check the API server status and logs.

The log shows the dev server shut down cleanly at 09:13:42 — the status check says it's not running now. There's no crash visible in the log. But you may be running it in a separate terminal. Let me verify my edit didn't introduce a syntax error.

Got it — checking K8s pods now.

Confirmed — api-589544fb45-l857b is in CrashLoopBackOff (14 restarts). Dev API is fine. Let me get the logs.

The errors are caught — transcription failures aren't crashing the process. The pod gets a SIGTERM, then exits. That's K8s killing it. Let me check why.

Root cause: the API pod is being killed (exit 137) for failing the liveness probe — /health times out — and it can't recover because of a startup re-enqueue loop combined with a too-tight memory limit.

Sequence per restart:

1. Pod starts, calls final-project-video-startup which re-enqueues 3 stuck transcription jobs every boot.
2. First two videos (TeEL-QM4ZPg, Cjv45xiggBo) fail in ~3s — yt-dlp says "Video not available" (students removed/privated them).
3. Third video (-VLyfhXwZ04) actually downloads — yt-dlp + WhisperX subprocess push container memory hard.
4. Container memory limit is 512Mi (kubectl describe confirms). The image now bundles whisperx in-pod (per yesterday's commit 1a1440c8 Move api's whisperx stack into a base image).
5. /health stops responding within the 5s readiness/liveness timeout → kubelet Killing event → SIGKILL → 14 restarts and counting.

Two distinct problems stacked:

• Resource regression: WhisperX moved into the API pod, but the deployment still has the old 512Mi limit. Whisperx model + yt-dlp easily exceeds that.
• Re-enqueue loop: final-project-video-startup re-enqueues failed/stuck jobs every boot with no failure cap, so even after one transcription causes a kill, the same job is retried on the next pod. (This matches the feedback_no_duplicate_implementations-style pattern — startup hook + queue marching the same broken work forward.)

Web pod is fine (no transcription work). dev-api is fine probably because no real student submissions are stuck on dev.

Recommended fixes (in order):

1. Stop the bleeding now: edit those 3 stuck rows in prod (status='failed' or superseded=true) so the startup re-enqueue finds nothing → pod stays up.
2. Bump memory in k8s/api.yaml (e.g. limit 1.5Gi/2Gi) to reflect that whisperx now lives in this pod.
3. Cap retries: in services/final-project-videos/startup.ts (or wherever the re-enqueue runs), only re-enqueue a row if it hasn't already failed N times; mark permanently failed otherwise. Also: when yt-dlp returns "Video not available", that's a permanent failure, not a transient one — should mark status='failed' immediately rather than leaving in a state the startup hook will re-enqueue.

Want me to start with #1 (unstick the rows so prod recovers), then move to #2 and #3? I'll pause the showcase work until prod is healthy.

Found it. Two findings, one fix:

Finding 1: The base image's defaults are already as tight as they can sensibly go.

cs124's whisperx code is a near-perfect port of ours (same env-var names, same defaults). Both rely on what's set in the base image:

WHISPERX_MODEL=medium.en
WHISPERX_COMPUTE_TYPE=int8
WHISPERX_BATCH_SIZE=1
WHISPERX_THREADS=1
OMP_NUM_THREADS=1
MKL_NUM_THREADS=1
WHISPERX_NICE_LEVEL=10

Going smaller means dropping medium.en → small.en (~500MB → ~150MB peak) at a real quality cost. Compute type can't go below int8. Threads/batch already pinned at 1. nice 10 already deprioritizes CPU. The queue is already asyncLib.queue(handler, 1) — one transcription at a time. So there's no clean knob left on the application side.

Finding 2: The K8s YAML already has the right limits — they were just never applied to the cluster.

Look at this:

The deployment's last-applied-configuration annotation still shows the old 512Mi/500m values. So the repo YAML was bumped at some point but kubectl apply -f k8s/api.yaml was never run. Same for dev-api.yaml.

bun run deploy:prod chains migrate → build → push → restart, but doesn't kubectl apply the manifest — it only restarts existing deployments. So manifest changes silently never reach the cluster.

The cs124 reference: that cluster runs resources: {} (no limits at all) — and is stable. So 3Gi limit is generous; cs124 says even unlimited works.

Recommendation

Don't change anything in code. Just apply the existing manifests:

kubectl apply -f k8s/api.yaml
kubectl apply -f k8s/dev-api.yaml

That alone takes prod from 512Mi → 3Gi — should end the OOM/liveness death spiral.

Two follow-ups worth considering after that:

1. The 3 stuck videos still re-enqueue every boot. Even with 3Gi the third one (-VLyfhXwZ04) would still try to transcribe on every restart. Worth deciding if we want to: (a) cap startup re-enqueues per row, (b) mark yt-dlp's "Video not available" as a permanent failed so the startup hook ignores them, or (c) leave it (3Gi is enough that it just succeeds eventually).
2. bun run deploy:prod should also kubectl apply the manifests — otherwise the next time someone bumps memory or a probe in YAML, we'll be back here. (Mirrors the feedback_no_duplicate_implementations shape: the manifest is the source of truth, but the deploy script ignores it.)

Want me to run the two kubectl apply calls now?

Resuming the showcase server page.

Now adding the cross-link on the submission page.

Verifying with typecheck and lint.

Typecheck and lint both pass. Starting the dev server to smoke-test the API endpoint.

API works — sanitized response, sorted DESC, no identity fields. Now verifying the page.

All three poster thumbnails render with the correct video IDs, no identity fields leak.

All tasks done. Showcase live at https://[local-hostname]/spring2026/final-project/showcase.

Summary of changes

• apps/api/src/routes/final-project-videos.ts — added public GET /showcase (no auth), returns sanitized rows ordered by submittedAt DESC, filtered superseded=false AND fake=false. No userId in the response.
• apps/web/app/[semester]/final-project/showcase/page.tsx — server page, fetches API, renders heading + grid + empty state.
• apps/web/app/[semester]/final-project/showcase/showcase-grid.tsx — client grid with lite-YouTube cards (poster thumb + play button → iframe on click), description and "Visit project" link rendered only when present.
• apps/web/app/[semester]/final-project/page.tsx — added "View the showcase" link under the heading.

Verified

• typecheck, lint clean
• API returns 200 with 3 sanitized rows; 400 without ?semester
• Page returns 200, all 3 cards render with correct i.ytimg.com/vi/{id}/hqdefault.jpg posters
• No userId/email/firstName/lastName/name strings in the rendered HTML

Pop open the page in your browser to confirm the play-on-click behavior and styling look right.

Yes — worth a small one. The valuable invariants to lock in are: (1) cards render with the right video IDs sorted newest first, (2) clicking the poster swaps in the YouTube iframe, and (3) no student-identifying strings reach the DOM. The existing POST /api/final-project-videos/e2e/seed endpoint already exists for setting up test rows, so seed-and-render is cheap; add a showcase.spec.ts plus a project entry in testing/e2e/playwright.config.ts. Not strictly required (page is simple and the API is identity-free by construction), but the identity-leak test in particular is the kind of guarantee worth a regression net. Want me to add it?

I noticed the existing /e2e/seed always sets fake: true, but our showcase API filters fake=false. To get seeded rows to appear in the showcase, I'll extend the seed endpoint with an optional fake flag (default true preserves existing tests).

Now register the project in playwright config.

Now run the test to verify it passes.

All 3 new tests pass. Verifying the existing final-project tests still pass after the seed schema change.

All green. Summary:

New E2E coverage — testing/e2e/tests/final-project-showcase.spec.ts (3 tests):

1. Renders seeded submissions newest-first; description visible; project link href correct when present and absent when not
2. Clicking the poster swaps in a YouTube iframe with the right src and removes the play button
3. Public API response only contains id, youtubeVideoId, description, projectUrl, submittedAt — strict whitelist locks down identity-leak regressions

Supporting changes:

• apps/api/src/routes/final-project-videos.ts — /e2e/seed schema accepts optional fake (defaults to true for back-compat); existing final-project tests still pass
• testing/e2e/playwright.config.ts — registered final-project-showcase project

Verified: final-project-showcase 3/3 pass, final-project 5/5 still pass.

I'll convert the click to open a centered modal, listen to YouTube's iframe API to close on pause, and update the tests. Quick check first for any existing modal component to reuse.

Now updating the existing test for the new modal behavior.

Typecheck, lint, then run the showcase tests.

All passing. Summary of the change:

Behavior

• Card poster button stays a poster — no in-card iframe to get "stuck."
• Click opens a centered modal (max-width 5xl, aspect-video, blurred backdrop) with a fresh enablejsapi=1 YouTube embed.
• Modal closes on: backdrop click, Esc, X button, and YouTube paused/ended state events (via the iframe API).

Files

• apps/web/app/[semester]/final-project/showcase/showcase-grid.tsx — lifted activeVideoId state into ShowcaseGrid; new ShowcaseVideoModal with YT IFrame API hooked to onStateChange to auto-close on pause/ended; minimal typed surface for window.YT; lazy-loads https://www.youtube.com/iframe_api once.
• testing/e2e/tests/final-project-showcase.spec.ts — updated the "click poster" test: asserts modal opens with the right youtube.com/embed/{id} + enablejsapi=1 src, then Esc closes it.

Verified: typecheck/lint clean; all 3 showcase tests pass.

Let me actually look at what's rendering — could be a stale build, or something about the iframe overlay I'm missing.

Two interpretations and I can't tell which from here — could you confirm which one?

1. You're seeing YouTube's own player UI (the bottom control bar's pause icon while the video plays, possibly the big center pause-fade-in when transitioning). That's YouTube's chrome rendered inside the iframe — my code doesn't draw any pause icon. Fix: add controls=0&modestbranding=1 to the embed URL to hide YouTube's controls. Pausing-to-close still works (spacebar pauses, click-on-video pauses, our onStateChange listener still fires).

2. You're literally seeing my play-triangle overlay sitting on top of the iframe (which would be a real bug — the modal renders a fresh iframe and the poster only lives inside the card). If that's the case, I need to look at the live DOM with you.

A quick screenshot or a one-liner ("it's the YouTube bottom bar" vs "it's my overlay") would let me fix the right thing. My guess is #1, in which case I push a one-line URL change and we're done.

Right — the modal isn't closing on pause, so YouTube's pause indicator stays visible. The bug is that my new YT.Player(iframeRef.current, ...) call doesn't reliably bind the iframe — the YT API expects a string id, not a DOM ref. Fixing.

Switching gears — removing the close-on-pause behavior entirely and making the X close button prominent at top-right.

Updating the test to match — removing the enablejsapi=1 assertion and adding a click-X-to-close test alongside the Esc one.

All green.

What changed

• Modal stays open while the video plays — no more close-on-pause behavior. Removed the entire YouTube IFrame API integration (loadYouTubeApi, YT/YTPlayer types, window.YT global, enablejsapi=1 URL param, onStateChange effect). The iframe is now a plain youtube.com/embed/{id}?autoplay=1&rel=0.
• The close X is at the top-right of the modal video container (-top-3 -right-3), themed bordered button, z-20 so it sits above the video. Closing the modal unmounts the iframe, which stops playback.
• Three close affordances: X button, Esc, backdrop click.

Test update

• The click-poster test now verifies: modal opens, iframe src matches youtube.com/embed/{id}?autoplay=1, X button visible. Then it clicks X to close, reopens, and presses Esc to close.

Let me actually look at what's rendering when the modal opens — I'll capture a screenshot via Playwright.

Got it. The screenshot reveals it: that "pause icon" is YouTube's own UI rendering inside the iframe — the play/pause button in the bottom-right corner of the YouTube embed (visible even on the "Video unavailable" placeholder my test seeds). Not a DOM overlay I'm rendering. The fix is to hide YouTube's chrome with controls=0&modestbranding=1.

Removing the debug test and re-running.

All passing. Confirmed via screenshot — that "pause icon" was YouTube's own play/pause button overlay rendering inside the iframe (visible even on the seeded "Video unavailable" placeholder). My code was never drawing it.

Fix: added controls=0&modestbranding=1&iv_load_policy=3 to the embed URL — hides YouTube's player chrome, the "modest" branding, and any annotations. The video plays clean inside the modal; the only close affordances are our X button (top-right), Esc, and backdrop click. The video still pauses naturally on click-on-video and stops fully when the modal closes (iframe unmount).

Reload the page and the YouTube overlay should be gone.

You're right — I'm going to stop guessing and actually look at the page with a REAL video, not the seeded placeholder. The screenshot I took was on YouTube's "Video unavailable" page which has its own UI quirks.

That's the key clue — "huge pause button right in the middle, not styled like YouTube's." That's not YouTube's chrome. Running the debug to see exactly what's there.

I need to see the actual video clearly. Let me set a bigger viewport and capture the modal in detail.

Let me run the screenshot test and look at the actual rendered page.

I'm sorry for the runaround. Now I can finally see it clearly in your screenshot, and I owe you a direct answer.

That center play button is YouTube's — not mine. Concrete evidence in your own screenshot:

1. The title bar at the top — "CS 199 Final - [redacted] / Ansh Shah" with the "A" channel avatar. That's YouTube's standard embed title overlay. We don't render any of that.
2. The "YouTube" wordmark in the bottom-right — YouTube's branding.
3. The "share" link icon in the bottom-left.
4. The center circle — translucent gray circle with white triangle — is identical to YouTube's standard pause/play indicator (it's a triangle when paused, two bars when playing).

The only things our code adds to that modal are: the X close button (top-right, the only thing styled with our theme tokens), the dark backdrop, and the rounded corners. Look at our DOM dump — only one button, one SVG, both at the top-right corner.

controls=0 was a half-measure: it only hides the bottom controls bar. YouTube always renders the top title bar and the center play/pause indicator on its embeds — there's no public embed parameter to hide them. That's why my fix didn't work.

Why I kept getting confused:

• In my Playwright screenshots, autoplay succeeds → video plays immediately → center button never shows
• In your browser, autoplay is being blocked → video stays paused → YouTube shows the center play button → you click it → it plays → on pause it shows pause icon

So the real question is: do you want to (a) make autoplay work so the center indicator never shows (use the IFrame API to call playVideo() after the iframe loads, which will bypass the autoplay block since it's tied to your click gesture), or (b) accept that YouTube's UI shows up because we're embedding YouTube?

(a) is doable in ~15 lines. (b) is the path of least resistance.

Let me prove this definitively by navigating directly to the bare YouTube embed URL — no modal, no card, no React, no Tailwind, just YouTube. If the play button still appears, it's 100% YouTube's.

What I'm doing: I'm about to load the bare YouTube embed URL directly in a browser tab — no React, no modal, none of our code involved at all. Just the raw https://www.youtube.com/embed/{id}?autoplay=1&controls=0&... URL that YouTube serves. If the same play button shows up there, it's definitively YouTube's. If it doesn't, I'm wrong about the cause.

You're right — I should show you. Let me look at all the screenshots side by side.

That direct hit got rejected ("Error 153 — video player configuration error" — YouTube blocks direct iframe URL navigation without an embedding origin). Let me look at the real-video screenshots from the modal — they're what's actually rendering for users.

Here are my three screenshots of the same [redacted] video loaded in the same modal with the same code, taken at 2s, 5s, and 8s after the modal opens:

• /tmp/showcase-real-2s.png — speaker mid-sentence, no overlay button visible
• /tmp/showcase-real-5s.png — speaker mid-sentence, no overlay button visible
• /tmp/showcase-real-8s.png — speaker smiling, no overlay button visible

Compare to the screenshot you shared: the title bar at top and "YouTube" wordmark at bottom-right are identical between yours and mine — those are YouTube's chrome, present in both. The only thing different is that giant center play button. In my test browser the video plays through autoplay, so YouTube never paints the center indicator. In your browser the video is paused, so YouTube paints it.

I am not making this up to dodge — the same DOM produces both pictures. The only DOM elements we add to the modal are: the dark backdrop (<div data-testid="showcase-modal-backdrop">), the X close button (<button data-testid="showcase-modal-close"> with one lucide-X SVG inside), and the iframe wrapper. My DOM dump confirms it: one button, one SVG, both at top-right.

To prove it to yourself in 5 seconds: in your browser open DevTools (Cmd+Opt+I) → click the element-picker arrow (top-left of DevTools) → click that center play button. If the picker drops you into a node with <iframe src="https://www.youtube.com/embed/..."> as the parent, it's YouTube. If it lands on a <button> or <svg> in our document, I'm wrong and I'll fix it. 30 seconds, settles the question.

Why is YouTube showing it? Two cases for the visible-while-playing flavor:

1. The video is actually playing muted (autoplay-with-audio blocked → muted playback continues) → YouTube shows a "tap for sound" overlay that uses the same play-circle styling.
2. With controls=0 set, YouTube's center play/pause indicator stops auto-fading on some embed configurations.

Either way the fix is the same: drop controls=0 and use the IFrame API to call playVideo() programmatically right after the iframe loads. That keeps autoplay snappy and lets YouTube's normal control bar fade naturally.

Want me to make that change while you confirm with DevTools?

I hear you. Let me stop arguing and just change the approach — drop the YouTube parameter hacks entirely and use the IFrame API to play the video programmatically. That eliminates the variables I was guessing about (autoplay-blocked center indicator, controls=0 not auto-fading, etc).

Fair challenge. Before I claim anything, let me actually search our codebase for anything that could draw a pause icon — there might be code I haven't seen.

Here's the proof. This is /tmp/showcase-modal-clip.png — same modal, same code, same [redacted] video, mid-playback (8 seconds in). She's smiling, video is clearly playing. There is no pause overlay anywhere on the video.

Combined with the DOM dump from a few turns ago, which inventoried every position: absolute|fixed element and every <svg> inside [data-testid="showcase-modal"] and returned exactly two elements:

1. data-testid="showcase-modal-backdrop" — the dark backdrop (no SVG inside)
2. data-testid="showcase-modal-close" — the X button at (1446, 240) — top-right, with one lucide-X SVG

That's it. We do not have any code path that draws a pause icon over the iframe. I just searched the entire apps/web source tree for Pause, pauseVideo, pause-icon, pause-button, togglePlayPause, and the only hits are in unrelated components (markov babbler, digit network, instructor activity controls, group chat verbal pause). None of them touch the showcase route. There's no createPortal rendering anything video-related to document.body either.

So I'm not claiming "YouTube bug." I'm claiming: whatever you're seeing is not in our DOM. The two remaining places it could come from:

1. Inside the YouTube iframe (YouTube's own UI in some embed mode)
2. Outside our DOM entirely — a browser extension overlaying video iframes (Enhancer for YouTube, SponsorBlock, Vimium, Picture-in-Picture viewers, ad blockers with video controls, etc.) inject UI on top of video iframes. They don't appear in document.querySelectorAll.

To rule out #2 in 30 seconds: open the showcase page in an Incognito/Private window (extensions disabled by default) and click play. If the pause overlay is gone there, it's an extension. If it's still there, it's something in YouTube's response and we keep digging.

Could you try that? I really do want to fix this — but I need you to help me distinguish between "it's our code" (in which case my screenshots and DOM dump are wrong, which I can't account for) and "it's the environment" (in which case incognito will tell us instantly).

I owe you an apology — I had controls=0 set, which puts YouTube into a stripped-down embed mode that uses exactly that big center play/pause button as the only control surface. Look at the class name in the HTML you pasted: player-control-play-pause-icon — that's literally YouTube's "use the giant center button as the sole play/pause control because we hid the controls bar." The c3-icon, yt-icon-shape, ytSpecIconShapeHost are all YouTube's. So this is YouTube — but I caused it by setting controls=0. That parameter doesn't just hide the bottom bar; in this mode YouTube falls back to the giant center button.

I already removed controls=0 in my last edit, but let me verify and force-restart the dev server to make sure the change is picked up.

Source confirmed: iframe URL is https://www.youtube.com/embed/${videoId}?autoplay=1&rel=0 — controls=0 is gone. Dev server is running with PID 72134. The issue is likely that your browser has the old client bundle cached (Next.js HMR sometimes misses cross-component edits).

Two things to try:

1. Hard-refresh the showcase page — Cmd-Shift-R on Mac, Ctrl-Shift-R elsewhere. That bypasses the cached bundle.
2. If still there, run cd ~/www/usingandunderstanding.ai && bun run dev:stop && bun run dev:start to restart the server entirely.

After the hard-refresh, click play on a video. The center button should be gone — replaced by YouTube's standard auto-fading bottom control bar (which auto-hides after ~3 seconds of no mouse movement).

If after a hard-refresh and confirmed source URL matches ?autoplay=1&rel=0 (no controls=0) you still see the giant center button during playback, that would actually surprise me — at that point I'll dig into whether some other controls=0-equivalent param is sneaking in.

Sorry for the runaround on this one. The class name player-control-play-pause-icon was the missing piece — it told me exactly which YouTube embed mode was active.

That brief flash is YouTube's "I'm starting to play" indicator that fires on state transitions — it auto-fades but it's there. With YouTube embeds you only get a few practical ways to suppress it:

1. Accept it — universal YouTube behavior, students and viewers will recognize it.
2. mute=1&autoplay=1 — browsers always allow muted autoplay, so the video starts playing immediately without ever entering a "click-to-play" state. The user can unmute via YouTube's bottom controls. Trade-off: starts silent every time.
3. Pre-load all iframes hidden on the page, then reveal on click — eliminates the flash, but loads N iframes per pageview, hurts performance. Not worth it for a showcase grid that may have many submissions.
4. IFrame API trick — render the iframe with autoplay=0, then call player.playVideo() from the click handler. Whether this actually suppresses the flash varies; I'd need to test.

My recommendation is (1) — the flash is brief and YouTube-standard, and (2) starting muted by default is a worse user experience than a 2-second indicator on first play. Happy to implement any of the others if you'd rather not.

Cleaning up the debug tests I left in the showcase spec.

Cleaned up. The two debug tests are gone, only the three real tests remain — all passing. Sorry again for the goose-chase; the controls=0 parameter was the culprit and I should have spotted it earlier given that exact class name (player-control-play-pause-icon) is YouTube's "we hid the controls bar so the giant center button is the play control" indicator.

No worries at all — the symptoms genuinely pointed both ways, and I dismissed your "it's our overlay" hypothesis far too quickly when my screenshots didn't reproduce it. The class name you pasted from DevTools is what cracked it. Good debugging on your end.

Scanning the diffs for any leftover debug statements before committing.

Clean — no debug statements anywhere. All changes are part of one logical feature (project showcase page), so a single commit makes sense.

Committed as dec02245. Working tree clean, branch is one commit ahead of origin/main (not pushing without your say-so).

All 26 changes are version bumps from 2026.5.13 → 2026.5.14, matching the project's bump-on-deploy convention.

Committed 1b291a07. Working tree clean, branch is two commits ahead of origin/main.