LLL · communication board

Verification and Constraints

● COMPLETE · revision 2 verified

A visible, testable contract for the Balionline website and CRM requests, plus the final client WhatsApp draft from 21–25 September.

Owner: Sol High executor Run: analit-whatsapp-20260926-v1 Updated: 2026-09-26

Current revision 2 terminal report · Final WhatsApp draft, not sent · Read test conditions and remaining limits before treating every protected visitor path as tested.

Goal and finish line

End goal: Make Balionline visitor and staff interfaces visibly match the WhatsApp requests, and prove website signups and quote requests reach the right CRM records.

Done means: Flight cards, trip order, custom-trip fields, and the April itinerary look and work as specified; a consented newsletter signup appears in the active CRM list; each distinct active quote-request flow creates or updates the right CRM partner. Each live result has its own proof. The final WhatsApp draft explains verified changes and the Facebook restriction accurately.

16 / 16criteria verified

7deliverables

0human actions pending

Rules that stay fixed

Keep approved trip facts, prices, content, visibility, real CRM records, and consent choices intact.
Deliver the requested newsletter and partner outcomes in the active CRM; preserve any working archive route.
Do not add an access gate or send client messages or campaigns; use bare public URLs for new review surfaces.

Proof standard: Every GUI test needs a post-change screenshot, a blind gpt-6-luna high description of that screenshot, and a criterion comparison. CRM tests also need record IDs and field readback.

Known interfacesSource identifiers, not completion proof

Group-trip collection and the affected three-step inquiry: https://balionline.hu/csoportos-utak-gyujtooldal/ , form[data-backend-form="form_csoportos"], headed Személyre szabott útiterv / Add meg az igényeidet. Step 1 contains Hozzávetőleges keret / fő, step 2 contains Utazás hossza, and step 3 contains Igények összegzése.
The 2027 5–19 April itinerary: https://balionline.hu/utazas/tavaszi-nyaralas-bali/ .
Website newsletter signup: https://balionline.hu/ , #newsletter-form, #newsletter-consent, Feliratkozom.
Known quote-request entry points for D7: homepage https://balionline.hu/ (#form_main), group collection https://balionline.hu/csoportos-utak-gyujtooldal/ (form[data-backend-form="form_csoportos"] / #form_csoportos), individual trips https://balionline.hu/egyeni-ut/ (#form_egyeni), and April trip https://balionline.hu/utazas/tavaszi-nyaralas-bali/ (#form_trip_tavaszi-nyaralas-bali). The collection button says Ajánlatot kérek, the other known quote buttons say Kérem a személyre szabott árajánlatot!. This is a starting inventory, not proof of exhaustive coverage or working CRM delivery. #form_global_contact (Üzenet Küldése) is a contact-only candidate to classify by its actual purpose.
These public interface identifiers were checked during Prepare. Their current behavior and CRM destinations still require the tests below. The authenticated CRM interfaces remain open facts. Matt clarified that the posting report concerns Facebook and removed its repair from scope.

End goal system

Where each result appears

Confirmed requestReported, unverifiedOpen source or decision

flowchart TD
 V["Visitor
Opens Balionline"]:::confirmed
 G["Group trips
Flights · order · April"]:::assumption
 I["Inquiry
Budget · Bali nights"]:::confirmed
 N["Newsletter
Consented signup"]:::confirmed
 Q["Quote forms
Every active flow"]:::confirmed
 C["Active CRM
Schema verified"]:::confirmed
 NL["Newsletter list
One subscriber"]:::confirmed
 P["Partners
Mapped request"]:::confirmed
 S["Final draft
WhatsApp handoff"]:::confirmed
 V-->G
 V-->I
 V-->N-->C-->NL
 V-->Q-->C-->P
 G-->S
 NL-->S
 P-->S
 classDef confirmed fill:#E8F5E9,stroke:#2E7D32,color:#173B25
 classDef assumption fill:#FCE4EC,stroke:#C2185B,color:#5B1430
 classDef open fill:#FFFFFF,stroke:#94A3B8,color:#475569,stroke-dasharray: 5 5

Route to the end state

Approved execution route

flowchart LR
 W["Reports
Screenshots"]:::confirmed
 H["Past fixes
Unverified"]:::assumption
 R["Reviewed
Comment applied"]:::confirmed
 L["Launch
Authorized"]:::confirmed
 X["Inspect
Live sources"]:::confirmed
 F["Fix
Scoped gaps"]:::confirmed
 E["Verify
Screenshots"]:::confirmed
 D["End state
7 results"]:::confirmed
 W-->R
 H-->R-->L-->X-->F-->E-->D
 classDef confirmed fill:#E8F5E9,stroke:#2E7D32,color:#173B25
 classDef assumption fill:#FCE4EC,stroke:#C2185B,color:#5B1430
 classDef open fill:#FFFFFF,stroke:#94A3B8,color:#475569,stroke-dasharray: 5 5

Deliverable flow

Inputs → outputs · maximum eight nodes

Read left to right. Each node names why it exists. Add an extra-next line only when it describes a later handoff that is not represented by the next visible node.

Input

WhatsApp requests

Why: What Dorottya and Zsuzsi reported, including the two screenshots.

Input

Live source and CRM

Why: Current pages, approved trip data, active CRM schema, relevant Facebook policy evidence.

Deliverable

Group trips

Why: Flight cards, saved order, and April image prove the visitor pages.

Deliverable

Collection-page inquiry

Why: Budget and Bali nights are clear and survive submission.

Deliverable

Newsletter CRM list

Why: Consented website signup is visible in the active list.

Deliverable

CRM partners

Why: Every distinct quote flow reaches a correctly mapped partner.

Verification

Evidence review

Why: One row per criterion with screenshots, provider readbacks, and truthful state.

Final output

Final WhatsApp draft

Why: After verification, a Hungarian draft explains changes and Facebook policy.

Supplied screenshots

Original observations, not completion proof

Original per-person budget dropdown — Screenshot 1 · Custom-trip budget dropdown with the old ranges.

Original detached photo below day ten — Screenshot 2 · Detached image below the 5–19 April day-10 itinerary card.

Parent ↔ child messages

Newest message first

Matt authorized one pinned Sol High executor. His comment removes Facebook repair and adds a final WhatsApp draft. Parent check: once at least 60 minutes after launch, then idle.

Parent read setSmall files first

After launch, the executor records the clean gist, deliverable list, and main prompts for the final parent review.

Work and proof

One card per deliverable

Show flight schedules

Visitors see the approved flight schedule inside each relevant group-trip description.

VERIFIED2 / 2

Show criteria, constraints, and evidence

Observable tests

D1.1 When a visitor opens each currently bookable group-trip page that has an approved flight itinerary and reads the trip description before the FAQ, then the corresponding flight schedule card with the approved route, dates, and times appears inside that description on desktop and a narrow mobile viewport.

Proof: live URL inventory, approved schedule source comparison, after-test screenshots and independent description.

D1.2 When the visitor opens the 2027 5–19 April trip at https://balionline.hu/utazas/tavaszi-nyaralas-bali/ and checks its flight card against the current approved itinerary, then the displayed schedule agrees with that itinerary in the trip description, without requiring a scroll to the FAQ.

Proof: source/readback comparison and after-test screenshots.

Desktop · Mobile left · Mobile right · Blind descriptions and comparison ·

Protect

keep the existing FAQ answer; do not invent or silently update airline, flight number, departure time, or included-price claims.
If no approved schedule exists for a trip, record that trip as an open source dependency instead of showing guessed details.

Evidence: source/public row comparison, eight desktop cards, sixteen mobile scroll-position captures, independent literal descriptions and parent comparisons.

Match saved trip order

Staff save the order once; public trip lists and navigation show that saved order.

VERIFIED3 / 3

Show criteria, constraints, and evidence

Observable tests

D2.1 When staff open a trip in WordPress Utazások → Navigáció sorrend, enter an agreed position and press the bottom Mentés button, then the saved position appears on reopening that editor and the corresponding trip appears in that position in the public Csoportos utak navigation and trip listing at https://balionline.hu/csoportos-utak-gyujtooldal/ after cache refresh, where those surfaces use this field.

Proof: editor readback, public ordering list, after-test screenshots from editor and anonymous desktop/mobile pages.

Restored editor · Mobile evidence 1 · Mobile evidence 2 · Mobile evidence 3 · Native save/readback · Public ID comparison · Saved title order · Blind descriptions and comparison · Desktop menu top · Desktop menu bottom ·

D2.2 When a visitor compares the inventoried navigation and trip-list surfaces actually driven by Navigáció sorrend, then the same visible active trips follow the saved order on desktop and mobile, while a trip hidden through the existing visibility control stays hidden.

Proof: ordered title/URL comparison and after-test screenshots.

D2.3 When the order guidance is found on a staff-facing or public page, then the visible text explains where to save and that cache can delay the public view, without promising an unverified fixed refresh time or implying that incognito itself purges the cache.

Proof: exact before/after copy and after-test screenshot. If the reported sentence cannot be found, retain the searched locations and historical/current discrepancy and leave this criterion unverified until its actual location or removal is established.

After-test editor screenshot
Blind description and comparison

Protect

do not replace the existing hide-from-navigation control
do not reorder trips by a new unrequested date rule or change current staff-selected ranking values except for a reversible test that is restored.

Evidence: native saved/restored ranks, current guidance, anonymous public ordering, editor and desktop/mobile screenshots, independent descriptions and comparisons.

Clarify custom trip inputs

The collection-page form shows exact budget and Bali nights through its three steps and receiving record.

VERIFIED3 / 3

Show criteria, constraints, and evidence

Observable tests

D4.1 When a visitor opens step 1 of the collection-page form_csoportos inquiry identified above and enters a per-person amount such as 1 000 000 Ft, then the Hozzávetőleges keret / fő field, step-3 Igények összegzése, and submitted receiving record show that exact numeric amount and clearly state whether international flights are included.

Proof: rendered form, submitted test payload/readback, and after-test screenshots. The old 500 000 Ft alatt and 500 000–800 000 Ft choices must not suggest a complete flight-inclusive trip at that price.

Final comparison · Independent image descriptions · Provider reconciliation · Deployed and restored hashes · Mobile budget · Mobile nights guidance · Mobile summary · Reachable submit · Mobile success · CRM request1790 · Four-request history · Protected D4 success · Desktop form comparison

Desktop and properly measured mobile budget/summary show1 000 000 Ft including international flights. Genuine protected1768 and final mobile1790 preserve exact receiving values. rev2-final-comparison.md + final-provider-reconciliation.json.

D4.2 When a visitor enters 7 in step 2 of form_csoportos for trip length, then the interface labels the value as Balin töltött éjszakák, explains the usual shortest stay as 7 éj / 8 nap in Bali with roughly two additional travel days, preserves the exception for people already in Asia combining countries, and step-3 Igények összegzése plus the submitted receiving record preserve 7 as Bali nights rather than total holiday days.

Proof: form, final review/payload readback, and after-test screenshots.

7 Bali nights,7 éj/8 nap plus travel-day guidance and Asia exception match summary and receiving records. Shorter stays remain allowed. Final mobile and provider comparison passed.

D4.3 When the form is completed on desktop and a narrow mobile viewport, then budget, nights, validation, and submit controls remain readable and operable, and the same submitted values reach the receiving record.

Proof: viewport screenshots and receiving readback.

Actual narrow380px form and390px success captures, operational controls and mobile request1790 match desktop values. Earlier validation proof retained. Rev2-final-blind and root comparison complete.

Protect

do not add a hard seven-night minimum or reject shorter inquiries without an existing approved rule.
Keep the rest of the three-step inquiry and its existing lead delivery intact; do not silently create a price quote, guarantee a total travel cost, or redefine existing submitted leads.
Preserve consent and existing field mappings unless a changed field requires a documented migration.

Actual website first/repeat submissions and matching CRM readbacks verified. Independent screenshot descriptions compared. CAPTCHA test conditions and protected-newsletter limit are documented in the terminal report.

Remove stray April image

The detached thumbnail below day 10 is gone; the itinerary remains intact.

VERIFIED1 / 1

Show criteria, constraints, and evidence

Observable tests

D5.1 When a visitor opens https://balionline.hu/utazas/tavaszi-nyaralas-bali/ (2027 5–19 April) and scrolls immediately below the day-10 Két út vár rád card shown in screenshot 2, then no detached unrelated thumbnail appears below the card, while the intended itinerary text and program choices still appear.

Proof: before/after location and desktop/mobile after-test screenshots.

Desktop day10 · Desktop transition · Mobile boundary · Mobile following content · Descriptions and comparison ·

Protect

remove only the erroneous image or attachment at that position
retain legitimate gallery/media elsewhere and the April trip's program layout and copy.

Evidence: exact provider change, text/media preservation, desktop/mobile boundary screenshots and independent descriptions.

Connect newsletter to CRM

A website signup lands in the active CRM newsletter list with consent and source.

VERIFIED2 / 2

Show criteria, constraints, and evidence

Observable tests

D6.1 When a visitor submits the homepage #newsletter-form at https://balionline.hu/ using Feliratkozom, the existing consent choice, and a unique consenting test address, then the site shows an honest result and exactly one matching subscriber appears in the active CRM newsletter list with the expected consent/source fields.

Proof: form response, CRM list readback/record ID, and after-test screenshots of both interfaces.

Final comparison · Independent image descriptions · Provider reconciliation · Deployed and restored hashes · Consented website form · First result · Repeat result · CRM source and consent · One subscribed list result · First exact preservation · Repeat exact preservation · No pending note backup · Restored rejection · No-record receipt

Website-origin partner3664/email3844/list1, one consent/source block. Final first/repeat website attempts on deployed a3ba4313 preserve entire contact/details and original timestamps, zero pending backup. Authorized temporary exception restored.

D6.2 When staff inspect the active CRM after the signup, then they can find the new subscriber by the same address and see whether it is eligible for the newsletter; the outcome does not depend solely on a Sheet export or retired Mailchimp audience.

Proof: CRM search and screenshot plus the current integration route readback.

Exact-address CRM active-list screenshot shows one subscribed partner3664 with source/consent detail. Current caller and final bridge readback verified. No campaign sent.

Protect

use the CRM list selected by the client, preserve opt-in/consent semantics, and avoid duplicate subscribers or campaign sends.
Do not remove a functioning Sheet/archive flow without checking its current role and preserving existing data.

Create partners from inquiries

Every distinct active quote-request flow creates or updates the correctly mapped CRM partner.

VERIFIED3 / 3

Show criteria, constraints, and evidence

Observable tests

D7.1 When a visitor submits a unique, valid quote request through each active website quote-request flow, then the CRM Partnerek list shows one correctly matched partner created or updated automatically under the verified duplicate rule, with that form's name/contact data and agreed custom fields mapped correctly.

Proof: inventory every active quote entry point with its URL, visible button/form title, form identifier, destination/modal, submission route and CRM mapping. Reconcile the four known routes above and any additional active quote buttons found across the public site. For every distinct flow retain successful submission, CRM partner record ID/field comparison, and after-test screenshots of the form and CRM record. Entry points may share an end-to-end test only when shared rendering, submission route, effective field mapping, CRM create/update path and duplicate behavior are evidenced.

23 URL inventory reconciled to five distinct receiving mappings, CF6 shared across18pages with equivalence evidence. Website submissions and CRM partner/custom-field screenshots/readbacks verified.

D7.2 When the same known contact submits a second test inquiry through each distinct CRM mapping/update path inventoried in D7.1, then the CRM applies its agreed duplicate/update behavior without an uncontrolled second partner, and both requests remain traceable.

Proof: before/after CRM search, record IDs, field/request history, and screenshots.

Same-address repeated website requests retain one partner/email detail for each mapping and both traceable requests. Twelve task quote jobs delivered and field-verified, including four D4requests.

D7.3 When staff open an incoming test request from each distinct CRM mapping/update path in the CRM, then the corresponding partner can be identified by the matching contact/request identifier and already contains the mapped form values, without staff manually re-entering them.

Proof: CRM interface screenshot and provider readback.

Each incoming mapping has CRM screenshot, matching partner/requestUUID and mapped values. All12jobs verified and transient request body removed. Provider ampersand display blemish documented.

Protect

include quote-request flows only.
Exclude unrelated booking and general-contact forms with a recorded purpose-based reason, checking whether any also offers a quote-request action.
Keep the D4 budget/night field changes confined to its named form.
Preserve existing inquiry notification and request history; do not overwrite unrelated partner fields or create newsletter consent from a quote inquiry.
Confirm the authoritative CRM, field schema, and duplicate rule before wiring them.

Draft the WhatsApp handoff

Final Hungarian draft explains verified changes, staff operation, and accurately qualified Facebook policy.

VERIFIED2 / 2

Show criteria, constraints, and evidence

Observable tests

D8.1 When Matt opens client-whatsapp-draft.md after D1, D2, D4, D5, D6 and D7 have been verified or their precise remaining limits recorded, then a concise Hungarian message ready to copy into WhatsApp explains what was actually changed, where visitors see it, and where staff save trip order, find newsletter subscribers, and find quote-request partners. Any unfinished outcome is described honestly.

Proof: saved draft compared line by line with verified receipts and unresolved criteria.

Unsent WhatsApp draft · Claim-by-claim comparison · Official policy and applicability gap ·

D8.2 When Matt reads the final one or two sentences about Facebook posting in that draft, then they explain the relevant URL-posting policy or restriction accurately, using current official Meta information or the affected account’s notice. A universal paywall is not asserted from the comment alone. If applicability cannot be verified, the draft clearly qualifies it as a possible or account-specific restriction and the accompanying internal note names the evidence gap.

Proof: official source or account notice, dated applicability check, and exact draft wording. The file visibly says draft, not sent.

Unsent WhatsApp draft · Claim-by-claim comparison · Official policy and applicability gap ·

Protect

do not repair Facebook, publish test posts, subscribe to a paid product, or send the WhatsApp message.
Keep the text natural Hungarian, without em dashes or semicolons.
Do not claim unverified completion or invent a universal Facebook policy.
Write this draft as the final plan step after establishing actual outcomes.

Final unsent Hungarian draft compared claim by claim with verified results and explicit remaining limits. Current official Meta policy cited, account applicability qualified.

Open facts and later handoff

Unknowns stay visible

CONFIRMED: Dorottya wants the flight schedule in trip descriptions, realistic budget entry, Bali-night wording, the stray April image removed, and website leads in the CRM. Dani says the order field is “Navigáció sorrend”.

RESOLVED: Current CMS flight data, saved staff ranks, editor guidance, flight-inclusive budget wording and QlickCRM schema/list/duplicate rule have been read. Their live acceptance remains criterion-specific.

LIMITS: Successful protected newsletter submission is untested. Authorized exact-address exceptions are restored. Final no-challenge UI rejection creates no CRM record. Two CRM labels display a literal ampersand entity. Facebook Page-specific applicability remains unverified.

LATER INPUT: Dorottya says the copy, photos, and ideas for new individual-trip sections are still being prepared. Those sections and a possible consultation page are a later scope when materials arrive.

Execution state

Terminal result and test limits

16 / 16criteria verified

UNSENTHungarian WhatsApp draft

Restoredoriginal CAPTCHA source