builder.io 1.9.17 → 1.9.19

package/types/cli/backup.d.ts

@@ -1,6 +1,6 @@
 import type { DevToolsSys } from "../types";
 import type { Credentials } from "./credentials";
-import { type GitBackupUploadUrlResult, type GitBackupUploadUrlOptions, type GitBackupRecordOptions, type GitBackupRecordResult, type BackupMetadata, type WorkspaceConfiguration, type CodegenSetLastCommit } from "$/ai-utils";
+import { type GitBackupUploadUrlResult, type GitBackupUploadUrlOptions, type GitBackupRecordOptions, type GitBackupRecordResult, type BackupMetadata, type WorkspaceConfiguration, type CodegenRuntimeStatus } from "$/ai-utils";
 interface BackupGitRepoOptions {
     sys: DevToolsSys;
     credentials: Credentials;
@@ -102,7 +102,7 @@ export declare function computeMD5Hash(bundlePath: string): Promise<{
  * This is called frequently throughout the codebase (after every commit creation)
  * to track the current state and determine if backups are up-to-date.
  */
-export declare function setLastCommit(sys: DevToolsSys, credentials: Credentials, data: CodegenSetLastCommit, verbose: boolean): Promise<any>;
+export declare function setRuntimeStatus(sys: DevToolsSys, credentials: Credentials, data: CodegenRuntimeStatus): Promise<any>;
 /**
  * Computes a unique backup reference string that combines version, repo URL, and commit hash.
  * This reference can be used to identify and retrieve specific backups.

package/types/cli/codegen.d.ts

@@ -108,11 +108,11 @@ export declare class CodeGenSession {
     /**
      * Get the feature branch name
      */
-    getFeatureBranch(): string | undefined;
+    getFeatureBranch(): string;
     /**
      * Get the AI branch name
      */
-    getAiBranch(): string | undefined;
+    getAiBranch(): string;
     git(args: string[], opts?: string | RunGitOptions): Promise<string>;
     /**
      * Helper to run git commands

package/types/cli/launch/InitStateMachine.d.ts

@@ -31,6 +31,7 @@ export declare class InitStateMachine {
         success?: boolean;
     }): void;
     clearInitLogs(): void;
+    hasFilesButNoGit(repoPath: string): Promise<boolean>;
     step1CheckDirectories(config: InitConfig, repositories: Required<WorkspaceFolder>[]): Promise<void>;
     step2ConfigureGitRepositories(config: InitConfig, repositories: Required<WorkspaceFolder>[]): Promise<void>;
     step3ConfigureGitUser(config: InitConfig, repositories: Required<WorkspaceFolder>[]): Promise<void>;

package/types/cli/utils/component-group-mdx-prompt.d.ts

@@ -1 +1 @@
-export declare const COMPONENT_GROUP_MDX_PROMPT = "# Component Documentation Generation\n\n## Objective\nGenerate comprehensive MDX documentation for a specific component, analyzing their interfaces, relationships, and usage patterns using the relevant files provided in the input.\n\n## Instructions\n\n### 1. Component Analysis\nFor the given component, analyze each relevant file by:\n- **Interdependency mapping** - Document how components depend on each other\n- **Interface examination** - Extract and document all props, their types, and descriptions\n- **Context analysis** - Identify shared state, contexts, or communication patterns\n- **Compositional patterns** - Document required parent-child relationships\n- **Usage pattern analysis** - Identify how components work together\n- **Example extraction** - Find real usage examples from the codebase\n\n{{COMPONENT_NAME}} has the following related components: {{RELATED_COMPONENTS}}\nThe following files are associated with {{COMPONENT_NAME}}: {{FILE_LIST}}\n\n### 2. Documentation Structure\nCreate comprehensive documentation covering:\n- **Component rationale** - Why these components work together and when to use them\n- **Architectural overview** - How the components form a cohesive system\n- **Component interfaces** - Detailed prop documentation with interdependencies\n- **Composition patterns** - Required and optional usage combinations\n- **Integration examples** - Real-world scenarios showing the component in action\n- **Best practices** - Recommended usage patterns and guidelines\n\n## Required Output Format\n\nGenerate an MDX file with this structure:\n\n```mdx\n---\n# {{COMPONENT_NAME}}\n\n## Overview\n\n### Purpose\n{{COMPONENT_DESCRIPTION}}\n\n### When to Use\n[Expand on the use cases mentioned in the description - be specific about scenarios, user needs, and implementation contexts]\n\n### Architecture\n[Explain the architectural pattern based on coupling strength:]\n- **Critical/Strong Coupling**: Describe the required relationships, shared context, or compositional hierarchy\n- **Moderate Coupling**: Explain how components enhance each other\n- **No Coupling**: Note that this is a standalone component\n\n### Component Interdependencies\n[Map out component relationships - only for components with coupling:]\n- Required parent-child relationships\n- Shared context dependencies  \n- Communication patterns between components\n- Related components\n\n## Components\n\n### [PrimaryComponent] {Primary Component for components with coupling}\n[Mark the main/root component for coupled components]\n\n**Purpose:** [What this specific component does]\n\n**Interface:**\n```typescript\ninterface [PrimaryComponent]Props {\n  // Document all props with types and descriptions\n  children: React.ReactNode; // Required child components (for coupled components)\n  property: string; // Description of what this prop does\n  onAction?: () => void; // Optional callback description\n}\n```\n\n**Dependencies:** [For coupled components - what this component requires]\n**Provides:** [For coupled components - what context/state this component provides to children]\n\n**Usage Example:**\n```tsx\nimport { [PrimaryComponent] } from '@your-library/components';\n\nfunction Example() {\n  return (\n    <[PrimaryComponent]\n      property=\"value\"\n      onAction={() => console.log('action')}\n    >\n      {/* Required children for coupled components */}\n    </[PrimaryComponent]>\n  );\n}\n```\n\n### [DependentComponent] {Dependent Component for components with coupling}\n[Mark components that depend on the primary component]\n\n**Purpose:** [What this specific component does]\n\n**Interface:**\n```typescript\ninterface [DependentComponent]Props {\n  // Props specific to this component\n  // Note any props that are passed down from parent context\n}\n```\n\n**Context Dependencies:** [What context/state this component requires from parent]\n**Parent Requirements:** [Required parent components for proper functionality]\n\n**Usage Example:**\n```tsx\n// Must be used within [PrimaryComponent] for coupled components\n<[PrimaryComponent]>\n  <[DependentComponent] prop=\"value\">\n    Content\n  </[DependentComponent]>\n</[PrimaryComponent]>\n```\n\n### [StandaloneComponent] {For uncoupled components}\n[For components with no coupling]\n\n**Purpose:** [What this component does and when to use it]\n\n**Interface:**\n```typescript\ninterface [StandaloneComponent]Props {\n  // All props with types and descriptions\n}\n```\n\n**Usage Example:**\n```tsx\nimport { [StandaloneComponent] } from '@your-library/components';\n\nfunction Example() {\n  return (\n    <[StandaloneComponent]\n      property=\"value\"\n      onAction={() => console.log('action')}\n    />\n  );\n}\n```\n\n## Integration Patterns\n\n### Basic Usage {Only for coupled components}\n```tsx\nimport { [PrimaryComponent], [DependentComponent1], [DependentComponent2] } from '@your-library/components';\n\n// Minimal required structure\nfunction BasicExample() {\n  return (\n    <[PrimaryComponent]>\n      <[DependentComponent1]>Required content</[DependentComponent1]>\n      <[DependentComponent2]>More content</[DependentComponent2]>\n    </[PrimaryComponent]>\n  );\n}\n```\n\n### Advanced Usage {Only for coupled components}\n```tsx\n// Complex usage with all features\nfunction AdvancedExample() {\n  return (\n    <[PrimaryComponent] \n      property=\"value\" \n      onAction={handleAction}\n    >\n      <[DependentComponent1] prop=\"value\">\n        <Content />\n      </[DependentComponent1]>\n      <[DependentComponent2] prop=\"value\">\n        <MoreContent />\n      </[DependentComponent2]>\n    </[PrimaryComponent]>\n  );\n}\n```\n\n### Common Variations {Adapt based on component types}\n```tsx\n// Show different ways to use the component(s)\n// Include conditional rendering, different prop combinations, etc.\n```\n\n## Component Relationships {Only for coupled components}\n\n### Data Flow\n[Explain how data flows between the component and related components}\n\n### Context Sharing\n[Document shared contexts, providers, or state management]\n\n### Event Handling\n[Describe how events bubble up or propagate between components]\n\n## Best Practices\n\n### Usage Guidelines\n- [Specific recommendation based on component purpose and use cases]\n- [Another recommendation focusing on accessibility or performance]\n- [Usage pattern guidance based on the component's architecture]\n\n### Accessibility {When relevant}\n- [ARIA relationships between components]\n- [Keyboard navigation patterns]\n- [Screen reader considerations]\n\n### Performance {When relevant}\n- [Optimization recommendations]\n- [State management best practices]\n- [Rendering performance considerations]\n\n## Common Patterns {Expand based on component functionality}\n\n### Pattern 1: [Specific Pattern Name]\n```tsx\n// Example showing a specific usage pattern\n// Include comments explaining why this pattern is recommended\n```\n\n### Pattern 2: [Another Pattern Name]\n```tsx\n// Another common pattern with explanation\n```\n\n```\n\n## File Generation Requirements\n\n**File Naming:**\n- Use kebab-case derived from component name: `{{COMPONENT_NAME_KEBAB}}.mdx`\n- Place in `repo-indexing/` folder\n- Example: `repo-indexing/{{COMPONENT_NAME_KEBAB}}.mdx`\n\n**Content Requirements:**\n1. **Use coupling strength context** - Adapt documentation structure based on couplingStrength value\n2. **Extract real interfaces** - Don't create placeholder interfaces, extract actual TypeScript interfaces from the codebase\n3. **Leverage component description** - Expand on the provided description with specific use cases and implementation guidance\n4. **Document interdependencies** - For coupled components, clearly explain component relationships and requirements\n5. **Include practical examples** - Use realistic, working code examples that demonstrate proper usage\n6. **Show integration patterns** - For coupled components, demonstrate required composition patterns\n**Coupling-Specific Requirements:**\n- **Critical/Strong Coupling**: Focus on required relationships, composition patterns, and shared context\n- **Moderate Coupling**: Show how components enhance each other and optional usage patterns  \n- **No Coupling**: Document standalone usage, variants, and individual component capabilities\n\n## Output\nReturn only the complete MDX file content, ready to be saved as `repo-indexing/{{COMPONENT_NAME_KEBAB}}.mdx`";
+export declare const COMPONENT_GROUP_MDX_PROMPT = "# Component Documentation Generation\n\n## Objective\nGenerate comprehensive MDX documentation for a specific component, analyzing their interfaces, relationships, and usage patterns using the relevant files provided in the input.\n\n## Instructions\n\n### 1. Component Analysis\nFor the given component, analyze each relevant file by:\n- **Interdependency mapping** - Document how components depend on each other\n- **Interface examination** - Extract and document all props, their types, and descriptions\n- **Context analysis** - Identify shared state, contexts, or communication patterns\n- **Compositional patterns** - Document required parent-child relationships\n- **Usage pattern analysis** - Identify how components work together\n- **Example extraction** - Find real usage examples from the codebase\n\n{{COMPONENT_NAME}} has the following related components: {{RELATED_COMPONENTS}}\nThe following files are associated with {{COMPONENT_NAME}}: {{FILE_LIST}}\n\n### 2. Documentation Structure\nCreate comprehensive documentation covering:\n- **Component rationale** - Why these components work together and when to use them\n- **Architectural overview** - How the components form a cohesive system\n- **Component interfaces** - Detailed prop documentation with interdependencies\n- **Composition patterns** - Required and optional usage combinations\n- **Integration examples** - Real-world scenarios showing the component in action\n- **Best practices** - Recommended usage patterns and guidelines\n\n## Required Output Format\n\nGenerate an MDX file with this structure:\n\n```mdx\n---\n# {{COMPONENT_NAME}}\n\n## Overview\n\n### Purpose\n{{COMPONENT_DESCRIPTION}}\n\n### When to Use\n[Expand on the use cases mentioned in the description - be specific about scenarios, user needs, and implementation contexts]\n\n### Architecture\n[Explain the architectural pattern based on coupling strength:]\n- **Critical/Strong Coupling**: Describe the required relationships, shared context, or compositional hierarchy\n- **Moderate Coupling**: Explain how components enhance each other\n- **No Coupling**: Note that this is a standalone component\n\n### Component Interdependencies\n[Map out component relationships - only for components with coupling:]\n- Required parent-child relationships\n- Shared context dependencies  \n- Communication patterns between components\n- Related components\n\n## Components\n\n### [PrimaryComponent] {Primary Component for components with coupling}\n[Mark the main/root component for coupled components]\n\n**Purpose:** [What this specific component does]\n\n**Interface:**\n```typescript\ninterface [PrimaryComponent]Props {\n  // Document all props with types and descriptions\n  children: React.ReactNode; // Required child components (for coupled components)\n  property: string; // Description of what this prop does\n  onAction?: () => void; // Optional callback description\n}\n```\n\n**Dependencies:** [For coupled components - what this component requires]\n**Provides:** [For coupled components - what context/state this component provides to children]\n\n**Usage Example:**\n```tsx\nimport { [PrimaryComponent] } from '@your-library/components';\n\nfunction Example() {\n  return (\n    <[PrimaryComponent]\n      property=\"value\"\n      onAction={() => console.log('action')}\n    >\n      {/* Required children for coupled components */}\n    </[PrimaryComponent]>\n  );\n}\n```\n\n### [DependentComponent] {Dependent Component for components with coupling}\n[Mark components that depend on the primary component]\n\n**Purpose:** [What this specific component does]\n\n**Interface:**\n```typescript\ninterface [DependentComponent]Props {\n  // Props specific to this component\n  // Note any props that are passed down from parent context\n}\n```\n\n**Context Dependencies:** [What context/state this component requires from parent]\n**Parent Requirements:** [Required parent components for proper functionality]\n\n**Usage Example:**\n```tsx\n// Must be used within [PrimaryComponent] for coupled components\n<[PrimaryComponent]>\n  <[DependentComponent] prop=\"value\">\n    Content\n  </[DependentComponent]>\n</[PrimaryComponent]>\n```\n\n### [StandaloneComponent] {For uncoupled components}\n[For components with no coupling]\n\n**Purpose:** [What this component does and when to use it]\n\n**Interface:**\n```typescript\ninterface [StandaloneComponent]Props {\n  // All props with types and descriptions\n}\n```\n\n**Usage Example:**\n```tsx\nimport { [StandaloneComponent] } from '@your-library/components';\n\nfunction Example() {\n  return (\n    <[StandaloneComponent]\n      property=\"value\"\n      onAction={() => console.log('action')}\n    />\n  );\n}\n```\n\n## Integration Patterns\n\n### Basic Usage {Only for coupled components}\n```tsx\nimport { [PrimaryComponent], [DependentComponent1], [DependentComponent2] } from '@your-library/components';\n\n// Minimal required structure\nfunction BasicExample() {\n  return (\n    <[PrimaryComponent]>\n      <[DependentComponent1]>Required content</[DependentComponent1]>\n      <[DependentComponent2]>More content</[DependentComponent2]>\n    </[PrimaryComponent]>\n  );\n}\n```\n\n### Advanced Usage {Only for coupled components}\n```tsx\n// Complex usage with all features\nfunction AdvancedExample() {\n  return (\n    <[PrimaryComponent] \n      property=\"value\" \n      onAction={handleAction}\n    >\n      <[DependentComponent1] prop=\"value\">\n        <Content />\n      </[DependentComponent1]>\n      <[DependentComponent2] prop=\"value\">\n        <MoreContent />\n      </[DependentComponent2]>\n    </[PrimaryComponent]>\n  );\n}\n```\n\n### Common Variations {Adapt based on component types}\n```tsx\n// Show different ways to use the component(s)\n// Include conditional rendering, different prop combinations, etc.\n```\n\n## Component Relationships {Only for coupled components}\n\n### Data Flow\n[Explain how data flows between the component and related components}\n\n### Context Sharing\n[Document shared contexts, providers, or state management]\n\n### Event Handling\n[Describe how events bubble up or propagate between components]\n\n## Best Practices\n\n### Usage Guidelines\n- [Specific recommendation based on component purpose and use cases]\n- [Another recommendation focusing on accessibility or performance]\n- [Usage pattern guidance based on the component's architecture]\n\n### Accessibility {When relevant}\n- [ARIA relationships between components]\n- [Keyboard navigation patterns]\n- [Screen reader considerations]\n\n### Performance {When relevant}\n- [Optimization recommendations]\n- [State management best practices]\n- [Rendering performance considerations]\n\n## Common Patterns {Expand based on component functionality}\n\n### Pattern 1: [Specific Pattern Name]\n```tsx\n// Example showing a specific usage pattern\n// Include comments explaining why this pattern is recommended\n```\n\n### Pattern 2: [Another Pattern Name]\n```tsx\n// Another common pattern with explanation\n```\n\n```\n\n## File Generation Requirements\n\n**File Naming:**\n- Use kebab-case derived from component name: `{{COMPONENT_NAME_KEBAB}}.mdx`\n- Place in `repo-indexing/` folder\n- Example: `repo-indexing/{{COMPONENT_NAME_KEBAB}}.mdx`\n\n**Content Requirements:**\n1. **Use coupling strength context** - Adapt documentation structure based on couplingStrength value\n2. **Extract real interfaces** - Don't create placeholder interfaces, extract actual TypeScript interfaces from the codebase\n3. **Leverage component description** - Expand on the provided description with specific use cases and implementation guidance\n4. **Document interdependencies** - For coupled components, clearly explain component relationships and requirements\n5. **Include practical examples** - Use realistic, working code examples that demonstrate proper usage\n6. **Show integration patterns** - For coupled components, demonstrate required composition patterns\n**Coupling-Specific Requirements:**\n- **Critical/Strong Coupling**: Focus on required relationships, composition patterns, and shared context\n- **Moderate Coupling**: Show how components enhance each other and optional usage patterns  \n- **No Coupling**: Document standalone usage, variants, and individual component capabilities\n\n## Output\nReturn only the complete MDX file content, ready to be saved as `repo-indexing/{{COMPONENT_NAME_KEBAB}}.mdx`. You must use the Write tool in your response.";

package/types/cli/utils/repo-indexing-agent-prompt.d.ts

@@ -1 +1 @@
-export declare const REPO_INDEXING_AGENT_PROMPT = "You are tasked with generating comprehensive documentation for a design system based on the provided components.\n\n---\n\n# Design System Component Reference\n\nThis document provides a comprehensive overview of the design system's component architecture and available components for code generation and development reference.\n\n## System Architecture\n\nThe design system follows a modular component-based architecture where each component provides specific functionality. Components are organized into logical groups that can work independently or in combination with other components.\n\n### Component Organization Principles\n\n- **Single Responsibility**: Each component serves a specific purpose\n- **Composability**: Components can be combined to create complex interfaces\n- **Consistency**: All components follow the same design patterns and API conventions\n- **Accessibility**: Components are built with accessibility standards in mind\n\n## Documentation Structure\n\nFor detailed documentation on any component, refer to the corresponding MDX file in the `design-system-docs` folder. The documentation files follow the naming convention:\n\n```\ndesign-system-docs/[componentname].mdx\n```\n\nFor example:\n- `design-system-docs/button.mdx` - Detailed documentation for Button component\n- `design-system-docs/table.mdx` - Detailed documentation for Table component\n- `design-system-docs/annotationcontext.mdx` - Detailed documentation for AnnotationContext\n- `design-system-docs/applayout.mdx` - Detailed documentation for AppLayout component\n\nThese MDX files contain comprehensive information including:\n- Component API documentation\n- Usage examples\n- Props and configuration options\n- Best practices and implementation guidelines\n- Accessibility requirements\n- Integration patterns with other components\n\n## Component Categories\n\nCategorize and organize the components into logical groups such as:\n\n### Layout & Structure\nComponents that provide foundational layout and structural elements for applications.\n\n### Navigation\nComponents for user navigation and wayfinding within applications.\n\n### Form Controls\nInteractive components for user input and data collection.\n\n### Data Display\nComponents for presenting and organizing data and content.\n\n### Charts & Visualization\nComponents for data visualization and graphical representation.\n\n### Interactive Elements\nComponents for user interaction and actions.\n\n### Feedback & Communication\nComponents for providing feedback and communicating with users.\n\n### Form Organization\nComponents for structuring and organizing forms.\n\n### Content Organization\nComponents for organizing and structuring content.\n\n### Advanced Controls\nSpecialized components for complex interactions and data management.\n\n### Selection & Control\nComponents for user selections and interface controls.\n\n### Specialized Components\nComponents for specific use cases and advanced functionality.\n\n### Tutorial & Annotation System\nA specialized component group for creating interactive tutorials and annotations.\n\n### System Components\nComponents for system-level functionality and configuration.\n\n**Instructions for categorization:**\n1. Analyze each component provided below\n2. Group components by their primary functionality\n3. List each component with its description under the appropriate category\n4. Use the format: `**ComponentName** - [description from the component data]`\n5. Identify any component dependencies (like AnnotationContext)\n6. Create new categories if needed based on the actual component data\n\n## Usage Guidelines\n\n### Component Dependencies\n- Most components are self-contained and can be used independently\n- Identify any components that require multiple components to work together\n- Some components work better in combination (e.g., Form + FormField, Table + Pagination)\n\n### Integration Patterns\n- Layout components typically serve as containers for other components\n- Form controls should be wrapped in FormField components for proper labeling\n- Navigation components can be used independently or as part of larger layout structures\n- Data display components can be enhanced with interactive elements like buttons and popovers\n\n### Accessibility Considerations\n- All components are built with accessibility in mind\n- Use semantic HTML structures provided by the components\n- Leverage built-in ARIA attributes and keyboard navigation\n- The LiveRegion component provides additional accessibility announcements when needed\n\n### Responsive Design\n- Layout components provide responsive behavior out of the box\n- Grid and ColumnLayout components adapt to different screen sizes\n- Mobile-friendly navigation patterns are built into navigation components\n\n## Usage Reference\n\nThis reference should be used to understand the available components and their intended purposes when generating code or building applications with this design system. For specific implementation details, always consult the corresponding MDX documentation file in the `design-system-docs` folder.\n\n---\n\n**Template Usage Instructions:**\n1. Replace {{COMPONENTS}} with the actual JSON array of components\n2. Process each component to extract the name and description\n3. Categorize components based on their functionality and description\n4. Generate the appropriate category sections with component listings\n5. Ensure all component names are properly formatted and descriptions are included\n\nMake sure to save the output in the file AGENT.md";
+export declare const REPO_INDEXING_AGENT_PROMPT = "You are tasked with generating comprehensive documentation for a design system based on the provided components.\n\n---\n\n# Design System Component Reference\n\nThis document provides a comprehensive overview of the design system's component architecture and available components for code generation and development reference.\n\n## System Architecture\n\nThe design system follows a modular component-based architecture where each component provides specific functionality. Components are organized into logical groups that can work independently or in combination with other components.\n\n### Component Organization Principles\n\n- **Single Responsibility**: Each component serves a specific purpose\n- **Composability**: Components can be combined to create complex interfaces\n- **Consistency**: All components follow the same design patterns and API conventions\n- **Accessibility**: Components are built with accessibility standards in mind\n\n## Documentation Structure\n\nFor detailed documentation on any component, refer to the corresponding MDX file in the `design-system-docs` folder. The documentation files follow the naming convention:\n\n```\ndesign-system-docs/[componentname].mdx\n```\n\nFor example:\n- `design-system-docs/button.mdx` - Detailed documentation for Button component\n- `design-system-docs/table.mdx` - Detailed documentation for Table component\n- `design-system-docs/annotationcontext.mdx` - Detailed documentation for AnnotationContext\n- `design-system-docs/applayout.mdx` - Detailed documentation for AppLayout component\n\nThese MDX files contain comprehensive information including:\n- Component API documentation\n- Usage examples\n- Props and configuration options\n- Best practices and implementation guidelines\n- Accessibility requirements\n- Integration patterns with other components\n\n## Component Categories\n\nCategorize and organize the components into logical groups such as:\n\n### Layout & Structure\nComponents that provide foundational layout and structural elements for applications.\n\n### Navigation\nComponents for user navigation and wayfinding within applications.\n\n### Form Controls\nInteractive components for user input and data collection.\n\n### Data Display\nComponents for presenting and organizing data and content.\n\n### Charts & Visualization\nComponents for data visualization and graphical representation.\n\n### Interactive Elements\nComponents for user interaction and actions.\n\n### Feedback & Communication\nComponents for providing feedback and communicating with users.\n\n### Form Organization\nComponents for structuring and organizing forms.\n\n### Content Organization\nComponents for organizing and structuring content.\n\n### Advanced Controls\nSpecialized components for complex interactions and data management.\n\n### Selection & Control\nComponents for user selections and interface controls.\n\n### Specialized Components\nComponents for specific use cases and advanced functionality.\n\n### Tutorial & Annotation System\nA specialized component group for creating interactive tutorials and annotations.\n\n### System Components\nComponents for system-level functionality and configuration.\n\n**Instructions for categorization:**\n1. Analyze each component provided below\n2. Group components by their primary functionality\n3. List each component with its description under the appropriate category\n4. Use the format: `**ComponentName** - [description from the component data]`\n5. Identify any component dependencies (like AnnotationContext)\n6. Create new categories if needed based on the actual component data\n\n## Usage Guidelines\n\n### Component Dependencies\n- Most components are self-contained and can be used independently\n- Identify any components that require multiple components to work together\n- Some components work better in combination (e.g., Form + FormField, Table + Pagination)\n\n### Integration Patterns\n- Layout components typically serve as containers for other components\n- Form controls should be wrapped in FormField components for proper labeling\n- Navigation components can be used independently or as part of larger layout structures\n- Data display components can be enhanced with interactive elements like buttons and popovers\n\n### Accessibility Considerations\n- All components are built with accessibility in mind\n- Use semantic HTML structures provided by the components\n- Leverage built-in ARIA attributes and keyboard navigation\n- The LiveRegion component provides additional accessibility announcements when needed\n\n### Responsive Design\n- Layout components provide responsive behavior out of the box\n- Grid and ColumnLayout components adapt to different screen sizes\n- Mobile-friendly navigation patterns are built into navigation components\n\n## Usage Reference\n\nThis reference should be used to understand the available components and their intended purposes when generating code or building applications with this design system. For specific implementation details, always consult the corresponding MDX documentation file in the `design-system-docs` folder.\n\n---\n\n**Template Usage Instructions:**\n1. Replace {{COMPONENTS}} with the actual JSON array of components\n2. Process each component to extract the name and description\n3. Categorize components based on their functionality and description\n4. Generate the appropriate category sections with component listings\n5. Ensure all component names are properly formatted and descriptions are included\n\nMake sure to save the output in the file AGENT.md. You must use the Write tool in your response.";