/goal Make the free-video and paid-enrollment frontend flows feel obvious and reassuring, with consistent email previews that always lead to the correct next screen.

# Contract 03-flow, revision 1: Signup, payment and emails that join the journey

## Goal
Make the free-video and paid-enrollment frontend flows feel obvious and reassuring, with consistent email previews that always lead to the correct next screen.

## Scope and authority
Read `/Users/agency/Documents/Agty/KomplexLogopédia/plans/rita-ui-parallel-20261002/SHARED.md` first. Its product facts, ownership, routes, verification rules and completion boundaries are part of this goal. This is authorised frontend improvement when Matt launches this contract, not permission to launch the other contracts.

Work only under `/Users/agency/Documents/Agty/KomplexLogopédia/outputs/rita-ui-parallel-20261002/site`. Your exclusive UI ownership: **flow/****. You also own `/Users/agency/Documents/Agty/KomplexLogopédia/outputs/rita-ui-parallel-20261002/handoffs/03-flow/`, `/Users/agency/Documents/Agty/KomplexLogopédia/outputs/rita-ui-parallel-20261002/evidence/03-flow/`, and `/Users/agency/Documents/Agty/KomplexLogopédia/outputs/rita-ui-parallel-20261002/reports/03-flow.md`. Other agents share the workspace; preserve their edits. The old executor and the immutable baseline are read-only.

## Authoritative inputs and fixed decisions
Start from all existing `flow/` pages, `flow.js`, `flow.css` and `emails.json` (58 topics, 116 A/B versions). Read the shared route agreement and existing `app/lessons.json`. Preserve topic IDs and the state schema. Use the new flow storage namespace fixed in SHARED.md, leaving the old demo untouched.

The full existing site is already copied to the new work root. Do not rebuild from zero. The original snapshot and its hashes are at `/Users/agency/Documents/Agty/KomplexLogopédia/plans/rita-ui-parallel-20261002/baseline-manifest.json`. Follow the shared source hierarchy, brand, daily-feedback model and frontend-only boundary.

## Required deliverables
Refine the free upload/consent/receipt/feedback states, Stripe-like checkout branches, confirmation/access states and email-preview interface. Keep all 58 topics and both versions, but make the recommended customer sequence immediately understandable. Daily service messages must correspond to all fourteen lesson IDs. Consultation messages lead to the course owner's consultation UI.

The acceptance owner is the canvas integrator for module handoff and Matt for the eventual client presentation. Final planned canvas URL: https://review.clientsflow.hu/komplex-rita-ui-canvas-2026-10-02-v1/ . This is a destination to create, not a claim that it is already published.

## End-state checklist
### FL1. The free route has no confusing leap

Criteria:
- A cold visitor knows what to record, what happens to the selected clip in this demo and what response is proposed. Choose a local video → see a playable preview → submit deliberately → see receipt/waiting → open explicitly labelled sample feedback. Invalid/no video never yields a false success.
- Marketing consent is optional and separated from service communication. Refusing it still allows the free demo flow. Sample feedback is clearly illustrative and does not pretend Rita watched an unseen video.
- Feedback and useful follow-up make the paid next step relevant. Read the first nurture letters in full: they give useful context before the invitation, do not repeatedly sell with filler, and their CTA opens the appropriate challenge page.

### FL2. Checkout and access give the buyer confidence

Criteria:
- From both paid variants, the checkout summary, once-only price, programme scope and daily support agree with the landing. Demonstrate success, cancellation, pending, error and sold-out/waitlist states, each with an understandable next action. A failed/pending state must not display paid confirmation.
- Simulated success leads to confirmation and a working course-entry link. Back/cancel/retry keeps the originating variant and does not erase unrelated progress. Refreshing a local demo does not invent a second purchase or a real enrollment.
- The surface visibly remains a prototype without turning the customer copy into an engineering report. Do not request real card details, create a Stripe session or imply an actual charge. Use a plausible Stripe handoff and clear demonstration controls.

### FL3. Emails remain useful interfaces, not a copy dump

Criteria:
- Every email topic/version has a readable mobile inbox-style preview with subject, preheader, complete body and working CTA. The viewer shows recipient/trigger/timing in a separate review strip. No technical notes are embedded as if they were normal customer email copy.
- The 14 guide, reminder and feedback pairs name the correct day, task and destination. Feedback-available messages point to received feedback, not an empty generic homepage. Do not substitute module duration for an approved daily-time promise.
- The canvas can present only relevant letters at each stage while all 116 versions remain reachable for comparison. Consent and paid-recipient exclusions, weekly-versus-campaign rule and consultation states are represented coherently in demo scenarios. No actual send or mailing backend exists.

## Verification and evidence
Capture the free upload/preview/receipt/feedback transition, every distinct checkout outcome and confirmation/access at mobile widths. Luna must see the action, response and next step agree. Capture every unique email body at readable scale with its subject and CTA; reuse shared shell checks, without multiplying 116 bodies by unrelated checkout states. Show one complete nurture chain and day/feedback/consultation sequences in journey order.

Keep screenshots and findings in your assigned evidence directory. Link actual observations to the criterion IDs above. A screenshot placeholder is a pending check, never proof. Put useful UI first and evidence behind its concise handoff. Before declaring a route ready, use it in the rendered browser and read its entire unique copy. Use the required independent Luna process from SHARED.md, with bounded partitions and actual image inspection. Headless checks are allowed; do not open Matt's panels or leave task-owned tabs open.

## Constraints and rational changes
Do not build payments, email automation, authentication or a second booking interface. Do not edit app storage, lesson text or landing files.

If a verification criterion is objectively wrong, duplicated or tests the wrong outcome, record its original text, replacement, rationale and evidence in your report. Preserve the user's requested outcome and explicit constraints. An unfinished hard requirement cannot be converted into an optional one to claim DONE.

## Completion and blocked state
Write `/Users/agency/Documents/Agty/KomplexLogopédia/outputs/rita-ui-parallel-20261002/handoffs/03-flow/manifest.json` using the small shared schema and your concise report at `/Users/agency/Documents/Agty/KomplexLogopédia/outputs/rita-ui-parallel-20261002/reports/03-flow.md`, based on `/Users/agency/.agents/skills/launch-agent/report-template.md`. A manifest marked ready means this owned UI works and its local checks pass. The publisher performs the final deployed acceptance.

If no viable in-scope recovery remains, finish independent UI work and record the exact affected dependency, actual evidence and resume point. Do not manufacture blockers from optional polish. Return once in your final channel: DONE or STALLED, report path and the usable entry route. Native children use their normal completion channel back to parent `01a0c622-0f03-7480-9f24-003a441af4b3`. Separate visible tasks report through their own final response; do not send a second message to another task. No per-child wrap-up/audio.