# AutoShorts dashboard → Director render → private YouTube → website companion

Use this reference for the user's TrueTrace/AutoShorts short-form pipeline when a dashboard `APPROVE_PRODUCTION <queue_item_id>` or hash-bound `APPROVED_FOR_PRIVATE_YOUTUBE_UPLOAD ...` command appears.

## Production approval flow

1. Resolve the current queue item through the dashboard agent API (`/api/agent/production/next` or the specific queue item state).
2. If status is still `locked_next`, first call `/concept-proposed`, then `/approve-generation`; do not skip the concept gate just because the user sent `APPROVE_PRODUCTION`.
3. Produce a **real Director Pass render**, not the dashboard's deterministic workflow-preview bridge, when the user expects a reviewable video.
4. Generate or select 3–5 premium AI styleframes/keyframes for the concrete scam scenario. Avoid PowerPoint cards, generic icons, templates, large title slides, unreviewed logos, real URLs, phone numbers, bank/card/IBAN/private data.
5. Render with Gianna premium voice where this channel uses it; keep `video_duration <= voice_duration + 0.5s`.
6. Run visual QA on a framesheet. If subtitles sit near the Shorts/logo area, move them higher and re-render; the hash and approval command must then be regenerated. Also inspect the last 1–2 seconds separately: Whisper/forced-alignment can hallucinate zero-duration trailing words after an acronym (e.g. final `QR` becoming an extra burned-in `YOU ARE`). If that happens, filter/remove the hallucinated trailing words in the alignment JSON or subtitle segmentation, re-render, and verify a late-frame screenshot before reporting approval text.
7. Import the finished package into the dashboard using a `storage/incoming/<package_id>/manifest.json` with `queue_item_id`, quality gates, source metadata, and `status: ready_for_review`; then mark the queue item ready/in_review. If a user-approved review video needs a small fix after import, create a new superseding package ID/version (for example `_director_v2`), import that, mark the queue item to the new `video_asset_id`, and clearly tell the user to use only the new upload command.
8. Report dashboard review URLs and the exact next hash-bound YouTube approval command. Do not upload or update the website before the separate upload approval.

## Hash-bound private YouTube upload flow

1. Load the approved upload package and re-validate:
   - approval text exactly matches candidate ID, version, video SHA, and posting-pack SHA;
   - `privacyStatus=private`;
   - `containsSyntheticMedia` and `selfDeclaredMadeForKids` match the package;
   - token scope is only `https://www.googleapis.com/auth/youtube.upload`.
2. Candidate-local upload packages require `AUTOSHORTS_YOUTUBE_PACKAGE_DIR='<candidate>/<version>/youtube_private_upload_package'` before running the upload executor; otherwise the CLI looks in the default package directory.
3. Execute only the upload-only CLI/API path. Acceptable endpoints are `videos.insert` and, if an approved thumbnail exists, `thumbnails.set`. Never call comments, analytics, public-publish, or broad YouTube scopes in this flow.
4. Import the upload audit into the dashboard via the reconciliation endpoint so the video asset and YouTube draft become `uploaded_private`.

## Website companion after private upload

For this user's workflow, after successful private upload:

1. Create/update the website candidate JSON and generated red-flag Markdown page.
2. Set `videoUrl` to the real Shorts URL even while YouTube is still private; the user manually switches visibility in Studio.
3. Generate/update the real start-frame thumbnail from the uploaded MP4.
4. Run the website build/QA and browser-check the new live or preview page; verify that `Open on YouTube` is visible and links to the new Shorts URL.
5. Commit and push only the files for the new companion page; avoid sweeping unrelated pending website files into the commit.
6. Update dashboard `WebsiteCompanion` state/status if the dashboard would otherwise show the website as missing.

## Pitfalls from session work

- YouTube Studio CSV imports can include private/unavailable videos. Before using analytics to steer future topics, probe each `Videos` ID for public availability (for example with `yt-dlp --skip-download --print '%(id)s\t%(availability)s\t%(title)s' https://www.youtube.com/watch?v=<id>`), exclude private/unavailable rows from performance learning, then store/apply the public-only analysis to dashboard recommendations.
- The dashboard currently imports CSV metrics and emits basic analytics insights, but production recommendation weighting does not reliably enforce public-only filtering or deep creative conclusions by itself; when the user asks for performance-informed next topics, apply a separate public-only analysis and write explicit `performance_recommendation` queue items or equivalent settings.
- The dashboard `generate-review-package` service may emit a control-plane preview labelled as a workflow preview. That is useful for bridge testing, but not acceptable as the final video when the user approved a real Short.
- After re-rendering for any visual-only change, recalculate MP4 SHA and rebuild the YouTube private upload package; never reuse the previous approval command.
- Subtitle QA must include the final subtitle, not only the framesheet overview. Late-frame spot checks catch acronym hallucinations such as `QR` being transcribed/rendered as `you are` after the real spoken ending.
- The dashboard `/concept-proposed` fallback can produce stale or mismatched script/storyboard text from a previous concept even when the queue item title/family is correct. Before rendering, compare the concept `script_text`, hook, storyboard, title, and family; if any part belongs to another scam scenario, override with a fresh topic-specific Director script and metadata rather than rendering the stale concept.
- When manually importing packages, stale folders in `storage/incoming` can all be re-scanned and reported as imported/skipped. Identify the matching log by package folder and use the returned `video_id` for dashboard links.
- Browser verification can succeed on Cloudflare Pages even if raw `urllib`/curl gets a 403; treat the browser check as the human-facing verification for the page.