@autobe/agent 0.23.1 → 0.24.1

package/src/orchestrate/realize/structures/IAutoBeRealizeWriteApplication.ts

@@ -8,294 +8,48 @@ export interface IAutoBeRealizeWriteApplication {
    * error-free code generation.
    *
    * The generation process includes:
+   *
    * 1. Strategic planning based on Prisma schema analysis
-   * 2. Initial draft without Date type usage
+   * 2. Schema definition for relevant models
    * 3. Review and refinement for completeness
-   * 4. Compiler feedback integration if errors detected
-   * 5. Final implementation with all validations and type safety
+   * 4. Final implementation with all validations and type safety
    *
-   * @param next Properties containing the multi-phase implementation plan and code
+   * @param next Properties containing the multi-phase implementation plan and
+   *   code
    */
   coding: (next: IAutoBeRealizeWriteApplication.IProps) => void;
 }
 
 export namespace IAutoBeRealizeWriteApplication {
   /**
-   * Properties for the Realize Write Application following Chain of Thinking (CoT).
-   * 
-   * Each field represents a distinct phase in the reasoning and implementation process,
-   * building upon the previous step to create a complete, error-free implementation.
-   * This structured approach ensures clarity, debuggability, and systematic thinking.
+   * Properties for the Realize Write Application following Chain of Thinking
+   * (CoT).
+   *
+   * Each field represents a distinct phase in the implementation process.
+   * Detailed guidelines are in REALIZE_WRITE.md.
    */
   export interface IProps {
     /**
      * Step 1 - Planning Phase (CoT: Initial Reasoning)
      *
-     * 🧠 Provider Function Implementation Plan
-     *
-     * This field outlines the strategic plan for implementing the provider
-     * function according to the Realize Coder Agent specification. Before
-     * writing the actual code, think through the logic and structure.
-     *
-     * The plan follows a SCHEMA-FIRST APPROACH:
-     *
-     * 📋 STEP 1 - PRISMA SCHEMA VERIFICATION:
-     *
-     * DO:
-     *
-     * - Examine the actual Prisma schema model definition
-     * - List EVERY field that exists in the model with exact types
-     * - Explicitly note fields that DO NOT exist
-     * - Verify database compatibility (PostgreSQL AND SQLite)
-     *
-     * DO NOT:
-     *
-     * - Assume common fields exist without verification
-     * - Use fields like deleted_at, created_by, updated_by, is_deleted, is_active
-     *   without checking
-     * - Use PostgreSQL-specific features like mode: "insensitive"
-     *
-     * 📋 STEP 2 - FIELD INVENTORY:
-     *
-     * - List ONLY fields confirmed to exist in schema
-     * - Example: "Verified fields in user model: id (String), email (String),
-     *   created_at (DateTime), updated_at (DateTime)"
-     * - Example: "Fields that DO NOT exist: deleted_at, is_active, created_by"
-     *
-     * 📋 STEP 3 - FIELD ACCESS STRATEGY:
-     *
-     * - Plan which verified fields will be used in select, update, create
-     *   operations
-     * - For complex operations with type errors, plan to use separate queries
-     *   instead of nested operations
-     *
-     * 📋 STEP 4 - TYPE COMPATIBILITY:
-     *
-     * - Plan DateTime to ISO string conversions using toISOStringSafe()
-     * - Plan handling of nullable vs required fields
-     *
-     * 📋 STEP 5 - IMPLEMENTATION APPROACH:
-     *
-     * - 🧩 Required business entities (e.g., users, posts, logs) and their
-     *   relationships
-     * - 🛠 Operations needed to fulfill the business scenario (e.g., fetch,
-     *   create, update) using ONLY verified fields
-     * - 🔄 Data dependencies between steps (e.g., use userId to fetch related
-     *   data)
-     * - ✅ Validation points (based on business rules, not field presence)
-     * - 🚧 Error and edge cases that must be handled explicitly (e.g., missing
-     *   records)
-     * - 🏗 Structure: always a single `async function`, using only `parameters`
-     *   and `body`
+     * Strategic plan following SCHEMA-FIRST APPROACH:
      *
-     * ⚠️ Important Constraints:
+     * 1. Verify Prisma schema fields (list existing and non-existing)
+     * 2. Plan field usage in operations
+     * 3. Plan type conversions and nullable handling
+     * 4. Define implementation approach with error handling
      *
-     * - Do NOT perform input validation — assume `parameters` and `body` are
-     *   already valid
-     * - Use `typia.random<T>()` with an explanatory comment if logic can't be
-     *   implemented
-     * - Never use `any` or make assumptions without sufficient context
-     * - Use only allowed imports — DTOs and Prisma types
-     * - Use `MyGlobal.prisma` for DB access and respect Prisma typing rules
-     *
-     * ⚠️ TypeScript-specific considerations:
-     *
-     * - Do **not** use native `Date` objects directly; always convert all dates
-     *   using `toISOStringSafe()` and brand as `string &
-     *   tags.Format<'date-time'>`. This rule applies throughout all phases.
-     * - Prefer `satisfies` for DTO conformance instead of unsafe `as` casts
-     * - Avoid weak typing such as `any`, `as any`, or `satisfies any`
-     * - Use branded types (e.g., `tags.Format<'uuid'>`) and literal unions where
-     *   applicable
-     *
-     * ✅ Example Structure:
-     *
-     * ```ts
-     * export async function doSomething(
-     *   user: { id: string & tags.Format<"uuid">; type: string },
-     *   parameters: IParams,
-     *   body: IBody
-     * ): Promise<IReturn> {
-     *   const { id } = parameters;
-     *   const { name } = body;
-     *   const user = await MyGlobal.prisma.users.findFirst({ where: { id } });
-     *   if (!user) throw new Error("User not found");
-     *   ...
-     *   return result;
-     * }
-     * ```
-     *
-     * 🔍 Feasibility Analysis Requirement:
-     *
-     * - Before generating any code, the agent **must analyze** whether the
-     *   requested implementation is **feasible based on the given Prisma schema
-     *   and DTO types**.
-     * - If required fields or relationships are **missing or incompatible**, the
-     *   plan should explicitly state that the implementation is **not
-     *   possible** with the current schema/DTO, and no code should be generated
-     *   in later stages.
-     * - In such cases, only a detailed **comment in the `implementationCode`**
-     *   should be returned explaining why the logic cannot be implemented.
-     *
-     * 🔥 Error Handling Plan:
-     *
-     * If an error is expected or encountered during implementation:
-     *
-     * - Clearly document the error message(s) and TypeScript error codes.
-     * - Analyze the root cause (e.g., type mismatch, missing field, nullability
-     *   issue).
-     * - Define concrete steps to resolve the issue, such as:
-     *
-     *   - Adjusting type declarations or using Prisma-generated input types.
-     *   - Using `?? undefined` to normalize nullable fields.
-     *   - Applying correct relation handling (e.g., `connect` instead of direct
-     *       foreign key assignment).
-     *   - Ensuring all date fields use `.toISOString()` and proper branding.
-     * - Include fallback or workaround plans if a direct fix is complex.
-     * - If no error is present, simply omit this section.
-     *
-     * This plan ensures the function will:
-     *
-     * - Respect the global architecture and coding conventions
-     * - Be safe, predictable, and aligned with upstream logic
+     * See REALIZE_WRITE.md for detailed requirements.
      */
     plan: string;
 
-    /**
-     * Step 2 - Schema Definition (CoT: Context Establishment)
-     *
-     * The Prisma schema string that will be used to validate the implementation
-     * logic in this file.
-     *
-     * You must **explicitly specify only the relevant models and fields** from
-     * your full schema that are used in this implementation. This ensures that
-     * your logic is aligned with the expected database structure without
-     * accidentally introducing unrelated fields or models.
-     *
-     * ⚠️ Important: The value of this field must be a valid Prisma schema
-     * string containing only the models used in this code — not the entire
-     * schema.
-     *
-     * This acts as a safeguard against:
-     *
-     * - Forgetting required fields used in this implementation
-     * - Including fields or models that are not actually used
-     */
-    prisma_schemas: string;
+    /** Step 2 - Relevant Prisma schema models and fields */
+    prismaSchemas: string;
 
-    /**
-     * Step 3 - Initial Draft (CoT: First Implementation Attempt)
-     *
-     * Draft WITHOUT using native Date type.
-     *
-     * This is the initial drafting phase where you outline the basic skeleton
-     * of the function.
-     *
-     * DO NOT: Use the native Date type.
-     *
-     * - The function signature must correctly include `user`, `parameters`, and
-     *   `body` arguments.
-     * - Design the main flow of business logic, such as DB fetches and early
-     *   returns based on conditions.
-     * - Mark any incomplete or missing parts clearly with placeholders (e.g.,
-     *   comments or temporary values).
-     *
-     * Import rules:
-     *
-     * DO NOT:
-     *
-     * - Add any new import statements manually
-     * - Write import statements directly (this causes compile errors)
-     *
-     * Note: All necessary imports are provided globally or by the system
-     * automatically.
-     *
-     * ✅ Requirements:
-     *
-     * - Avoid using the `any` type at all costs to ensure type safety.
-     * - NEVER declare variables with `: Date` type
-     * - ALWAYS use `string & tags.Format<'date-time'>` for date values
-     * - Use `toISOStringSafe(new Date())` for current timestamps
-     * - Maintain a single-function structure; avoid using classes.
-     */
-    draft_without_date_type: string;
-
-    /**
-     * Step 4 - Review and Refinement (CoT: Self-Reflection)
-     *
-     * A refined version of the draft with improved completeness.
-     *
-     * - Replace placeholder logic with real DTO-conformant operations.
-     * - Add error handling (`throw new Error(...)`) where necessary.
-     * - Begin resolving structural or type mismatches.
-     *
-     * ✅ Requirements:
-     *
-     * - Use `satisfies` to ensure DTO conformity.
-     * - Avoid unsafe `as` casts unless only for branding or literal narrowing.
-     * - Use `toISOStringSafe()` for all date conversions (NOT `.toISOString()`).
-     * - Ensure all object keys strictly conform to the expected type definitions.
-     * - NEVER use `mode: "insensitive"` in string operations (breaks SQLite).
-     */
+    /** Step 3 - Refined version with real operations */
     review: string;
 
-
-    /**
-     * Step 5 - Complete Implementation (CoT: Final Synthesis)
-     *
-     * The complete and fully correct TypeScript function implementation.
-     *
-     * - Passes strict type checking without errors.
-     * - Uses only safe branding or literal type assertions.
-     * - Converts all date values properly using `toISOStringSafe()`.
-     * - Follows DTO structures using `satisfies`.
-     * - Avoids any weak typing such as `any`, `as any`, or `satisfies any`.
-     * - Uses only allowed imports (e.g., from `../api/structures` and
-     *   `MyGlobal.prisma`).
-     * - NEVER creates intermediate variables for Prisma operations.
-     * - NEVER uses `mode: "insensitive"` (PostgreSQL-only, breaks SQLite).
-     *
-     * ⚠️ Fallback Behavior:
-     *
-     * - If the `plan` phase explicitly determines that the requested logic is
-     *   **not feasible** due to mismatches or limitations in the provided
-     *   Prisma schema and DTO types:
-     *
-     *   - The implementation must still return a syntactically valid function.
-     *   - In such cases, return mock data using `typia.random<T>()` wrapped in the
-     *       correct structure, along with a comment explaining the limitation.
-     *
-     *   Example fallback:
-     *
-     * ```ts
-     *   // ⚠️ Cannot implement logic due to missing relation between A and B
-     *   export async function someFunction(...) {
-     *     return typia.random<IReturn>(); // mocked output
-     *   }
-     * ```
-     *
-     * ⚠️ Prohibited Practices:
-     *
-     * - Do NOT add or modify import statements manually. Imports are handled
-     *   automatically by the system.
-     * - Do NOT use `any`, `as any`, or `satisfies any` to bypass type checking.
-     * - Do NOT assign native `Date` objects directly; always convert them using
-     *   `toISOStringSafe()`.
-     * - Do NOT use unsafe type assertions except for safe branding or literal
-     *   narrowing.
-     * - Do NOT write code outside the single async function structure (e.g., no
-     *   classes or multiple functions).
-     * - Do NOT perform any input validation — assume all inputs are already
-     *   validated.
-     * - Do NOT use dynamic import expressions (`import()`); all imports must be
-     *   static.
-     * - Do NOT use Prisma-generated input types; always use types from
-     *   `../api/structures`.
-     * - Do NOT use `Object.prototype.hasOwnProperty.call()` for field checks.
-     * - Do NOT escape newlines or quotes in the implementation string (e.g., no
-     *   `\\n` or `\"`); use a properly formatted template literal with actual
-     *   line breaks instead.
-     */
-    implementationCode: string;
+    /** Step 4 - Final implementation See REALIZE_WRITE.md for requirements */
+    final: string;
   }
 }

package/src/orchestrate/realize/utils/filterDiagnostics.ts

@@ -0,0 +1,21 @@
+import { IAutoBeRealizeFunctionFailure } from "../structures/IAutoBeRealizeFunctionFailure";
+
+/**
+ * Filter diagnostic failures to only include those matching the given
+ * locations.
+ *
+ * @param failures - Array of function failures with diagnostic information
+ * @param locations - Array of file locations to filter by
+ * @returns Filtered array of failures matching the specified locations
+ * @warning This function assumes f.function and f.function.location are always defined.
+ *          If f.function is undefined, this will throw a runtime error.
+ *          Consider using optional chaining: f.function?.location
+ */
+export function filterDiagnostics(
+  failures: IAutoBeRealizeFunctionFailure[],
+  locations: string[],
+): IAutoBeRealizeFunctionFailure[] {
+  return failures
+    .filter((f) => f.function.location.startsWith("src/providers"))
+    .filter((f) => locations.includes(f.function.location));
+}

package/src/structures/IAutoBeConfig.ts

@@ -64,7 +64,40 @@ export interface IAutoBeConfig {
    */
   timezone?: string;
 
-  timeout?: number;
+  /**
+   * Maximum execution time limit for agent conversations in milliseconds.
+   *
+   * Controls the maximum duration allowed for each agent's conversation and
+   * code generation process. When set to a numeric value, the agent will
+   * automatically abort the conversation if it exceeds the specified time
+   * limit, preventing infinite loops or excessively long running operations
+   * that could consume excessive resources.
+   *
+   * Setting this value to `null` disables the timeout, allowing the agent to
+   * run indefinitely until the conversation naturally completes or encounters
+   * an error. This unlimited mode should be used with caution, particularly in
+   * production environments where resource management is critical.
+   *
+   * The timeout applies to each individual agent conversation phase (analyze,
+   * prisma, interface, test, realize) separately, not to the entire AutoBE
+   * pipeline execution. This ensures that a single slow phase doesn't prevent
+   * completion of other phases while still protecting against runaway
+   * processes.
+   *
+   * @example
+   *   // 10 minute timeout
+   *   {
+   *     timeout: 10 * 60 * 1_000;
+   *   }
+   *
+   *   // No timeout (unlimited)
+   *   {
+   *     timeout: null;
+   *   }
+   *
+   * @default null
+   */
+  timeout?: number | null;
 
   /**
    * Backoff strategy for retrying failed operations.

package/src/utils/{TimeoutConversation.ts → TimedConversation.ts}

@@ -4,11 +4,11 @@ import { ConditionVariable, IPointer, Singleton, sleep_for } from "tstl";
 
 import { AutoBeTimeoutError } from "./AutoBeTimeoutError";
 
-export namespace TimeoutConversation {
+export namespace TimedConversation {
   export interface IProps<Model extends ILlmSchema.Model> {
     agent: MicroAgentica<Model>;
-    timeout: number;
     message: string;
+    timeout: number | null;
   }
   export type IResult<Model extends ILlmSchema.Model> =
     | ISuccessResult<Model>
@@ -30,6 +30,21 @@ export namespace TimeoutConversation {
   export const process = async <Model extends ILlmSchema.Model>(
     props: IProps<Model>,
   ): Promise<IResult<Model>> => {
+    if (props.timeout === null)
+      try {
+        const histories: MicroAgenticaHistory<Model>[] =
+          await props.agent.conversate(props.message);
+        return {
+          type: "success",
+          histories,
+        };
+      } catch (error) {
+        return {
+          type: "error",
+          error: error as Error,
+        };
+      }
+
     // PREPARE TIMEOUT HANDLERS
     const result: IPointer<IResult<Model> | null> = {
       value: null,
@@ -45,7 +60,7 @@ export namespace TimeoutConversation {
         };
         abort.abort(`Timeout, over ${props.timeout} ms`);
         void holder.notify_all().catch(() => {});
-      }, props.timeout),
+      }, props.timeout!),
     );
 
     // DO CONVERSATE

package/lib/utils/TimeoutConversation.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"TimeoutConversation.js","sourceRoot":"","sources":["../../src/utils/TimeoutConversation.ts"],"names":[],"mappings":";;;;;;;;;;;;AAEA,+BAAyE;AAEzE,6DAA0D;AAE1D,IAAiB,mBAAmB,CA2EnC;AA3ED,WAAiB,mBAAmB;IAuBrB,2BAAO,GAAG,CACrB,KAAoB,EACK,EAAE;QAC3B,2BAA2B;QAC3B,MAAM,MAAM,GAAoC;YAC9C,KAAK,EAAE,IAAI;SACZ,CAAC;QACF,MAAM,MAAM,GAAsB,IAAI,wBAAiB,EAAE,CAAC;QAC1D,MAAM,KAAK,GAAoB,IAAI,eAAe,EAAE,CAAC;QACrD,MAAM,OAAO,GAA8B,IAAI,gBAAS,CAAC,GAAG,EAAE,CAC5D,UAAU,CAAC,GAAG,EAAE;YACd,IAAI,MAAM,CAAC,KAAK,KAAK,IAAI;gBAAE,OAAO;YAClC,MAAM,CAAC,KAAK,GAAG;gBACb,IAAI,EAAE,SAAS;gBACf,KAAK,EAAE,IAAI,uCAAkB,CAAC,iBAAiB,KAAK,CAAC,OAAO,MAAM,CAAC;aACpE,CAAC;YACF,KAAK,CAAC,KAAK,CAAC,iBAAiB,KAAK,CAAC,OAAO,KAAK,CAAC,CAAC;YACjD,KAAK,MAAM,CAAC,UAAU,EAAE,CAAC,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;QAC3C,CAAC,EAAE,KAAK,CAAC,OAAO,CAAC,CAClB,CAAC;QAEF,gBAAgB;QAChB,KAAK,CAAC,KAAK,CAAC,EAAE,CAAC,SAAS,EAAE,GAAG,EAAE;YAC7B,OAAO,CAAC,GAAG,EAAE,CAAC;QAChB,CAAC,CAAC,CAAC;QACH,KAAK,CAAC,KAAK;aACR,UAAU,CAAC,KAAK,CAAC,OAAO,EAAE;YACzB,WAAW,EAAE,KAAK,CAAC,MAAM;SAC1B,CAAC;aACD,IAAI,CACH,CAAC,CAAC,EAAE,EAAE;;YACJ,OAAA,OAAC,MAAM,CAAC,KAAK,oCAAZ,MAAM,CAAC,KAAK,GAAK;gBAChB,IAAI,EAAE,SAAS;gBACf,SAAS,EAAE,CAAC;aACb,EAAC,CAAA;SAAA,CACL;aACA,KAAK,CACJ,CAAC,CAAC,EAAE,EAAE;;YACJ,OAAA,OAAC,MAAM,CAAC,KAAK,oCAAZ,MAAM,CAAC,KAAK,GAAK;gBAChB,IAAI,EAAE,OAAO;gBACb,KAAK,EAAE,CAAU;aAClB,EAAC,CAAA;SAAA,CACL;aACA,OAAO,CAAC,GAAG,EAAE;YACZ,KAAK,MAAM,CAAC,UAAU,EAAE,CAAC,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;YACzC,YAAY,CAAC,OAAO,CAAC,GAAG,EAAE,CAAC,CAAC;QAC9B,CAAC,CAAC,CAAC;QAEL,MAAM,MAAM,CAAC,IAAI,EAAE,CAAC;QACpB,MAAM,IAAA,gBAAS,EAAC,CAAC,CAAC,CAAC;QACnB,OAAO,MAAM,CAAC,KAAM,CAAC;IACvB,CAAC,CAAA,CAAC;AACJ,CAAC,EA3EgB,mBAAmB,mCAAnB,mBAAmB,QA2EnC"}