@abeedoo/radish-schemas 1.7.7

package/prompts/radish-app-generation.md

@@ -0,0 +1,259 @@
+# AI App Blueprint Generation Prompt Template
+
+You are an expert application architect. Generate a JSON app blueprint based on the user's description.
+
+## Purpose
+
+The app blueprint is the **master document** for a Radish application. It captures the high-level intent, audience, workflows, features, and entity overview. Other generators (types.json, roles.json, UI layer) use this blueprint as their primary input.
+
+## IMPORTANT: Output Format
+
+1. **Return ONLY valid JSON** - No markdown, explanations, or code blocks
+2. **Use this exact top-level structure**:
+
+```json
+{
+  "version": 1,
+  "app": {
+    "name": "AppName",
+    "displayName": "App Display Name",
+    "description": "Full description of the application",
+    "version": "0.1.0",
+    "domain": "business-domain",
+    "tags": ["tag1", "tag2", "tag3"]
+  },
+  "audience": {
+    "primary": "Primary user persona description",
+    "secondary": "Secondary user persona description",
+    "admin": "Admin user persona description"
+  },
+  "workflows": [
+    {
+      "name": "Workflow Name",
+      "actor": "persona",
+      "description": "What the user does step by step"
+    }
+  ],
+  "categories": [
+    {
+      "name": "Category Name",
+      "subcategories": ["Sub1", "Sub2", "Sub3"]
+    }
+  ],
+  "style": {
+    "theme": "radish-admin",
+    "tone": "professional but approachable",
+    "palette": "description of color palette",
+    "typography": "font and spacing preferences",
+    "layout": "layout style description",
+    "icons": "icon style description",
+    "imagery": "imagery style description"
+  },
+  "features": {
+    "auth": true,
+    "roles": true,
+    "adminPanel": true,
+    "api": true,
+    "search": true,
+    "pagination": true,
+    "fileUploads": false,
+    "notifications": false,
+    "analytics": false,
+    "scheduling": false,
+    "logging": true
+  },
+  "entityOverview": {
+    "groupName": [
+      { "EntityName": "Description of entity purpose and relationships" }
+    ]
+  },
+  "accessPatterns": {
+    "public": ["Action anyone can do"],
+    "authenticated": ["Action logged-in users can do"],
+    "admin": ["Action admins can do"]
+  },
+  "database": {
+    "type": "mongodb",
+    "name": "appname"
+  }
+}
+```
+
+## Section Details
+
+### app (required)
+Core application metadata.
+
+- **name** (required): PascalCase or camelCase identifier used in code generation
+- **displayName**: Human-readable name for UI display
+- **description** (required): Comprehensive description of what the application does. Be specific about key features, user interactions, and business goals. This drives all downstream generation.
+- **version**: Application version in semver format (start with "0.1.0")
+- **domain**: Business domain category (e.g., education, e-commerce, healthcare, finance, social, productivity)
+- **tags**: Searchable keywords
+
+### audience
+Define who uses the application. Be specific about their goals and context.
+
+- **primary**: The main user persona — who they are and what they want
+- **secondary**: Supporting user persona — different role or use case
+- **admin**: Administrative persona — platform management responsibilities
+
+### workflows
+The most important section for driving UI generation. Describe **what users actually do** in the application.
+
+**Guidelines:**
+- Each workflow should describe a complete user journey
+- Use action verbs: browse, create, submit, review, manage
+- Include the sequence of steps where possible
+- Map each workflow to an actor (persona)
+- Think about CRUD operations but describe them as user goals
+
+**Example:**
+```json
+{
+  "name": "Project Planning",
+  "actor": "manager",
+  "description": "Create a new project, define milestones and tasks, assign team members, set deadlines, track progress through kanban board"
+}
+```
+
+### categories (optional)
+Content taxonomy for the application. Useful for apps with categorized content.
+
+### style
+Branding and UI hints. These inform the UI layer generator but do not enforce specific implementations.
+
+- **theme**: Theme identifier (e.g., "radish-admin", "minimal", "dashboard")
+- **tone**: Brand voice description
+- **palette**: Color scheme description or specific colors
+- **typography**: Font preferences and spacing
+- **layout**: Layout pattern preferences (e.g., "card-based", "sidebar navigation", "top navbar")
+- **icons**: Icon style (e.g., "feather/outline", "filled", "material")
+- **imagery**: Placeholder and image style
+
+### features
+Boolean flags for application capabilities. These drive which generators and templates are used.
+
+| Feature | Description |
+|---------|-------------|
+| auth | Authentication system (login, register, password reset) |
+| roles | Role-based access control |
+| adminPanel | Administrative dashboard |
+| api | REST API endpoints |
+| search | Search functionality across entities |
+| pagination | Paginated list views |
+| fileUploads | File/image upload capability |
+| notifications | In-app or email notifications |
+| analytics | Usage analytics and reporting |
+| scheduling | Calendar, scheduling, or time-based features |
+| logging | Application event logging |
+
+### entityOverview
+High-level entity descriptions grouped by domain concern. This drives types.json generation.
+
+**Guidelines:**
+- Group entities by domain concern (core, engagement, community, etc.)
+- Use PascalCase for entity names
+- Describe purpose, key relationships, and ownership
+- Mention which entities are "owned by" users
+- Don't define fields here — that's for types.json
+
+**Example:**
+```json
+{
+  "core": [
+    { "Project": "Top-level container. Has tasks and milestones. Owned by creator." },
+    { "Task": "Work item within a project. Assigned to team members. Has status, priority, due date." }
+  ],
+  "collaboration": [
+    { "Comment": "Threaded discussion on tasks or projects." },
+    { "Activity": "Audit log of actions taken on entities." }
+  ]
+}
+```
+
+### accessPatterns
+Who can do what, organized by access level. This drives roles.json generation.
+
+**Guidelines:**
+- Use clear access levels: public, authenticated, role-specific names, admin
+- Describe actions in plain language
+- Think about read vs. write vs. manage permissions
+- Consider data ownership (users can edit "own" vs "any")
+
+### database
+Database configuration for the project.
+
+- **type**: Database engine — currently supports "mongodb"
+- **name**: Database name (lowercase, no spaces)
+
+## What Makes a Good App Blueprint
+
+### DO:
+- Write a rich, detailed app description — it drives everything downstream
+- Define specific workflows with clear user journeys
+- Think about all user personas and their goals
+- Include realistic feature flags
+- Group entities logically by domain concern
+- Define clear access patterns
+
+### DON'T:
+- Don't define individual fields — that's for types.json
+- Don't specify routes or pages — that's for the UI layer
+- Don't include implementation details (API endpoints, database queries)
+- Don't create entities for built-in types (User, Profile, Role, Permission, ApiKey, Setting)
+- Don't over-specify style — keep it high-level and suggestive
+
+## Built-in Entities (Do NOT Include in entityOverview)
+
+The following entities are provided by the system:
+- **User** — Authentication and identity
+- **Profile** — Extended user information
+- **Role** — Permission management
+- **Permission** — Access control
+- **ApiKey** — API authentication
+- **Setting** — System configuration
+
+Reference these in workflows and access patterns, but don't redefine them.
+
+---
+
+**User Description**: {{USER_DESCRIPTION}}
+
+---
+
+## Response Format
+
+You MUST respond with ONLY a valid JSON object in this EXACT format:
+
+```json
+{
+  "app": {
+    "version": 1,
+    "app": {
+      "name": "AppName",
+      "description": "Full description..."
+    },
+    "audience": { ... },
+    "workflows": [ ... ],
+    "features": { ... },
+    "entityOverview": { ... },
+    "accessPatterns": { ... },
+    "database": { ... }
+  }
+}
+```
+
+**CRITICAL REQUIREMENTS**:
+1. Return ONLY the JSON object — no markdown code blocks, no explanations, no preamble
+2. The `app` value must be a complete JSON object (NOT a string)
+3. Must include `"version": 1` at the top level of the app object
+4. All keys and string values must be properly quoted
+
+**Common Mistakes to AVOID**:
+- Wrapping response in markdown ```json...``` blocks
+- Including explanatory text before or after the JSON
+- Defining individual entity fields (save for types.json)
+- Including built-in entities (User, Role, etc.) in entityOverview
+- Using implementation-specific details instead of high-level descriptions
+- Returning YAML strings instead of JSON objects

package/prompts/radish-components-generation.md

@@ -0,0 +1,138 @@
+# AI Components Blueprint Generation Prompt
+
+You are a UI component architect for a Svelte 5 + DaisyUI application. Given entity definitions, UI page layouts, and a list of available UI primitives, generate a components.json blueprint that maps each referenced component to an implementation.
+
+**Generate ONLY the components blueprint. Do NOT include types, roles, app, ui, or theme.**
+
+## Available @radish/components Primitives
+
+**Actions:** Button, Dropdown, Swap, ThemeController
+**Composites:** AutoForm, ChatPanel, ConfirmDialog, DataTable, EmptyState, Icon, Modal, PageHeader, Tabs
+**Data Display:** Accordion, Avatar, Badge, Carousel, ChatBubble, CodeBlock, Collapse, Countdown, Kbd, List, Stat, StatGroup, Status, Table, Timeline
+**Data Input:** Calendar, Checkbox, DateRangeInput, DropZone, FileInput, FormField, Radio, Range, Rating, SearchInput, Select, TextInput, Textarea, Toggle
+**Feedback:** Alert, Loading, Progress, RadialProgress, Skeleton, Toast, Tooltip
+**Layout:** Card, Divider, Drawer, Footer, Hero, Stack
+**Navigation:** Breadcrumbs, Dock, Link, Menu, Navbar, Pagination, Steps
+**Content:** ContentBlock
+
+## Component Definition Format
+
+### Static components (no entity binding)
+```json
+{
+  "base": "Hero",
+  "props": {
+    "title": "Welcome to My App",
+    "subtitle": "Build something amazing"
+  }
+}
+```
+
+### Entity-bound card
+```json
+{
+  "base": "Card",
+  "entity": "Course",
+  "fields": {
+    "title": "title",
+    "body": "description",
+    "badge": "difficultyLevel"
+  },
+  "actions": [
+    { "label": "View", "href": "/courses/{id}", "variant": "primary" }
+  ]
+}
+```
+
+### Entity data table
+```json
+{
+  "base": "DataTable",
+  "entity": "Course",
+  "display": "table",
+  "columns": ["title", "difficultyLevel", "price", "publishStatus"]
+}
+```
+
+### Grid with card component
+```json
+{
+  "base": "DataTable",
+  "entity": "Course",
+  "display": "grid",
+  "cardComponent": "CourseCard"
+}
+```
+
+### Editable CMS block
+```json
+{
+  "base": "ContentBlock",
+  "editable": true,
+  "defaultContent": "<h2>About Us</h2><p>Learn more about our platform.</p>"
+}
+```
+
+## Rules
+
+- Component names must be PascalCase (e.g., `CourseCard`, `HeroSection`, `EnrollmentTable`)
+- Each component referenced in the UI blueprint pages must have a definition
+- Use entity field names that match the types blueprint exactly
+- For entity lists, pick the 3-5 most meaningful columns (skip _id, timestamps, ownerId)
+- For cards, map title/body/badge to the most relevant entity fields
+- Generate realistic default content for editable blocks
+- Actions with `href` support interpolation: `/courses/{id}`, `/users/{userId}`
+
+## What NOT to include
+- Do not define the entities themselves (that's types.json)
+- Do not define routes or pages (that's ui.json)
+- Do not define theme colors (that's theme.json)
+- Do not include CSS or styling details
+
+---
+
+**User Description**: {{USER_DESCRIPTION}}
+
+---
+
+## Response Format
+
+You MUST respond with ONLY a valid JSON object:
+
+```json
+{
+  "version": 1,
+  "components": {
+    "HeroSection": {
+      "base": "Hero",
+      "props": { "title": "...", "subtitle": "..." }
+    },
+    "CourseCard": {
+      "base": "Card",
+      "entity": "Course",
+      "fields": { "title": "title", "body": "description", "badge": "category" },
+      "actions": [{ "label": "View", "href": "/courses/{id}" }]
+    },
+    "CourseTable": {
+      "base": "DataTable",
+      "entity": "Course",
+      "display": "table",
+      "columns": ["title", "category", "price", "status"]
+    }
+  }
+}
+```
+
+**CRITICAL REQUIREMENTS**:
+1. Return ONLY the JSON object - no markdown code blocks, no explanations
+2. Must include `"version": 1`
+3. Must include `"components"` with at least one component
+4. Component names must be PascalCase
+5. `base` must be a valid primitive from the list above
+
+**Common Mistakes to AVOID**:
+- Wrapping response in markdown ```json...``` blocks
+- Using lowercase or camelCase for component names
+- Using field names that don't exist in the types blueprint
+- Including too many columns (stick to 3-5 most important)
+- Forgetting to define components referenced in the UI blueprint

package/prompts/radish-roles-generation.md

@@ -0,0 +1,133 @@
+# AI Roles Blueprint Generation Prompt
+
+You are an expert in application security and access control. Generate a JSON roles blueprint based on the user's description.
+
+**Generate ONLY the roles blueprint. Do NOT include types/entities.**
+
+## Role Structure
+
+Each role is an object with these properties:
+- **label** (required): Human-readable role name
+- **description** (required): What this role can do
+- **isSystem** (required): Whether this is a system-managed role (permissions resolved in code)
+- **permissions** (optional): Array of permission keys (ignored for system roles)
+
+## Permission Format
+
+Permission keys use lowercase with colons: `"entity:action"` or `"entity:action:scope"`
+
+**Examples:**
+- `"project:create"` - Create projects
+- `"project:edit"` - Edit projects
+- `"project:delete"` - Delete projects
+- `"project:view"` - View projects
+- `"user:manage"` - Manage users
+- `"comment:create"` - Create comments
+- `"report:view:own"` - View own reports
+
+## Built-in Roles
+
+Always include these two system roles:
+
+- **USER** - Standard authenticated user (isSystem: true)
+- **ADMIN** - Full system access (isSystem: true)
+
+Add domain-specific roles based on the application description.
+
+## Example
+
+```json
+{
+  "version": 1,
+  "roles": {
+    "USER": {
+      "label": "Standard User",
+      "description": "Standard user with basic permissions",
+      "isSystem": true,
+      "permissions": []
+    },
+    "ADMIN": {
+      "label": "Administrator",
+      "description": "Full system access",
+      "isSystem": true,
+      "permissions": []
+    },
+    "MANAGER": {
+      "label": "Manager",
+      "description": "Can manage projects and teams",
+      "isSystem": false,
+      "permissions": [
+        "project:create",
+        "project:edit",
+        "project:delete",
+        "user:manage"
+      ]
+    },
+    "PROJECT_MEMBER": {
+      "label": "Project Member",
+      "description": "Can view and edit assigned projects",
+      "isSystem": false,
+      "permissions": [
+        "project:view",
+        "task:create",
+        "task:edit",
+        "comment:create"
+      ]
+    }
+  }
+}
+```
+
+## Rules
+
+- Role keys MUST be UPPERCASE (USER, ADMIN, MANAGER), NOT lowercase or camelCase
+- Roles MUST be objects with keys, NOT arrays
+- Permission names use `entity:action` format (e.g., `"project:create"`, `"userProfile:view"`, `"file-upload:manage"`)
+- System roles (USER, ADMIN) have `"isSystem": true` and empty permissions
+- Custom roles have `"isSystem": false` and explicit permissions
+- Derive permissions from the entities and workflows described by the user
+
+---
+
+**User Description**: {{USER_DESCRIPTION}}
+
+---
+
+## Response Format
+
+You MUST respond with ONLY a valid JSON object starting with `{ "version": 1, "roles": { ... } }`.
+
+```json
+{
+  "version": 1,
+  "roles": {
+    "USER": {
+      "label": "Standard User",
+      "description": "Standard user with basic permissions",
+      "isSystem": true,
+      "permissions": []
+    },
+    "ADMIN": {
+      "label": "Administrator",
+      "description": "Full system access",
+      "isSystem": true,
+      "permissions": []
+    }
+  }
+}
+```
+
+**CRITICAL REQUIREMENTS**:
+1. Return ONLY the JSON object - no markdown code blocks, no explanations, no preamble
+2. Must include `"version": 1`
+3. Must include `"roles"` with at least USER and ADMIN
+4. Do NOT include types/entities - this is roles only
+5. All keys and string values must be properly quoted
+
+**Common Mistakes to AVOID**:
+- Wrapping response in markdown ```json...``` blocks
+- Including explanatory text before or after the JSON
+- Including a "types" or "entities" section (generate roles ONLY)
+- Using arrays for roles (must be objects with keys)
+- Permission names without colons (use `"entity:action"` format)
+- Lowercase role keys (must be UPPERCASE)