# THIS YOU — V2 Production Architecture

## Purpose

V2 separates two different domains that were previously mixed in one admin experience:

1. **MAGAZINE** — shared editorial creation, once per issue.
2. **PRODUCTION** — one personalized magazine for one reader × one issue.

The detailed product / Visual Lock / fidelity tooling remains available under **Edit / Debug** only.

## Normal operator flow

```text
PRODUCTION
→ open MagazineInstance
→ PREPARE GPT INPUT for a missing chapter
→ upload one input ZIP to THIS YOU Production GPT
→ GPT runs the complete chapter without intermediate approval stops
→ GPT returns one production-result.zip + final HERO
→ put ZIP into /teleport/
→ return to the MagazineInstance screen
→ GO — TELEPORT
→ chapter result appears in the magazine
→ repeat missing chapters
→ ACTIVATE MAGAZINE
→ GENERATE PRINT PDF
→ MARK SENT TO PRINT
→ NEXT
```

The normal UI deliberately does not expose A/B/C1/C2, Visual Lock states, fidelity status, fingerprints or per-step approvals.

## MagazineInstance

V2 adds the explicit `magazine_instances` production object.

A MagazineInstance is one personalized magazine for one reader and one issue. It is linked one-to-one to the existing `user_issues` record so the existing renderer/public edition continues to work.

Sources supported by the data model:

- `manual`
- `order`
- `subscription`
- `gift`

Orders and subscriptions are provenance/creation mechanisms only. They do not create separate production workflows.

## ChapterGeneration

Every Teleport result creates a versioned `chapter_generations` row.

Important behavior:

- previous generation records are kept;
- one generation is active per chapter;
- a replacement Teleport package can select different products without forcing the operator through the old detailed UI;
- the active database snapshot moves to the newest generation;
- the original processed package path is retained for traceability / rollback tooling.

## GPT input

`PREPARE GPT INPUT` downloads one ZIP containing:

- `chapter-product-input.json`
- all usable reader reference images
- a tiny `READ_ME_FIRST.txt`

The top-level JSON schema is:

```text
this_you.chapter_production_input.v1
```

It wraps the existing PRODUCT-FIRST input rather than duplicating the source-of-truth chapter/reader/Scene-DNA logic.

The GPT instruction is explicit:

```text
INPUT → PRODUCTS → VISUAL LOCK → HERO → FIDELITY
→ max one targeted correction → FINAL ZIP
```

No intermediate operator approval is requested.

## HERO guardrails included in the production input

- preserve reader body morphology from the reference images;
- clothing size / oversized preference describes clothes, not body width;
- full body when shoes are selected;
- both shoes fully inside the frame;
- no embedded text, credits, titles, page numbers, labels or watermark;
- real file/attachment delivery, not a textual filename;
- product fidelity + Scene DNA fidelity preflight;
- maximum one focused correction, then fail clearly rather than loop.

## Teleport

The V1.8 Teleport importer remains the handoff bridge, but V2 connects it to MagazineInstance / ChapterGeneration.

On a successful import:

1. product / Visual Lock / personalized / fidelity artifacts are ingested using the existing detailed services;
2. the final HERO becomes the active chapter image;
3. a new ChapterGeneration version is recorded;
4. MagazineInstance chapter progress updates automatically.

The Production screen detects matching packages in `/teleport/` and shows one **GO — TELEPORT** button. The operator does not need to open the Teleport debug screen.

## Whole-magazine approval

V2 moves human editorial approval to the finished result.

`ACTIVATE MAGAZINE` is the one normal human approval action. It:

- requires all shared issue chapters to have a personalized result;
- records a `magazine_revisions` snapshot;
- selects the active chapter generations;
- approves existing generated personalized pages at magazine level;
- sets the production revision active.

Detailed internal review remains available in Edit / Debug for exceptions.

## PDF

PDF generation remains a separate renderer step.

It never invokes GPT or live retailer sourcing.

After PDF export V2 stores the exact interior/cover paths against the MagazineInstance.

## Admin domains

### PRODUCTION

Reader × issue production queue and the default daily operator workflow.

### MAGAZINE

Issue/editorial authoring only: shared chapters, stories, SCENEs, Scene DNA, layouts and issue packages.

### ORDERS

Reserved for commerce ingestion. V2 data model already supports `source_type=order` and `source_order_id`.

### SUBSCRIBERS

Reserved for Phase 2 eligibility/cutoff snapshots. V2 data model already supports `source_type=subscription` and `source_subscription_id`.

### EDIT / DEBUG

Old detailed production controls:

- readers/profile diagnostics;
- products and price tools;
- Product Visual Lock;
- Dynamic Feature Map;
- HERO fidelity;
- raw Teleport diagnostics;
- retailer request log;
- issue package tools.

## Deferred intentionally

This release does **not** yet implement:

- Stripe order ingestion;
- subscription eligibility/cutoff snapshots;
- print-provider API submission;
- OpenAI API production runner;
- automatic retailer sourcing/catalog architecture.

Those are separate adapters/phases. The V2 production domain is designed so they create or execute MagazineInstances rather than changing the production model.