I'd like to create a way to collect video submissions from students describin...

I'd like to create a way to collect video submissions from students describing their final project. They should upload them to YouTube, mark them as public or unlisted, and then share the video link. We should caption them automatically using WhisperX, and limit the video submission length to (say) 10 minutes. You can find code doing a similar task in ~/www/cs124.org/servers/api, at least that's the backend code. Develop a plan for this new component, including where to add it to the site.

Do we have reasonable WhisperX defaults set up to avoid enormous memory consumption?

No, let's use medium.

Let's do it!

<<autonomous-loop-dynamic>>

Do we have e2e tests for this that exercise the full pipeline?

Probably not enabled by default, but I'd like them to be there.

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.

The dev API container is crash looping.

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.

Why is the layout for the final project submission page like this? [Image #1]

[Image: source: ~/.claude/image-cache/5d2d38d9-7b74-4692-aaf5-f0d161f960d4/1.png]

Why is the submission form all the way to the right? And let's add a proper title for Final Project Video. Also the login button there does not do a proper returnTo. This is broken in many places across the site. Login should always returnTo the page it's on. Why is this so broken?

Sorry, still bad layout here. [Image #2]

[Image: source: ~/.claude/image-cache/5d2d38d9-7b74-4692-aaf5-f0d161f960d4/2.png]

Better, but now the text is very small.

Can we use the same size as default text on meeting pages?

Nice!

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.

Your task

Pull new page captures from the production database and clean them up for use as course readings. Follow this process strictly.

Step 1: Pull captures

Run bun run captures:pull to pull new captures from the production database to content/spring2026/readings/. Note which files are new.

Step 2: Clean remote DB junk

Run the standard cleanup query to remove iframe cruft captures (Disqus, reCAPTCHA, privacy popups):

bun run db:query prod "DELETE FROM page_captures WHERE url LIKE '%disqus%' OR url LIKE '%recaptcha%' OR url LIKE '%privacy-mgmt%';"

Step 3: Clean article cruft

For each new article, remove common capture artifacts:

• Advertisements: Advertisement lines and [SKIP ADVERTISEMENT](...) links
• Image credits: Credit... lines (NYT image attribution)
• Bylines/bios: Author name, bio paragraphs that duplicate frontmatter info
• Datelines: Date stamps like "March 12, 2026, 8 AM ET" (the date is in frontmatter)
• Narration credits: Read by... / Narration produced by... / Engineered by... blocks at article end
• Newsletter boilerplate: "You're reading the X newsletter..." subscription cruft
• Internal publication links: [Read: ...] blocks (Atlantic "Read more" cross-links)

Preserve all actual article content, external links, and embedded quotes.

Step 4: Restore section breaks

Open the original article URL and compare with the captured MDX. Where the original article has visual section transitions (extra spacing between sections, decorative dividers, typographic ornaments), add --- in the MDX on its own line with blank lines above and below.

Most publications (Atlantic, NYT, New Yorker) encode section breaks as CSS spacing only, which is lost during the HTML-to-Markdown conversion. These need to be restored manually by comparing with the original article.

Step 5: Preserve media embeds

If the article has an associated video or podcast (e.g., Substack, YouTube), add a responsive iframe embed at the top of the article content:

<div style={{ position: "relative", width: "100%", paddingBottom: "56.25%", marginBottom: "2rem" }}>
  <iframe
    src="EMBED_URL"
    style={{ position: "absolute", top: 0, left: 0, width: "100%", height: "100%", border: "none" }}
    allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
    allowFullScreen
  />
</div>

Step 6: Add sidenotes

Review each article for opportunities to add 2-4 sidenotes connecting the article content to course themes. The sidenotes should help students relate what they're reading to their hands-on experience with AI in the course.

Sidenote syntax:

[linked text](sn:note-id)

<Sidenote id="note-id">Note content connecting article to course themes.</Sidenote>

Critical placement rules:

• <Sidenote> blocks are JSX and MUST be standalone paragraphs separated by blank lines above and below — NEVER inline within a paragraph
• The [linked text](sn:id) anchor goes inline in the paragraph text; the <Sidenote> block goes between paragraphs
• If the anchor text is mid-paragraph, place the <Sidenote> block after that paragraph ends, NOT splitting the paragraph around it

Critical: replace smart quotes before adding sidenotes. Web captures contain curly/smart quotes (U+201C, U+201D, U+2018, U+2019) that break MDX JSX parsing. Replace them all with straight quotes early in the cleanup process:

python3 -c "
import sys
with open(sys.argv[1], 'r') as f: text = f.read()
text = text.replace('\u201c', '\"').replace('\u201d', '\"').replace('\u2018', \"'\").replace('\u2019', \"'\")
with open(sys.argv[1], 'w') as f: f.write(text)
" FILE.mdx

Guidelines for good sidenotes:

• Connect article claims to students' direct experience (training networks, using AI tools, etc.)
• Point out when multiple readings are in dialogue with each other
• Ask questions that prompt reflection, not just provide commentary
• Keep them concise — 2-3 sentences max

Step 7: Verify

Start the dev server if not running and check each new reading renders correctly:

• No remaining cruft (ads, credits, bylines)
• Sidenotes render (hover/click triggers margin note)
• Video embeds load where present
• No broken paragraph breaks (especially around Sidenote blocks)

Present all changes for review before committing.

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.

Let's add an optional URL input to the final project submission form.

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.