# /goal Lovasember: rebuild the complete client review Status: LAUNCH AUTHORIZED · latest board comments reconciled · Sol xhigh executor dispatch pending. ## End goal Create a coherent, persuasive, visually consistent Lovasember website and campaign review that lets Matt and then Sanyi/Dóri evaluate both complete audience journeys and choose the best variants. ## End state A stable public commentable review contains two complete variants each of home, About, self-knowledge and individual-leader pages, all in the existing site's visual language. The two landing families include 16 image creatives each and 3 copy variants per creative plus targeting, displayed below the footer as mobile Facebook-feed previews. Multiple functional frontend form/booking choices show the whole funnel. Original production is unchanged. Sources, screenshots, editable outputs, client email draft and next steps support continued work after feedback. ## Accepted decisions and provenance Matt's latest Q1-Q10 answers govern. Q1 A full build with Gemini 3.1 Pro API first drafts and a four-exact-section monolithic HTML/CSS brandbook plus supplied template. Q2 A problem-aware/coaching-sceptical. Q3 E evidence-led women hook ranking, with recurring patterns and self-neglect strong candidates. Q4 E evidence-led leader hooks, with dependence/control and work-private-life spillover strong candidates. Q5 A human situation first, horse-assisted method as grounded experiential differentiation. Q6 A/B testable paid-continuation sections. Q7 E light/strong qualification, C time and budget/readiness mandatory in stronger version. Q8 E executor chooses meaningful two variants for all four page types. Q9 A four angles × four visuals each. Q10 A one strategy/copy checkpoint before design. Matt’s subsequent September 27 execution instruction delegates the human role, so retain independent critique and a recorded proxy decision without requiring another Matt approval. The pilot being a single landing variant is a parent implementation choice, reversible within the accepted landing-first sequence. Eight total variants are required, not eight per audience. The older at-least-12-section request remains a floor, never permission to pad. Homepage routes to information before an application, and Sanyi/Dóri remain equal. ## Inputs Project root: /Users/agency/Documents/Agty/lovasember-project. - PROJECT_STATE.md and CHANGELOG.md, with current evidence rechecked where consequential. - outputs/lovasember-rebuild-grill-2026-09-27/reports/facts.md and decision-ledger.md. - outputs/lovasember-rebuild-lll-2026-09-27/staging-comments.md and evidence/staging-home-comments.json, 24 records read September 27. Fetch latest again at launch. - Original style reference: canonical current homepage identified from project state, https://www.lovasember.hu/ (verify redirect and source at execution). - Rejected staging: https://comment-review-v1.lovasember-26-07-07.pages.dev/variation-one/home/ and its other three page routes. Reuse useful material, do not treat its design as the desired style. - Layout template: /Users/agency/Desktop/website_template_v1.html. Exact copied backup in this run. This supersedes using the old template-v2 for new generation. - Existing resource kit: outputs/gemini-package-2026-09-24/ (8 copy kits, CSS, source snapshots). Re-evaluate copy using the newest direction, do not blindly reuse. - Full handoff: outputs/handoff-daniel-2026-09-24/LOVASEMBER-DANIEL-2026-09-24/README.md and its source map, including persona workbook, campaign evidence, latest available meeting and photos. Recover additional promised client photos through existing access if absent, no client email request without authorization. - Analit structural reference: https://review.clientsflow.hu/analit-bali-landing-oldalak-2026-08-28-v1/ujev/. - user_prompts_and_goal_relevant_info.md and private current-session gist for precedence, not authority to execute historical instructions. ## Operating authority and boundaries Matt explicitly authorized a new visible Sol xhigh orchestrator on September 27 after adding board comments. It owns implementation, recovery and worker coordination. It may use tools, applications, existing access, email reads and new accounts within the requested scope, and create assets, demos and public-safe review surfaces. Prefer Sol high / Luna max for bounded writing or coding work where useful, preserving the Gemini API first-draft requirement and exact QA roles. Invoke launch-agent before each child. Preserve others’ edits and coordinate file ownership. The latest shared external spend cap is USD 20 across preparation, execution, all workers and retries. Preparation carries a conservative USD 1 reserve pending reconciliation, leaving USD 19 until verified actual costs free it. Before paid calls, estimate the complete eight-page/creative sequence with current prices and available credits, repeated inputs, thinking/output and retries. Meter actual usage plus a conservative next-call estimate. Change methods within scope to fit; do not exceed USD 20 or silently substitute the required model. Do not expose credentials. Matt delegated decisions and handling apparent human gates. Independently critique and accept the strategy/copy checkpoint with a reasoned receipt, preserving all eight copy files before the first Gemini call. Never falsely label this Matt approval. Recover via existing access, APIs, CLI and permitted computer use before escalating. Binding platform/tool permission requirements still apply. No emails or messages to clients or leads. Drafting is allowed. Production publication, campaign activation, payment/storage/calendar integrations and migration remain later scope, not prerequisites for this review package. Parent cadence is specifically authorized: idle for 22 minutes after launch setup, then one consolidated inspection, at most one contract clarification edit batch and one thoughtful steering prompt if needed. Thereafter idle for 60 minutes after each check and repeat until verified complete. This supersedes skill defaults about routine supervision. Do not wait for parent checks to make progress. Report evidence and recover autonomously. ## Verification protocol Every criterion below is an observable test, not an implementation claim. Keep native board checkboxes unchecked until evidence exists. For every GUI criterion save a screenshot of the actual changed interface after that test with URL/build, viewport and state. Give screenshots alone to an independent gpt-6-luna high observer without the expected outcome. Attach its factual description and the executor's comparison to the criterion, and resolve any mismatch. Missing screenshot/description/comparison means unverified. This blind evidence check is separate from the complete Luna visual QA loop. Apply luna-visual-qa-section-screehoshots to the extracted brandbook by explicit user request, after EACH Gemini page before the next generation, and to every client-facing deployment: at least two independent fresh Luna xhigh workers, inventory-complete desktop/mobile section/state PNGs, report every section including passes, Luna max fixes with exclusive ownership, fresh re-QA until no errors remain. Retain earlier rounds. Actual postdeployment screenshots are required. Internal LLL board does not require the full client-site QA loop. ## Deliverables and observable tests ### D1. Ground decisions in sources Recover what works, understand the client and resolve every review comment. - **D1.1** When the existing campaign reports, persona workbook, latest recovered client meeting, current homepage and supplied staging are inspected, then source-ledger.md identifies dated facts, hypotheses, rejected drafts, missing facts and the strongest supported hooks for both audiences. - Evidence: Source ledger with exact paths/URLs, dates and claim-to-source references. - **D1.2** When the 24 saved homepage comments and fresh comments at launch are reconciled, then comments-disposition.md maps every comment ID to a specific copy/design/form requirement and its eventual page/section or reasoned non-applicability. - Evidence: Saved raw readback plus one row per record, including positive comment 17. Do not resolve the original comments. Constraints: - Keep original production website, working campaign and 5,000 Ft self-knowledge path unchanged. - Do not treat persona hypotheses, old testimonials or rejected staging claims as validated leadership outcomes. ### D2. Write persuasive journeys before design Define the promise, objections and next steps before Gemini sees the copy. - **D2.1** When both persona profiles and four message angles per audience are reviewed, then strategy.md explains everyday pain, attention hooks, objections, trust, willingness to invest, relevant targeting and ad-to-landing message match, with evidence strength and audience self-selection explicit. - Evidence: Persona-angle-targeting matrix. Women A/B and leader A/C are preferred hypotheses to rank, not mandatory winners. - **D2.2** When each of the eight page-copy files is read without design, then at least 12 substantive sections per variant explain relevance, trust, the method, what application and consultation involve, and what can follow, with a stated purpose and conversion role for every section. - Evidence: Eight Hungarian Markdown copy files, sentence/section critique and two independently reasoned variants of home, About, self and leader. Count is a floor, not a quality score. - **D2.3** When both persona/ad packs and all four plain-text landing variants receive a documented independent strategy/copy critique under Matt’s delegated decision authority, then checkpoint.md records the executor’s reasoned acceptance and applied revisions, and all eight completed, sentence-critiqued plain-text copy files exist before the first Gemini page-generation API call. - Evidence: Checkpoint receipt with reviewer findings, executor decisions and eight versioned copy files. Home/About copy derives from settled plain-text landing journeys. Matt’s September 27 launch instruction delegates human-gated decisions: complete the substantive quality review autonomously, never fabricate Matt approval or wait solely for a human click. All eight copy files must precede the first page call. Constraints: - Sanyi and Dóri are equal partners, without inventing qualifications, attendance promises or results. - Problem-aware, coaching-sceptical visitors get human situations first, then experiential horse-assisted differentiation. Do not imply scientifically proven superiority, mystical claims or guaranteed outcomes. - Paid-continuation section A gives verified format, activities, time/location and available prices. Section B explains the experience and next step while leaving later prices for the consultation. Keep facts identical and do not invent a fixed leader package. ### D3. Extract and prove the brandbook Give Gemini a faithful style specimen instead of a vague visual description. - **D3.1** When brandbook.html is opened from its saved monolithic file, then four identified sections copied from the current original homepage, plus its exact navbar/header/footer reference, render with the original CSS embedded in the HTML and source assets resolving. - Evidence: Source snapshot, section selectors/IDs, extracted fragment comparison, CSS hashes and asset/font manifest. Separate original-source specimen from explanatory guidance. - **D3.2** When the original homepage and extracted specimen are inspected at matched desktop/mobile sizes and corresponding section states, then all four sections and shell elements match typography, colors, spacing, widths, images and component styling in brandbook-comparison.md before any Gemini generation. - Evidence: Paired local PNG section screenshots, blind Luna high descriptions and parent comparisons, plus tailored full Luna visual QA reports. Document dynamic/source differences explicitly. - **D3.3** When a Gemini input bundle is assembled, then it contains the checked brandbook HTML, brandbook-guide.md, the exact supplied website_template_v1.html, approved relevant copy, verified facts and page-specific instructions. - Evidence: Bundle inventory and SHA256 comparison to /Users/agency/Desktop/website_template_v1.html. Guide says original style wins over template styling. Each home generation uses a fresh Gemini context containing both settled persona/ad/targeting packs and refined landing outputs, alongside its prewritten copy. Any new copy refinements are completed before that page call. Supply the exact HTML/CSS of brandbook and template as labeled text parts, not a URL-only reference or unsupported raw-byte attachment. Count the full bundle and record source-byte hashes. Constraints: - The four source sections must be extracted faithfully, not reconstructed or redesigned. Embed CSS and preserve working image/font references or bundled assets. - Template /Users/agency/Desktop/website_template_v1.html supplies layout options only. Do not replace it with the older reusable-template-kit/template-v2.html. - Do not reproduce unrelated live tracking or form submission side effects in the reference demo. Record any removed runtime behavior without silently altering appearance. ### D4. Generate eight consistent Gemini drafts Learn from every completed page before generating the next, including page seven before page eight. - **D4.1** When the first approved landing-page variant is requested through the Gemini 3.1 Pro API using the complete bundle, then its saved HTML and generation-receipt.json identify the actual model, input versions, request time, response and token/cost usage. - Evidence: Native API receipt and saved raw response, with credentials removed. Choose the pilot from the accepted two landing journeys and explain why. Preflight records documented endpoint gemini-3.1-pro-preview, preview status, selected project access/quota, bundle token count, configured output ceiling and aggregate/per-call budget. Record returned model version and finish reason; truncated HTML is a failed draft, not a completed variant. - **D4.2** When the first page is visually inspected and repaired, then pilot-review.md records complete section/state coverage and design comparison, and versioned brandbook guidance plus next-page prompt contain the useful corrections before the second generation call. - Evidence: Tailored Luna xhigh QA, Luna max fixes as needed, fresh QA, before/after screenshots, ordered timestamps and prompt/brandbook hashes. Preserve faithful source specimens during guide revisions. - **D4.3** When the remaining variants are generated sequentially, then eight distinct first-draft API outputs and eight refined pages exist as home A/B, About A/B, self A/B and leader A/B, each using the latest accepted style guidance and its own approved copy. - Evidence: Eight model receipts and input bundles, generation order, change log, full page inventory. After EACH Gemini page, apply luna-visual-qa-section-screehoshots fully: section screenshots, independent QA, fixes and fresh QA plus design-consistency review. Improve versioned brandbook guidance and the next Gemini prompt before the next call, explicitly including page seven to eight. Preserve the exact source specimens. Harmonise earlier pages when shared rules improve. Constraints: - Use Gemini 3.1 Pro API for the first drafts, not browser Gemini or another model silently. Verify the current exact model identifier and access. - Generate one page variant first. Do not batch all eight before the pilot QA and guidance update. Finish landing journeys before deriving final home/About design. - Gemini must not drop approved meaning, invent client facts, overwrite the source brandbook or mix template typography/colors into the established brand. ### D5. Show campaign combinations below landings Make every ad, message and audience reviewable below the landing footer, using the Analit appendix as the structural template. - **D5.1** When the two campaign asset manifests are counted and opened, then each campaign has 16 actual new image creatives grouped as four message angles by four visual executions, with three tailored copy variants per creative, totaling 32 assets and 96 copies. - Evidence: Asset files, concept/copy matrix, source-photo provenance, current top-performer evidence and generation receipts. SVG text cards or prompts alone are not finished image creatives. - **D5.2** When either variant of each landing is opened and scrolled past its footer, then its campaign appendix displays all 16 matching creatives, their three selectable copy variants and audience/targeting rationale as readable mobile Facebook-feed-style previews. - Evidence: Actual hosted screenshots of every creative/copy state in inventory, no distorted/cropped assets, working switching and campaign mapping. Appendix is visibly separate from customer copy. Matrix: two audiences × two landing variants × 16 creatives × three copies = 192 placements/states backed by 32 unique assets and 96 unique copies. If one verified shared appendix renders both variants, document code/data equivalence and test each variant’s correct audience mapping; inventory every state and retain screenshot proof of each unique rendered state plus each mounted placement. Constraints: - Use existing best-performer patterns and client-supplied photos where appropriate. Do not fabricate client portraits, testimonials, endorsement or performance claims. - Use the Analit page as structural reference, not its travel claims/audiences. Keep proposed campaigns as review-only drafts and make no live targeting, budget, tracking, activation or spend changes. Existing campaigns remain in their current state. ### D6. Demonstrate alternative lead-capture journeys Let Sanyi compare the full application-to-booking experience. - **D6.1** When reviewers exercise the light and stronger qualification variants, then short interactive cards/sliders/questions lead to contact details on a second step, validation, a demo submission confirmation and a thank-you booking choice, with back-navigation preserving entries. - Evidence: Local and hosted interaction screenshots covering both audiences and each variant. Stronger version includes time commitment and budget/readiness without inventing package prices. Before building, enumerate both light and strong modes for each audience in a closed route/state manifest; both landing variants expose their audience’s two modes without multiplying pages. Cover contact validation, back-navigation, confirmation and booking for every applicable branch, and mark route choices inapplicable only with an explicit reason. - **D6.2** When the booking options are compared, then a booking-button version, an embedded-calendar frontend demo and future 5,000/10,000 Ft leader paid-path design states can be reviewed, with the optional 30,000 Ft calendar-backend integration explained separately. - Evidence: Screenshots of free/current/future-paid journeys and review labels. Payment screens are prototypes with no real charge or live availability claim. Present the exact 30,000 Ft as Matt’s proposed optional calendar-backend upgrade, not a purchased service or a new binding commitment. This is separate from undefined paid coaching continuation. - **D6.3** When a reviewer chooses the self, leader or unsure route, then consultation terms remain explicit before submission: self introduction 5,000 Ft, leader introduction initially free, and unsure visitors choose a clearly priced route rather than an invented third price. - Evidence: Route matrix and rendered screenshots. Demo submits do not send emails, save to production Sheets or book live calendar slots. Close the self/leader/unsure branch matrix against the form manifest, record expected totals and actual receipts, and verify no storage, email, payment or live-booking request is issued. - **D6.4** When reviewers compare paid-continuation disclosure for each landing family, then both A and B section alternatives render and can be selected or compared within the existing eight-page review scope. - Evidence: A/B state inventory and hosted screenshots for both audiences. A shows verified detail and available prices; B explains the experience and leaves later prices to consultation. No extra full-page variant matrix. GUI screenshot/independent description/comparison required. Constraints: - Keep application before optional booking. Live storage, Sanyi notification, Sheets, calendar integration and payment backend are later implementation steps. - Remove the rejected demo terms-acceptance checkbox, retain clear prototype status, and record that actual production consent/legal text requires a later check rather than silently removing production obligations. - No actual leads or sensitive answers are collected during public review. Any stronger readiness wording remains tactful and relevant to the verified offer. ### D7. Verify and publish the complete review Prove visual coherence and the whole funnel on the actual hosted build. - **D7.1** When all eight pages are reviewed at desktop/mobile viewports and meaningful interaction states, then section-coverage.md contains every header, section, footer, tall-section segment, campaign preview and form state with inspected PNGs and no unresolved visual errors. - Evidence: At least two fresh Luna xhigh QA workers with disjoint page/viewport partitions, actual model receipts, Luna max fixes where needed, fresh complete re-QA. Blind high screenshot descriptions and criterion comparisons attached separately. - **D7.2** When the full website is opened in a fresh unauthenticated client at its stable review URL, then all eight variants, navigation, form demos, campaign appendices and comment controls work and comment/rewrite persistence passes using a disposable/intercepted document. - Evidence: Anonymous HTTP readbacks, desktop/mobile actual postdeployment screenshots and interaction receipts. Preserve existing review host pages and document identity. - **D7.3** When original-brand references and all eight final pages are compared together, then consistency-review.md verifies a shared content width, nav alignment, type scale/body style, darker green palette, image treatment, icon weight and section rhythm, with all 24 comments dispositioned. - Evidence: Side-by-side screenshots and comment-ID evidence links. Do not call section count, DOM checks, a successful build or one desktop screenshot sufficient quality proof. Constraints: - Publish through comment-html-review-host at a bare URL with no login/token/VPN/IP gate. Keep secrets and sensitive source data off public pages. - Preserve the original successful site/campaign, rejected staging and its existing comments. Use a distinct new review surface and retain all prior QA rounds. ### D8. Prepare the client handoff and continuation Finish with clear review instructions and a usable next-work state. - **D8.1** When the review handoff is opened, then README.md and the review index list verified URLs, deliverables, status, remaining client choices and the exact workflow after Sanyi/Dóri comment, with editable sources and generation inputs available. - Evidence: URL manifest, deliverable list, main-prompts file, current-session file, final report, updated project state/changelog, reusable next-step checklist. - **D8.2** When client-email-draft.md is read, then it concisely links the full review, explains the ad/copy/targeting and funnel choices, requests consolidated feedback and asks Sanyi whether to issue a small partial invoice now or arrange payment differently. It proposes weekly reporting/check-in without inventing dates or binding commitments. - Evidence: Draft only, no send receipt. Clearly state demo forms, optional calendar fee, and separate later approval of campaign launch/spend. No invoice issued. Retain Matt’s exact proposed optional 30,000 Ft calendar-backend upgrade without presenting it as purchased or already connected. - **D8.3** When the continuation plan is read after review, then it separates feedback revisions, approved production publication, storage/notifications/Sheets, calendar/payment options, tracking verification, Cloudflare migration and campaign activation into ordered next steps with dependencies and unresolved facts. - Evidence: next-steps.md, no claim these later integrations or migration are implemented. Include reporting/check-in proposal without inventing dates or client commitments. Constraints: - No emails to Dani or client, no invoice, no binding price changes, no campaign activation and no production migration in this run. - Do not mark the run complete until all required evidence is attached or an exact blocker and resume point are recorded. Keep rejected drafts clearly labelled. ## Open facts, assumptions and resolution No further strategic question is needed to execute. The executor chooses persona hooks and variant contrasts from evidence, recording hypotheses honestly. Resolve the exact paid follow-on offer from sources and flag missing commercial facts for client review, never invent them. Public Google documentation checked on 2026-09-27 identifies `gemini-3.1-pro-preview` (Preview), with 1,048,576 input and 65,536 output tokens maximum. Use that ordinary endpoint, not the distinct customtools endpoint. Standard API rates are $2 input/$12 output per million tokens for prompts at most 200,000 tokens and $4/$18 above that threshold; output includes thinking and no free API tier is listed. Recheck these version-sensitive values at execution and preserve the requested model if identifiers change. Account access, billing/quota, actual bundle sizes, usable client photo availability and source styling dependencies still require provider/source evidence. Send HTML/CSS inline as labeled text; if a supported Files API path is chosen instead, retain exact bytes/MIME and handle the documented 48-hour expiry. Sources: [model](https://ai.google.dev/gemini-api/docs/models/gemini-3.1-pro-preview), [pricing](https://ai.google.dev/gemini-api/docs/pricing), [API input](https://ai.google.dev/api/generate-content), [file inputs](https://ai.google.dev/gemini-api/docs/file-input-methods), [rate limits](https://ai.google.dev/gemini-api/docs/rate-limits). Missing custom photos may use verified existing site assets while the omission remains visible, but a missing required brandbook/API/QA capability cannot be called passed. Do not silently create a price for the unsure route. ## Board, launch and continuation Primary board URL: https://review.clientsflow.hu/lovasember-rebuild-verification-2026-09-27-v1/ Local HTML: outputs/lovasember-rebuild-lll-2026-09-27/verification.html. The executor must be able to edit and republish this HTML. Preserve the base plan black, progress/evidence blue, verified green and failures red, native criterion IDs, counters and screenshots. Record current item and proof, republish the same URL after meaningful updates. Public board omits sensitive evidence, linking safe summaries instead. Parent read both live annotations on September 27 and reconciled them with the explicit launch request. Preserve this run URL and comment document during execution. Executor maintains deliverables.md, main-prompts.md and current-session.md. Parent uses the explicitly requested 22-minute then 60-minute single-check cadence, staying idle between checks. Completion review uses exact-session extract-gist plus small read set, current board and main outputs. Final state distinguishes verified/pending/blocked/untested, preserves evidence and resume points, and uses xplain-with-voice after the substantive execution. No automatic re-launch.