@autobe/agent 0.17.1 → 0.19.1

package/src/orchestrate/interface/structures/IAutoBeInterfaceGroupApplication.ts

@@ -5,10 +5,10 @@ export interface IAutoBeInterfaceGroupApplication {
    * Generate logical groups for organizing API endpoint creation based on
    * Prisma schema structure.
    *
-   * Groups MUST be derived from Prisma schema organization (namespaces, file
-   * structure, table prefixes) rather than arbitrary business domains. Only
-   * create new groups when existing schema structure cannot adequately cover
-   * all requirements.
+   * DO: Derive groups from Prisma schema organization (namespaces, file
+   * structure, table prefixes) rather than arbitrary business domains.
+   * DO: Create new groups only when existing schema structure cannot adequately
+   * cover all requirements.
    *
    * @param props Properties containing the groups to be created for API
    *   organization
@@ -21,8 +21,8 @@ export namespace IAutoBeInterfaceGroupApplication {
     /**
      * Array of API endpoint groups for organizing development.
      *
-     * Groups MUST be organized around existing Prisma schema structure and
-     * provide complete coverage of all entities and requirements without
+     * DO: Organize groups around existing Prisma schema structure.
+     * DO: Provide complete coverage of all entities and requirements without
      * overlap.
      */
     groups: IGroup[] & tags.MinItems<1>;
@@ -34,10 +34,11 @@ export namespace IAutoBeInterfaceGroupApplication {
    *
    * **SCHEMA-BASED GROUP REQUIREMENTS:**
    *
-   * Groups MUST be derived from the Prisma schema structure rather than
-   * arbitrary business domain names. This ensures consistency with the
-   * underlying data model and prevents misalignment between API organization
-   * and database structure.
+   * DO: Derive groups from the Prisma schema structure rather than arbitrary
+   * business domain names.
+   * 
+   * This ensures consistency with the underlying data model and prevents
+   * misalignment between API organization and database structure.
    *
    * **Primary Group Sources (in order of priority):**
    *
@@ -51,12 +52,11 @@ export namespace IAutoBeInterfaceGroupApplication {
    *
    * **Group Creation Guidelines:**
    *
-   * - Each group must cover specific Prisma schema entities without overlap
+   * - Each group covers specific Prisma schema entities without overlap
    * - Size groups appropriately for manageable endpoint generation cycles
    * - Maintain clear boundaries based on schema organization
    * - Ensure complete coverage of all database entities and requirements
-   * - Related database tables within the same schema area should be grouped
-   *   together
+   * - Related database tables within the same schema area are grouped together
    *
    * **When to Create Schema-Independent Groups:**
    *
@@ -71,14 +71,14 @@ export namespace IAutoBeInterfaceGroupApplication {
    * **Naming Standards:**
    *
    * - Use PascalCase format (e.g., "Shopping", "BBS", "UserManagement")
-   * - Names MUST directly reflect Prisma schema structure
+   * - Names directly reflect Prisma schema structure
    * - Keep names concise and schema-derived
    * - Avoid arbitrary business domain names
    * - Maintain consistency with schema organization
    *
    * **Quality Requirements:**
    *
-   * - Groups collectively must cover ALL entities and requirements
+   * - Groups collectively cover ALL entities and requirements
    * - Each database entity belongs to exactly one group
    * - Clear mapping to specific Prisma schema elements
    * - Balance group sizes within schema constraints
@@ -88,7 +88,7 @@ export namespace IAutoBeInterfaceGroupApplication {
     /**
      * Unique identifier name derived from Prisma schema structure.
      *
-     * Must correspond to schema namespaces, file names, table prefixes, or
+     * DO: Correspond to schema namespaces, file names, table prefixes, or
      * organizational annotations rather than arbitrary business domain names.
      */
     name: string & tags.MinLength<1>;

package/src/orchestrate/interface/structures/IAutoBeInterfaceOperationApplication.ts

@@ -1,4 +1,4 @@
-import { AutoBeOpenApi } from "@autobe/interface";
+import { AutoBeOpenApi, CamelPattern } from "@autobe/interface";
 import { tags } from "typia";
 
 export interface IAutoBeInterfaceOperationApplication {
@@ -23,7 +23,7 @@ export namespace IAutoBeInterfaceOperationApplication {
     /**
      * Array of API operations to generate.
      *
-     * Each operation in this array must include:
+     * Each operation in this array includes:
      *
      * - Specification: Detailed API specification with clear purpose and
      *   functionality
@@ -38,7 +38,7 @@ export namespace IAutoBeInterfaceOperationApplication {
      *   components.schemas
      * - ResponseBody: With typeName referencing appropriate response type
      *
-     * All operations must follow strict quality standards:
+     * All operations follow strict quality standards:
      *
      * 1. Detailed descriptions referencing Prisma schema comments
      * 2. Accurate parameter definitions matching path parameters
@@ -66,11 +66,10 @@ export namespace IAutoBeInterfaceOperationApplication {
    * reason and description fields, making it clear why the API was designed and
    * how it should be used.
    *
-   * All request bodies and responses for this operation must be object types
-   * and must reference named types defined in the components section. The
-   * content-type is always `application/json`. For file upload/download
-   * operations, use `string & tags.Format<"uri">` in the appropriate schema
-   * instead of binary data formats.
+   * DO: Use object types for all request bodies and responses. DO: Reference
+   * named types defined in the components section. DO: Use `application/json`
+   * as the content-type. DO: Use `string & tags.Format<"uri">` in the schema
+   * for file upload/download operations instead of binary data formats.
    *
    * In OpenAPI, this might represent:
    *
@@ -88,7 +87,10 @@ export namespace IAutoBeInterfaceOperationApplication {
    * ```
    */
   export interface IOperation
-    extends Omit<AutoBeOpenApi.IOperation, "authorizationRole"> {
+    extends Omit<
+      AutoBeOpenApi.IOperation,
+      "authorizationRole" | "authorizationType"
+    > {
     /**
      * Authorization roles required to access this API operation.
      *
@@ -96,12 +98,47 @@ export namespace IAutoBeInterfaceOperationApplication {
      * endpoint. Multiple roles can be specified to allow different types of
      * users to access the same endpoint.
      *
+     * ## ⚠️ CRITICAL: Role Multiplication Effect
+     *
+     * **EACH ROLE IN THIS ARRAY GENERATES A SEPARATE ENDPOINT**
+     *
+     * - If you specify `["admin", "moderator", "member"]`, this creates 3
+     *   separate endpoints
+     * - Total generated endpoints = operations × average roles.length
+     * - Example: 100 operations with 3 roles each = 300 actual endpoints
+     *
+     * ## 🔴 AVOID OVER-GENERATION
+     *
+     * **DO NOT create role-specific endpoints when a public endpoint would
+     * suffice:**
+     *
+     * - ❌ BAD: Separate GET endpoints for admin, member, moderator to view the
+     *   same public data
+     * - ✅ GOOD: Single public endpoint `[]` with role-based filtering in business
+     *   logic
+     *
+     * **DO NOT enumerate all possible roles when the Prisma schema uses a
+     * single User table:**
+     *
+     * - If Prisma has a User table with role/permission fields, you likely only
+     *   need `["user"]`
+     * - Avoid listing `["admin", "seller", "buyer", "moderator", ...]`
+     *   unnecessarily
+     * - The actual role checking happens in business logic, not at the endpoint
+     *   level
+     *
+     * ## Naming Convention
+     *
+     * DO: Use camelCase for all role names.
+     *
      * ## Important Guidelines
      *
      * - Set to empty array `[]` for public endpoints that require no
      *   authentication
      * - Set to array with role strings for role-restricted endpoints
-     * - The role names MUST match exactly with the user type/role defined in the
+     * - **MINIMIZE the number of roles per endpoint to prevent explosion**
+     * - Consider if the endpoint can be public with role-based filtering instead
+     * - The role names match exactly with the user type/role defined in the
      *   database
      * - This will be used by the Realize Agent to generate appropriate decorator
      *   and authorization logic in the provider functions
@@ -110,16 +147,31 @@ export namespace IAutoBeInterfaceOperationApplication {
      *
      * ## Examples
      *
-     * - `[]` - Public endpoint, no authentication required
-     * - `["user"]` - Any authenticated user can access
-     * - `["admin"]` - Only admin users can access
+     * - `[]` - Public endpoint, no authentication required (PREFERRED for read
+     *   operations)
+     * - `["user"]` - Any authenticated user can access (PREFERRED for
+     *   user-specific operations)
+     * - `["admin"]` - Only admin users can access (USE SPARINGLY)
      * - `["admin", "moderator"]` - Both admin and moderator users can access
-     * - `["seller"]` - Only seller users can access
+     *   (AVOID if possible)
+     * - `["seller"]` - Only seller users can access (ONLY if Seller is a separate
+     *   table)
+     *
+     * ## Best Practices
+     *
+     * 1. **Start with public `[]` for all read operations** unless sensitive data
+     *    is involved
+     * 2. **Use single role `["user"]` for authenticated operations** and handle
+     *    permissions in business logic
+     * 3. **Only use multiple roles when absolutely necessary** for different
+     *    business logic paths
+     * 4. **Remember: Fewer roles = Fewer endpoints = Better performance and
+     *    maintainability**
      *
      * Note: The actual authentication/authorization implementation will be
      * handled by decorators at the controller level, and the provider function
      * will receive the authenticated user object with the appropriate type.
      */
-    authorizationRoles: Array<string & tags.MinLength<1>>;
+    authorizationRoles: Array<string & CamelPattern & tags.MinLength<1>>;
   }
 }

package/src/orchestrate/interface/structures/IAutoBeInterfaceOperationsReviewApplication.ts

@@ -0,0 +1,139 @@
+import { AutoBeOpenApi } from "@autobe/interface";
+
+/**
+ * Application interface for reviewing and validating API operations.
+ *
+ * Provides functionality to systematically review generated API operations
+ * against business requirements, technical specifications, and OpenAPI
+ * standards. The review process ensures each operation meets quality criteria
+ * before proceeding to implementation.
+ */
+export interface IAutoBeInterfaceOperationsReviewApplication {
+  /**
+   * Reviews a batch of API operations for quality and correctness.
+   *
+   * Validates each operation's request/response schemas, authentication
+   * handling, error responses, and documentation completeness. Operations are
+   * marked as passed or failed based on compliance with enterprise standards.
+   *
+   * @param input Collection of operations to review with their validation
+   *   results
+   */
+  reviewOperations(
+    input: IAutoBeInterfaceOperationsReviewApplication.IProps,
+  ): void;
+}
+
+export namespace IAutoBeInterfaceOperationsReviewApplication {
+  /**
+   * Properties for API operation review and improvement process.
+   *
+   * Contains both the input operations to be reviewed and the outputs generated
+   * by the Interface Operations Review Agent, which will be published as part
+   * of the AutoBeInterfaceOperationsReviewEvent.
+   */
+  export interface IProps {
+    /**
+     * Comprehensive review analysis with prioritized findings.
+     *
+     * Systematic assessment organized by severity levels (CRITICAL, HIGH,
+     * MEDIUM, LOW):
+     *
+     * - **Security Analysis**: Authentication boundary violations, exposed
+     *   passwords/tokens, unauthorized data access patterns, SQL injection
+     *   risks
+     * - **Logic Validation**: Return type consistency (list operations returning
+     *   arrays, single retrieval returning single items), HTTP method semantics
+     *   alignment, parameter usage verification
+     * - **Schema Compliance**: Field existence in Prisma schema, type accuracy,
+     *   relationship validity, required field handling
+     * - **Quality Assessment**: Documentation completeness, naming conventions,
+     *   error handling patterns, pagination standards
+     *
+     * Each finding includes specific examples, current vs expected behavior,
+     * and concrete fix recommendations. Critical security issues and logical
+     * contradictions are highlighted for immediate attention.
+     */
+    review: string;
+
+    /**
+     * Prioritized action plan for identified issues.
+     *
+     * Structured improvement strategy categorized by severity:
+     *
+     * - **Immediate Actions (CRITICAL)**: Security vulnerabilities that must be
+     *   fixed before production (password exposure, missing authorization,
+     *   authentication bypass risks)
+     * - **Required Fixes (HIGH)**: Functional issues affecting API correctness
+     *   (wrong return types, missing required fields, schema mismatches)
+     * - **Recommended Improvements (MEDIUM)**: Quality enhancements for better
+     *   API design (validation rules, format specifications, consistency)
+     * - **Optional Enhancements (LOW)**: Documentation and usability improvements
+     *
+     * If all operations pass review without issues, contains: "No improvements
+     * required. All operations meet AutoBE standards."
+     *
+     * Each action item includes the specific operation path, the exact change
+     * needed, and the rationale for the modification.
+     */
+    plan: string;
+
+    /**
+     * Production-ready operations with all critical issues resolved.
+     *
+     * Final API operations after systematic enhancement:
+     *
+     * - **Security Fixes Applied**: All authentication boundaries enforced,
+     *   sensitive data removed from responses, proper authorization
+     *   implemented
+     * - **Logic Corrections Made**: Return types match operation intent, HTTP
+     *   methods align with semantics, parameters properly utilized
+     * - **Schema Alignment Verified**: All fields exist in Prisma schema, types
+     *   correctly mapped, relationships properly defined
+     * - **Quality Improvements Added**: Enhanced documentation, format
+     *   specifications, validation rules, consistent naming patterns
+     *
+     * If no issues were found during review, this contains the exact original
+     * operations unchanged. These operations are validated and ready for schema
+     * generation and subsequent implementation phases.
+     */
+    content: IOperation[];
+  }
+
+  /**
+   * Operation of the Restful API.
+   *
+   * This interface defines a single API endpoint with its HTTP {@link method},
+   * {@link path}, {@link parameters path parameters},
+   * {@link requestBody request body}, and {@link responseBody} structure. It
+   * corresponds to an individual operation in the paths section of an OpenAPI
+   * document.
+   *
+   * Each operation requires a detailed explanation of its purpose through the
+   * reason and description fields, making it clear why the API was designed and
+   * how it should be used.
+   *
+   * All request bodies and responses for this operation must be object types
+   * and must reference named types defined in the components section. The
+   * content-type is always `application/json`. For file upload/download
+   * operations, use `string & tags.Format<"uri">` in the appropriate schema
+   * instead of binary data formats.
+   *
+   * In OpenAPI, this might represent:
+   *
+   * ```json
+   * {
+   *   "/shoppings/customers/orders": {
+   *     "post": {
+   *       "description": "Create a new order application from shopping cart...",
+   *       "parameters": [...],
+   *       "requestBody": {...},
+   *       "responses": {...}
+   *     }
+   *   }
+   * }
+   * ```
+   */
+  export interface IOperation
+    extends Omit<AutoBeOpenApi.IOperation, "authorizationType"> {}
+}

package/src/orchestrate/interface/structures/IAutoBeInterfaceSchemaApplication.ts

@@ -14,10 +14,9 @@ export interface IAutoBeInterfaceSchemaApplication {
    * creation. This ensures that the final OpenAPI document has complete type
    * coverage for all operations.
    *
-   * CRITICAL: All schema definitions must follow the established naming
-   * conventions (IEntityName, IEntityName.ICreate, etc.) and must be thoroughly
-   * documented with descriptions that reference the original Prisma schema
-   * comments.
+   * DO: Follow established naming conventions (IEntityName,
+   * IEntityName.ICreate, etc.) DO: Document thoroughly with descriptions that
+   * reference the original Prisma schema comments.
    *
    * @param props Properties containing components to generate.
    */
@@ -25,6 +24,40 @@ export interface IAutoBeInterfaceSchemaApplication {
 }
 export namespace IAutoBeInterfaceSchemaApplication {
   export interface IProps {
+    /**
+     * TypeScript draft code for schema definitions.
+     *
+     * This property contains TypeScript interface definitions that serve as a
+     * preliminary draft before generating the final JSON schema components.
+     * The draft allows for initial design and validation of the schema structure
+     * using TypeScript's type system before converting to OpenAPI/JSON Schema format.
+     *
+     * The draft typically includes:
+     * - Entity interfaces matching the Prisma models
+     * - Operation-specific variants (ICreate, IUpdate, etc.)
+     * - Utility types and enumerations
+     * - Type relationships and constraints
+     *
+     * This TypeScript draft serves as the foundation for the subsequent schema
+     * generation, ensuring type safety and consistency. The final schemas in the
+     * `schemas` property should be derived from and validated against this draft.
+     *
+     * Example draft structure:
+     * ```typescript
+     * interface IUser {
+     *   id: string;
+     *   email: string;
+     *   profile: IUserProfile;
+     * }
+     * 
+     * namespace IUser {
+     *   interface ICreate extends Omit<IUser, "id"> {}
+     *   interface IUpdate extends Partial<ICreate> {}
+     * }
+     * ```
+     */
+    draft: string;
+
     /**
      * Complete set of schema components for the OpenAPI specification.
      *
@@ -32,23 +65,23 @@ export namespace IAutoBeInterfaceSchemaApplication {
      * the system. It is the central repository of all named schema types that
      * will be used throughout the API specification.
      *
-     * CRITICAL REQUIREMENT: All object types MUST be defined as named types in
-     * the components.schemas section. Inline anonymous object definitions are
-     * strictly prohibited.
+     * DO: Define all object types as named types in the components.schemas
+     * section. DO NOT: Use inline anonymous object definitions.
      *
-     * This components object should include:
+     * This components object includes:
      *
      * - Main entity types (IEntityName)
      * - Operation-specific variants (.ICreate, .IUpdate, .ISummary, etc.)
      * - Container types (IPage<T> for pagination)
      * - Enumeration types
      *
-     * All schema definitions must include detailed descriptions that reference
-     * the original Prisma schema comments and thoroughly document each
-     * property. Every property that references an object must use a $ref to a
-     * named type in the components.schemas section. This applies to all objects
-     * in request bodies, response bodies, and properties that are objects or
-     * arrays of objects.
+     * DO: Include detailed descriptions that reference the original Prisma
+     * schema comments and thoroughly document each property. DO: Use a $ref to
+     * a named type in the components.schemas section for every property that
+     * references an object.
+     *
+     * This applies to all objects in request bodies, response bodies, and
+     * properties that are objects or arrays of objects.
      *
      * Example structure:
      *

package/src/orchestrate/interface/structures/IAutobeInterfaceSchemasReviewApplication.ts

@@ -0,0 +1,92 @@
+import { AutoBeOpenApi } from "@autobe/interface";
+
+export interface IAutoBeInterfaceSchemasReviewApplication {
+  /**
+   * Analyzes and improves OpenAPI schema definitions.
+   *
+   * This function receives schema definitions and performs comprehensive review
+   * and enhancement. It identifies issues, creates an improvement plan, and
+   * produces refined schemas that meet quality standards.
+   *
+   * The function populates three key outputs:
+   *
+   * - A detailed review of findings organized by severity
+   * - An actionable plan for improvements
+   * - Enhanced schemas with all issues resolved
+   *
+   * @param props Contains review findings, improvement plan, and enhanced
+   *   schemas
+   */
+  review: (props: IAutoBeInterfaceSchemasReviewApplication.IProps) => void;
+}
+
+export namespace IAutoBeInterfaceSchemasReviewApplication {
+  /**
+   * Schema review and enhancement parameters for the review function.
+   *
+   * When the review function is called, these properties must be populated to
+   * complete the schema validation and improvement process. The LLM uses this
+   * interface to understand what outputs are required.
+   */
+  export interface IProps {
+    /**
+     * Issues and problems found during schema analysis.
+     *
+     * DO: Document only problems that need fixing.
+     * DO NOT: Include positive feedback, compliments, or confirmations
+     *
+     * Focus exclusively on issues organized by severity:
+     *
+     * Severity levels:
+     * - Security vulnerabilities (exposed passwords, missing auth boundaries)
+     * - Missing required variants, incorrect type mappings
+     * - Missing format specifications, incomplete relationships
+     * - Documentation improvements, style consistency
+     *
+     * Each issue must include the specific schema name and what needs to be
+     * fixed. If there are no issues at all, simply state: "No issues found."
+     */
+    review: string;
+
+    /**
+     * Action plan for addressing identified issues.
+     *
+     * Must specify concrete fixes categorized by priority:
+     *
+     * - For perfect schemas: "No improvements required. All schemas meet AutoBE
+     *   standards."
+     * - For fixable issues: List each fix with operation path and exact change
+     * - For critical problems: Describe how schemas were recreated or corrected
+     *
+     * Never leave this empty. Always provide a clear plan even if no changes
+     * are needed. The plan documents what was done to produce the content
+     * field.
+     */
+    plan: string;
+
+    /**
+     * Final validated and enhanced schemas ready for production use.
+     *
+     * DO:
+     * - Include valid OpenAPI schema definitions
+     * - Include all entities that were in the original input
+     * - Provide fixed versions if original schemas have issues
+     * - Rename entities correctly if names are wrong
+     * - Include created variants if schemas are missing them
+     *
+     * DO NOT:
+     * - Return an empty object {} (this will delete all schemas)
+     * - Return undefined or null
+     * - Include explanations or excuses in schema descriptions
+     * - Leave broken schemas unfixed
+     *
+     * When original schemas are beyond repair, recreate them properly based on
+     * entity names and context. This field becomes the final schemas used by
+     * the system, so it must always contain complete, valid schemas.
+     */
+    content: Record<
+      string,
+      AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema>
+    >;
+  }
+}

package/src/orchestrate/interface/utils/validateAuthorizationSchema.ts

@@ -0,0 +1,41 @@
+import { AutoBeOpenApi } from "@autobe/interface";
+import { IValidation } from "typia";
+
+export const validateAuthorizationSchema = (props: {
+  errors: IValidation.IError[];
+  schemas: Record<string, AutoBeOpenApi.IJsonSchemaDescriptive>;
+  path: string;
+}): void => {
+  for (const [key, value] of Object.entries(props.schemas)) {
+    if (!key.endsWith(".IAuthorized")) continue;
+
+    // Check if it's an object type
+    if (!isObjectSchema(value)) {
+      props.errors.push({
+        path: `${props.path}.${key}`,
+        expected: `AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema.IObject>`,
+        value: value,
+        description: `${key} must be an object type for authorization responses`,
+      });
+      continue;
+    }
+
+    // Check if token property exists
+    value.properties ??= {};
+    value.properties["token"] = {
+      $ref: "#/components/schemas/IAuthorizationToken",
+      description: "JWT token information for authentication",
+    } as AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema.IReference>;
+
+    value.required ??= [];
+    if (value.required.includes("token") === false) {
+      value.required.push("token");
+    }
+  }
+};
+
+const isObjectSchema = (
+  schema: AutoBeOpenApi.IJsonSchemaDescriptive,
+): schema is AutoBeOpenApi.IJsonSchemaDescriptive<AutoBeOpenApi.IJsonSchema.IObject> => {
+  return "type" in schema && schema.type === "object";
+};

package/src/orchestrate/prisma/histories/transformPrismaComponentsHistories.ts

@@ -1,4 +1,5 @@
 import { IAgenticaHistoryJson } from "@agentica/core";
+import { NamingConvention } from "typia/lib/utils/NamingConvention";
 import { v4 } from "uuid";
 
 import { AutoBeSystemPromptConstant } from "../../../constants/AutoBeSystemPromptConstant";
@@ -11,18 +12,9 @@ export const transformPrismaComponentsHistories = (
   IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage
 > => {
   if (state.analyze === null)
-    return [
-      {
-        id: v4(),
-        created_at: new Date().toISOString(),
-        type: "systemMessage",
-        text: [
-          "Requirement analysis is not yet completed.",
-          "Don't call any tool function,",
-          "but say to process the requirement analysis.",
-        ].join(" "),
-      },
-    ];
+    // unreachable
+    throw new Error("Analyze state is not set.");
+  if (prefix) prefix = NamingConvention.snake(prefix);
   return [
     {
       id: v4(),
@@ -50,13 +42,14 @@ export const transformPrismaComponentsHistories = (
         `* Prefix provided by the user: ${prefix}`,
         "",
         "The user wants all database schema (table) names to start with the prefix provided below.",
-        "If the prefix is `null`, it should be ignored.",
-        "If a prefix is provided, all table names **must begin with it**.",
-        "However, if there is a special-purpose prefix like `mv` (for materialized views), it **must precede** the given prefix.",
+        "",
+        "DO: Use the provided prefix for all table names",
+        "DO: Place special-purpose prefixes like `mv` (for materialized views) before the given prefix",
+        "DO NOT: Apply prefix if it is `null`",
         "",
         "## Prefix Example",
         "",
-        "If the prefix is `shopping`, then table names should be like:",
+        "If the prefix is `shopping`, then table names are like:",
         "",
         "* `shopping_sales`",
         "* `shopping_sale_options`",