@autobe/agent 0.30.4 → 0.30.5

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

@@ -5,25 +5,17 @@ import { IAutoBePreliminaryGetAnalysisSections } from "../../common/structures/I
 import { IAutoBePreliminaryGetPreviousAnalysisSections } from "../../common/structures/IAutoBePreliminaryGetPreviousAnalysisSections";
 import { IAutoBePreliminaryGetPreviousDatabaseSchemas } from "../../common/structures/IAutoBePreliminaryGetPreviousDatabaseSchemas";
 
+/**
+ * Designs ALL actor-related authentication tables. The Database Component agent
+ * will NOT create any actor or authentication tables — this agent owns that
+ * scope entirely.
+ */
 export interface IAutoBeDatabaseAuthorizationApplication {
   /**
-   * Process authorization table design task for all actors or preliminary data
-   * requests.
-   *
-   * Receives all actor definitions (name, kind, description for each) and
-   * generates all authentication and authorization related tables for every
-   * actor type (guest/member/admin) in a single call. This includes for each
-   * actor:
-   *
-   * - The main actor table (e.g., users, administrators, guests)
-   * - Session tables for JWT token management
-   * - Authentication support tables (password reset, email verification, etc.)
-   *
-   * This agent is responsible for ALL actor-related tables. The Database
-   * Component agent will NOT create any actor or authentication tables.
+   * Process authorization table design task or preliminary data requests.
    *
    * @param props Request containing either preliminary data request or complete
-   *   table design for all actors
+   *   task
    */
   process(props: IAutoBeDatabaseAuthorizationApplication.IProps): void;
 }
@@ -33,35 +25,17 @@ export namespace IAutoBeDatabaseAuthorizationApplication {
     /**
      * 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 for designing auth tables?
-     * - Why do you need it specifically right now?
-     * - Be brief - state the gap, don't list everything you have.
-     *
-     * For completion (complete):
-     *
-     * - What tables did you design for this actor?
-     * - How does the design support authentication workflows?
-     * - 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 table design (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
@@ -71,76 +45,25 @@ export namespace IAutoBeDatabaseAuthorizationApplication {
   }
 
   /**
-   * Request to complete the authorization table design for all actors.
-   *
-   * Takes all actor definitions (name, kind, description for each) and
-   * generates all database tables required for every actor's authentication and
-   * authorization needs, including main actor tables, session tables, and any
-   * authentication support tables for each actor.
-   *
-   * This is about creating tables for ALL actors in a single call. Each actor
-   * must have at minimum a main actor table and a session table.
+   * Complete authorization table design for all actors. Each actor must have a
+   * main actor table and a session table.
    */
   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 all actors' authentication requirements.
-     *
-     * Documents the agent's understanding of each actor's authentication needs:
-     *
-     * - What actors exist and their kinds (guest/member/admin)?
-     * - What authentication patterns apply to each actor kind?
-     * - What authentication features are required (login, registration, etc.)?
-     * - What are the session management requirements for each actor?
-     * - Are there any special authentication mechanisms (2FA, OAuth, etc.)?
-     */
+    /** Analysis of all actors' authentication requirements and patterns. */
     analysis: string;
 
-    /**
-     * Rationale for the authorization table design decisions.
-     *
-     * Explains why tables were designed this way:
-     *
-     * - Why was each table created for each actor?
-     * - What is the relationship between actor and session tables?
-     * - How do tables support the authentication workflow for all actors?
-     * - What normalization decisions were made for auth-related data?
-     */
+    /** Rationale for the authorization table design decisions. */
     rationale: string;
 
     /**
-     * Array of table designs for ALL ACTORS' authentication domains.
-     *
-     * Contains all database tables required for every actor's authentication
-     * and authorization needs. Each table design includes table name
-     * (snake_case, plural) and description explaining the table's purpose.
-     *
-     * The AI agent must design tables based on:
-     *
-     * - Each actor's kind (guest/member/admin) and its authentication patterns
-     * - Authentication requirements from analysis sections
-     * - Session management requirements (JWT, refresh tokens)
-     * - Security requirements (password policies, 2FA)
-     *
-     * MUST include for EACH actor:
-     *
-     * - Main actor table (e.g., `users`, `administrators`, `guests`)
-     * - Session table (e.g., `user_sessions`, `administrator_sessions`)
-     *
-     * MAY include (based on requirements):
+     * Table designs for all actors' authentication domains (snake_case, plural
+     * names).
      *
-     * - Password reset tokens table
-     * - Email verification tokens table
-     * - OAuth connections table
-     * - Two-factor authentication tokens table
+     * MUST include for each actor: main actor table + session table. MAY
+     * include: password reset, email verification, OAuth, 2FA tables.
      */
     tables: AutoBeDatabaseComponentTableDesign[] & tags.MinItems<1>;
   }

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

@@ -5,52 +5,21 @@ import { IAutoBePreliminaryGetPreviousAnalysisSections } from "../../common/stru
 import { IAutoBePreliminaryGetPreviousDatabaseSchemas } from "../../common/structures/IAutoBePreliminaryGetPreviousDatabaseSchemas";
 
 export interface IAutoBeDatabaseAuthorizationReviewApplication {
-  /**
-   * Analyze requirements and review the single authorization component
-   * containing tables for ALL actors.
-   *
-   * Your PRIMARY task is to deeply analyze authentication requirements and
-   * ensure complete table coverage for EVERY actor type in the authorization
-   * component. The component contains tables for all actors
-   * (guest/member/admin), and you must verify that each actor has its required
-   * tables.
-   *
-   * ALWAYS fetch analysis sections first using `getAnalysisSections` to
-   * understand what authentication features are required, then systematically
-   * verify that EVERY actor has main actor table + session table, and apply
-   * corrections.
-   *
-   * @param props Request containing either preliminary data request or complete
-   *   task with table revisions for all actors
-   */
+  /** Process authorization review task or retrieve preliminary data. */
   process(props: IAutoBeDatabaseAuthorizationReviewApplication.IProps): void;
 }
 
 export namespace IAutoBeDatabaseAuthorizationReviewApplication {
   export interface IProps {
     /**
-     * Reflect on requirements analysis before acting.
-     *
-     * For preliminary requests (getAnalysisSections,
-     * getPreviousAnalysisSections, getPreviousDatabaseSchemas):
-     *
-     * - What authentication requirements do you need to analyze?
-     * - Which actor types need to be verified?
-     *
-     * For completion (complete):
-     *
-     * - What authentication requirements did you analyze?
-     * - How many revisions are you making and why?
-     * - Summarize the requirements-to-revisions 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 table revisions after
-     * thorough authentication requirements analysis.
+     * Action to perform. Exhausted preliminary types are removed from the
+     * union.
      */
     request:
       | IComplete
@@ -59,94 +28,28 @@ export namespace IAutoBeDatabaseAuthorizationReviewApplication {
       | IAutoBePreliminaryGetPreviousDatabaseSchemas;
   }
 
-  /**
-   * Submit table revisions after authentication requirements analysis.
-   *
-   * The authorization component contains tables for ALL actors, so ensure no
-   * actor is missing its required tables.
-   */
+  /** Submit table revisions after authentication requirements analysis. */
   export interface IComplete {
     /** Type discriminator. Value "complete" indicates final submission. */
     type: "complete";
 
     /**
-     * Authentication requirements coverage analysis.
-     *
-     * Document how you analyzed authentication requirements and mapped them to
-     * table modifications:
-     *
-     * - What actor types are defined?
-     * - Does each actor have a main table and session table?
-     * - What authentication support tables are needed?
-     * - What existing tables need renaming or removal?
-     *
-     * Be specific - reference actual requirements and explain the
-     * requirements-to-revisions mapping.
+     * How authentication requirements map to proposed table modifications,
+     * identifying coverage gaps.
      */
     review: string;
 
     /**
-     * Array of table 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:
+     * Table revision operations (create/update/erase). Each must include a
+     * reason.
      *
-     * ### Create - Add missing tables
-     *
-     * Use when a table is needed to fulfill authentication requirements but
-     * doesn't exist.
-     *
-     * ```typescript
-     * {
-     *   "type": "create",
-     *   "reason": "Actor 'customer' requires password reset token storage",
-     *   "table": "shopping_customer_password_resets",
-     *   "description": "Stores password reset tokens with expiration for customers"
-     * }
-     * ```
-     *
-     * ### Update - Rename tables
-     *
-     * Use when a table has naming convention issues.
-     *
-     * ```typescript
-     * {
-     *   "type": "update",
-     *   "reason": "Table name violates actor naming convention",
-     *   "original": "customerSessions",
-     *   "updated": "shopping_customer_sessions",
-     *   "description": "Authentication sessions for shopping customers"
-     * }
-     * ```
-     *
-     * ### Erase - Remove tables
-     *
-     * Use when a table doesn't belong to authorization.
-     *
-     * ```typescript
-     * {
-     *   "type": "erase",
-     *   "reason": "Table is a business domain entity, not authentication",
-     *   "table": "shopping_orders"
-     * }
-     * ```
-     *
-     * ## Constraints:
+     * Constraints:
      *
      * - Only CREATE tables related to authentication and authorization
      * - Each actor MUST have a main actor table and session table
-     * - Each operation must have a clear, requirement-based reason
      * - Empty array is valid if no modifications are needed
      *
-     * ## Naming Conventions:
-     *
-     * - Snake case: `user_sessions` not `userSessions`
-     * - Plural form: `users` not `user`
-     * - Domain prefix: `shopping_customer_sessions`
-     * - Actor name in table: all tables must contain the actor name
+     * Naming: snake_case, plural, domain-prefixed, actor name in table.
      */
     revises: AutoBeDatabaseComponentTableRevise[];
   }

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

@@ -5,59 +5,21 @@ import { IAutoBePreliminaryGetPreviousAnalysisSections } from "../../common/stru
 import { IAutoBePreliminaryGetPreviousDatabaseSchemas } from "../../common/structures/IAutoBePreliminaryGetPreviousDatabaseSchemas";
 
 export interface IAutoBeDatabaseComponentApplication {
-  /**
-   * Process table design task for a single component skeleton or preliminary
-   * data requests.
-   *
-   * Receives a component skeleton (namespace, filename, thinking, review,
-   * rationale already determined by DATABASE_GROUP phase) and fills in the
-   * tables field with complete table designs for that single component.
-   *
-   * This is NOT about creating or organizing multiple components. The component
-   * identity is fixed. This agent ONLY designs the tables that belong to the
-   * provided component skeleton.
-   *
-   * @param props Request containing either preliminary data request or complete
-   *   table design
-   */
+  /** Process table design task or retrieve preliminary data. */
   process(props: IAutoBeDatabaseComponentApplication.IProps): void;
 }
 
 export namespace IAutoBeDatabaseComponentApplication {
   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):
-     *
-     * - 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 table design (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
@@ -67,75 +29,27 @@ export namespace IAutoBeDatabaseComponentApplication {
   }
 
   /**
-   * Request to complete the database component by filling in table designs.
-   *
-   * Takes a component skeleton (namespace, filename already determined by
-   * DATABASE_GROUP phase) and fills in the tables field by designing all
-   * necessary database tables for this single component.
-   *
-   * This is NOT about creating multiple components - the component identity is
-   * already fixed. This is ONLY about designing the tables that belong to this
-   * single component.
+   * Complete the database component by filling in table designs for the given
+   * skeleton.
    */
   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 component's scope and table requirements.
-     *
-     * Documents the agent's understanding of this component's domain:
-     *
-     * - What is the component's business purpose (from the skeleton)?
-     * - What entities from the requirements belong to this component?
-     * - What relationships exist between these entities?
-     * - What normalization patterns were identified?
+     * Analysis of the component's scope, entities, relationships, and table
+     * requirements.
      */
     analysis: string;
 
-    /**
-     * Rationale for the table design decisions.
-     *
-     * Explains why tables were designed this way:
-     *
-     * - Why was each table created?
-     * - Why were certain entities kept separate vs combined?
-     * - What normalization principles were applied?
-     * - How do the tables fulfill the component's rationale?
-     */
+    /** Rationale for table design decisions and normalization choices. */
     rationale: string;
 
     /**
-     * Array of table designs for THIS SINGLE component.
-     *
-     * Contains all database tables that belong to the component skeleton
-     * received as input. Each table design includes table name (snake_case,
-     * plural) and description explaining the table's purpose and contents.
-     *
-     * The AI agent must design tables based on:
-     *
-     * - The component's namespace and intended domain (from skeleton)
-     * - Business requirements from analysis sections
-     * - Previous database schemas for consistency
-     * - Normalization principles (3NF)
-     * - Relationship integrity
-     *
-     * CRITICAL CONSTRAINTS:
+     * Table designs for this single component (snake_case, plural names).
      *
-     * - The namespace and filename are ALREADY DETERMINED by the component
-     *   skeleton
-     * - Do NOT create multiple components or reorganize component boundaries
-     * - Do NOT include thinking, review, decision, or rationale - those are
-     *   already in the skeleton
-     * - ALL tables generated here belong to THE SINGLE component skeleton
-     *   provided
-     * - ONLY provide the tables array - nothing else
+     * Namespace and filename are already determined by the skeleton. All tables
+     * must belong to this component only.
      */
     tables: AutoBeDatabaseComponentTableDesign[];
   }

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

@@ -5,49 +5,21 @@ import { IAutoBePreliminaryGetPreviousAnalysisSections } from "../../common/stru
 import { IAutoBePreliminaryGetPreviousDatabaseSchemas } from "../../common/structures/IAutoBePreliminaryGetPreviousDatabaseSchemas";
 
 export interface IAutoBeDatabaseComponentReviewApplication {
-  /**
-   * Analyze requirements and review the component's table list.
-   *
-   * Your PRIMARY task is to deeply analyze user requirements and ensure
-   * complete table coverage for all features in this component's domain. Review
-   * existing tables and identify necessary modifications using create, update,
-   * or erase operations.
-   *
-   * ALWAYS fetch analysis sections first using `getAnalysisSections` to
-   * understand what features this component's domain needs to support, then
-   * systematically verify table coverage and apply corrections.
-   *
-   * @param props Request containing either preliminary data request or complete
-   *   task with table revisions
-   */
+  /** Process component review task or retrieve preliminary data. */
   process(props: IAutoBeDatabaseComponentReviewApplication.IProps): void;
 }
 
 export namespace IAutoBeDatabaseComponentReviewApplication {
   export interface IProps {
     /**
-     * Reflect on requirements analysis before acting.
-     *
-     * For preliminary requests (getAnalysisSections,
-     * getPreviousAnalysisSections, getPreviousDatabaseSchemas):
-     *
-     * - What requirements documents do you need to analyze this component?
-     * - Which features in this domain need to be understood?
-     *
-     * For completion (complete):
-     *
-     * - What requirements did you analyze?
-     * - How many revisions are you making and why?
-     * - Summarize the requirements-to-revisions 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 table revisions after
-     * thorough requirements analysis.
+     * Action to perform. Exhausted preliminary types are removed from the
+     * union.
      */
     request:
       | IComplete
@@ -62,89 +34,24 @@ export namespace IAutoBeDatabaseComponentReviewApplication {
     type: "complete";
 
     /**
-     * Requirements coverage analysis.
-     *
-     * Document how you analyzed requirements and mapped them to table
-     * modifications:
-     *
-     * - What features does this domain support?
-     * - What data storage needs does each feature have?
-     * - What tables are missing to fulfill these requirements?
-     * - What existing tables need renaming or removal?
-     *
-     * Be specific - reference actual requirements and explain the
-     * requirements-to-revisions mapping.
+     * How requirements map to proposed table modifications, identifying
+     * coverage gaps.
      */
     review: string;
 
     /**
-     * Array of table 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:
-     *
-     * ### Create - Add missing tables
+     * Table revision operations (create/update/erase). Each must include a
+     * reason.
      *
-     * Use when a table is needed to fulfill requirements but doesn't exist.
+     * Constraints:
      *
-     * ```typescript
-     * {
-     *   "type": "create",
-     *   "reason": "Requirement 3.2 specifies order cancellation tracking",
-     *   "table": "order_cancellations",
-     *   "description": "Stores cancellation records with reasons and timestamps"
-     * }
-     * ```
-     *
-     * ### Update - Rename tables
-     *
-     * Use when a table has naming convention issues.
-     *
-     * ```typescript
-     * {
-     *   "type": "update",
-     *   "reason": "Table name violates snake_case convention",
-     *   "original": "orderCancel",
-     *   "updated": "order_cancellations",
-     *   "description": "Stores cancellation records with reasons and timestamps"
-     * }
-     * ```
-     *
-     * ### Erase - Remove tables
-     *
-     * Use when a table belongs to another domain or is unnecessary.
-     *
-     * ```typescript
-     * {
-     *   "type": "erase",
-     *   "reason": "Table belongs to Actors component, not Orders",
-     *   "table": "shopping_customers"
-     * }
-     * ```
-     *
-     * ## Constraints:
-     *
-     * - Only CREATE tables that CLEARLY belong to THIS component's domain
-     * - If uncertain about domain ownership → DO NOT CREATE
-     * - Each operation must have a clear, requirement-based reason
+     * - Only CREATE tables that clearly belong to THIS component's domain
+     * - CREATE/UPDATE names are validated against other components (duplicates
+     *   fail)
+     * - Revises only affect the target component
      * - Empty array is valid if no modifications are needed
      *
-     * ## Validation Rules:
-     *
-     * - CREATE/UPDATE table names are checked against "Tables in Other
-     *   Components"
-     * - If the table name already exists in another component → validation FAILS
-     * - Always check "Tables in Other Components" before CREATE/UPDATE operations
-     * - Your revises only affect Target Component, never other components' tables
-     *
-     * ## Naming Conventions:
-     *
-     * - Snake case: `user_profiles` not `userProfiles`
-     * - Plural form: `users` not `user`
-     * - Domain prefix: `shopping_customers`
+     * Naming: snake_case, plural, domain-prefixed.
      */
     revises: AutoBeDatabaseComponentTableRevise[];
   }