@autobe/agent 0.30.4 → 0.30.5

package/src/orchestrate/prisma/structures/IAutoBeDatabaseCorrectApplication.ts

@@ -9,9 +9,6 @@ export interface IAutoBeDatabaseCorrectApplication {
   /**
    * Process schema correction task or preliminary data requests.
    *
-   * Fixes validation errors in specific database models while preserving all
-   * business logic and model descriptions. Returns ONLY corrected models.
-   *
    * @param props Request containing either preliminary data request or complete
    *   task
    */
@@ -22,35 +19,17 @@ export namespace IAutoBeDatabaseCorrectApplication {
     /**
      * Think before you act.
      *
-     * Before requesting preliminary data or completing your task, reflect on
-     * your current state and explain your reasoning:
-     *
-     * For preliminary requests (getAnalysisSections, getDatabaseSchemas, etc.):
-     *
-     * - What critical information is missing that you don't already have?
-     * - Why do you need it specifically right now?
-     * - Be brief - state the gap, don't list everything you have.
+     * For preliminary requests: what critical information is missing and why?
+     * Be brief — state the gap, don't list everything you have.
      *
-     * For completion (complete):
-     *
-     * - What key assets did you acquire?
-     * - What did you accomplish?
-     * - Why is it sufficient to complete?
-     * - Summarize - don't enumerate every single item.
-     *
-     * This reflection helps you avoid duplicate requests and premature
-     * completion.
+     * For completion: what key assets did you acquire, what did you accomplish,
+     * why is it sufficient? Summarize — don't enumerate every single item.
      */
     thinking: string;
 
     /**
-     * Type discriminator for the request.
-     *
-     * Determines which action to perform: preliminary data retrieval
-     * (getAnalysisSections, getPreviousAnalysisSections, getDatabaseSchemas,
-     * getPreviousDatabaseSchemas) or final schema correction (complete). When
-     * preliminary returns empty array, that type is removed from the union,
-     * physically preventing repeated calls.
+     * Action to perform. Exhausted preliminary types are removed from the
+     * union, physically preventing repeated calls.
      */
     request:
       | IComplete
@@ -61,96 +40,35 @@ export namespace IAutoBeDatabaseCorrectApplication {
   }
 
   /**
-   * Request to fix validation errors in database models.
-   *
-   * Executes targeted error correction to resolve specific validation issues in
-   * affected models only. Applies minimal changes while preserving original
-   * design intent and business logic.
+   * Fix validation errors in affected models only, preserving design intent and
+   * business logic.
    */
   export interface IComplete {
-    /**
-     * Type discriminator for the request.
-     *
-     * Determines which action to perform: preliminary data retrieval or actual
-     * task execution. Value "complete" indicates this is the final task
-     * execution request.
-     */
+    /** Type discriminator for completion request. */
     type: "complete";
 
     /**
-     * Detailed execution plan for fixing validation errors.
-     *
-     * Contains systematic reasoning and step-by-step error resolution approach
-     * for targeted model validation issues.
-     *
-     * Required planning content:
-     *
-     * 1. Error scope analysis:
-     *
-     *    - List all validation errors from IAutoBeDatabaseValidation.IError[]
-     *    - Extract unique table names to identify affected models
-     *    - Categorize errors by type (field duplications, references, types,
-     *         indexes)
-     *    - Identify which models need correction vs. remain unchanged
-     * 2. Targeted fix strategy:
-     *
-     *    - Focus ONLY on models mentioned in validation errors
-     *    - Outline minimal changes needed for each affected model
-     *    - Plan cross-model reference updates without modifying non-error models
-     *    - Ensure unchanged models maintain valid references to corrected models
-     * 3. Model-specific fix plan:
-     *
-     *    - Model-by-model modification plan for ONLY affected models
-     *    - Exact field additions, renames, or type corrections required
-     *    - Reference updates within corrected models only
-     *    - Index corrections limited to affected models
-     * 4. Minimal scope validation:
-     *
-     *    - Confirm which models will be included in output (error models only)
-     *    - List models that will remain unchanged in original schema
-     *    - Identify cross-model dependencies without including unchanged models
-     *    - Preserve all business logic within corrected models
-     * 5. Targeted impact assessment:
-     *
-     *    - Potential effects of fixes on unchanged models (reference validation)
-     *    - Verification points for corrected models only
-     *    - Ensure no new validation errors in targeted models
-     *    - Confirm minimal output scope compliance
+     * Execution plan for fixing validation errors. Required steps:
+     *
+     * 1. Error scope analysis — list all validation errors, extract affected table
+     *    names, categorize by type (duplications, references, types, indexes)
+     * 2. Targeted fix strategy — focus ONLY on models in errors, outline minimal
+     *    changes per model
+     * 3. Model-specific fix plan — detail corrections per affected model
+     * 4. Minimal scope validation — confirm which models are in/out of output
+     * 5. Targeted impact assessment — verify fixes don't break references from
+     *    unchanged models
+     *
+     * Preserve all business logic and cross-model references.
      */
     planning: string;
 
     /**
      * Models with validation errors that need correction.
      *
-     * Contains ONLY models mentioned in IAutoBeDatabaseValidation.IError[]
-     * array. Each model has specific validation errors requiring targeted
-     * correction. Models not mentioned in errors are excluded from this input.
-     *
-     * Expected validation issues:
-     *
-     * - Duplicate field/relation names within these specific models
-     * - Invalid foreign key references from these models to other models
-     * - Single foreign key fields in index arrays within these models
-     * - Invalid naming conventions within these specific models
-     * - Type validation errors in fields of these models
-     *
-     * Model content analysis:
-     *
-     * - Complete field definitions for each error model only
-     * - Relationships from these models (may reference unchanged models)
-     * - Indexes within these models that need correction
-     * - Business descriptions specific to these models
-     * - Cross-model references that need validation (read-only for targets)
-     *
-     * Processing notes:
-     *
-     * - Input contains ONLY models with validation errors
-     * - May reference other models not included in this input
-     * - Cross-model references must be validated but target models won't be
-     *   modified
-     * - Output should return corrected versions of ONLY these input models
-     * - All business logic and descriptions within these models must be preserved
-     * - Corrections must not break references from unchanged models
+     * Contains ONLY models from IAutoBeDatabaseValidation.IError[]. Output
+     * corrected versions of these models only. Cross-model references must stay
+     * valid but target models are not modified.
      */
     models: AutoBeDatabase.IModel[];
   }

package/src/orchestrate/prisma/structures/IAutoBeDatabaseGroupApplication.ts

@@ -6,55 +6,21 @@ import { IAutoBePreliminaryGetPreviousAnalysisSections } from "../../common/stru
 import { IAutoBePreliminaryGetPreviousDatabaseSchemas } from "../../common/structures/IAutoBePreliminaryGetPreviousDatabaseSchemas";
 
 export interface IAutoBeDatabaseGroupApplication {
-  /**
-   * Process database component group generation task or preliminary data
-   * requests.
-   *
-   * Generate logical groups for organizing database component extraction based
-   * on business domains. Processes group generation with incremental context
-   * loading to ensure comprehensive organization.
-   *
-   * @param props Request containing either preliminary data request or complete
-   *   task
-   */
+  /** Process group generation task or retrieve preliminary data. */
   process(props: IAutoBeDatabaseGroupApplication.IProps): void;
 }
 
 export namespace IAutoBeDatabaseGroupApplication {
   export interface IProps {
     /**
-     * Think before you act.
-     *
-     * Before requesting preliminary data or completing your task, reflect on
-     * your current state and explain your reasoning:
-     *
-     * For preliminary requests (getAnalysisSections,
-     * getPreviousAnalysisSections, getPreviousDatabaseSchemas):
-     *
-     * - What critical information is missing that you don't already have?
-     * - Why do you need it specifically right now?
-     * - Be brief - state the gap, don't list everything you have.
-     *
-     * For completion (complete):
-     *
-     * - What key assets did you acquire?
-     * - What did you accomplish?
-     * - Why is it sufficient to complete?
-     * - Summarize - don't enumerate every single item.
-     *
-     * This reflection helps you avoid duplicate requests and premature
-     * completion.
+     * Reasoning about your current state: what's missing (preliminary) or what
+     * you accomplished (completion).
      */
     thinking: string;
 
     /**
-     * Type discriminator for the request.
-     *
-     * Determines which action to perform: preliminary data retrieval
-     * (getAnalysisSections, getPreviousAnalysisSections,
-     * getPreviousDatabaseSchemas) or final group generation (complete). When
-     * preliminary returns empty array, that type is removed from the union,
-     * physically preventing repeated calls.
+     * Action to perform. Exhausted preliminary types are removed from the
+     * union.
      */
     request:
       | IComplete
@@ -63,54 +29,25 @@ export namespace IAutoBeDatabaseGroupApplication {
       | IAutoBePreliminaryGetPreviousDatabaseSchemas;
   }
 
-  /**
-   * Request to generate database component groups.
-   *
-   * Executes group generation to organize database components based on business
-   * domains from requirements.
-   */
+  /** Generate database component groups organized by business domains. */
   export interface IComplete {
-    /**
-     * Type discriminator for the request.
-     *
-     * Determines which action to perform: preliminary data retrieval or actual
-     * task execution. Value "complete" indicates this is the final task
-     * execution request.
-     */
+    /** Type discriminator for completion request. */
     type: "complete";
 
     /**
-     * Analysis of the requirements structure and domain organization.
-     *
-     * Documents the agent's understanding of the business requirements:
-     *
-     * - What major business domains were identified from the requirements?
-     * - How are these domains related to each other?
-     * - What organizational patterns exist in the requirements?
-     * - What foundational vs domain-specific components are needed?
+     * Analysis of the requirements structure, domain organization, and
+     * component needs.
      */
     analysis: string;
 
-    /**
-     * Rationale for the component grouping decisions.
-     *
-     * Explains why the groups were organized this way:
-     *
-     * - Why was each component group created?
-     * - Why were certain domains combined or kept separate?
-     * - How does the grouping reflect the business domain structure?
-     * - What considerations drove the component ordering?
-     */
+    /** Rationale for component grouping decisions and domain boundaries. */
     rationale: string;
 
     /**
-     * Array of database component groups for organizing development.
+     * Database component groups derived from business domains.
      *
-     * DO: Derive groups from business domains in requirements rather than
-     * arbitrary technical divisions. DO: Create foundational groups
-     * (Systematic, Actors) separately from domain-specific groups. DO: Organize
-     * groups around business workflows and entity relationships. DO: Provide
-     * complete coverage of all components without overlap.
+     * Separate foundational groups (Systematic, Actors) from domain-specific
+     * groups. Ensure complete coverage without overlap.
      */
     groups: AutoBeDatabaseGroup[] & tags.MinItems<1>;
   }

package/src/orchestrate/prisma/structures/IAutoBeDatabaseGroupReviewApplication.ts

@@ -5,49 +5,21 @@ import { IAutoBePreliminaryGetPreviousAnalysisSections } from "../../common/stru
 import { IAutoBePreliminaryGetPreviousDatabaseSchemas } from "../../common/structures/IAutoBePreliminaryGetPreviousDatabaseSchemas";
 
 export interface IAutoBeDatabaseGroupReviewApplication {
-  /**
-   * Analyze requirements and review the component group skeletons.
-   *
-   * Your PRIMARY task is to verify that the group structure provides complete,
-   * well-organized coverage of all business domains described in the
-   * requirements. Review existing groups and identify necessary modifications
-   * using create, update, or erase operations.
-   *
-   * ALWAYS fetch analysis sections first using `getAnalysisSections` to
-   * understand what business domains exist, then systematically verify group
-   * coverage and apply corrections.
-   *
-   * @param props Request containing either preliminary data request or complete
-   *   task with group revisions
-   */
+  /** Process group review task or retrieve preliminary data. */
   process(props: IAutoBeDatabaseGroupReviewApplication.IProps): void;
 }
 
 export namespace IAutoBeDatabaseGroupReviewApplication {
   export interface IProps {
     /**
-     * Reflect on requirements analysis before acting.
-     *
-     * For preliminary requests (getAnalysisSections,
-     * getPreviousAnalysisSections, getPreviousDatabaseSchemas):
-     *
-     * - What business domains do you need to analyze?
-     * - What requirements will help verify group coverage?
-     *
-     * For completion (complete):
-     *
-     * - What domains did you analyze?
-     * - How many revisions are you making and why?
-     * - Summarize the domain-to-group mapping.
+     * Reasoning about your current state: what's missing (preliminary) or what
+     * you accomplished (completion).
      */
     thinking: string;
 
     /**
-     * Request type discriminator.
-     *
-     * Use preliminary requests (getAnalysisSections, etc.) to fetch
-     * requirements documents. Use complete to submit group revisions after
-     * thorough domain coverage analysis.
+     * Action to perform. Exhausted preliminary types are removed from the
+     * union.
      */
     request:
       | IComplete
@@ -62,92 +34,22 @@ export namespace IAutoBeDatabaseGroupReviewApplication {
     type: "complete";
 
     /**
-     * Domain coverage analysis.
-     *
-     * Document how you analyzed business requirements and mapped them to group
-     * modifications:
-     *
-     * - What business domains are defined in requirements?
-     * - Does each domain have a corresponding group?
-     * - Are group boundaries appropriate?
-     * - Are kind assignments correct?
-     *
-     * Be specific - reference actual requirements and explain the
-     * domain-to-revisions mapping.
+     * How business requirements map to proposed group modifications,
+     * identifying coverage gaps.
      */
     review: string;
 
     /**
-     * Array of group revision operations.
-     *
-     * Include all create, update, and erase operations identified during
-     * review. Each operation must include a reason explaining why the change is
-     * necessary.
-     *
-     * ## Operation Types:
+     * Group revision operations (create/update/erase). Each must include a
+     * reason.
      *
-     * ### Create - Add missing groups
+     * Constraints:
      *
-     * Use when a business domain has no corresponding group.
-     *
-     * ```typescript
-     * {
-     *   "type": "create",
-     *   "reason": "Notification functionality exists in requirements but has no group",
-     *   "group": {
-     *     "thinking": "...",
-     *     "review": "...",
-     *     "rationale": "...",
-     *     "namespace": "Notifications",
-     *     "filename": "schema-10-notifications.prisma",
-     *     "kind": "domain"
-     *   }
-     * }
-     * ```
-     *
-     * ### Update - Modify existing groups
-     *
-     * Use when a group has property issues.
-     *
-     * ```typescript
-     * {
-     *   "type": "update",
-     *   "reason": "Namespace uses incorrect casing",
-     *   "originalNamespace": "products_catalog",
-     *   "group": {
-     *     "thinking": "...",
-     *     "review": "...",
-     *     "rationale": "...",
-     *     "namespace": "Products",
-     *     "filename": "schema-03-products.prisma",
-     *     "kind": "domain"
-     *   }
-     * }
-     * ```
-     *
-     * ### Erase - Remove groups
-     *
-     * Use when a group is unnecessary.
-     *
-     * ```typescript
-     * {
-     *   "type": "erase",
-     *   "reason": "Group is redundant with existing Products group",
-     *   "namespace": "Catalog"
-     * }
-     * ```
-     *
-     * ## Constraints:
-     *
-     * - After revisions: exactly 1 authorization group, ≥1 domain groups
-     * - Each operation must have a clear, requirement-based reason
+     * - After revisions: exactly 1 authorization group, at least 1 domain group
      * - Empty array is valid if no modifications are needed
      *
-     * ## Naming Conventions:
-     *
-     * - Namespace: PascalCase (e.g., "Products", "Orders")
-     * - Filename: `schema-{number}-{domain}.prisma` format
-     * - Kind: "authorization" or "domain"
+     * Naming: namespace PascalCase, filename `schema-{number}-{domain}.prisma`,
+     * kind "authorization" or "domain".
      */
     revises: AutoBeDatabaseGroupRevise[];
   }

package/src/orchestrate/prisma/structures/IAutoBeDatabaseSchemaApplication.ts

@@ -6,10 +6,7 @@ import { IAutoBePreliminaryGetPreviousDatabaseSchemas } from "../../common/struc
 
 export interface IAutoBeDatabaseSchemaApplication {
   /**
-   * Process schema generation task or preliminary data requests.
-   *
-   * Generates database models for the target component following normalization
-   * principles and database design best practices.
+   * Process schema generation task or retrieve preliminary data.
    *
    * @param props Request containing either preliminary data request or complete
    *   task
@@ -21,35 +18,17 @@ export namespace IAutoBeDatabaseSchemaApplication {
     /**
      * Think before you act.
      *
-     * Before requesting preliminary data or completing your task, reflect on
-     * your current state and explain your reasoning:
-     *
-     * For preliminary requests (getAnalysisSections, getDatabaseSchemas, etc.):
-     *
-     * - What critical information is missing that you don't already have?
-     * - Why do you need it specifically right now?
-     * - Be brief - state the gap, don't list everything you have.
-     *
-     * For completion (complete):
-     *
-     * - What key assets did you acquire?
-     * - What did you accomplish?
-     * - Why is it sufficient to complete?
-     * - Summarize - don't enumerate every single item.
+     * For preliminary requests: what critical information is missing and why?
+     * Be brief — state the gap, don't list everything you have.
      *
-     * This reflection helps you avoid duplicate requests and premature
-     * completion.
+     * For completion: what key assets did you acquire, what did you accomplish,
+     * why is it sufficient? Summarize — don't enumerate every single item.
      */
     thinking: string;
 
     /**
-     * Type discriminator for the request.
-     *
-     * Determines which action to perform: preliminary data retrieval
-     * (getAnalysisSections, getPreviousAnalysisSections,
-     * getPreviousDatabaseSchemas) or final schema generation (complete). When
-     * preliminary returns empty array, that type is removed from the union,
-     * physically preventing repeated calls.
+     * Action to perform. Exhausted preliminary types are removed from the
+     * union, physically preventing repeated calls.
      */
     request:
       | IComplete
@@ -59,85 +38,35 @@ export namespace IAutoBeDatabaseSchemaApplication {
   }
 
   /**
-   * Request to generate database schema models.
-   *
-   * Executes schema generation to create production-ready database models
-   * following normalization principles, relationship patterns, and indexing
-   * strategies.
+   * Generate production-ready database schema models with normalization and
+   * indexing.
    */
   export interface IComplete {
-    /**
-     * Type discriminator for the request.
-     *
-     * Determines which action to perform: preliminary data retrieval or actual
-     * task execution. Value "complete" indicates this is the final task
-     * execution request.
-     */
+    /** Type discriminator for completion request. */
     type: "complete";
 
     /**
-     * Strategic database design analysis and planning.
-     *
-     * Contains the database architecture strategy for the target table and any
-     * child tables needed for First Normal Form (1NF) compliance, including
-     * structure, relationships, normalization approach, indexing strategies,
-     * and business requirement mapping. This planning phase defines the
-     * blueprint for the model implementations.
-     *
-     * Key planning aspects:
+     * Database design plan for the target table and any child tables (1NF
+     * decomposition).
      *
-     * - Assignment validation: Extract targetTable as the assignment
-     * - Target table: The primary table matching targetTable is mandatory
-     * - Child tables: Additional tables to decompose repeating groups or
-     *   non-atomic values into separate normalized tables (1NF compliance)
-     * - Child table naming: Must use singular form of targetTable as prefix
-     *   (e.g., for "shopping_orders": "shopping_order_items")
-     * - Other tables: Identify existing tables from otherComponents for foreign
-     *   key relationships — never recreate them
-     * - Normalization: Strict adherence to 1NF, 2NF, 3NF principles
-     * - Snapshot architecture: Design for historical data preservation
-     * - Junction tables: Plan M:N relationships with proper naming
-     *   ({table1}_{table2})
-     * - Materialized views: Identify needs for mv_ prefixed denormalized tables
+     * Child table naming: singular form of targetTable as prefix (e.g.,
+     * "shopping_order_items"). Never recreate existing tables from
+     * otherComponents. Strict 1NF/2NF/3NF adherence. Junction tables:
+     * {table1}_{table2}. Materialized views: mv_ prefix.
      */
     plan: string;
 
     /**
-     * Schema definition containing the single target table model and any newly
-     * discovered table designs.
-     *
-     * The definition carries exactly one
-     * {@link AutoBeDatabaseSchemaDefinition.model} — the target table assigned
-     * to this call — so that the output stays within the LLM's maximum output
-     * token limit. If normalization (e.g. 1NF decomposition) requires
-     * additional child tables, declare them in
-     * {@link AutoBeDatabaseSchemaDefinition.newDesigns} as lightweight name +
-     * description pairs; they will be generated by their own dedicated pipeline
-     * calls.
-     *
-     * Model implementation requirements:
-     *
-     * - Primary keys: Always UUID type with field name "id"
-     * - Foreign keys: Proper IRelation configurations for all relationships
-     * - Business fields: Only raw data fields - no calculated or derived values
-     * - Data types: Limited to uuid, string, int, double, datetime, boolean, uri
-     * - Relationships: Correct patterns for 1:1, 1:N, and M:N
-     * - Indexes:
-     *
-     *   - UniqueIndexes: Business constraints and composite unique keys
-     *   - PlainIndexes: Multi-column query optimization (never single FK)
-     *   - GinIndexes: Full-text search on appropriate string fields
-     * - Materialized views: Tables prefixed with "mv_" have material flag set
-     * - Documentation: Comprehensive English descriptions with business context
-     *
-     * Quality standards:
-     *
-     * - Strict adherence to 3NF (Third Normal Form)
-     * - No denormalization except in materialized views (mv_ tables)
-     * - All foreign keys reference valid existing tables
-     * - Consistent created_at, updated_at, deleted_at patterns
-     * - Proper historical data preservation where needed
-     * - Optimized index strategy for expected query patterns
+     * Schema definition with exactly one
+     * {@link AutoBeDatabaseSchemaDefinition.model} (the target table).
+     * Additional child tables go in
+     * {@link AutoBeDatabaseSchemaDefinition.newDesigns} as name + description
+     * pairs.
+     *
+     * Key rules: UUID "id" primary keys, data types limited to
+     * uuid/string/int/double/ datetime/boolean/uri, no derived values, strict
+     * 3NF, mv_ prefix for materialized views, consistent
+     * created_at/updated_at/deleted_at, PlainIndexes never single FK.
      */
     definition: AutoBeDatabaseSchemaDefinition;
   }