# Mobile approval cockpit for creator dashboards

Use this when a creator dashboard must support on-the-go approval from iPhone/mobile for prepared videos, uploads, and website companion decisions.

## Trigger

The user needs to approve Shorts/Reels/TikTok/YouTube production while away from desktop. The full desktop review page may exist, but the mobile path needs a dedicated decision cockpit.

## Product shape

Add a mobile-first route rather than only relying on responsive desktop cards:

```text
/mobile-review
/videos/:id/mobile-review
```

Recommended behaviour:

- `/mobile-review` auto-selects the first active review item (`ready_for_review`, `in_review`, `needs_metadata`) and redirects to `/videos/<id>/mobile-review`.
- Keep normal desktop review route intact.
- Add a nav entry such as `Mobile Review / iPhone Freigabe`.
- Add a direct `iPhone Review` button from the dashboard focus card when a review video is active.

## UI requirements

- Mobile max width around one phone column (`max-w-md`).
- 9:16 video-first layout at top; use `playsinline`, controls, poster, and `/api/videos/:id/media`.
- Sticky top header with title/status and short feedback message.
- Sticky bottom decision bar with large touch targets:
  - Reject / Ablehnen
  - Request changes / Ändern
  - Approve review / Review OK
- Use bottom-sheet modal for reject/change reason entry.
- Buttons should be at least ~48px high (`min-h-12`) and full-width where possible.
- Add iOS safe-area padding to the sticky bottom bar: `padding-bottom: max(0.75rem, env(safe-area-inset-bottom));`.
- Collapse non-essential text/script/details behind `<details>` sections.

## Approval workflow for AutoShorts-style dashboards

The mobile cockpit should expose only the decisions needed on the road:

1. Watch the video.
2. See Quality Gate overall status.
3. If gate failed, block approval/upload and offer changes/reject.
4. Edit or confirm YouTube title/description/tags.
5. Require explicit checkboxes before private upload:
   - Synthetic media checked.
   - Title/description reviewed.
   - Disclosure reviewed.
   - Upload remains private.
6. Create the hash-bound/private UploadRequest via the existing uploader path; do not directly public-upload.
7. TikTok remains manual: MP4 download, caption/hashtags, mark exported.
8. Website companion remains separate and should not leak private YouTube links publicly.

## Implementation pattern

Reuse existing API clients rather than adding new backend primitives where possible:

- `api.videos()` to choose the next active item.
- `api.video(id)` for details/drafts/quality report.
- `api.patchDraft(...)` and `api.patchVideo(...)` for metadata/status.
- `api.saveAndApprovePrivateUpload(...)` for existing Jarvis uploader UploadRequest.
- `api.uploadSnapshot(...)` for hash/snapshot visibility.
- `api.rejectVideo(...)` / `api.requestVideoChanges(...)` for decision bottom sheet.

## Verification

Before reporting mobile readiness:

- `npm run build` / typecheck passes.
- Backend tests still pass.
- Browser-smoke `/mobile-review` locally.
- Confirm no console errors.
- Confirm the page renders a video, Quality Gate, YouTube checkboxes, disabled/enabled private-upload button, and bottom decision bar.
- If exposing over Tailnet, start frontend bound to `0.0.0.0` with `/api` proxied to local backend; report the direct Tailnet IP/port or Tailscale Serve URL truthfully.

## Pitfalls

- Do not bury approval buttons below a long desktop-form stack; mobile users need sticky actions.
- Do not enable private upload until all explicit confirmation checkboxes are checked.
- Do not show private YouTube URLs as public website links; website payload should keep `videoUrl: null` until public-link policy allows it.
- Do not rely on browser `localhost` from the user’s phone; proxy `/api` through the frontend host or use Tailscale Serve.
- Do not claim Tailscale Serve is configured when `tailscale serve` was denied; use direct Tailnet IP fallback and mention the operator fix separately.