@builder.io/dev-tools 1.17.24-dev.202511131337.7305ffc47 → 1.17.24-dev.202511131623.844feace3

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

@@ -1,2 +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## API\n**Types**: Interfaces related to the component including all props, methods, or children along with descriptions.\n**Dependencies:** Other components that must be used\n**Provides:** Context/state this component provides to children. Only required for coupled components.\n\n## Usage Examples\nInclude examples that show how to fully use the component. At a minimum, you must include the following examples:\n\n- Basic usage including how to import the component if applicable\n- Usage with any dependency components\n- Variations with conditional rendering, different prop combinations, etc\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 type 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.";
+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## API\n**Types**: Interfaces related to the component including all props, methods, or children along with descriptions.\n**Dependencies:** Other components that must be used\n**Provides:** Context/state this component provides to children. Only required for coupled components.\n\n## Usage Examples\nInclude examples that show how to fully use the component. At a minimum, you must include the following examples:\n\n- Basic usage including how to import the component if applicable\n- Usage with any dependency components\n- Variations with conditional rendering, different prop combinations, etc\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 type 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/dev-server-url-parser.d.ts

@@ -1,6 +1,6 @@
 export interface DevServerUrlInfo {
-	url: string;
-	port: number;
+    url: string;
+    port: number;
 }
 /**
  * Parse dev server output to extract URL and port information
@@ -9,7 +9,4 @@ export interface DevServerUrlInfo {
  * @param customPatterns - Optional array of custom regex patterns to try first
  * @returns Object with url and port, or null if no valid URL found
  */
-export declare function parseDevServerOutput(
-	output: string,
-	customPatterns?: string[],
-): DevServerUrlInfo | null;
+export declare function parseDevServerOutput(output: string, customPatterns?: string[]): DevServerUrlInfo | null;

package/types/cli/utils/env-capture.d.ts

@@ -2,23 +2,23 @@
  * Options for capturing environment variables from a setup command
  */
 export interface EnvCaptureOptions {
-	/** The command to wrap with env capture */
-	command: string;
+    /** The command to wrap with env capture */
+    command: string;
 }
 /**
  * Result of environment capture
  */
 export interface EnvCaptureResult {
-	/** The modified command that includes env capture */
-	command: string;
-	/** Path to the temporary file where env will be captured */
-	envFilePath: string;
-	/**
-	 * Function to get the captured environment variables.
-	 * This will read, parse, and cleanup the env file in one call.
-	 * Returns undefined if the env file couldn't be read.
-	 */
-	getCapturedEnv: () => Promise<Record<string, string> | undefined>;
+    /** The modified command that includes env capture */
+    command: string;
+    /** Path to the temporary file where env will be captured */
+    envFilePath: string;
+    /**
+     * Function to get the captured environment variables.
+     * This will read, parse, and cleanup the env file in one call.
+     * Returns undefined if the env file couldn't be read.
+     */
+    getCapturedEnv: () => Promise<Record<string, string> | undefined>;
 }
 /**
  * Wraps a command with environment variable capture at the end.
@@ -38,9 +38,7 @@ export interface EnvCaptureResult {
  * const env = await getCapturedEnv();
  * ```
  */
-export declare function wrapCommandWithEnvCapture(
-	options: EnvCaptureOptions,
-): EnvCaptureResult;
+export declare function wrapCommandWithEnvCapture(options: EnvCaptureOptions): EnvCaptureResult;
 /**
  * Parses an environment file into a key-value object.
  * Handles multi-line values and empty lines.
@@ -54,9 +52,7 @@ export declare function wrapCommandWithEnvCapture(
  * console.log(env.PATH); // "/usr/bin:/bin"
  * ```
  */
-export declare function parseEnvFile(
-	filePath: string,
-): Promise<Record<string, string>>;
+export declare function parseEnvFile(filePath: string): Promise<Record<string, string>>;
 /**
  * Parses environment variable content into a key-value object.
  * This is the core parsing logic extracted for easier testing.
@@ -73,9 +69,7 @@ export declare function parseEnvFile(
  * // { PATH: '/usr/bin', HOME: '/home/user' }
  * ```
  */
-export declare function parseEnvContent(
-	content: string,
-): Record<string, string>;
+export declare function parseEnvContent(content: string): Record<string, string>;
 /**
  * Cleans up the environment capture file.
  * Call this after parsing to remove temporary files.

package/types/cli/utils/feature-flags.d.ts

@@ -1,4 +1,2 @@
-export declare function setFeatureFlags(
-	featureFlags: Record<string, boolean>,
-): void;
+export declare function setFeatureFlags(featureFlags: Record<string, boolean>): void;
 export declare function getFeatureFlag(featureFlag: string): boolean;

package/types/cli/utils/file-overrides-manager.d.ts

@@ -1,26 +1,26 @@
 export interface FileOverride {
-	/**
-	 * Path where the file should be written.
-	 * - Absolute paths: "/app/.env", "/etc/config/app.conf"
-	 * - Tilde expansion: "~/.config/app.json" (expands to home directory)
-	 * - Relative paths: "./file.txt", "config.json" (resolved against working directory)
-	 */
-	path: string;
-	/**
-	 * Content to write to the file.
-	 */
-	content: string;
+    /**
+     * Path where the file should be written.
+     * - Absolute paths: "/app/.env", "/etc/config/app.conf"
+     * - Tilde expansion: "~/.config/app.json" (expands to home directory)
+     * - Relative paths: "./file.txt", "config.json" (resolved against working directory)
+     */
+    path: string;
+    /**
+     * Content to write to the file.
+     */
+    content: string;
 }
 export interface SentryLike {
-	captureException: (error: unknown) => void;
+    captureException: (error: unknown) => void;
 }
 export interface ApplyFileOverridesResult {
-	success: boolean;
-	appliedFiles: string[];
-	failedFiles: Array<{
-		path: string;
-		error: string;
-	}>;
+    success: boolean;
+    appliedFiles: string[];
+    failedFiles: Array<{
+        path: string;
+        error: string;
+    }>;
 }
 /**
  * Expand tilde (~) in file path to home directory
@@ -35,10 +35,7 @@ export declare function expandTildePath(filePath: string): string;
  * @param workingDirectory - Optional working directory for resolving relative paths
  * @returns Resolved absolute path
  */
-export declare function resolveFilePath(
-	filePath: string,
-	workingDirectory?: string,
-): string;
+export declare function resolveFilePath(filePath: string, workingDirectory?: string): string;
 /**
  * Validate that a file path can be resolved to an absolute path
  * Supports tilde (~) expansion and relative paths (when workingDirectory is provided)
@@ -46,10 +43,7 @@ export declare function resolveFilePath(
  * @param workingDirectory - Optional working directory for resolving relative paths
  * @returns true if valid, false otherwise
  */
-export declare function isValidFilePath(
-	filePath: string,
-	workingDirectory?: string,
-): boolean;
+export declare function isValidFilePath(filePath: string, workingDirectory?: string): boolean;
 /**
  * Apply multiple file overrides to the filesystem.
  * This function will:
@@ -64,11 +58,7 @@ export declare function isValidFilePath(
  * @param sentry - Optional Sentry instance for error logging
  * @returns Object with overall success status and details for each file
  */
-export declare function applyFileOverrides(
-	overrides: FileOverride[],
-	workingDirectory?: string,
-	sentry?: SentryLike,
-): ApplyFileOverridesResult;
+export declare function applyFileOverrides(overrides: FileOverride[], workingDirectory?: string, sentry?: SentryLike): ApplyFileOverridesResult;
 /**
  * Read a file and return its content
  * Supports tilde (~) expansion and relative paths.
@@ -76,10 +66,7 @@ export declare function applyFileOverrides(
  * @param workingDirectory - Optional working directory for resolving relative paths
  * @returns The file content or null if it cannot be read
  */
-export declare function readFileOverride(
-	filePath: string,
-	workingDirectory?: string,
-): string | null;
+export declare function readFileOverride(filePath: string, workingDirectory?: string): string | null;
 /**
  * Check if a file exists at the given path
  * Supports tilde (~) expansion and relative paths.
@@ -87,7 +74,4 @@ export declare function readFileOverride(
  * @param workingDirectory - Optional working directory for resolving relative paths
  * @returns true if the file exists, false otherwise
  */
-export declare function fileOverrideExists(
-	filePath: string,
-	workingDirectory?: string,
-): boolean;
+export declare function fileOverrideExists(filePath: string, workingDirectory?: string): boolean;

package/types/cli/utils/git.d.ts

@@ -2,33 +2,21 @@ import type { DevToolsSys } from "../../types";
 import type { Credentials } from "../credentials";
 import type { GitConfigs } from "$/ai-utils";
 export interface RunCommandOptions {
-	cwd?: string;
-	debug?: boolean;
-	sys: DevToolsSys;
-	timeout?: number;
-	stdin?: string;
-	retry?: number;
+    cwd?: string;
+    debug?: boolean;
+    sys: DevToolsSys;
+    timeout?: number;
+    stdin?: string;
+    retry?: number;
 }
-type FetchGitConfigsResult =
-	| {
-			success: true;
-			gitConfigs: GitConfigs;
-	  }
-	| {
-			success: false;
-			error: Error;
-	  };
-export declare function runCommand(
-	cmd: string,
-	args: string[],
-	opts: RunCommandOptions,
-): Promise<string>;
-export declare const isGitRepoCorrupted: (
-	stdout: string,
-	stderr: string,
-) => boolean;
-export declare function fetchGitConfigs(
-	credentials: Credentials,
-	projectId: string,
-): Promise<FetchGitConfigsResult>;
+type FetchGitConfigsResult = {
+    success: true;
+    gitConfigs: GitConfigs;
+} | {
+    success: false;
+    error: Error;
+};
+export declare function runCommand(cmd: string, args: string[], opts: RunCommandOptions): Promise<string>;
+export declare const isGitRepoCorrupted: (stdout: string, stderr: string) => boolean;
+export declare function fetchGitConfigs(credentials: Credentials, projectId: string): Promise<FetchGitConfigsResult>;
 export {};

package/types/cli/utils/hosts-file-manager.d.ts

@@ -1,9 +1,9 @@
 export interface HostEntry {
-	hostname: string;
-	ip?: string;
+    hostname: string;
+    ip?: string;
 }
 export interface SentryLike {
-	captureException: (error: unknown) => void;
+    captureException: (error: unknown) => void;
 }
 /**
  * Check if a hostname is localhost or 127.0.0.1
@@ -20,10 +20,7 @@ export declare function isLocalhost(hostname: string): boolean;
  * @param sentry - Optional Sentry instance for error logging
  * @returns true if successful, false otherwise
  */
-export declare function updateHostsFile(
-	entries: HostEntry[],
-	sentry?: SentryLike,
-): boolean;
+export declare function updateHostsFile(entries: HostEntry[], sentry?: SentryLike): boolean;
 /**
  * Remove all managed entries from the hosts file
  * @param sentry - Optional Sentry instance for error logging

package/types/cli/utils/lock-file.d.ts

@@ -1,12 +1,12 @@
 import type { DevToolsSys } from "@builder.io/dev-tools/core";
 import type { FusionConfig } from "$/ai-utils";
 export interface LockFileData {
-	cwd: string;
-	projectId?: string;
-	branchId?: string;
-	pid: number;
-	createdAt: number;
-	port?: number;
+    cwd: string;
+    projectId?: string;
+    branchId?: string;
+    pid: number;
+    createdAt: number;
+    port?: number;
 }
 export type LockConflictBehavior = "replace" | "exit" | "kill";
 /**
@@ -25,7 +25,4 @@ export type LockConflictBehavior = "replace" | "exit" | "kill";
  * @param projectId - Optional project ID
  * @param branchId - Optional branch ID/name
  */
-export declare function registerLock(
-	sys: DevToolsSys,
-	fusionConfig: FusionConfig,
-): Promise<void>;
+export declare function registerLock(sys: DevToolsSys, fusionConfig: FusionConfig): Promise<void>;

package/types/cli/utils/parseGitDiff.d.ts

@@ -5,7 +5,4 @@ import type { ApplyActionsResult } from "../../../ai-utils/src/codegen";
  * @param includeFilesOnly - If true, only populate action and filePath properties
  * @returns Array of ApplyActionsResult objects
  */
-export declare function parseGitDiffToApplyActions(
-	diff: string,
-	includeFilesOnly?: boolean,
-): ApplyActionsResult[];
+export declare function parseGitDiffToApplyActions(diff: string, includeFilesOnly?: boolean): ApplyActionsResult[];

package/types/cli/utils/process-tracker.d.ts

@@ -1,11 +1,4 @@
-import {
-	ChildProcess,
-	type ChildProcessWithoutNullStreams,
-	type ChildProcessByStdio,
-	type SpawnOptions,
-	type StdioPipe,
-	type StdioNull,
-} from "child_process";
+import { ChildProcess, type ChildProcessWithoutNullStreams, type ChildProcessByStdio, type SpawnOptions, type StdioPipe, type StdioNull } from "child_process";
 import type { Readable } from "stream";
 import type { DevToolsSys } from "../../types";
 import type { DevCommandProcess } from "../launch/dev-server-orchestrator";
@@ -14,81 +7,65 @@ import type { DevCommandProcess } from "../launch/dev-server-orchestrator";
  * and ensures they are killed when the main process exits
  */
 declare class ProcessTracker {
-	private processes;
-	private cleanupHandlersRegistered;
-	constructor();
-	/**
-	 * Register a spawned process for tracking and cleanup
-	 */
-	track(childProcess: ChildProcess): void;
-	/**
-	 * Untrack a process (useful if you're managing it manually)
-	 */
-	untrack(childProcess: ChildProcess): void;
-	/**
-	 * Kill all tracked processes
-	 * @param sys - DevToolsSys for logging and Sentry integration
-	 */
-	killAll(sys?: DevToolsSys): Promise<void>;
-	/**
-	 * Register cleanup handlers for various exit signals
-	 */
-	private registerCleanupHandlers;
-	/**
-	 * Get the number of tracked processes
-	 */
-	get count(): number;
+    private processes;
+    private cleanupHandlersRegistered;
+    constructor();
+    /**
+     * Register a spawned process for tracking and cleanup
+     */
+    track(childProcess: ChildProcess): void;
+    /**
+     * Untrack a process (useful if you're managing it manually)
+     */
+    untrack(childProcess: ChildProcess): void;
+    /**
+     * Kill all tracked processes
+     * @param sys - DevToolsSys for logging and Sentry integration
+     */
+    killAll(sys?: DevToolsSys): Promise<void>;
+    /**
+     * Register cleanup handlers for various exit signals
+     */
+    private registerCleanupHandlers;
+    /**
+     * Get the number of tracked processes
+     */
+    get count(): number;
 }
 export declare const processTracker: ProcessTracker;
 /**
  * Options for trackedSpawn function
  */
 export interface TrackedSpawnOptions {
-	/** The command to run */
-	command: string;
-	/** Arguments for the command */
-	args?: readonly string[];
-	/** Spawn options */
-	options?: SpawnOptions;
+    /** The command to run */
+    command: string;
+    /** Arguments for the command */
+    args?: readonly string[];
+    /** Spawn options */
+    options?: SpawnOptions;
 }
 /**
  * Wrapper around child_process.spawn that automatically tracks the spawned process
  * and ensures it gets killed when the main process exits
  */
-export declare function trackedSpawn(
-	config: TrackedSpawnOptions & {
-		options: SpawnOptions & {
-			stdio: "pipe" | [StdioPipe, StdioPipe, StdioPipe];
-		};
-	},
-): ChildProcessWithoutNullStreams;
-export declare function trackedSpawn(
-	config: TrackedSpawnOptions & {
-		options: SpawnOptions & {
-			stdio: [StdioNull | "ignore", StdioPipe, StdioPipe];
-		};
-	},
-): ChildProcessByStdio<null, Readable, Readable>;
+export declare function trackedSpawn(config: TrackedSpawnOptions & {
+    options: SpawnOptions & {
+        stdio: "pipe" | [StdioPipe, StdioPipe, StdioPipe];
+    };
+}): ChildProcessWithoutNullStreams;
+export declare function trackedSpawn(config: TrackedSpawnOptions & {
+    options: SpawnOptions & {
+        stdio: [StdioNull | "ignore", StdioPipe, StdioPipe];
+    };
+}): ChildProcessByStdio<null, Readable, Readable>;
 export declare function trackedSpawn(config: TrackedSpawnOptions): ChildProcess;
-export declare function safeSpawn(
-	shell: string,
-	command: string,
-	options: SpawnOptions & {
-		stdio: "pipe" | [StdioPipe, StdioPipe, StdioPipe];
-	},
-): ChildProcessWithoutNullStreams;
-export declare function safeSpawn(
-	shell: string,
-	command: string,
-	options: SpawnOptions & {
-		stdio: [StdioNull | "ignore", StdioPipe, StdioPipe];
-	},
-): ChildProcessByStdio<null, Readable, Readable>;
-export declare function safeSpawn(
-	shell: string,
-	command: string,
-	options: SpawnOptions,
-): ChildProcess;
+export declare function safeSpawn(shell: string, command: string, options: SpawnOptions & {
+    stdio: "pipe" | [StdioPipe, StdioPipe, StdioPipe];
+}): ChildProcessWithoutNullStreams;
+export declare function safeSpawn(shell: string, command: string, options: SpawnOptions & {
+    stdio: [StdioNull | "ignore", StdioPipe, StdioPipe];
+}): ChildProcessByStdio<null, Readable, Readable>;
+export declare function safeSpawn(shell: string, command: string, options: SpawnOptions): ChildProcess;
 export declare const getTempFolder: () => string;
 export declare const cleanupTempFolder: () => boolean;
 /**
@@ -98,23 +75,12 @@ export declare const isMultiLineCommand: (command: string) => boolean;
 /**
  * Creates a temporary script file for multi-line commands
  */
-export declare const createTempScript: (
-	command: string,
-	shell: string,
-) => string;
+export declare const createTempScript: (command: string, shell: string) => string;
 export declare const getTempScriptPath: (extension: string) => string;
 /**
  * Cleans up a temporary script file
  */
 export declare const cleanupTempScript: (scriptPath: string) => void;
-export declare const getCommandWithShellArgs: (
-	command: string,
-	shell: string,
-) => string[];
-export declare function killProcess(
-	sys: DevToolsSys,
-	procOrPid: ChildProcess | DevCommandProcess | number | undefined,
-	abortSignal?: AbortSignal,
-	timeout?: number,
-): Promise<boolean>;
+export declare const getCommandWithShellArgs: (command: string, shell: string) => string[];
+export declare function killProcess(sys: DevToolsSys, procOrPid: ChildProcess | DevCommandProcess | number | undefined, abortSignal?: AbortSignal, timeout?: number): Promise<boolean>;
 export {};

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

@@ -1,2 +1 @@
-export declare const REPO_INDEXING_AGENT_PROMPT =
-	"# 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## Components\n\n{{COMPONENTS}}\n{{ICONS}}\n{{TOKENS}}\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.";
+export declare const REPO_INDEXING_AGENT_PROMPT = "# 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## Components\n\n{{COMPONENTS}}\n{{ICONS}}\n{{TOKENS}}\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.";

package/types/cli/utils/terminal-buffer.d.ts

@@ -3,27 +3,27 @@
  * to properly represent what would be shown in a real terminal
  */
 export declare class TerminalBuffer {
-	private lines;
-	private currentLine;
-	private currentColumn;
-	private maxLines;
-	private maxColumns;
-	private chunks;
-	constructor(maxLines?: number, maxColumns?: number);
-	write(data: string): void;
-	private ensureLineExists;
-	getWrite(): string;
-	getContent(): string;
-	clear(): void;
-	/**
-	 * Get current cursor position for testing/debugging
-	 */
-	getCursorPosition(): {
-		line: number;
-		column: number;
-	};
-	/**
-	 * Get the current number of lines for testing/debugging
-	 */
-	getLineCount(): number;
+    private lines;
+    private currentLine;
+    private currentColumn;
+    private maxLines;
+    private maxColumns;
+    private chunks;
+    constructor(maxLines?: number, maxColumns?: number);
+    write(data: string): void;
+    private ensureLineExists;
+    getWrite(): string;
+    getContent(): string;
+    clear(): void;
+    /**
+     * Get current cursor position for testing/debugging
+     */
+    getCursorPosition(): {
+        line: number;
+        column: number;
+    };
+    /**
+     * Get the current number of lines for testing/debugging
+     */
+    getLineCount(): number;
 }

package/types/cli/utils/workspace-path-resolver.d.ts

@@ -1,19 +1,16 @@
-import type {
-	WorkspaceFolder,
-	WorkspaceConfiguration,
-} from "@builder.io/ai-utils";
+import type { WorkspaceFolder, WorkspaceConfiguration } from "@builder.io/ai-utils";
 import type { DevToolsSys } from "../../types";
 export interface ResolveWorkspacePathOptions {
-	filePath: string;
-	forceWorkspace?: boolean;
-	workspace?: WorkspaceConfiguration;
-	workingDirectory: string;
-	sys: DevToolsSys;
-	canCollapseWorkspace?: boolean;
+    filePath: string;
+    forceWorkspace?: boolean;
+    workspace?: WorkspaceConfiguration;
+    workingDirectory: string;
+    sys: DevToolsSys;
+    canCollapseWorkspace?: boolean;
 }
 export interface ResolveWorkspacePathResult {
-	resolvedPath: string;
-	workspaceFolder?: WorkspaceFolder;
+    resolvedPath: string;
+    workspaceFolder?: WorkspaceFolder;
 }
 /**
  * Resolves a workspace file path to its actual file system path.
@@ -52,15 +49,13 @@ export interface ResolveWorkspacePathResult {
  * // }
  * ```
  */
-export declare function resolveWorkspacePath(
-	options: ResolveWorkspacePathOptions,
-): ResolveWorkspacePathResult;
+export declare function resolveWorkspacePath(options: ResolveWorkspacePathOptions): ResolveWorkspacePathResult;
 export interface AbsolutePathToWorkspaceUrlOptions {
-	absolutePath: string;
-	workspace?: WorkspaceConfiguration;
-	workingDirectory: string;
-	sys: DevToolsSys;
-	canCollapseWorkspace?: boolean;
+    absolutePath: string;
+    workspace?: WorkspaceConfiguration;
+    workingDirectory: string;
+    sys: DevToolsSys;
+    canCollapseWorkspace?: boolean;
 }
 /**
  * Converts an absolute file system path to a workspace URL if possible.
@@ -94,6 +89,4 @@ export interface AbsolutePathToWorkspaceUrlOptions {
  * // Returns: 'frontend/src/components/Button.tsx'
  * ```
  */
-export declare function absolutePathToWorkspaceUrl(
-	options: AbsolutePathToWorkspaceUrlOptions,
-): string | undefined;
+export declare function absolutePathToWorkspaceUrl(options: AbsolutePathToWorkspaceUrlOptions): string | undefined;