@autobe/agent 0.22.1 → 0.23.1

package/lib/agent/src/orchestrate/test/structures/IAutoBeTestScenarioApplication.d.ts

@@ -1,161 +0,0 @@
-import { AutoBeOpenApi, SnakePattern } from "@autobe/interface";
-import { tags } from "typia";
-export interface IAutoBeTestScenarioApplication {
-    /**
-     * Make test scenarios for the given endpoints.
-     *
-     * @param props Properties containing the endpoints and test scenarios.
-     */
-    makeScenario(props: IAutoBeTestScenarioApplication.IProps): void;
-}
-export declare namespace IAutoBeTestScenarioApplication {
-    interface IProps {
-        /** Array of test scenario groups. */
-        scenarioGroups: IAutoBeTestScenarioApplication.IScenarioGroup[];
-    }
-    interface IScenarioGroup {
-        /**
-         * Target API endpoint to test.
-         *
-         * This must be **unique** across all scenario groups. An endpoint is
-         * identified by its `path` and `method` combination.
-         *
-         * Multiple test scenarios may exist for a single endpoint.
-         */
-        endpoint: AutoBeOpenApi.IEndpoint;
-        /**
-         * An array of test scenarios associated with the given endpoint.
-         *
-         * Each scenario represents a specific test case for the same `path` and
-         * `method`.
-         *
-         * IMPORTANT: Each scenario must be actually implementable. A scenario's
-         * implementability is determined by the existence of ALL APIs (endpoints)
-         * required to test it. This includes not only the primary endpoint being
-         * tested, but also ALL dependency endpoints needed for setup,
-         * authentication, and data preparation. If even one required dependency API
-         * is missing from the available operations, the scenario cannot be
-         * implemented and should not be generated.
-         *
-         * Example: A "test banned user login" scenario requires both a login API
-         * AND a ban user API. If the ban API doesn't exist, this scenario is not
-         * implementable regardless of database schema fields.
-         */
-        scenarios: IScenario[] & tags.MinItems<1>;
-    }
-    /**
-     * Represents a test scenario for a single API operation.
-     *
-     * This interface defines a structured, user-centric test draft that includes
-     * a descriptive function name, a detailed scenario draft, and logical
-     * dependencies on other endpoints required for context or setup.
-     *
-     * CRITICAL: All referenced endpoints MUST exist in the provided API
-     * operations. Do NOT create scenarios for non-existent APIs, even if database
-     * schema fields suggest their existence. Test scenarios must be implementable
-     * with available APIs only.
-     */
-    interface IScenario {
-        /**
-         * A detailed natural language description of how this API endpoint should
-         * be tested. This should include both successful and failure scenarios,
-         * business rule validations, edge cases, and any sequence of steps
-         * necessary to perform the test. A subsequent agent will use this draft to
-         * generate multiple concrete test cases.
-         */
-        draft: string;
-        /**
-         * Descriptive function name derived from the user scenario.
-         *
-         * The function name serves as a concise, technical identifier that clearly
-         * represents the specific user scenario being described. It should be
-         * immediately understandable and directly correspond to the user situation
-         * without requiring additional context.
-         *
-         * ## Naming Convention
-         *
-         * DO: Use snake_case naming convention.
-         *
-         * - Must start with `test_api_` prefix (mandatory requirement)
-         * - ALWAYS start with business feature, NOT action verbs
-         * - Business feature comes first, followed by scenario context
-         * - Embed action verbs within the scenario description, not at the beginning
-         *
-         * ## Content Structure
-         *
-         * Function names should follow this pattern:
-         * `test_api_[core_feature]_[specific_scenario]`
-         *
-         * Where:
-         *
-         * - `core_feature`: The main business feature or entity being tested
-         *   (customer, seller, cart, push_message, etc.)
-         * - `specific_scenario`: The specific operation or scenario context
-         *   (join_verification_not_found, login_success,
-         *   moderator_assignment_update, discountable_ticket_duplicated,
-         *   csv_export, etc.)
-         *
-         * ## Business Feature-Based Examples
-         *
-         * - `test_api_customer_join_verification_not_found` - Customer join
-         *   verification when verification code not found
-         * - `test_api_seller_login` - Seller login operation
-         * - `test_api_cart_discountable_ticket_duplicated` - Cart discountable ticket
-         *   with duplication scenario
-         * - `test_api_push_message_csv` - Push message functionality with CSV format
-         * - `test_api_product_review_update` - Product review update operation
-         *
-         * ## Clarity Guidelines
-         *
-         * - Prioritize clarity over brevity
-         * - Avoid technical jargon or implementation terms
-         * - Use terminology that reflects user perspective
-         * - Ensure the name alone conveys the user's intent
-         * - Make it understandable to non-technical stakeholders
-         * - Keep consistent with user scenario description
-         *
-         * ## Single Endpoint Alignment
-         *
-         * Function names must reflect scenarios that:
-         *
-         * - Accomplish user goals through this single endpoint only
-         * - Don't imply dependency on other API operations
-         * - Represent complete user interactions
-         */
-        functionName: string & SnakePattern;
-        /**
-         * A list of other API endpoints that this scenario logically depends on.
-         *
-         * These dependencies represent context or prerequisite conditions, such as
-         * authentication, resource creation, or data setup, that are relevant to
-         * the test. This list is not a strict execution order — if ordering is
-         * important, it must be described explicitly in the `purpose`.
-         *
-         * WARNING: Every endpoint referenced here MUST exist in the provided API
-         * operations. Do NOT reference endpoints that are not explicitly available,
-         * even if they seem logically necessary based on database schema or
-         * business logic.
-         */
-        dependencies: IDependencies[];
-    }
-    interface IDependencies {
-        /**
-         * Target API endpoint that this scenario depends on.
-         *
-         * This endpoint MUST exist in the available API operations list.
-         * Non-existent endpoints will cause test implementation failures.
-         */
-        endpoint: AutoBeOpenApi.IEndpoint;
-        /**
-         * A concise explanation of why this API call is relevant or required for
-         * the main test scenario.
-         *
-         * This should describe the contextual or setup role of the dependency, such
-         * as creating necessary data or establishing user authentication.
-         *
-         * Example: "Creates a category so that a product can be linked to it during
-         * creation."
-         */
-        purpose: string;
-    }
-}

package/lib/agent/src/orchestrate/test/structures/IAutoBeTestScenarioApplication.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"IAutoBeTestScenarioApplication.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/structures/IAutoBeTestScenarioApplication.ts"],"names":[],"mappings":""}

package/lib/agent/src/orchestrate/test/structures/IAutoBeTestScenarioArtifacts.d.ts

@@ -1,8 +0,0 @@
-import { AutoBeOpenApi } from "@autobe/interface";
-export interface IAutoBeTestScenarioArtifacts {
-    document: AutoBeOpenApi.IDocument;
-    sdk: Record<string, string>;
-    dto: Record<string, string>;
-    e2e: Record<string, string>;
-    template: string;
-}

package/lib/agent/src/orchestrate/test/structures/IAutoBeTestScenarioArtifacts.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"IAutoBeTestScenarioArtifacts.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/structures/IAutoBeTestScenarioArtifacts.ts"],"names":[],"mappings":""}

package/lib/agent/src/orchestrate/test/structures/IAutoBeTestScenarioAuthorizationRole.d.ts

@@ -1,6 +0,0 @@
-import { AutoBeOpenApi } from "@autobe/interface";
-export interface IAutoBeTestScenarioAuthorizationRole {
-    name: string;
-    join: AutoBeOpenApi.IOperation | null;
-    login: AutoBeOpenApi.IOperation | null;
-}

package/lib/agent/src/orchestrate/test/structures/IAutoBeTestScenarioAuthorizationRole.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"IAutoBeTestScenarioAuthorizationRole.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/structures/IAutoBeTestScenarioAuthorizationRole.ts"],"names":[],"mappings":""}

package/lib/agent/src/orchestrate/test/structures/IAutoBeTestWriteApplication.d.ts

@@ -1,126 +0,0 @@
-import { SnakePattern } from "@autobe/interface";
-export interface IAutoBeTestWriteApplication {
-    /**
-     * Main entry point for AI Function Call - generates complete E2E test code.
-     *
-     * The AI executes this function to perform the entire test generation
-     * workflow: scenario analysis → draft implementation → code review → final
-     * code production. This structured approach ensures high-quality,
-     * compilation-error-free test code.
-     *
-     * @param props Complete specification for test generation including scenario,
-     *   domain, and implementation steps
-     */
-    write(props: IAutoBeTestWriteApplication.IProps): void;
-}
-export declare namespace IAutoBeTestWriteApplication {
-    interface IProps {
-        /**
-         * Step 1: Strategic test planning and scenario analysis.
-         *
-         * AI analyzes the given test scenario and creates a comprehensive
-         * implementation strategy. This planning phase is crucial for generating
-         * well-structured, maintainable test code. The AI must define test
-         * methodology, data preparation, execution flow, and validation logic
-         * before proceeding to code implementation.
-         *
-         * Workflow: Input scenario → Strategic analysis → Detailed test plan
-         */
-        scenario: string;
-        /**
-         * Step 2: Functional domain classification for test organization.
-         *
-         * AI determines the appropriate domain category based on the scenario
-         * analysis. This classification drives file structure, test categorization,
-         * and logical grouping. The domain must be a single, lowercase word in
-         * snake_case format that represents the primary API resource.
-         *
-         * Workflow: Scenario analysis → Domain identification → Test organization
-         * structure
-         */
-        domain: string & SnakePattern;
-        /**
-         * Step 3: Initial TypeScript E2E test code implementation.
-         *
-         * AI generates the first working version of the test code based on the
-         * strategic plan. This draft must be compilation-error-free and follow
-         *
-         * @nestia/e2e framework conventions. The code should implement all planned
-         * test scenarios with proper async/await patterns, type safety, and
-         * comprehensive error handling.
-         *
-         * Workflow: Strategic plan → TypeScript implementation → Functional test
-         * code
-         *
-         * Critical: NO import statements, start directly with 'export async function'
-         */
-        draft: string;
-        /**
-         * Steps 4-5: Code review and final refinement process.
-         *
-         * Contains the iterative improvement workflow that transforms the initial
-         * draft into production-ready test code. This two-phase process ensures
-         * systematic quality enhancement through comprehensive review followed by
-         * targeted refinement based on identified issues.
-         *
-         * Workflow: Draft → Review analysis → Final implementation
-         */
-        revise: IReviseProps;
-    }
-    interface IReviseProps {
-        /**
-         * Step 4: Code review and quality assessment.
-         *
-         * AI performs a thorough review of the draft implementation, examining:
-         *
-         * **Compilation & Syntax:**
-         *
-         * - TypeScript compilation errors and type mismatches
-         * - Syntax errors and missing semicolons/brackets
-         * - Correct function signatures and parameter types
-         *
-         * **Framework Compliance:**
-         *
-         * - @nestia/e2e framework conventions adherence
-         * - Proper API SDK function calling patterns
-         * - Correct use of typia.assert() and TestValidator functions
-         *
-         * **Business Logic & Test Coverage:**
-         *
-         * - Complete workflow implementation (authentication → data setup → main test
-         *   → validation)
-         * - Realistic business scenarios and user journeys
-         * - Edge case handling and error condition testing
-         * - Proper data dependencies and cleanup procedures
-         *
-         * **Code Quality & Security:**
-         *
-         * - Type safety violations (any, @ts-ignore, etc.)
-         * - Variable naming and code organization
-         * - Performance considerations and resource management
-         * - Security best practices in test data generation
-         *
-         * Workflow: Draft code → Systematic analysis → Specific improvement
-         * recommendations
-         *
-         * The review must identify concrete issues with line-by-line feedback and
-         * provide actionable solutions for each problem discovered.
-         */
-        review: string;
-        /**
-         * Step 5: Final production-ready test code.
-         *
-         * AI produces the final, polished version of the test code incorporating
-         * all review feedback. This code represents the completed test
-         * implementation, ready for production deployment. All identified issues
-         * must be resolved, and the code must meet the highest quality standards.
-         *
-         * Workflow: Review feedback → Code refinement → Production-ready
-         * implementation
-         *
-         * This is the ultimate deliverable that will be used in the actual test
-         * suite.
-         */
-        final: string;
-    }
-}

package/lib/agent/src/orchestrate/test/structures/IAutoBeTestWriteApplication.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"IAutoBeTestWriteApplication.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/structures/IAutoBeTestWriteApplication.ts"],"names":[],"mappings":""}

package/lib/agent/src/orchestrate/test/structures/IAutoBeTestWriteResult.d.ts

@@ -1,7 +0,0 @@
-import { AutoBeTestScenario, AutoBeTestWriteEvent } from "@autobe/interface";
-import { IAutoBeTestScenarioArtifacts } from "./IAutoBeTestScenarioArtifacts";
-export interface IAutoBeTestWriteResult {
-    scenario: AutoBeTestScenario;
-    artifacts: IAutoBeTestScenarioArtifacts;
-    event: AutoBeTestWriteEvent;
-}

package/lib/agent/src/orchestrate/test/structures/IAutoBeTestWriteResult.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"IAutoBeTestWriteResult.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/structures/IAutoBeTestWriteResult.ts"],"names":[],"mappings":""}

package/lib/agent/src/orchestrate/test/utils/getReferenceIds.d.ts

@@ -1,5 +0,0 @@
-import { AutoBeOpenApi } from "@autobe/interface";
-export declare const getReferenceIds: (props: {
-    document: AutoBeOpenApi.IDocument;
-    operation: AutoBeOpenApi.IOperation;
-}) => string[];

package/lib/agent/src/orchestrate/test/utils/getReferenceIds.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"getReferenceIds.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/test/utils/getReferenceIds.ts"],"names":[],"mappings":";;;AACA,8CAAsD;AAE/C,MAAM,eAAe,GAAG,CAAC,KAG/B,EAAY,EAAE;IACb,MAAM,MAAM,GAAgB,IAAI,GAAG,EAAE,CAAC;IACtC,MAAM,OAAO,GAAG,CAAC,GAAW,EAAE,EAAE;QAC9B,IAAI,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC;YAAE,MAAM,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC;IAC3C,CAAC,CAAC;IAEF,KAAK,CAAC,SAAS,CAAC,UAAU,CAAC,OAAO,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,OAAO,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC;IAC3D,IAAI,KAAK,CAAC,SAAS,CAAC,WAAW,EAAE,CAAC;QAChC,4BAAkB,CAAC,KAAK,CAAC;YACvB,UAAU,EAAE,KAAK,CAAC,QAAQ,CAAC,UAAU;YACrC,MAAM,EAAE,EAAE,IAAI,EAAE,KAAK,CAAC,SAAS,CAAC,WAAW,CAAC,QAAQ,EAAE;YACtD,OAAO,EAAE,CAAC,MAAM,EAAE,EAAE;;gBAClB,IAAI,4BAAkB,CAAC,QAAQ,CAAC,MAAM,CAAC,KAAK,KAAK;oBAAE,OAAO;gBAC1D,KAAK,MAAM,GAAG,IAAI,MAAM,CAAC,IAAI,CAAC,MAAA,MAAM,CAAC,UAAU,mCAAI,EAAE,CAAC;oBAAE,OAAO,CAAC,GAAG,CAAC,CAAC;YACvE,CAAC;SACF,CAAC,CAAC;IACL,CAAC;IACD,OAAO,KAAK,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC;AAC5B,CAAC,CAAC;AArBW,QAAA,eAAe,mBAqB1B"}

package/lib/agent/src/structures/IAutoBeConfig.d.ts

@@ -1,75 +0,0 @@
-/**
- * Interface defining behavioral configuration for AutoBeAgent localization and
- * context.
- *
- * This interface customizes the agent's communication style, language
- * preferences, and geographical context to provide personalized vibe coding
- * experiences. The configuration enables culturally appropriate interactions
- * and regionally aware development decisions throughout the automated
- * development pipeline.
- *
- * Locale and timezone settings influence not only the language of communication
- * but also contextual understanding of regulatory requirements, business
- * practices, and temporal considerations that may affect requirements analysis,
- * database design, API specifications, and implementation approaches.
- *
- * @author Samchon
- */
-export interface IAutoBeConfig {
-    /** @default 4 */
-    retry?: number;
-    /**
-     * Language and cultural locale preference for AI agent communication.
-     *
-     * Configures the language and cultural context for all AI assistant responses
-     * throughout the vibe coding process. When specified, the agent will
-     * communicate in the preferred language while respecting cultural conventions
-     * and linguistic nuances during requirements gathering, progress updates, and
-     * guidance provision.
-     *
-     * The locale setting also influences the agent's understanding of regional
-     * business practices, regulatory considerations, and cultural expectations
-     * that may impact software design decisions and implementation approaches.
-     *
-     * Common formats follow BCP 47 language tags such as "en-US", "ko-KR",
-     * "ja-JP", "zh-CN", "de-DE", etc. Platform-specific detection methods:
-     *
-     * - Browser: `navigator.language`
-     * - Node.js: `process.env.LANG.split(".")[0]`
-     *
-     * @default System locale or "en" if unavailable
-     */
-    locale?: string;
-    /**
-     * Geographic timezone for temporal context and time-sensitive operations.
-     *
-     * Provides timezone awareness for proper handling of time-related
-     * considerations during the vibe coding process. This includes scheduling
-     * references, temporal business logic requirements, timestamp handling in
-     * generated code, and time-based communications that need to be
-     * contextualized for the user's local time.
-     *
-     * Timezone awareness ensures that generated applications properly handle time
-     * zones, that scheduling-related requirements are interpreted correctly, and
-     * that temporal references in documentation and code comments reflect the
-     * user's geographical context.
-     *
-     * Format follows IANA Time Zone Database identifiers such as
-     * "America/New_York", "Asia/Seoul", "Europe/London", "Pacific/Auckland", etc.
-     * Platform detection: `Intl.DateTimeFormat().resolvedOptions().timeZone`
-     *
-     * @default System timezone or "UTC" if unavailable
-     */
-    timezone?: string;
-    /**
-     * Backoff strategy for retrying failed operations.
-     *
-     * Defines the logic for retrying failed operations when the agent encounters
-     * errors. This includes retrying function calls, API requests, and other
-     * operations that may fail due to temporary issues.
-     */
-    backoffStrategy?: (props: {
-        count: number;
-        error: unknown;
-    }) => number;
-}

package/lib/agent/src/structures/IAutoBeConfig.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"IAutoBeConfig.js","sourceRoot":"","sources":["../../../../src/structures/IAutoBeConfig.ts"],"names":[],"mappings":""}

package/lib/agent/src/structures/IAutoBeProps.d.ts

@@ -1,109 +0,0 @@
-import { AutoBeHistory, IAutoBeCompiler, IAutoBeCompilerListener, IAutoBeTokenUsageJson } from "@autobe/interface";
-import { ILlmSchema } from "@samchon/openapi";
-import { AutoBeTokenUsage } from "../context/AutoBeTokenUsage";
-import { IAutoBeConfig } from "./IAutoBeConfig";
-import { IAutoBeVendor } from "./IAutoBeVendor";
-/**
- * Configuration properties for initializing an AutoBeAgent instance.
- *
- * This interface defines all the essential parameters required to create and
- * configure an AutoBeAgent for vibe coding operations. The properties establish
- * the AI model capabilities, vendor connectivity, compilation infrastructure,
- * behavioral context, and optional session continuity through conversation
- * histories.
- *
- * The configuration enables type-safe AI function calling through
- * model-specific schema generation, ensures compatibility with various AI
- * service providers, and provides the compilation tools necessary for the
- * sophisticated AST-based development pipeline that transforms conversations
- * into working software.
- *
- * @author Samchon
- */
-export interface IAutoBeProps<Model extends ILlmSchema.Model> {
-    /**
-     * AI model type specification for type-safe function calling schema
-     * generation.
-     *
-     * Determines the specific AI model schema used for generating function
-     * calling interfaces through
-     * [`typia.llm.application()`](https://typia.io/docs/llm/application). This
-     * type parameter ensures compile-time type safety and enables model-specific
-     * optimizations in the AI function calling interface generation process.
-     *
-     * Common values include "chatgpt" for OpenAI models, "claude" for Anthropic
-     * models, "deepseek" for DeepSeek models, and "llama" for Meta Llama models.
-     * The choice affects function calling capabilities, parameter limitations,
-     * and schema requirements throughout the vibe coding pipeline.
-     *
-     * Note that Google Gemini ("gemini") is not supported due to its lack of
-     * reference types and union types support required for OpenAPI document
-     * composition in the vibe coding process.
-     */
-    model: Model;
-    /**
-     * AI vendor configuration for service provider integration.
-     *
-     * Defines the complete AI service connection including the OpenAI SDK
-     * instance, model identifier, request options, and concurrency controls. This
-     * configuration enables the AutoBeAgent to connect with various AI providers
-     * while maintaining consistent functionality across the entire automated
-     * development workflow.
-     *
-     * The vendor settings determine the AI capabilities available for
-     * requirements analysis, database design, API specification, testing, and
-     * implementation phases of the vibe coding process.
-     */
-    vendor: IAutoBeVendor;
-    /**
-     * Compiler factory function for TypeScript, Prisma, and OpenAPI operations.
-     *
-     * Factory function that creates compiler instances required for the
-     * sophisticated AST-based development pipeline. The compiler handles
-     * validation, transformation, and code generation across all development
-     * phases including Prisma schema compilation, OpenAPI document validation,
-     * and TypeScript code compilation.
-     *
-     * For high-performance scenarios with multiple concurrent users, the compiler
-     * can be separated into dedicated worker processes to prevent blocking the
-     * main agent during computationally intensive compilation operations.
-     */
-    compiler: (listener: IAutoBeCompilerListener) => IAutoBeCompiler | Promise<IAutoBeCompiler>;
-    /**
-     * Optional conversation and development histories for session continuation.
-     *
-     * Enables resuming previous vibe coding sessions by providing the
-     * chronological record of past conversations, development activities, and
-     * generated artifacts. When provided, the agent reconstructs its internal
-     * state from these histories, allowing seamless continuation of development
-     * work.
-     *
-     * This capability supports iterative development workflows where users can
-     * return to modify, enhance, or extend previously generated applications
-     * while maintaining full context of earlier decisions and implementations.
-     */
-    histories?: AutoBeHistory[] | undefined;
-    /**
-     * Optional behavioral configuration for localization and context.
-     *
-     * Customizes the agent's communication style, language preferences, and
-     * geographical context to provide personalized vibe coding experiences.
-     * Configuration includes locale settings for internationalized responses and
-     * timezone information for temporal context awareness.
-     *
-     * These settings influence how the agent communicates with users, interprets
-     * regional requirements (such as regulatory considerations), and handles
-     * time-sensitive operations throughout the development process.
-     */
-    config?: IAutoBeConfig | undefined;
-    /**
-     * Token usage information.
-     *
-     * You can start token usage tracing by assigning this property.
-     *
-     * If you assign {@link IAutoBeTokenUsageJson} value, the token usage tracing
-     * would be from the value. Otherwise you assign the {@link AutoBeTokenUsage}
-     * typed instance, the tracing would be binded to the instance.
-     */
-    tokenUsage?: IAutoBeTokenUsageJson | AutoBeTokenUsage | undefined;
-}

package/lib/agent/src/structures/IAutoBeProps.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"IAutoBeProps.js","sourceRoot":"","sources":["../../../../src/structures/IAutoBeProps.ts"],"names":[],"mappings":""}

package/lib/agent/src/structures/IAutoBeVendor.d.ts

@@ -1,87 +0,0 @@
-import OpenAI from "openai";
-/**
- * Interface representing AI vendor configuration for the AutoBeAgent.
- *
- * Defines the connection parameters and settings required to integrate with AI
- * service providers that power the vibe coding pipeline. While utilizing the
- * OpenAI SDK as the connection interface, this configuration supports various
- * LLM vendors beyond OpenAI through flexible endpoint and authentication
- * configuration, enabling integration with Claude, DeepSeek, Meta Llama, and
- * other providers that follow OpenAI-compatible API patterns.
- *
- * The vendor configuration determines the AI capabilities available throughout
- * the entire automated development workflow, from requirements analysis and
- * database design through API specification, testing, and final implementation.
- * Different vendors may offer varying performance characteristics, cost
- * structures, and feature support that can be optimized for specific vibe
- * coding needs.
- *
- * Concurrent request management is built-in to prevent API rate limiting and
- * optimize resource utilization across multiple development phases and parallel
- * operations within the vibe coding pipeline.
- *
- * @author Samchon
- */
-export interface IAutoBeVendor {
-    /**
-     * OpenAI SDK instance configured for the target AI vendor.
-     *
-     * Provides the API connection interface used by the AutoBeAgent to
-     * communicate with AI services. While this uses the OpenAI SDK, it can be
-     * configured to connect with various LLM providers by setting the appropriate
-     * `baseURL` and authentication credentials. The SDK serves as a universal
-     * connector that abstracts the underlying API communication protocols.
-     *
-     * For non-OpenAI vendors, configure the SDK with the vendor's API endpoint
-     * and authentication requirements to enable seamless integration with the
-     * vibe coding system.
-     */
-    api: OpenAI;
-    /**
-     * Specific model identifier to use for AI operations.
-     *
-     * Specifies the exact model name or identifier that should be used for vibe
-     * coding tasks. Supports both official OpenAI chat models and custom model
-     * identifiers for third-party hosting services, cloud providers, or
-     * alternative LLM vendors. The model choice significantly impacts the
-     * quality, performance, and cost of the automated development process.
-     *
-     * Examples include "gpt-4", "gpt-3.5-turbo" for OpenAI, or vendor-specific
-     * identifiers like "claude-3-sonnet", "deepseek-chat-v3", "llama3.3-70b" when
-     * using alternative providers through compatible APIs.
-     */
-    model: OpenAI.ChatModel | ({} & string);
-    /**
-     * Optional request configuration for API calls.
-     *
-     * Additional request options that will be applied to all API calls made
-     * through the OpenAI SDK. This can include custom headers, timeouts, retry
-     * policies, or other HTTP client configuration that may be required for
-     * specific vendor integrations or enterprise environments.
-     *
-     * These options provide fine-grained control over the API communication
-     * behavior and can be used to optimize performance or meet specific
-     * infrastructure requirements.
-     */
-    options?: OpenAI.RequestOptions | undefined;
-    /**
-     * Maximum number of concurrent API requests allowed.
-     *
-     * Controls the concurrency level for AI API calls to prevent rate limiting,
-     * manage resource consumption, and optimize system performance. The vibe
-     * coding pipeline may make multiple parallel requests during development
-     * phases, and this setting ensures controlled resource utilization.
-     *
-     * A reasonable default provides balanced performance while respecting typical
-     * API rate limits. Lower values reduce resource consumption but may slow
-     * development progress, while higher values can improve performance but risk
-     * hitting rate limits or overwhelming the AI service.
-     *
-     * Set to undefined to disable concurrency limiting, allowing unlimited
-     * parallel requests (use with caution based on your API limits and
-     * infrastructure capacity).
-     *
-     * @default 16
-     */
-    semaphore?: number | undefined;
-}

package/lib/agent/src/structures/IAutoBeVendor.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"IAutoBeVendor.js","sourceRoot":"","sources":["../../../../src/structures/IAutoBeVendor.ts"],"names":[],"mappings":""}

package/lib/agent/src/utils/arrayToRecord.d.ts

@@ -1,17 +0,0 @@
-/**
- * Converts an array of key-value pairs (entries) into a Record.
- *
- * @param entries - Array of [key, value] tuples
- * @returns Record object from the entries
- */
-export declare function arrayToRecord<V>(entries: Array<[string, V]>): Record<string, V>;
-/**
- * Converts an array of objects into a Record using specified key and value
- * properties.
- *
- * @param items - Array of items to convert
- * @param keyProp - Property name to use as the key
- * @param valueProp - Property name to use as the value
- * @returns Record object with the extracted key-value pairs
- */
-export declare function arrayToRecord<T, K extends keyof T, V extends keyof T>(items: T[], keyProp: K, valueProp: V): Record<string, T[V]>;

package/lib/agent/src/utils/arrayToRecord.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"arrayToRecord.js","sourceRoot":"","sources":["../../../../src/utils/arrayToRecord.ts"],"names":[],"mappings":";;AAyBA,sCAuBC;AAvBD,SAAgB,aAAa,CAC3B,KAAiC,EACjC,OAAW,EACX,SAAa;IAEb,0CAA0C;IAC1C,IAAI,KAAK,CAAC,MAAM,GAAG,CAAC,IAAI,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,IAAI,KAAK,CAAC,CAAC,CAAC,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACzE,OAAQ,KAA8B,CAAC,MAAM,CAC3C,CAAC,GAAG,EAAE,CAAC,GAAG,EAAE,KAAK,CAAC,EAAE,EAAE,CAAC,MAAM,CAAC,MAAM,CAAC,GAAG,EAAE,EAAE,CAAC,GAAG,CAAC,EAAE,KAAK,EAAE,CAAC,EAC3D,EAAE,CACH,CAAC;IACJ,CAAC;IAED,2DAA2D;IAC3D,IAAI,OAAO,KAAK,SAAS,IAAI,SAAS,KAAK,SAAS,EAAE,CAAC;QACrD,OAAQ,KAAa;aAClB,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC;YACd,CAAC,MAAM,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC,CAAC,EAAE,IAAI,CAAC,SAAS,CAAC;SACzC,CAAC,CAAC;aACF,MAAM,CAAC,CAAC,GAAG,EAAE,GAAG,EAAE,EAAE,CAAC,MAAM,CAAC,MAAM,CAAC,GAAG,EAAE,GAAG,CAAC,EAAE,EAAE,CAAC,CAAC;IACvD,CAAC;IAED,MAAM,IAAI,KAAK,CAAC,qCAAqC,CAAC,CAAC;AACzD,CAAC"}