# AI INSTRUCTIONS — THIS YOU ISSUE AUTHORING ## What you are building You are creating one issue of **THIS YOU**, a real fashion/culture magazine with a personalized fashion layer. Core positioning: > **Same issue. Same city. Same moment. Different you.** The shared magazine creates the same world, event and moment for every reader. When the reader enters selected moments, their arrival, styling, products and commentary change according to their own taste, body, sizes, budget and preferences. This is **not** a face-swap product, joke generator or generic AI-avatar magazine. Use this language when describing the product: > **Human-edited. AI-assisted. Individually reviewed.** Print is an artifact. Digital is an interactive companion. --- # 1. DO NOT MODIFY THE ENGINE Everything for this issue belongs inside the issue package folder: ```text /issues/{issue-slug}/ ``` Do not copy issue assets, layouts or theme files into global engine folders. Do not modify: ```text /lib/ /admin/ /layouts/ /themes/ /assets/ ``` unless the user explicitly asks for an engine feature. The issue package is portable and should remain independently copyable. --- # 2. SOURCE OF TRUTH The issue folder is the **shared issue master**. It contains: ```text manifest.json issue.json chapters.json pages.json theme.css /layouts/ /assets/ /docs/ ``` Reader-specific generation is a later layer and must not alter the shared package. --- # 3. LOCKED EDITORIAL GRAMMAR The normal issue structure is: > **ONE CITY / ONE SEASON / SIX MOMENTS** At least: - 1 ACTIVE moment - 1 DRESS-UP moment Each chapter uses the protected four-page grammar: > **STORY → SCENE → MOMENT → STYLE** Meaning: ### STORY What happens. Real context, event, culture, place, people and editorial reporting. ### SCENE How the moment feels. Objects, fragments, traces, atmosphere, time, movement, fatigue, sound and small human details. SCENE is **not** a product-selection page. ### MOMENT The reader enters. This is where the personalized reader becomes present in the shared world. ### STYLE What the reader wears and why. Products, brands, prices, fit, proportions, links and personalized editorial explanation. Do not blur these four functions. --- # 4. SCENE RULES SCENE must be built as **live HTML/CSS + separate assets**. Do not flatten the complete SCENE page into one generated image. Default structure: > **6–8 TOTAL editorial modules** > > usually **3–4 visual modules + 3–4 text/graphic modules** Text and negative space normally dominate. Typical balance: > **30–45% visual / 55–70% typography + negative space** Visual modules can be: - transparent PNG cutout - photograph fragment - map/route graphic - document fragment - abstract generative element Never add an image only to fill a grid. Avoid branded product selections inside SCENE. Save product specificity for STYLE. --- # 5. STORY IMAGE POLICY Every STORY needs a meaningful visual anchor. Preferred hierarchy: 1. **licensed / official press asset** with confirmed editorial-use conditions 2. **own / commissioned / original image** 3. **generated editorial illustration** 4. appropriate free-license image where editorially suitable Do not use generated imagery to fake documentary evidence of a real event. For every external image archive: - source URL - creator / photographer - exact credit wording - rights / license note - original master - screenshot or source record when useful If exact credit is uncertain, do not invent it. Flag it for review. --- # 6. WHEN TO USE AI-GENERATED IMAGES Good uses: - modular SCENE objects - abstract editorial illustration - atmospheric elements - non-documentary conceptual graphics - personalized reader arrival images - personalized sponsor creative Bad uses: - pretending to be a real press photograph - fake documentary evidence - invented event branding - fake tickets, schedules or logos that could be mistaken for factual material - generated text inside images when the text can stay live HTML/CSS Validate generated-object logic: - physical plausibility - season/date/event relevance - no wrong chapter elements - no accidental logos - no fake factual text - no anachronisms --- # 7. QR RULE > **A link alone does not justify a QR. A meaningful digital continuation does.** Digital pages can contain clickable links without a print QR. Use a print QR only where the reader gains something that print cannot provide, such as: - interactive issue entry - product continuation / personalized STYLE - motion / generative work - personalized sponsor continuation Do not automatically add a QR to every event mention or source. --- # 8. SPONSOR RULE Sponsored content must remain clearly editorially controlled. A sponsor slot can be personalized, but sponsorship must not silently rewrite the shared editorial world. Keep the sponsor page structurally separate from STORY / SCENE. --- # 9. PROCESS — AI MUST LEAD, USER APPROVES The AI leads the production process and stops at major approval gates. Do **not** jump from concept directly to final generation. Use this exact high-level workflow: ### STEP 1 — LOCK EDITORIAL PLAN Define: - city - season - issue concept - six moments - chapter order - active / dress-up balance - 32-page skeleton Stop and ask for approval. ### STEP 2 — WRITE SHARED COPY Write the shared editorial layer. Stop and ask for approval. ### STEP 3 — FULL EDITORIAL READ-THROUGH Polish: - tone - repetition - rhythm - factual precision - page-to-page transitions - headlines / captions / microcopy Stop and ask for approval. ### STEP 4 — BUILD ISSUE PACKAGE DATA Fill: - issue.json - chapters.json - pages.json - manifest.json - QR metadata - layout registry Validate the package. Stop and ask for approval. ### STEP 5 — SHARED VISUALS Select/create: - STORY visuals - SCENE modular assets - shared maps / graphics - credits / rights records Build SCENE pages as live layouts. Perform a visual audit. Stop and ask for approval. ### STEP 6 — FULL SHARED ISSUE ASSEMBLY / QA Render the complete shared issue. Check: - sequence - rhythm - clipping - overlaps - responsive behavior - image credits - print-safe layout Personalized pages can remain designed placeholders. Stop and ask for approval. ### STEP 7 — ONE MASTER READER Only now create one complete personalized edition: - cover - six MOMENT arrivals - six STYLE pages - personal summary - personalized sponsor - full issue QA Stop and ask for approval. ### STEP 8 — AUTOMATE / SCALE Only after one master reader works: - automate generation - generate additional readers - optimize cost / speed - batch production --- # 10. INTERACTION STYLE The user prefers a guided production workflow. At each major step: 1. explain what is being decided / created 2. do the work 3. show the result 4. state what remains unresolved 5. stop and wait for **APPROVE / LOCK / GO** Do not continue several major steps without approval. If the user says **go**, continue to the next already-agreed step. Do not ask questions that can be resolved from the issue brief or files. --- # 11. FACT CHECKING For real events, schedules, people, venues, prices, rights or current information: - verify externally when the user expects current factual accuracy - prefer official / primary sources for event facts and press assets - preserve source records inside the issue docs Do not convert uncertain information into confident magazine copy. --- # 12. DESIGN PRINCIPLE The issue should feel like a magazine, not a generated website. Prefer: - editorial hierarchy - negative space - asymmetric rhythm - intentional page pacing - real typography - live text - modular objects - strong contrast between page types Avoid: - repeated card UI - generic dashboard styling - overly regular web grids - “AI collage” look - every page using the same composition --- # 13. BEFORE DECLARING THE ISSUE READY Confirm: - package validates - 32 pages exist and are continuous - all issue-local layouts resolve - every required image asset exists - STORY credits are recorded - SCENE is live HTML/CSS, not flattened - QR use is selective - personalized slots are not accidentally baked into shared copy - print and digital versions do not contain accidental text/image overlaps Then present the shared issue for approval. ## V3 additions — SCENE variants + Style Exploration - SCENE remains one shared page/layout. When an object needs a presentation-specific version, use `data_json.objects[].variants.default/male/female`; do not create duplicate male/female SCENE pages. - Existing legacy SCENE data is still valid. For new variant-aware scenes, use the V3 object schema documented in `docs/04_SCENE_DESIGN_SYSTEM.md`. - Reader styling has `familiar / elevated / surprise` exploration modes. Brands are high-priority references in familiar (never a whitelist), taste/budget signals in elevated, and reference signals in surprise. Product-first selection still happens before final hero generation. - STYLE pages may include `recommended_style_mode`; an explicit `style_exploration_override` should be exceptional.