@autobe/agent 0.30.4 → 0.30.5

package/lib/orchestrate/prisma/structures/IAutoBeDatabaseCorrectApplication.d.ts

@@ -7,9 +7,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
      */
@@ -20,126 +17,47 @@ export declare 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 | IAutoBePreliminaryGetAnalysisSections | IAutoBePreliminaryGetDatabaseSchemas | IAutoBePreliminaryGetPreviousAnalysisSections | IAutoBePreliminaryGetPreviousDatabaseSchemas;
     }
     /**
-     * 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.
      */
     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/lib/orchestrate/prisma/structures/IAutoBeDatabaseGroupApplication.d.ts

@@ -4,101 +4,38 @@ import { IAutoBePreliminaryGetAnalysisSections } from "../../common/structures/I
 import { IAutoBePreliminaryGetPreviousAnalysisSections } from "../../common/structures/IAutoBePreliminaryGetPreviousAnalysisSections";
 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 declare namespace IAutoBeDatabaseGroupApplication {
     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 | IAutoBePreliminaryGetAnalysisSections | IAutoBePreliminaryGetPreviousAnalysisSections | 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. */
     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/lib/orchestrate/prisma/structures/IAutoBeDatabaseGroupReviewApplication.d.ts

@@ -3,47 +3,19 @@ import { IAutoBePreliminaryGetAnalysisSections } from "../../common/structures/I
 import { IAutoBePreliminaryGetPreviousAnalysisSections } from "../../common/structures/IAutoBePreliminaryGetPreviousAnalysisSections";
 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 declare namespace IAutoBeDatabaseGroupReviewApplication {
     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 | IAutoBePreliminaryGetAnalysisSections | IAutoBePreliminaryGetPreviousAnalysisSections | IAutoBePreliminaryGetPreviousDatabaseSchemas;
     }
@@ -52,91 +24,21 @@ export declare namespace IAutoBeDatabaseGroupReviewApplication {
         /** Type discriminator. Value "complete" indicates final submission. */
         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/lib/orchestrate/prisma/structures/IAutoBeDatabaseSchemaApplication.d.ts

@@ -4,10 +4,7 @@ import { IAutoBePreliminaryGetPreviousAnalysisSections } from "../../common/stru
 import { IAutoBePreliminaryGetPreviousDatabaseSchemas } from "../../common/structures/IAutoBePreliminaryGetPreviousDatabaseSchemas";
 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
@@ -19,115 +16,47 @@ export declare 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 | IAutoBePreliminaryGetAnalysisSections | IAutoBePreliminaryGetPreviousAnalysisSections | IAutoBePreliminaryGetPreviousDatabaseSchemas;
     }
     /**
-     * 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.
      */
     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;
     }