Komplex Logopédia · parallel UI contracts · 2 October 2026
Finish the journey. Reuse the work.
Five bounded assignments turn the existing screens into one coherent, clickable customer journey that you can present to Rita. Clear ownership, natural copy, useful next actions and a single final canvas.
PLAN READY · EXECUTORS NOT LAUNCHEDFRONTEND ONLYEXISTING UI COPIED, NOT REBUILT
Make the existing work useful
The baseline already includes 20 ads, four landings, 14 participant days, 14 Rita screens and 116 email versions. These are inputs to improve, not a new batch to generate from scratch.
5separate ownership areas
1Rita-ready final canvas
0backend work required
What changes about execution
Ads, landings, signup/email flow and the daily app can improve in parallel. The canvas agent starts its shell alongside them and integrates ready modules.
The participant and Rita screens remain with one owner because they share code and state. Only the canvas owner publishes. The current child’s files remain untouched.
Two entry routes become the same daily practice experience. Each box below represents actual interfaces the executors must deliver, with matching copy and working next steps.
Days 1–14Guide → practice → reflection → video → Rita feedback → next day
→
Continue thoughtfullyFinal practice clip → online consultation → next steps
Rita’s 14 matching video-review screens form the second canvas row, directly below the participant days. The complete set of alternatives is available without overwhelming the recommended path.
Real start dates and capacity remain unconfirmed. The daily-feedback service, 24,900 Ft price and 12-person cohort remain proposals for Rita’s review. Good conversion is a testable hypothesis, not something screenshots can prove.
Copy a complete goal into each new agent
The copy buttons include both the agent’s contract and the shared product/route rules. Launch 01–04 in parallel when resources permit. Agent05 may build the canvas shell concurrently, then integrates their declared-ready results. With fewer slots, run the four writers first and05 after.
Improve the existing twenty Facebook ad previews so a new visitor understands the situation, the offer and what happens after clicking, with coherent square images and natural Hungarian copy.
Owns: ads/** · assets/ads/**
Keep 20 full Facebook-style previews and 20 real square images: 01–10 free-video, 11–20 challenge. Each preview includes image, on-image wording, matching primary text, headline, CTA and working offer destination. Supply a recommended pair per offer and concise reasoning for the remaining test angles, not a new persona workbook.
A fresh Luna copy critic reads image text → primary text → headline → CTA for all 20, then states the offer and expected click outcome. Reject unexplained hooks, arbitrary USP lists, vague emotional language or a change of promise halfway through.
A 390px Facebook preview shows a legible 1:1 image and readable Hungarian at actual display size. No Rita name appears on the creative or ad copy, and no fabricated engagement or endorsement is presented as real.
For every changed caption, obtain a bounded Luna critique before regenerating its raster. Reuse a good existing image when the wording still matches; repair any stale baked-in text rather than hiding the mismatch in the caption.
AD2 · The ad leads into the same offer on the landing
Click all 20 CTAs: free ads reach a free landing, paid ads reach a challenge landing. The first landing viewport repeats the same benefit, commitment and next action without requiring an explanation from Matt.
Retain meaningful distinct angles across the set. Do not call colour swaps or synonyms new hypotheses. Recommend two per offer and explain what reader uncertainty each tests in one sentence.
AD3 · The assets are easy to compare and hand off
Every ad has stable ID, destination and short keep/fix rationale in the module manifest. The canvas owner can embed previews and image URLs directly.
Review the revised batch at 360/390/430 with actual image inspection, legibility and no clipped copy. Final deployed screenshots are coordinated by Agent05; do not publish your own competing batch.
SCREENSHOT EVIDENCE PENDING · WHAT LUNA MUST SEE
Show the full Facebook-style card at 390px, with the whole image and enough matching copy to judge the narrative. Luna must identify what caught attention, what is being offered, why the click is relevant, and any caption/image/landing mismatch. Show 360/430 views for readability and wrapping; no desktop ad QA.
The executor links the actual captures in its assigned report. This placeholder does not count as proof.
Read the full /goal prompt
Goal 02
Four persuasive, coherent landing pages
Start in parallel
Refine the existing two free-video and two challenge landing variants into clear mobile pages that look like Komplex, fulfil the ads' promises and make the next step feel worthwhile and manageable.
Owns: landing/** · assets/landing/**
Keep `free-a.html`, `free-b.html`, `challenge-a.html`, `challenge-b.html` plus `cta-alternatives.html`. Retain seven relevant custom visuals. Provide three complete main-CTA section alternatives per offer, six total, with copy and working destination. A/B variants differ in the persuasive emphasis and sequence, not the service facts.
LP1 · Each page answers the visitor's buying questions in order
The first mobile viewport identifies who the offer is relevant to, the useful outcome and the next action in plain Hungarian. Free pages make free personal video feedback clear; paid pages make the 14-day guided-practice offer clear. A reader should not need Matt's explanation.
Reading down the actual rendered page answers: what will I do, what do I receive, why trust this, what effort is involved, what happens next, and what remains outside the programme. Each section has a job; remove repetitive filler while preserving relevant template coverage.
Use real identity and source-supported explanation as proof. Do not invent testimonials, results, recordings or urgency. Show daily feedback consistently with the current pilot proposal, while keeping unresolved commercial facts distinguishable from accepted commitments.
LP2 · The brand, variants and template work as one design
All four pages use the live Komplex visual identity, real logo/portrait and consistent typography, spacing, controls and image treatment. At 360/390/430 no clipping, tiny explanatory copy, broken media or conflicting sticky controls prevent reading or clicking.
Preserve purposeful coverage of the supplied 28 layouts across the family using the existing layout map, not 28 sections on every page. Log any changed interpretation. Preserve Gemini 3.1 Pro design provenance; small copy/CSS fixes do not require regenerating a whole page.
The A/B and six CTA-section alternatives are full rendered sections that can be compared at the same scale. State one plausible test hypothesis for each pair. Do not produce multiple incompatible prices, feedback cadences or guarantees as variants.
LP3 · A clear CTA leads to a clear next screen
Every principal free CTA opens `../flow/free-upload.html?variant=free-a` or `free-b`. Every principal paid CTA opens `../flow/checkout.html?variant=challenge-a` or `challenge-b`. No empty anchors, old deployment links or nonfunctional fake buttons remain.
At the paid decision point the visitor understands the proposed once-only price, the daily work/support and the final consultation. Free signup does not unexpectedly become a payment request. Each form/checkout destination fulfils the exact CTA wording.
An independent Luna reviewer reads all four actual pages and records the strongest remaining objection, any out-of-context sentence and each concrete usability defect. Fix material defects and inspect fresh captures, not just DOM counts.
SCREENSHOT EVIDENCE PENDING · WHAT LUNA MUST SEE
For all four pages, capture readable semantic sections, tall-section segments and overlapping 3–4-section runs at the three mobile widths. Luna must see the hero-to-offer narrative, rhythm, image relevance, objections, price context and CTA destination. Include each of the six complete CTA alternatives and meaningful expanded FAQ content. Never multiply every FAQ state by every unrelated CTA variant.
The executor links the actual captures in its assigned report. This placeholder does not count as proof.
Read the full /goal prompt
Goal 03
Signup, payment and emails that join the journey
Start in parallel
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.
Owns: flow/**
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.
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
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
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.
SCREENSHOT EVIDENCE PENDING · WHAT LUNA MUST SEE
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.
The executor links the actual captures in its assigned report. This placeholder does not count as proof.
Read the full /goal prompt
Goal 04
A daily practice app and a usable Rita feedback loop
Start in parallel
Turn the existing participant and Rita screens into a calm, understandable mobile practice experience: the learner knows what to do today, can submit a video, and sees relevant personal feedback before continuing.
Owns: app/** · assets/daily/**
Refine entry/login demonstration, course overview, days01–14, expert days01–14 and the final consultation interface. Keep two infographic and two AI-image choices per day, 56 total, with a calm recommended choice in the customer flow and the alternatives in review controls. Preserve all full lesson content and the current local video/state mechanisms where they already work.
APP1 · Every day is a usable lesson, not an archive page
All 14 day URLs show the right day/title, what to do first, relevant exercise instructions, what to record, reflection/sliders, submission state and next action. Rita's original exercise wording and source cautions remain complete and reachable; no duplicate contradictory simplified instruction is substituted.
An independent reviewer can perform the day from the screen alone without guessing the exercise order or what video to send. Use progressive disclosure for long originals and optional visuals while keeping today's instructions visible. Verify all six originals against their stored hashes and map each of the 14 days to the intended source.
Days2/5/8/12 begin with the prior relevant video/feedback when available; missing submission, waiting feedback, received feedback and missed-day/return states remain understandable. Day1's spontaneous clip and day14's agreed 2–3-minute practice clip are not confused.
APP2 · The participant-to-Rita-to-participant loop works locally
For every one of 14 day IDs: change a slider and reflection → save → choose/preview a valid video → submit → open the matching Rita screen → read that day's task and participant input → draft/preview/send a written response → read that same response in the participant screen. Required state persists through refresh within this browser demo.
Rita sees participant identity, day, submission status, the playable correct clip, task context and previous useful feedback without navigating a maze. Empty/missing/invalid video and unsent drafts never masquerade as reviewed work. The participant sees waiting versus received feedback distinctly.
Check both existing sample participants to catch state mixing. Changing day or participant must never show another person's clip, reflection or feedback. Keep technical fixtures marked as samples, not Rita teaching videos or genuine personal assessments.
APP3 · Completion and consultation feel like a natural continuation
The overview makes current, completed and upcoming work easy to recognise without locking a reviewer out. On mobile at360/390/430, video controls, sliders, long Hungarian instructions, keyboard/form state and primary buttons remain readable and usable.
After day14 the learner can review what they practised, provide the final clip, choose a clearly sample consultation time, see confirmation/preparation, reschedule/cancel, and inspect a post-consultation next-step view. No fabricated real availability, real Meet link or claim that all development is complete.
All 56 existing visuals remain reachable by day with two infographic/two image alternatives. Their content matches the actual exercise and does not introduce an unsafe or contradictory instruction. Luna inspects actual daily content and interface states; broken or misleading visuals are repaired selectively.
SCREENSHOT EVIDENCE PENDING · WHAT LUNA MUST SEE
For every day capture the opening/task section, usable exercise content, reflection/video state and the matching Rita screen. Luna must confirm the learner knows the next action and Rita has the correct context. Also capture saved→submitted→waiting→received feedback with identical day/participant identifiers, the four rewatch checkpoints, both participant identities, final clip and consultation states. Mobile only. The reviewer must read the actual lesson text, not just check a heading or green status.
The executor links the actual captures in its assigned report. This placeholder does not count as proof.
Read the full /goal prompt
Goal 05
One Rita-ready canvas and final integration
Start the canvas now; integrate ready modules later
Assemble the improved modules into one polished, public, outer-commentable left-to-right journey canvas that Matt can review quickly and then present to Rita without explaining missing links.
Owns: root canvas files · review/** · sole publisher
Deliver the final canvas at the intended stable URL, every actual interface in journey order, a compact recommended path and accessible A/B alternatives, meaningful customer-facing flow labels, asset-level reviewer rationale and an unsent Hungarian Rita email draft linking the real sections. Reuse existing persona/analysis and tighten it. No new evidence-dashboard project.
CAN1 · The canvas is the entire customer journey at a glance
Show two understandable entry branches: free-video ad→free landing→upload/receipt/feedback→useful email→challenge, and direct ad→challenge. They converge at checkout→confirmation/access→overview→all14 days→final clip→consultation. Show relevant service/marketing email interfaces beside the transition they support, not one disconnected email bucket.
Place all14 Rita screens on a second row directly below their matching participant days, with stable day IDs and clear submission/feedback links. All20 ads,4 landings,6 CTA alternatives,58 email topics/116 versions,7 landing visuals and56 daily alternatives are reachable without cluttering the recommended route.
Preserve the actual CC Klíma pan, anchored zoom, fit, stage jump and expanded-view behaviour. A full mobile screen is readable in the inspector and closing it restores the previous canvas position. The index lists all deliverable interfaces, not private evidence files.
CAN2 · The review helps Rita evaluate a coherent proposal
The opening orientation says what the participant gets, the two entry paths, the daily-feedback pilot and which commercial/service facts remain proposals. Use a clean presentation mode with actual screens and a review mode for comparisons/analysis. Do not flood customer screens with status tables, developer controls or backend explanations.
For every asset/stage, use existing analysis as a short outside-the-screen card: before-view mindset, attention, interpretation order, likely objection, intended next action and reason to try it. Identify weak existing copy and explain the concrete correction. Apply the value-equation reasoning naturally, without invented numeric scores. Keep A/B alternatives side by side at equal scale and state a hypothesis, not a winner.
Only the outer canvas owns the comment layer, using stable asset targets. Users can comment on the ad, landing/section, day or Rita screen from the outer surface and return to the same asset. Embedded pages do not each inject a second toolbar. Publish through the canonical shared host skill and preserve unrelated host routes.
CAN3 · The assembled prototype is ready to present
Run both complete entry paths from ad to consultation, including checkout cancel/retry, optional consent, previous-day return and one complete participant/Rita loop. Verify all14 day-pair links/source mappings and every visible CTA, plus refresh and back navigation. No old-host detours, broken media or unintended actual transactions/sends remain.
Coordinate independent Luna section QA and fresh deployed screenshots for all unique pages, mobile360/390/430 for customer UI and desktop only for the outer canvas. Resolve real flow/copy/visual defects with their exclusive owner. Keep one concise result table; no claim of verified based merely on generated captures or an existing report.
Publish one public assembled canvas at the intended URL and verify anonymous readback, index/reachability, functional review controls and comment persistence on a disposable test document. Provide a short unsent Rita email: what each real URL/section shows, what feedback is wanted, and what still awaits agreement. Explicitly label this frontend proposal, not a live campaign/system or client approval.
SCREENSHOT EVIDENCE PENDING · WHAT LUNA MUST SEE
Capture the entire two-branch canvas at overview scale, a readable expanded landing, an A/B comparison, all14 aligned participant/Rita pairs, a full free-to-paid path and a paid-to-consultation path. The independent reviewer must see how every screen connects and whether a real visitor would understand the next action. The postdeployment captures must be from the actual final URL/build; do not relabel local evidence as live.
The executor links the actual captures in its assigned report. This placeholder does not count as proof.
Read the full /goal prompt
What makes the final canvas ready
Question
Required proof
Who owns it
Does the visitor understand the offer?
Independent reading of image → copy → hero → CTA. No unexplained promise changes.
Ads + landings
Does the next action actually work?
Both entry paths followed through checkout, access, daily practice, feedback and consultation.
Flow + course + integrator
Can someone complete today’s lesson?
All14 source-based task screens and matching Rita screens, correct videos/feedback, readable mobile controls.
Course
Can Matt show it without narrating missing pieces?
One clean canvas, recommended path, equal-scale alternatives, all interfaces reachable, outer comments.
Canvas
Has it really been checked?
Actual rendered observations and fresh deployed Luna screenshots. No fabricated passes or screenshot-count theatre.
Each owner, then integrator
Keep the scope narrow: no backend, no campaign launch, no evidence-viewer rebuild, no automatic regeneration of 83 satisfactory images. A criterion can be improved with a recorded rational reason, but never weakened just to declare completion.
The release and Rita handoff
The final canvas owner freezes the ready modules, publishes one assembled surface, checks both journeys on that deployed build and writes the unsent Hungarian email explaining what Rita should review. The new intended canvas route is shown in the contracts. It is not published by this planning task.
Choose the recommended path first. Open alternatives only where there is a real copy or layout decision. Show technical checks in the agent reports, not in Rita’s customer walkthrough.
Shared rules, exact paths and integration agreement