webcake-landing-mcp 1.0.45 → 1.0.46

package/dist/changelog.json

@@ -1,4 +1,11 @@
 [
+  {
+    "v": "1.0.46",
+    "d": "09/06/2026",
+    "type": "Changed",
+    "en": "validate_page now emits an advisory warning when no section, button, or text on the page carries a non-neutral color (white, black, or grey),…",
+    "vi": "validate_page nay phát cảnh báo tư vấn khi không có section, button hay text nào trên trang mang màu thực sự (không phải trắng, đen hoặc xám), giúp…"
+  },
   {
     "v": "1.0.45",
     "d": "09/06/2026",
@@ -33,12 +40,5 @@
     "type": "Changed",
     "en": "get_generation_guide and server instructions now require the agent to write all page copy in the same language the user is chatting in, with full,…",
     "vi": "get_generation_guide và hướng dẫn server nay yêu cầu agent viết toàn bộ nội dung trang bằng cùng ngôn ngữ người dùng đang nhắn tin, với đầy đủ dấu…"
-  },
-  {
-    "v": "1.0.40",
-    "d": "09/06/2026",
-    "type": "Added",
-    "en": "New ingest_html tool parses an HTML string into a compact reference AST (~2–5KB) that classifies sections by role (header, hero, features, form,…",
-    "vi": "Công cụ ingest_html mới phân tích cú pháp một chuỗi HTML thành AST tham chiếu thu gọn (~2–5KB) phân loại các section theo vai trò (header, hero,…"
   }
 ]

package/dist/domains/landing/guide.js

@@ -84,7 +84,7 @@ PREMIUM CRAFT (what separates a polished page from an amateur one — apply to E
 - CTA WEIGHT: the primary button is the heaviest thing on its band — accent background, bold label, generous padding (height ~46–52), the same radius used everywhere else.
 
 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.
+- Each section is one visual band: height that comfortably holds its content (taller on mobile since things stack), and a background that contrasts its text. SET responsive.<bp>.styles.background ON EVERY SECTION (both breakpoints) — the section factory default has NO background, so a section you leave unset renders transparent/white and the whole page looks colorless. Pull each band's background from the locked PALETTE and alternate them (light / tinted / dark) so consecutive bands read as distinct, never a flat white wall.
 - HEADER — logo/brand at the page's LEFT margin (left=80 desktop / 20 mobile), nav/CTA flush to the RIGHT margin (its left = canvas − margin − width, so its right edge lands on 880 desktop / 400 mobile). Use the SAME margin as every section below — do NOT center the logo or invent a new left; a header on a different axis than the bands under it is the #1 header defect. Put every header child on ONE shared vertical centerline: match top + height/2 across the logo, brand text, and CTA button so nothing sits higher/lower than the rest.
 - 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.
@@ -126,12 +126,15 @@ WORKFLOW (recommended)
 0. INTAKE (never skip — even for a quick/test page): ask the essentials above, WAIT for the answers, restate a short outline (sections + CTA + colors), and get the user's "yes" BEFORE any new_page_skeleton / create_page. Do not generate on the same turn as the request.
 0b. LOCK THE DESIGN SYSTEM (after the customer confirms): commit the exact palette, type scale, spacing scale, and component specs (see DESIGN SYSTEM) — these are your tokens for every element below. Set settings.fontGeneral to the chosen font.
 1. Call get_generation_guide (this) once, then new_page_skeleton for the top-level shape.
-2. BATCH the reads: call get_element ONCE with every type you'll use ({types:[…]}) to learn their specials + examples, and search_images ONCE with one query per image slot ({queries:[…]}). Don't call them per-type/per-image. (new_element is OPTIONAL — compact authoring (id + type + responsive styles + specials) is enough; skip it unless you want a skeleton.) Use placehold.co ONLY when search_images returns ok:false.
-3. Assemble { page, popup, settings, options, cartConfigs } in one pass.
-4. To save: call list_organizations, show the orgs and ask which to use (default to is_default). Then call create_page directly with dry_run=false (it validates internally and BLOCKS on errors — no separate validate_page round-trip, no dry-run pre-pass). Use dry_run=true / a standalone validate_page only when the request is ambiguous, the user asks to preview, or you assembled a source you are not persisting this turn. Fix every error before the real write.
+2. For each element type you'll use, call get_element to learn its specials & see an example.
+3. Optionally call new_element to get a correct skeleton, then fill specials + coordinates.
+3b. For every image the page needs (hero, product, about, feature, gallery), call search_images and put a returned URL into specials.src / gallery item.link. Use placehold.co ONLY when search_images returns ok:false.
+4. Assemble { page, popup, settings, options, cartConfigs }.
+5. Call validate_page and fix every error.
+6. To save: call list_organizations, show the orgs to the user and ask which to use (default to is_default). Then create_page (dry_run first, then dry_run:false with the chosen organization_id).
 
 EDITING an existing page
 - list_pages → let the user pick (or take a page_id from a URL).
 - get_page(page_id) → you get the live { page, popup, settings, ... }. Edit it surgically: change only the elements the user asked for (text/styles/specials/events); keep every other element, its id, and coordinates intact. Never regenerate the whole tree for a small change.
 - To add an element: build it with new_element, give it a unique id, set top/left/width/height inside the right section's children.
-- update_page(page_id, source) directly with dry_run=false (it validates + blocks on errors — no separate validate_page or dry-run pre-pass needed). Use dry_run=true only to preview an overwrite of significant existing content.`;
+- validate_page → update_page(page_id, source) (dry_run first, then dry_run:false).`;

package/dist/domains/landing/instructions.js

@@ -9,9 +9,9 @@ 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. 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.
 - LANGUAGE: write ALL page copy in the SAME language the user is chatting in, with FULL, CORRECT diacritics/accents. For Vietnamese, every word MUST carry its proper dấu (e.g. "Trân Trọng Kính Mời", "Ngày 15 Tháng 08 Năm 2025") — NEVER emit accent-stripped "không dấu" text. Never romanize or drop accent marks from any language.
-- VALIDATION IS BUILT IN — create_page / update_page / add_section all validate the source themselves and BLOCK on errors (a dry_run=true call IS the validator: it validates + returns warnings without writing). So do NOT spend a separate validate_page round-trip before persisting — go straight to the persist call. Call validate_page on its own ONLY when you assemble a source you are NOT about to persist this turn (e.g. an intermediate check). Either way, fix every error before the real write.
+- ALWAYS call validate_page and fix every error before create_page / update_page.
 - BUILD THE SOURCE IN ONE PASS — gather everything you need BEFORE assembling the source, then build the FULL tree once. BATCH the reads: when a section needs several element types (section + text-block + image-block + button + form + input), call get_element({types:[…]}) ONCE instead of one call per type — same for images, call search_images({queries:[…]}) ONCE with one query per image slot (it dedups + parallelizes and returns one best photo per query). Do NOT interleave get_element calls between create_page previews and rebuild. create_page/update_page take the entire source as input, so each call re-ships the whole page — re-previewing repeatedly wastes the request.
-- create_page and update_page DEFAULT to dry_run=true (a safety net for ambiguous requests). When the user's intent is clear, call with dry_run=false DIRECTLY (one call): the persist tools validate internally and block on errors, so the dry-run round-trip buys nothing here. Use dry_run=true only when (a) the request is ambiguous about target/content, (b) the user explicitly asks to "preview" or "xem trước", (c) this is an update_page that overwrites significant existing content, or (d) you genuinely need to inspect the redacted payload. Never loop dry-runs to "check" the source — the dry-run is itself the validator. Do not run dry-run then dry-run again before the real write, and do not add a separate validate_page call in front of it.
+- create_page and update_page DEFAULT to dry_run=true (a safety net for ambiguous requests). When the user's intent is clear AND validate_page already passed (no errors), SKIP the dry-run and call with dry_run=false directly — saves one round-trip. Use dry_run=true only when (a) the request is ambiguous about target/content, (b) the user explicitly asks to "preview" or "xem trước", (c) this is an update_page that overwrites significant existing content, or (d) you genuinely need to inspect the redacted payload. Never loop dry-runs to "check" the source — validate_page is the validator. Do not run dry-run then dry-run again before the real write.
 - LARGE PAGES (4+ sections) — build INCREMENTALLY to avoid the giant single create_page payload that can drop the connection: create_page with a SMALL skeleton (empty/near-empty page) to get a page_id, then call add_section once per section (each call ships ONLY that section; the backend appends it server-side and rejects duplicate ids — no whole-source get+put). Small pages can still go in one create_page pass.
 - EDIT existing pages surgically: find_pages (locate the page by name/domain/id when you don't already have a page_id) → get_page → change ONLY what was asked → keep every other element, its id, and coordinates → validate_page → update_page. Never regenerate the whole tree for a small change.
 - Organizations: call list_organizations and ask which to use; default to the is_default org. Endpoints are owner-scoped (only the account's own pages).

package/dist/domains/landing/validate.js

@@ -57,6 +57,45 @@ function num(v) {
     }
     return undefined;
 }
+/**
+ * True when a CSS color string carries real hue — i.e. NOT white/black/grey/
+ * transparent. Used to flag a page that ships with no color at all (every band
+ * white/neutral, no accent), which renders flat/"colorless". A gradient or image
+ * background counts as color. Neutrals (white/black/grey) have ~0 channel spread.
+ */
+function isVividColor(v) {
+    if (typeof v !== "string")
+        return false;
+    const s = v.trim().toLowerCase();
+    if (!s || s === "transparent" || s === "none" || s === "inherit")
+        return false;
+    if (s.includes("gradient") || s.startsWith("url("))
+        return true;
+    let r, g, b, a = 1;
+    const rgba = s.match(/rgba?\(([^)]+)\)/);
+    if (rgba) {
+        const parts = rgba[1].split(",").map((x) => parseFloat(x.trim()));
+        [r, g, b] = parts;
+        if (parts.length >= 4 && Number.isFinite(parts[3]))
+            a = parts[3];
+    }
+    else {
+        const hex = s.match(/^#([0-9a-f]{3}|[0-9a-f]{6})$/);
+        if (!hex)
+            return false;
+        let h = hex[1];
+        if (h.length === 3)
+            h = h[0] + h[0] + h[1] + h[1] + h[2] + h[2];
+        r = parseInt(h.slice(0, 2), 16);
+        g = parseInt(h.slice(2, 4), 16);
+        b = parseInt(h.slice(4, 6), 16);
+    }
+    if (![r, g, b].every((n) => Number.isFinite(n)))
+        return false;
+    if (a <= 0.05)
+        return false; // fully transparent
+    return Math.max(r, g, b) - Math.min(r, g, b) >= 16; // channel spread ⇒ has hue
+}
 /** Accept an object or a JSON string. Returns the parsed page or throws. */
 export function coercePage(input) {
     if (typeof input === "string")
@@ -90,6 +129,9 @@ export function validatePage(input) {
     // form nodes — used to check field_name uniqueness within each form's scope
     const forms = [];
     let elementCount = 0;
+    // Whether ANY element (section, button, text…) carries real color on either
+    // breakpoint. A page where this stays false renders flat/colorless (warned once).
+    let anyVividColor = false;
     const topList = Array.isArray(page?.page)
         ? page.page
         : page?.page
@@ -117,6 +159,20 @@ export function validatePage(input) {
         if (!node.responsive?.desktop || !node.responsive?.mobile) {
             errors.push(`${path} (${type}): must have responsive.desktop AND responsive.mobile.`);
         }
+        // does this element put any real color on the page? (background / text / border)
+        if (!anyVividColor) {
+            for (const bp of ["desktop", "mobile"]) {
+                const st = node.responsive?.[bp]?.styles;
+                if (st &&
+                    (isVividColor(st.background) ||
+                        isVividColor(st.backgroundColor) ||
+                        isVividColor(st.color) ||
+                        isVividColor(st.borderColor))) {
+                    anyVividColor = true;
+                    break;
+                }
+            }
+        }
         // children only on containers
         if (Array.isArray(node.children) && node.children.length > 0 && type && !CONTAINER_TYPES.has(type)) {
             errors.push(`${path} (${type}): has children but "${type}" is not a container type.`);
@@ -383,6 +439,12 @@ export function validatePage(input) {
             warnings.push(`Sections start on different left margins (${list}). Put every band's left-anchored content (the header logo included) on ONE shared left axis — e.g. left=${minEdge} desktop — so the page reads aligned, not ragged. This is the #1 header-misalignment defect.`);
         }
     }
+    // 3c) Colorless page — nothing on the page carries real color (every band/button/
+    //     heading is white/black/grey). Sections have NO default background, so a page
+    //     that never sets one renders as a flat white wall. Advisory only.
+    if (topList.length >= 2 && elementCount >= 3 && !anyVividColor) {
+        warnings.push(`Page has no color — no section background, button, or text uses a non-neutral color, so it renders as a flat white/grey wall. Set responsive.<bp>.styles.background on each section (alternate light/tinted/dark from the palette) and give the primary CTA an accent background. If a stark black-and-white look is intentional, ignore this.`);
+    }
     popups.forEach((p, i) => {
         const ds = p?.responsive?.desktop?.styles ?? {};
         const ms = p?.responsive?.mobile?.styles ?? {};

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "webcake-landing-mcp",
-  "version": "1.0.45",
+  "version": "1.0.46",
   "description": "MCP server exposing Webcake landing-page element schemas + AI usage hints, and persisting LLM-generated page sources to a Webcake backend.",
   "mcpName": "io.github.vuluu2k/webcake-landing-mcp",
   "type": "module",