owndesign 0.1.12 → 0.2.1

package/dist/index.js

@@ -15,7 +15,7 @@ async function main(argv) {
     return;
   }
   if (options === "version") {
-    console.log("0.1.12");
+    console.log("0.2.1");
     return;
   }
   const cliRoot = path.dirname(fileURLToPath(import.meta.url));

package/dist/server/index.js

@@ -56834,14 +56834,32 @@ function createDeleteToolDefinition() {
 }
 
 // ../core/src/agent/tools/edit.ts
+var DESCRIPTION = [
+  "Performs exact string replacements in Project Workspace files.",
+  "",
+  "Usage:",
+  "- You must use the read tool before editing an existing file so you can match the current contents exactly.",
+  "- The path parameter must be a relative file path inside the Project Workspace.",
+  "- When editing text from read tool output, preserve the exact indentation after the line number prefix.",
+  "- The line number prefix format is `<line>: `. Everything after that prefix is the actual file content to match.",
+  "- Never include any part of the line number prefix in oldString or newString.",
+  "- Prefer editing existing files. Only create new files when the user request explicitly requires it.",
+  "- Only use emojis if the user explicitly requests them.",
+  "- The edit will fail if oldString is not found in the file.",
+  "- The edit will fail if oldString is found multiple times unless replaceAll is true.",
+  "- Provide more surrounding context in oldString when you need to identify one specific match.",
+  "- Use replaceAll for replacing or renaming every occurrence of a string across the file."
+].join("\n");
 function createEditToolDefinition() {
   return {
-    description: "Edit one UTF-8 text file by replacing oldString with newString. By default oldString must occur exactly once; set replaceAll to replace every occurrence.",
+    description: DESCRIPTION,
     inputSchema: external_exports.object({
-      newString: external_exports.string().describe("Replacement text."),
-      oldString: external_exports.string().describe("Text to replace."),
-      path: external_exports.string().describe("Relative file path inside the Project Workspace."),
-      replaceAll: external_exports.boolean().describe("Replace every occurrence of oldString instead of requiring exactly one match.").optional()
+      newString: external_exports.string().describe("Replacement text. Must be different from oldString."),
+      oldString: external_exports.string().describe("Exact text to replace from the current file contents."),
+      path: external_exports.string().describe("Relative file path inside the Project Workspace to modify."),
+      replaceAll: external_exports.boolean().describe(
+        "Replace every occurrence of oldString instead of requiring exactly one match. Default false."
+      ).optional()
     }).strict(),
     name: "edit",
     parallelSafe: false,
@@ -56850,12 +56868,24 @@ function createEditToolDefinition() {
 }
 
 // ../core/src/agent/tools/glob.ts
+var DESCRIPTION2 = [
+  "- Fast file pattern matching tool for the current Project Workspace.",
+  '- Supports glob patterns like "**/*.html" or "assets/*.{css,js}".',
+  "- Returns matching Project Workspace relative file and directory paths.",
+  "- Use this tool when you need to find files by name patterns.",
+  "- The optional path parameter must be a relative directory path inside the Project Workspace.",
+  "- You can call multiple read, glob, and grep tools in parallel when several searches are useful."
+].join("\n");
 function createGlobToolDefinition() {
   return {
-    description: "Find files and directories in the current Project Workspace by glob pattern, sorted by most recently modified first.",
+    description: DESCRIPTION2,
     inputSchema: external_exports.object({
-      path: external_exports.string().describe("Optional relative directory path inside the Project Workspace to search from.").optional(),
-      pattern: external_exports.string().describe('Glob pattern such as "**/*.html", "assets/*.{css,js}", or "index.html".')
+      path: external_exports.string().describe(
+        "Optional relative directory path inside the Project Workspace to search from. Omit this field to search from the workspace root."
+      ).optional(),
+      pattern: external_exports.string().describe(
+        'Glob pattern to match Project Workspace files against, such as "**/*.html", "assets/*.{css,js}", or "index.html".'
+      )
     }).strict(),
     name: "glob",
     parallelSafe: true,
@@ -56866,15 +56896,26 @@ function createGlobToolDefinition() {
 }
 
 // ../core/src/agent/tools/grep.ts
+var DESCRIPTION3 = [
+  "- Fast content search tool for UTF-8 text files in the current Project Workspace.",
+  "- Searches file contents using JavaScript regular expressions.",
+  '- Supports regex patterns such as "log.*Error" or "function\\s+\\w+".',
+  '- Filter files by pattern with the include parameter, such as "*.html" or "**/*.{css,js}".',
+  "- Returns Project Workspace relative file paths and line numbers with matching lines.",
+  "- Use this tool when you need to find files containing specific patterns.",
+  "- Use a more specific path or include pattern if the result is too broad or truncated."
+].join("\n");
 function createGrepToolDefinition() {
   return {
-    description: "Search UTF-8 text files in the current Project Workspace using a JavaScript regular expression.",
+    description: DESCRIPTION3,
     inputSchema: external_exports.object({
-      include: external_exports.string().describe('Optional file glob to include, such as "*.html" or "**/*.{css,js}".').optional(),
+      include: external_exports.string().describe(
+        'Optional Project Workspace file glob to include, such as "*.html" or "**/*.{css,js}".'
+      ).optional(),
       path: external_exports.string().describe(
-        "Optional relative file or directory path inside the Project Workspace to search."
+        "Optional relative file or directory path inside the Project Workspace to search. Omit this field to search the workspace root."
       ).optional(),
-      pattern: external_exports.string().describe("JavaScript regular expression pattern to search for.")
+      pattern: external_exports.string().describe("JavaScript regular expression pattern to search for in file contents.")
     }).strict(),
     name: "grep",
     parallelSafe: true,
@@ -56887,43 +56928,6 @@ function createGrepToolDefinition() {
   };
 }
 
-// ../core/src/agent/tools/patch.ts
-function createPatchToolDefinition() {
-  return {
-    description: "Apply coordinated UTF-8 file changes inside the current Project Workspace. Supports add/write, edit, and delete changes.",
-    inputSchema: external_exports.object({
-      changes: external_exports.array(
-        external_exports.discriminatedUnion("operation", [
-          external_exports.object({
-            content: external_exports.string().describe("Complete file content for add operations."),
-            operation: external_exports.literal("add"),
-            path: external_exports.string().describe("Relative file or directory path inside the Project Workspace.")
-          }).strict(),
-          external_exports.object({
-            content: external_exports.string().describe("Complete file content for write operations."),
-            operation: external_exports.literal("write"),
-            path: external_exports.string().describe("Relative file or directory path inside the Project Workspace.")
-          }).strict(),
-          external_exports.object({
-            newString: external_exports.string().describe("Replacement text for edit operations."),
-            oldString: external_exports.string().describe("Text to replace for edit operations."),
-            operation: external_exports.literal("edit"),
-            path: external_exports.string().describe("Relative file or directory path inside the Project Workspace."),
-            replaceAll: external_exports.boolean().describe("For edit operations, replace every occurrence of oldString.").optional()
-          }).strict(),
-          external_exports.object({
-            operation: external_exports.literal("delete"),
-            path: external_exports.string().describe("Relative file or directory path inside the Project Workspace.")
-          }).strict()
-        ])
-      ).min(1)
-    }).strict(),
-    name: "patch",
-    parallelSafe: false,
-    execute: async ({ changes }, { projectId, workspaceStore }) => workspaceStore.applyProjectWorkspacePatch(projectId, changes)
-  };
-}
-
 // ../core/src/realtime/frontend-command-bus.ts
 var KEEPALIVE_INTERVAL_MS = 15e3;
 var FrontendCommandBus = class {
@@ -57066,9 +57070,25 @@ function createPreviewRefreshToolDefinition() {
 }
 
 // ../core/src/agent/tools/read.ts
+var DESCRIPTION4 = [
+  "Read a file or directory from the current Project Workspace. If the path does not exist, an error is returned.",
+  "",
+  "Usage:",
+  "- The path parameter must be a relative file or directory path inside the Project Workspace.",
+  "- By default, this tool returns up to 2000 lines or directory entries from the start of the target.",
+  "- The offset parameter is the line number or directory-entry number to start from (1-indexed).",
+  "- To read later sections, call this tool again with a larger offset.",
+  "- Use the grep tool to find specific content in large files or files with long lines.",
+  "- If you are unsure of the correct path, use the glob tool to look up filenames by glob pattern.",
+  "- File contents are returned with each line prefixed by its line number as `<line>: <content>`.",
+  "- Directory entries are returned as Project Workspace relative paths.",
+  "- Long lines and large files may be truncated. Use offset and limit to inspect the needed section.",
+  "- Call this tool in parallel when you know there are multiple files you want to read.",
+  "- Avoid tiny repeated slices. If you need more context, read a larger window."
+].join("\n");
 function createReadToolDefinition() {
   return {
-    description: "Read one UTF-8 file or directory from the current Project Workspace. Files are returned with 1-indexed line numbers.",
+    description: DESCRIPTION4,
     inputSchema: external_exports.object({
       limit: external_exports.number().describe("Maximum number of lines or directory entries to read. Defaults to 2000.").optional(),
       offset: external_exports.number().describe(
@@ -57088,12 +57108,24 @@ function createReadToolDefinition() {
 }
 
 // ../core/src/agent/tools/write.ts
+var DESCRIPTION5 = [
+  "Writes a file in the current Project Workspace.",
+  "",
+  "Usage:",
+  "- This tool will overwrite the existing file if there is one at the provided path.",
+  "- The path parameter must be a relative file path inside the Project Workspace.",
+  "- If this is an existing file, you must use the read tool first to read the file contents.",
+  "- Prefer editing existing files with the edit tool. Only write full files when intentional.",
+  "- Do not use write to create the initial index.html; use createHtml first.",
+  "- Never proactively create documentation files (*.md) or README files. Only create documentation files if explicitly requested by the user.",
+  "- Only use emojis if the user explicitly requests them."
+].join("\n");
 function createWriteToolDefinition() {
   return {
-    description: "Create or overwrite one UTF-8 text file in the current Project Workspace.",
+    description: DESCRIPTION5,
     inputSchema: external_exports.object({
-      content: external_exports.string().describe("Complete UTF-8 text file content."),
-      path: external_exports.string().describe("Relative file path inside the Project Workspace.")
+      content: external_exports.string().describe("Complete UTF-8 text file content to write."),
+      path: external_exports.string().describe("Relative file path inside the Project Workspace to create or overwrite.")
     }).strict(),
     name: "write",
     parallelSafe: false,
@@ -57110,7 +57142,6 @@ function createProjectWorkspaceToolDefinitions() {
     createEditToolDefinition(),
     createGlobToolDefinition(),
     createGrepToolDefinition(),
-    createPatchToolDefinition(),
     createPreviewRefreshToolDefinition(),
     createReadToolDefinition(),
     createWriteToolDefinition()
@@ -57179,7 +57210,7 @@ function buildFrontendCapabilityPrompt() {
 }
 
 // ../core/src/agent/design-page-agent.ts
-var DESIGN_PAGE_AGENT_PROMPT_VERSION = 1;
+var DESIGN_PAGE_AGENT_PROMPT_VERSION = 3;
 var AiSdkDesignPageAgent = class {
   constructor(workspaceStore) {
     this.workspaceStore = workspaceStore;
@@ -57337,12 +57368,10 @@ function buildDesignPageConversationInstructions(resources) {
       tag: "frontend_capabilities",
       content: buildFrontendCapabilityPrompt()
     },
-    ...resources ? [
-      {
-        tag: "resource_policy",
-        content: buildResourcePolicyPrompt(resources)
-      }
-    ] : []
+    {
+      tag: "resource_policy",
+      content: resources ? buildResourcePolicyPrompt(resources) : buildResourcePolicyFallbackPrompt()
+    }
   ];
   return renderDesignPromptSections(sections);
 }
@@ -57386,7 +57415,6 @@ function buildToolWorkflowPrompt() {
     "Choose tools by intent:",
     "- Use `createHtml` only to create a missing `index.html` file.",
     "- Use `edit` for small, focused replacements in one existing file.",
-    "- Use `patch` for coordinated changes or repeated replacements.",
     "- Use `write` only for deliberate full-file replacement of `index.html`.",
     "- Do not use `write` to create the initial `index.html`; use `createHtml` first.",
     "- Use `copyFile` only when the current user message explicitly asks you to duplicate an existing file.",
@@ -57397,7 +57425,8 @@ function buildToolWorkflowPrompt() {
     "- When `index.html` exists, read it before editing and do not call `createHtml`.",
     "",
     "Recover from tool failures:",
-    "- If an edit fails, read the file again and retry with a smaller edit or patch.",
+    "- If an edit fails, read the file again and retry with a smaller, exact edit.",
+    "- If repeated focused edits would be more fragile than replacing the file, use `write` for an intentional full-file replacement.",
     "- If a generated prototype becomes too large or brittle, simplify the file while preserving visible quality."
   ].join("\n");
 }
@@ -57429,6 +57458,17 @@ function buildResourcePolicyPrompt(resources) {
     "Use regular inline CSS as the primary styling method."
   ].join("\n");
 }
+function buildResourcePolicyFallbackPrompt() {
+  return [
+    "## Resource Policy",
+    "No global resource settings were provided for this run.",
+    "Use resources already present in the existing `index.html` or the default HTML template.",
+    "Prefer local CSS and built-in browser capabilities before adding any external resource.",
+    "Do not add a new font, icon, image, script, or CDN dependency unless the user explicitly requests it or it is necessary for prototype quality.",
+    "If no icon library is configured, use text labels or simple CSS shapes instead of assuming a specific icon system.",
+    "Use regular inline CSS as the primary styling method."
+  ].join("\n");
+}
 function getDefaultResourceLibrary(libraries) {
   return libraries.find((library) => library.isDefault) ?? libraries[0];
 }

package/dist/server/prompts/agents/component-audit.md

@@ -2,7 +2,7 @@
 
 You are a read-only design consistency auditor for OwnDesign HTML workspaces.
 Inspect the final workspace state after the main design agent finishes a user task.
-Use only read, glob, and grep tools. Never edit files and never ask to call write, edit, patch, createHtml, delete, copyFile, preview tools, or syncSharedComponent yourself.
+Use only read, glob, and grep tools. Never edit files and never ask to call write, edit, createHtml, delete, copyFile, preview tools, or syncSharedComponent yourself.
 
 Return JSON only with this shape:
 {"passed": boolean, "findings": [{"type": string, "severity": "high" | "medium" | "low", "message": string, "path"?: string, "recommendedAction"?: string}], "summary": string}

package/dist/server/prompts/agents/design-page.md

@@ -1,54 +1,67 @@
 # OwnDesign Single HTML Page Agent
 
-You design and implement high-quality previewable page prototypes in a single `index.html` file inside the Project Workspace.
+You are OwnDesign's single HTML page design agent. You turn a user's product idea, redesign request, or interface change into one polished, previewable `index.html` prototype inside the Project Workspace.
 
-The user's result is judged by what appears in the Preview Pane iframe. A task is complete only when `index.html` renders an intentional, polished, useful interface prototype, not merely valid markup.
+The user's result is judged by what appears in the Preview Pane iframe. A task is complete only when `index.html` communicates a coherent product experience with useful interface states, not merely valid markup.
 
-## Core Output Model
+## Identity
 
-- `index.html` is the only previewable page and the main design canvas.
-- Put the page structure, CSS, and local prototype JavaScript directly in `index.html`.
-- Do not create additional HTML pages for different screens.
-- Do not use custom elements, Shadow DOM, React, framework build files, page/component metadata files, or shared component modules.
-- For multi-page experiences, implement internal views in `index.html` using state, hash routing, tabs, buttons, or `[data-view]` sections.
+- Act as a product-minded frontend designer and implementer for a single preview canvas.
+- Stay grounded in the current project. If `index.html` exists, understand its structure, visual language, and interaction model before changing it.
+- Be decisive once the design direction is clear. Build the visible experience instead of narrating possibilities.
+- Preserve useful existing intent. Replace the whole file only when that is the cleanest way to deliver the requested result.
+
+## Operating Priorities
+
+When instructions pull in different directions, follow this order:
+
+1. The single `index.html` target, available workspace tools, configured resources, and Preview Pane constraints.
+2. The user's explicit product goal, content request, audience, and visual preferences.
+3. Domain-appropriate design judgment and prototype quality.
+4. Local consistency with the existing `index.html`.
+
+User requests guide the design intent, but they do not override the single-file target, the workspace tool boundary, the resource policy, or the requirement that the result be previewable in `index.html`.
+
+Do not inherit assumptions from general coding agents or full application builders. Use only the project workspace tools supplied to you and keep the work focused on the previewable prototype.
 
-## Work Rhythm
+## Design Judgment
 
-Before editing, make the design decision first:
+Before editing, form a compact design brief in your own reasoning:
 
-1. Identify the interface purpose, target user, primary task, and product tone.
-2. Choose one clear visual direction that fits the domain and makes the page memorable.
-3. Plan the first viewport, key workflow, primary actions, supporting content, and interaction states.
-4. When the product needs mobile support, plan the mobile structure as a real responsive layout, not as a device mockup.
-5. Then implement the design in `index.html`.
+1. What is the interface for, and what outcome should the user reach first?
+2. Who is the target user, and what level of density, guidance, and polish do they expect?
+3. What product tone fits the domain: operational, editorial, playful, premium, technical, calm, expressive, or another clear direction?
+4. What must be visible in the first viewport so the page feels useful immediately?
+5. Which interaction states will make the prototype feel alive without pretending to be a real backend product?
 
-Prefer finishing the visible page over maintaining abstractions. One coherent single file is the intended architecture.
+Choose one strong visual direction that fits the product instead of blending generic patterns. SaaS, CRM, admin, and productivity tools should be organized for scanning, comparison, and repeated action. Consumer, brand, portfolio, game, and story-driven pages may be more expressive, visual, and immersive when the user's request calls for it.
 
-## Implementation Contract
+## Single HTML Craft
 
-- Keep the whole previewable prototype in `index.html`.
+- `index.html` is the only previewable page and the main design canvas.
+- Put the page structure, CSS, and local prototype JavaScript directly in `index.html`.
+- Do not create additional HTML pages, React/Vue/Svelte apps, framework build files, custom elements, Shadow DOM, component module folders, or reuse metadata.
+- For multiple pages, screens, routes, or steps, implement internal views in `index.html` using state, hash routing, tabs, buttons, or `[data-view]` sections.
 - Use `<main id="app">` for the visible app/page body.
-- Keep CSS in the file's `<style>` block and organize it clearly: reset, tokens, layout, components, responsive rules, and motion.
-- Keep JavaScript in the file's `<script>` block and include only prototype behavior that is needed for the requested interaction.
-- For multiple screens or routes, use `[data-view]` sections with a single active state, hash/state/tab navigation, and clear button/link handlers.
-- Do not leave default template placeholders, empty sections, unfinished scripts, or dead controls.
+- Keep CSS in the file's `<style>` block and organize it clearly: reset, tokens, layout, components, states, responsive rules, and motion.
+- Keep JavaScript in the file's `<script>` block and include only prototype behavior that is needed for visible interaction.
+- Prefer one coherent, finished file over abstractions that make the prototype harder to inspect.
 
-## Design Quality
+## Frontend Taste Model
 
 Every rendered `index.html` should feel like a complete product-quality prototype:
 
 - Give the first viewport a clear visual focus and at least one useful product action or workflow entry point.
+- Let the subject matter shape the interface. Use realistic labels, domain-specific copy, representative data, and controls the target user would expect.
 - Use a deliberate visual system with clear typography, spacing, color, hierarchy, density, radius, shadow, and motion choices.
-- Use CSS variables or clear repeated values for the page's color, spacing, radius, shadow, and motion system.
-- Build realistic labels, concise content, minimal mock data, and useful interface states. Avoid lorem ipsum, vague placeholder copy, and empty marketing filler.
-- Make common workflows visible and understandable, including relevant hover, focus, active, selected, empty, loading, or error states.
-- Adapt to mobile when the interface calls for it (for example consumer-facing or touch-first products); when you do, reorganize navigation, actions, and dense content for small screens instead of only shrinking columns. Desktop-only tools do not need a mobile layout.
-- For mobile interfaces, design the real app/page layout only. Do not add simulated system status bars, notches, home indicators, phone frames, device chrome, browser chrome, or screenshot containers unless the user explicitly asks for a device mockup or app-store-style screenshot.
-- Keep text readable and prevent overflow, clipping, and accidental overlap.
-- Prefer polished, domain-specific UI over generic sections.
-- Use spatial composition intentionally: density, negative space, asymmetry, layering, or grid discipline should match the product tone.
-- Add motion, background treatment, texture, depth, hover states, and micro-interactions only when they improve the user's understanding or make the interface feel more finished.
-- Use icons, controls, data, imagery, and interaction states when they fit the user's request.
+- Use CSS variables or an obvious reusable scale for repeated colors, spacing, radii, shadows, and motion values.
+- Build with stable layout dimensions where UI elements have fixed roles, such as toolbars, boards, grids, counters, tabs, icon buttons, and cards.
+- Keep text readable and prevent overflow, clipping, accidental overlap, cramped buttons, and mobile horizontal scrolling.
+- Match display type to context. Use large type for true hero moments and tighter headings inside panels, dashboards, sidebars, and tool surfaces.
+- Show relevant hover, focus, active, selected, empty, loading, disabled, success, and error states when they help the workflow read clearly.
+- Use icons, controls, data, imagery, texture, depth, and motion when they serve the product experience. Avoid decoration that competes with comprehension.
+- Treat mobile as a real layout when the product needs it. Reorganize navigation, actions, and dense content instead of only shrinking columns.
+- For mobile interfaces, design the real app/page layout only. Do not add simulated status bars, notches, home indicators, phone frames, device chrome, browser chrome, or screenshot containers unless the user explicitly asks for a device mockup.
 
 ## Mock Data Minimalism
 
@@ -69,6 +82,18 @@ For content-heavy interfaces, use short excerpts and visual placeholders. Do not
 
 Avoid data-first implementation. Start from the visible interface structure, then add only the smallest amount of mock content needed to make the prototype convincing.
 
+## Prototype Behavior
+
+Build frontend prototypes. Interactions should demonstrate interface states, user flows, and visual feedback; they should not turn the prototype into a real browser, OS, local file tool, or business workflow unless the user explicitly asks for that capability.
+
+Good prototype interactions include active tabs, modal open/close, drawer visibility, filter chips, selected rows, toast messages, simple steppers, hash/view switching, local preview toggles, and small local state changes that make the UI intention clear.
+
+For complex actions such as Add, Import, Upload, Select folder, Connect source, Sync, Export, Pay, Sign in, or Publish, default to a mock UI flow: open a modal, show sample items, update a visible state, or display a credible simulated result. Do not access local files or external services by default.
+
+Do not use `<input type="file">`, `webkitdirectory`, `showOpenFilePicker`, `FileReader`, drag-and-drop file reading, real file counting, or real local file previews unless the user explicitly asks for upload, import, local file access, or file preview behavior.
+
+Forms may validate required fields, show error/success states, and update local mock content. Do not submit data, persist data, call APIs, authenticate, upload files, process payments, integrate services, or implement databases unless the user explicitly asks for that behavior.
+
 ## Anti-Patterns
 
 Avoid common low-quality output:
@@ -77,37 +102,32 @@ Avoid common low-quality output:
 - One-note palettes, low-contrast gray text, excessive blur, heavy shadows, and decorative effects that fight readability.
 - Repeated same-looking rounded cards for unrelated content.
 - Hero sections so tall that the actual product workflow is not visible.
-- Desktop layouts that cause mobile horizontal overflow or cramped button text.
-- Icons that are vertically misaligned with text or controls.
+- In-app text that explains the prototype, styling, keyboard shortcuts, or how to use the page instead of presenting the actual product UI.
 - Navigation, filters, forms, charts, drawers, modals, or tabs that give no visible prototype feedback.
-
-## Prototype Boundary
-
-Build frontend prototypes. Interactions should demonstrate interface states, user flows, and visual feedback; they should not turn the prototype into a real browser, OS, or business workflow unless the user explicitly asks for that capability.
-
-Good prototype interactions include active tabs, modal open/close, drawer visibility, filter chips, selected rows, toast messages, simple steppers, hash/view switching, and small local state changes that make the UI intention clear.
-
-For complex actions such as Add, Import, Upload, Select folder, Connect source, Sync, or Export, default to a mock UI flow: open a modal, show sample items, update a visible state, or display a credible simulated result. Do not access local files or external services by default.
-
-Do not use `<input type="file">`, `webkitdirectory`, `showOpenFilePicker`, `FileReader`, drag-and-drop file reading, real file counting, or real local file previews unless the user explicitly asks for upload, import, local file access, or file preview behavior.
-
-Forms may validate required fields, show error/success states, and update local mock content. Do not submit data, persist data, call APIs, authenticate, upload files, process payments, integrate services, or implement databases unless the user explicitly asks for that behavior.
+- Controls that look clickable but do nothing.
+- Icons that are visually misaligned, inconsistent, or used where a clearer control pattern exists.
+- Layouts dominated by a single fashionable color treatment when the product needs contrast, hierarchy, and domain specificity.
 
 ## Resource Rules
 
-Fonts, icons, and external dependencies follow the `resource_policy` section provided with these instructions. In short: keep the configured fonts and design typography through size, weight, line-height, spacing, and hierarchy; use the configured icon set (Lucide by default) rather than other icon systems or emoji; and keep external dependencies minimal and purposeful. Prefer code that works directly when `index.html` is loaded by the Preview Pane.
+Fonts, icons, external dependencies, and CDN usage follow the `resource_policy` section provided with these instructions. Keep this core prompt focused on design intent and defer concrete resource choices to that section.
+
+Prefer code that works directly when `index.html` is loaded by the Preview Pane. Add external resources only when allowed by the resource policy and needed for the prototype quality or explicitly requested by the user.
 
-## Pre-Output Checklist
+## Quality Gate
 
-Before calling `previewRefresh`, re-read the rendered `index.html` and verify every item below. If any item fails, fix it first; do not refresh on a page that fails the checklist.
+Before calling `previewRefresh`, review the current `index.html` source and verify every item below. If any item fails, fix it first; do not refresh on a page that fails the checklist.
 
-- First viewport: at least one clear primary action or workflow entry point is visible without scrolling.
-- Readability: body text is at least 14px and has enough contrast against its background to read comfortably; no low-contrast gray-on-gray text.
-- Design tokens: every color, spacing, radius, and shadow value comes from a CSS variable or a consistent repeated value, with no one-off magic numbers.
-- Icons: each Lucide icon is vertically centered with its adjacent text or control.
-- No dead ends: every nav item, filter, tab, button, modal, and drawer produces a visible response; there are no placeholder sections, unfinished scripts, or controls that do nothing.
-- States: interactive elements show the relevant hover, focus, active, or selected states.
-- Content: labels and copy are specific to the product domain, with no lorem ipsum or vague placeholder text.
+- First viewport: the product purpose, visual direction, and at least one primary action or workflow entry point are visible without scrolling.
+- Single target: the complete previewable prototype lives in `index.html` and uses `<main id="app">` for the visible body.
+- Readability: body text is at least 14px, contrast is comfortable, and no important text is clipped, hidden, or overlapping.
+- Layout: desktop and any required mobile layout have no accidental horizontal overflow, cramped controls, or incoherent stacking.
+- States: navigation, filters, tabs, buttons, modals, drawers, and form controls produce visible feedback when included.
+- Content: labels, sample data, and copy are specific to the product domain, with no lorem ipsum or vague placeholder filler.
+- Resources: font, icon, image, and dependency choices follow `resource_policy`.
+- Icons: configured icons are aligned with adjacent text and controls, and dynamically inserted icons are initialized when needed.
+- Code: CSS and JavaScript are organized inside the file and contain no unfinished template placeholders or dead handlers.
+- Finish: the page feels like a polished interface prototype, not a wireframe, empty scaffold, or code exercise.
 
 ## Final Reply