hottub/prompts/new-channel.md

Implement a new Hottub provider for <SITE_NAME> at <BASE_URL>.

You are working inside the Hottub Rust server. Your job is to add a functioning provider module that can survive handoff to another model with minimal guesswork. Do not stop at code generation. Carry the work through code, validation, and documentation updates.

Execution order is mandatory:

1. Read the repo docs.
2. Inspect the target site and collect evidence about routes, player/media requests, and pagination.
3. Choose the closest existing provider/proxy as the template.
4. Implement the provider.
5. Validate it end to end.
6. Update docs if the new provider adds a new pattern.

Do not start coding until you know:

• latest/default feed URL
• search URL
• page 2 URL
• detail page URL
• actual media request or manifest URL
• thumbnail behavior
• whether tag/uploader/studio pages exist
• whether the site has a JSON API that is easier than HTML scraping

Read these files first:

1. docs/README.md
2. docs/architecture.md
3. docs/provider-playbook.md
4. docs/provider-catalog.md
5. docs/hottubapp/🎬 Videos - Hot Tub Docs.html
6. docs/hottubapp/📡 Status - Hot Tub Docs.html
7. docs/hottubapp/👤 Uploaders - Hot Tub Docs.html

Then inspect the closest existing providers and proxies before coding. Pick the nearest template instead of starting from scratch.

Template selection rules:

• Use src/providers/vjav.rs if the target site has JSON APIs, rich tag metadata, or stable uploader identities.
• Use src/providers/hsex.rs if the target site is mostly HTML and needs background-loaded tags/uploaders.
• Use src/providers/omgxxx.rs if the site exposes multiple large filter catalogs like sites, networks, models, or studios.
• Use src/providers/noodlemagazine.rs, src/providers/pornhd3x.rs, or src/providers/spankbang.rs if media or thumbnails require local /proxy/... routes.

Required deliverables:

1. Add a new provider file at src/providers/<channel_id>.rs.
2. Register it in build.rs.
3. Export CHANNEL_METADATA with the correct group.
4. Implement get_channel with sane options and descriptions.
5. Implement get_videos so the default feed works, search works, and page 2 works.
6. If the site needs proxying, add src/proxies/<channel_id>.rs and wire src/proxy.rs.
7. Reuse requester_or_default(&options, CHANNEL_ID, "...") for outbound requests.
8. Return high-quality VideoItems with the best metadata the site exposes.
9. Do not use embed unless the site truly requires it.
10. Update docs/provider-catalog.md if you add a new provider or proxy.

Implementation requirements:

• Determine the real site routing for:
  • default/latest listing
  • search
  • page 2 and later
  • tag/category shortcuts
  • uploader/studio/model shortcuts if the site exposes them
  • featured/trending/most-viewed or similar alternate feeds
• Model routing explicitly with a local enum like Target.
• If the site exposes tag or uploader IDs, keep a lookup map from normalized display title to site ID/URL target.
• Put tags into VideoItem.tags.
• Put uploader name/url/id into uploader, uploaderUrl, and uploaderId when available.
• If uploader support is implemented, use a namespaced uploaderId such as <channel>:<site-local-id> so /api/uploaders can route directly.
• If the query matches a known tag/uploader shortcut, use the direct archive URL instead of generic search.
• If the site exposes real media URLs or HLS manifests, populate formats.
• If direct playback needs a referer/cookie transform, use a local /proxy/... route built with build_proxy_url(&options, "...", target).
• Keep the first version small and reliable. Add extra filters only after the default feed, search, and pagination are working.

Validation requirements:

1. cargo check -q
2. HOT_TUB_PROVIDER=<channel_id> cargo check -q
3. HOT_TUB_PROVIDER=<channel_id> cargo run --features debug
4. Verify /api/status exposes the new channel.
5. Verify /api/videos returns results for:
   • default feed
   • search query
   • page 2
   • at least one tag/uploader shortcut if implemented
6. Verify thumbnails load.
7. Verify yt-dlp can resolve video.url or one of formats[*].url.
8. If a proxy route exists, verify it directly with curl -I or equivalent.

Testing commands to run:

curl -s http://127.0.0.1:18080/api/status \
  -H 'User-Agent: Hot%20Tub/22c CFNetwork/1494.0.7 Darwin/23.4.0' | jq

curl -s http://127.0.0.1:18080/api/videos \
  -H 'Content-Type: application/json' \
  -H 'User-Agent: Hot%20Tub/22c CFNetwork/1494.0.7 Darwin/23.4.0' \
  -d '{"channel":"<channel_id>","sort":"new","page":1,"perPage":10}' | jq

curl -s http://127.0.0.1:18080/api/videos \
  -H 'Content-Type: application/json' \
  -d '{"channel":"<channel_id>","query":"test","page":1,"perPage":10}' | jq

Important Hottub-specific rules:

• Do not invent a new provider style if an existing provider already matches the site shape.
• Do not forget build.rs; missing registration means the provider does not exist at runtime.
• Do not create a brand-new requester in normal provider fetches unless you have a strong reason.
• Do not assume page URLs are playable media URLs.
• Do not expose status filters that you did not implement in get_videos.
• Do not finish without checking at least one returned media URL with yt-dlp.
• Do not claim pagination works unless page 2 was verified.

Completion format:

1. Briefly state which existing provider/proxy you used as the template and why.
2. List the files changed.
3. Report the exact validation commands you ran and whether they passed.
4. Report any residual limitations or site behaviors that still need follow-up.