# Approval-first content pipeline pattern

Use this when building a quality-first Shorts/Retention Studio system before real rendering or publishing.

## Shape

Build the pipeline as boring typed artifacts, with tests at every boundary:

```text
ContentBrief
→ ScriptDraft
→ CandidateDraft
→ VideoCandidate
→ TestBatch
→ ReviewBatch
→ Telegram delivery preview
```

## Artifact responsibilities

- `ContentBrief`: pillar, topic, audience problem, payoff, positioning, tone, visual rules, no-go topics, platforms, target duration.
- `ScriptDraft`: exact hook, script outline, 3–5 retention beats, visual concept, caption, CTA, estimated duration.
- `CandidateDraft`: existing candidate-factory input, preserving hook/script/visual/caption/CTA plus initial conservative quality score and policy notes.
- `VideoCandidate`: validated candidate from the existing factory, with stable id, default hashtags, duration class, and pillar/platform checks.
- `ReviewBatch`: ready/blocked/invalid split before any render or publish action.
- `Telegram delivery preview`: metadata + review text only; no real sending.

## Guardrails

- Keep real Telegram sending, rendering, and publishing behind later explicit adapters.
- Reject blank strategy/script fields before candidate conversion.
- Reject generic AI-slop phrases before rendering (e.g. `in this video`, `unlock your full potential`, `game changer`).
- Preserve user/human approval in policy notes and review output.
- In helper factories, do not use `override or default` for strings/numbers; use `override if override is not None else default` so tests can exercise invalid blanks and zeroes.
- Start with a conservative initial quality score; let later review/scoring improve it rather than pretending early drafts are perfect.

## TDD sequence

1. Write tests for `ContentBrief` creation/validation.
2. Write tests for `ScriptDraft` creation/validation and AI-slop rejection.
3. Write tests for `ScriptDraft` → `CandidateDraft` conversion.
4. Write tests for `CandidateDraft` → `VideoCandidate` via the existing factory.
5. Verify the candidate reaches `ready_for_review` through the review workflow.
6. Only then build demo CLIs or delivery previews.

This pattern prevents GPU/render time from being spent on weak prompts and keeps the system approval-first rather than accidentally becoming a content catapult.