import { AutoBeAgent } from "@autobe/agent";
import { AutoBeCompiler } from "@autobe/compiler";
import OpenAI from "openai";
 
const agent = new AutoBeAgent({
  model: "chatgpt",
  vendor: {
    api: new OpenAI({ apiKey: "********" }),
    model: "gpt-4.1",
  },
  compiler: new AutoBeCompiler(),
});
 
agent.on("userMessage", (event) => {
  console.log("User message contents:", event.contents);
});
agent.on("assistantMessage", (event) => {
  console.log("Assistant message:", event.text);
});
agent.on("analyzeComplete", (event) => {
  console.log("Analyze complete:", event.files);
});
agent.on("prismaComplete", (event) => {
  console.log(
    "Prisma complete:",
    event.schemas,
    event.compiled.type === "success" ? event.compiled.document : null,
  );
});
agent.on("interfaceComplete", (event) => {
  console.log("Interface complete:", event.document, event.files);
});
agent.on("testComplete", (event) => {
  console.log("Test complete:", event.files);
});
 
await agent.conversate(`
  I want to create a political/economic discussion board.
  
  Since I'm not familiar with programming, 
  please write a requirements analysis report as you see fit.
`);

import { AutoBeAnalyzeCompleteEvent } from "./AutoBeAnalyzeCompleteEvent";
import { AutoBeAnalyzeReviewEvent } from "./AutoBeAnalyzeReviewEvent";
import { AutoBeAnalyzeScenarioEvent } from "./AutoBeAnalyzeScenarioEvent";
import { AutoBeAnalyzeStartEvent } from "./AutoBeAnalyzeStartEvent";
import { AutoBeAnalyzeWriteEvent } from "./AutoBeAnalyzeWriteEvent";
import { AutoBeAssistantMessageEvent } from "./AutoBeAssistantMessageEvent";
import { AutoBeConsentFunctionCallEvent } from "./AutoBeConsentFunctionCallEvent";
import { AutoBeInterfaceAuthorizationEvent } from "./AutoBeInterfaceAuthorizationEvent";
import { AutoBeInterfaceComplementEvent } from "./AutoBeInterfaceComplementEvent";
import { AutoBeInterfaceCompleteEvent } from "./AutoBeInterfaceCompleteEvent";
import { AutoBeInterfaceEndpointsEvent } from "./AutoBeInterfaceEndpointsEvent";
import { AutoBeInterfaceEndpointsReviewEvent } from "./AutoBeInterfaceEndpointsReviewEvent";
import { AutoBeInterfaceGroupsEvent } from "./AutoBeInterfaceGroupsEvent";
import { AutoBeInterfaceOperationsEvent } from "./AutoBeInterfaceOperationsEvent";
import { AutoBeInterfaceOperationsReviewEvent } from "./AutoBeInterfaceOperationsReviewEvent";
import { AutoBeInterfaceSchemasEvent } from "./AutoBeInterfaceSchemasEvent";
import { AutoBeInterfaceSchemasReviewEvent } from "./AutoBeInterfaceSchemasReviewEvent";
import { AutoBeInterfaceStartEvent } from "./AutoBeInterfaceStartEvent";
import { AutoBeJsonParseErrorEvent } from "./AutoBeJsonParseErrorEvent";
import { AutoBeJsonValidateErrorEvent } from "./AutoBeJsonValidateErrorEvent";
import { AutoBePrismaCompleteEvent } from "./AutoBePrismaCompleteEvent";
import { AutoBePrismaComponentsEvent } from "./AutoBePrismaComponentsEvent";
import { AutoBePrismaCorrectEvent } from "./AutoBePrismaCorrectEvent";
import { AutoBePrismaInsufficientEvent } from "./AutoBePrismaInsufficientEvent";
import { AutoBePrismaReviewEvent } from "./AutoBePrismaReviewEvent";
import { AutoBePrismaSchemasEvent } from "./AutoBePrismaSchemasEvent";
import { AutoBePrismaStartEvent } from "./AutoBePrismaStartEvent";
import { AutoBePrismaValidateEvent } from "./AutoBePrismaValidateEvent";
import { AutoBeRealizeAuthorizationCompleteEvent } from "./AutoBeRealizeAuthorizationCompleteEvent";
import { AutoBeRealizeAuthorizationCorrectEvent } from "./AutoBeRealizeAuthorizationCorrectEvent";
import { AutoBeRealizeAuthorizationStartEvent } from "./AutoBeRealizeAuthorizationStartEvent";
import { AutoBeRealizeAuthorizationValidateEvent } from "./AutoBeRealizeAuthorizationValidateEvent";
import { AutoBeRealizeAuthorizationWriteEvent } from "./AutoBeRealizeAuthorizationWriteEvent";
import { AutoBeRealizeCompleteEvent } from "./AutoBeRealizeCompleteEvent";
import { AutoBeRealizeCorrectEvent } from "./AutoBeRealizeCorrectEvent";
import { AutoBeRealizeStartEvent } from "./AutoBeRealizeStartEvent";
import { AutoBeRealizeTestCompleteEvent } from "./AutoBeRealizeTestCompleteEvent";
import { AutoBeRealizeTestOperationEvent } from "./AutoBeRealizeTestOperationEvent";
import { AutoBeRealizeTestResetEvent } from "./AutoBeRealizeTestResetEvent";
import { AutoBeRealizeTestStartEvent } from "./AutoBeRealizeTestStartEvent";
import { AutoBeRealizeValidateEvent } from "./AutoBeRealizeValidateEvent";
import { AutoBeRealizeWriteEvent } from "./AutoBeRealizeWriteEvent";
import { AutoBeTestCompleteEvent } from "./AutoBeTestCompleteEvent";
import { AutoBeTestCorrectEvent } from "./AutoBeTestCorrectEvent";
import { AutoBeTestScenariosEvent } from "./AutoBeTestScenariosEvent";
import { AutoBeTestStartEvent } from "./AutoBeTestStartEvent";
import { AutoBeTestValidateEvent } from "./AutoBeTestValidateEvent";
import { AutoBeTestWriteEvent } from "./AutoBeTestWriteEvent";
import { AutoBeUserMessageEvent } from "./AutoBeUserMessageEvent";
import { AutoBeVendorRequestEvent } from "./AutoBeVendorRequestEvent";
import { AutoBeVendorResponseEvent } from "./AutoBeVendorResponseEvent";
 
/**
 * Union type representing all possible events that can occur during the AutoBe
 * development pipeline execution.
 *
 * This comprehensive event system provides real-time visibility into every
 * stage of the automated development process, from initial requirements
 * analysis through final application generation. Each event type captures
 * specific moments in the pipeline workflow, enabling detailed monitoring,
 * progress tracking, and debugging capabilities.
 *
 * The events are organized by agent responsibility: conversation events for
 * user interaction, analyze events for requirements processing, interface
 * events for API specification generation, prisma events for database design,
 * test events for validation code creation, and realize events for final
 * application assembly.
 *
 * This event-driven architecture allows external systems to monitor pipeline
 * execution, implement custom logging, provide user feedback, or integrate with
 * other development tools by subscribing to specific event types.
 *
 * @author Samchon
 */
export type AutoBeEvent =
  // MESSAGES
  | AutoBeAssistantMessageEvent
  | AutoBeUserMessageEvent
  | AutoBeVendorRequestEvent
  | AutoBeVendorResponseEvent
  | AutoBeJsonValidateErrorEvent
  | AutoBeJsonParseErrorEvent
  | AutoBeConsentFunctionCallEvent
  // ANALYZE
  | AutoBeAnalyzeStartEvent
  | AutoBeAnalyzeScenarioEvent
  | AutoBeAnalyzeWriteEvent
  | AutoBeAnalyzeReviewEvent
  | AutoBeAnalyzeCompleteEvent
  // INTERFACE
  | AutoBeInterfaceStartEvent
  | AutoBeInterfaceGroupsEvent
  | AutoBeInterfaceEndpointsEvent
  | AutoBeInterfaceEndpointsReviewEvent
  | AutoBeInterfaceOperationsReviewEvent
  | AutoBeInterfaceOperationsEvent
  | AutoBeInterfaceAuthorizationEvent
  | AutoBeInterfaceSchemasEvent
  | AutoBeInterfaceSchemasReviewEvent
  | AutoBeInterfaceComplementEvent
  | AutoBeInterfaceCompleteEvent
  // PRISMA
  | AutoBePrismaStartEvent
  | AutoBePrismaComponentsEvent
  | AutoBePrismaSchemasEvent
  | AutoBePrismaInsufficientEvent
  | AutoBePrismaReviewEvent
  | AutoBePrismaValidateEvent
  | AutoBePrismaCorrectEvent
  | AutoBePrismaCompleteEvent
  // TEST
  | AutoBeTestStartEvent
  | AutoBeTestScenariosEvent
  | AutoBeTestWriteEvent
  | AutoBeTestValidateEvent
  | AutoBeTestCorrectEvent
  | AutoBeTestCompleteEvent
  // REALIZE
  | AutoBeRealizeStartEvent
  | AutoBeRealizeWriteEvent
  | AutoBeRealizeCorrectEvent
  | AutoBeRealizeValidateEvent
  | AutoBeRealizeCompleteEvent
  | AutoBeRealizeAuthorizationStartEvent
  | AutoBeRealizeAuthorizationWriteEvent
  | AutoBeRealizeAuthorizationValidateEvent
  | AutoBeRealizeAuthorizationCorrectEvent
  | AutoBeRealizeAuthorizationCompleteEvent
  | AutoBeRealizeTestStartEvent
  | AutoBeRealizeTestResetEvent
  | AutoBeRealizeTestOperationEvent
  | AutoBeRealizeTestCompleteEvent;
 
export namespace AutoBeEvent {
  /**
   * Type literal union of all possible event type strings.
   *
   * Provides a compile-time enumeration of all event types that can occur
   * during pipeline execution. This type is extracted from the discriminant
   * union property of the AutoBeEvent type and is useful for type guards,
   * switch statements, and event filtering logic.
   *
   * The type enables type-safe event handling by ensuring that only valid event
   * type strings can be used when subscribing to events, filtering event
   * streams, or implementing event handlers.
   */
  export type Type = AutoBeEvent["type"];
 
  /**
   * Type mapping interface that associates event type strings with their
   * corresponding event object types.
   *
   * This mapping provides a type-safe way to access specific event types by
   * their string identifiers, enabling generic event handling patterns and
   * type-safe event subscription mechanisms. Each key represents an event type
   * string, and each value represents the complete event object type for that
   * event.
   *
   * The mapper is particularly useful for implementing event handlers that need
   * to process different event types with full type safety, allowing TypeScript
   * to provide accurate autocompletion and type checking for event-specific
   * properties and methods.
   *
   * Example usage patterns include event router implementations, type-safe
   * event subscription systems, and generic event processing utilities that
   * maintain compile-time type safety across different event types.
   */
  export type Mapper = {
    assistantMessage: AutoBeAssistantMessageEvent;
    userMessage: AutoBeUserMessageEvent;
    vendorRequest: AutoBeVendorRequestEvent;
    vendorResponse: AutoBeVendorResponseEvent;
    jsonValidateError: AutoBeJsonValidateErrorEvent;
    jsonParseError: AutoBeJsonParseErrorEvent;
    consentFunctionCall: AutoBeConsentFunctionCallEvent;
    // ANALYZE
    analyzeStart: AutoBeAnalyzeStartEvent;
    analyzeScenario: AutoBeAnalyzeScenarioEvent;
    analyzeWrite: AutoBeAnalyzeWriteEvent;
    analyzeReview: AutoBeAnalyzeReviewEvent;
    analyzeComplete: AutoBeAnalyzeCompleteEvent;
    // PRISMA
    prismaStart: AutoBePrismaStartEvent;
    prismaComponents: AutoBePrismaComponentsEvent;
    prismaSchemas: AutoBePrismaSchemasEvent;
    prismaInsufficient: AutoBePrismaInsufficientEvent;
    prismaReview: AutoBePrismaReviewEvent;
    prismaValidate: AutoBePrismaValidateEvent;
    prismaCorrect: AutoBePrismaCorrectEvent;
    prismaComplete: AutoBePrismaCompleteEvent;
    // INTERFACE
    interfaceStart: AutoBeInterfaceStartEvent;
    interfaceGroups: AutoBeInterfaceGroupsEvent;
    interfaceAuthorization: AutoBeInterfaceAuthorizationEvent;
    interfaceEndpoints: AutoBeInterfaceEndpointsEvent;
    interfaceEndpointsReview: AutoBeInterfaceEndpointsReviewEvent;
    interfaceOperations: AutoBeInterfaceOperationsEvent;
    interfaceOperationsReview: AutoBeInterfaceOperationsReviewEvent;
    interfaceSchemas: AutoBeInterfaceSchemasEvent;
    interfaceSchemasReview: AutoBeInterfaceSchemasReviewEvent;
    interfaceComplement: AutoBeInterfaceComplementEvent;
    interfaceComplete: AutoBeInterfaceCompleteEvent;
    // TEST
    testStart: AutoBeTestStartEvent;
    testScenarios: AutoBeTestScenariosEvent;
    testWrite: AutoBeTestWriteEvent;
    testValidate: AutoBeTestValidateEvent;
    testCorrect: AutoBeTestCorrectEvent;
    testComplete: AutoBeTestCompleteEvent;
    // REALIZE
    realizeStart: AutoBeRealizeStartEvent;
    realizeWrite: AutoBeRealizeWriteEvent;
    realizeCorrect: AutoBeRealizeCorrectEvent;
    realizeValidate: AutoBeRealizeValidateEvent;
    realizeComplete: AutoBeRealizeCompleteEvent;
    realizeAuthorizationStart: AutoBeRealizeAuthorizationStartEvent;
    realizeAuthorizationWrite: AutoBeRealizeAuthorizationWriteEvent;
    realizeAuthorizationValidate: AutoBeRealizeAuthorizationValidateEvent;
    realizeAuthorizationCorrect: AutoBeRealizeAuthorizationCorrectEvent;
    realizeAuthorizationComplete: AutoBeRealizeAuthorizationCompleteEvent;
    realizeTestStart: AutoBeRealizeTestStartEvent;
    realizeTestReset: AutoBeRealizeTestResetEvent;
    realizeTestOperation: AutoBeRealizeTestOperationEvent;
    realizeTestComplete: AutoBeRealizeTestCompleteEvent;
  };
}

import { AutoBeUserMessageContent } from "../histories/contents/AutoBeUserMessageContent";
import { AutoBeEventBase } from "./AutoBeEventBase";
 
/**
 * Event fired when a user sends a message during the conversation flow.
 *
 * This event represents real-time user input in the vibe coding conversation,
 * capturing the multimodal communication from users that drives the development
 * process. User messages can include text descriptions, visual references,
 * document uploads, and voice input that provide the requirements, feedback,
 * and guidance necessary for the AI agents to generate accurate software
 * solutions.
 *
 * The user message events serve as the primary input source for the entire vibe
 * coding pipeline, enabling users to express their needs through multiple
 * modalities and maintain interactive control over the automated development
 * process as it progresses through different phases.
 *
 * @author Samchon
 */
export interface AutoBeUserMessageEvent extends AutoBeEventBase<"userMessage"> {
  /**
   * Array of multimodal content items that comprise the user's message.
   *
   * Contains the diverse {@link AutoBeUserMessageContent} elements that make up
   * the user's communication, which can include text descriptions, images for
   * visual references, document files for specifications, and audio for voice
   * input. Each content item represents a different modality or attachment
   * within the same message.
   *
   * The multimodal array structure allows users to combine multiple content
   * types in a single message, such as text requirements accompanied by
   * reference images or documents. This comprehensive input approach provides
   * rich context for the AI agents to better understand user intentions and
   * generate more accurate development artifacts throughout the vibe coding
   * process.
   */
  contents: AutoBeUserMessageContent[];
}

import { AutoBeEventBase } from "./AutoBeEventBase";
 
/**
 * Event fired when the AI assistant sends a message to the user during the
 * conversation.
 *
 * This event represents real-time communication from the assistant to the user,
 * providing responses to queries, explanations of development processes,
 * progress updates, and guidance throughout the vibe coding workflow. The
 * assistant uses these messages to maintain clear communication and ensure
 * users understand what is happening during the automated development process.
 *
 * Unlike user messages which support multimodal content, assistant messages are
 * exclusively text-based, focusing on clear and precise communication that
 * guides users through the development experience and provides necessary
 * context about ongoing operations and next steps.
 *
 * @author Samchon
 */
export interface AutoBeAssistantMessageEvent
  extends AutoBeEventBase<"assistantMessage"> {
  /**
   * The text content of the assistant's message to the user.
   *
   * Contains the complete text response from the AI assistant, which may
   * include explanations of current activities, progress updates on development
   * phases, answers to user questions, guidance for next steps, error
   * descriptions, or clarification requests. The message content is designed to
   * keep users informed and engaged throughout the vibe coding process.
   *
   * The text communication serves as the primary interface for the assistant to
   * provide context, explain complex processes in understandable terms, and
   * maintain a collaborative atmosphere during the automated development
   * workflow.
   */
  text: string;
}

//----------------------------------------
// File: AutoBeUserMessageContent.ts
//----------------------------------------
import { AutoBeUserMessageAudioContent } from "./AutoBeUserMessageAudioContent";
import { AutoBeUserMessageFileContent } from "./AutoBeUserMessageFileContent";
import { AutoBeUserMessageImageContent } from "./AutoBeUserMessageImageContent";
import { AutoBeUserMessageTextContent } from "./AutoBeUserMessageTextContent";
 
/**
 * Union type representing all possible content types within a user message.
 *
 * This comprehensive multimodal union enables users to communicate through
 * various input modalities including text descriptions, visual references
 * through images, documentation through file uploads, and natural voice
 * interaction through audio. The multimodal approach enhances the vibe coding
 * experience by allowing users to express requirements using the most
 * appropriate medium for their needs.
 *
 * Each content type is designed to provide rich context to the AI assistant,
 * enabling more accurate understanding of user requirements and generating
 * better development artifacts. Users can combine multiple content types within
 * a single message to provide comprehensive specification of their needs.
 *
 * @author Samchon
 */
export type AutoBeUserMessageContent =
  | AutoBeUserMessageAudioContent
  | AutoBeUserMessageFileContent
  | AutoBeUserMessageImageContent
  | AutoBeUserMessageTextContent;
 
export namespace AutoBeUserMessageContent {
  /**
   * Type alias for extracting the discriminator union from user message content
   * types.
   *
   * Provides a convenient way to reference all possible content type values
   * including "audio", "file", "image", and "text". This type is essential for
   * type guards, content processing logic, and multimodal input handling
   * throughout the conversation system.
   */
  export type Type = AutoBeUserMessageContent["type"];
 
  /**
   * Type mapping interface that associates each content type string with its
   * corresponding content interface.
   *
   * Enables type-safe processing of different content modalities based on their
   * discriminator values. This mapper facilitates robust multimodal content
   * handling, ensuring that each content type is processed according to its
   * specific characteristics and requirements in the vibe coding pipeline.
   *
   * The mapper provides compile-time type safety when working with
   * heterogeneous content arrays and enables efficient content type-specific
   * processing logic.
   */
  export interface Mapper {
    audio: AutoBeUserMessageAudioContent;
    file: AutoBeUserMessageFileContent;
    image: AutoBeUserMessageImageContent;
    text: AutoBeUserMessageTextContent;
  }
}
 
//----------------------------------------
// File: AutoBeUserMessageAudioContent.ts
//----------------------------------------
import { AutoBeUserMessageContentBase } from "./AutoBeUserMessageContentBase";
 
/**
 * Content type representing audio input from users in the conversation.
 *
 * Enables natural voice interaction by allowing users to communicate
 * requirements, ask questions, and provide specifications through spoken input.
 * Voice input enhances the vibe coding experience by providing a more natural
 * and efficient way to express complex requirements, especially when describing
 * workflows, business processes, or detailed specifications.
 *
 * The audio content is processed through speech-to-text capabilities, allowing
 * the AI assistant to understand and respond to voice-based requirements just
 * as effectively as text input. This multimodal approach makes the development
 * conversation more accessible and user-friendly.
 *
 * @author Samchon
 */
export interface AutoBeUserMessageAudioContent
  extends AutoBeUserMessageContentBase<"audio"> {
  /**
   * Base64 encoded audio data containing the user's voice input.
   *
   * The audio data is encoded in Base64 format to ensure safe transmission and
   * storage within the message system. This encoding allows the voice input to
   * be processed by speech-to-text services and integrated seamlessly into the
   * conversation flow alongside other content types.
   *
   * The encoded audio maintains the original quality necessary for accurate
   * speech recognition while being compatible with standard data transmission
   * and storage protocols.
   */
  data: string;
 
  /**
   * The format of the encoded audio data.
   *
   * Specifies the audio codec and container format used for the voice input.
   * Currently supports "wav" for uncompressed high-quality audio and "mp3" for
   * compressed audio with smaller file sizes. The format information ensures
   * proper decoding and processing of the audio content.
   *
   * Different formats may be preferred based on quality requirements, file size
   * constraints, and compatibility with speech recognition services.
   */
  format: "wav" | "mp3";
}
 
//----------------------------------------
// File: AutoBeUserMessageFileContent.ts
//----------------------------------------
import { AutoBeUserMessageContentBase } from "./AutoBeUserMessageContentBase";
 
/**
 * User message content for file uploads.
 *
 * Handles file attachments in user messages, supporting both direct file data
 * and file references. Used when users need to share documents, specifications,
 * code files, or other resources as part of their development requirements.
 *
 * @author Samchon
 */
export interface AutoBeUserMessageFileContent
  extends AutoBeUserMessageContentBase<"file"> {
  /**
   * File content data.
   *
   * Either base64-encoded file data or a reference ID to a previously uploaded
   * file.
   */
  file: AutoBeUserMessageFileContent.IBase64 | AutoBeUserMessageFileContent.IId;
}
 
export namespace AutoBeUserMessageFileContent {
  /** Direct file upload with base64-encoded data. */
  export interface IBase64 {
    /** Discriminator indicating this contains direct file data. */
    type: "base64";
 
    /** Original filename. */
    name: string;
 
    /** Base64-encoded file content. */
    data: string;
  }
 
  /** File reference by ID. */
  export interface IId {
    /** Discriminator indicating this is a file reference. */
    type: "id";
 
    /** File ID for retrieving previously uploaded file. */
    id: string;
  }
}
 
//----------------------------------------
// File: AutoBeUserMessageImageContent.ts
//----------------------------------------
import { tags } from "typia";
 
import { AutoBeUserMessageContentBase } from "./AutoBeUserMessageContentBase";
 
/**
 * User message content for image uploads.
 *
 * Handles image attachments in user messages, supporting both base64-encoded
 * images and URL references. Used for sharing UI mockups, diagrams,
 * screenshots, and other visual materials.
 *
 * @author Samchon
 */
export interface AutoBeUserMessageImageContent
  extends AutoBeUserMessageContentBase<"image"> {
  /**
   * Image content data.
   *
   * Either base64-encoded image data or a URL reference.
   */
  image:
    | AutoBeUserMessageImageContent.IBase64
    | AutoBeUserMessageImageContent.IUrl;
 
  /**
   * Image analysis detail level.
   *
   * - "auto": Automatic detail selection
   * - "high": Detailed analysis for complex images
   * - "low": Fast processing for simple images
   */
  detail?: "auto" | "high" | "low" | undefined;
}
export namespace AutoBeUserMessageImageContent {
  /** Direct image upload with base64-encoded data. */
  export interface IBase64 {
    /** Discriminator for base64 type. */
    type: "base64";
 
    /** Base64-encoded image data. */
    data: string;
  }
 
  /** Image reference by URL. */
  export interface IUrl {
    /** Discriminator for URL type. */
    type: "url";
 
    /** Image URL with format validation. */
    url: string & tags.Format<"url">;
  }
}
 
//----------------------------------------
// File: AutoBeUserMessageTextContent.ts
//----------------------------------------
import { AutoBeUserMessageContentBase } from "./AutoBeUserMessageContentBase";
 
/**
 * Content type representing textual input from users in the conversation.
 *
 * Serves as the primary communication medium for expressing requirements,
 * asking questions, providing clarifications, and engaging in detailed
 * discussions about development needs. Text content remains the most
 * fundamental and versatile way for users to communicate complex business
 * logic, technical specifications, and nuanced requirements in the vibe coding
 * process.
 *
 * While the system supports multimodal input including audio, images, and
 * files, text content provides the precision and clarity needed for detailed
 * requirement specification and iterative refinement of development goals. It
 * enables users to articulate complex business processes, technical
 * constraints, and specific implementation preferences with the detail
 * necessary for accurate code generation.
 *
 * @author Samchon
 */
export interface AutoBeUserMessageTextContent
  extends AutoBeUserMessageContentBase<"text"> {
  /**
   * The textual content of the user's message.
   *
   * Contains the user's written communication including requirements
   * descriptions, questions, feedback, clarifications, or any other textual
   * input that guides the development process. This text serves as the primary
   * source of business logic understanding and technical requirement
   * specification.
   *
   * The text content can range from simple queries to comprehensive requirement
   * documents, architectural decisions, feature specifications, or detailed
   * business process descriptions that inform the entire vibe coding pipeline
   * from analysis through implementation.
   */
  text: string;
}

import { AutoBeEventBase } from "./AutoBeEventBase";
 
/**
 * Event fired when the Analyze agent begins the requirements analysis process.
 *
 * This event marks the initiation of the structured requirements analysis
 * workflow, signaling that the agent is starting to draft the comprehensive
 * analysis report. The start event represents the beginning of the critical
 * foundation phase that transforms user conversations and business needs into
 * structured documentation for the entire vibe coding pipeline.
 *
 * The analysis process that begins with this event will proceed through
 * drafting, reviewing, and finalizing phases to produce the authoritative
 * requirements documentation that guides all subsequent development activities
 * including database design, API specification, and implementation.
 *
 * @author Kakasoo
 */
export interface AutoBeAnalyzeStartEvent
  extends AutoBeEventBase<"analyzeStart"> {
  /**
   * Reason why the Analyze agent was activated through function calling.
   *
   * Explains the specific circumstances that triggered the AI chatbot to invoke
   * the Analyze agent via function calling. This could include reasons such as
   * initial project requirements gathering, requests for requirement
   * clarification, updates to existing requirements based on user feedback, or
   * revision requests for the analysis report.
   *
   * Understanding the activation reason provides context for the analysis scope
   * and helps stakeholders understand whether this is an initial analysis or a
   * refinement of existing requirements.
   */
  reason: string;
 
  /**
   * Iteration number of the requirements analysis being started.
   *
   * Indicates which revision of the requirements analysis is beginning. A value
   * of 0 means this is the initial requirements analysis, while higher values
   * represent subsequent revisions being initiated based on user feedback,
   * additional requirements, or refinement needs.
   *
   * This step number helps track the iterative nature of requirements
   * development and provides context for understanding the evolution of project
   * requirements throughout the development process.
   */
  step: number;
}

import { AutoBeAnalyzeFile } from "../histories/contents/AutoBeAnalyzeFile";
import { AutoBeEventBase } from "./AutoBeEventBase";
import { AutoBeProgressEventBase } from "./AutoBeProgressEventBase";
import { AutoBeTokenUsageEventBase } from "./AutoBeTokenUsageEventBase";
 
/**
 * Event fired during the writing phase of the requirements analysis process.
 *
 * This event represents the core activity of the Analyze Writer Agent
 * (PlannerAgent), which serves as AutoBE's requirements analysis specialist.
 * The agent transforms user requirements and business objectives into
 * comprehensive, developer-ready documentation following the WHY → WHAT → HOW
 * framework.
 *
 * The Analyze Writer Agent operates as the first critical step in AutoBE's
 * waterfall development model, producing structured markdown documents that
 * include:
 *
 * - Business models and user roles
 * - Functional requirements in EARS (Easy Approach to Requirements Syntax) format
 * - API endpoint specifications (as guidance, not prescriptive)
 * - Entity relationship diagrams (ERD)
 * - Security and business logic requirements
 *
 * Key characteristics of the writing process:
 *
 * - Focuses exclusively on backend requirements (no frontend/UI specifications)
 * - Produces documents ranging from 2,000 to 30,000+ characters
 * - Avoids ambiguous terms and maintains clear, measurable requirements
 * - Excludes implementation details to preserve developer autonomy
 *
 * The generated documents serve as the foundation for subsequent AutoBE agents:
 * Prisma Agent (database design), Interface Agent (API design), Test Agent
 * (test generation), and Realize Agent (implementation).
 *
 * For detailed information about the Analyze Writer Agent's behavior and
 * requirements, refer to packages/agent/prompts/ANALYZE_WRITE.md
 *
 * @author Kakasoo
 */
export interface AutoBeAnalyzeWriteEvent
  extends AutoBeEventBase<"analyzeWrite">,
    AutoBeProgressEventBase,
    AutoBeTokenUsageEventBase {
  /**
   * File structure and content being written by the Analyze Writer Agent.
   *
   * Contains the markdown document being generated, including all sections such
   * as overview, business model, functional requirements, API specifications,
   * and ERD diagrams. This file will be validated by the Analyze Review Agent
   * before proceeding to the next development phase.
   */
  file: AutoBeAnalyzeFile;
 
  /**
   * Current iteration number of the requirements analysis being written.
   *
   * Indicates which version of the requirements analysis is being drafted. This
   * step number provides context for understanding whether this is an initial
   * draft or a revision being written based on previous feedback or additional
   * requirements gathering.
   *
   * The step value helps track the iterative nature of requirements development
   * and correlates the writing activity with the overall requirements evolution
   * process throughout the project lifecycle.
   */
  step: number;
}

import { AutoBeAnalyzeFile } from "../histories/contents/AutoBeAnalyzeFile";
import { AutoBeEventBase } from "./AutoBeEventBase";
import { AutoBeProgressEventBase } from "./AutoBeProgressEventBase";
import { AutoBeTokenUsageEventBase } from "./AutoBeTokenUsageEventBase";
 
/**
 * Event fired during the review and amendment phase of the requirements
 * analysis process.
 *
 * This event represents the quality assurance activity of the Analyze Review
 * Agent, which validates documents produced by the Analyze Writer Agent. The
 * reviewer ensures that requirements documentation meets AutoBE's strict
 * standards before proceeding to the development phases.
 *
 * The Analyze Review Agent performs comprehensive validation including:
 *
 * - Document length verification (minimum 2,000 characters, excluding TOC)
 * - Table of contents completeness check (all sections must be filled)
 * - Internal anchor link validation (all #links must be valid)
 * - Mermaid diagram syntax verification (especially quote usage rules)
 * - EARS format compliance for functional requirements
 *
 * Review outcomes:
 *
 * - **Accept**: Document meets all criteria and can proceed to next phase
 * - **Reject**: Document requires revision with specific feedback provided
 *
 * Key characteristics of the review process:
 *
 * - Reviewer provides only feedback and commands, never writes content directly
 * - Reviews one document at a time with focused attention
 * - Enforces strict Mermaid syntax rules (no parentheses within brackets)
 * - Iterative process continues until document meets all quality standards
 *
 * The review ensures that subsequent agents (Prisma, Interface, Test, Realize)
 * receive well-structured, unambiguous requirements that enable fully automated
 * backend development without human intervention.
 *
 * For detailed information about the Analyze Review Agent's validation rules
 * and criteria, refer to packages/agent/prompts/ANALYZE_REVIEW.md
 *
 * @author Kakasoo
 */
export interface AutoBeAnalyzeReviewEvent
  extends AutoBeEventBase<"analyzeReview">,
    AutoBeProgressEventBase,
    AutoBeTokenUsageEventBase {
  /**
   * Original file content submitted for review.
   *
   * Contains the markdown document generated by the Analyze Writer Agent,
   * including all sections such as business model, functional requirements, API
   * specifications, and ERD diagrams that need validation.
   */
  file: AutoBeAnalyzeFile;
 
  /**
   * Detailed review feedback from the Analyze Review Agent.
   *
   * Contains specific validation results including:
   *
   * - Document length assessment
   * - Missing or incomplete sections
   * - Invalid anchor links
   * - Mermaid syntax errors
   * - EARS format violations
   * - Overall quality assessment and recommendations
   */
  review: string;
 
  /**
   * Amendment plan based on the review feedback.
   *
   * Outlines specific changes to be made to address review comments. If the
   * original document is perfect and requires no modifications, this field will
   * explicitly state that no changes are needed.
   *
   * The plan serves as a bridge between review feedback and actual document
   * revision, ensuring all identified issues are addressed.
   */
  plan: string;
 
  /**
   * Revised content based on the amendment plan.
   *
   * Contains the fully updated markdown document incorporating all review
   * feedback. If the original document was perfect and required no changes,
   * this will be identical to the original content.
   *
   * This revised content must pass all validation criteria before the document
   * can proceed to the next development phase.
   */
  content: string;
 
  /**
   * Current iteration number of the requirements analysis being reviewed.
   *
   * Indicates which version of the requirements analysis is undergoing review
   * and amendment. This step number helps track the iterative refinement
   * process and provides context for understanding how many revision cycles
   * have been completed.
   *
   * The step value increments with each major revision cycle, allowing
   * stakeholders to understand the evolution of the requirements and the level
   * of refinement that has been applied to achieve the final analysis.
   */
  step: number;
}

import { AutoBeAnalyzeFile } from "../histories/contents/AutoBeAnalyzeFile";
import { AutoBeAnalyzeRole } from "../histories/contents/AutoBeAnalyzeRole";
import { AutoBeEventBase } from "./AutoBeEventBase";
 
/**
 * Event fired when the Analyze agent completes the requirements analysis
 * process and finalizes the comprehensive analysis report.
 *
 * This event represents the successful completion of the requirements analysis
 * workflow, which includes drafting, reviewing, amending, and finalizing the
 * analysis documentation. The event indicates that all discussions regarding
 * requirements have been completed and a comprehensive report has been issued
 * that will serve as the foundation for subsequent development phases.
 *
 * The completion of requirements analysis marks a critical milestone in the
 * vibe coding pipeline, as the generated report guides all subsequent
 * development activities including database design, API specification, and
 * implementation.
 *
 * @author Kakasoo
 */
export interface AutoBeAnalyzeCompleteEvent
  extends AutoBeEventBase<"analyzeComplete"> {
  /**
   * Project alias prefix that will be applied to all generated artifacts.
   *
   * A short project identifier that will be consistently used as a prefix for
   * database table names, API function names, and DTO type names throughout the
   * entire codebase. This ensures consistent naming conventions and helps avoid
   * naming conflicts in larger systems.
   *
   * For example, if the prefix is "shopping", generated artifacts might include
   * tables like "shopping_customers" and DTOs like "ShoppingCustomerDto".
   */
  prefix: string;
 
  /**
   * Generated requirements analysis report files as key-value pairs.
   *
   * Contains the complete set of markdown documents that comprise the finalized
   * requirements analysis report. Each key represents the filename and each
   * value contains the actual markdown content. The report typically includes
   * business context, functional requirements, technical specifications,
   * architectural decisions, and implementation guidelines.
   *
   * These documents serve as the authoritative source for understanding project
   * requirements and guide all subsequent development phases in the vibe coding
   * pipeline including database design, API specification, and implementation.
   */
  files: AutoBeAnalyzeFile[];
 
  /**
   * List of roles identified during the requirements analysis process.
   *
   * Contains the various user roles, personas, or stakeholder types that were
   * identified and analyzed during the requirements gathering phase. These
   * roles help define different user perspectives, access levels, and
   * functional requirements needed for the system being developed.
   */
  roles: AutoBeAnalyzeRole[];
 
  /**
   * Final iteration number of the completed requirements analysis report.
   *
   * Indicates the final revision number of the requirements analysis that was
   * completed. A value of 0 means this is the initial requirements analysis,
   * while higher values represent the number of revisions that were made based
   * on user feedback or additional requirements gathering.
   *
   * This step number serves as a reference point for other development
   * artifacts, ensuring they are aligned with the latest requirements.
   * Development artifacts with lower step values may need regeneration to
   * reflect the completed analysis.
   */
  step: number;
 
  /**
   * Elapsed time in milliseconds for the entire requirements analysis process.
   *
   * Indicates the total time taken from the start of the requirements analysis
   * process until its completion. This metric helps in understanding the
   * efficiency of the requirements gathering and analysis phase, providing
   * insights into the time investment required for thorough analysis and
   * documentation of business requirements.
   *
   * This elapsed time is same with the difference between the timestamps
   * recorded in the `created_at` field of the `AutoBeAnalyzeStartEvent` and
   * this event.
   */
  elapsed: number;
}

//----------------------------------------
// File: AutoBePrismaStartEvent.ts
//----------------------------------------
import { AutoBeEventBase } from "./AutoBeEventBase";
 
/**
 * Event fired when the Prisma agent begins the database design process.
 *
 * This event marks the initiation of the sophisticated three-tier compiler
 * infrastructure that transforms business requirements into validated database
 * architectures through AST manipulation. The Prisma agent start represents the
 * beginning of the foundational data layer development that will support all
 * subsequent application functionality.
 *
 * The database design process that begins with this event will proceed through
 * component organization, schema creation, validation, and compilation to
 * produce production-ready Prisma schemas that maintain perfect semantic
 * integrity and syntactic correctness while accurately reflecting business
 * requirements.
 *
 * @author Samchon
 */
export interface AutoBePrismaStartEvent extends AutoBeEventBase<"prismaStart"> {
  /**
   * Reason why the Prisma agent was activated through function calling.
   *
   * Explains the specific circumstances that triggered the AI chatbot to invoke
   * the Prisma agent via function calling. This could include reasons such as
   * initial database design after requirements analysis completion, updating
   * database schemas due to requirement changes, regenerating data models to
   * reflect modified business logic, or creating additional database structures
   * for new functionality.
   *
   * Understanding the activation reason provides context for the database
   * design scope and helps stakeholders understand whether this represents
   * initial development, schema refinement, or expansion of existing data
   * architecture.
   */
  reason: string;
 
  /**
   * Iteration number of the requirements analysis this database design is being
   * started for.
   *
   * Indicates which version of the requirements analysis this database design
   * will reflect. This step number ensures that the Prisma agent works with the
   * current requirements and helps track the evolution of database schemas as
   * business requirements and data needs change.
   *
   * The step value enables proper synchronization between database design
   * activities and the underlying requirements, ensuring that the data
   * architecture remains aligned with the current project scope and business
   * objectives throughout the iterative development process.
   */
  step: number;
}
 
//----------------------------------------
// File: AutoBePrismaComponentsEvent.ts
//----------------------------------------
import { AutoBePrisma } from "../prisma";
import { AutoBeEventBase } from "./AutoBeEventBase";
import { AutoBeTokenUsageEventBase } from "./AutoBeTokenUsageEventBase";
 
/**
 * Event fired when the Prisma agent organizes database tables into categorized
 * groups during the database design process.
 *
 * This event occurs when the Prisma agent has analyzed the requirements and
 * determined the complete scope of database tables needed, organizing them into
 * logical groups based on business domains and functional relationships. The
 * component organization follows domain-driven design principles to ensure
 * maintainable and coherent database architecture.
 *
 * The categorized components provide a clear roadmap for the schema generation
 * process, enabling systematic development of related tables while maintaining
 * proper dependencies and relationships across the database design.
 *
 * @author Samchon
 */
export interface AutoBePrismaComponentsEvent
  extends AutoBeEventBase<"prismaComponents">,
    AutoBeTokenUsageEventBase {
  /**
   * Initial thoughts on namespace classification criteria.
   *
   * Contains the AI agent's initial analysis and reasoning about how to
   * organize tables into different business domains/namespaces.
   *
   * **Example:**
   *
   *     "Based on the business requirements, I identify several key domains:
   *     - User-related entities should be grouped under 'Actors' namespace
   *     - Product and sales information under 'Sales' namespace
   *     - System configuration under 'Systematic' namespace"
   */
  thinking: string;
 
  /**
   * Review and refinement of the namespace classification.
   *
   * Contains the AI agent's review process, considering relationships between
   * tables and potential improvements to the initial classification.
   *
   * **Example:**
   *
   *     "Upon review, I noticed that 'shopping_channel_categories' has strong
   *     relationships with both channels and sales. However, since it primarily
   *     defines the channel structure, it should remain in 'Systematic' namespace."
   */
  review: string;
 
  /**
   * Final decision on namespace classification.
   *
   * Contains the AI agent's final reasoning and rationale for the chosen
   * namespace organization, explaining why this structure best serves the
   * business requirements.
   *
   * **Example:**
   *
   *     "Final decision: Organize tables into 3 main namespaces:
   *     1. Systematic - for channel and system configuration
   *     2. Actors - for all user types (customers, citizens, administrators)
   *     3. Sales - for product sales and related transactional data
   *     This structure provides clear separation of concerns and follows DDD principles."
   */
  decision: string;
 
  /**
   * Array of component groups organizing tables by business domain and
   * functional relationships.
   *
   * Each component represents a logical grouping of database tables that belong
   * to the same business domain or functional area. The grouping follows
   * domain-driven design principles where related tables are organized together
   * to maintain coherent schema files and enable systematic development.
   *
   * Each component includes the target filename for the schema file and the
   * list of table names that will be included in that domain. This organization
   * ensures that the generated Prisma schema files are logically structured and
   * maintainable, with clear separation of concerns across different business
   * areas.
   */
  components: AutoBePrisma.IComponent[];
 
  /**
   * Iteration number of the requirements analysis this component organization
   * was performed for.
   *
   * Indicates which version of the requirements analysis this table
   * organization reflects. This step number ensures that the database component
   * structure is aligned with the current requirements and helps track the
   * evolution of database architecture as business requirements change.
   *
   * The step value enables proper synchronization between database organization
   * and the underlying requirements, ensuring that the schema structure remains
   * relevant to the current project scope and business objectives.
   */
  step: number;
}
 
//----------------------------------------
// File: AutoBePrismaSchemasEvent.ts
//----------------------------------------
import { AutoBePrisma } from "../prisma";
import { AutoBeEventBase } from "./AutoBeEventBase";
import { AutoBeProgressEventBase } from "./AutoBeProgressEventBase";
import { AutoBeTokenUsageEventBase } from "./AutoBeTokenUsageEventBase";
 
/**
 * Event fired when the Prisma agent generates a complete schema file for a
 * specific business domain during the database design process.
 *
 * This event occurs when the Prisma agent has successfully designed and
 * generated all database tables for a particular business domain (e.g., Sales,
 * Orders, Users). The agent follows a systematic 2-step process: strategic
 * planning (plan) and model generation (models), producing production-ready
 * database schemas that maintain data integrity and business logic accuracy.
 * The generated models will be reviewed by a separate review agent.
 *
 * Each schema file represents a cohesive unit of database design focused on a
 * specific business area, following domain-driven design principles. The
 * progressive completion of schema files provides real-time visibility into the
 * database architecture development, enabling stakeholders to track progress
 * and validate domain-specific data models incrementally.
 *
 * @author Samchon
 */
export interface AutoBePrismaSchemasEvent
  extends AutoBeEventBase<"prismaSchemas">,
    AutoBeProgressEventBase,
    AutoBeTokenUsageEventBase {
  /**
   * Strategic database design analysis and planning phase.
   *
   * Contains the AI agent's comprehensive analysis of the target business
   * domain and its database design strategy. The agent evaluates the required
   * tables, their relationships, normalization requirements, and performance
   * considerations to create a well-architected database schema that aligns
   * with business objectives and technical best practices.
   *
   * This planning phase establishes the foundation for the entire schema
   * design, ensuring proper table organization, relationship mapping, and
   * adherence to database normalization principles while considering future
   * scalability and maintainability requirements.
   */
  plan: string;
 
  /**
   * Prisma schema models generated based on the strategic plan.
   *
   * Contains the production-ready AST representation of Prisma schema models
   * generated following the strategic plan. These models implement all planned
   * tables, relationships, and constraints using the AutoBePrisma.IModel
   * interface. The models are designed to be production-ready from the start.
   *
   * The models include exact table names from requirements, proper UUID primary
   * fields, foreign key relationships, business fields with appropriate types,
   * strategic indexes, and comprehensive English-only descriptions.
   */
  models: AutoBePrisma.IModel[];
 
  /**
   * Generated Prisma schema file information for a specific business domain.
   *
   * This field contains the complete schema file data including the filename,
   * namespace, and the production-ready Prisma schema models. The AI agent has
   * analyzed the requirements, designed the tables, and produced models that
   * include all necessary relationships, indexes, and constraints.
   *
   * The generated file follows the naming convention
   * `schema-{number}-{domain}.prisma` where the number indicates dependency
   * order and the domain represents the business area. The final models within
   * the file follow Prisma conventions while incorporating enterprise patterns
   * like snapshot tables and materialized views.
   *
   * Each model in the file.models array represents a table in the database with
   * proper field definitions, relationships, indexes, and comprehensive
   * documentation, designed to ensure production readiness from the initial
   * generation.
   */
  file: AutoBePrisma.IFile;
 
  /**
   * Iteration number of the requirements analysis this schema was generated
   * for.
   *
   * Tracks which version of the business requirements this database schema
   * reflects, ensuring alignment between the evolving requirements and the
   * generated data models. As requirements change through iterations, this step
   * number helps maintain traceability and version consistency across the
   * database architecture development process.
   */
  step: number;
}
 
//----------------------------------------
// File: AutoBePrismaValidateEvent.ts
//----------------------------------------
import { IAutoBePrismaCompileResult } from "../compiler/IAutoBePrismaCompileResult";
import { IAutoBePrismaValidation } from "../prisma/IAutoBePrismaValidation";
import { AutoBeEventBase } from "./AutoBeEventBase";
 
/**
 * Event fired when the Prisma agent validates the constructed database design
 * and encounters validation failures that need correction.
 *
 * This event occurs when the custom Prisma compiler processes the generated AST
 * structure and detects validation errors that prevent successful schema
 * compilation. The validation process represents a critical quality gate in the
 * vibe coding pipeline, ensuring that only semantically correct and
 * business-aligned database designs proceed to final generation.
 *
 * The validation event triggers the feedback loop that enables AI
 * self-correction, providing detailed error information that helps the Prisma
 * agent understand what needs to be fixed and how to improve the database
 * design quality.
 *
 * @author Samchon
 */
export interface AutoBePrismaValidateEvent
  extends AutoBeEventBase<"prismaValidate"> {
  /**
   * The validation failure details describing what errors were detected.
   *
   * Contains the specific {@link IAutoBePrismaValidation.IFailure} information
   * that describes the validation errors found in the database design. This
   * includes details about relationship issues, constraint violations, naming
   * problems, performance concerns, or other semantic errors that prevent the
   * design from meeting quality standards.
   *
   * The failure information provides comprehensive diagnostic details necessary
   * for the AI to understand the validation problems and formulate appropriate
   * corrections to resolve the identified issues.
   */
  result: IAutoBePrismaValidation.IFailure;
 
  /**
   * Results of attempting to compile the current database design.
   *
   * Contains the {@link IAutoBePrismaCompileResult} from the compilation attempt
   * that revealed the validation issues. Even when validation fails, the
   * compiler may provide partial results or additional diagnostic information
   * that helps understand the scope and nature of the problems.
   *
   * The compilation results offer additional context beyond the validation
   * failure, potentially including information about which parts of the design
   * are working correctly and which specific areas need attention.
   */
  compiled: IAutoBePrismaCompileResult;
 
  /**
   * Generated schema files that failed validation as key-value pairs.
   *
   * Contains the Prisma schema files that were generated but failed to pass
   * validation. Each key represents the filename and each value contains the
   * schema content that contains the validation errors. These schemas provide
   * context for understanding what was attempted and where the problems
   * occurred.
   *
   * Having access to the failing schemas enables detailed analysis of the
   * validation issues and helps in formulating precise corrections that address
   * the specific problems without disrupting working portions of the design.
   */
  schemas: Record<string, string>;
 
  /**
   * Iteration number of the requirements analysis this validation was performed
   * for.
   *
   * Indicates which version of the requirements analysis this database
   * validation reflects. This step number ensures that the validation feedback
   * is aligned with the current requirements and helps track the quality
   * improvement process as validation issues are identified and resolved.
   *
   * The step value enables proper synchronization between validation activities
   * and the underlying requirements, ensuring that validation efforts remain
   * relevant to the current project scope and business objectives.
   */
  step: number;
}
 
//----------------------------------------
// File: AutoBePrismaCorrectEvent.ts
//----------------------------------------
import { AutoBePrisma } from "../prisma/AutoBePrisma";
import { IAutoBePrismaValidation } from "../prisma/IAutoBePrismaValidation";
import { AutoBeEventBase } from "./AutoBeEventBase";
import { AutoBeTokenUsageEventBase } from "./AutoBeTokenUsageEventBase";
 
/**
 * Event fired when the Prisma agent corrects validation failures in the
 * database design.
 *
 * This event occurs when the custom Prisma compiler detects validation errors
 * in the constructed AST structure and the Prisma agent receives feedback to
 * correct compilation issues. The correction process represents the
 * sophisticated feedback loop that enables AI self-correction, ensuring that
 * only valid and semantically correct database designs proceed to final
 * generation.
 *
 * The correction mechanism is essential for maintaining the reliability of the
 * vibe coding pipeline, allowing the system to iteratively refine database
 * designs until they meet all validation requirements and business
 * constraints.
 *
 * @author Samchon
 */
export interface AutoBePrismaCorrectEvent
  extends AutoBeEventBase<"prismaCorrect">,
    AutoBeTokenUsageEventBase {
  /**
   * The validation failure details that triggered the correction process.
   *
   * Contains the specific {@link IAutoBePrismaValidation.IFailure} information
   * that describes what validation errors were detected in the database design.
   * This includes details about relationship issues, constraint violations,
   * naming problems, or other semantic errors that prevented successful
   * validation.
   *
   * The failure information provides the diagnostic context necessary for the
   * AI to understand what went wrong and make appropriate corrections to the
   * database design.
   */
  failure: IAutoBePrismaValidation.IFailure;
 
  /**
   * The corrected AST application structure addressing the validation failures.
   *
   * Contains the revised {@link AutoBePrisma.IApplication} structure that
   * attempts to resolve the validation issues identified in the failure. The
   * correction incorporates the feedback from the validation process to address
   * relationship problems, fix constraint violations, resolve naming conflicts,
   * or correct other structural issues.
   *
   * This corrected structure will undergo validation again to ensure that the
   * modifications successfully resolve the identified problems while
   * maintaining the integrity of the overall database design.
   */
  correction: AutoBePrisma.IApplication;
 
  /**
   * Explanation of the correction strategy and changes being made.
   *
   * Describes the AI's analysis of the validation failure and the specific
   * approach being taken to resolve the issues. This planning explanation
   * provides transparency into the correction process, helping stakeholders
   * understand what changes are being made and why they are necessary.
   *
   * The planning commentary helps track the iterative improvement process and
   * provides insights into how the AI learns from validation feedback to
   * improve database design quality.
   */
  planning: string;
 
  /**
   * Iteration number of the requirements analysis this correction was performed
   * for.
   *
   * Indicates which version of the requirements analysis this database
   * correction reflects. This step number ensures that the correction efforts
   * are aligned with the current requirements and helps track the evolution of
   * database design quality as validation feedback is incorporated.
   *
   * The step value enables proper synchronization between correction activities
   * and the underlying requirements, ensuring that design improvements remain
   * relevant to the current project scope and business objectives.
   */
  step: number;
}
 
//----------------------------------------
// File: AutoBePrismaCompleteEvent.ts
//----------------------------------------
import { IAutoBePrismaCompileResult } from "../compiler";
import { AutoBePrisma, IAutoBePrismaValidation } from "../prisma";
import { AutoBeEventBase } from "./AutoBeEventBase";
 
/**
 * Event fired when the Prisma agent completes the database design process and
 * successfully generates validated schema files.
 *
 * This event represents the successful completion of the sophisticated
 * three-tier compiler infrastructure that transforms business requirements into
 * validated database architectures. The completion marks the transition from
 * requirements analysis to a concrete database implementation that maintains
 * perfect semantic integrity and syntactic correctness.
 *
 * The Prisma agent's completion ensures that the database design accurately
 * reflects business needs while providing the foundation for subsequent API
 * development and application implementation phases.
 *
 * @author Samchon
 */
export interface AutoBePrismaCompleteEvent
  extends AutoBeEventBase<"prismaComplete"> {
  /**
   * The validated AST application structure containing the complete database
   * design.
   *
   * Contains the finalized {@link AutoBePrisma.IApplication} structure that
   * represents the complete database architecture as validated AST data. This
   * application includes all models, relationships, constraints, and business
   * rules that have passed through the comprehensive validation process
   * including relationship graph analysis, business logic validation, and
   * performance optimization.
   *
   * The application structure serves as the authoritative source of database
   * design that has been verified for semantic correctness and business
   * alignment before code generation.
   */
  result: IAutoBePrismaValidation;
 
  /**
   * Generated Prisma schema files as key-value pairs.
   *
   * Contains the production-ready schema files generated through deterministic
   * code generation from the validated AST structure. Each key represents the
   * filename (following the pattern `schema-{number}-{domain}.prisma`) and each
   * value contains the actual Prisma schema content organized by business
   * domains.
   *
   * The schemas include comprehensive documentation, optimal indexes, proper
   * constraints, and all optimizations derived from the AST analysis, ready for
   * immediate deployment to the target database environment.
   */
  schemas: Record<string, string>;
 
  /**
   * Results of compiling the generated Prisma schema files.
   *
   * Contains the {@link IAutoBePrismaCompileResult} from processing the
   * generated schemas through the Prisma compiler. This should always indicate
   * successful compilation since the schemas are generated from pre-validated
   * AST structures. The compilation results include documentation, diagrams,
   * and dependency files ready for deployment.
   *
   * Successful compilation confirms that the generated schemas will work
   * correctly in the target database environment and integrate properly with
   * the broader development ecosystem.
   */
  compiled: IAutoBePrismaCompileResult;
 
  /**
   * Iteration number of the requirements analysis this database design was
   * completed for.
   *
   * Indicates which version of the requirements analysis this database design
   * reflects. This step number ensures that the database implementation is
   * aligned with the current requirements and helps track the evolution of data
   * architecture as business requirements change.
   *
   * The step value enables proper synchronization between database design and
   * the underlying requirements, ensuring that subsequent development phases
   * work with the most current and relevant database foundation.
   */
  step: number;
 
  /**
   * Elapsed time in milliseconds for the entire Prisma completion process.
   *
   * Indicates the total time taken from the start of the Prisma design phase
   * until its completion. This metric helps in understanding the efficiency of
   * the database design and validation process, providing insights into the
   * time investment required for thorough design, validation, and code
   * generation.
   *
   * This elapsed time is same with the difference between the timestamps
   * recorded in the `created_at` field of the `AutoBePrismaStartEvent` and this
   * event.
   */
  elapsed: number;
}

import { tags } from "typia";
 
import { CamelPattern } from "../typings";
import { SnakePattern } from "../typings/SnakePattern";
 
/**
 * AST type system for programmatic Prisma ORM schema generation through AI
 * function calling.
 *
 * This namespace defines a comprehensive Abstract Syntax Tree structure that
 * enables AI agents to construct complete Prisma schema files at the AST level.
 * Each type corresponds to specific Prisma Schema Language (PSL) constructs,
 * allowing precise control over generated database schemas while maintaining
 * type safety and business logic accuracy.
 *
 * ## Core Purpose
 *
 * The system is designed for systematic generation where AI function calls
 * build database schemas step-by-step, mapping business requirements to
 * executable Prisma schema code. Instead of generating raw PSL strings, AI
 * agents construct structured AST objects that represent:
 *
 * - Complete database schemas organized by business domains
 * - Properly typed models with relationships and constraints
 * - Performance-optimized indexes for common query patterns
 * - Business-appropriate data types and validation rules
 *
 * ## Architecture Overview
 *
 * - **IApplication**: Root container representing the entire database schema
 * - **IFile**: Domain-specific schema files organized by business functionality
 * - **IModel**: Database tables representing business entities with full
 *   relationship mapping
 * - **Fields**: Primary keys, foreign keys, and business data fields with proper
 *   typing
 * - **Indexes**: Performance optimization through unique, regular, and full-text
 *   search indexes
 *
 * ## Domain-Driven Schema Organization
 *
 * Schemas are typically organized into multiple domain-specific files following
 * DDD principles:
 *
 * - Core/System: Foundation entities and application configuration
 * - Identity: User management, authentication, and authorization
 * - Business Logic: Domain-specific entities and workflows
 * - Transactions: Financial operations and payment processing
 * - Communication: Messaging, notifications, and user interactions
 * - Content: Media management, documentation, and publishing systems
 * - Analytics: Reporting, metrics, and business intelligence data
 *
 * ## Database Design Patterns
 *
 * The generated schemas follow enterprise-grade patterns:
 *
 * - UUID primary keys for distributed system compatibility and security
 * - Snapshot/versioning tables for audit trails and data history
 * - Junction tables for many-to-many relationship management
 * - Materialized views for performance optimization of complex queries
 * - Soft deletion patterns with timestamp-based lifecycle management
 * - Full-text search capabilities using PostgreSQL GIN indexes
 *
 * Each generated schema reflects real business workflows where entities
 * maintain proper relationships, data integrity constraints, and performance
 * characteristics suitable for production applications handling complex
 * business logic and high query volumes.
 *
 * @author Samchon
 */
export namespace AutoBePrisma {
  /**
   * Root interface representing the entire Prisma application schema.
   *
   * Contains multiple schema files that will be generated, typically organized
   * by business domain. Based on the uploaded schemas, applications usually
   * contain 8-10 files covering different functional areas like user
   * management, sales, orders, etc.
   */
  export interface IApplication {
    /**
     * Array of Prisma schema files to be generated.
     *
     * Each file represents a specific business domain or functional area.
     * Examples from uploaded schemas: systematic (channels/sections), actors
     * (users/customers), sales (products/snapshots), carts, orders, coupons,
     * coins (deposits/mileage), inquiries, favorites, and articles (BBS
     * system).
     */
    files: IFile[];
  }
 
  /**
   * Interface representing a logical grouping of database tables organized by
   * business domain for schema file generation.
   *
   * Components provide a systematic way to organize database tables into
   * coherent groups following domain-driven design principles. Each component
   * represents a specific business domain or functional area that will be
   * generated as a separate Prisma schema file, ensuring maintainable and
   * logically structured database architecture.
   *
   * This interface is primarily used during the database design phase when the
   * Prisma agent analyzes requirements and determines the complete scope of
   * tables needed, then organizes them into logical groups based on business
   * relationships and functional dependencies.
   *
   * ## Usage in Schema Generation Process
   *
   * Components serve as the blueprint for generating multiple Prisma schema
   * files:
   *
   * 1. **Requirements Analysis**: AI agent identifies all required tables from
   *    business requirements
   * 2. **Domain Grouping**: Tables are organized into components based on business
   *    domains and functional relationships
   * 3. **File Generation**: Each component becomes a separate .prisma file
   *    containing related models
   * 4. **Dependency Management**: Components are ordered to handle cross-domain
   *    relationships properly
   *
   * ## Domain Organization Examples
   *
   * Based on typical business applications, components commonly include:
   *
   * - **Systematic**: Core system tables (channels, sections, configurations)
   * - **Actors**: User management (customers, citizens, administrators)
   * - **Sales**: Product catalog and sales entities
   * - **Carts**: Shopping cart and item management
   * - **Orders**: Order processing and fulfillment
   * - **Coupons**: Discount and promotion systems
   * - **Coins**: Digital currency and mileage systems
   * - **Inquiries**: Customer support and FAQ systems
   * - **Favorites**: User preference and wishlist management
   * - **Articles**: Content management and BBS systems
   *
   * ## Relationship to {@link AutoBePrisma.IFile}
   *
   * Each IComponent serves as a blueprint for generating one IFile during the
   * schema generation process. The component's metadata (filename, namespace,
   * tables) is used to structure the actual Prisma schema file with proper
   * models, relationships, and indexes.
   *
   * @see IFile For the actual schema file structure generated from components
   * @see AutoBePrismaComponentsEvent For the event that delivers component
   * organization results
   */
  export interface IComponent {
    /**
     * Target filename for the Prisma schema file containing this component's
     * tables.
     *
     * Follows the naming convention `schema-{number}-{domain}.prisma` where the
     * number indicates dependency order and domain represents the business
     * area.
     */
    filename: string & tags.Pattern<"^[a-zA-Z0-9._-]+\\.prisma$">;
 
    /**
     * Business domain namespace that groups related models.
     *
     * Used in Prisma documentation comments as "@\namespace directive".
     * Examples from uploaded schemas: "Systematic", "Actors", "Sales", "Carts",
     * "Orders", "Coupons", "Coins", "Inquiries", "Favorites", "Articles"
     */
    namespace: string;
 
    /**
     * Initial thoughts on why these tables belong together.
     *
     * **Example:**
     *
     *     "These tables all relate to user management and authentication.
     *     They share common patterns like user identification and access control."
     */
    thinking: string;
 
    /**
     * Review considerations for this component grouping.
     *
     * **Example:**
     *
     *     "Reviewed relationships with other domains. While customers create orders,
     *     the customer entity itself is fundamentally about user identity, not sales."
     */
    review: string;
 
    /**
     * Final rationale for this component's composition.
     *
     * **Example:**
     *
     *     "This component groups all actor-related tables to maintain a clear
     *     separation between identity management and business transactions."
     */
    rationale: string;
 
    /**
     * Array of table names that will be included in this component's schema
     * file.
     *
     * Contains all database table names that belong to this business domain,
     * ensuring logical grouping and proper organization of related data
     * structures.
     */
    tables: Array<string & SnakePattern> & tags.MinItems<1>;
  }
 
  /**
   * Interface representing a single Prisma schema file within the application.
   *
   * Each file focuses on a specific business domain and contains related
   * models. File organization follows domain-driven design principles as seen
   * in the uploaded schemas.
   */
  export interface IFile {
    /**
     * Name of the schema file to be generated.
     *
     * Should follow the naming convention: "schema-{number}-{domain}.prisma"
     * Examples: "schema-02-systematic.prisma", "schema-03-actors.prisma" The
     * number indicates the dependency order for schema generation.
     */
    filename: string & tags.Pattern<"^[a-zA-Z0-9._-]+\\.prisma$">;
 
    /**
     * Business domain namespace that groups related models.
     *
     * Used in Prisma documentation comments as "@\namespace directive".
     * Examples from uploaded schemas: "Systematic", "Actors", "Sales", "Carts",
     * "Orders", "Coupons", "Coins", "Inquiries", "Favorites", "Articles"
     */
    namespace: string;
 
    /**
     * Array of Prisma models (database tables) within this domain.
     *
     * Each model represents a business entity or concept within the namespace.
     * Models can reference each other through foreign key relationships.
     */
    models: IModel[] & tags.MinItems<1>;
  }
 
  /**
   * Interface representing a single Prisma model (database table).
   *
   * Based on the uploaded schemas, models follow specific patterns:
   *
   * - Main business entities (e.g., shopping_sales, shopping_customers)
   * - Snapshot/versioning entities for audit trails (e.g.,
   *   shopping_sale_snapshots)
   * - Junction tables for M:N relationships (e.g.,
   *   shopping_cart_commodity_stocks)
   * - Materialized views for performance (prefixed with mv_)
   */
  export interface IModel {
    /**
     * Name of the Prisma model (database table name).
     *
     * MUST use snake_case naming convention. Examples: "shopping_customers",
     * "shopping_sale_snapshots", "bbs_articles" Materialized views use "mv_"
     * prefix: "mv_shopping_sale_last_snapshots"
     */
    name: string & SnakePattern;
 
    /**
     * Detailed description explaining the business purpose and usage of the
     * model.
     *
     * Should include:
     *
     * - Business context and purpose
     * - Key relationships with other models
     * - Important behavioral notes or constraints
     * - References to related entities using "{@\link ModelName}" syntax
     *
     * **IMPORTANT**: Description must be written in English. Example: "Customer
     * information, but not a person but a **connection** basis..."
     */
    description: string;
 
    /**
     * Indicates whether this model represents a materialized view for
     * performance optimization.
     *
     * Materialized views are read-only computed tables that cache complex query
     * results. They're marked as "@\hidden" in documentation and prefixed with
     * "mv_" in naming. Examples: mv_shopping_sale_last_snapshots,
     * mv_shopping_cart_commodity_prices
     */
    material: boolean;
 
    /**
     * Specifies the architectural stance of this model within the database
     * system.
     *
     * This property defines how the table positions itself in relation to other
     * tables and what role it plays in the overall data architecture,
     * particularly for API endpoint generation and business logic
     * organization.
     *
     * ## Values:
     *
     * ### `"primary"` - Main Business Entity
     *
     * Tables that represent core business concepts and serve as the primary
     * subjects of user operations. These tables typically warrant independent
     * CRUD API endpoints since users directly interact with these entities.
     *
     * **Key principle**: If users need to independently create, search, filter,
     * or manage entities regardless of their parent context, the table should
     * be primary stance.
     *
     * **API Requirements:**
     *
     * - Independent creation endpoints (POST /articles, POST /comments)
     * - Search and filtering capabilities across all instances
     * - Direct update and delete operations
     * - List/pagination endpoints for browsing
     *
     * **Why `bbs_article_comments` is primary, not subsidiary:**
     *
     * Although comments belong to articles, they require independent
     * management:
     *
     * - **Search across articles**: "Find all comments by user X across all
     *   articles"
     * - **Moderation workflows**: "List all pending comments for review"
     * - **User activity**: "Show all comments made by this user"
     * - **Independent operations**: Users edit/delete their comments directly
     * - **Notification systems**: "Alert when any comment is posted"
     *
     * If comments were subsidiary, these operations would be impossible or
     * require inefficient nested queries through parent articles.
     *
     * **Characteristics:**
     *
     * - Represents tangible business concepts that users manage
     * - Serves as reference points for other tables
     * - Requires comprehensive API operations (CREATE, READ, UPDATE, DELETE)
     * - Forms the backbone of the application's business logic
     *
     * **Examples:**
     *
     * - `bbs_articles` - Forum posts that users create, edit, and manage
     * - `bbs_article_comments` - User comments that require independent
     *   management
     *
     * ### `"subsidiary"` - Supporting/Dependent Entity
     *
     * Tables that exist to support primary entities but are not independently
     * managed by users. These tables are typically managed through their parent
     * entities and may not need standalone API endpoints.
     *
     * **Characteristics:**
     *
     * - Depends on primary or snapshot entities for context
     * - Often managed indirectly through parent entity operations
     * - May have limited or no independent API operations
     * - Provides supporting data or relationships
     *
     * **Examples:**
     *
     * - `bbs_article_snapshot_files` - Files attached to article snapshots
     * - `bbs_article_snapshot_tags` - Tags associated with article snapshots
     * - `bbs_article_comment_snapshot_files` - Files attached to comment
     *   snapshots
     *
     * ### `"snapshot"` - Historical/Versioning Entity
     *
     * Tables that capture point-in-time states of primary entities for audit
     * trails, version control, or historical tracking. These tables record
     * changes but are rarely modified directly by users.
     *
     * **Characteristics:**
     *
     * - Captures historical states of primary entities
     * - Typically append-only (rarely updated or deleted)
     * - Referenced for audit trails and change tracking
     * - Usually read-only from user perspective
     *
     * **Examples:**
     *
     * - `bbs_article_snapshots` - Historical states of articles
     * - `bbs_article_comment_snapshots` - Comment modification history
     *
     * ## API Generation Guidelines:
     *
     * The stance property guides automatic API endpoint generation:
     *
     * - **`"primary"`** → Generate full CRUD endpoints based on business
     *   requirements
     * - **`"subsidiary"`** → Evaluate carefully; often managed through parent
     *   entities
     * - **`"snapshot"`** → Typically read-only endpoints for historical data
     *   access
     *
     * @example
     *   ```typescript
     *   // Primary business entity - needs full CRUD API
     *   {
     *     name: "bbs_articles",
     *     stance: "primary",
     *     description: "Forum articles that users create and manage independently"
     *   }
     *
     *   // Another primary entity - despite being "child" of articles
     *   {
     *     name: "bbs_article_comments",
     *     stance: "primary",
     *     description: "User comments requiring independent search and management"
     *   }
     *
     *   // Subsidiary entity - managed through snapshot operations
     *   {
     *     name: "bbs_article_snapshot_files",
     *     stance: "subsidiary",
     *     description: "Files attached to article snapshots, managed via snapshot APIs"
     *   }
     *
     *   // Snapshot entity - read-only historical data
     *   {
     *     name: "bbs_article_snapshots",
     *     stance: "snapshot",
     *     description: "Historical states of articles for audit and versioning"
     *   }
     *   ```;
     */
    stance: "primary" | "subsidiary" | "snapshot";
 
    //----
    // FIELDS
    //----
    /**
     * The primary key field of the model.
     *
     * In all uploaded schemas, primary keys are always UUID type with "@\id"
     * directive. Usually named "id" and marked with "@\db.Uuid" for PostgreSQL
     * mapping.
     */
    primaryField: IPrimaryField;
 
    /**
     * Array of foreign key fields that reference other models.
     *
     * These establish relationships between models and include Prisma relation
     * directives. Can be nullable (optional relationships) or required
     * (mandatory relationships). May have unique constraints for 1:1
     * relationships.
     */
    foreignFields: IForeignField[];
 
    /**
     * Array of regular data fields that don't reference other models.
     *
     * Include business data like names, descriptions, timestamps, flags,
     * amounts, etc. Common patterns: created_at, updated_at, deleted_at for
     * soft deletion and auditing.
     */
    plainFields: IPlainField[];
 
    //----
    // INDEXES
    //----
    /**
     * Array of unique indexes for enforcing data integrity constraints.
     *
     * Ensure uniqueness across single or multiple columns. Examples: unique
     * email addresses, unique codes within a channel, unique combinations like
     * (channel_id, nickname).
     */
    uniqueIndexes: IUniqueIndex[];
 
    /**
     * Array of regular indexes for query performance optimization.
     *
     * Speed up common query patterns like filtering by foreign keys, date
     * ranges, or frequently searched fields. Examples: indexes on created_at,
     * foreign key fields, search fields.
     */
    plainIndexes: IPlainIndex[];
 
    /**
     * Array of GIN (Generalized Inverted Index) indexes for full-text search.
     *
     * Used specifically for PostgreSQL text search capabilities using trigram
     * operations. Applied to text fields that need fuzzy matching or partial
     * text search. Examples: searching names, nicknames, titles, content
     * bodies.
     */
    ginIndexes: IGinIndex[];
  }
 
  /**
   * Interface representing the primary key field of a Prisma model.
   *
   * All models in the uploaded schemas use UUID as primary key for better
   * distributed system compatibility and security (no sequential ID exposure).
   */
  export interface IPrimaryField {
    /**
     * Name of the primary key field.
     *
     * MUST use snake_case naming convention. Consistently named "id" across all
     * models in the uploaded schemas. Represents the unique identifier for each
     * record in the table.
     */
    name: string & SnakePattern;
 
    /**
     * Data type of the primary key field.
     *
     * Always "uuid" in the uploaded schemas for better distributed system
     * support and to avoid exposing sequential IDs that could reveal business
     * information.
     */
    type: "uuid";
 
    /**
     * Description of the primary key field's purpose.
     *
     * Standard description is "Primary Key." across all models. Serves as the
     * unique identifier for the model instance.
     *
     * **IMPORTANT**: Description must be written in English.
     */
    description: string;
  }
 
  /**
   * Interface representing a foreign key field that establishes relationships
   * between models.
   *
   * Foreign keys create associations between models, enabling relational data
   * modeling. They can represent 1:1, 1:N, or participate in M:N relationships
   * through junction tables.
   */
  export interface IForeignField {
    /**
     * Name of the foreign key field.
     *
     * MUST use snake_case naming convention. Follows convention:
     * "{target_model_name_without_prefix}_id" Examples: "shopping_customer_id",
     * "bbs_article_id", "attachment_file_id" For self-references: "parent_id"
     * (e.g., in hierarchical structures)
     */
    name: string & SnakePattern;
 
    /**
     * Data type of the foreign key field.
     *
     * Always "uuid" to match the primary key type of referenced models. Ensures
     * referential integrity and consistency across the schema.
     */
    type: "uuid";
 
    /**
     * Description explaining the purpose and target of this foreign key
     * relationship.
     *
     * Should reference the target model using format: "Target model's {@\link
     * ModelName.id}" Examples: "Belonged customer's {@\link
     * shopping_customers.id}" May include additional context about the
     * relationship's business meaning.
     *
     * **IMPORTANT**: Description must be written in English.
     */
    description: string;
 
    /**
     * Prisma relation configuration defining the association details.
     *
     * Specifies how this foreign key connects to the target model, including
     * relation name, target model, and target field. This configuration is used
     * to generate the appropriate Prisma relation directive in the schema.
     */
    relation: IRelation;
 
    /**
     * Whether this foreign key has a unique constraint.
     *
     * True: Creates a 1:1 relationship (e.g., user profile, order publish
     * details) false: Allows 1:N relationship (e.g., customer to multiple
     * orders) Used for enforcing business rules about relationship
     * cardinality.
     */
    unique: boolean;
 
    /**
     * Whether this foreign key can be null (optional relationship).
     *
     * True: Relationship is optional, foreign key can be null false:
     * Relationship is required, foreign key cannot be null Reflects business
     * rules about mandatory vs optional associations.
     */
    nullable: boolean;
  }
 
  /**
   * Interface representing a Prisma relation configuration between models.
   *
   * This interface defines how foreign key fields establish relationships with
   * their target models. It provides the necessary information for Prisma to
   * generate appropriate relation directives (@relation) in the schema,
   * enabling proper relational data modeling and ORM functionality.
   *
   * The relation configuration is essential for:
   *
   * - Generating correct Prisma relation syntax
   * - Establishing bidirectional relationships between models
   * - Enabling proper type-safe querying through Prisma client
   * - Supporting complex relationship patterns (1:1, 1:N, M:N)
   */
  export interface IRelation {
    /**
     * Name of the relation property in the Prisma model.
     *
     * This becomes the property name used to access the related model instance
     * through the Prisma client. Should be descriptive and reflect the business
     * relationship being modeled.
     *
     * Examples:
     *
     * - "customer" for shopping_customer_id field
     * - "channel" for shopping_channel_id field
     * - "parent" for parent_id field in hierarchical structures
     * - "snapshot" for versioning relationships
     * - "article" for bbs_article_id field
     *
     * Naming convention: camelCase, descriptive of the relationship's business
     * meaning
     */
    name: string & CamelPattern;
 
    /**
     * Name of the target model being referenced by this relation.
     *
     * Must exactly match an existing model name in the schema. This is used by
     * Prisma to establish the foreign key constraint and generate the
     * appropriate relation mapping.
     *
     * Examples:
     *
     * - "shopping_customers" for customer relationships
     * - "shopping_channels" for channel relationships
     * - "bbs_articles" for article relationships
     * - "attachment_files" for file attachments
     *
     * The target model should exist in the same schema or be accessible through
     * the Prisma schema configuration.
     */
    targetModel: string;
 
    /**
     * Optional explicit mapping name for complex relationship scenarios.
     *
     * Used internally by Prisma to handle advanced relationship patterns such
     * as:
     *
     * - Self-referential relationships with multiple foreign keys
     * - Complex many-to-many relationships through junction tables
     * - Relationships that require custom naming to avoid conflicts
     *
     * When not specified, Prisma automatically generates appropriate mapping
     * names based on the model names and field names. This field should only be
     * used when the automatic naming conflicts with other relationships or when
     * specific naming is required for business logic.
     *
     * Examples:
     *
     * - "ParentChild" for hierarchical self-references
     * - "CustomerOrder" for customer-order relationships
     * - "UserProfile" for user-profile 1:1 relationships
     *
     * @internal This field is primarily used by the code generation system
     * and should not be modified unless dealing with complex relationship patterns.
     */
    mappingName?: string;
  }
 
  /**
   * Interface representing a regular data field that stores business
   * information.
   *
   * These fields contain the actual business data like names, amounts,
   * timestamps, flags, descriptions, and other domain-specific information.
   */
  export interface IPlainField {
    /**
     * Name of the field in the database table.
     *
     * MUST use snake_case naming convention. Common patterns from uploaded
     * schemas:
     *
     * - Timestamps: created_at, updated_at, deleted_at, opened_at, closed_at
     * - Identifiers: code, name, nickname, title
     * - Business data: value, quantity, price, volume, balance
     * - Flags: primary, required, exclusive, secret, multiplicative
     */
    name: string & SnakePattern;
 
    /**
     * Data type of the field for Prisma schema generation.
     *
     * Maps to appropriate Prisma/PostgreSQL types:
     *
     * - Boolean: Boolean flags and yes/no values
     * - Int: Integer numbers, quantities, sequences
     * - Double: Decimal numbers, prices, monetary values, percentages
     * - String: Text data, names, descriptions, codes
     * - Uri: URL/URI fields for links and references
     * - Uuid: UUID fields (for non-foreign-key UUIDs)
     * - Datetime: Timestamp fields with date and time
     */
    type: "boolean" | "int" | "double" | "string" | "uri" | "uuid" | "datetime";
 
    /**
     * Description explaining the business purpose and usage of this field.
     *
     * Should clearly explain:
     *
     * - What business concept this field represents
     * - Valid values or constraints if applicable
     * - How it relates to business processes
     * - Any special behavioral notes
     *
     * **IMPORTANT**: Description must be written in English. Example: "Amount
     * of cash payment." or "Whether the unit is required or not."
     */
    description: string;
 
    /**
     * Whether this field can contain null values.
     *
     * True: Field is optional and can be null (e.g., middle name, description)
     * false: Field is required and cannot be null (e.g., creation timestamp,
     * name) Reflects business rules about mandatory vs optional data.
     */
    nullable: boolean;
  }
 
  /**
   * Interface representing a unique index constraint on one or more fields.
   *
   * Unique indexes enforce data integrity by ensuring no duplicate values exist
   * for the specified field combination. Essential for business rules that
   * require uniqueness like email addresses, codes, or composite keys.
   */
  export interface IUniqueIndex {
    /**
     * Array of field names that together form the unique constraint.
     *
     * Can be single field (e.g., ["email"]) or composite (e.g., ["channel_id",
     * "code"]). All field names must exist in the model. Order matters for
     * composite indexes. Examples: ["code"], ["shopping_channel_id",
     * "nickname"], ["email"]
     */
    fieldNames: string[] & tags.MinItems<1> & tags.UniqueItems;
 
    /**
     * Explicit marker indicating this is a unique index.
     *
     * Always true to distinguish from regular indexes. Used by code generator
     * to emit "@@unique" directive in Prisma schema instead of "@@index".
     */
    unique: true;
  }
 
  /**
   * Interface representing a regular (non-unique) index for query performance.
   *
   * Regular indexes speed up database queries by creating optimized data
   * structures for common search patterns. Essential for foreign keys, date
   * ranges, and frequently filtered fields.
   */
  export interface IPlainIndex {
    /**
     * Array of field names to include in the performance index.
     *
     * Can be single field (e.g., ["created_at"]) or composite (e.g.,
     * ["customer_id", "created_at"]). All field names must exist in the model.
     * Order matters for composite indexes and should match common query
     * patterns. Examples: ["created_at"], ["shopping_customer_id",
     * "created_at"], ["ip"]
     */
    fieldNames: string[] & tags.MinItems<1> & tags.UniqueItems;
  }
 
  /**
   * Interface representing a GIN (Generalized Inverted Index) for full-text
   * search.
   *
   * GIN indexes enable advanced PostgreSQL text search capabilities including
   * fuzzy matching and partial text search using trigram operations. Essential
   * for user-facing search features on text content.
   */
  export interface IGinIndex {
    /**
     * Name of the text field to index for full-text search capabilities.
     *
     * Must be a string field in the model that contains searchable text.
     * Examples from uploaded schemas: "nickname", "title", "body", "name" Used
     * with PostgreSQL gin_trgm_ops for trigram-based fuzzy text search.
     */
    fieldName: string;
  }
}

import { AutoBePrisma } from "./AutoBePrisma";
 
/**
 * Union type representing the result of Prisma schema validation.
 *
 * This type encapsulates the outcome of validating an AutoBePrisma.IApplication
 * structure against Prisma schema rules and business constraints. The
 * validation process checks for structural integrity, referential consistency,
 * naming conventions, and compliance with the established schema generation
 * rules.
 *
 * The validation can result in either complete success (all rules satisfied) or
 * failure with detailed error information for precise error resolution.
 *
 * @author Samchon
 */
export type IAutoBePrismaValidation =
  | IAutoBePrismaValidation.ISuccess
  | IAutoBePrismaValidation.IFailure;
 
/**
 * Namespace containing all interfaces for Prisma schema validation results.
 *
 * This namespace defines the structure for validation responses from the schema
 * validation system, providing detailed feedback about schema correctness and
 * specific error locations when validation fails.
 */
export namespace IAutoBePrismaValidation {
  /**
   * Interface representing a successful validation result.
   *
   * This interface is returned when the AutoBePrisma.IApplication structure
   * passes all validation rules including:
   *
   * - No duplicate model names across all files
   * - No duplicate field names within any model
   * - No duplicate relation names within any model
   * - All foreign key references point to existing models
   * - All field types are valid and properly configured
   * - All indexes follow the established rules (no single foreign key indexes)
   * - All naming conventions are properly applied (plural models, snake_case
   *   fields)
   * - All business constraints are satisfied
   */
  export interface ISuccess {
    /**
     * Validation success indicator.
     *
     * Always true for successful validation results. This discriminator
     * property allows TypeScript to properly narrow the union type and provides
     * runtime type checking for validation result processing.
     */
    success: true;
 
    /**
     * The validated and approved AutoBePrisma application structure.
     *
     * This contains the complete, validation-passed schema definition that can
     * be safely passed to the code generator for Prisma schema file creation.
     * All models, fields, relationships, and indexes in this structure have
     * been verified for correctness and compliance with schema rules.
     *
     * Important: This may not be identical to the original input application.
     * The validation process can apply automatic corrections to resolve
     * validation issues such as removing duplicates or fixing structural
     * problems. These corrections preserve the original business intent while
     * ensuring schema consistency and data integrity.
     */
    data: AutoBePrisma.IApplication;
  }
 
  /**
   * Interface representing a failed validation result with detailed error
   * information.
   *
   * This interface is returned when the AutoBePrisma.IApplication structure
   * contains one or more validation errors. It provides both the original
   * (potentially flawed) application structure and a comprehensive list of
   * specific errors that need to be resolved.
   *
   * The error information is structured to enable precise error location
   * identification and targeted fixes without affecting unrelated parts of the
   * schema.
   */
  export interface IFailure {
    /**
     * Validation failure indicator.
     *
     * Always false for failed validation results. This discriminator property
     * allows TypeScript to properly narrow the union type and indicates that
     * the errors array contains specific validation issues that must be
     * resolved.
     */
    success: false;
 
    /**
     * The original AutoBePrisma application structure that failed validation.
     *
     * This contains the complete schema definition as it was submitted for
     * validation, including all the elements that caused validation errors.
     * This structure serves as the baseline for error analysis and correction,
     * allowing error-fixing systems to understand the full context of the
     * schema while addressing specific validation issues.
     */
    data: AutoBePrisma.IApplication;
 
    /**
     * Array of specific validation errors found in the application structure.
     *
     * Each error provides precise location information (file path, model name,
     * field name) and detailed error descriptions to enable targeted fixes.
     * Errors are ordered by severity and location to facilitate systematic
     * resolution. The array will never be empty when success is false.
     *
     * Common error categories include:
     *
     * - Duplication errors (duplicate models, fields, relations)
     * - Reference errors (invalid foreign key targets, missing models)
     * - Type validation errors (invalid field types, constraint violations)
     * - Index configuration errors (invalid field references, forbidden single FK
     *   indexes)
     * - Naming convention violations (non-plural models, invalid field names)
     */
    errors: IError[];
  }
 
  /**
   * Interface representing a specific validation error with precise location
   * information.
   *
   * This interface provides detailed information about individual validation
   * errors, including exact location within the schema structure and
   * comprehensive error descriptions. The location information enables
   * error-fixing systems to pinpoint exactly where problems occur without
   * manual search or guesswork.
   *
   * Each error represents a specific violation of schema rules that must be
   * resolved for successful validation.
   */
  export interface IError {
    /**
     * File path where the validation error occurs.
     *
     * Specifies the exact schema file within the
     * AutoBePrisma.IApplication.files array where this error was detected. This
     * corresponds to the filename property of the IFile interface and enables
     * targeted file-level error resolution.
     *
     * Examples: "schema-01-articles.prisma", "schema-03-actors.prisma"
     *
     * This path information allows error-fixing systems to:
     *
     * - Navigate directly to the problematic file
     * - Understand cross-file reference issues
     * - Apply fixes within the correct file context
     * - Maintain proper file organization during error resolution
     */
    path: string;
 
    /**
     * Name of the model (database table) where the validation error occurs.
     *
     * Specifies the exact model within the identified file that contains the
     * validation error. This corresponds to the name property of the IModel
     * interface and enables targeted model-level error resolution.
     *
     * Examples: "shopping_customers", "bbs_articles",
     * "mv_shopping_sale_last_snapshots"
     *
     * When null, indicates file-level errors such as:
     *
     * - Duplicated file names
     * - Invalid file names
     *
     * This model information allows error-fixing systems to:
     *
     * - Navigate directly to the problematic model definition
     * - Understand model-specific constraint violations
     * - Apply fixes within the correct model context
     * - Resolve cross-model relationship issues
     */
    table: string | null;
 
    /**
     * Name of the specific field (column) where the validation error occurs.
     *
     * Specifies the exact field within the identified model that contains the
     * validation error, or null for model-level errors that don't relate to a
     * specific field. This corresponds to field names in primaryField,
     * foreignFields, or plainFields arrays of the IModel interface.
     *
     * Examples: "shopping_customer_id", "created_at", "name", null
     *
     * When null, indicates model-level errors such as:
     *
     * - Duplicate model names across files
     * - Missing primary key definitions
     * - Invalid model naming conventions
     * - Model-level constraint violations
     *
     * When string, indicates field-level errors such as:
     *
     * - Duplicate field names within the model
     * - Invalid field types or constraints
     * - Invalid foreign key configurations
     * - Field naming convention violations
     *
     * This field information allows error-fixing systems to:
     *
     * - Navigate directly to the problematic field definition
     * - Distinguish between model-level and field-level issues
     * - Apply targeted fixes without affecting other fields
     * - Resolve field-specific constraint violations
     */
    field: string | null;
 
    /**
     * Detailed human-readable description of the validation error.
     *
     * Provides comprehensive information about what validation rule was
     * violated, why it's problematic, and often hints at how to resolve the
     * issue. The message is designed to be informative enough for both
     * automated error-fixing systems and human developers to understand and
     * address the problem.
     *
     * Message format typically includes:
     *
     * - Clear description of what rule was violated
     * - Specific details about the problematic element
     * - Context about why this causes validation failure
     * - Sometimes suggestions for resolution approaches
     *
     * This message information allows error-fixing systems to:
     *
     * - Understand the exact nature of the validation failure
     * - Implement appropriate resolution strategies
     * - Provide meaningful feedback to developers
     * - Log detailed error information for debugging
     * - Make informed decisions about fix approaches
     */
    message: string;
  }
}

/**
 * Result of compiling and processing Prisma schema files through the custom
 * Prisma Compiler.
 *
 * This union type represents all possible outcomes when the Prisma Compiler
 * transforms validated {@link AutoBePrisma.IApplication} AST structures into
 * production-ready artifacts. The compilation process includes schema
 * validation, documentation generation, ERD diagram creation, and dependency
 * resolution.
 *
 * The compiler should always produce successful results since it operates on
 * pre-validated AST structures. Failure cases typically indicate issues with
 * the compilation environment or unexpected edge cases that should be reported
 * as bugs.
 *
 * @author Samchon
 */
export type IAutoBePrismaCompileResult =
  | IAutoBePrismaCompileResult.ISuccess
  | IAutoBePrismaCompileResult.IFailure
  | IAutoBePrismaCompileResult.IException;
 
export namespace IAutoBePrismaCompileResult {
  /**
   * Successful compilation result containing all generated artifacts.
   *
   * Represents the ideal outcome where the Prisma schema compilation completed
   * without errors and produced all expected outputs including documentation,
   * diagrams, and dependency files ready for deployment.
   */
  export interface ISuccess {
    /** Discriminator indicating successful compilation. */
    type: "success";
 
    /**
     * Generated comprehensive documentation for the database schema.
     *
     * Contains detailed markdown documentation automatically synthesized from
     * AST descriptions, including business context, technical constraints, and
     * operational characteristics for every model and field. This documentation
     * becomes an integral part of the codebase for ongoing maintenance.
     */
    document: string;
 
    /**
     * Generated Entity Relationship Diagrams as key-value pairs.
     *
     * Each key represents the diagram filename and each value contains the
     * diagram content (typically in Mermaid or other visualization format).
     * These diagrams are automatically generated through integration with
     * [`prisma-markdown`](https://github.com/samchon/prisma-markdown|prisma-markdown)
     * and provide visual documentation that stays synchronized with
     * implementation.
     */
    diagrams: Record<string, string>;
 
    /**
     * Final Prisma schema files optimized for production deployment.
     *
     * Contains the definitive schema files with all optimizations applied,
     * including automatically generated indexes, constraints, and performance
     * enhancements. These schemas are ready for immediate deployment to the
     * target database environment.
     */
    schemas: Record<string, string>;
 
    /**
     * Generated Node.js dependency files and configurations.
     *
     * Includes package.json configurations, TypeScript definitions, and other
     * Node.js ecosystem files required for proper integration with the
     * generated Prisma schemas. Ensures seamless compatibility with existing
     * development and deployment workflows.
     */
    nodeModules: Record<string, string>;
  }
 
  /**
   * Compilation failure with detailed error information.
   *
   * Represents cases where the compilation process encountered logical or
   * semantic errors that prevented successful generation of artifacts. This
   * should be rare since compilation operates on pre-validated AST structures.
   */
  export interface IFailure {
    /** Discriminator indicating compilation failure. */
    type: "failure";
 
    /**
     * Detailed explanation of why the compilation failed.
     *
     * Provides specific information about the error condition, including
     * context about which part of the compilation process failed and potential
     * remediation steps. This information is crucial for debugging and
     * improving the compilation process.
     */
    reason: string;
  }
 
  /**
   * Unexpected exception during compilation process.
   *
   * Represents cases where the compilation process encountered an unexpected
   * runtime error or system exception. These cases indicate potential bugs in
   * the compiler implementation that should be investigated and reported.
   */
  export interface IException {
    /** Discriminator indicating compilation exception. */
    type: "exception";
 
    /**
     * The raw error or exception that occurred during compilation.
     *
     * Contains the original error object or exception details for debugging
     * purposes. This information helps developers identify the root cause of
     * unexpected compilation failures and improve system reliability.
     */
    error: unknown;
  }
}

//----------------------------------------
// File: AutoBeInterfaceStartEvent.ts
//----------------------------------------
import { AutoBeEventBase } from "./AutoBeEventBase";
 
/**
 * Event fired when the Interface agent begins the RESTful API design process.
 *
 * This event marks the initiation of the sophisticated multi-stage
 * transformation pipeline that converts validated AST structures into
 * comprehensive API specifications. The Interface agent start represents a
 * critical transition point where database schemas and requirements analysis
 * are transformed into API contracts that bridge data storage and application
 * functionality.
 *
 * The API design process that begins with this event will proceed through
 * endpoint creation, operation definition, component specification, and final
 * code generation to produce production-ready NestJS applications with complete
 * type safety and business logic integration.
 *
 * @author Samchon
 */
export interface AutoBeInterfaceStartEvent
  extends AutoBeEventBase<"interfaceStart"> {
  /**
   * Reason why the Interface agent was activated through function calling.
   *
   * Explains the specific circumstances that triggered the AI chatbot to invoke
   * the Interface agent via function calling. This could include reasons such
   * as completing initial API design after database schema creation, updating
   * API specifications due to requirement changes, regenerating interfaces to
   * reflect modified data models, or creating new API endpoints for additional
   * functionality.
   *
   * Understanding the activation reason provides context for the API design
   * scope and helps stakeholders understand whether this represents new
   * development, refinement of existing specifications, or integration with
   * updated database schemas.
   */
  reason: string;
 
  /**
   * Iteration number of the requirements analysis this API design is being
   * started for.
   *
   * Indicates which version of the requirements analysis this API design will
   * reflect. This step number ensures that the Interface agent works with the
   * current requirements and helps track the evolution of API specifications as
   * requirements and database schemas change.
   *
   * The step value enables proper synchronization between API design activities
   * and the underlying requirements, ensuring that the API development remains
   * aligned with the current project scope and business objectives throughout
   * the iterative development process.
   */
  step: number;
}
 
//----------------------------------------
// File: AutoBeInterfaceEndpointsEvent.ts
//----------------------------------------
import { AutoBeOpenApi } from "../openapi/AutoBeOpenApi";
import { AutoBeEventBase } from "./AutoBeEventBase";
import { AutoBeProgressEventBase } from "./AutoBeProgressEventBase";
import { AutoBeTokenUsageEventBase } from "./AutoBeTokenUsageEventBase";
 
/**
 * Event fired when the Interface agent creates the complete list of API
 * endpoints during the RESTful API design process.
 *
 * This event occurs early in the API design workflow, after the Interface agent
 * has analyzed the requirements and database schema to determine what API
 * endpoints are needed for the application. The endpoint creation establishes
 * the fundamental structure of the API surface area before detailed operation
 * definitions and schema components are developed.
 *
 * The endpoints list provides the architectural foundation for the API design,
 * ensuring comprehensive coverage of the business functionality while
 * maintaining RESTful principles and consistency with the underlying data
 * model.
 *
 * @author Samchon
 */
export interface AutoBeInterfaceEndpointsEvent
  extends AutoBeEventBase<"interfaceEndpoints">,
    AutoBeProgressEventBase,
    AutoBeTokenUsageEventBase {
  /**
   * Array of API endpoints that have been defined for the application.
   *
   * Contains the complete list of {@link AutoBeOpenApi.IEndpoint} definitions
   * that establish the API surface area for the application. Each endpoint
   * represents a specific URL path and HTTP method combination that will be
   * available in the final API, covering all necessary business operations and
   * data access patterns.
   *
   * The endpoints are designed to provide comprehensive coverage of the
   * business functionality while following RESTful conventions and maintaining
   * consistency with the database schema. This foundational structure guides
   * the subsequent development of detailed operation specifications and schema
   * definitions.
   */
  endpoints: AutoBeOpenApi.IEndpoint[];
 
  /**
   * Iteration number of the requirements analysis this endpoint creation was
   * performed for.
   *
   * Indicates which version of the requirements analysis this endpoint design
   * reflects. This step number ensures that the API endpoints are aligned with
   * the current requirements and helps track the evolution of the API surface
   * area as requirements change.
   *
   * The step value enables proper synchronization between endpoint definitions
   * and the underlying requirements, ensuring that the API structure remains
   * relevant to the current project scope and business objectives.
   */
  step: number;
}
 
//----------------------------------------
// File: AutoBeInterfaceOperationsEvent.ts
//----------------------------------------
import { AutoBeOpenApi } from "../openapi/AutoBeOpenApi";
import { AutoBeEventBase } from "./AutoBeEventBase";
import { AutoBeProgressEventBase } from "./AutoBeProgressEventBase";
import { AutoBeTokenUsageEventBase } from "./AutoBeTokenUsageEventBase";
 
/**
 * Event fired when the Interface agent defines API operations during the
 * RESTful API specification process.
 *
 * This event occurs when the Interface agent is creating detailed operation
 * specifications that define the role, behavior, and characteristics of each
 * API function. Operations include comprehensive business logic definitions,
 * parameter specifications, response schemas, error handling, and security
 * requirements that transform endpoint definitions into fully functional API
 * contracts.
 *
 * The operation definition process ensures that each API endpoint has complete
 * behavioral specifications, proper documentation, and clear contracts that
 * enable accurate code generation and reliable client integration.
 *
 * @author Samchon
 */
export interface AutoBeInterfaceOperationsEvent
  extends AutoBeEventBase<"interfaceOperations">,
    AutoBeProgressEventBase,
    AutoBeTokenUsageEventBase {
  /**
   * Array of API operations being defined for the endpoints.
   *
   * Contains the detailed {@link AutoBeOpenApi.IOperation} specifications that
   * define the business logic, parameters, responses, and behavior for each API
   * function. Each operation includes comprehensive documentation,
   * request/response schemas, error handling specifications, and security
   * requirements that transform basic endpoints into complete API contracts.
   *
   * The operations ensure that every API function has clear behavioral
   * definitions, proper validation rules, and comprehensive documentation that
   * enables accurate implementation and reliable client integration throughout
   * the application ecosystem.
   */
  operations: AutoBeOpenApi.IOperation[];
 
  /**
   * Iteration number of the requirements analysis this operation definition was
   * performed for.
   *
   * Indicates which version of the requirements analysis this operation design
   * reflects. This step number ensures that the API operations are aligned with
   * the current requirements and helps track the evolution of API functionality
   * as business requirements change.
   *
   * The step value enables proper synchronization between operation definitions
   * and the underlying requirements, ensuring that the API behavior remains
   * relevant to the current project scope and business objectives.
   */
  step: number;
}
 
//----------------------------------------
// File: AutoBeInterfaceOperationsReviewEvent.ts
//----------------------------------------
import { AutoBeOpenApi } from "../openapi";
import { AutoBeEventBase } from "./AutoBeEventBase";
import { AutoBeProgressEventBase } from "./AutoBeProgressEventBase";
import { AutoBeTokenUsageEventBase } from "./AutoBeTokenUsageEventBase";
 
/**
 * Event fired during the review and validation phase of API operation
 * definitions.
 *
 * This event occurs when the Interface agent is reviewing and validating the
 * generated API operations against business requirements, technical
 * specifications, and OpenAPI standards. The review phase ensures that each
 * operation properly implements the required functionality with correct
 * request/response schemas, authentication, error handling, and documentation.
 *
 * The review process involves systematic validation where the agent evaluates
 * operation completeness, parameter correctness, response accuracy, and overall
 * API design consistency. Operations that fail validation are marked for
 * revision to ensure the final API specification meets enterprise-level quality
 * standards.
 *
 * @author Kakasoo
 */
export interface AutoBeInterfaceOperationsReviewEvent
  extends AutoBeEventBase<"interfaceOperationsReview">,
    AutoBeProgressEventBase,
    AutoBeTokenUsageEventBase {
  /**
   * Original API operations submitted for review.
   *
   * The complete set of operations generated by the Interface Operations Agent
   * that require validation for security compliance, schema alignment, logical
   * consistency, and adherence to AutoBE standards. These are the operations
   * being evaluated for potential issues and improvements.
   */
  operations: AutoBeOpenApi.IOperation[];
 
  /**
   * Detailed review feedback from the Interface Operations Review Agent.
   *
   * Contains comprehensive assessment results including:
   *
   * - Security vulnerability analysis
   * - Schema compliance validation
   * - Logical consistency verification
   * - Standard adherence evaluation
   * - Identified critical issues and recommendations
   */
  review: string;
 
  /**
   * Amendment plan based on the review feedback.
   *
   * Structured action plan outlining specific corrections needed for:
   *
   * - Security issues (password exposure, authorization bypasses)
   * - Logic errors (mismatched return types, incorrect HTTP semantics)
   * - Schema violations (missing fields, type mismatches)
   *
   * If operations are perfect, explicitly states no changes are required.
   */
  plan: string;
 
  /**
   * Revised operations based on the amendment plan.
   *
   * The final corrected API operations after applying all fixes from the
   * improvement plan. If no issues were found during review, this contains the
   * original operations unchanged. These enhanced operations are ready for
   * schema generation and subsequent implementation phases.
   */
  content: AutoBeOpenApi.IOperation[];
 
  /**
   * Current iteration number of the operation review process.
   *
   * Indicates which revision cycle of the API operation review is currently
   * being executed. This step number helps track the iterative validation
   * process and provides context for understanding how many review cycles have
   * been completed to achieve the desired operation quality.
   *
   * The step value increments with each major review iteration, allowing
   * stakeholders to monitor the progressive refinement of API operations and
   * understand the validation rigor applied to the interface design.
   */
  step: number;
}
 
//----------------------------------------
// File: AutoBeInterfaceSchemasEvent.ts
//----------------------------------------
import { AutoBeOpenApi } from "../openapi/AutoBeOpenApi";
import { AutoBeEventBase } from "./AutoBeEventBase";
import { AutoBeProgressEventBase } from "./AutoBeProgressEventBase";
import { AutoBeTokenUsageEventBase } from "./AutoBeTokenUsageEventBase";
 
/**
 * Event fired when the Interface agent defines schema definitions during the
 * API specification process.
 *
 * This event occurs when the Interface agent is creating the reusable schema
 * definitions that will be used throughout the API specification. Schema
 * definitions include data transfer objects (DTOs), request/response schemas,
 * and other type definitions that provide the structural foundation for API
 * operations and ensure type safety across the entire application.
 *
 * The schema creation process ensures that all data structures used in API
 * operations are properly defined, validated, and documented, enabling
 * consistent data handling and robust type checking throughout the generated
 * application.
 *
 * @author Samchon
 */
export interface AutoBeInterfaceSchemasEvent
  extends AutoBeEventBase<"interfaceSchemas">,
    AutoBeProgressEventBase,
    AutoBeTokenUsageEventBase {
  /**
   * Schema definitions being defined for the API specification.
   *
   * Contains the schema record that defines reusable schema definitions for the
   * OpenAPI specification. These schemas serve as the building blocks for API
   * operations, providing consistent type definitions and ensuring that data
   * structures are properly validated and documented.
   *
   * The schemas maintain perfect alignment with the database schema while
   * providing the appropriate level of abstraction for API consumers, including
   * proper validation rules, descriptive documentation, and type safety
   * throughout the application stack.
   */
  schemas: Record<string, AutoBeOpenApi.IJsonSchemaDescriptive>;
 
  /**
   * Iteration number of the requirements analysis this schema creation was
   * performed for.
   *
   * Indicates which version of the requirements analysis this schema design
   * reflects. This step number ensures that the schema definitions are aligned
   * with the current requirements and helps track the evolution of data
   * structures as requirements change.
   *
   * The step value enables proper synchronization between schema definitions
   * and the underlying requirements, ensuring that the API schemas remain
   * relevant to the current project scope and business objectives.
   */
  step: number;
}
 
//----------------------------------------
// File: AutoBeInterfaceSchemasReviewEvent.ts
//----------------------------------------
import { AutoBeOpenApi } from "../openapi";
import { AutoBeEventBase } from "./AutoBeEventBase";
import { AutoBeProgressEventBase } from "./AutoBeProgressEventBase";
import { AutoBeTokenUsageEventBase } from "./AutoBeTokenUsageEventBase";
 
/**
 * Event fired during the review and improvement phase of OpenAPI schema
 * generation process.
 *
 * This event represents the quality assurance activity of the Interface Schemas
 * Review Agent, which validates and enhances the OpenAPI schemas produced by
 * the Interface Schemas Agent. The reviewer ensures that all schemas meet
 * AutoBE's standards for type safety, completeness, and consistency before
 * being integrated into the final API specification.
 *
 * The Interface Schemas Review Agent performs comprehensive validation
 * including:
 *
 * - Schema completeness verification (all required properties defined)
 * - Type correctness and consistency across related schemas
 * - Proper use of OpenAPI schema features (allOf, oneOf, anyOf, etc.)
 * - Validation rules and constraints appropriateness
 * - Naming conventions and structural consistency
 * - Relationship integrity between interconnected schemas
 *
 * Review outcomes:
 *
 * - **Accept**: Schemas meet all criteria and can be used as-is
 * - **Improve**: Schemas are enhanced with better type definitions or constraints
 * - **Correct**: Critical issues are fixed to ensure proper API functionality
 *
 * Key characteristics of the review process:
 *
 * - Reviews all schemas holistically to ensure consistency
 * - Enhances schemas with additional validation rules when beneficial
 * - Ensures compatibility with Prisma models and business requirements
 * - Validates that schemas properly represent the API's data contracts
 *
 * The review ensures that the Interface Agent receives well-structured,
 * type-safe schemas that accurately represent the application's data models and
 * enable reliable API endpoint generation.
 *
 * @author Kakasoo
 */
export interface AutoBeInterfaceSchemasReviewEvent
  extends AutoBeEventBase<"interfaceSchemasReview">,
    AutoBeProgressEventBase,
    AutoBeTokenUsageEventBase {
  /**
   * Original schemas submitted for review.
   *
   * Contains the complete set of OpenAPI schemas generated by the Interface
   * Schemas Agent, including all data models, request/response types, and
   * shared definitions that need validation and potential enhancement.
   */
  schemas: Record<string, AutoBeOpenApi.IJsonSchemaDescriptive>;
 
  /**
   * Detailed review feedback from the Interface Schemas Review Agent.
   *
   * Contains specific validation results including:
   *
   * - Schema completeness assessment
   * - Type safety violations
   * - Naming convention issues
   * - Missing or incorrect relationships
   * - Validation rule recommendations
   * - Overall quality assessment and improvement suggestions
   */
  review: string;
 
  /**
   * Amendment plan based on the review feedback.
   *
   * Outlines specific changes to be made to improve the schemas. If the
   * original schemas are perfect and require no modifications, this field will
   * explicitly state that no changes are needed.
   *
   * The plan serves as a structured approach to enhance schemas, ensuring all
   * identified improvements are systematically applied.
   */
  plan: string;
 
  /**
   * Revised schemas based on the amendment plan.
   *
   * Contains the fully updated OpenAPI schemas incorporating all review
   * feedback and improvements. If the original schemas were perfect and
   * required no changes, this will be identical to the original schemas.
   *
   * These revised schemas must pass all validation criteria before being used
   * for API endpoint generation.
   */
  content: Record<string, AutoBeOpenApi.IJsonSchemaDescriptive>;
 
  /**
   * Current iteration number of the schema generation being reviewed.
   *
   * Indicates which version of the schemas is undergoing review and
   * improvement. This step number helps track the iterative refinement process
   * and provides context for understanding how many revision cycles have been
   * completed.
   */
  step: number;
}
 
//----------------------------------------
// File: AutoBeInterfaceComplementEvent.ts
//----------------------------------------
import { AutoBeOpenApi } from "../openapi/AutoBeOpenApi";
import { AutoBeEventBase } from "./AutoBeEventBase";
import { AutoBeTokenUsageEventBase } from "./AutoBeTokenUsageEventBase";
 
/**
 * Event fired when the Interface agent supplements missing types and schemas
 * during the API specification process.
 *
 * This event occurs when the Interface agent identifies that additional type
 * definitions or schema components are needed to complete the API
 * specification. The complement phase ensures that all necessary types used in
 * API operations are properly defined, including nested objects, utility types,
 * and supporting data structures that may have been initially overlooked.
 *
 * The complement process is essential for creating complete and self-contained
 * OpenAPI specifications that can generate fully functional NestJS applications
 * without missing dependencies or incomplete type definitions.
 *
 * @author Samchon
 */
export interface AutoBeInterfaceComplementEvent
  extends AutoBeEventBase<"interfaceComplement">,
    AutoBeTokenUsageEventBase {
  /**
   * Array of missing schema names that were identified and need to be defined.
   *
   * Contains the list of type or schema names that were referenced in API
   * operations but were not previously defined in the components section. These
   * missing definitions could include nested data transfer objects, utility
   * types, enumeration definitions, or supporting data structures that are
   * required for complete API functionality.
   *
   * Identifying and tracking these missing schemas ensures that the final
   * OpenAPI specification is complete and self-contained, preventing
   * compilation errors in the generated code.
   */
  missed: string[];
 
  /**
   * Additional schema definitions being added to complement the API
   * specification.
   *
   * Contains the newly created schema definitions that fill the gaps identified
   * in the missed array. Each key represents the schema name and each value
   * contains the complete {@link AutoBeOpenApi.IJsonSchemaDescriptive}
   * definition with proper typing, validation rules, and descriptive
   * documentation.
   *
   * These complementary schemas ensure that all types referenced throughout the
   * API specification are properly defined, enabling successful code generation
   * and maintaining type safety across the entire application.
   */
  schemas: Record<string, AutoBeOpenApi.IJsonSchemaDescriptive>;
 
  /**
   * Iteration number of the requirements analysis this API complement was
   * performed for.
   *
   * Indicates which version of the requirements analysis this schema complement
   * activity reflects. This step number ensures that the complementary types
   * are aligned with the current requirements and helps track the evolution of
   * the API specification as requirements change.
   *
   * The step value enables proper synchronization between the API design and
   * the underlying requirements, ensuring that schema additions remain relevant
   * to the current project scope and objectives.
   */
  step: number;
}
 
//----------------------------------------
// File: AutoBeInterfaceCompleteEvent.ts
//----------------------------------------
import { AutoBeInterfaceAuthorization } from "../histories";
import { AutoBeOpenApi } from "../openapi/AutoBeOpenApi";
import { AutoBeEventBase } from "./AutoBeEventBase";
 
/**
 * Event fired when the Interface agent completes the RESTful API design process
 * and generates the complete NestJS application.
 *
 * This event represents the successful completion of the sophisticated
 * multi-stage transformation pipeline that converts validated AST structures
 * into comprehensive API specifications and production-ready NestJS code. The
 * completion marks the transition from API design to implementation-ready
 * artifacts that maintain perfect alignment with business requirements and
 * database schemas.
 *
 * The Interface agent's completion ensures that API designs are syntactically
 * perfect and semantically aligned with business requirements, ready for
 * immediate deployment or further customization in the development workflow.
 *
 * @author Samchon
 */
export interface AutoBeInterfaceCompleteEvent
  extends AutoBeEventBase<"interfaceComplete"> {
  /**
   * The complete OpenAPI document containing the finalized API specification.
   *
   * Contains the validated {@link AutoBeOpenApi.IDocument} AST structure that
   * defines all API endpoints, operations, schemas, and business logic. This
   * document represents the culmination of the API design process,
   * incorporating comprehensive business logic integration, type safety bridges
   * with Prisma schemas, and security pattern validation.
   *
   * The document serves as the authoritative API specification that has been
   * converted from the internal AST format to formal OpenAPI standards, ready
   * for code generation and integration with the broader development
   * ecosystem.
   */
  document: AutoBeOpenApi.IDocument;
 
  /**
   * JWT-based authentication and authorization operations generated for each
   * user role.
   *
   * Contains role-specific authentication API operations including essential
   * flows (join, login, validate, changePassword, refresh) plus additional
   * operations based on Prisma schema capabilities like email verification and
   * password reset. These operations are generated by analyzing the database
   * schema to determine which authentication features are supported for each
   * role.
   */
  authorizations: AutoBeInterfaceAuthorization[];
 
  /**
   * Iteration number of the requirements analysis this API design was completed
   * for.
   *
   * Indicates which version of the requirements analysis this API design
   * reflects. If this value is lower than the current
   * {@link AutoBeAnalyzeCompleteEvent.step}, it means the API design may not
   * reflect the latest requirements and could need regeneration.
   *
   * The step value ensures proper synchronization between API specifications
   * and the underlying requirements, enabling stakeholders to understand the
   * currency of the API design relative to evolving project requirements.
   */
  step: number;
 
  /**
   * Elapsed time in milliseconds for the entire API design process.
   *
   * Indicates the total time taken to complete the API design process from the
   * start of requirements analysis through to the final API specification
   * generation. This metric helps in understanding the efficiency of the API
   * design phase and can be used for process improvement analysis.
   *
   * This elapsed time includes all stages of the API design process, from
   * initial requirements gathering, through business logic integration, to the
   * final generation of the OpenAPI document. It serves as a performance
   * indicator for the Interface agent's design capabilities and the overall
   * efficiency of the API design workflow.
   */
  elapsed: number;
}