# Proof Short Real-Problem Reset

Use this when an early short/pilot looks increasingly polished but still fails because viewers cannot see a real problem in the first second.

## Trigger

Switch to this mode when the user says a pilot is:

- pretty but semantically empty
- too abstract or generic
- missing a visible fail / real viewer pain
- overproduced before the format is validated
- relying on AI images, Wan/I2V, glassmorphism, or B-roll as the story carrier

## Archive the old candidate first

Mark the old candidate as a paused learning case, not a render target.

Recommended archive fields:

```json
{
  "status": "paused_learning_case",
  "reason": "Pretty but semantically weak. Too abstract for first pilot. Visuals do not create immediate viewer pain or retention.",
  "do_not_continue": {
    "further_optimization": false,
    "rendering": false,
    "posting": false,
    "wan": false,
    "i2v": false,
    "platform_api": false
  }
}
```

Postmortem structure:

- Worked: approval gates, clean captions, delivery discipline, workflow/styleframe learning, technical I2V sanity where applicable.
- Failed: topic too abstract, no visible fail, too much production before validation, too many visual metaphors, AI video/image generation used too early as story carrier.
- New rule: `Pretty Empty Visual Blocker`.

## Pretty Empty Visual Blocker

Block a candidate or visual plan if:

- the image is high-quality but does not show a clear problem without voiceover
- no visible fail exists
- the visual is only mood/B-roll
- the viewer cannot tell within 1 second what is at stake
- usefulness only emerges through abstract explanation
- the scene is interchangeable with dozens of other AI/productivity videos

A visual plan must answer:

1. What is concretely broken?
2. Where can the viewer see the error?
3. What is at stake for the viewer?
4. Which simple rule repairs it?
5. Why would someone save or share this?

## ProofShortMode defaults

Proof Shorts are the default for the first 10–20 unvalidated videos.

- 25–35 seconds
- screen/mockup-led or real-problem-led
- no Wan final
- no I2V/T2V full render
- no premium styleframe pass
- no abstract metaphors
- no AI B-roll as main visual
- fast useful preview to validate topic/format
- manual approval before any posting pack

Premium episodes come only after the theme/format is proven by viewer response.

## Good first Proof Short shape

For digital safety/workflow/AI-mechanism content:

```text
visible fail → recognition → mechanism → simple check/rule → safe next action → memorable takeaway
```

Example topic class: fake invoice/payment-route red flag.

- Use controlled fictional mockups.
- Show invoice/email/payment route in the first frame.
- Avoid real brands, addresses, IBANs, QR codes, logos, and real people.
- Use renderer-owned UI text/highlights; do not use real scam templates.
- Keep claims as general safety advice, not legal/financial advice.

## Caption style

Keep the user's corrected style:

- static phrase segments
- active-word highlight
- white inactive words
- yellow active word
- no frame/box/full-width bar/dark subtitle block
- subtle shadow or outline only
- mobile-safe bottom position

## ReviewPackageV2 additions

For Proof Shorts include:

- `ProofShortMode = true`
- selected hook plus hook variants
- script
- visual plan
- Pretty Empty Visual Blocker result
- claim gate
- AI disclosure
- save/share/follow reasons
- platform fit
- preview MP4 path, SHA256, duration, resolution
- Telegram delivery status

## Hard blocks until approval

Do not run:

- Wan/I2V/T2V full render
- full-final render
- platform API
- auto-posting
- scheduling
- render series

Allowed next commands should be explicit, e.g.:

```text
APPROVED_PROOF_SHORT <candidate_id>
REVISE_PROOF_SHORT <candidate_id> <field> "Änderungswunsch"
REJECT_PROOF_SHORT <candidate_id> "Grund"
APPROVED_FOR_MANUAL_POSTING_PACK <candidate_id>
```