Build this tool: Underdog/Betting Code Compliance Disclaimer Generator
Product folder name: Betting Disclaimer Generator

PRODUCT BRIEF
Tool generates properly formatted, platform-compliant gambling/sponsor disclaimer text based on sponsor type (betting, supplements, merch) to reduce demonetization/legal risk

CONTEXT
Difficulty: Easy
Category: Gaming

TREND HOOK
Bordeaux's "Code BORD on Underdog" sports betting promo in a gaming video

VIDEO ANGLE
Short: "Creators are risking strikes with bad betting disclaimers." Long: build generator, test against real examples.

WHY THIS TOOL
Channel-safety + compliance tool, underserved niche.

STACK (standalone desktop app)
- Python 3 + tkinter GUI (standalone desktop tool — not a website, unless explicitly requested).
- Even if the brief says "web app" / "site", ship a Python desktop GUI for v1.
- Include: main .py, requirements.txt, run_*.bat, build_exe.bat (PyInstaller), and an exports/ folder for saved output.
- Smoke-test core logic offline without requiring live API keys when possible.

GUI RULES
- Clean, readable dark or light UI — pick one consistent palette (no brand lock-in required).
- Clear app title / hero name derived from the product folder name.
- Short muted "How to use: …" line under the title (one sentence: what to enter → what button → what you get).
- Prefer real inputs (paste URL / fields / text) over fake demos.
- No sample dropdowns or canned demo datasets unless explicitly requested.
- Dropdowns: NEVER ttk.Combobox (unreadable on Windows dark UI). Use DarkSelect
  (preferred, no grab_set) OR dark-styled tk.OptionMenu (BG_ELEVATED / TEXT /
  active #243056 / BORDER+TEAL highlight; style the popup menu the same way).
  Never use grab_set (breaks close behavior on Windows).
- Handle window close with WM_DELETE_WINDOW.
- One job per tool; working copy/export; avoid overbuilt dashboards.

APIs & KEYS
- Never hardcode API keys or secrets into source or the packaged EXE.
- Store keys in a local user settings JSON under %LOCALAPPDATA%\<AppName>\ (or a single shared settings file if multiple tools share a key).
- Label each key field clearly in the UI (e.g. YouTube API key vs Gemini API key).
- Local/offline logic must work first; APIs are optional enhancements where possible.
- Call network APIs in a background thread; update the UI with after(...). On failure, keep local results and show a clear error.

Gemini API (optional copy / polish)
- Add optional Gemini when the tool WRITES language creators will paste online
  (titles, captions, descriptions, pinned comments, end-cards, disclaimers, SEO templates).
- UI: API key field + Model text field + checkbox like "Use Gemini" / "Polish with Gemini".
- Default model: gemini-2.5-flash-lite. Also accept typed model ids (e.g. gemini-3.1-flash-lite).
- Do not hardcode the model URL/path; pass the Model field value into the generate call.
- Pattern: compute local templates/scores first; Gemini only rewrites or expands final copy fields.
- On Gemini failure: keep local output, show error, do not wipe results.
- Flash Lite is enough for short creative jobs — do not default to Pro.

IMPLEMENTATION NOTES
- Match the product brief closely; keep v1 focused on one job.
- Support Copy and/or Export of results where useful (TXT/CSV/JSON as fits the tool).
- Validate inputs; show empty/error states clearly.
- If scoring/grading: show score + short explanation of what failed/passed.
- If generating copy: show multiple variants when the brief asks for them.

OUTPUT
- Runnable standalone Python app
- requirements.txt + run bat + optional EXE build script
- In-app how-to line
- Example of typical input → output (in README or comments, not fake UI samples)