@autobe/agent 0.5.1 → 0.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/lib/AutoBeAgent.js +25 -6
- package/lib/AutoBeAgent.js.map +1 -1
- package/lib/constants/AutoBeSystemPromptConstant.d.ts +3 -3
- package/lib/context/AutoBeContext.d.ts +2 -2
- package/lib/context/IAutoBeApplicationProps.d.ts +6 -0
- package/lib/factory/createAgenticaHistory.js +1 -0
- package/lib/factory/createAgenticaHistory.js.map +1 -1
- package/lib/factory/createAutoBeApplication.js +16 -16
- package/lib/factory/createAutoBeApplication.js.map +1 -1
- package/lib/index.mjs +4608 -4644
- package/lib/index.mjs.map +1 -1
- package/lib/{analyze → orchestrate/analyze}/AutoBeAnalyzeAgent.d.ts +4 -8
- package/lib/{analyze → orchestrate/analyze}/AutoBeAnalyzeAgent.js +10 -2
- package/lib/orchestrate/analyze/AutoBeAnalyzeAgent.js.map +1 -0
- package/lib/orchestrate/analyze/AutoBeAnalyzeFileSystem.js.map +1 -0
- package/lib/orchestrate/analyze/AutoBeAnalyzePointer.d.ts +9 -0
- package/lib/orchestrate/analyze/AutoBeAnalyzePointer.js +3 -0
- package/lib/orchestrate/analyze/AutoBeAnalyzePointer.js.map +1 -0
- package/lib/{analyze → orchestrate/analyze}/AutoBeAnalyzeReviewer.d.ts +1 -1
- package/lib/{analyze → orchestrate/analyze}/AutoBeAnalyzeReviewer.js +5 -0
- package/lib/orchestrate/analyze/AutoBeAnalyzeReviewer.js.map +1 -0
- package/lib/orchestrate/{orchestrateAnalyze.d.ts → analyze/orchestrateAnalyze.d.ts} +2 -2
- package/lib/orchestrate/{orchestrateAnalyze.js → analyze/orchestrateAnalyze.js} +101 -38
- package/lib/orchestrate/analyze/orchestrateAnalyze.js.map +1 -0
- package/lib/orchestrate/facade/transformFacadeStateMessage.js +1 -1
- package/lib/orchestrate/facade/transformFacadeStateMessage.js.map +1 -1
- package/lib/orchestrate/index.d.ts +3 -3
- package/lib/orchestrate/index.js +6 -6
- package/lib/orchestrate/index.js.map +1 -1
- package/lib/orchestrate/interface/orchestrateInterfaceComplement.js +5 -0
- package/lib/orchestrate/interface/orchestrateInterfaceComplement.js.map +1 -1
- package/lib/orchestrate/interface/orchestrateInterfaceComponents.js +3 -0
- package/lib/orchestrate/interface/orchestrateInterfaceComponents.js.map +1 -1
- package/lib/orchestrate/interface/transformInterfaceHistories.js +15 -0
- package/lib/orchestrate/interface/transformInterfaceHistories.js.map +1 -1
- package/lib/orchestrate/prisma/orchestratePrismaCorrect.js +764 -915
- package/lib/orchestrate/prisma/orchestratePrismaCorrect.js.map +1 -1
- package/lib/orchestrate/prisma/transformPrismaComponentsHistories.js +7 -0
- package/lib/orchestrate/prisma/transformPrismaComponentsHistories.js.map +1 -1
- package/lib/orchestrate/prisma/transformPrismaCorrectHistories.js +10 -1
- package/lib/orchestrate/prisma/transformPrismaCorrectHistories.js.map +1 -1
- package/lib/orchestrate/prisma/transformPrismaHistories.js +9 -0
- package/lib/orchestrate/prisma/transformPrismaHistories.js.map +1 -1
- package/lib/orchestrate/prisma/transformPrismaSchemaHistories.js +8 -1
- package/lib/orchestrate/prisma/transformPrismaSchemaHistories.js.map +1 -1
- package/lib/structures/IAutoBeVendor.d.ts +45 -2
- package/package.json +6 -6
- package/src/AutoBeAgent.ts +32 -3
- package/src/constants/AutoBeSystemPromptConstant.ts +3 -3
- package/src/context/AutoBeContext.ts +2 -2
- package/src/context/IAutoBeApplicationProps.ts +6 -0
- package/src/factory/createAgenticaHistory.ts +1 -0
- package/src/factory/createAutoBeApplication.ts +1 -1
- package/src/{analyze → orchestrate/analyze}/AutoBeAnalyzeAgent.ts +20 -15
- package/src/orchestrate/analyze/AutoBeAnalyzePointer.ts +10 -0
- package/src/{analyze → orchestrate/analyze}/AutoBeAnalyzeReviewer.ts +7 -2
- package/src/orchestrate/{orchestrateAnalyze.ts → analyze/orchestrateAnalyze.ts} +43 -24
- package/src/orchestrate/index.ts +3 -3
- package/src/orchestrate/interface/orchestrateInterfaceComplement.ts +5 -0
- package/src/orchestrate/interface/orchestrateInterfaceComponents.ts +3 -0
- package/src/orchestrate/interface/transformInterfaceHistories.ts +15 -0
- package/src/orchestrate/prisma/orchestratePrismaCorrect.ts +112 -79
- package/src/orchestrate/prisma/transformPrismaComponentsHistories.ts +7 -0
- package/src/orchestrate/prisma/transformPrismaCorrectHistories.ts +9 -0
- package/src/orchestrate/prisma/transformPrismaHistories.ts +9 -0
- package/src/orchestrate/prisma/transformPrismaSchemaHistories.ts +7 -0
- package/src/structures/IAutoBeVendor.ts +48 -2
- package/lib/analyze/AnalyzeAgent.d.ts +0 -24
- package/lib/analyze/AnalyzeAgent.js +0 -942
- package/lib/analyze/AnalyzeAgent.js.map +0 -1
- package/lib/analyze/AutoBeAnalyzeAgent.js.map +0 -1
- package/lib/analyze/AutoBeAnalyzeFileSystem.js.map +0 -1
- package/lib/analyze/AutoBeAnalyzeReviewer.js.map +0 -1
- package/lib/orchestrate/orchestrateAnalyze.js.map +0 -1
- package/src/analyze/AnalyzeAgent.ts +0 -183
- /package/lib/{analyze → orchestrate/analyze}/AutoBeAnalyzeFileSystem.d.ts +0 -0
- /package/lib/{analyze → orchestrate/analyze}/AutoBeAnalyzeFileSystem.js +0 -0
- /package/src/{analyze → orchestrate/analyze}/AutoBeAnalyzeFileSystem.ts +0 -0
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"orchestratePrismaCorrect.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/orchestratePrismaCorrect.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAUA,
|
|
1
|
+
{"version":3,"file":"orchestratePrismaCorrect.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/orchestratePrismaCorrect.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAUA,4DAcC;;;AAxBD,yCAAoE;AAIpE,kDAA0B;AAG1B,uEAAoE;AACpE,uFAAoF;AAEpF,SAAgB,wBAAwB,CACtC,GAAyB,EACzB,WAAsC,EACtC,QAAgB,CAAC;IAEjB,MAAM,MAAM,GAAgB,IAAI,GAAG,EAAE,CAAC;IACtC,KAAK,MAAM,IAAI,IAAI,WAAW,CAAC,KAAK;QAClC,IAAI,CAAC,MAAM,GAAG,IAAI,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC,KAAK,EAAE,EAAE;YACzC,IAAI,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,IAAI,CAAC;gBAAE,OAAO,KAAK,CAAC;YACzC,MAAM,CAAC,GAAG,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACvB,OAAO,IAAI,CAAC;QACd,CAAC,CAAC,CAAC;IACL,WAAW,CAAC,KAAK,GAAG,WAAW,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,CAAC,MAAM,KAAK,CAAC,CAAC,CAAC;IAC3E,OAAO,IAAI,CAAC,GAAG,EAAE,WAAW,EAAE,KAAK,CAAC,CAAC;AACvC,CAAC;AAED,SAAe,IAAI,CACjB,GAAyB,EACzB,WAAsC,EACtC,IAAY;;;QAEZ,MAAM,MAAM,GACV,MAAM,GAAG,CAAC,QAAQ,CAAC,MAAM,CAAC,QAAQ,CAAC,WAAW,CAAC,CAAC;QAClD,IAAI,MAAM,CAAC,OAAO;YAAE,OAAO,MAAM,CAAC,CAAC,UAAU;QAE7C,oBAAoB;QACpB,MAAM,OAAO,GACX,MAAM,GAAG,CAAC,QAAQ,CAAC,MAAM,CAAC,KAAK,CAAC,WAAW,CAAC,CAAC;QAC/C,GAAG,CAAC,QAAQ,CAAC;YACX,IAAI,EAAE,gBAAgB;YACtB,MAAM;YACN,OAAO;YACP,QAAQ,EAAE,MAAM,GAAG,CAAC,QAAQ,CAAC,MAAM,CAAC,OAAO,CAAC;gBAC1C,KAAK,EAAE,OAAO;aACf,CAAC;YACF,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC;YACpC,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC,CAAC,CAAC;QAEH,MAAM,OAAO,GAAmD;YAC9D,KAAK,EAAE,IAAI;SACZ,CAAC;QACF,MAAM,QAAQ,GAAyB,IAAI,oBAAa,CAAC;YACvD,KAAK,EAAE,GAAG,CAAC,KAAK;YAChB,MAAM,EAAE,GAAG,CAAC,MAAM;YAClB,MAAM,oBACD,CAAC,MAAA,GAAG,CAAC,MAAM,mCAAI,EAAE,CAAC,CACtB;YACD,SAAS,EAAE,IAAA,iEAA+B,EAAC,MAAM,CAAC;YAClD,UAAU,EAAE,GAAG,CAAC,KAAK,EAAE;YACvB,WAAW,EAAE;gBACX,iBAAiB,CAAC;oBAChB,KAAK,EAAE,GAAG,CAAC,KAAK;oBAChB,KAAK,EAAE,CAAC,IAAI,EAAE,EAAE;wBACd,OAAO,CAAC,KAAK,GAAG,IAAI,CAAC;oBACvB,CAAC;iBACF,CAAC;aACH;SACF,CAAC,CAAC;QACH,QAAQ,CAAC,EAAE,CAAC,SAAS,EAAE,CAAC,KAAK,EAAE,EAAE;YAC/B,IAAI,KAAK,CAAC,IAAI,CAAC,KAAK,EAAE,CAAC;gBACrB,KAAK,CAAC,IAAI,CAAC,WAAW,GAAG,UAAU,CAAC;YACtC,CAAC;QACH,CAAC,CAAC,CAAC;QAEH,qBAAqB;QACrB,MAAM,QAAQ,CAAC,UAAU,CACvB,qEAAqE,CACtE,CAAC;QACF,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI,EAAE,CAAC;YAC3B,OAAO,CAAC,KAAK,CACX,8DAA8D,CAC/D,CAAC;YACF,OAAO,MAAM,CAAC,CAAC,cAAc;QAC/B,CAAC;QAED,MAAM,UAAU,GAA8B;YAC5C,KAAK,EAAE,WAAW,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAC;gBACtC,QAAQ,EAAE,IAAI,CAAC,QAAQ;gBACvB,SAAS,EAAE,IAAI,CAAC,SAAS;gBACzB,MAAM,EAAE,IAAI,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE;oBAChC,MAAM,MAAM,GAAG,OAAO,CAAC,KAAM,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,KAAK,CAAC,IAAI,CAAC,CAAC;oBACxE,OAAO,MAAM,aAAN,MAAM,cAAN,MAAM,GAAI,KAAK,CAAC;gBACzB,CAAC,CAAC;aACH,CAAC,CAAC;SACJ,CAAC;QACF,GAAG,CAAC,QAAQ,CAAC;YACX,IAAI,EAAE,eAAe;YACrB,OAAO,EAAE,MAAM;YACf,UAAU;YACV,QAAQ,EAAE,OAAO,CAAC,KAAK,CAAC,QAAQ;YAChC,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC;YACpC,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACrC,CAAC,CAAC;QACH,OAAO,IAAI,CACT,GAAG,EACH;YACE,KAAK,EAAE,UAAU,CAAC,KAAK;SACxB,EACD,IAAI,GAAG,CAAC,CACT,CAAC;IACJ,CAAC;CAAA;AAED,SAAS,iBAAiB,CAAiC,KAG1D;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAC/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACyB,CAAC;IACvC,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,iBAAiB;QACvB,WAAW;QACX,OAAO,EAAE;YACP,wBAAwB,EAAE,CAAC,IAAI,EAAE,EAAE;gBACjC,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACqB;KACzB,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAIT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAIJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;IACb,KAAK;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAA8C;CACpD,CAAC"}
|
|
@@ -1,10 +1,13 @@
|
|
|
1
1
|
"use strict";
|
|
2
2
|
Object.defineProperty(exports, "__esModule", { value: true });
|
|
3
3
|
exports.transformPrismaComponentsHistories = void 0;
|
|
4
|
+
const uuid_1 = require("uuid");
|
|
4
5
|
const transformPrismaComponentsHistories = (state) => {
|
|
5
6
|
if (state.analyze === null)
|
|
6
7
|
return [
|
|
7
8
|
{
|
|
9
|
+
id: (0, uuid_1.v4)(),
|
|
10
|
+
created_at: new Date().toISOString(),
|
|
8
11
|
type: "systemMessage",
|
|
9
12
|
text: [
|
|
10
13
|
"Requirement analysis is not yet completed.",
|
|
@@ -15,10 +18,14 @@ const transformPrismaComponentsHistories = (state) => {
|
|
|
15
18
|
];
|
|
16
19
|
return [
|
|
17
20
|
{
|
|
21
|
+
id: (0, uuid_1.v4)(),
|
|
22
|
+
created_at: new Date().toISOString(),
|
|
18
23
|
type: "systemMessage",
|
|
19
24
|
text: "You are a world-class database architecture analyst specializing in domain-driven design and schema organization. You excel at analyzing requirements and organizing database models into logical, maintainable file structures.\n\n### Core Principles\n\n- **Never ask for clarification** - Work with the provided requirements and make reasonable assumptions\n- **Output only structured JSON** - Return organized file-table mappings in the specified format\n- **Follow domain-driven design** - Group related entities into cohesive domains\n- **Prioritize logical separation** - Ensure clear boundaries between different business domains\n\n### Default Working Language: English\n\n- Use the language specified by user in messages as the working language when explicitly provided\n- All thinking and analysis must be in the working language\n- All model/table names must be in English regardless of working language\n\n### Task: Analyze Requirements and Generate File Structure\n\nYour primary task is to analyze user requirements and generate a structured file organization plan in the format: `{filename: string; tables: string[]}[]`\n\n### Analysis Steps\n\n1. **Domain Analysis**: Identify distinct business domains from requirements\n2. **Entity Identification**: Extract all entities/models mentioned or implied\n3. **Relationship Mapping**: Understand how entities relate across domains\n4. **File Organization**: Group related entities into logical files\n5. **Validation**: Ensure all entities are accounted for and properly grouped\n\n### File Organization Guidelines\n\n#### Naming Conventions\n\n- **Filenames**: `schema-{number}-{domain}.prisma` (e.g., `schema-01-core.prisma`, `schema-02-users.prisma`)\n- **Domain names**: Use clear, descriptive domain names in snake_case\n\n#### Grouping Strategy\n\n- **Core/Foundation**: Basic entities used across multiple domains (users, organizations)\n- **Domain-specific**: Entities belonging to specific business domains\n- **Cross-cutting**: Entities that span multiple domains (notifications, audit logs)\n- **Utility**: Helper entities (settings, configurations)\n\n#### File Structure Rules\n\n- **Maximum 8-10 models per file** for maintainability\n- **Related entities together**: Keep strongly related models in the same file\n- **Dependency consideration**: Place foundational models in earlier files\n- **Logical progression**: Order files from core to specific domains\n\n### Expected Output Format\n\n```json\n[\n {\n \"filename\": \"schema-01-core.prisma\", \n \"tables\": [\"users\", \"user_profiles\", \"organizations\"]\n },\n {\n \"filename\": \"schema-02-articles.prisma\",\n \"tables\": [\"articles\", \"article_snapshots\", \"article_comments\"]\n }\n]\n```\n\n### Quality Checklist\n\nBefore outputting, ensure:\n- [ ] All entities from requirements are included\n- [ ] Files are logically organized by domain\n- [ ] No single file is overloaded with too many models\n- [ ] Dependencies flow from core to specific domains\n- [ ] Filename conventions are followed" /* AutoBeSystemPromptConstant.PRISMA_COMPONENT */,
|
|
20
25
|
},
|
|
21
26
|
{
|
|
27
|
+
id: (0, uuid_1.v4)(),
|
|
28
|
+
created_at: new Date().toISOString(),
|
|
22
29
|
type: "assistantMessage",
|
|
23
30
|
text: [
|
|
24
31
|
"Here is the requirement analysis report.",
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"transformPrismaComponentsHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/transformPrismaComponentsHistories.ts"],"names":[],"mappings":";;;
|
|
1
|
+
{"version":3,"file":"transformPrismaComponentsHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/transformPrismaComponentsHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAKnB,MAAM,kCAAkC,GAAG,CAChD,KAAkB,EAGlB,EAAE;IACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,+BAA+B;oBAC/B,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;IACJ,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,iiGAA6C;SAClD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,0CAA0C;gBAC1C,EAAE;gBACF,8DAA8D;gBAC9D,gDAAgD;gBAChD,EAAE;gBACF,iBAAiB;gBACjB,KAAK,CAAC,OAAO,CAAC,MAAM;gBACpB,EAAE;gBACF,gCAAgC;gBAChC,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC;gBACnC,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AA9CW,QAAA,kCAAkC,sCA8C7C"}
|
|
@@ -1,13 +1,18 @@
|
|
|
1
1
|
"use strict";
|
|
2
2
|
Object.defineProperty(exports, "__esModule", { value: true });
|
|
3
3
|
exports.transformPrismaCorrectHistories = void 0;
|
|
4
|
+
const uuid_1 = require("uuid");
|
|
4
5
|
const transformPrismaCorrectHistories = (result) => {
|
|
5
6
|
return [
|
|
6
7
|
{
|
|
8
|
+
id: (0, uuid_1.v4)(),
|
|
9
|
+
created_at: new Date().toISOString(),
|
|
7
10
|
type: "systemMessage",
|
|
8
|
-
text: "# AutoBePrismaSyntax Validation Error Fixing Agent\n\nYou are a world-class Prisma schema validation and error resolution specialist working with structured AutoBePrismaSyntax definitions. Your primary mission is to analyze validation errors in IAutoBePrismaValidation.IFailure responses and provide precise fixes while maintaining complete schema integrity and business logic.\n\n## Core Operating Principles\n\n### \uD83D\uDEAB ABSOLUTE PROHIBITIONS\n- **NEVER ask for clarification** - analyze and fix validation errors directly\n- **NEVER remove or modify existing business logic** unless it causes validation errors\n- **NEVER delete model descriptions or field descriptions** unless removing duplicate elements\n- **NEVER create new duplicate fields, relations, or models**\n- **NEVER ignore validation errors** - every error must be addressed\n- **NEVER break existing relationships** unless they're causing validation errors\n- **NEVER change data types** unless specifically required by validation errors\n\n### \u2705 MANDATORY REQUIREMENTS\n- **Fix ALL validation errors** listed in the IAutoBePrismaValidation.IFailure.errors array\n- **Preserve business intent** and architectural patterns from original schema\n- **Return complete AutoBePrismaSyntax.IApplication** structure with all fixes applied\n- **Maintain referential integrity** across all models and relationships\n- **Preserve ALL model and field descriptions** (except for removed duplicates)\n- **Keep original naming conventions** unless they cause validation errors\n\n## Error Analysis & Resolution Strategy\n\n### 1. Validation Error Processing\n\n#### Error Structure Analysis\n```typescript\ninterface IError {\n path: string; // File path where error occurs\n table: string; // Model name with the error\n column: string | null; // Field name (null for model-level errors)\n message: string; // Detailed error description\n}\n```\n\n#### Error Categorization\n- **Model-level errors** (column: null): Duplicate models, invalid model names, missing primary keys\n- **Field-level errors** (column: string): Duplicate fields, invalid types, missing foreign keys\n- **Relationship errors**: Invalid references, missing target models, circular dependencies\n- **Index errors**: Invalid field references, duplicate indexes\n- **Cross-file errors**: References to non-existent models across files\n\n### 2. Common Validation Errors & Solutions\n\n#### Duplication Errors\n- **Duplicate model names across files**\n - Rename one model with domain-specific prefix/suffix\n - Update all references to renamed model in foreign keys and relations\n- **Duplicate field names within model**\n - Remove or rename duplicate field (preserve most appropriate one)\n - Update any references or indexes that use the renamed field\n- **Duplicate relation names within model**\n - Rename conflicting relation with descriptive suffix\n - Ensure relation names don't conflict with field names\n\n#### Reference Errors\n- **Invalid target model in foreign field**\n - Update targetModel to correct existing model name\n - Verify model exists in the specified file\n- **Invalid target field in foreign field**\n - Usually should be \"id\" - update targetfield property\n- **Missing foreign key for relation**\n - Add required foreign key field to foreignFields array\n - Ensure field name matches relation configuration\n\n#### Type Validation Errors\n- **Invalid field type**\n - Update to valid AutoBePrismaSyntax type (boolean, int, double, string, uri, uuid, date, datetime)\n- **Foreign key type mismatch**\n - Ensure all foreign keys use \"uuid\" type\n- **Primary key issues**\n - Ensure primaryField has type \"uuid\" and name \"id\"\n\n#### Index Validation Errors\n- **Invalid field names in indexes**\n - Update fieldNames array to reference existing fields only\n - Remove references to non-existent fields\n- **Single foreign key in indexes**\n - Remove single foreign key fields from plainIndexes and uniqueIndexes\n - Keep composite indexes that include foreign keys with other fields\n\n#### Naming Convention Errors\n- **Non-plural model names**\n - Update model name to plural form\n - Update all references in other models' foreign keys and relations\n- **Invalid field naming**\n - Update to snake_case convention\n - Update any references in indexes\n\n### 3. Fix Implementation Strategy\n\n#### Error Processing Order\n1. **Model-level duplications** - Fix duplicate model names first\n2. **Field-level duplications** - Fix duplicate fields within models\n3. **Reference errors** - Fix invalid model/field references\n4. **Type validation** - Fix invalid data types\n5. **Index validation** - Fix invalid index configurations\n6. **Cross-validation** - Ensure all fixes maintain integrity\n\n#### Reference Update Process\nWhen renaming models or fields:\n1. **Update foreign key field names** in other models\n2. **Update targetModel references** in foreign field relations\n3. **Update index field references** that use renamed fields\n4. **Verify bidirectional relationships** remain consistent\n\n#### Business Logic Preservation\n- **Keep original field purposes** when fixing naming/type issues\n- **Maintain relationship semantics** when fixing reference errors\n- **Preserve data integrity constraints** when fixing index issues\n- **Keep audit trail patterns** (snapshots, timestamps) intact\n\n### 4. Validation Rules Compliance\n\n#### Model Validation\n- All model names must be plural and unique across all files\n- Each model must have exactly one primaryField with type \"uuid\" and name \"id\"\n- Materialized views must have material: true and name starting with \"mv_\"\n\n#### Field Validation\n- No duplicate field names within the same model\n- All foreign key fields must have type \"uuid\" and follow \"{target_model}_id\" pattern\n- All foreign fields must have corresponding relation configuration\n\n#### Relationship Validation\n- All targetModel references must point to existing models\n- All targetfield references should be \"id\" (primary key)\n- Relation names must be unique within each model\n- Relation names must not conflict with field names\n\n#### Index Validation\n- No single foreign key fields in plainIndexes or uniqueIndexes arrays\n- All fieldNames in indexes must reference existing fields in the model\n- Composite indexes can include foreign keys with other fields\n\n## Error Resolution Workflow\n\n### 1. Error Analysis Phase\n1. **Parse IAutoBePrismaValidation.IFailure** structure\n2. **Categorize errors by type** (duplication, reference, type, index, naming)\n3. **Group related errors** that might be fixed together\n4. **Plan fix sequence** to avoid creating new errors\n\n### 2. Fix Planning Phase\n1. **Identify models/fields to rename** for duplication resolution\n2. **Plan reference updates** for all affected elements\n3. **Determine minimal changes** needed for each error\n4. **Check for fix conflicts** that might create new errors\n\n### 3. Fix Implementation Phase\n1. **Apply duplication fixes** (renames, removals)\n2. **Update all references** to renamed elements\n3. **Fix type and validation errors**\n4. **Update indexes** to reference correct fields\n5. **Verify relationship integrity**\n\n### 4. Validation Phase\n1. **Check all errors are addressed**\n2. **Verify no new validation issues**\n3. **Confirm business logic preservation**\n4. **Validate cross-file reference integrity**\n\n## Input/Output Format\n\n### Input Structure\n```typescript\n{\n success: false,\n application: AutoBePrismaSyntax.IApplication,\n errors: IError[]\n}\n```\n\n### Output Requirement\nReturn corrected AutoBePrismaSyntax.IApplication structure:\n```typescript\nconst fixedApplication: AutoBePrismaSyntax.IApplication = {\n files: [\n // All files with errors fixed\n // Complete model definitions preserved\n // All descriptions and business logic maintained\n ]\n};\n```\n\n## Critical Success Criteria\n\n### \u2705 Must Achieve\n- [ ] All validation errors from IError[] array resolved\n- [ ] Original business logic and purpose preserved\n- [ ] All model and field descriptions maintained (except removed duplicates)\n- [ ] No new duplicate models, fields, or relations created\n- [ ] All cross-file references remain valid\n- [ ] Referential integrity maintained across all relationships\n- [ ] Naming conventions properly applied (plural models, snake_case fields)\n- [ ] Index configurations comply with rules (no single foreign keys)\n- [ ] Return complete AutoBePrismaSyntax.IApplication structure\n\n### \uD83D\uDEAB Must Avoid\n- [ ] Ignoring any validation errors\n- [ ] Creating new duplications during fixes\n- [ ] Breaking existing business relationships\n- [ ] Removing necessary business logic\n- [ ] Making unnecessary changes beyond error fixes\n- [ ] Creating circular dependencies\n- [ ] Introducing type mismatches\n- [ ] Breaking cross-file reference integrity\n\n## Quality Assurance Process\n\n### Pre-Output Validation\n1. **Error Resolution Check**: Verify every error in the original IError[] array is addressed\n2. **Duplication Prevention**: Ensure no new duplicates are introduced\n3. **Reference Integrity**: Validate all foreign key references point to existing models/fields\n4. **Business Logic Preservation**: Confirm original intent and descriptions are maintained\n5. **Type Consistency**: Verify all types comply with AutoBePrismaSyntax requirements\n6. **Index Compliance**: Ensure index configurations follow the established rules\n\n### Response Validation Questions\n- Are all validation errors from the input resolved?\n- Do all model names follow plural naming convention?\n- Are all foreign key types \"uuid\" and properly referenced?\n- Do all indexes avoid single foreign key fields?\n- Are all cross-file model references valid?\n- Is the business logic from original descriptions preserved?\n\nRemember: Your goal is to be a precise validation error resolver, not a schema redesigner. Fix only what validation errors require, preserve all business intent, and maintain the integrity of the AutoBePrismaSyntax structure." /* AutoBeSystemPromptConstant.PRISMA_CORRECT */,
|
|
11
|
+
text: "# `AutoBePrisma` Targeted Validation Error Fixing Agent\n\nYou are a world-class Prisma schema validation and error resolution specialist working with structured `AutoBePrisma` definitions. Your primary mission is to analyze validation errors in `IAutoBePrismaValidation.IFailure` responses and provide precise fixes for **ONLY the affected tables/models** while maintaining complete schema integrity and business logic.\n\n## Core Operating Principles\n\n### \uD83D\uDEAB ABSOLUTE PROHIBITIONS\n- **NEVER ask for clarification** - analyze and fix validation errors directly\n- **NEVER remove or modify existing business logic** unless it causes validation errors\n- **NEVER delete model descriptions or field descriptions** unless removing duplicate elements\n- **NEVER create new duplicate fields, relations, or models**\n- **NEVER ignore validation errors** - every error must be addressed\n- **NEVER break existing relationships** unless they're causing validation errors\n- **NEVER change data types** unless specifically required by validation errors\n- **\uD83D\uDD34 CRITICAL: NEVER delete fields or relationships to avoid compilation errors**\n- **\uD83D\uDD34 CRITICAL: Only delete elements when they are EXACT DUPLICATES of existing elements**\n- **\uD83D\uDD34 CRITICAL: Always FIX errors by correction, not by removal (unless duplicate)**\n- **\uD83D\uDD34 CRITICAL: NEVER modify tables/models that are not mentioned in validation errors**\n\n### \u2705 MANDATORY REQUIREMENTS\n- **Fix ONLY validation errors** listed in the IAutoBePrismaValidation.IFailure.errors array\n- **Return ONLY the corrected models/tables** that had validation errors\n- **Preserve business intent** and architectural patterns from original schema\n- **Maintain referential integrity** with unchanged models\n- **Preserve ALL model and field descriptions** (except for removed duplicates)\n- **Keep original naming conventions** unless they cause validation errors\n- **\uD83D\uDFE2 PRIORITY: Correct errors through proper fixes, not deletions**\n- **\uD83D\uDFE2 PRIORITY: Maintain ALL business functionality and data structure**\n- **\uD83D\uDFE2 PRIORITY: Minimize output scope to only affected models**\n\n## Targeted Fix Strategy\n\n### 1. Error Scope Analysis\n\n#### Error Filtering Process\n```typescript\ninterface IError {\n path: string; // File path where error occurs\n table: string; // Model name with the error - TARGET FOR FIX\n column: string | null; // Field name (null for model-level errors)\n message: string; // Detailed error description\n}\n```\n\n#### Affected Model Identification\n1. **Extract unique table names** from all errors in IError[] array\n2. **Group errors by table** for efficient processing\n3. **Identify cross-table dependencies** that need consideration\n4. **Focus ONLY on models mentioned in errors** - ignore all others\n5. **Track relationship impacts** on non-error models (for reference validation only)\n\n### 2. Targeted Error Resolution\n\n#### Model-Level Fixes (Scope: Single Model)\n- **Duplicate model names**: Rename affected model only\n- **Invalid model names**: Update naming convention for specific model\n- **Missing primary keys**: Add/fix primary key in affected model only\n- **Materialized view issues**: Fix material flag and naming for specific model\n\n#### Field-Level Fixes (Scope: Specific Fields in Error Models)\n- **Duplicate field names**: Fix only within the affected model\n- **Invalid field types**: Update types for specific fields only\n- **Missing foreign keys**: Add required foreign keys to affected model only\n- **Foreign key reference errors**: Fix references in affected model only\n\n#### Relationship Fixes (Scope: Affected Model Relations)\n- **Invalid target model references**: Update references in error model only\n- **Missing relation configurations**: Add/fix relations in affected model only\n- **Relation naming conflicts**: Resolve conflicts within affected model only\n\n#### Index Fixes (Scope: Affected Model Indexes)\n- **Invalid field references**: Fix index fieldNames in affected model only\n- **Single foreign key indexes**: Restructure indexes in affected model only\n- **Duplicate indexes**: Remove duplicates within affected model only\n\n### 3. Cross-Model Impact Analysis\n\n#### Reference Validation (Read-Only for Non-Error Models)\n- **Verify target model existence** for foreign key references\n- **Check target field validity** (usually \"id\" primary key)\n- **Validate bidirectional relationship consistency**\n- **Ensure renamed model references are updated** in other models\n\n#### Dependency Tracking\n- **Identify models that reference** the corrected models\n- **Note potential cascade effects** of model/field renaming\n- **Flag models that may need reference updates** (for external handling)\n- **Maintain awareness of schema-wide implications**\n\n### 4. Minimal Output Strategy\n\n#### Output Scope Determination\n**Include in output ONLY:**\n1. **Models explicitly mentioned in validation errors**\n2. **Models with fields that reference renamed models** (if any)\n3. **Models that require relationship updates** due to fixes\n\n**Exclude from output:**\n1. **Models with no validation errors**\n2. **Models not affected by fixes**\n3. **Models that maintain valid references to corrected models**\n\n#### Fix Documentation\nFor each corrected model, provide:\n- **Original error description**\n- **Applied fix explanation**\n- **Impact on other models** (reference updates needed)\n- **Business logic preservation confirmation**\n\n## Error Resolution Workflow\n\n### 1. Error Parsing & Scope Definition\n1. **Parse IAutoBePrismaValidation.IFailure** structure\n2. **Extract unique table names** from error array\n3. **Group errors by affected model** for batch processing\n4. **Identify minimal fix scope** - only what's necessary\n5. **Plan cross-model reference updates** (if needed)\n\n### 2. Targeted Fix Planning\n1. **Analyze each error model individually**\n2. **Plan fixes for each affected model**\n3. **Check for inter-model dependency impacts**\n4. **Determine minimal output scope**\n5. **Validate fix feasibility without breaking references**\n\n### 3. Precision Fix Implementation\n1. **Apply fixes ONLY to error models**\n2. **Update cross-references ONLY if needed**\n3. **Preserve all unchanged model integrity**\n4. **Maintain business logic in fixed models**\n5. **Verify minimal scope compliance**\n\n### 4. Output Validation\n1. **Confirm all errors are addressed** in affected models\n2. **Verify no new validation issues** in fixed models\n3. **Check reference integrity** with unchanged models\n4. **Validate business logic preservation** in corrected models\n5. **Ensure minimal output scope** - no unnecessary models included\n\n## Input/Output Format\n\n### Input Structure\n```typescript\n{\n success: false,\n application: AutoBePrisma.IApplication, // Full schema for reference\n errors: IError[] // Target models for fixing\n}\n```\n\n### Output Requirement\nReturn ONLY corrected models that had validation errors:\n```typescript\nconst correctedModels: AutoBePrisma.IModel[] = [\n // ONLY models mentioned in IError[] array\n // ONLY models affected by cross-reference updates\n // All other models are preserved unchanged\n];\n\n// Include metadata about the fix scope\nconst fixSummary = {\n correctedModels: string[], // Names of models that were fixed\n crossReferenceUpdates: string[], // Models that needed reference updates\n preservedModels: string[], // Models that remain unchanged\n errorsCorrected: number // Count of resolved errors\n};\n```\n\n## Targeted Correction Examples\n\n### Example 1: Single Model Duplicate Field Error\n**Input Error:**\n```typescript\n{\n path: \"users.prisma\",\n table: \"users\",\n column: \"email\",\n message: \"Duplicate field 'email' in model 'users'\"\n}\n```\n\n**Output:** Only the `users` model with the duplicate field resolved\n- **Scope:** 1 model\n- **Change:** Rename one `email` field to `email_secondary` or merge if identical\n- **Excluded:** All other models remain unchanged\n\n### Example 2: Cross-Model Reference Error\n**Input Error:**\n```typescript\n{\n path: \"orders.prisma\",\n table: \"orders\",\n column: \"user_id\",\n message: \"Invalid target model 'user' for foreign key 'user_id'\"\n}\n```\n\n**Output:** Only the `orders` model with corrected reference\n- **Scope:** 1 model (orders)\n- **Change:** Update `targetModel` from \"user\" to \"users\"\n- **Excluded:** The `users` model remains unchanged (just referenced correctly)\n\n### Example 3: Model Name Duplication Across Files\n**Input Errors:**\n```typescript\n[\n {\n path: \"auth/users.prisma\",\n table: \"users\",\n column: null,\n message: \"Duplicate model name 'users'\"\n },\n {\n path: \"admin/users.prisma\",\n table: \"users\",\n column: null,\n message: \"Duplicate model name 'users'\"\n }\n]\n```\n\n**Output:** Both affected `users` models with one renamed\n- **Scope:** 2 models\n- **Change:** Rename one to `admin_users`, update all its references\n- **Excluded:** All other models that don't reference the renamed model\n\n## Critical Success Criteria\n\n### \u2705 Must Achieve (Targeted Scope)\n- [ ] All validation errors resolved **for mentioned models only**\n- [ ] Original business logic preserved **in corrected models**\n- [ ] Cross-model references remain valid **through minimal updates**\n- [ ] Output contains **ONLY affected models** - no unnecessary inclusions\n- [ ] Referential integrity maintained **with unchanged models**\n- [ ] **\uD83D\uDD34 MINIMAL SCOPE: Only error models + necessary reference updates**\n- [ ] **\uD83D\uDD34 UNCHANGED MODELS: Preserved completely in original schema**\n\n### \uD83D\uDEAB Must Avoid (Scope Violations)\n- [ ] Including models without validation errors in output\n- [ ] Modifying models not mentioned in error array\n- [ ] Returning entire schema when only partial fixes needed\n- [ ] Making unnecessary changes beyond error resolution\n- [ ] Breaking references to unchanged models\n- [ ] **\uD83D\uDD34 SCOPE CREEP: Fixing models that don't have errors**\n- [ ] **\uD83D\uDD34 OUTPUT BLOAT: Including unchanged models in response**\n\n## Quality Assurance Process\n\n### Pre-Output Scope Validation\n1. **Error Coverage Check**: Every error in IError[] array addressed **in minimal scope**\n2. **Output Scope Audit**: Only affected models included in response\n3. **Reference Integrity**: Unchanged models maintain valid references\n4. **Business Logic Preservation**: Corrected models maintain original intent\n5. **Cross-Model Impact**: Necessary reference updates identified and applied\n6. ****\uD83D\uDD34 Minimal Output Verification**: No unnecessary models in response**\n7. **\uD83D\uDD34 Unchanged Model Preservation**: Non-error models completely preserved**\n\n### Targeted Response Validation Questions\n- Are all validation errors resolved **with minimal model changes**?\n- Does the output include **ONLY models that had errors** or needed reference updates?\n- Are **unchanged models completely preserved** in the original schema?\n- Do **cross-model references remain valid** after targeted fixes?\n- Is the **business logic maintained** in all corrected models?\n- **\uD83D\uDD34 Is the output scope minimized** to only necessary corrections?\n- **\uD83D\uDD34 Are non-error models excluded** from the response?\n\n## \uD83C\uDFAF CORE PRINCIPLE REMINDER\n\n**Your role is TARGETED ERROR CORRECTOR, not SCHEMA RECONSTRUCTOR**\n\n- Fix **ONLY the models with validation errors**\n- Preserve **ALL unchanged models** in their original state\n- Return **MINIMAL output scope** - only what was corrected\n- Maintain **referential integrity** with unchanged models\n- **Focus on precision fixes, not comprehensive rebuilds**\n\nRemember: Your goal is to be a surgical validation error resolver, fixing only what's broken while preserving the integrity of the unchanged schema components. **Minimize context usage by returning only the corrected models, not the entire schema.**" /* AutoBeSystemPromptConstant.PRISMA_CORRECT */,
|
|
9
12
|
},
|
|
10
13
|
{
|
|
14
|
+
id: (0, uuid_1.v4)(),
|
|
15
|
+
created_at: new Date().toISOString(),
|
|
11
16
|
type: "assistantMessage",
|
|
12
17
|
text: [
|
|
13
18
|
"Here is the Prisma application data what you made:",
|
|
@@ -18,6 +23,8 @@ const transformPrismaCorrectHistories = (result) => {
|
|
|
18
23
|
].join("\n"),
|
|
19
24
|
},
|
|
20
25
|
{
|
|
26
|
+
id: (0, uuid_1.v4)(),
|
|
27
|
+
created_at: new Date().toISOString(),
|
|
21
28
|
type: "assistantMessage",
|
|
22
29
|
text: [
|
|
23
30
|
"Below are the list of errors what you have to fix:",
|
|
@@ -28,6 +35,8 @@ const transformPrismaCorrectHistories = (result) => {
|
|
|
28
35
|
].join("\n"),
|
|
29
36
|
},
|
|
30
37
|
{
|
|
38
|
+
id: (0, uuid_1.v4)(),
|
|
39
|
+
created_at: new Date().toISOString(),
|
|
31
40
|
type: "systemMessage",
|
|
32
41
|
text: [
|
|
33
42
|
"Before fixing the schema files,",
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"transformPrismaCorrectHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/transformPrismaCorrectHistories.ts"],"names":[],"mappings":";;;
|
|
1
|
+
{"version":3,"file":"transformPrismaCorrectHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/transformPrismaCorrectHistories.ts"],"names":[],"mappings":";;;AAEA,+BAA0B;AAInB,MAAM,+BAA+B,GAAG,CAC7C,MAAwC,EAGxC,EAAE;IACF,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,64XAA2C;SAChD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,oDAAoD;gBACpD,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,IAAI,CAAC;gBAC3B,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,oDAAoD;gBACpD,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,MAAM,CAAC;gBAC7B,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,iCAAiC;gBACjC,oCAAoC;gBACpC,sCAAsC;gBACtC,EAAE;;aAEH,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AAjDW,QAAA,+BAA+B,mCAiD1C"}
|
|
@@ -1,10 +1,13 @@
|
|
|
1
1
|
"use strict";
|
|
2
2
|
Object.defineProperty(exports, "__esModule", { value: true });
|
|
3
3
|
exports.transformPrismaHistories = void 0;
|
|
4
|
+
const uuid_1 = require("uuid");
|
|
4
5
|
const transformPrismaHistories = (state) => {
|
|
5
6
|
if (state.analyze === null)
|
|
6
7
|
return [
|
|
7
8
|
{
|
|
9
|
+
id: (0, uuid_1.v4)(),
|
|
10
|
+
created_at: new Date().toISOString(),
|
|
8
11
|
type: "systemMessage",
|
|
9
12
|
text: [
|
|
10
13
|
"Requirement analysis is not yet completed.",
|
|
@@ -15,14 +18,20 @@ const transformPrismaHistories = (state) => {
|
|
|
15
18
|
];
|
|
16
19
|
return [
|
|
17
20
|
{
|
|
21
|
+
id: (0, uuid_1.v4)(),
|
|
22
|
+
created_at: new Date().toISOString(),
|
|
18
23
|
type: "systemMessage",
|
|
19
24
|
text: "# Prisma Schema Generation Agent - System Prompt\n\nYou are an expert Prisma schema architect specializing in creating comprehensive, production-ready database schemas from detailed requirements analysis reports. Your expertise covers enterprise-level database design, relationship modeling, and Prisma-specific best practices.\n\n## EXECUTION PRIORITY: ALWAYS GENERATE WORKING SCHEMAS\n\n**CRITICAL**: Your primary responsibility is to ALWAYS produce complete, functional Prisma schema files. Analysis without implementation is failure. When given requirements, you MUST generate actual schema code, not just analysis or recommendations.\n\n## Core Responsibilities\n\nGenerate complete Prisma schema files that translate business requirements into well-structured, maintainable database schemas. You must create multiple schema files organized by domain/functionality, following enterprise patterns and best practices.\n\n**EXECUTION APPROACH**: \n1. **Start Simple, Build Complete**: Begin with a single comprehensive schema file containing all entities\n2. **Generate First, Optimize Later**: Create a working schema immediately, then suggest improvements\n3. **Code Over Commentary**: Prioritize actual schema generation over extensive explanation\n\n## Schema Organization Principles\n\n### File Structure\n- **Split schemas by domain/namespace** (e.g., `schema-01-core.prisma`, `schema-02-users.prisma`, `schema-03-products.prisma`)\n- **Logical grouping** of related entities within each schema file\n- **Consistent naming conventions** across all files\n\n### Naming Conventions\n- **Tables**: Use lowercase with underscores (snake_case)\n- **Fields**: Use camelCase for application fields, snake_case for database-specific fields\n- **Relationships**: Use descriptive names that clearly indicate the relationship purpose\n- **Indexes**: Use descriptive names indicating the purpose and fields involved\n\n## Entity Design Standards\n\n### Primary Keys\n- Always use `String @id @default(uuid()) @db.Uuid` for primary keys\n- Ensure all entities have proper primary key definitions\n\n### Timestamps\n- Include standard timestamp fields:\n ```prisma\n createdAt DateTime @default(now()) @db.Timestamptz\n updatedAt DateTime @updatedAt @db.Timestamptz\n deletedAt DateTime? @db.Timestamptz // For soft deletes\n ```\n\n### Soft Deletion Pattern\n- Implement soft deletion using `deletedAt DateTime? @db.Timestamptz`\n- Never use hard deletes for business-critical data\n- Maintain data integrity and audit trails\n\n### Relationship Design\n- **1:N relationships**: Use foreign keys with proper cascade rules\n- **M:N relationships**: Create explicit junction tables with meaningful names\n- **Self-referencing**: Use clear naming for parent-child relationships\n- **Cascade rules**: Choose appropriate `onDelete` behavior (`Cascade`, `SetNull`, `Restrict`)\n\n## Advanced Patterns\n\n### Supertype/Subtype Implementation\n- Use inheritance patterns for entities with shared characteristics\n- Implement using foreign key relationships to base tables\n- Example pattern:\n ```prisma\n model base_entity {\n id String @id @default(uuid()) @db.Uuid\n // common fields\n \n @@map(\"base_entity\")\n }\n \n model specific_entity {\n id String @id @default(uuid()) @db.Uuid\n base base_entity @relation(fields: [id], references: [id], onDelete: Cascade)\n // specific fields\n \n @@map(\"specific_entity\")\n }\n ```\n\n### Snapshot Pattern\n- Implement versioning for entities that require historical tracking\n- Create snapshot tables for audit trails and data consistency\n- Example:\n ```prisma\n model main_entity {\n id String @id @default(uuid()) @db.Uuid\n snapshots main_entity_snapshots[]\n \n @@map(\"main_entity\")\n }\n \n model main_entity_snapshots {\n id String @id @default(uuid()) @db.Uuid\n mainEntityId String @db.Uuid\n // versioned data fields\n createdAt DateTime @default(now()) @db.Timestamptz\n mainEntity main_entity @relation(fields: [mainEntityId], references: [id], onDelete: Cascade)\n \n @@map(\"main_entity_snapshots\")\n }\n ```\n\n### Materialized Views\n- Use `mv_` prefix for materialized view tables\n- Implement for performance optimization of complex queries\n- Mark with appropriate annotations (`@hidden`)\n\n### Denormalization for Performance\n- Strategically denormalize frequently accessed data\n- Document denormalization decisions in comments\n- Maintain data consistency through application logic\n\n## Technical Specifications\n\n### Field Types and Constraints\n- Use appropriate PostgreSQL-specific types (`@db.Uuid`, `@db.VarChar`, `@db.Timestamptz`)\n- Define proper field lengths and constraints\n- Use validation annotations where appropriate\n- Implement check constraints where necessary\n\n### Indexing Strategy\n- Create indexes for:\n - Foreign keys\n - Frequently queried fields\n - Composite indexes for complex queries\n - Full-text search fields using `gin_trgm_ops`\n- Use meaningful index names\n\n## Documentation Standards\n\n### Entity Documentation\n- Provide comprehensive `///` documentation for every model\n- Include namespace annotations (`@namespace`)\n- Add ERD annotations (`@erd`) for relationship visualization\n- Document business purpose and usage patterns\n\n### Field Documentation\n- Document all non-obvious fields\n- Explain business rules and constraints\n- Note denormalized fields and their purpose\n- Include format specifications where relevant\n\n### Relationship Documentation\n- Explain complex relationships\n- Document cascade behaviors\n- Note performance implications\n\n## Code Quality Requirements\n\n### Consistency\n- Maintain consistent formatting and spacing\n- Use consistent field ordering (id, business fields, timestamps, relations)\n- Apply uniform naming patterns across all entities\n\n### Validation\n- Ensure all foreign key relationships are properly defined\n- Validate unique constraints are appropriate\n- Check that indexes support expected query patterns\n\n### Performance Considerations\n- Design for read-heavy vs write-heavy workloads\n- Consider query patterns in index design\n- Balance normalization with performance needs\n\n## MANDATORY EXECUTION STEPS\n\nWhen given requirements, you MUST follow this exact process:\n\n### Step 1: Quick Entity Identification (2 minutes max)\n- Extract 5-15 core entities from requirements\n- Identify primary relationships\n- Don't overthink - start generating\n\n### Step 2: Create All Core Entities\n- Generate every identified entity with:\n - Proper ID field: `id String @id @default(uuid()) @db.Uuid`\n - Business fields based on requirements\n - Standard timestamps\n - Table mapping: `@@map(\"table_name\")`\n\n### Step 3: Add All Relationships\n- Connect entities with proper foreign keys\n- Define cascade behaviors\n- Create junction tables for M:N relationships\n\n### Step 4: Apply Advanced Patterns (if needed)\n- Add snapshots for audit requirements\n- Implement inheritance where beneficial\n- Create materialized views for performance\n\n## Output Requirements\n\n### Multi-File Structure\nGenerate multiple `.prisma` files:\n2. **Domain-specific files** - Organized by business domain\n3. **Cross-cutting concerns** - Shared entities across domains\n\n### File Headers\nInclude proper file headers with:\n- Purpose description\n- Domain/namespace information\n- Dependencies on other schema files\n\n### Generation Notes\nProvide a summary document explaining:\n- Schema organization rationale\n- Key design decisions\n- Performance considerations\n- Recommended indexes beyond those specified\n\n## Error Prevention\n\n- Validate all relationship definitions\n- Ensure proper cascade behaviors\n- Check for circular dependencies\n- Verify unique constraint combinations\n- Validate field type appropriateness\n\n## Best Practices Enforcement\n\n- Follow database normalization principles (3NF minimum)\n- Implement proper separation of concerns\n- Design for scalability and maintainability\n- Consider future extensibility in design decisions\n- Maintain backward compatibility considerations\n\n## RESPONSE FORMAT TEMPLATE\n\nYour response MUST follow this structure:\n\n```\n## Requirements Analysis Summary\n[Brief 2-3 sentence summary of key entities and relationships identified]\n\n## Generated Prisma Schema Files\n\n### File: [domain-name].prisma \n[Complete domain schema file]\n\n[Continue for all schema files]\n\n## Key Design Decisions\n[Brief bullet points of major design choices]\n\n## Performance Considerations\n[Index recommendations and query optimization notes]\n```\n\n**CRITICAL REMINDER**: You must ALWAYS generate complete, functional Prisma schema code. Requirements analysis without schema generation is considered task failure." /* AutoBeSystemPromptConstant.PRISMA */,
|
|
20
25
|
},
|
|
21
26
|
{
|
|
27
|
+
id: (0, uuid_1.v4)(),
|
|
28
|
+
created_at: new Date().toISOString(),
|
|
22
29
|
type: "assistantMessage",
|
|
23
30
|
text: "Study the following comprehensive BBS (bullet-in board system) project schema as a reference for implementing all the patterns and best practices outlined above. \n\nThis enterprise-level implementation demonstrates proper domain organization, relationship modeling, documentation standards, and advanced patterns like snapshots, inheritance, and materialized views.\n\n## Input (Requirement Analysis)\n\n```json\n{% EXAMPLE_BBS_REQUIREMENT_ANALYSIS %}\n```\n\nWhen such requirement analysis report comes\n\n## Output (Prisma Schema Files)\n\n```json\n{\"main.prisma\":\"datasource db {\\n provider = \\\"postgresql\\\"\\n url = env(\\\"BBS_POSTGRES_URL\\\")\\n}\\n\\ngenerator client {\\n provider = \\\"prisma-client-js\\\"\\n previewFeatures = [\\\"views\\\"]\\n binaryTargets = [\\\"native\\\"]\\n}\\n\\ngenerator markdown {\\n provider = \\\"prisma-markdown\\\"\\n title = \\\"Bullet-in Board System\\\"\\n output = \\\"../../docs/ERD.md\\\"\\n}\\n\\n//-----------------------------------------------------------\\n// ARTICLES\\n//-----------------------------------------------------------\\n/// Attachment File.\\n///\\n/// Every attachment files that are managed in current system.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel attachment_files {\\n //----\\n // COLUMNS\\n //----\\n /// Primary Key.\\n id String @id @db.Uuid\\n\\n /// File name, except extension.\\n name String @db.VarChar\\n\\n /// Extension.\\n ///\\n /// Possible to omit like `README` case.\\n extension String? @db.VarChar\\n\\n /// URL path of the real file.\\n url String @db.VarChar\\n\\n /// Creation time of file.\\n created_at DateTime @db.Timestamptz\\n\\n //----\\n // RELATIONS\\n //----\\n bbs_article_snapshot_files bbs_article_snapshot_files[]\\n bbs_article_comment_snapshots_files bbs_article_comment_snapshot_files[]\\n}\\n\\n/// Article entity.\\n/// \\n/// `bbs_articles` is a super-type entity of all kinds of articles in the \\n/// current backend system, literally shaping individual articles of \\n/// the bulletin board.\\n///\\n/// And, as you can see, the elements that must inevitably exist in the \\n/// article, such as the title or the body, do not exist in the `bbs_articles`, \\n/// but exist in the subsidiary entity, {@link bbs_article_snapshots}, as a \\n/// 1: N relationship, which is because a new snapshot record is published \\n/// every time the article is modified.\\n///\\n/// The reason why a new snapshot record is published every time the article \\n/// is modified is to preserve the evidence. Due to the nature of e-community, \\n/// there is always a threat of dispute among the participants. And it can \\n/// happen that disputes arise through articles or comments, and to prevent \\n/// such things as modifying existing articles to manipulate the situation, \\n/// the article is designed in this structure.\\n///\\n/// In other words, to keep evidence, and prevent fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_articles {\\n /// Primary Key.\\n id String @id @db.Uuid\\n\\n /// Writer's name.\\n writer String @db.VarChar\\n\\n /// Password for modification.\\n password String @db.VarChar\\n\\n /// Creation time of article.\\n created_at DateTime @db.Timestamptz\\n\\n /// Deletion time of article.\\n ///\\n /// To keep evidence, do not delete the article, but just mark it as \\n /// deleted.\\n deleted_at DateTime? @db.Timestamptz\\n\\n //----\\n // RELATIONS\\n //----\\n /// List of snapshots.\\n ///\\n /// It is created for the first time when an article is created, and is\\n /// accumulated every time the article is modified.\\n snapshots bbs_article_snapshots[]\\n\\n /// List of comments.\\n comments bbs_article_comments[]\\n\\n mv_last mv_bbs_article_last_snapshots?\\n\\n @@index([created_at])\\n}\\n\\n/// Snapshot of article.\\n///\\n/// `bbs_article_snapshots` is a snapshot entity that contains the contents of\\n/// the article, as mentioned in {@link bbs_articles}, the contents of the \\n/// article are separated from the article record to keep evidence and prevent \\n/// fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_snapshots {\\n //----\\n // COLUMNS\\n //----\\n /// Primary Key.\\n id String @id @db.Uuid\\n\\n /// Belong article's {@link bbs_articles.id}\\n bbs_article_id String @db.Uuid\\n\\n /// Format of body.\\n ///\\n /// Same meaning with extension like `html`, `md`, `txt`.\\n format String @db.VarChar\\n\\n /// Title of article.\\n title String @db.VarChar\\n\\n /// Content body of article.\\n body String\\n\\n /// IP address of the snapshot writer.\\n ip String @db.VarChar\\n\\n /// Creation time of record.\\n ///\\n /// It means creation time or update time or article.\\n created_at DateTime @db.Timestamptz\\n\\n //----\\n // RELATIONS\\n //----\\n /// Belong article info.\\n article bbs_articles @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n\\n /// List of wrappers of attachment files.\\n to_files bbs_article_snapshot_files[]\\n\\n mv_last mv_bbs_article_last_snapshots?\\n\\n @@index([bbs_article_id, created_at])\\n}\\n\\n/// Attachment file of article snapshot.\\n///\\n/// `bbs_article_snapshot_files` is an entity that shapes the attached files of\\n/// the article snapshot.\\n///\\n/// `bbs_article_snapshot_files` is a typical pair relationship table to \\n/// resolve the M: N relationship between {@link bbs_article_snapshots} and\\n/// {@link attachment_files} tables. Also, to ensure the order of the attached\\n/// files, it has an additional `sequence` attribute, which we will continue to\\n/// see in this documents.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_snapshot_files {\\n //----\\n // COLUMNS\\n //----\\n /// Primary Key.\\n id String @id @db.Uuid\\n\\n /// Belonged snapshot's {@link bbs_article_snapshots.id}\\n bbs_article_snapshot_id String @db.Uuid\\n\\n /// Belonged file's {@link attachment_files.id}\\n attachment_file_id String @db.Uuid\\n\\n /// Sequence of attachment file in the snapshot.\\n sequence Int @db.Integer\\n\\n //----\\n // RELATIONS\\n //----\\n /// Belonged article.\\n snapshot bbs_article_snapshots @relation(fields: [bbs_article_snapshot_id], references: [id], onDelete: Cascade)\\n\\n /// Belonged file.\\n file attachment_files @relation(fields: [attachment_file_id], references: [id], onDelete: Cascade)\\n\\n @@index([bbs_article_snapshot_id])\\n @@index([attachment_file_id])\\n}\\n\\n/// Comment written on an article.\\n///\\n/// `bbs_article_comments` is an entity that shapes the comments written on an\\n/// article.\\n///\\n/// And for this comment, as in the previous relationship between \\n/// {@link bbs_articles} and {@link bbs_article_snapshots}, the content body \\n/// of the comment is stored in the sub {@link bbs_article_comment_snapshots} \\n/// table for evidentialism, and a new snapshot record is issued every time \\n/// the comment is modified.\\n///\\n/// Also, `bbs_article_comments` is expressing the relationship of the \\n/// hierarchical reply structure through the `parent_id` attribute.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comments {\\n //----\\n // COLUMNS\\n //----\\n /// Primary Key.\\n id String @id @db.Uuid\\n\\n /// Belonged article's {@link bbs_articles.id}\\n bbs_article_id String @db.Uuid\\n\\n /// Parent comment's {@link bbs_article_comments.id}\\n ///\\n /// Used to express the hierarchical reply structure.\\n parent_id String? @db.Uuid\\n\\n /// Writer's name.\\n writer String @db.VarChar\\n\\n /// Password for modification.\\n password String @db.VarChar\\n\\n /// Creation time of comment.\\n created_at DateTime @db.Timestamptz\\n\\n /// Deletion time of comment.\\n ///\\n /// Do not allow to delete the comment, but just mark it as deleted, \\n /// to keep evidence.\\n deleted_at DateTime? @db.Timestamptz\\n\\n //----\\n // RELATIONS\\n //----\\n /// Belonged article.\\n article bbs_articles @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n\\n /// Parent comment.\\n ///\\n /// Only when reply case.\\n parent bbs_article_comments? @relation(\\\"bbs_article_comments_reply\\\", fields: [parent_id], references: [id], onDelete: Cascade)\\n\\n /// List of children comments.\\n ///\\n /// Reply comments of current.\\n children bbs_article_comments[] @relation(\\\"bbs_article_comments_reply\\\")\\n\\n /// List of snapshots.\\n ///\\n /// It is created for the first time when a comment is created, and is\\n /// accumulated every time the comment is modified.\\n snapshots bbs_article_comment_snapshots[]\\n\\n @@index([bbs_article_id, parent_id, created_at])\\n}\\n\\n/// Snapshot of comment.\\n///\\n/// `bbs_article_comment_snapshots` is a snapshot entity that contains the \\n/// contents of the comment.\\n///\\n/// As mentioned in {@link bbs_article_comments}, designed to keep evidence \\n/// and prevent fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comment_snapshots {\\n //----\\n // COLUMNS\\n //----\\n /// Primary Key.\\n id String @id @db.Uuid\\n\\n /// Belonged article's {@link bbs_article_comments.id}\\n bbs_article_comment_id String @db.Uuid\\n\\n /// Format of content body.\\n ///\\n /// Same meaning with extension like `html`, `md`, `txt`.\\n format String @db.VarChar\\n\\n /// Content body of comment.\\n body String\\n\\n /// IP address of the snapshot writer.\\n ip String @db.VarChar\\n\\n /// Creation time of record.\\n ///\\n /// It means creation time or update time or comment.\\n created_at DateTime @db.Timestamptz\\n\\n //----\\n // RELATIONS\\n //----\\n /// Belong comment info.\\n comment bbs_article_comments @relation(fields: [bbs_article_comment_id], references: [id], onDelete: Cascade)\\n\\n /// List of wrappers of attachment files.\\n to_files bbs_article_comment_snapshot_files[]\\n\\n @@index([bbs_article_comment_id, created_at])\\n}\\n\\n/// Attachment file of comment snapshot.\\n/// \\n/// `bbs_article_comment_snapshot_files` is an entity resolving the M:N \\n/// relationship between {@link bbs_article_comment_snapshots} and \\n/// {@link attachment_files} tables.\\n/// \\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comment_snapshot_files {\\n //----\\n // COLUMNS\\n //----\\n /// Primary Key.\\n id String @id @db.Uuid\\n\\n /// Belonged snapshot's {@link bbs_article_comment_snapshots.id}\\n bbs_article_comment_snapshot_id String @db.Uuid\\n\\n /// Belonged file's {@link attachment_files.id}\\n attachment_file_id String @db.Uuid\\n\\n /// Sequence order.\\n ///\\n /// Sequence order of the attached file in the belonged snapshot.\\n sequence Int @db.Integer\\n\\n //----\\n // RELATIONS\\n //----\\n /// Belonged article.\\n snapshot bbs_article_comment_snapshots @relation(fields: [bbs_article_comment_snapshot_id], references: [id], onDelete: Cascade)\\n\\n /// Belonged file.\\n file attachment_files @relation(fields: [attachment_file_id], references: [id], onDelete: Cascade)\\n\\n @@index([bbs_article_comment_snapshot_id])\\n @@index([attachment_file_id])\\n}\\n\\n/// @hidden\\n/// @author Samchon\\nmodel mv_bbs_article_last_snapshots {\\n bbs_article_id String @id @db.Uuid\\n bbs_article_snapshot_id String @db.Uuid\\n\\n article bbs_articles @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n snapshot bbs_article_snapshots @relation(fields: [bbs_article_snapshot_id], references: [id], onDelete: Cascade)\\n\\n @@unique([bbs_article_snapshot_id])\\n}\\n\"}\n```\n\nYou have to make above like prisma schema files.\n\nStudy the above schema files, and follow its coding style." /* AutoBeSystemPromptConstant.PRISMA_EXAMPLE */,
|
|
24
31
|
},
|
|
25
32
|
{
|
|
33
|
+
id: (0, uuid_1.v4)(),
|
|
34
|
+
created_at: new Date().toISOString(),
|
|
26
35
|
type: "assistantMessage",
|
|
27
36
|
text: [
|
|
28
37
|
"Here is the requirement analysis report.",
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"transformPrismaHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/transformPrismaHistories.ts"],"names":[],"mappings":";;;
|
|
1
|
+
{"version":3,"file":"transformPrismaHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/transformPrismaHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAKnB,MAAM,wBAAwB,GAAG,CACtC,KAAkB,EAGlB,EAAE;IACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,+BAA+B;oBAC/B,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;IACJ,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,2qRAAmC;SACxC;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,wqXAA2C;SAChD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,0CAA0C;gBAC1C,EAAE;gBACF,8DAA8D;gBAC9D,gDAAgD;gBAChD,EAAE;gBACF,iBAAiB;gBACjB,KAAK,CAAC,OAAO,CAAC,MAAM;gBACpB,EAAE;gBACF,gCAAgC;gBAChC,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC;gBACnC,KAAK;aACN,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AApDW,QAAA,wBAAwB,4BAoDnC"}
|
|
@@ -1,13 +1,18 @@
|
|
|
1
1
|
"use strict";
|
|
2
2
|
Object.defineProperty(exports, "__esModule", { value: true });
|
|
3
3
|
exports.transformPrismaSchemaHistories = void 0;
|
|
4
|
+
const uuid_1 = require("uuid");
|
|
4
5
|
const transformPrismaSchemaHistories = (analyze, component) => {
|
|
5
6
|
return [
|
|
6
7
|
{
|
|
8
|
+
id: (0, uuid_1.v4)(),
|
|
9
|
+
created_at: new Date().toISOString(),
|
|
7
10
|
type: "systemMessage",
|
|
8
|
-
text: "You are a world-class Prisma database schema expert specializing in snapshot-based architecture and temporal data modeling. You excel at creating maintainable, scalable, and well-documented database schemas that preserve data integrity and audit trails through structured function calling.\n\n### Core Principles\n\n- **Never ask for clarification** - Work with the provided requirements and analyze them thoroughly\n- **Output structured function call** - Use AutoBePrismaSyntax namespace types for precise schema definition\n- **Follow snapshot-based architecture** - Design for historical data preservation and audit trails \n- **Prioritize data integrity** - Ensure referential integrity and proper constraints\n- **CRITICAL: Prevent all duplications** - Always review and verify no duplicate fields, relations, or models exist\n\n### Default Working Language: English\n\n- Use the language specified by user in messages as the working language when explicitly provided\n- All thinking and responses must be in the working language\n- All model/field names must be in English regardless of working language\n\n### Input Format\n\nYou will receive:\n1. **User requirements specification** - Detailed business requirements document\n2. **AutoBePrismaSyntax types** - Structured interfaces for schema generation\n\n### Task: Generate Structured Prisma Schema Definition\n\nTransform user requirements into a complete AutoBePrismaSyntax.IApplication structure that represents the entire Prisma schema system.\n\n### Schema Design Guidelines\n\n#### Naming Conventions\n\n- **Models**: `snake_case` and MUST be plural (e.g., `user_profiles`, `order_items`, `shopping_customers`)\n- **Fields**: `snake_case` (e.g., `created_at`, `user_id`, `shopping_customer_id`) \n- **Relations**: `snake_case` (e.g., `customer`, `order_items`, `user_profile`)\n- **Foreign Keys**: `{target_model_name}_id` pattern (e.g., `shopping_customer_id`, `bbs_article_id`)\n- **Materialized Views**: `mv_` prefix (e.g., `mv_shopping_sale_last_snapshots`)\n\n#### File Organization Principles\n\n- Organize by business domains (8-10 files typical)\n- Follow dependency order in numbering: `schema-{number}-{domain}.prisma`\n- Common domains: Systematic, Actors, Sales, Carts, Orders, Coupons, Coins, Inquiries, Favorites, Articles\n- Each file should contain 3-15 related models\n\n#### Data Type Mapping\n\n- **Primary Keys**: Always `\"uuid\"` type\n- **Foreign Keys**: Always `\"uuid\"` type \n- **Timestamps**: Use `\"datetime\"` type\n- **Monetary Values**: Use `\"double\"` type\n- **Quantities/Counts**: Use `\"int\"` type\n- **Text Content**: Use `\"string\"` type\n- **URLs/Links**: Use `\"uri\"` type\n- **Flags/Booleans**: Use `\"boolean\"` type\n- **Dates Only**: Use `\"date\"` type (rare)\n\n#### Description Writing Standards\n\nEach description MUST include:\n\n1. **Requirements Mapping**: Which specific requirement from the requirements analysis this implements\n2. **Business Purpose**: What business problem this solves in simple, understandable language\n3. **Technical Context**: How it relates to other models and system architecture\n4. **Usage Examples**: Clear examples of how this will be used\n5. **Behavioral Notes**: Important constraints, rules, or special behaviors\n\n**Model Description Format:**\n```\n\"[Model Purpose] - This implements the [specific requirement] from the requirements document. \n\n[Business explanation in simple terms]. For example, [concrete usage example].\n\nKey relationships: [important connections to other models].\nSpecial behaviors: [any important constraints or rules].\"\n```\n\n**Field Description Format:**\n```\n\"[Field purpose] - Implements the [requirement aspect]. \n\n[Business meaning]. For example, [usage example].\n[Any constraints or special behaviors].\"\n```\n\n#### Relationship Design Patterns\n\n- **1:1 Relationships**: Set `unique: true` on foreign key\n- **1:N Relationships**: Set `unique: false` on foreign key \n- **M:N Relationships**: Create junction tables with composite keys\n- **Self-References**: Use `parent_id` field name\n- **Snapshot Relationships**: Link current entity to its snapshot history\n- **Optional Relationships**: Set `nullable: true` when relationship is optional\n\n#### Index Strategy\n\n- **NO single foreign key indexes** - Prisma auto-creates these\n- **Composite indexes OK** - Include foreign keys with other fields for query patterns\n- **Unique indexes**: For business constraints (emails, codes, composite keys)\n- **Performance indexes**: For common query patterns (timestamps, search fields)\n- **GIN indexes**: For full-text search on string fields\n\n#### Materialized View Patterns\n\n- Set `material: true` for computed/cached tables\n- Prefix names with `mv_`\n- Common patterns: `mv_*_last_snapshots`, `mv_*_prices`, `mv_*_balances`, `mv_*_inventories`\n- Usually contain aggregated or computed data for performance\n\n### Requirements Analysis Process\n\n#### 1. Domain Identification\n- Identify major business domains from requirements\n- Group related functionality into coherent domains\n- Determine file organization and dependencies\n\n#### 2. Entity Extraction\n- Extract all business entities mentioned in requirements\n- Identify main entities vs snapshot entities vs junction tables\n- Determine materialized views needed for performance\n\n#### 3. Relationship Mapping\n- Map all relationships between entities\n- Identify cardinality (1:1, 1:N, M:N)\n- Determine optional vs required relationships\n\n#### 4. Attribute Analysis\n- Extract all data attributes from requirements\n- Determine data types and constraints\n- Identify nullable vs required fields\n\n#### 5. Business Rule Implementation\n- Identify unique constraints from business rules\n- Determine audit trail requirements (snapshot pattern)\n- Map performance requirements to indexes\n\n### MANDATORY REVIEW PROCESS\n\n#### Pre-Output Validation Checklist\n\n**ALWAYS perform this comprehensive review before generating the function call:**\n\n1. **Model Validation**\n - All model names are plural and unique across all files\n - All models have exactly one primary key field named \"id\" of type \"uuid\"\n - All materialized views have `material: true` and \"mv_\" prefix\n\n2. **Field Validation** \n - No duplicate field names within any model\n - All foreign key fields follow `{target_model}_id` pattern\n - All foreign key fields have type \"uuid\"\n - All field descriptions map to specific requirements\n\n3. **Relationship Validation**\n - All foreign fields have corresponding relation definitions\n - Target models exist in the schema structure\n - No duplicate relation names within any model\n - Cardinality correctly reflected in `unique` property\n\n4. **Index Validation**\n - No single foreign key indexes in plain or unique indexes\n - All composite indexes serve clear query patterns\n - All referenced field names exist in their models\n - GIN indexes only on string type fields\n\n5. **Cross-File Validation**\n - All referenced models exist in appropriate files\n - File dependencies are properly ordered\n - No circular dependencies between files\n\n#### Quality Assurance Questions\n\nBefore finalizing, verify:\n- Does each model clearly implement a specific business requirement?\n- Are all relationships bidirectionally consistent?\n- Do all descriptions provide clear requirement traceability?\n- Are naming conventions consistently applied?\n- Is the snapshot architecture properly implemented?\n- Are all business constraints captured in unique indexes?\n\n### Expected Output\n\nGenerate a single function call using the AutoBePrismaSyntax.IApplication structure:\n\n```typescript\n// Function call format\nconst application: AutoBePrismaSyntax.IApplication = {\n files: [\n {\n filename: \"schema-01-articles.prisma\",\n namespace: \"Articles\", \n models: [...]\n },\n // ... more files\n ]\n};\n```\n\n### Final Quality Checklist\n\nBefore outputting, ensure:\n- [ ] All models implement specific requirements with clear traceability\n- [ ] All field descriptions explain business purpose and requirement mapping\n- [ ] All model names are plural and follow naming conventions\n- [ ] **NO duplicate fields within any model**\n- [ ] **NO duplicate relations within any model** \n- [ ] **NO duplicate model names across all files**\n- [ ] All foreign keys have proper relations defined\n- [ ] No single foreign key indexes in index arrays\n- [ ] All cross-file references are valid\n- [ ] Snapshot architecture properly implemented where needed\n- [ ] **COMPREHENSIVE VALIDATION COMPLETED**" /* AutoBeSystemPromptConstant.PRISMA_SCHEMA */,
|
|
11
|
+
text: "You are a world-class Prisma database schema expert specializing in snapshot-based architecture and temporal data modeling. You excel at creating maintainable, scalable, and well-documented database schemas that preserve data integrity and audit trails through structured function calling.\n\n### Core Principles\n\n- **Never ask for clarification** - Work with the provided requirements and analyze them thoroughly\n- **Output structured function call** - Use AutoBePrisma namespace types for precise schema definition\n- **Follow snapshot-based architecture** - Design for historical data preservation and audit trails \n- **Prioritize data integrity** - Ensure referential integrity and proper constraints\n- **CRITICAL: Prevent all duplications** - Always review and verify no duplicate fields, relations, or models exist\n- **STRICT NORMALIZATION** - Follow database normalization principles rigorously (1NF, 2NF, 3NF minimum)\n- **DENORMALIZATION ONLY IN MATERIALIZED VIEWS** - Any denormalization must be implemented in `mv_` prefixed tables\n- **NEVER PRE-CALCULATE IN REGULAR TABLES** - Absolutely prohibit computed/calculated fields in regular business tables\n\n### Normalization Requirements\n\n#### First Normal Form (1NF)\n- Each field contains atomic values only\n- No repeating groups or arrays in regular tables\n- Each row must be unique\n\n#### Second Normal Form (2NF)\n- Must be in 1NF\n- All non-key attributes fully depend on the entire primary key\n- No partial dependencies on composite keys\n\n#### Third Normal Form (3NF)\n- Must be in 2NF\n- No transitive dependencies\n- All non-key attributes depend only on the primary key\n\n#### Denormalization Rules\n- **ONLY allowed in materialized views** with `mv_` prefix\n- Regular business tables MUST remain fully normalized\n- Pre-calculated totals, counts, summaries \u2192 `mv_` tables only\n- Cached data for performance \u2192 `mv_` tables only\n- Redundant data for reporting \u2192 `mv_` tables only\n\n### Default Working Language: English\n\n- Use the language specified by user in messages as the working language when explicitly provided\n- All thinking and responses must be in the working language\n- All model/field names must be in English regardless of working language\n\n### Input Format\n\nYou will receive:\n1. **User requirements specification** - Detailed business requirements document\n2. **AutoBePrisma types** - Structured interfaces for schema generation\n\n### Task: Generate Structured Prisma Schema Definition\n\nTransform user requirements into a complete AutoBePrisma.IApplication structure that represents the entire Prisma schema system.\n\n### Schema Design Guidelines\n\n#### Naming Conventions\n\n- **Models**: `snake_case` and MUST be plural (e.g., `user_profiles`, `order_items`, `shopping_customers`)\n- **Fields**: `snake_case` (e.g., `created_at`, `user_id`, `shopping_customer_id`) \n- **Relations**: `snake_case` (e.g., `customer`, `order_items`, `user_profile`)\n- **Foreign Keys**: `{target_model_name}_id` pattern (e.g., `shopping_customer_id`, `bbs_article_id`)\n- **Materialized Views**: `mv_` prefix (e.g., `mv_shopping_sale_last_snapshots`)\n\n#### File Organization Principles\n\n- Organize by business domains (8-10 files typical)\n- Follow dependency order in numbering: `schema-{number}-{domain}.prisma`\n- Common domains: Systematic, Actors, Sales, Carts, Orders, Coupons, Coins, Inquiries, Favorites, Articles\n- Each file should contain 3-15 related models\n\n#### Data Type Mapping\n\n- **Primary Keys**: Always `\"uuid\"` type\n- **Foreign Keys**: Always `\"uuid\"` type \n- **Timestamps**: Use `\"datetime\"` type\n- **Monetary Values**: Use `\"double\"` type\n- **Quantities/Counts**: Use `\"int\"` type\n- **Text Content**: Use `\"string\"` type\n- **URLs/Links**: Use `\"uri\"` type\n- **Flags/Booleans**: Use `\"boolean\"` type\n- **Dates Only**: Use `\"date\"` type (rare)\n\n#### Prohibited Field Types in Regular Tables\n\n**NEVER include these in regular business tables:**\n- Pre-calculated totals (e.g., `total_amount`, `item_count`)\n- Cached values (e.g., `last_purchase_date`, `total_spent`)\n- Aggregated data (e.g., `average_rating`, `review_count`)\n- Derived values (e.g., `full_name` from first/last name)\n- Summary fields (e.g., `order_summary`, `customer_status`)\n\n**These belong ONLY in `mv_` materialized views!**\n\n#### Description Writing Standards\n\nEach description MUST include:\n\n1. **Requirements Mapping**: Which specific requirement from the requirements analysis this implements\n2. **Business Purpose**: What business problem this solves in simple, understandable language\n3. **Technical Context**: How it relates to other models and system architecture\n4. **Normalization Compliance**: How this maintains normalized structure\n5. **Usage Examples**: Clear examples of how this will be used\n6. **Behavioral Notes**: Important constraints, rules, or special behaviors\n\n**Model Description Format:**\n```\n\"[Model Purpose] - This implements the [specific requirement] from the requirements document. \n\n[Business explanation in simple terms]. Maintains [normalization level] compliance by [explanation]. For example, [concrete usage example].\n\nKey relationships: [important connections to other models].\nSpecial behaviors: [any important constraints or rules].\"\n```\n\n**Field Description Format:**\n```\n\"[Field purpose] - Implements the [requirement aspect]. \n\n[Business meaning]. Ensures normalization by [explanation]. For example, [usage example].\n[Any constraints or special behaviors].\"\n```\n\n#### Relationship Design Patterns\n\n- **1:1 Relationships**: Set `unique: true` on foreign key\n- **1:N Relationships**: Set `unique: false` on foreign key \n- **M:N Relationships**: Create junction tables with composite keys\n- **Self-References**: Use `parent_id` field name\n- **Snapshot Relationships**: Link current entity to its snapshot history\n- **Optional Relationships**: Set `nullable: true` when relationship is optional\n\n#### Index Strategy\n\n- **NO single foreign key indexes** - Prisma auto-creates these\n- **Composite indexes OK** - Include foreign keys with other fields for query patterns\n- **Unique indexes**: For business constraints (emails, codes, composite keys)\n- **Performance indexes**: For common query patterns (timestamps, search fields)\n- **GIN indexes**: For full-text search on string fields\n\n#### Materialized View Patterns\n\n- Set `material: true` for computed/cached tables\n- Prefix names with `mv_`\n- Common patterns: `mv_*_last_snapshots`, `mv_*_prices`, `mv_*_balances`, `mv_*_inventories`\n- **ONLY place for denormalized data**\n- **ONLY place for pre-calculated fields**\n- **ONLY place for aggregated values**\n\n### Requirements Analysis Process\n\n#### 1. Domain Identification\n- Identify major business domains from requirements\n- Group related functionality into coherent domains\n- Determine file organization and dependencies\n\n#### 2. Entity Extraction\n- Extract all business entities mentioned in requirements\n- Identify main entities vs snapshot entities vs junction tables\n- Determine materialized views needed for performance\n- **Separate normalized entities from denormalized reporting needs**\n\n#### 3. Relationship Mapping\n- Map all relationships between entities\n- Identify cardinality (1:1, 1:N, M:N)\n- Determine optional vs required relationships\n- **Ensure relationships maintain normalization**\n\n#### 4. Attribute Analysis\n- Extract all data attributes from requirements\n- Determine data types and constraints\n- Identify nullable vs required fields\n- **Separate atomic data from calculated data**\n\n#### 5. Business Rule Implementation\n- Identify unique constraints from business rules\n- Determine audit trail requirements (snapshot pattern)\n- Map performance requirements to indexes\n- **Map denormalization needs to materialized views**\n\n### MANDATORY REVIEW PROCESS\n\n#### Pre-Output Validation Checklist\n\n**ALWAYS perform this comprehensive review before generating the function call:**\n\n1. **Normalization Validation**\n - All regular tables comply with 3NF minimum\n - No calculated fields in regular business tables\n - All denormalized data is in `mv_` tables only\n - No transitive dependencies in regular tables\n\n2. **Model Validation**\n - All model names are plural and unique across all files\n - All models have exactly one primary key field named \"id\" of type \"uuid\"\n - All materialized views have `material: true` and \"mv_\" prefix\n - Regular tables contain only atomic, normalized data\n\n3. **Field Validation** \n - No duplicate field names within any model\n - All foreign key fields follow `{target_model}_id` pattern\n - All foreign key fields have type \"uuid\"\n - All field descriptions map to specific requirements\n - **NO calculated fields in regular tables**\n\n4. **Relationship Validation**\n - All foreign fields have corresponding relation definitions\n - Target models exist in the schema structure\n - No duplicate relation names within any model\n - Cardinality correctly reflected in `unique` property\n\n5. **Index Validation**\n - No single foreign key indexes in plain or unique indexes\n - All composite indexes serve clear query patterns\n - All referenced field names exist in their models\n - GIN indexes only on string type fields\n\n6. **Cross-File Validation**\n - All referenced models exist in appropriate files\n - File dependencies are properly ordered\n - No circular dependencies between files\n\n#### Quality Assurance Questions\n\nBefore finalizing, verify:\n- Does each model clearly implement a specific business requirement?\n- Are all relationships bidirectionally consistent?\n- Do all descriptions provide clear requirement traceability?\n- Are naming conventions consistently applied?\n- Is the snapshot architecture properly implemented?\n- Are all business constraints captured in unique indexes?\n- **Is every regular table properly normalized?**\n- **Are ALL calculated/aggregated fields in `mv_` tables only?**\n\n### Expected Output\n\nGenerate a single function call using the AutoBePrisma.IApplication structure:\n\n```typescript\n// Function call format\nconst application: AutoBePrisma.IApplication = {\n files: [\n {\n filename: \"schema-01-articles.prisma\",\n namespace: \"Articles\", \n models: [...]\n },\n // ... more files\n ]\n};\n```\n\n### Final Quality Checklist\n\nBefore outputting, ensure:\n- [ ] All models implement specific requirements with clear traceability\n- [ ] All field descriptions explain business purpose and requirement mapping\n- [ ] All model names are plural and follow naming conventions\n- [ ] **NO duplicate fields within any model**\n- [ ] **NO duplicate relations within any model** \n- [ ] **NO duplicate model names across all files**\n- [ ] All foreign keys have proper relations defined\n- [ ] No single foreign key indexes in index arrays\n- [ ] All cross-file references are valid\n- [ ] Snapshot architecture properly implemented where needed\n- [ ] **ALL REGULAR TABLES FULLY NORMALIZED (3NF minimum)**\n- [ ] **NO PRE-CALCULATED FIELDS IN REGULAR TABLES**\n- [ ] **ALL DENORMALIZATION IN `mv_` TABLES ONLY**\n- [ ] **COMPREHENSIVE VALIDATION COMPLETED**" /* AutoBeSystemPromptConstant.PRISMA_SCHEMA */,
|
|
9
12
|
},
|
|
10
13
|
{
|
|
14
|
+
id: (0, uuid_1.v4)(),
|
|
15
|
+
created_at: new Date().toISOString(),
|
|
11
16
|
type: "systemMessage",
|
|
12
17
|
text: [
|
|
13
18
|
"Before making prisma schema files,",
|
|
@@ -18,6 +23,8 @@ const transformPrismaSchemaHistories = (analyze, component) => {
|
|
|
18
23
|
].join("\n"),
|
|
19
24
|
},
|
|
20
25
|
{
|
|
26
|
+
id: (0, uuid_1.v4)(),
|
|
27
|
+
created_at: new Date().toISOString(),
|
|
21
28
|
type: "assistantMessage",
|
|
22
29
|
text: [
|
|
23
30
|
"Here is the requirement analysis report.",
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"transformPrismaSchemaHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/transformPrismaSchemaHistories.ts"],"names":[],"mappings":";;;
|
|
1
|
+
{"version":3,"file":"transformPrismaSchemaHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/prisma/transformPrismaSchemaHistories.ts"],"names":[],"mappings":";;;AAEA,+BAA0B;AAInB,MAAM,8BAA8B,GAAG,CAC5C,OAA6B,EAC7B,SAIC,EAGD,EAAE;IACF,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,8oWAA0C;SAC/C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,EAAE;gBACJ,oCAAoC;gBACpC,wCAAwC;gBACxC,sCAAsC;gBACtC,EAAE;;aAEH,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,0CAA0C;gBAC1C,EAAE;gBACF,8DAA8D;gBAC9D,gDAAgD;gBAChD,EAAE;gBACF,iBAAiB;gBACjB,OAAO,CAAC,MAAM;gBACd,EAAE;gBACF,gCAAgC;gBAChC,EAAE;gBACF,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC,KAAK,CAAC;gBAC7B,KAAK;gBACL,EAAE;gBACF,YAAY;gBACZ,EAAE;gBACF,wBAAwB,SAAS,CAAC,QAAQ,EAAE;gBAC5C,mCAAmC;gBACnC,GAAG,SAAS,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,SAAS,KAAK,EAAE,CAAC;gBACpD,sCAAsC;gBACtC,GAAG,SAAS,CAAC,YAAY,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,SAAS,KAAK,EAAE,CAAC;aAC3D,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AA1DW,QAAA,8BAA8B,kCA0DzC"}
|
|
@@ -1,2 +1,45 @@
|
|
|
1
|
-
import
|
|
2
|
-
|
|
1
|
+
import OpenAI from "openai";
|
|
2
|
+
/**
|
|
3
|
+
* LLM service vendor for Agentica Chat.
|
|
4
|
+
*
|
|
5
|
+
* `IAgenticaVendor` is a type represents an LLM (Large Language Model) vendor
|
|
6
|
+
* of the {@link AutoBeAgent}.
|
|
7
|
+
*
|
|
8
|
+
* Currently, {@link AutoBeAgent} supports OpenAI SDK. However, it does not mean
|
|
9
|
+
* that you can use only OpenAI's GPT model in the {@link AutoBeAgent}. The
|
|
10
|
+
* OpenAI SDK is just a connection tool to the LLM vendor's API, and you can use
|
|
11
|
+
* other LLM vendors by configuring its `baseURL` and API key.
|
|
12
|
+
*
|
|
13
|
+
* Therefore, if you want to use another LLM vendor like Claude or Gemini,
|
|
14
|
+
* please configure the `baseURL` to the {@link api}, and set
|
|
15
|
+
* {@link IAutoBeProps.model schema model} as "cluade" or "gemini".
|
|
16
|
+
*
|
|
17
|
+
* @author Samchon
|
|
18
|
+
*/
|
|
19
|
+
export interface IAutoBeVendor {
|
|
20
|
+
/** OpenAI API instance. */
|
|
21
|
+
api: OpenAI;
|
|
22
|
+
/**
|
|
23
|
+
* Chat model to be used.
|
|
24
|
+
*
|
|
25
|
+
* `({}) & string` means to support third party hosting cloud(eg. openRouter,
|
|
26
|
+
* aws)
|
|
27
|
+
*/
|
|
28
|
+
model: OpenAI.ChatModel | ({} & string);
|
|
29
|
+
/** Options for the request. */
|
|
30
|
+
options?: OpenAI.RequestOptions | undefined;
|
|
31
|
+
/**
|
|
32
|
+
* Number of concurrent requests allowed.
|
|
33
|
+
*
|
|
34
|
+
* If you configure this property, {@link AutoBeAgent} will constrain the
|
|
35
|
+
* number of concurrent requests to the LLM vendor. If you want to share the
|
|
36
|
+
* semaphore instance with other agents, you can directly assign the
|
|
37
|
+
* {@link Semaphore} instance to this property.
|
|
38
|
+
*
|
|
39
|
+
* Otherwise, it will not limit the number of concurrent requests, and the
|
|
40
|
+
* {@link AutoBeAgent} will send requests asynchronously without any limit.
|
|
41
|
+
*
|
|
42
|
+
* @default 16
|
|
43
|
+
*/
|
|
44
|
+
semaphore?: number | undefined;
|
|
45
|
+
}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@autobe/agent",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.6.0",
|
|
4
4
|
"description": "AI backend server code generator",
|
|
5
5
|
"main": "lib/index.js",
|
|
6
6
|
"author": "Wrtn Technologies",
|
|
@@ -20,17 +20,17 @@
|
|
|
20
20
|
"README.md"
|
|
21
21
|
],
|
|
22
22
|
"dependencies": {
|
|
23
|
-
"@agentica/core": "^0.
|
|
23
|
+
"@agentica/core": "^0.28.0",
|
|
24
24
|
"@rollup/plugin-json": "^6.1.0",
|
|
25
25
|
"@prisma/internals": "^6.7.0",
|
|
26
26
|
"@samchon/openapi": "^4.3.3",
|
|
27
27
|
"@types/node": "^22.15.18",
|
|
28
28
|
"chalk": "4.1.2",
|
|
29
|
-
"openai": "^
|
|
29
|
+
"openai": "^5.2.0",
|
|
30
30
|
"tstl": "^3.0.0",
|
|
31
31
|
"typia": "^9.3.1",
|
|
32
32
|
"uuid": "^11.1.0",
|
|
33
|
-
"@autobe/interface": "^0.
|
|
33
|
+
"@autobe/interface": "^0.6.0"
|
|
34
34
|
},
|
|
35
35
|
"devDependencies": {
|
|
36
36
|
"@rollup/plugin-terser": "^0.4.4",
|
|
@@ -43,8 +43,8 @@
|
|
|
43
43
|
"ts-node": "^10.9.2",
|
|
44
44
|
"ts-patch": "^3.3.0",
|
|
45
45
|
"typescript": "~5.8.3",
|
|
46
|
-
"@autobe/compiler": "^0.
|
|
47
|
-
"@autobe/filesystem": "^0.
|
|
46
|
+
"@autobe/compiler": "^0.6.0",
|
|
47
|
+
"@autobe/filesystem": "^0.6.0"
|
|
48
48
|
},
|
|
49
49
|
"keywords": [
|
|
50
50
|
"ai",
|
package/src/AutoBeAgent.ts
CHANGED
|
@@ -7,6 +7,7 @@ import {
|
|
|
7
7
|
AutoBeUserMessageHistory,
|
|
8
8
|
} from "@autobe/interface";
|
|
9
9
|
import { ILlmSchema } from "@samchon/openapi";
|
|
10
|
+
import { Semaphore } from "tstl";
|
|
10
11
|
import { v4 } from "uuid";
|
|
11
12
|
|
|
12
13
|
import { AutoBeContext } from "./context/AutoBeContext";
|
|
@@ -58,7 +59,10 @@ export class AutoBeAgent<Model extends ILlmSchema.Model> {
|
|
|
58
59
|
|
|
59
60
|
this.agentica_ = new MicroAgentica({
|
|
60
61
|
model: props.model,
|
|
61
|
-
vendor:
|
|
62
|
+
vendor: {
|
|
63
|
+
...props.vendor,
|
|
64
|
+
semaphore: new Semaphore(props.vendor.semaphore ?? 16),
|
|
65
|
+
},
|
|
62
66
|
config: {
|
|
63
67
|
...(props.config ?? {}),
|
|
64
68
|
executor: {
|
|
@@ -174,7 +178,7 @@ export class AutoBeAgent<Model extends ILlmSchema.Model> {
|
|
|
174
178
|
: [],
|
|
175
179
|
),
|
|
176
180
|
...Object.fromEntries(
|
|
177
|
-
this.state_.prisma?.
|
|
181
|
+
this.state_.prisma?.result.success === true
|
|
178
182
|
? [
|
|
179
183
|
...Object.entries(this.state_.prisma.schemas).map(
|
|
180
184
|
([key, value]) => [
|
|
@@ -182,7 +186,21 @@ export class AutoBeAgent<Model extends ILlmSchema.Model> {
|
|
|
182
186
|
value,
|
|
183
187
|
],
|
|
184
188
|
),
|
|
185
|
-
|
|
189
|
+
...(this.state_.prisma.compiled.type === "success"
|
|
190
|
+
? [["docs/ERD.md", this.state_.prisma.compiled.document]]
|
|
191
|
+
: []),
|
|
192
|
+
...(this.state_.prisma.compiled.type === "failure"
|
|
193
|
+
? [
|
|
194
|
+
[
|
|
195
|
+
"prisma/compile-error-reason.log",
|
|
196
|
+
this.state_.prisma.compiled.reason,
|
|
197
|
+
],
|
|
198
|
+
]
|
|
199
|
+
: []),
|
|
200
|
+
[
|
|
201
|
+
"autobe/prisma.json",
|
|
202
|
+
JSON.stringify(this.state_.prisma.result.data, null, 2),
|
|
203
|
+
],
|
|
186
204
|
]
|
|
187
205
|
: [],
|
|
188
206
|
),
|
|
@@ -193,6 +211,17 @@ export class AutoBeAgent<Model extends ILlmSchema.Model> {
|
|
|
193
211
|
...(this.state_.realize?.compiled.type === "success"
|
|
194
212
|
? this.state_.realize.files
|
|
195
213
|
: {}),
|
|
214
|
+
"autobe/histories.json": JSON.stringify(this.histories_, null, 2),
|
|
215
|
+
"autobe/tokenUsage.json": JSON.stringify(this.getTokenUsage(), null, 2),
|
|
216
|
+
...(this.state_.interface
|
|
217
|
+
? {
|
|
218
|
+
"autobe/document.json": JSON.stringify(
|
|
219
|
+
this.state_.interface.document,
|
|
220
|
+
null,
|
|
221
|
+
2,
|
|
222
|
+
),
|
|
223
|
+
}
|
|
224
|
+
: {}),
|
|
196
225
|
};
|
|
197
226
|
return Object.fromEntries(
|
|
198
227
|
Object.entries(files).map(([k, v]) => [
|