@sudajs/cli 0.13.1 → 0.13.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sudajs/cli",
-  "version": "0.13.1",
+  "version": "0.13.3",
   "type": "module",
   "bin": {
     "suda": "./bin/suda.js"
@@ -34,7 +34,7 @@
     "react": "^19.2.7",
     "react-dom": "^19.2.7",
     "zod": "^3.24.1",
-    "@sudajs/theme-engine": "5.1.1"
+    "@sudajs/theme-engine": "5.1.3"
   },
   "devDependencies": {
     "@tailwindcss/postcss": "^4.3.0",

package/templates/theme/AGENTS.md

@@ -71,6 +71,28 @@ one pass:
 8. Run `pnpm typecheck`, `pnpm lint`, `pnpm build`, and `pnpm validate` before
    handoff.
 
+Rendering fallback rule:
+
+- Defaults belong in `defaultProps`, starter page data, or CMS template data.
+  During render, read values directly from props. Do not add fallback display
+  values with `||`, `??`, or ternaries unless the fallback is truly required for
+  runtime safety.
+- This is wrong because render invents content that is not in props:
+
+```tsx
+<div>{props.title || "title"}</div>
+```
+
+- This is correct because render only displays the authored prop value:
+
+```tsx
+<div>{props.title}</div>
+```
+
+- Conditional rendering is fine when absence intentionally removes optional UI,
+  such as hiding an optional image, button, or eyebrow. Do not use conditional
+  rendering to substitute placeholder copy, labels, links, or menu items.
+
 Configure ordinary fields like this:
 
 ```ts
@@ -143,6 +165,145 @@ Field source of truth:
   `range`, `spacing`, `media`, `image`, `video`, and `posts`. These are valid
   in `fields` and are normalized by `@sudajs/theme-engine`.
 
+## Navigation and footer menus
+
+Navigation and footer menus must be typed arrays. Do not use the legacy menu
+field type, multiline text areas, or newline-delimited strings to model menus.
+Every link destination must use a `url` field type, never a plain `text` field.
+The `fields`, TypeScript props, and `defaultProps` data structures must match
+exactly.
+
+Navigation supports at most two levels:
+
+- `navItems[]`
+- `navItems[].submenu[]`
+
+Submenu items may contain only text and link fields. Do not add another nested
+submenu field inside `navItems[].submenu[]`; the field shape must make third
+levels impossible. An empty `submenu` array means the item is an ordinary
+top-level link.
+
+The simplest Navigation field shape is:
+
+```ts
+type NavSubItem = {
+  label: string;
+  href: string;
+};
+
+type NavItem = {
+  label: string;
+  href: string;
+  submenu: NavSubItem[];
+};
+
+const navItemsField = {
+  type: "array",
+  label: t("common.fields.navigationItems"),
+  getItemSummary: (item: NavItem) => item.label || "Navigation item",
+  defaultItemProps: {
+    label: "Home",
+    href: "/",
+    submenu: [],
+  },
+  arrayFields: {
+    label: {
+      type: "text",
+      label: t("common.fields.label"),
+    },
+    href: {
+      type: "url",
+      label: t("common.fields.link"),
+    },
+    submenu: {
+      type: "array",
+      label: t("common.fields.submenu"),
+      getItemSummary: (item: NavSubItem) => item.label || "Submenu item",
+      arrayFields: {
+        label: {
+          type: "text",
+          label: t("common.fields.label"),
+        },
+        href: {
+          type: "url",
+          label: t("common.fields.link"),
+        },
+      },
+    },
+  },
+};
+
+const defaultNavItems: NavItem[] = [
+  {
+    label: "Home",
+    href: "/",
+    submenu: [],
+  },
+  {
+    label: "Company",
+    href: "/company",
+    submenu: [
+      {
+        label: "About",
+        href: "/about",
+      },
+    ],
+  },
+];
+```
+
+Footer grouped menus use two array levels:
+
+- `columns[]`
+- `columns[].links[]`
+
+Use this prop shape and mirror it exactly in the field config and defaults:
+
+```ts
+type FooterColumn = {
+  title: string;
+  links: {
+    text: string;
+    url: string;
+  }[];
+};
+
+const footerColumnsField = {
+  type: "array",
+  label: t("common.fields.columns"),
+  getItemSummary: (item: FooterColumn) => item.title || "Footer column",
+  defaultItemProps: {
+    title: "Company",
+    links: [{ text: "About", url: "/about" }],
+  },
+  arrayFields: {
+    title: {
+      type: "text",
+      label: t("common.fields.title"),
+    },
+    links: {
+      type: "array",
+      label: t("common.fields.links"),
+      getItemSummary: (item: FooterColumn["links"][number]) => item.text || "Footer link",
+      defaultItemProps: {
+        text: "About",
+        url: "/about",
+      },
+      arrayFields: {
+        text: {
+          type: "text",
+          label: t("common.fields.label"),
+        },
+        url: {
+          type: "url",
+          label: t("common.fields.link"),
+        },
+      },
+    },
+  },
+};
+```
+
 Use these field patterns:
 
 ```ts
@@ -236,8 +397,6 @@ defaultProps: {
   download: "",
   icon: "sparkles",
   accentColor: "#2563eb",
-  font: "system",
-  links: [{ label: "Home", url: "/" }],
   spacing: "md",
   postList: { strategy: "featured", limit: 3 },
   badge: { label: "New", tone: "primary" },
@@ -485,6 +644,238 @@ export const Hero: SudaComponentConfig<HeroProps> = {
 - If a page section needs controlled nested content, use Suda `blockSlots`, not a hand-written Puck slot field. `blockSlots` lets the theme define exactly which local block kinds are allowed inside that section.
 - Do not use legacy DropZone or `zones` patterns.
 
+## Puck Editor Compatibility Contract
+
+Every public page and layout component must render consistently in the public
+site, the Puck Editor iframe, and editor preview mode. Build this compatibility
+in when creating the theme; do not wait for an editor-only positioning bug.
+
+### Puck mutates the real component root
+
+In edit mode Puck may attach selection and drag attributes and an inline
+position directly to the first real DOM element returned by a component:
+
+```ts
+el.setAttribute("data-puck-component", id);
+el.setAttribute("data-puck-dnd", id);
+el.style.position = "relative";
+```
+
+- Never assume `[data-puck-component]` is an external wrapper. It may be the
+  component's own `<nav>`, `<header>`, `<section>`, or `<footer>`.
+- `:has(.component-root)` does not match an element that is itself
+  `.component-root`. When both DOM shapes are possible, cover both explicitly:
+
+```css
+.component-root[data-puck-component],
+[data-puck-component]:has(.component-root) {
+  /* compatibility override */
+}
+```
+
+- Puck's inline `position: relative` beats ordinary theme CSS. A component
+  whose real root must remain `sticky`, `fixed`, or `absolute` in the editor
+  needs a specific editor-scoped rule with `!important`.
+- Never apply `position: relative !important` to every editor component. That
+  destroys navigation, overlays, and floating controls.
+
+### Stable component roots
+
+- Every public page and layout component should return one stable, semantic,
+  real DOM root. Prefer `<header>` or `<nav>` for navigation, `<footer>` for the
+  footer, and `<section>` or an explicit container for ordinary sections.
+- Do not use a Fragment as the root of a component that controls positioning,
+  margin, size, stacking, background, or editor selection. Do not depend on
+  Puck to wrap a Fragment.
+- Do not use `display: contents` on a root that needs margin, padding,
+  positioning, sticky/fixed behavior, `z-index`, background, or a selection
+  outline.
+- `PageOutlet` must render a real DOM element when it needs negative margin,
+  overlap, positioning, or sizing.
+
+### Explicit editor scope
+
+The layout root must derive editor state from
+`puck?.metadata?.isEditor === true` and expose a stable marker:
+
+```tsx
+<div className="theme-root" data-suda-editor={isEditor ? "true" : undefined}>
+  {children}
+</div>
+```
+
+Keep every editor-only compatibility rule below
+`.theme-root[data-suda-editor="true"]`. Do not globally override `.navbar`,
+`.section`, or `[data-puck-component]`, change the public-site layout to repair
+the editor, use vague selectors that affect unrelated components, or edit
+third-party minified CSS. Put compatibility overrides in the theme's scoped
+`src/styles.css`.
+
+When the component itself may be the Puck root or may sit inside one, write and
+test both selectors. Keep later rules from overriding the correction:
+
+```css
+.theme-root[data-suda-editor="true"] .theme-navigation[data-puck-component],
+.theme-root[data-suda-editor="true"]
+  [data-puck-component]:has(.theme-navigation)
+  .theme-navigation {
+  position: sticky !important;
+  top: 0;
+  z-index: 30;
+}
+```
+
+### Sticky and fixed positioning
+
+Before implementing Header, announcement bar, floating CTA, or any
+sticky/fixed component, verify all of the following:
+
+- whether Puck writes `position: relative` on the actual positioned root;
+- which element really scrolls in the site and in the editor iframe;
+- that the sticky element is inside the intended scroll container;
+- whether any ancestor has `overflow: hidden`, `auto`, `scroll`, or `clip`, or
+  has `transform`, `filter`, `perspective`, or `contain`;
+- that the sticky parent is taller than the sticky element where required;
+- that `top` and `z-index` are explicit; and
+- that iframe scrolling and the outer editor canvas do not use incompatible
+  coordinate systems.
+
+For a layout Header, prefer putting sticky behavior on the Header's real root.
+If that root receives `data-puck-component`, override Puck's inline position on
+that same node. Do not force the Header root to `relative !important` and then
+expect a parent sticky rule to work. Site and editor may use different
+positioning strategies only when their visual result remains equivalent.
+
+### Transparent navigation is state plus layout
+
+Transparent navigation must coordinate all of these concerns, not merely set
+`background: transparent`:
+
+- transparent background and removed shadow;
+- logo, menu text, and button color changes;
+- Hero or `PageOutlet` overlap beneath the Header;
+- restoration of the solid state after the scroll threshold;
+- Puck's root-node positioning mutation in the editor; and
+- identical SSR-first-frame and hydrated state.
+
+Never render a white logo/text state above an accidentally white navigation
+background. Prefer React Context for a page's transparent-navigation request,
+an SSR-readable DOM marker for the first-frame fallback, and a real
+`PageOutlet` element with negative margin in the editor. The public site may use
+a spacer or equivalent layout strategy. Keep shared measurements in CSS
+variables, for example `--theme-navigation-height: 4.6rem`.
+
+### Editor scroll detection
+
+Do not rely only on `window.scrollY` or a `window` scroll listener. The active
+scroll source may be `document.scrollingElement`, the iframe document, or an
+inner `overflow: auto/scroll` container, and `scroll` does not bubble.
+
+- Find the nearest scrollable ancestor for each navigation instance and read
+  that element's own `scrollTop`.
+- Listen on the document with
+  `document.addEventListener("scroll", handler, { capture: true, passive: true })`
+  and keep a window listener for public-site compatibility.
+- Do not assume editor and site share the same scrolling element.
+
+### React and editor runtime lifecycle
+
+Runtime code must tolerate editor remounts, live prop changes, HMR, frequent
+`MutationObserver` callbacks, React Strict Mode effect replay, and loading after
+`DOMContentLoaded` has already fired.
+
+- Make event binding and initialization idempotent.
+- Observe components inserted later and relevant attribute changes.
+- Do not use a permanent `window.__xxxBound` flag that prevents required HMR
+  reinitialization.
+- Clean up component effects, observers, and listeners.
+- Keep SSR markers and client state synchronized instead of letting them fight.
+
+### Puck interaction styles
+
+Assume edit mode may apply rules equivalent to:
+
+```css
+[data-puck-component] * {
+  pointer-events: none;
+  user-select: none;
+}
+
+[data-puck-component] {
+  pointer-events: auto !important;
+}
+```
+
+An unclickable link, dropdown, carousel, or button in edit mode is not by
+itself a theme interaction bug. Distinguish edit mode from preview mode. Never
+globally restore descendant pointer events because that breaks selection and
+dragging; test visitor interactions in editor preview and the public site.
+
+### Layout ownership
+
+- Keep only `Header`, `PageOutlet`, `Footer`, and necessary global chrome such
+  as an announcement bar in `layoutConfig`.
+- Render Header and Footer exactly once per page from the layout. Do not repeat
+  them in starter pages.
+- If Footer or Header moves from page sections into the layout, remove duplicate
+  entries from `starterPages`, `cmsTemplates`, `pageConfig.categories`, and AI
+  examples.
+- Give Header, `PageOutlet`, and Footer stable `props.id` values, with
+  `PageOutlet` between Header and Footer.
+- Read platform white-label, ICP, and other footer metadata from runtime
+  metadata; do not persist it as duplicated static component data.
+
+### Vendor CSS
+
+Do not modify original third-party minified CSS unless the task explicitly
+requires a maintained vendor patch. Use precise selectors in the theme's own
+scoped `src/styles.css`. If a vendor file truly must change, document the
+reproducible problem and why an override cannot solve it.
+
+### New-theme completion checklist
+
+When creating a theme, complete all of these in the initial implementation:
+
+- editor root marker and stable real roots;
+- layout-owned Header / `PageOutlet` / Footer with stable ids;
+- Header sticky compatibility in the editor;
+- transparent navigation in editor and site modes;
+- scrollable-ancestor detection and an SSR state marker;
+- idempotent runtime setup and cleanup;
+- real-element `PageOutlet` overlap behavior;
+- responsive viewport behavior; and
+- editor preview versus public-site comparison.
+
+### Required regression matrix
+
+Whenever Header, transparent navigation, sticky/fixed positioning,
+`PageOutlet`, Footer, carousel, dropdown/mobile menu, or a `100vh` Hero changes,
+verify:
+
+- public-site SSR first frame and post-hydration state;
+- editor desktop, tablet, and mobile viewports;
+- editor edit mode and preview mode;
+- initial top state and state after crossing the scroll threshold;
+- state after HMR and live prop updates;
+- exactly one Header and one Footer; and
+- intact Puck selection and drag behavior.
+
+### Debugging order
+
+When editor and site differ, inspect in this order before changing CSS:
+
+1. The component's actual root node.
+2. The element that received `data-puck-component`.
+3. Inline styles written on that element.
+4. Computed `position`, `background`, `z-index`, and ancestor `overflow`.
+5. The real scrolling element and its `scrollTop`.
+6. Iframe versus outer-canvas coordinate systems.
+7. Whether the theme runtime initialized.
+8. Transparent-state Context and DOM markers.
+9. Stylesheet load and cascade order.
+
+Do not guess selectors repeatedly before confirming the DOM and computed style.
+
 ## Design system rules
 
 Build every theme from one theme-level design system. Do not let each section,