docs and prompt

docs/README.md

@@ -0,0 +1,40 @@
+# Hottub Docs
+
+This folder is the fastest handoff path for anyone adding or repairing a channel.
+
+Start here:
+
+1. Read `architecture.md` for the server flow, request lifecycle, and core types.
+2. Read `provider-playbook.md` for the exact process to add a new provider or proxy.
+3. Use `provider-catalog.md` to find the closest existing implementation to copy.
+4. Use `docs/hottubapp/*.html` when you need the client-facing API contract for status, videos, or uploaders.
+5. Only then touch `prompts/new-channel.md`; it assumes the docs above exist.
+
+Recommended local workflow:
+
+```bash
+cargo check -q
+HOT_TUB_PROVIDER=<channel_id> cargo check -q
+HOT_TUB_PROVIDER=<channel_id> cargo run --features debug
+```
+
+Useful runtime baseline:
+
+```dotenv
+DATABASE_URL=hottub.db
+RUST_LOG=info
+PROXY=0
+BURP_URL=http://127.0.0.1:8081
+FLARE_URL=http://127.0.0.1:8191/v1
+DOMAIN=127.0.0.1:18080
+DISCORD_WEBHOOK=
+```
+
+Key facts:
+
+- Hottub is a Rust `ntex` server with providers under `src/providers/`.
+- `build.rs` controls compile-time provider registration.
+- `/api/videos` is the main provider execution path.
+- `/proxy/...` exists for sites whose direct media or thumbnails need a redirect/proxy layer.
+- Only three providers currently implement `/api/uploaders`: `hsex`, `omgxxx`, and `vjav`.
+- Uploader IDs should be namespaced like `<channel>:<site-local-id>` so `/api/uploaders` can route directly.