webcake-landing-mcp 1.0.18 → 1.0.20

package/dist/domains/landing/guide.js

@@ -49,6 +49,31 @@ STICKY / FIXED HEADER (and any overlay element) — reserve space so nothing hid
 - Do NOT duplicate the brand/shop name: if the header shows the shop name, remove or reposition any shop-name line that sat at the very top of the hero — otherwise the two overlap (a classic symptom: a half-hidden shop-name behind the header).
 - A NON-sticky header is simpler — it's just the first section in \`page\`, stacks normally, and pushes the hero down on its own (no offset needed). Only add the offset when the header is sticky/fixed.
 
+LAYOUT ARCHETYPES (the page's STRUCTURE follows its TYPE — from the intake goal, pick the archetype that matches and do NOT default every page to the sales template. Each archetype has a DIFFERENT section set + flow. These are section orders, not coordinates — still design sizes/positions from the centering math above.)
+- Sales / COD product → header · hero (offer + CTA) · benefits · product list or grid · social-proof · order form · footer.
+- Lead-gen / service → header · hero (value-prop, with the form or CTA inside the hero) · benefits · how-it-works steps · testimonials · FAQ · final CTA · footer.
+- Event / invitation → hero (title + date/venue + countdown) · about/agenda · speakers or schedule · gallery · RSVP form · location · footer. (No "products".)
+- App / SaaS promo → hero (app/phone mockup or screenshot + tagline) · feature grid · how-it-works · pricing tiers · store badges or signup · footer.
+- Portfolio / personal → bold typographic hero (lots of whitespace, often no image) · selected-work gallery/grid · about · services/skills · contact · footer. Minimal, NOT a hard sell.
+- Local business / restaurant → hero (ambiance photo) · highlights or menu · story/about · gallery · hours + map + reservation/contact · footer.
+- Course / webinar → hero (outcome + enroll) · what-you'll-learn · curriculum/modules · instructor · testimonials · pricing/enroll · FAQ · footer.
+Drop/add sections per what the user confirmed; a simple page can be just hero + form. If the page type isn't listed, compose a structure from its purpose — never fall back to the sales template by reflex.
+
+VISUAL VARIETY (make two pages of the SAME type still look different — driven by the brand + tone, never one default skin):
+- HERO treatment — pick ONE that fits and VARY it across pages: (a) text on one side + image/mockup on the other; (b) full-bleed background image + color overlay + centered headline; (c) bold centered typography, no image; (d) product/phone mockup centered. Do NOT reach for "image-right" every time.
+- PALETTE — derive from the user's primary color: one accent + 2–3 neutrals + 1–2 band backgrounds. Alternate band backgrounds (light / tinted / dark) so sections read as distinct; always keep text contrast.
+- TONE → type & alignment — premium/minimal = lighter weights, generous whitespace, centered or left-ragged; playful = bolder, rounded, more color. Match the tone the user described.
+- DENSITY/RHYTHM — size section heights and padding to the content; keep vertical rhythm consistent WITHIN a page and a shared horizontal axis, but vary composition BETWEEN pages so output never feels templated.
+
+SECTION BUILD HINTS (apply to whichever sections the chosen archetype uses)
+- Each section is one visual band: height that comfortably holds its content (taller on mobile since things stack), background that contrasts its text.
+- HERO — always a clear H1, a short supporting line, and the primary CTA visible without scrolling.
+- FEATURES / BENEFITS — a row of equal cards (icon + title + text) or a 2-column list. Center the row with the ROW math; on mobile shrink to one canvas width or stack.
+- PRODUCT / OFFER — image beside name + price + benefit list + CTA (swap sides per balance). Price and CTA stand out.
+- SOCIAL PROOF — testimonial cards, a logo strip, or a row of stat counters (auto-number + label). Center the row.
+- FORM / CTA — center the form box; stack inputs vertically with comfortable spacing; each input needs a unique specials.field_name (canonical: full_name, phone_number, email, address, quantity); prominent submit button.
+- FOOTER — name + real contact lines, usually centered on a dark band. Only real data the user provided.
+
 RULES
 - Visible content goes in "specials" (text-block.specials.text, image-block.specials.src…), NEVER in "styles".
 - Colors as rgba(r,g,b,a). fontSize/borderWidth/top/left/width/height are NUMBERS (px).
@@ -60,16 +85,21 @@ RULES
 - ANIMATION: each breakpoint's config has config.animation = { "name":"none", "delay":0, "duration":3, "repeat":null }. Keep "none" unless an entrance animation is wanted.
 - Real data the page DISPLAYS must come from the user — never invent it: phone/hotline/Zalo, price (+ original price), address, shop/brand name, links/URLs, email, opening hours, exact stats/social-proof numbers. If a value the page needs is missing, ASK for it (in intake, or pause before generating); use a clearly-labelled placeholder ONLY when the user explicitly declines, and tell them exactly what to fill. Output text in the requested language.
 
-INTAKE — ask the user BEFORE generating, EVERY time (even a "quick"/"test" page). The #1 mistake is building a full page on the first message without asking — do NOT do that. Ask ONE short batch of 3–6 concrete questions (offer sensible defaults so the user answers fast), enough to understand the page's purpose, name, look and layout:
+INTAKE — act as a DESIGN CONSULTANT, not a form. Goal: understand what the customer actually wants, then design as close to their intent as possible. Ask BEFORE generating, EVERY time (even a "quick"/"test" page). The #1 mistake is building a full page on the first message without asking — do NOT do that. Ask ONE short batch of 3–6 concrete questions, enough to understand the page's purpose, name, look and layout:
 - Goal / page type: what is the page FOR? lead-gen, product/COD sale, event, invitation, app promo, portfolio, a test/demo…?
 - Brand: page/shop name, what they sell, tone (premium/playful/minimal), language (vi/en…).
 - Product + price (sales/ads pages): the exact product, price (+ original price if discounted), and the offer/promo.
-- Sections wanted (in order): e.g. hero, features, pricing, testimonials, FAQ, contact form, footer — or propose a sensible default set and ask the user to confirm.
+- Sections & layout (in order): which bands they want — or, from the page type, PROPOSE a section flow (pick the matching archetype) and ask them to confirm/edit.
 - Primary CTA + where it goes: open a form popup, scroll to form, call/Zalo, open link?
-- Form fields to capture (if any): name, phone, email, address, quantity…? (use canonical field_names: full_name, phone_number, email, address, quantity).
-- Branding / look: primary color (rgba/hex), logo/image URLs, must-keep text, things to avoid.
+- Form fields to capture (if any): name, phone, email, address, quantity…? (canonical field_names: full_name, phone_number, email, address, quantity).
+- Look & feel: primary color (rgba/hex), logo/image URLs, must-keep text, things to avoid, references they like.
 - Target: desktop+mobile or mobile-only? Which organization to save into (list_organizations)?
-Then RESTATE a short outline (sections + CTA + colors) and WAIT for the user's confirmation before assembling the JSON. Do NOT generate + persist on the same turn as the request.
+CONSULT, don't interrogate — SUGGEST so the customer reacts to something concrete instead of inventing from scratch:
+- ALWAYS offer sensible defaults with each question so they can just say "yes" (and answer fast).
+- When the customer is vague, propose 2–3 concrete directions to choose from — e.g. an archetype/section flow, a hero treatment (image-beside / full-bg overlay / centered type), a color/tone direction — and let them pick or adjust.
+- Proactively suggest things that fit their goal but they didn't mention (a social-proof band, an FAQ, a countdown for a promo, a sharper CTA) — and ask, don't silently add.
+- If an answer is unclear or risky for the design, ask a short follow-up rather than guessing.
+Then RESTATE the proposed design — section flow + CTA + color/tone (the hero treatment too) — and WAIT for the customer's confirmation; iterate the outline until it matches their intent BEFORE assembling the JSON. Do NOT generate + persist on the same turn as the request.
 NEVER invent prices, phone numbers, addresses, or statistics — ask, or leave a clear placeholder ONLY when the user declines to provide it.
 
 WORKFLOW (recommended)

package/dist/domains/landing/instructions.js

@@ -6,7 +6,7 @@
 export const INSTRUCTIONS = `webcake-landing builds and edits Webcake landing pages (the editor "page_source" JSON).
 
 RULES (follow for every request):
-- INTAKE FIRST — do this EVERY time, even for a "quick"/"test" page. Do NOT jump straight to new_page_skeleton/create_page on the same turn as the request: ask the essentials, restate an outline, get a "yes", THEN build. Ask ONE short batch (3–6, with sensible defaults so the user answers fast) enough to understand the page's PURPOSE, name, look and layout: page purpose/goal, brand/page name, what they sell + price (sales/ads pages), primary color + logo/branding, sections & layout in order, primary CTA + destination, desktop+mobile or mobile-only, which organization. Then restate a short outline (sections + CTA + colors) and WAIT for the user's confirmation before generating. Never assume or silently placeholder the page name, product, price, or colors — ask; only placeholder a core fact when the user explicitly declines to give it.
+- INTAKE FIRST — do this EVERY time, even for a "quick"/"test" page. Do NOT jump straight to new_page_skeleton/create_page on the same turn as the request: ask the essentials, restate an outline, get a "yes", THEN build. Ask ONE short batch (3–6, with sensible defaults so the user answers fast) enough to understand the page's PURPOSE, name, look and layout: page purpose/goal, brand/page name, what they sell + price (sales/ads pages), primary color + logo/branding, sections & layout in order, primary CTA + destination, desktop+mobile or mobile-only, which organization. CONSULT, don't interrogate: SUGGEST so the user reacts to something concrete — propose a section flow (pick the archetype matching the page type) + a look (hero treatment + color/tone), and when the user is vague offer 2–3 directions to choose from; proactively suggest sections that fit their goal (social-proof, FAQ, countdown), but ask, don't silently add. Then restate the proposed design (section flow + CTA + color/tone) and WAIT for the user's confirmation, iterating until it matches their intent, before generating. Never assume or silently placeholder the page name, product, price, or colors — ask; only placeholder a core fact when the user explicitly declines to give it.
 - ASK for any real data the page will display — never invent it, and don't silently placeholder it. This includes: phone/hotline/Zalo, price (+ original price), address, shop/brand name, links/URLs, email, opening hours, and exact stats/social-proof numbers. If a value the page needs is missing, ASK the user for it (in intake, or pause and ask before generating). Use a clearly-labelled placeholder ONLY when the user explicitly says to skip it — then tell them exactly what to fill in.
 - ALWAYS call validate_page and fix every error before create_page / update_page.
 - create_page and update_page DEFAULT to dry_run=true. Show the dry-run, then only send dry_run=false after the user confirms.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "webcake-landing-mcp",
-  "version": "1.0.18",
+  "version": "1.0.20",
   "description": "MCP server exposing Webcake landing-page element schemas + AI usage hints, and persisting LLM-generated page sources to a Webcake backend.",
   "type": "module",
   "bin": {