@sudajs/cli 0.16.0 → 0.17.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sudajs/cli",
-  "version": "0.16.0",
+  "version": "0.17.0",
   "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": "6.0.0"
+    "@sudajs/theme-engine": "6.1.0"
   },
   "devDependencies": {
     "@tailwindcss/postcss": "^4.3.0",

package/templates/theme/AGENTS.md

@@ -2,7 +2,7 @@
 
 This directory is a standalone Vite + React + Tailwind Suda theme generated by `suda theme init`.
 
-Your job in a theme project is to create a complete, publishable theme with theme-specific components, realistic starter pages, scoped styling, assets, and AI metadata. Do not build pages by assembling generic engine components; those are reserved for end users who need supplemental editing blocks after the theme is installed.
+Your job in a theme project is to create a complete, publishable theme with theme-specific components, realistic starter pages, scoped styling, assets, and AI metadata. Do not build starter pages by assembling generic engine components. Suda adds those blocks automatically so users and AI can create supplemental content pages after the theme is installed.
 
 ## Component naming and editor organization
 
@@ -650,7 +650,7 @@ export const Hero: SudaComponentConfig<HeroProps> = {
 ## Component strategy
 
 - Create theme-specific components and sections first. Every page component should express this theme's brand, industry, visual rhythm, and content model.
-- Do not register `createEngineComponents()`, `createBaseBlocks()`, or `createContainers()` in `pageConfig.components` when creating a theme. Generic engine components are fallback editing tools for users, not the foundation of a theme template.
+- Do not register `createEngineComponents()`, `createBaseBlocks()`, or `createContainers()` in `pageConfig.components` when creating a theme. Suda automatically adds the platform base content blocks (`Text`, `Heading`, `RichText`, `Markdown`, `Image`, `Button`, and `Spacer`) to every page config. Use the single `Markdown` block for standalone long-form pages such as privacy policies, terms, legal notices, documentation, or guides that should not appear in CMS posts. Generic blocks supplement theme-specific sections; they are not the foundation of starter templates.
 - Prefer purpose-built sections such as hero, services, product highlights, feature comparisons, gallery, process, pricing, testimonial, FAQ, article list, contact, and CTA when the theme needs those patterns.
 - Keep section APIs semantic. Expose props that describe content and editor decisions, not implementation details.
 - Keep `fields`, `defaultProps`, and `render` in sync. Every editor field should have a sensible default, and render functions should tolerate omitted optional values.
@@ -1032,7 +1032,7 @@ Good component instructions explain:
 - Frequency: whether it should appear once, multiple times, or only near another section.
 - Composition: required neighboring content or local blocks, when relevant.
 
-- For icons, expose props with `{ type: "icon" }`, type values as `SudaLucideIconName`, render them with `SudaLucideIcon` from `@sudajs/theme-engine/icons`, and store canonical Lucide names such as `"rocket"` or `"mouse-pointer-click"` (not `"lucide-rocket"`). Do not keep theme-local icon maps, emoji/icon switch statements, or custom SVG icon registries unless the theme truly needs a bespoke non-Lucide graphic.
+- For icons, expose props with `{ type: "icon" }`, type values as `SudaIconName`, and render them with `SudaIcon` from `@sudajs/theme-engine/icons`. Store canonical Lucide names such as `"rocket"` or `"mouse-pointer-click"` (not `"lucide-rocket"`), or namespaced Simple Icons brand names such as `"simple-icons:github"`. Do not keep theme-local icon maps, emoji/icon switch statements, or custom SVG icon registries unless the theme truly needs a bespoke graphic.
 - Add optional field-level `ai.instructions`, `ai.required`, or `ai.exclude` when a prop needs generation guidance beyond its label and type.
 - Use `ai.exclude: true` only for structural or editor-only components, and still provide instructions explaining why AI must not generate them. `PageOutlet` is the standard example.
 

package/templates/theme/src/sections.tsx

@@ -1,7 +1,7 @@
 import type { SudaComponentConfig } from "@sudajs/theme-engine";
 import {
-  SudaLucideIcon,
-  type SudaLucideIconName,
+  SudaIcon,
+  type SudaIconName,
 } from "@sudajs/theme-engine/icons";
 import {
   getPostResource,
@@ -13,7 +13,7 @@ import {
 import { t } from "./i18n.js";
 import { themeAsset } from "./theme-asset.js";
 
-type FeatureItem = { icon?: SudaLucideIconName; title?: string; description?: string };
+type FeatureItem = { icon?: SudaIconName; title?: string; description?: string };
 type PuckExtras = { puck?: { metadata?: ThemeRenderMetadata } };
 type HeroProps = {
   showLogo?: boolean;
@@ -155,7 +155,7 @@ export const FeatureGrid: SudaComponentConfig<FeatureGridProps> = {
       >
         {features.map((feature: FeatureItem, index: number) => (
           <article className="__SUDA_THEME_KEY__-card" key={index}>
-            <SudaLucideIcon className="__SUDA_THEME_KEY__-card-icon" name={feature.icon} />
+            <SudaIcon className="__SUDA_THEME_KEY__-card-icon" name={feature.icon} />
             <h3>{feature.title}</h3>
             <p>{feature.description}</p>
           </article>