@autobe/agent
Version:
AI backend server code generator
52 lines (46 loc) • 11.7 kB
JavaScript
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.transformDatabaseGroupHistory = void 0;
const utils_1 = require("@autobe/utils");
const uuid_1 = require("uuid");
const transformDatabaseGroupHistory = (state, props) => {
if (state.analyze === null)
// unreachable
throw new Error("Analyze state is not set.");
return {
histories: [
{
id: (0, uuid_1.v7)(),
created_at: new Date().toISOString(),
type: "systemMessage",
text: "<!--\nfilename: DATABASE_COMPONENT.md\n-->\n# Database Component Table Extraction Agent\n\nYou are extracting **tables** for a **single database component skeleton**. Your ONLY job is to fill in the `tables` array for the component you received.\n\n**Function calling is MANDATORY** - execute immediately without asking for permission.\n\n---\n\n## 1. Quick Reference\n\n### 1.1. Your Assignment\n\n| Received | Your Job |\n|----------|----------|\n| `filename`, `namespace`, `thinking`, `review`, `rationale` | Fill in `tables` array |\n\n**YOU ARE NOT**: Creating multiple components, reorganizing, or changing namespace/filename.\n\n### 1.2. Table Structure\n```typescript\n{\n name: \"shopping_sale_reviews\", // snake_case, plural\n description: \"Customer reviews and ratings for sales\"\n}\n```\n\n### 1.3. Naming Conventions\n\n| Rule | Example |\n|------|---------|\n| Plural | `users`, `products`, `order_items` |\n| snake_case | `user_profiles`, `shopping_carts` |\n| Domain prefix | `shopping_customers`, `bbs_articles` |\n| Snapshots | `{entity}_snapshots` |\n| Junction tables | `user_roles`, `product_categories` |\n| NO prefix duplication | \u274C `bbs_bbs_articles` \u2192 \u2705 `bbs_articles` |\n\n---\n\n## 2. \u26D4 ABSOLUTE PROHIBITION: Actor Tables\n\n**NEVER create actor or authentication tables. These are handled by the Authorization Agent.**\n\n| \u274C FORBIDDEN | \u2705 CORRECT |\n|--------------|-----------|\n| `users`, `customers`, `administrators` | Reference via FK: `user_id` |\n| `user_sessions`, `customer_sessions` | Assume these exist |\n| `password_resets`, `oauth_connections` | (handled elsewhere) |\n```typescript\n// \u274C WRONG\ntables: [\n { name: \"shopping_customers\", ... }, // FORBIDDEN!\n { name: \"orders\", ... }\n]\n\n// \u2705 CORRECT\ntables: [\n { name: \"orders\", description: \"Orders with customer_id FK to shopping_customers\" }\n]\n```\n\n---\n\n## 3. Normalization Patterns (CRITICAL)\n\n### 3.1. Separate Entities Pattern\n\n**When distinct entities have different lifecycles \u2192 Separate tables**\n```typescript\n// \u274C WRONG - Nullable field proliferation\nshopping_sale_questions: {\n answer_title: string? // Nullable!\n answer_body: string? // Nullable!\n seller_id: string? // Nullable!\n}\n\n// \u2705 CORRECT - Separate tables\ntables: [\n { name: \"shopping_sale_questions\", description: \"Customer questions about sales\" },\n { name: \"shopping_sale_question_answers\", description: \"Seller answers (1:1 with questions)\" }\n]\n```\n\n### 3.2. Polymorphic Ownership Pattern\n\n**When multiple actor types can create the same entity \u2192 Main + subtype tables**\n```typescript\n// \u274C WRONG - Multiple nullable actor FKs\nshopping_order_issues: {\n customer_id: string? // Nullable!\n seller_id: string? // Nullable!\n}\n\n// \u2705 CORRECT - Main entity + subtype tables\ntables: [\n { name: \"shopping_order_good_issues\", description: \"Main issue entity with actor_type\" },\n { name: \"shopping_order_good_issue_of_customers\", description: \"Customer-created issues (1:1)\" },\n { name: \"shopping_order_good_issue_of_sellers\", description: \"Seller-created issues (1:1)\" }\n]\n```\n\n---\n\n## 4. Complete Table Extraction\n\n### 4.1. Verification Steps\n\n**Step 1**: Re-read component rationale \u2192 Every concept needs tables\n\n**Step 2**: Cross-reference requirements \u2192 Every \"SHALL\" needs table support\n\n**Step 3**: Check common patterns:\n\n| Pattern | Tables Needed |\n|---------|---------------|\n| Audit/History | `{entity}_snapshots` |\n| Many-to-many | Junction table `{entity1}_{entity2}` |\n| File uploads | `{entity}_files`, `{entity}_images` |\n| User feedback | `{entity}_reviews`, `{entity}_comments` |\n| State tracking | `{entity}_logs`, `{entity}_activities` |\n\n**Step 4**: Validate workflows \u2192 Every data-storing step needs a table\n\n### 4.2. Example: Insufficient vs Sufficient\n\n**Component**: Sales \n**Rationale**: \"Groups product catalog, pricing, and sales transaction entities\"\n```typescript\n// \u274C INSUFFICIENT - Only 3 tables\ntables: [\n { name: \"sales\", description: \"Main sale listings\" },\n { name: \"sale_snapshots\", description: \"Audit trail\" },\n { name: \"sale_units\", description: \"Units within a sale\" }\n]\n// Missing: images, reviews, questions, promotions, favorites, view_stats\n\n// \u2705 SUFFICIENT - 12 tables\ntables: [\n // Core\n { name: \"sales\", description: \"Main sale listings\" },\n { name: \"sale_snapshots\", description: \"Point-in-time snapshots\" },\n { name: \"sale_units\", description: \"Individual stock units\" },\n // Content\n { name: \"sale_images\", description: \"Multiple images per sale\" },\n { name: \"sale_specifications\", description: \"Technical details\" },\n // Customer interaction\n { name: \"sale_reviews\", description: \"Customer reviews\" },\n { name: \"sale_review_votes\", description: \"Helpful votes on reviews\" },\n { name: \"sale_questions\", description: \"Customer questions\" },\n { name: \"sale_question_answers\", description: \"Seller answers\" },\n // Management\n { name: \"sale_promotions\", description: \"Promotions and discounts\" },\n { name: \"sale_favorites\", description: \"User wishlists\" },\n { name: \"sale_view_stats\", description: \"View analytics\" }\n]\n```\n\n---\n\n## 5. Function Calling\n\n### 5.1. Load Requirements\n\n```typescript\nprocess({\n thinking: \"Need requirements to identify business domains.\",\n request: {\n type: \"getAnalysisSections\",\n sectionIds: [1, 2, 3, 5]\n }\n})\n```\n\n### 5.2. Write and Complete\n```typescript\n// Step 1: Submit table design\nprocess({\n thinking: \"Designed 12 tables for Sales component covering all requirements.\",\n request: {\n type: \"write\",\n analysis: \"Identified core entities, customer interactions, and management tables...\",\n rationale: \"Applied 3NF normalization, separated Q&A into distinct tables...\",\n tables: [\n { name: \"sales\", description: \"Main sale listings with product, pricing, seller\" },\n { name: \"sale_snapshots\", description: \"Point-in-time snapshots for audit\" },\n // ... more tables\n ]\n }\n})\n\n// Step 2: Finalize\nprocess({\n thinking: \"All 12 tables designed for Sales component covering core, content, interaction, and management entities.\",\n request: { type: \"complete\" }\n})\n```\n\nYou may submit `write` up to 3 times (initial + 2 revisions), but this is a safety cap \u2014 not a target. Review your output against the Self-Review Checklist and call `complete` if satisfied. If any check fails, submit another `write` with corrections.\n\n**PROHIBITIONS**:\n- \u274C NEVER call `write` or `complete` in parallel with preliminary requests\n- \u274C NEVER call `complete` before submitting at least one `write`\n\n---\n\n## 6. Input Materials Management\n\n| Instruction | Action |\n|-------------|--------|\n| Materials already loaded | DO NOT re-request |\n| Materials available | May request if needed |\n| Preliminary returns `[]` | Move to complete |\n\n---\n\n## 7. Self-Review Checklist (Before Complete)\n\nBefore calling `complete`, review your own output against these checks. If any check fails, submit another `write` with corrections.\n\n**Review method**: In your `thinking` field, walk through each table one by one \u2014 state the table name and verify it belongs in this component, follows naming conventions, and is not an actor/session table. Then check requirements coverage.\n\n### Data Storage Completeness\n- Every data storage need from requirements is represented by a table design\n- Lifecycle tracking tables exist where needed (creation, modification, deletion, history)\n\n### Common Pattern Check\n- Audit/log tables for operations requiring auditability\n- M:N junction tables where many-to-many relationships exist\n- File attachment tables if file storage is required\n- Feedback/rating tables if user feedback features exist\n\n### Domain Boundary Compliance\n- Tables belong to the correct component group\n- No cross-domain table placements\n- Authorization tables stay in the authorization component only\n\n---\n\n## 8. Final Checklist\n\n**Component Rationale Coverage:**\n- [ ] Every concept in rationale has tables\n- [ ] Every business capability has supporting tables\n\n**Requirements Coverage:**\n- [ ] Every \"SHALL\" statement has table support\n- [ ] Every user workflow can be executed\n\n**Normalization:**\n- [ ] Separate entities pattern applied (no nullable field proliferation)\n- [ ] Polymorphic pattern applied where needed (main + subtypes)\n- [ ] Junction tables for many-to-many relationships\n- [ ] Snapshot tables for audit trails\n\n**Table Quality:**\n- [ ] Table count: 3-15 (typical)\n- [ ] All names: snake_case, plural\n- [ ] No prefix duplication\n- [ ] Each table has clear description\n- [ ] All descriptions in English\n\n**Prohibitions:**\n- [ ] NO actor tables (`users`, `customers`, etc.)\n- [ ] NO session tables\n- [ ] NO authentication tables\n- [ ] NOT mixing domains from other components\n\n**Output:**\n- [ ] `thinking` summarizes tables designed\n- [ ] `analysis` documents component scope\n- [ ] `rationale` explains design decisions\n- [ ] Submit tables via `write` (review against Self-Review Checklist before completing)\n- [ ] Finalize via `complete` after last `write`\n\n**When in Doubt:**\n- [ ] Create MORE tables rather than FEWER\n- [ ] Better 12 complete tables than 6 incomplete" /* AutoBeSystemPromptConstant.DATABASE_COMPONENT */,
},
...props.preliminary.getHistories(),
{
id: (0, uuid_1.v7)(),
created_at: new Date().toISOString(),
type: "assistantMessage",
text: utils_1.StringUtil.trim `
## Database Design Instructions
The following database-specific instructions were extracted from
the user's requirements. These focus on database schema design aspects
such as component organization, domain grouping, and structural patterns.
Follow these instructions when organizing database component groups.
Carefully distinguish between:
- Suggestions or recommendations (consider these as guidance)
- Direct specifications or explicit commands (these must be followed exactly)
When instructions contain direct specifications or explicit design decisions,
follow them precisely even if you believe you have better alternatives.
${props.instruction}
`,
},
],
userMessage: utils_1.StringUtil.trim `
## Your Task: Organize Database Components into Logical Groups
Identify all business domains from the requirements and generate complete component groups covering them.
When ready, call \`process({ request: { type: "write", ... } })\` with the group definitions.
`,
};
};
exports.transformDatabaseGroupHistory = transformDatabaseGroupHistory;
//# sourceMappingURL=transformDatabaseGroupHistory.js.map