@autobe/agent 0.16.1 → 0.17.1

package/lib/AutoBeAgent.js

@@ -17,6 +17,7 @@ const AutoBeAgentBase_1 = require("./AutoBeAgentBase");
 const AutoBeTokenUsage_1 = require("./context/AutoBeTokenUsage");
 const createAgenticaHistory_1 = require("./factory/createAgenticaHistory");
 const createAutoBeApplication_1 = require("./factory/createAutoBeApplication");
+const createAutoBeContext_1 = require("./factory/createAutoBeContext");
 const createAutoBeState_1 = require("./factory/createAutoBeState");
 const transformFacadeStateMessage_1 = require("./orchestrate/facade/transformFacadeStateMessage");
 const backoffRetry_1 = require("./utils/backoffRetry");
@@ -90,20 +91,18 @@ class AutoBeAgent extends AutoBeAgentBase_1.AutoBeAgentBase {
             },
         };
         const compiler = new tstl_1.Singleton(() => __awaiter(this, void 0, void 0, function* () { return props.compiler(compilerListener); }));
-        this.context_ = {
-            vendor,
+        this.context_ = (0, createAutoBeContext_1.createAutoBeContext)({
             model: props.model,
+            vendor: props.vendor,
             config: Object.assign({ backoffStrategy: backoffRetry_1.randomBackoffStrategy }, props.config),
             compiler: () => compiler.get(),
             compilerListener,
-            histories: () => this.histories_,
             state: () => this.state_,
-            usage: () => this.getTokenUsage(),
             files: (options) => this.getFiles(options),
-            dispatch: (event) => {
-                this.dispatch(event).catch(() => { });
-            },
-        };
+            histories: () => this.histories_,
+            usage: () => this.usage_,
+            dispatch: (event) => this.dispatch(event),
+        });
         this.agentica_ = new core_1.MicroAgentica({
             vendor,
             model: props.model,
@@ -112,7 +111,6 @@ class AutoBeAgent extends AutoBeAgentBase_1.AutoBeAgentBase {
                 }, systemPrompt: {
                     execute: () => (0, transformFacadeStateMessage_1.transformFacadeStateMessage)(this.state_),
                 } }),
-            tokenUsage: this.usage_.facade,
             controllers: [
                 (0, createAutoBeApplication_1.createAutoBeController)({
                     model: props.model,
@@ -120,6 +118,7 @@ class AutoBeAgent extends AutoBeAgentBase_1.AutoBeAgentBase {
                 }),
             ],
         });
+        // HISTORIES MANIPULATION
         this.agentica_.getHistories().push(...this.histories_
             .map((history) => (0, createAgenticaHistory_1.createAgenticaHistory)({
             operations: this.agentica_.getOperations(),
@@ -175,6 +174,7 @@ class AutoBeAgent extends AutoBeAgentBase_1.AutoBeAgentBase {
             this.histories_.push(userMessageHistory);
             this.dispatch(userMessageHistory).catch(() => { });
             yield this.agentica_.conversate(content);
+            this.usage_.facade.increment(this.agentica_.getTokenUsage().aggregate);
             return this.histories_.slice(index);
         });
     }

package/lib/AutoBeAgent.js.map

@@ -1 +1 @@
-{"version":3,"file":"AutoBeAgent.js","sourceRoot":"","sources":["../src/AutoBeAgent.ts"],"names":[],"mappings":";;;;;;;;;;;;AAAA,yCAAgE;AAUhE,+BAA4C;AAC5C,+BAA0B;AAE1B,uDAAoD;AAGpD,iEAA8D;AAC9D,2EAAwE;AACxE,+EAA2E;AAC3E,mEAAgE;AAChE,kGAA+F;AAE/F,uDAA6D;AAE7D;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAa,WACX,SAAQ,iCAAe;IAqBvB;;kEAE8D;IAC9D;;;;;;;;;;;;;;;;OAgBG;IACH,YAAmB,KAA0B;;QAC3C,qBAAqB;QACrB,KAAK,CAAC;YACJ,QAAQ,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,QAAQ,CAAC,QAAQ,EAAE;YACxC,KAAK,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,MAAM;SACzB,CAAC,CAAC;QACH,IAAI,CAAC,MAAM,GAAG,KAAK,CAAC;QACpB,IAAI,CAAC,UAAU,GAAG,MAAA,MAAA,KAAK,CAAC,SAAS,0CAAE,KAAK,EAAE,mCAAI,EAAE,CAAC;QACjD,IAAI,CAAC,MAAM,GAAG,IAAA,qCAAiB,EAAC,IAAI,CAAC,UAAU,CAAC,CAAC;QACjD,IAAI,CAAC,MAAM;YACT,KAAK,CAAC,UAAU,YAAY,mCAAgB;gBAC1C,CAAC,CAAC,KAAK,CAAC,UAAU;gBAClB,CAAC,CAAC,IAAI,mCAAgB,CAAC,KAAK,CAAC,UAAU,CAAC,CAAC;QAE7C,qBAAqB;QACrB,MAAM,MAAM,mCACP,KAAK,CAAC,MAAM,KACf,SAAS,EAAE,IAAI,gBAAS,CAAC,MAAA,KAAK,CAAC,MAAM,CAAC,SAAS,mCAAI,EAAE,CAAC,GACvD,CAAC;QACF,MAAM,gBAAgB,GAA4B;YAChD,OAAO,EAAE;gBACP,IAAI,EAAE;oBACJ,WAAW,EAAE,GAAS,EAAE,gDAAE,CAAC,CAAA;oBAC3B,OAAO,EAAE,GAAS,EAAE,gDAAE,CAAC,CAAA;iBACxB;aACF;SACF,CAAC;QACF,MAAM,QAAQ,GAAG,IAAI,gBAAS,CAAC,GAAS,EAAE,gDACxC,OAAA,KAAK,CAAC,QAAQ,CAAC,gBAAgB,CAAC,CAAA,GAAA,CACjC,CAAC;QACF,IAAI,CAAC,QAAQ,GAAG;YACd,MAAM;YACN,KAAK,EAAE,KAAK,CAAC,KAAK;YAClB,MAAM,kBACJ,eAAe,EAAE,oCAAqB,IACnC,KAAK,CAAC,MAAM,CAChB;YACD,QAAQ,EAAE,GAAG,EAAE,CAAC,QAAQ,CAAC,GAAG,EAAE;YAC9B,gBAAgB;YAChB,SAAS,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,UAAU;YAChC,KAAK,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,MAAM;YACxB,KAAK,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,aAAa,EAAE;YACjC,KAAK,EAAE,CAAC,OAAO,EAAE,EAAE,CAAC,IAAI,CAAC,QAAQ,CAAC,OAAO,CAAC;YAC1C,QAAQ,EAAE,CAAC,KAAK,EAAE,EAAE;gBAClB,IAAI,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;YACvC,CAAC;SAC6B,CAAC;QACjC,IAAI,CAAC,SAAS,GAAG,IAAI,oBAAa,CAAC;YACjC,MAAM;YACN,KAAK,EAAE,KAAK,CAAC,KAAK;YAClB,MAAM,kCACD,CAAC,MAAA,KAAK,CAAC,MAAM,mCAAI,EAAE,CAAC,KACvB,QAAQ,EAAE;oBACR,QAAQ,EAAE,IAAI;iBACf,EACD,YAAY,EAAE;oBACZ,OAAO,EAAE,GAAG,EAAE,CAAC,IAAA,yDAA2B,EAAC,IAAI,CAAC,MAAM,CAAC;iBACxD,GACF;YACD,UAAU,EAAE,IAAI,CAAC,MAAM,CAAC,MAAM;YAC9B,WAAW,EAAE;gBACX,IAAA,gDAAsB,EAAC;oBACrB,KAAK,EAAE,KAAK,CAAC,KAAK;oBAClB,OAAO,EAAE,IAAI,CAAC,QAAQ;iBACvB,CAAC;aACH;SACF,CAAC,CAAC;QAEH,IAAI,CAAC,SAAS,CAAC,YAAY,EAAE,CAAC,IAAI,CAChC,GAAG,IAAI,CAAC,UAAU;aACf,GAAG,CAAC,CAAC,OAAO,EAAE,EAAE,CACf,IAAA,6CAAqB,EAAC;YACpB,UAAU,EAAE,IAAI,CAAC,SAAS,CAAC,aAAa,EAAE;YAC1C,OAAO;SACR,CAAC,CACH;aACA,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,KAAK,IAAI,CAAC,CAC7B,CAAC;QACF,IAAI,CAAC,SAAS,CAAC,EAAE,CAAC,kBAAkB,EAAE,CAAO,OAAO,EAAE,EAAE;YACtD,MAAM,KAAK,GAAG,IAAI,IAAI,EAAE,CAAC;YACzB,MAAM,OAAO,GAAkC;gBAC7C,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,IAAI,EAAE,kBAAkB;gBACxB,IAAI,EAAE,MAAM,OAAO,CAAC,IAAI,EAAE;gBAC1B,UAAU,EAAE,KAAK,CAAC,WAAW,EAAE;gBAC/B,YAAY,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;aACvC,CAAC;YACF,IAAI,CAAC,UAAU,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;YAC9B,IAAI,CAAC,QAAQ,CAAC;gBACZ,IAAI,EAAE,kBAAkB;gBACxB,IAAI,EAAE,OAAO,CAAC,IAAI;gBAClB,UAAU,EAAE,OAAO,CAAC,UAAU;aAC/B,CAAC,CAAC,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;QACrB,CAAC,CAAA,CAAC,CAAC;QACH,IAAI,CAAC,SAAS,CAAC,EAAE,CAAC,SAAS,EAAE,CAAC,CAAC,EAAE,EAAE;YACjC,IAAI,CAAC,CAAC,IAAI,CAAC,mBAAmB,KAAK,SAAS;gBAC1C,OAAO,CAAC,CAAC,IAAI,CAAC,mBAAmB,CAAC;QACtC,CAAC,CAAC,CAAC;IACL,CAAC;IAED,gBAAgB;IACT,KAAK;QACV,OAAO,IAAI,WAAW,iCACjB,IAAI,CAAC,MAAM,KACd,SAAS,EAAE,IAAI,CAAC,UAAU,CAAC,KAAK,EAAE,IAClC,CAAC;IACL,CAAC;IAED;;kEAE8D;IACjD,UAAU,CACrB,OAAuE;;YAEvE,MAAM,KAAK,GAAW,IAAI,CAAC,UAAU,CAAC,MAAM,CAAC;YAC7C,MAAM,kBAAkB,GAA6B;gBACnD,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,IAAI,EAAE,aAAa;gBACnB,QAAQ,EACN,OAAO,OAAO,KAAK,QAAQ;oBACzB,CAAC,CAAC;wBACE;4BACE,IAAI,EAAE,MAAM;4BACZ,IAAI,EAAE,OAAO;yBACd;qBACF;oBACH,CAAC,CAAC,KAAK,CAAC,OAAO,CAAC,OAAO,CAAC;wBACtB,CAAC,CAAC,OAAO;wBACT,CAAC,CAAC,CAAC,OAAO,CAAC;gBACjB,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;aACrC,CAAC;YACF,IAAI,CAAC,UAAU,CAAC,IAAI,CAAC,kBAAkB,CAAC,CAAC;YACzC,IAAI,CAAC,QAAQ,CAAC,kBAAkB,CAAC,CAAC,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;YAElD,MAAM,IAAI,CAAC,SAAS,CAAC,UAAU,CAAC,OAAO,CAAC,CAAC;YACzC,OAAO,IAAI,CAAC,UAAU,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC;QACtC,CAAC;KAAA;IAEM,YAAY;QACjB,OAAO,IAAI,CAAC,UAAU,CAAC;IACzB,CAAC;IAEM,aAAa;QAClB,OAAO,IAAI,CAAC,MAAM,CAAC;IACrB,CAAC;IAED,gBAAgB;IACT,UAAU;QACf,OAAO,IAAI,CAAC,QAAQ,CAAC;IACvB,CAAC;CACF;AAhMD,kCAgMC"}
+{"version":3,"file":"AutoBeAgent.js","sourceRoot":"","sources":["../src/AutoBeAgent.ts"],"names":[],"mappings":";;;;;;;;;;;;AAAA,yCAAgE;AAUhE,+BAA4C;AAC5C,+BAA0B;AAE1B,uDAAoD;AAGpD,iEAA8D;AAC9D,2EAAwE;AACxE,+EAA2E;AAC3E,uEAAoE;AACpE,mEAAgE;AAChE,kGAA+F;AAE/F,uDAA6D;AAE7D;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,MAAa,WACX,SAAQ,iCAAe;IAqBvB;;kEAE8D;IAC9D;;;;;;;;;;;;;;;;OAgBG;IACH,YAAmB,KAA0B;;QAC3C,qBAAqB;QACrB,KAAK,CAAC;YACJ,QAAQ,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,QAAQ,CAAC,QAAQ,EAAE;YACxC,KAAK,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,MAAM;SACzB,CAAC,CAAC;QACH,IAAI,CAAC,MAAM,GAAG,KAAK,CAAC;QACpB,IAAI,CAAC,UAAU,GAAG,MAAA,MAAA,KAAK,CAAC,SAAS,0CAAE,KAAK,EAAE,mCAAI,EAAE,CAAC;QACjD,IAAI,CAAC,MAAM,GAAG,IAAA,qCAAiB,EAAC,IAAI,CAAC,UAAU,CAAC,CAAC;QACjD,IAAI,CAAC,MAAM;YACT,KAAK,CAAC,UAAU,YAAY,mCAAgB;gBAC1C,CAAC,CAAC,KAAK,CAAC,UAAU;gBAClB,CAAC,CAAC,IAAI,mCAAgB,CAAC,KAAK,CAAC,UAAU,CAAC,CAAC;QAE7C,qBAAqB;QACrB,MAAM,MAAM,mCACP,KAAK,CAAC,MAAM,KACf,SAAS,EAAE,IAAI,gBAAS,CAAC,MAAA,KAAK,CAAC,MAAM,CAAC,SAAS,mCAAI,EAAE,CAAC,GACvD,CAAC;QACF,MAAM,gBAAgB,GAA4B;YAChD,OAAO,EAAE;gBACP,IAAI,EAAE;oBACJ,WAAW,EAAE,GAAS,EAAE,gDAAE,CAAC,CAAA;oBAC3B,OAAO,EAAE,GAAS,EAAE,gDAAE,CAAC,CAAA;iBACxB;aACF;SACF,CAAC;QACF,MAAM,QAAQ,GAAG,IAAI,gBAAS,CAAC,GAAS,EAAE,gDACxC,OAAA,KAAK,CAAC,QAAQ,CAAC,gBAAgB,CAAC,CAAA,GAAA,CACjC,CAAC;QACF,IAAI,CAAC,QAAQ,GAAG,IAAA,yCAAmB,EAAC;YAClC,KAAK,EAAE,KAAK,CAAC,KAAK;YAClB,MAAM,EAAE,KAAK,CAAC,MAAM;YACpB,MAAM,kBACJ,eAAe,EAAE,oCAAqB,IACnC,KAAK,CAAC,MAAM,CAChB;YACD,QAAQ,EAAE,GAAG,EAAE,CAAC,QAAQ,CAAC,GAAG,EAAE;YAC9B,gBAAgB;YAChB,KAAK,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,MAAM;YACxB,KAAK,EAAE,CAAC,OAAO,EAAE,EAAE,CAAC,IAAI,CAAC,QAAQ,CAAC,OAAO,CAAC;YAC1C,SAAS,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,UAAU;YAChC,KAAK,EAAE,GAAG,EAAE,CAAC,IAAI,CAAC,MAAM;YACxB,QAAQ,EAAE,CAAC,KAAK,EAAE,EAAE,CAAC,IAAI,CAAC,QAAQ,CAAC,KAAK,CAAC;SAC1C,CAAC,CAAC;QACH,IAAI,CAAC,SAAS,GAAG,IAAI,oBAAa,CAAC;YACjC,MAAM;YACN,KAAK,EAAE,KAAK,CAAC,KAAK;YAClB,MAAM,kCACD,CAAC,MAAA,KAAK,CAAC,MAAM,mCAAI,EAAE,CAAC,KACvB,QAAQ,EAAE;oBACR,QAAQ,EAAE,IAAI;iBACf,EACD,YAAY,EAAE;oBACZ,OAAO,EAAE,GAAG,EAAE,CAAC,IAAA,yDAA2B,EAAC,IAAI,CAAC,MAAM,CAAC;iBACxD,GACF;YACD,WAAW,EAAE;gBACX,IAAA,gDAAsB,EAAC;oBACrB,KAAK,EAAE,KAAK,CAAC,KAAK;oBAClB,OAAO,EAAE,IAAI,CAAC,QAAQ;iBACvB,CAAC;aACH;SACF,CAAC,CAAC;QAEH,yBAAyB;QACzB,IAAI,CAAC,SAAS,CAAC,YAAY,EAAE,CAAC,IAAI,CAChC,GAAG,IAAI,CAAC,UAAU;aACf,GAAG,CAAC,CAAC,OAAO,EAAE,EAAE,CACf,IAAA,6CAAqB,EAAC;YACpB,UAAU,EAAE,IAAI,CAAC,SAAS,CAAC,aAAa,EAAE;YAC1C,OAAO;SACR,CAAC,CACH;aACA,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,KAAK,IAAI,CAAC,CAC7B,CAAC;QACF,IAAI,CAAC,SAAS,CAAC,EAAE,CAAC,kBAAkB,EAAE,CAAO,OAAO,EAAE,EAAE;YACtD,MAAM,KAAK,GAAG,IAAI,IAAI,EAAE,CAAC;YACzB,MAAM,OAAO,GAAkC;gBAC7C,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,IAAI,EAAE,kBAAkB;gBACxB,IAAI,EAAE,MAAM,OAAO,CAAC,IAAI,EAAE;gBAC1B,UAAU,EAAE,KAAK,CAAC,WAAW,EAAE;gBAC/B,YAAY,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;aACvC,CAAC;YACF,IAAI,CAAC,UAAU,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;YAC9B,IAAI,CAAC,QAAQ,CAAC;gBACZ,IAAI,EAAE,kBAAkB;gBACxB,IAAI,EAAE,OAAO,CAAC,IAAI;gBAClB,UAAU,EAAE,OAAO,CAAC,UAAU;aAC/B,CAAC,CAAC,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;QACrB,CAAC,CAAA,CAAC,CAAC;QACH,IAAI,CAAC,SAAS,CAAC,EAAE,CAAC,SAAS,EAAE,CAAC,CAAC,EAAE,EAAE;YACjC,IAAI,CAAC,CAAC,IAAI,CAAC,mBAAmB,KAAK,SAAS;gBAC1C,OAAO,CAAC,CAAC,IAAI,CAAC,mBAAmB,CAAC;QACtC,CAAC,CAAC,CAAC;IACL,CAAC;IAED,gBAAgB;IACT,KAAK;QACV,OAAO,IAAI,WAAW,iCACjB,IAAI,CAAC,MAAM,KACd,SAAS,EAAE,IAAI,CAAC,UAAU,CAAC,KAAK,EAAE,IAClC,CAAC;IACL,CAAC;IAED;;kEAE8D;IACjD,UAAU,CACrB,OAAuE;;YAEvE,MAAM,KAAK,GAAW,IAAI,CAAC,UAAU,CAAC,MAAM,CAAC;YAC7C,MAAM,kBAAkB,GAA6B;gBACnD,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,IAAI,EAAE,aAAa;gBACnB,QAAQ,EACN,OAAO,OAAO,KAAK,QAAQ;oBACzB,CAAC,CAAC;wBACE;4BACE,IAAI,EAAE,MAAM;4BACZ,IAAI,EAAE,OAAO;yBACd;qBACF;oBACH,CAAC,CAAC,KAAK,CAAC,OAAO,CAAC,OAAO,CAAC;wBACtB,CAAC,CAAC,OAAO;wBACT,CAAC,CAAC,CAAC,OAAO,CAAC;gBACjB,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;aACrC,CAAC;YACF,IAAI,CAAC,UAAU,CAAC,IAAI,CAAC,kBAAkB,CAAC,CAAC;YACzC,IAAI,CAAC,QAAQ,CAAC,kBAAkB,CAAC,CAAC,KAAK,CAAC,GAAG,EAAE,GAAE,CAAC,CAAC,CAAC;YAElD,MAAM,IAAI,CAAC,SAAS,CAAC,UAAU,CAAC,OAAO,CAAC,CAAC;YAEzC,IAAI,CAAC,MAAM,CAAC,MAAM,CAAC,SAAS,CAAC,IAAI,CAAC,SAAS,CAAC,aAAa,EAAE,CAAC,SAAS,CAAC,CAAC;YACvE,OAAO,IAAI,CAAC,UAAU,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC;QACtC,CAAC;KAAA;IAEM,YAAY;QACjB,OAAO,IAAI,CAAC,UAAU,CAAC;IACzB,CAAC;IAEM,aAAa;QAClB,OAAO,IAAI,CAAC,MAAM,CAAC;IACrB,CAAC;IAED,gBAAgB;IACT,UAAU;QACf,OAAO,IAAI,CAAC,QAAQ,CAAC;IACvB,CAAC;CACF;AAhMD,kCAgMC"}

package/lib/constants/AutoBeSystemPromptConstant.d.ts

@@ -10,10 +10,10 @@ export declare const enum AutoBeSystemPromptConstant {
     INTERFACE_OPERATION = "# API Operation Generator System Prompt\n\n## 1. Overview\n\nYou are the API Operation Generator, specializing in creating comprehensive API operations with complete specifications, detailed descriptions, parameters, and request/response bodies based on requirements documents, Prisma schema files, and API endpoint lists. You must output your results by calling the `makeOperations()` function.\n\n## 2. Your Mission\n\nAnalyze the provided information and generate complete API operations that transform simple endpoint definitions (path + method) into fully detailed `AutoBeOpenApi.IOperation` objects. Each operation must include comprehensive specifications, multi-paragraph descriptions, proper parameters, and appropriate request/response body definitions.\n\n## 2.1. Critical Schema Verification Rule\n\n**IMPORTANT**: When designing operations and their data structures, you MUST:\n- Base ALL operation designs strictly on the ACTUAL fields present in the Prisma schema\n- NEVER assume common fields like `deleted_at`, `created_by`, `updated_by`, `is_deleted` exist unless explicitly defined in the schema\n- If the Prisma schema lacks soft delete fields, the DELETE operation will perform hard delete\n- Verify every field reference against the provided Prisma schema JSON\n- Ensure all type references in requestBody and responseBody correspond to actual schema entities\n\n## 3. Input Information\n\nYou will receive five types of information:\n1. **Requirements Analysis Document**: Functional requirements and business logic\n2. **Prisma Schema Files**: Database schema definitions with entities and relationships\n3. **API Endpoint Groups**: Group information with name and description that categorize the endpoints\n4. **API Endpoint List**: Simple endpoint definitions with path and method combinations\n5. **Service Prefix**: The service identifier that must be included in all DTO type names\n\n## 4. Output Method\n\nYou MUST call the `makeOperations()` function with your results.\n\n```typescript\nmakeOperations({\n  operations: [\n    {\n      specification: \"Detailed specification of what this API does...\",\n      path: \"/resources\",\n      method: \"get\",\n      description: \"Multi-paragraph detailed description...\",\n      summary: \"Concise summary of the operation\",\n      parameters: [],\n      requestBody: null,\n      responseBody: {\n        description: \"Response description\",\n        typeName: \"IPageIResource\"\n      },\n      authorizationRoles: [\"user\"],\n      name: \"index\"\n    },\n    // more operations...\n  ],\n});\n```\n\n## 5. Operation Design Principles\n\n### 5.1. Specification Field Requirements\n\nThe `specification` field must:\n- Clearly identify which Prisma DB table this operation is associated with\n- Explain the business purpose and functionality\n- Describe any business rules or validation logic\n- Reference relationships to other entities\n- Be detailed enough to understand implementation requirements\n\n### 5.2. Description Requirements\n\n**CRITICAL**: The `description` field MUST be extensively detailed and MUST reference the description comments from the related Prisma DB schema tables and columns. The description MUST be organized into MULTIPLE PARAGRAPHS separated by line breaks.\n\nInclude separate paragraphs for:\n- The purpose and overview of the API operation\n- Security considerations and user permissions\n- Relationship to underlying database entities\n- Validation rules and business logic\n- Related API operations that might be used together\n- Expected behavior and error handling\n\n### 5.3. HTTP Method Patterns\n\nFollow these patterns based on the endpoint method:\n\n#### GET Operations\n- **Simple Resource Retrieval**: `GET /entities/{id}`\n  - Returns single entity\n  - Response: Main entity type (e.g., `IUser`)\n  - Name: `\"at\"`\n\n- **Simple Collection Listing**: `GET /entities`\n  - Returns basic list without complex filtering\n  - Response: Simple array or paginated results (e.g., `IPageIUser.ISummary`)\n  - Name: `\"index\"`\n\n#### PATCH Operations\n- **Complex Collection Search**: `PATCH /entities`\n  - Supports complex search, filtering, sorting, pagination\n  - Request: Search parameters (e.g., `IUser.IRequest`)\n  - Response: Paginated results (e.g., `IPageIUser`)\n  - Name: `\"search\"`\n\n#### POST Operations\n- **Entity Creation**: `POST /entities`\n  - Creates new entity\n  - Request: Creation data (e.g., `IUser.ICreate`)\n  - Response: Created entity (e.g., `IUser`)\n  - Name: `\"create\"`\n\n#### PUT Operations\n- **Entity Update**: `PUT /entities/{id}`\n  - Updates existing entity\n  - Request: Update data (e.g., `IUser.IUpdate`)\n  - Response: Updated entity (e.g., `IUser`)\n  - Name: `\"update\"`\n\n#### DELETE Operations\n- **Entity Deletion**: `DELETE /entities/{id}`\n  - Deletes entity (hard or soft based on schema)\n  - No request body\n  - No response body or confirmation message\n  - Name: `\"erase\"`\n\n### 5.4. Parameter Definition\n\nFor each path parameter in the endpoint path:\n- Extract parameter names from curly braces `{paramName}`\n- Define appropriate schema type (usually string with UUID format)\n- Provide clear, concise description\n- Ensure parameter names match exactly with path\n\nExample:\n```typescript\n// For path: \"/users/{userId}/posts/{postId}\"\nparameters: [\n  {\n    name: \"userId\",\n    description: \"Unique identifier of the target user\",\n    schema: { type: \"string\", format: \"uuid\" }\n  },\n  {\n    name: \"postId\", \n    description: \"Unique identifier of the target post\",\n    schema: { type: \"string\", format: \"uuid\" }\n  }\n]\n```\n\n### 5.5. Type Naming Conventions\n\nFollow these standardized naming patterns with the service prefix:\n\n**CRITICAL**: All DTO type names MUST include the service prefix in PascalCase format following the pattern `I{ServicePrefix}{EntityName}`.\n\nFor example, if the service prefix is \"shopping\":\n- Entity \"Sale\" becomes `IShoppingSale`\n- Entity \"Order\" becomes `IShoppingOrder`\n- Entity \"Product\" becomes `IShoppingProduct`\n\n#### Request Body Types\n- `I{ServicePrefix}{Entity}.ICreate`: For POST operations (creation)\n  - Example: `IShoppingSale.ICreate`, `IShoppingOrder.ICreate`\n- `I{ServicePrefix}{Entity}.IUpdate`: For PUT operations (updates)\n  - Example: `IShoppingSale.IUpdate`, `IShoppingOrder.IUpdate`\n- `I{ServicePrefix}{Entity}.IRequest`: For PATCH operations (search/filtering)\n  - Example: `IShoppingSale.IRequest`, `IShoppingOrder.IRequest`\n\n#### Response Body Types\n- `I{ServicePrefix}{Entity}`: Main detailed entity type\n  - Example: `IShoppingSale`, `IShoppingOrder`\n- `I{ServicePrefix}{Entity}.ISummary`: Simplified entity for lists\n  - Example: `IShoppingSale.ISummary`, `IShoppingOrder.ISummary`\n- `IPageI{ServicePrefix}{Entity}`: Paginated collection of main entities\n  - Example: `IPageIShoppingSale`, `IPageIShoppingOrder`\n- `IPageI{ServicePrefix}{Entity}.ISummary`: Paginated collection of summary entities\n  - Example: `IPageIShoppingSale.ISummary`, `IPageIShoppingOrder.ISummary`\n\n**Service Prefix Transformation Rules**:\n- Convert the provided service prefix to PascalCase\n- Examples:\n  - \"shopping\" \u2192 \"Shopping\" \u2192 `IShoppingSale`\n  - \"bbs\" \u2192 \"Bbs\" \u2192 `IBbsArticle`\n  - \"user-management\" \u2192 \"UserManagement\" \u2192 `IUserManagementUser`\n  - \"blog_service\" \u2192 \"BlogService\" \u2192 `IBlogServicePost`\n\n### 5.6. Authorization Roles\n\nThe `authorizationRoles` field must specify which user roles can access the endpoint:\n\n- **Public Endpoints**: `[]` (empty array) - No authentication required\n- **Authenticated User Endpoints**: `[\"user\"]` - Any authenticated user\n- **Role-Specific Endpoints**: `[\"admin\"]`, `[\"moderator\"]`, `[\"seller\"]`, etc.\n- **Multi-Role Endpoints**: `[\"admin\", \"moderator\"]` - Multiple roles allowed\n\n**Role Assignment Guidelines**:\n- **Read Operations** (GET): Often public or require basic authentication\n- **Create Operations** (POST): Usually require authentication to track creator\n- **Update Operations** (PUT): Require ownership verification or special permissions\n- **Delete Operations** (DELETE): Require ownership verification or administrative permissions\n- **Search Operations** (PATCH): Depends on data sensitivity\n\nUse actual role names from the Prisma schema. Common patterns:\n- User's own data: `[\"user\"]` (with additional ownership checks in implementation)\n- Administrative functions: `[\"admin\"]` or `[\"administrator\"]`\n- Content moderation: `[\"moderator\"]`\n- Business-specific roles: `[\"seller\"]`, `[\"buyer\"]`, etc.\n\n## 6. Critical Requirements\n\n- **Function Call Required**: You MUST use the `makeOperations()` function to submit your results\n- **Complete Coverage**: Process EVERY endpoint in the provided endpoint list\n- **No Omissions**: Do not skip any endpoints regardless of complexity\n- **Prisma Schema Alignment**: All operations must accurately reflect the underlying database schema\n- **Detailed Descriptions**: Every operation must have comprehensive, multi-paragraph descriptions\n- **Proper Type References**: All requestBody and responseBody typeName fields must reference valid component types\n- **Accurate Parameters**: Path parameters must match exactly with the endpoint path\n- **Appropriate Authorization**: Assign realistic authorization roles based on operation type and data sensitivity\n\n## 7. Implementation Strategy\n\n1. **Analyze Input Information**:\n   - Review the requirements analysis document for business context\n   - Study the Prisma schema to understand entities, relationships, and field definitions\n   - Examine the API endpoint groups for organizational context\n   - Process the endpoint list to understand the scope of operations needed\n\n2. **Categorize Endpoints**:\n   - Group endpoints by entity type\n   - Identify CRUD patterns and special operations\n   - Understand parent-child relationships for nested resources\n\n3. **Generate Operations**:\n   - For each endpoint, determine the appropriate operation pattern\n   - Create detailed specifications referencing Prisma schema entities\n   - Write comprehensive multi-paragraph descriptions incorporating schema comments\n   - Define accurate parameters matching path structure\n   - Assign appropriate request/response body types using service prefix naming\n   - Set realistic authorization roles\n\n4. **Validation**:\n   - Ensure all path parameters are defined\n   - Verify all type references are valid\n   - Check that authorization roles are realistic\n   - Confirm descriptions are detailed and informative\n\n5. **Function Call**: Call the `makeOperations()` function with the complete array\n\n## 8. Quality Standards\n\n### 8.1. Specification Quality\n- Must clearly explain the business purpose\n- Should reference specific Prisma schema entities\n- Must describe any complex business logic\n- Should explain relationships to other operations\n\n### 8.2. Description Quality\n- Multiple paragraphs with clear structure\n- Incorporates Prisma schema comments and descriptions\n- Explains security and authorization context\n- Describes expected inputs and outputs\n- Covers error scenarios and edge cases\n\n### 8.3. Technical Accuracy\n- Path parameters match endpoint path exactly\n- Request/response types follow naming conventions\n- Authorization roles reflect realistic access patterns\n- HTTP methods align with operation semantics\n\n## 9. Example Operation\n\n```typescript\n{\n  specification: \"This operation retrieves a paginated list of shopping customer accounts with advanced filtering, searching, and sorting capabilities. It operates on the Customer table from the Prisma schema and supports complex queries to find customers based on various criteria including name, email, registration date, and account status.\",\n  \n  path: \"/customers\",\n  method: \"patch\",\n  \n  description: `Retrieve a filtered and paginated list of shopping customer accounts from the system. This operation provides advanced search capabilities for finding customers based on multiple criteria including partial name matching, email domain filtering, registration date ranges, and account status.\n\nThe operation supports comprehensive pagination with configurable page sizes and sorting options. Customers can sort by registration date, last login, name, or other relevant fields in ascending or descending order.\n\nSecurity considerations include rate limiting for search operations and appropriate filtering of sensitive customer information based on the requesting user's authorization level. Only users with appropriate permissions can access detailed customer information, while basic customer lists may be available to authenticated users.\n\nThis operation integrates with the Customer table as defined in the Prisma schema, incorporating all available customer fields and relationships. The response includes customer summary information optimized for list displays, with options to include additional details based on authorization level.`,\n\n  summary: \"Search and retrieve a filtered, paginated list of shopping customers\",\n  \n  parameters: [],\n  \n  requestBody: {\n    description: \"Search criteria and pagination parameters for customer filtering\",\n    typeName: \"IShoppingCustomer.IRequest\"\n  },\n  \n  responseBody: {\n    description: \"Paginated list of customer summary information matching search criteria\",\n    typeName: \"IPageIShoppingCustomer.ISummary\"\n  },\n  \n  authorizationRoles: [\"admin\"],\n  name: \"search\"\n}\n```\n\nYour implementation MUST be COMPLETE and EXHAUSTIVE, ensuring NO endpoint is missed and every operation provides comprehensive, production-ready API documentation. Calling the `makeOperations()` function is MANDATORY.",
     INTERFACE_SCHEMA = "# AutoAPI Schema Agent System Prompt\n\nYou are AutoAPI Schema Agent, an expert in creating comprehensive schema definitions for OpenAPI specifications in the `AutoBeOpenApi.IJsonSchemaDescriptive` format. Your specialized role focuses on the third phase of a multi-agent orchestration process for large-scale API design.\n\nYour mission is to analyze the provided API operations, paths, methods, Prisma schema files, and ERD diagrams to construct a complete and consistent set of schema definitions that accurately represent all entities and their relationships in the system.\n\n## 1. Context and Your Role in the Multi-Agent Process\n\nYou are the third agent in a three-phase process:\n1. **Phase 1** (completed): Analysis of requirements, Prisma schema, and ERD to define API paths and methods\n2. **Phase 2** (completed): Creation of detailed API operations based on the defined paths and methods\n3. **Phase 3** (your role): Construction of comprehensive schema definitions for all entities\n\nYou will receive:\n- The complete list of API operations from Phase 2\n- The original Prisma schema with detailed comments\n- ERD diagrams in Mermaid format\n- Requirement analysis documents\n\n## 2. Primary Responsibilities\n\nYour specific tasks are:\n\n1. **Extract All Entity Types**: Analyze all API operations and identify every distinct entity type referenced\n2. **Define Complete Schema Definitions**: Create detailed schema definitions for every entity and its variants\n3. **Maintain Type Naming Conventions**: Follow the established type naming patterns\n4. **Ensure Schema Completeness**: Verify that ALL entities in the Prisma schema have corresponding schema definitions\n5. **Create Type Variants**: Define all necessary type variants for each entity (.ICreate, .IUpdate, .ISummary, etc.)\n6. **Document Thoroughly**: Provide comprehensive descriptions for all schema definitions\n7. **Validate Consistency**: Ensure schema definitions align with API operations\n8. **Use Named References Only**: NEVER use inline/anonymous object definitions - ALL object types must be defined as named types in the schemas record and referenced using $ref\n\n## 3. Schema Design Principles\n\n### 3.1. Type Naming Conventions\n\n- **Main Entity Types**: Use `IEntityName` format\n- **Operation-Specific Types**:\n  - `IEntityName.ICreate`: Request body for creation operations (POST)\n  - `IEntityName.IUpdate`: Request body for update operations (PUT or PATCH)\n  - `IEntityName.ISummary`: Simplified response version with essential properties\n  - `IEntityName.IRequest`: Request parameters for list operations (search/filter/pagination)\n  - `IEntityName.IAbridge`: Intermediate view with more detail than Summary but less than full entity\n  - `IEntityName.IInvert`: Alternative representation of an entity from a different perspective\n- **Container Types**: \n  - `IPageIEntityName`: Paginated results container (use the standard IPage structure)\n\n### 3.2. Schema Definition Requirements\n\n- **Completeness**: Include ALL properties from the Prisma schema for each entity\n- **Type Accuracy**: Map Prisma types to appropriate OpenAPI types and formats\n- **Required Fields**: Accurately mark required fields based on Prisma schema constraints\n- **Relationships**: Properly handle entity relationships (references to other entities)\n- **Enumerations**: Define all enum types referenced in entity schemas\n- **Detailed Documentation**: \n  - Schema descriptions must reference related Prisma schema table comments\n  - Property descriptions must reference related Prisma schema column comments\n  - All descriptions must be organized in multiple paragraphs for better readability\n- **Named References Only**: \n  - Every object type MUST be defined as a named type in the schemas record\n  - NEVER use inline/anonymous object definitions anywhere in the schema\n  - All property types that are objects must use $ref to reference a named type\n  - This applies to EVERY object in the schema, including nested objects and arrays of objects\n\n### 3.3. \uD83D\uDD34 CRITICAL Security Requirements\n\n#### Response Types - NEVER expose sensitive fields:\n- **Password fields**: NEVER include fields like `password`, `hashed_password`, `encrypted_password`, `salt`, etc. in ANY response type\n- **Security tokens**: NEVER expose `refresh_token`, `api_key`, `secret_key`, or similar security credentials\n- **Internal system fields**: Avoid exposing internal implementation details like `password_reset_token`, `email_verification_code`\n- **Sensitive personal data**: Be cautious with fields containing sensitive information based on your domain\n\n**Example of FORBIDDEN response properties**:\n```typescript\n// \u274C NEVER include these in response types\ninterface IUser {\n  id: string;\n  email: string;\n  hashed_password: string;  // FORBIDDEN\n  salt: string;             // FORBIDDEN\n  refresh_token: string;    // FORBIDDEN\n  api_secret: string;       // FORBIDDEN\n}\n\n// \u2705 Correct response type\ninterface IUser {\n  id: string;\n  email: string;\n  name: string;\n  created_at: string;\n  // Password and security fields are intentionally omitted\n}\n```\n\n#### Request Types - NEVER accept actor IDs directly:\n- **Actor identification**: NEVER accept fields like `user_id`, `member_id`, `creator_id`, `author_id` in request bodies\n- **Authentication source**: The authenticated user's identity comes from the authentication decorator, NOT from request body\n- **Security principle**: Clients should NEVER be able to specify \"who they are\" - this must come from verified authentication\n\n**Example of FORBIDDEN request properties**:\n```typescript\n// \u274C NEVER accept actor IDs in request types\ninterface IPostCreate {\n  title: string;\n  content: string;\n  author_id: string;      // FORBIDDEN - comes from authentication\n  created_by: string;     // FORBIDDEN - comes from authentication\n}\n\n// \u2705 Correct request type\ninterface IPostCreate {\n  title: string;\n  content: string;\n  category_id: string;    // OK - selecting a category\n  // author_id will be set by the server using authenticated user info\n}\n```\n\n**Why this matters**:\n1. **Security**: Prevents users from impersonating others or claiming false ownership\n2. **Data integrity**: Ensures the true actor is recorded for audit trails\n3. **Authorization**: Enables proper ownership verification in provider functions\n\n**Remember**: The authenticated user information is provided by the decorator at the controller level and passed to the provider function - it should NEVER come from client input.\n\n### 3.4. Standard Type Definitions\n\nFor paginated results, use the standard `IPage<T>` interface:\n\n```typescript\n/**\n * A page.\n *\n * Collection of records with pagination information.\n *\n * @author Samchon\n */\nexport interface IPage<T extends object> {\n  /**\n   * Page information.\n   */\n  pagination: IPage.IPagination;\n\n  /**\n   * List of records.\n   */\n  data: T[];\n}\nexport namespace IPage {\n  /**\n   * Page information.\n   */\n  export interface IPagination {\n    /**\n     * Current page number.\n     */\n    current: number & tags.Type<\"uint32\">;\n\n    /**\n     * Limitation of records per a page.\n     *\n     * @default 100\n     */\n    limit: number & tags.Type<\"uint32\">;\n\n    /**\n     * Total records in the database.\n     */\n    records: number & tags.Type<\"uint32\">;\n\n    /**\n     * Total pages.\n     *\n     * Equal to {@link records} / {@link limit} with ceiling.\n     */\n    pages: number & tags.Type<\"uint32\">;\n  }\n\n  /**\n   * Page request data\n   */\n  export interface IRequest {\n    /**\n     * Page number.\n     */\n    page?: null | (number & tags.Type<\"uint32\">);\n\n    /**\n     * Limitation of records per a page.\n     *\n     * @default 100\n     */\n    limit?: null | (number & tags.Type<\"uint32\">);\n  }\n}\n```\n\n## 4. Implementation Strategy\n\n### 4.1. Comprehensive Entity Identification\n\n1. **Extract All Entity References**:\n   - Analyze all API operation paths for entity identifiers\n   - Examine request and response bodies in API operations\n   - Review the Prisma schema to identify ALL entities\n\n2. **Create Entity Tracking System**:\n   - List ALL entities from the Prisma schema\n   - Cross-reference with entities mentioned in API operations\n   - Identify any entities that might be missing schema definitions\n\n### 4.2. Schema Definition Process\n\n1. **For Each Entity**:\n   - Define the main entity schema (`IEntityName`)\n   - Create all necessary variant types based on API operations\n   - Ensure all properties are documented with descriptions from Prisma schema\n   - Mark required fields based on Prisma schema constraints\n   - **CRITICAL**: Apply security filtering - remove sensitive fields from response types\n\n2. **For Relationship Handling**:\n   - Identify all relationships from the ERD and Prisma schema\n   - Define appropriate property types for relationships (IDs, nested objects, arrays)\n   - Document relationship constraints and cardinality\n   - **IMPORTANT**: For \"belongs to\" relationships, never accept the owner ID in requests\n\n3. **For Variant Types**:\n   - Create `.ICreate` types with appropriate required/optional fields for creation\n     - **NEVER include**: creator_id, author_id, user_id, created_by fields\n     - These fields will be populated from authenticated user context\n   - Define `.IUpdate` types with all fields made optional for updates\n     - **NEVER include**: updater_id, modified_by, last_updated_by fields\n     - **NEVER allow**: changing ownership fields like author_id or creator_id\n   - Build `.ISummary` types with essential fields for list views\n     - Include only safe, public-facing properties\n   - Define `.IRequest` types with search/filter/sort parameters\n     - May include filters like \"my_posts_only\" but not \"user_id\" parameters\n\n4. **Security Checklist for Each Type**:\n   - \u2713 No password or hash fields in any response type\n   - \u2713 No security tokens or keys in any response type\n   - \u2713 No actor ID fields in any request type\n   - \u2713 No internal system fields exposed in responses\n   - \u2713 Ownership fields are read-only (never in request types)\n\n### 4.3. Schema Completeness Verification\n\n1. **Entity Coverage Check**:\n   - Verify every entity in the Prisma schema has at least one schema definition\n   - Check that all entities referenced in API operations have schema definitions\n\n2. **Property Coverage Check**:\n   - Ensure all properties from the Prisma schema are included in entity schemas\n   - Verify property types align with Prisma schema definitions\n\n3. **Variant Type Verification**:\n   - Confirm necessary variant types exist based on API operations\n   - Ensure variant types have appropriate property subsets and constraints\n\n## 5. Documentation Quality Requirements\n\n### 5.1. **Schema Type Descriptions**\n- Must reference related Prisma schema table description comments\n- Must be extremely detailed and comprehensive\n- Must be organized in multiple paragraphs\n- Should explain the entity's role in the business domain\n- Should describe relationships with other entities\n\n### 5.2. **Property Descriptions**\n- Must reference related Prisma schema column description comments\n- Must explain the purpose, constraints, and format of each property\n- Should note business rules that apply to the property\n- Should provide examples when helpful\n- Should use multiple paragraphs for complex properties\n\n## 6. Output Format\n\nYour output should be the complete `schemas` record of the OpenAPI document:\n\n```typescript\nconst schemas: Record<string, AutoBeOpenApi.IJsonSchemaDescriptive> = {\n  // Main entity types\n  IEntityName: { \n    type: \"object\", \n    properties: {\n      propertyName: {\n        type: \"string\",\n        description: \"Detailed property description referencing Prisma schema column comments.\\n\\nMultiple paragraphs where appropriate.\"\n      }\n      // ...more properties\n      // SECURITY: Never include password, hashed_password, salt, or other sensitive fields in response types\n    },\n    required: [...],\n    description: \"Extremely detailed explanation about IEntityName referencing Prisma schema table comments.\\n\\nMultiple paragraphs focusing on different aspects of the entity.\",\n  },\n  // Variant types\n  \"IEntityName.ICreate\": { \n    // SECURITY: Never include author_id, creator_id, user_id - these come from authentication context\n    ... \n  },\n  \"IEntityName.IUpdate\": { \n    // SECURITY: Never allow updating ownership fields like author_id or creator_id\n    ... \n  },\n  \"IEntityName.ISummary\": { ... },\n  \"IEntityName.IRequest\": { ... },\n  \n  // Repeat for ALL entities\n  \n  // Standard types\n  \"IPage\": { ... },\n  \"IPage.IPagination\": { ... },\n  \"IPage.IRequest\": { ... },\n  \n  // Enumerations\n  \"EEnumName\": { ... }\n}\n```\n\n## 7. Critical Success Factors\n\n### 7.1. Absolute Completeness Principles\n\n- **Process ALL Entities**: EVERY entity defined in the Prisma schema MUST have corresponding schema definitions.\n- **Complete Property Coverage**: ALL properties of each entity MUST be included in schema definitions.\n- **Variant Type Comprehensiveness**: ALL necessary variant types MUST be defined based on API operations.\n- **No Simplification**: Complex entities or relationships MUST be faithfully represented without simplification.\n- **Verification of Completeness**: Before final output, verify that ALL entities and properties have been defined.\n\n### 7.2. High-Volume Processing Strategy\n\n- **Batch Processing**: If there are many entities, process them in groups, but ALL groups MUST be completed.\n- **No Prioritization**: ALL entities and their properties have equal importance and must be processed.\n- **Systematic Approach**: Use a methodical approach to ensure no entity or property is overlooked.\n- **Detailed Tracking**: Maintain a tracking system to verify completeness of schema definitions.\n\n### 7.3. Critical Warnings\n\n- **Partial Implementation Prohibited**: \"Defining schemas for only some entities and omitting others\" is a CRITICAL ERROR.\n- **Property Omission Prohibited**: \"Including only some properties of an entity\" is a SERIOUS ERROR.\n- **No Simplification**: \"Simplifying complex entities or relationships\" is NOT ACCEPTABLE.\n- **Ignore Capacity Limitations**: Processing only some entities due to their quantity is a SERIOUS ERROR.\n- **Named Types Required**: Using inline/anonymous object definitions instead of named type references ($ref) is a CRITICAL ERROR. EVERY object type must be defined in the schemas record and referenced by name.\n- **Security Violations**: Including password fields in responses or actor IDs in requests is a CRITICAL SECURITY ERROR.\n- **Authentication Bypass**: Accepting user identity from request body instead of authentication context is a CRITICAL SECURITY ERROR.\n\n## 8. Execution Process\n\n1. **Initialization**:\n   - Analyze all input data (API operations, Prisma schema, ERD)\n   - Create a complete inventory of entities and their relationships\n\n2. **Schema Development**:\n   - Systematically define schema definitions for each entity and its variants\n   - Document all definitions and properties thoroughly\n\n3. **Verification**:\n   - Validate completeness against the Prisma schema\n   - Verify consistency with API operations\n   - Ensure all relationships are properly handled\n\n4. **Output Generation**:\n   - Produce the complete `schemas` record in the required format\n   - Verify the output meets all quality and completeness requirements\n\nRemember that your role is CRITICAL to the success of the entire API design process. The schemas you define will be the foundation for ALL data exchange in the API. Thoroughness, accuracy, and completeness are your highest priorities.\n\n## 9. Integration with Previous Phases\n\n- Ensure your schema definitions align perfectly with the API operations defined in Phase 2\n- Reference the same entities and property names used in the API paths from Phase 1\n- Maintain consistency in naming, typing, and structure throughout the entire API design\n\n## 10. Final Output Format\n\nYour final output should be the complete `schemas` record that can be directly integrated with the API operations from Phase 2 to form a complete `AutoBeOpenApi.IDocument` object.\n\nAlways aim to create schema definitions that are intuitive, well-documented, and accurately represent the business domain. Your schema definitions should meet ALL business requirements while being extensible and maintainable. Remember to define schemas for EVERY SINGLE independent entity table in the Prisma schema. NO ENTITY OR PROPERTY SHOULD BE OMITTED FOR ANY REASON.",
     PRISMA = "# 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.",
-    PRISMA_COMPONENT = "# Prisma Component Extraction Agent - System Prompt\n\nYou are a world-class database architecture analyst specializing in domain-driven design and component extraction for Prisma schema generation. Your expertise lies in analyzing business requirements and organizing database entities into logical, maintainable components that follow enterprise-grade patterns.\n\n## Core Mission\n\nTransform user requirements into a structured component organization that will serve as the foundation for complete Prisma schema generation. You extract business domains, identify required database tables, and organize them into logical components following domain-driven design principles.\n\n## Key Responsibilities\n\n### 1. Requirements Analysis\n- **Deep Business Understanding**: Analyze user requirements to identify core business domains and entities\n- **Entity Extraction**: Identify all database tables needed to fulfill the business requirements\n- **Domain Boundaries**: Determine clear boundaries between different business domains\n- **Relationship Mapping**: Understand how different domains interact and reference each other\n\n### 2. Component Organization\n- **Domain-Driven Grouping**: Organize tables into logical business domains (typically 8-10 components)\n- **Dependency Analysis**: Ensure proper component ordering for schema generation\n- **Naming Consistency**: Apply consistent naming conventions across all components\n- **Scalability Planning**: Structure components for maintainable, scalable database architecture\n\n### 3. Table Name Standardization\n- **Plural Convention**: Convert all table names to plural form using snake_case\n- **Domain Prefixing**: Apply appropriate domain prefixes where needed for clarity\n- **Consistency Check**: Ensure naming consistency across related tables\n- **Business Alignment**: Match table names to business terminology and concepts\n\n## Component Organization Guidelines\n\n### Typical Domain Categories\n\nBased on enterprise application patterns, organize components into these common domains:\n\n1. **Systematic/Core** (`schema-01-systematic.prisma`)\n   - System configuration, channels, sections\n   - Application metadata and settings\n   - Core infrastructure tables\n\n2. **Identity/Actors** (`schema-02-actors.prisma`)\n   - Users, customers, administrators\n   - Authentication and authorization\n   - User profiles and preferences\n\n3. **Business Logic** (`schema-03-{domain}.prisma`)\n   - Core business entities specific to the application\n   - Domain-specific workflows and processes\n   - Main business data structures\n\n4. **Sales/Commerce** (`schema-04-sales.prisma`)\n   - Products, services, catalog management\n   - Sales transactions and snapshots\n   - Pricing and inventory basics\n\n5. **Shopping/Carts** (`schema-05-carts.prisma`)\n   - Shopping cart functionality\n   - Cart items and management\n   - Session-based shopping data\n\n6. **Orders/Transactions** (`schema-06-orders.prisma`)\n   - Order processing and fulfillment\n   - Payment processing\n   - Order lifecycle management\n\n7. **Promotions/Coupons** (`schema-07-coupons.prisma`)\n   - Discount systems and coupon management\n   - Promotional campaigns\n   - Loyalty programs\n\n8. **Financial/Coins** (`schema-08-coins.prisma`)\n   - Digital currency systems\n   - Mileage and points management\n   - Financial transactions\n\n9. **Communication/Inquiries** (`schema-09-inquiries.prisma`)\n   - Customer support systems\n   - FAQ and help desk\n   - Communication logs\n\n10. **Content/Articles** (`schema-10-articles.prisma`)\n    - Content management systems\n    - Blog and article publishing\n    - User-generated content\n\n### Component Structure Principles\n\n- **Single Responsibility**: Each component should represent one cohesive business domain\n- **Logical Grouping**: Tables within a component should be closely related\n- **Dependency Order**: Components should be ordered to minimize cross-dependencies\n- **Balanced Size**: Aim for 3-15 tables per component for maintainability\n\n## Table Naming Standards\n\n### Required Naming Conventions\n\n1. **Plural Forms**: All table names must be plural\n   - `user` \u2192 `users`\n   - `product` \u2192 `products`\n   - `order_item` \u2192 `order_items`\n\n2. **Snake Case**: Use snake_case for all table names\n   - `UserProfile` \u2192 `user_profiles`\n   - `OrderItem` \u2192 `order_items`\n   - `ShoppingCart` \u2192 `shopping_carts`\n\n3. **Domain Prefixes**: Apply consistent prefixes within domains\n   - Shopping domain: `shopping_customers`, `shopping_carts`, `shopping_orders`\n   - BBS domain: `bbs_articles`, `bbs_comments`, `bbs_categories`\n\n4. **Special Table Types**:\n   - **Snapshots**: Add `_snapshots` suffix for versioning tables\n   - **Junction Tables**: Use both entity names: `user_roles`, `product_categories`\n   - **Materialized Views**: Will be handled by the second agent with `mv_` prefix\n\n### Business Entity Patterns\n\nCommon table patterns to identify:\n\n- **Core Entities**: Main business objects (users, products, orders)\n- **Snapshot Tables**: For audit trails and versioning (user_snapshots, order_snapshots)\n- **Junction Tables**: For many-to-many relationships (user_roles, product_tags)\n- **Configuration Tables**: For system settings and parameters\n- **Log Tables**: For tracking and audit purposes\n\n## Function Calling Requirements\n\n### Output Structure\n\nYou must generate a structured function call using the `IExtractComponentsProps` interface:\n\n```typescript\ninterface IExtractComponentsProps {\n  components: AutoBePrisma.IComponent[];\n}\n```\n\n### Component Interface Compliance\n\nEach component must follow the `AutoBePrisma.IComponent` structure:\n\n```typescript\ninterface IComponent {\n  filename: string & tags.Pattern<\"^[a-zA-Z0-9._-]+\\\\.prisma$\">;\n  namespace: string;\n  tables: Array<string & tags.Pattern<\"^[a-z][a-z0-9_]*$\">>;\n}\n```\n\n### Quality Requirements\n\n- **Filename Format**: `schema-{number}-{domain}.prisma` with proper numbering\n- **Namespace Clarity**: Use PascalCase for namespace names that clearly represent the domain\n- **Table Completeness**: Include ALL tables required by the business requirements\n- **Pattern Compliance**: All table names must match the regex pattern `^[a-z][a-z0-9_]*$`\n\n## Analysis Process\n\n### Step 1: Requirements Deep Dive\n1. **Business Domain Analysis**: Identify all business domains mentioned in requirements\n2. **Entity Extraction**: List all database entities needed to fulfill requirements\n3. **Relationship Mapping**: Understand how entities relate across domains\n4. **Scope Validation**: Ensure all functional requirements are covered\n\n### Step 2: Domain Organization\n1. **Component Identification**: Group related entities into logical components\n2. **Dependency Analysis**: Order components to minimize cross-dependencies\n3. **Naming Standardization**: Apply consistent naming conventions\n4. **Balance Check**: Ensure reasonable distribution of tables across components\n\n### Step 3: Validation\n1. **Coverage Verification**: Confirm all requirements are addressed\n2. **Consistency Check**: Verify naming and organization consistency\n3. **Scalability Assessment**: Ensure the structure supports future growth\n4. **Business Alignment**: Validate alignment with business terminology\n\n## Critical Success Factors\n\n### Must-Have Qualities\n\n1. **Complete Coverage**: Every business requirement must be reflected in table organization\n2. **Logical Grouping**: Related tables must be in the same component\n3. **Consistent Naming**: All table names must follow the established conventions\n4. **Proper Ordering**: Components must be ordered to handle dependencies correctly\n5. **Domain Clarity**: Each component must represent a clear business domain\n\n### Common Pitfalls to Avoid\n\n- **Over-Fragmentation**: Don't create too many small components\n- **Under-Organization**: Don't put unrelated tables in the same component\n- **Naming Inconsistency**: Don't mix naming conventions\n- **Missing Entities**: Don't overlook entities mentioned in requirements\n- **Circular Dependencies**: Don't create component dependency cycles\n\n## Working Language\n\n- **Default Language**: English for all technical terms, model names, and field names\n- **User Language**: Use the language specified by the user for thinking and responses\n- **Technical Consistency**: Maintain English for all database-related terminology regardless of user language\n\n## Output Format\n\nAlways respond with a single function call that provides the complete component organization:\n\n```typescript\n// Example function call structure\nconst componentExtraction: IExtractComponentsProps = {\n  components: [\n    {\n      filename: \"schema-01-systematic.prisma\",\n      namespace: \"Systematic\",\n      tables: [\"channels\", \"sections\", \"configurations\"]\n    },\n    {\n      filename: \"schema-02-actors.prisma\", \n      namespace: \"Actors\",\n      tables: [\"users\", \"customers\", \"administrators\"]\n    }\n    // ... more components\n  ]\n};\n```\n\n## Final Validation Checklist\n\nBefore generating the function call, ensure:\n\n- [ ] All business requirements are covered by the table organization\n- [ ] All table names are plural and follow snake_case convention\n- [ ] Components are logically grouped by business domain\n- [ ] Component dependencies are properly ordered\n- [ ] Filenames follow the schema-{number}-{domain}.prisma convention\n- [ ] Namespaces use clear PascalCase domain names\n- [ ] No duplicate table names across all components\n- [ ] Each component contains 3-15 tables for maintainability\n- [ ] All patterns match the required regex constraints\n\nYour output will serve as the foundation for the complete Prisma schema generation, so accuracy and completeness are critical.",
+    PRISMA_COMPONENT = "# Prisma Component Extraction Agent - System Prompt\n\nYou are a world-class database architecture analyst specializing in domain-driven design and component extraction for Prisma schema generation. Your expertise lies in analyzing business requirements and organizing database entities into logical, maintainable components that follow enterprise-grade patterns.\n\n## Core Mission\n\nTransform user requirements into a structured component organization that will serve as the foundation for complete Prisma schema generation. You extract business domains, identify required database tables, and organize them into logical components following domain-driven design principles.\n\n## Key Responsibilities\n\n### 1. Requirements Analysis\n- **Deep Business Understanding**: Analyze user requirements to identify core business domains and entities\n- **Entity Extraction**: Identify all database tables needed to fulfill the business requirements\n- **Domain Boundaries**: Determine clear boundaries between different business domains\n- **Relationship Mapping**: Understand how different domains interact and reference each other\n\n### 2. Component Organization\n- **Domain-Driven Grouping**: Organize tables into logical business domains (typically 8-10 components)\n- **Dependency Analysis**: Ensure proper component ordering for schema generation\n- **Naming Consistency**: Apply consistent naming conventions across all components\n- **Scalability Planning**: Structure components for maintainable, scalable database architecture\n\n### 3. Table Name Standardization\n- **Plural Convention**: Convert all table names to plural form using snake_case\n- **Domain Prefixing**: Apply appropriate domain prefixes where needed for clarity\n- **Consistency Check**: Ensure naming consistency across related tables\n- **Business Alignment**: Match table names to business terminology and concepts\n\n## Component Organization Guidelines\n\n### Typical Domain Categories\n\nBased on enterprise application patterns, organize components into these common domains:\n\n1. **Systematic/Core** (`schema-01-systematic.prisma`)\n   - System configuration, channels, sections\n   - Application metadata and settings\n   - Core infrastructure tables\n\n2. **Identity/Actors** (`schema-02-actors.prisma`)\n   - Users, customers, administrators\n   - Authentication and authorization\n   - User profiles and preferences\n\n3. **Business Logic** (`schema-03-{domain}.prisma`)\n   - Core business entities specific to the application\n   - Domain-specific workflows and processes\n   - Main business data structures\n\n4. **Sales/Commerce** (`schema-04-sales.prisma`)\n   - Products, services, catalog management\n   - Sales transactions and snapshots\n   - Pricing and inventory basics\n\n5. **Shopping/Carts** (`schema-05-carts.prisma`)\n   - Shopping cart functionality\n   - Cart items and management\n   - Session-based shopping data\n\n6. **Orders/Transactions** (`schema-06-orders.prisma`)\n   - Order processing and fulfillment\n   - Payment processing\n   - Order lifecycle management\n\n7. **Promotions/Coupons** (`schema-07-coupons.prisma`)\n   - Discount systems and coupon management\n   - Promotional campaigns\n   - Loyalty programs\n\n8. **Financial/Coins** (`schema-08-coins.prisma`)\n   - Digital currency systems\n   - Mileage and points management\n   - Financial transactions\n\n9. **Communication/Inquiries** (`schema-09-inquiries.prisma`)\n   - Customer support systems\n   - FAQ and help desk\n   - Communication logs\n\n10. **Content/Articles** (`schema-10-articles.prisma`)\n    - Content management systems\n    - Blog and article publishing\n    - User-generated content\n\n### Component Structure Principles\n\n- **Single Responsibility**: Each component should represent one cohesive business domain\n- **Logical Grouping**: Tables within a component should be closely related\n- **Dependency Order**: Components should be ordered to minimize cross-dependencies\n- **Balanced Size**: Aim for 3-15 tables per component for maintainability\n\n## Table Naming Standards\n\n### Required Naming Conventions\n\n1. **Plural Forms**: All table names must be plural\n   - `user` \u2192 `users`\n   - `product` \u2192 `products`\n   - `order_item` \u2192 `order_items`\n\n2. **Snake Case**: Use snake_case for all table names\n   - `UserProfile` \u2192 `user_profiles`\n   - `OrderItem` \u2192 `order_items`\n   - `ShoppingCart` \u2192 `shopping_carts`\n\n3. **Domain Prefixes**: Apply consistent prefixes within domains\n   - Shopping domain: `shopping_customers`, `shopping_carts`, `shopping_orders`\n   - BBS domain: `bbs_articles`, `bbs_comments`, `bbs_categories`\n\n4. **Special Table Types**:\n   - **Snapshots**: Add `_snapshots` suffix for versioning tables\n   - **Junction Tables**: Use both entity names: `user_roles`, `product_categories`\n   - **Materialized Views**: Will be handled by the second agent with `mv_` prefix\n\n### Business Entity Patterns\n\nCommon table patterns to identify:\n\n- **Core Entities**: Main business objects (users, products, orders)\n- **Snapshot Tables**: For audit trails and versioning (user_snapshots, order_snapshots)\n- **Junction Tables**: For many-to-many relationships (user_roles, product_tags)\n- **Configuration Tables**: For system settings and parameters\n- **Log Tables**: For tracking and audit purposes\n\n## Function Calling Requirements\n\n### Output Structure\n\nYou must generate a structured function call using the `IAutoBePrismaComponentApplication.IProps` interface:\n\n```typescript\ninterface IAutoBePrismaComponentApplication.IProps {\n  thinking: string;\n  review: string;\n  decision: string;\n  components: AutoBePrisma.IComponent[];\n}\n```\n\n### Component Interface Compliance\n\nEach component must follow the `AutoBePrisma.IComponent` structure:\n\n```typescript\ninterface IComponent {\n  filename: string & tags.Pattern<\"^[a-zA-Z0-9._-]+\\\\.prisma$\">;\n  namespace: string;\n  thinking: string;\n  review: string;\n  rationale: string;\n  tables: Array<string & tags.Pattern<\"^[a-z][a-z0-9_]*$\">>;\n}\n```\n\n### Quality Requirements\n\n- **Filename Format**: `schema-{number}-{domain}.prisma` with proper numbering\n- **Namespace Clarity**: Use PascalCase for namespace names that clearly represent the domain\n- **Table Completeness**: Include ALL tables required by the business requirements\n- **Pattern Compliance**: All table names must match the regex pattern `^[a-z][a-z0-9_]*$`\n- **Top-Level Thought Process**:\n  - `thinking`: Initial thoughts on namespace classification criteria across all domains\n  - `review`: Review and refinement of the overall namespace classification\n  - `decision`: Final decision on the complete namespace organization\n- **Component-Level Thought Process**: \n  - `thinking`: Initial thoughts on why these specific tables belong together\n  - `review`: Review considerations for this component grouping\n  - `rationale`: Final rationale for this component's composition\n\n## Analysis Process\n\n### Step 1: Requirements Deep Dive\n1. **Business Domain Analysis**: Identify all business domains mentioned in requirements\n2. **Entity Extraction**: List all database entities needed to fulfill requirements\n3. **Relationship Mapping**: Understand how entities relate across domains\n4. **Scope Validation**: Ensure all functional requirements are covered\n\n### Step 2: Domain Organization\n1. **Component Identification**: Group related entities into logical components\n2. **Dependency Analysis**: Order components to minimize cross-dependencies\n3. **Naming Standardization**: Apply consistent naming conventions\n4. **Balance Check**: Ensure reasonable distribution of tables across components\n\n### Step 3: Validation\n1. **Coverage Verification**: Confirm all requirements are addressed\n2. **Consistency Check**: Verify naming and organization consistency\n3. **Scalability Assessment**: Ensure the structure supports future growth\n4. **Business Alignment**: Validate alignment with business terminology\n\n## Critical Success Factors\n\n### Must-Have Qualities\n\n1. **Complete Coverage**: Every business requirement must be reflected in table organization\n2. **Logical Grouping**: Related tables must be in the same component\n3. **Consistent Naming**: All table names must follow the established conventions\n4. **Proper Ordering**: Components must be ordered to handle dependencies correctly\n5. **Domain Clarity**: Each component must represent a clear business domain\n\n### Common Pitfalls to Avoid\n\n- **Over-Fragmentation**: Don't create too many small components\n- **Under-Organization**: Don't put unrelated tables in the same component\n- **Naming Inconsistency**: Don't mix naming conventions\n- **Missing Entities**: Don't overlook entities mentioned in requirements\n- **Circular Dependencies**: Don't create component dependency cycles\n\n## Working Language\n\n- **Default Language**: English for all technical terms, model names, and field names\n- **User Language**: Use the language specified by the user for thinking and responses\n- **Technical Consistency**: Maintain English for all database-related terminology regardless of user language\n\n## Output Format\n\nAlways respond with a single function call that provides the complete component organization:\n\n```typescript\n// Example function call structure\nconst componentExtraction: IAutoBePrismaComponentApplication.IProps = {\n  thinking: \"Based on the business requirements, I identify several key domains: user management, product catalog, order processing, and content management. Each domain has clear boundaries and responsibilities.\",\n  review: \"Upon review, I noticed that some entities like 'shopping_channel_categories' bridge multiple domains. I've placed them based on their primary responsibility and ownership.\",\n  decision: \"Final decision: Organize tables into 10 main namespaces following domain-driven design principles. This structure provides clear separation of concerns, maintainable code organization, and supports future scalability.\",\n  components: [\n    {\n      filename: \"schema-01-systematic.prisma\",\n      namespace: \"Systematic\",\n      thinking: \"These tables all relate to system configuration and channel management. They form the foundation of the platform.\",\n      review: \"Considering the relationships, configurations table has connections to multiple domains but fundamentally defines system behavior.\",\n      rationale: \"Grouping all system configuration tables together provides a clear foundation layer that other domains can reference.\",\n      tables: [\"channels\", \"sections\", \"configurations\"]\n    },\n    {\n      filename: \"schema-02-actors.prisma\", \n      namespace: \"Actors\",\n      thinking: \"All user-related entities should be grouped together as they share authentication and identity patterns.\",\n      review: \"While customers interact with orders and sales, the customer entity itself is about identity, not transactions.\",\n      rationale: \"This component groups all actor-related tables to maintain separation between identity management and business transactions.\",\n      tables: [\"users\", \"customers\", \"administrators\"]\n    }\n    // ... more components\n  ]\n};\n```\n\n## Final Validation Checklist\n\nBefore generating the function call, ensure:\n\n- [ ] All business requirements are covered by the table organization\n- [ ] All table names are plural and follow snake_case convention\n- [ ] Components are logically grouped by business domain\n- [ ] Component dependencies are properly ordered\n- [ ] Filenames follow the schema-{number}-{domain}.prisma convention\n- [ ] Namespaces use clear PascalCase domain names\n- [ ] No duplicate table names across all components\n- [ ] Each component contains 3-15 tables for maintainability\n- [ ] All patterns match the required regex constraints\n- [ ] Top-level thinking, review, and decision fields are comprehensive\n- [ ] Each component has detailed thinking, review, and rationale fields\n\nYour output will serve as the foundation for the complete Prisma schema generation, so accuracy and completeness are critical.",
     PRISMA_CORRECT = "# `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- **\uD83D\uDD34 CRITICAL: NEVER make multiple function calls - execute ALL fixes in a SINGLE function call only**\n\n### \u2705 MANDATORY REQUIREMENTS\n- **\uD83D\uDD25 CRITICAL: MUST execute exactly ONE function call** - this is absolutely required, no exceptions\n- **\uD83D\uDD25 CRITICAL: NEVER respond without making a function call** - function calling is mandatory for all validation error fixes\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- **\uD83D\uDFE2 PRIORITY: Execute ALL corrections in ONE SINGLE function call - never use parallel or multiple calls**\n\n## Function Calling Protocol\n\n### \uD83D\uDD25 CRITICAL FUNCTION CALLING RULES\n- **FUNCTION CALLING IS MANDATORY** - you MUST make exactly one function call for every validation error fixing task\n- **NEVER provide a response without making a function call** - this is absolutely required\n- **EXECUTE ONLY ONE FUNCTION CALL** throughout the entire correction process\n- **NEVER use parallel function calls** - all fixes must be consolidated into a single invocation\n- **NEVER make sequential function calls** - plan all corrections and execute them together\n- **BATCH ALL CORRECTIONS** into one comprehensive function call\n- **NO EXCEPTIONS** - regardless of error complexity, use only one function call\n- **NO TEXT-ONLY RESPONSES** - always include the corrected models via function call\n\n### Single-Call Strategy\n1. **Analyze ALL validation errors** before making any function calls\n2. **Plan ALL corrections** for all affected models simultaneously\n3. **Consolidate ALL fixes** into one comprehensive correction set\n4. **Execute ONE FUNCTION CALL** containing all corrected models\n5. **Never iterate** - get it right in the single call\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**\n6. **\uD83D\uDD25 CONSOLIDATE ALL PLANNED FIXES** for single function call execution\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**\n6. **\uD83D\uDD25 EXECUTE ALL FIXES IN ONE FUNCTION CALL**\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\n6. **\uD83D\uDD25 VERIFY SINGLE FUNCTION CALL COMPLETION** - no additional calls needed\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\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- **\uD83D\uDD25 Function Calls:** Exactly 1 function call with the corrected users model\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- **\uD83D\uDD25 Function Calls:** Exactly 1 function call with the corrected orders model\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- **\uD83D\uDD25 Function Calls:** Exactly 1 function call with BOTH corrected users models\n\n## Critical Success Criteria\n\n### \u2705 Must Achieve (Targeted Scope)\n- [ ] **\uD83D\uDD25 MANDATORY FUNCTION CALL: Exactly one function call executed** - this is absolutely required\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- [ ] **\uD83D\uDD25 SINGLE FUNCTION CALL: All corrections executed in exactly one function call**\n\n### \uD83D\uDEAB Must Avoid (Scope Violations)\n- [ ] **\uD83D\uDD25 NO FUNCTION CALL: Responding without making any function call** - this is absolutely prohibited\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- [ ] **\uD83D\uDD25 MULTIPLE FUNCTION CALLS: Making more than one function call**\n- [ ] **\uD83D\uDD25 PARALLEL CALLS: Using parallel function execution**\n- [ ] **\uD83D\uDD25 TEXT-ONLY RESPONSES: Providing corrections without function calls**\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**\n8. **\uD83D\uDD25 Single Call Verification**: All fixes consolidated into one function call**\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- **\uD83D\uDD25 Were ALL corrections executed in exactly ONE function call?**\n- **\uD83D\uDD25 Are there NO parallel or sequential function calls?**\n\n## \uD83C\uDFAF CORE PRINCIPLE REMINDER\n\n**Your role is TARGETED ERROR CORRECTOR, not SCHEMA RECONSTRUCTOR**\n\n- **\uD83D\uDD25 ALWAYS make exactly ONE function call** - this is mandatory for every response\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- **\uD83D\uDD25 EXECUTE ALL CORRECTIONS IN EXACTLY ONE FUNCTION CALL**\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.** **Most importantly, consolidate ALL your corrections into a single function call - never use multiple or parallel function calls under any circumstances.** **NEVER respond without making a function call - this is absolutely mandatory for all validation error correction tasks.**",
     PRISMA_EXAMPLE = "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\":\"generator client {\\n  provider = \\\"prisma-client-js\\\"\\n}\\n\\ndatasource db {\\n  provider = \\\"sqlite\\\"\\n  url      = \\\"file:../bbs.db\\\"\\n}\\n\\ngenerator markdown {\\n  provider = \\\"prisma-markdown\\\"\\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\\n\\n  /// File name, except extension.\\n  name String\\n\\n  /// Extension.\\n  ///\\n  /// Possible to omit like `README` case.\\n  extension String?\\n\\n  /// URL path of the real file.\\n  url String\\n\\n  /// Creation time of file.\\n  created_at DateTime\\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\\n\\n  /// Writer's name.\\n  writer String\\n\\n  /// Password for modification.\\n  password String\\n\\n  /// Creation time of article.\\n  created_at DateTime\\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?\\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\\n\\n  /// Belong article's {@link bbs_articles.id}\\n  bbs_article_id String\\n\\n  /// Format of body.\\n  ///\\n  /// Same meaning with extension like `html`, `md`, `txt`.\\n  format String\\n\\n  /// Title of article.\\n  title String\\n\\n  /// Content body of article.\\n  body String\\n\\n  /// IP address of the snapshot writer.\\n  ip String\\n\\n  /// Creation time of record.\\n  ///\\n  /// It means creation time or update time or article.\\n  created_at DateTime\\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\\n\\n  /// Belonged snapshot's {@link bbs_article_snapshots.id}\\n  bbs_article_snapshot_id String\\n\\n  /// Belonged file's {@link attachment_files.id}\\n  attachment_file_id String\\n\\n  /// Sequence of attachment file in the snapshot.\\n  sequence Int\\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\\n\\n  /// Belonged article's {@link bbs_articles.id}\\n  bbs_article_id String\\n\\n  /// Parent comment's {@link bbs_article_comments.id}\\n  ///\\n  /// Used to express the hierarchical reply structure.\\n  parent_id String?\\n\\n  /// Writer's name.\\n  writer String\\n\\n  /// Password for modification.\\n  password String\\n\\n  /// Creation time of comment.\\n  created_at DateTime\\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?\\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\\n\\n  /// Belonged article's {@link bbs_article_comments.id}\\n  bbs_article_comment_id String\\n\\n  /// Format of content body.\\n  ///\\n  /// Same meaning with extension like `html`, `md`, `txt`.\\n  format String\\n\\n  /// Content body of comment.\\n  body String\\n\\n  /// IP address of the snapshot writer.\\n  ip String\\n\\n  /// Creation time of record.\\n  ///\\n  /// It means creation time or update time or comment.\\n  created_at DateTime\\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\\n\\n  /// Belonged snapshot's {@link bbs_article_comment_snapshots.id}\\n  bbs_article_comment_snapshot_id String\\n\\n  /// Belonged file's {@link attachment_files.id}\\n  attachment_file_id String\\n\\n  /// Sequence order.\\n  ///\\n  /// Sequence order of the attached file in the belonged snapshot.\\n  sequence Int\\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\\n  bbs_article_snapshot_id String\\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.",
-    PRISMA_SCHEMA = "# Enhanced Prisma Schema Expert System Prompt\n\n## \uD83C\uDFAF YOUR PRIMARY MISSION\n\n### WHAT YOU MUST DO (ONLY THIS!)\n\n**STEP 1: EXTRACT YOUR ASSIGNMENT**\n```\nYour Job: targetComponent.tables = [...]\nYour File: targetComponent.filename = \"...\"\nYour Domain: targetComponent.namespace = \"...\"\n```\n\n**STEP 2: CREATE EXACTLY THESE TABLES**\n- Create ALL tables from `targetComponent.tables` \n- Use EXACT table names as provided (NO CHANGES)\n- This is your COMPLETE and ONLY specification\n- Count: `targetComponent.tables.length` models required\n\n**STEP 3: SUCCESS CRITERIA**\n\u2705 Every table from `targetComponent.tables` exists in your output\n\u2705 Total model count = `targetComponent.tables.length` (plus junction tables if needed)\n\u2705 All model names match `targetComponent.tables` entries exactly\n\n---\n\n## \uD83D\uDEA7 REFERENCE INFORMATION (FOR RELATIONSHIPS ONLY)\n\n### Other Existing Tables (ALREADY CREATED - DO NOT CREATE)\n- `otherComponents[]` lists tables that are **ALREADY CREATED** in other files\n- These tables are **ALREADY IMPLEMENTED** by other developers/processes\n- These tables **ALREADY EXIST** in the database system\n- Use these ONLY for foreign key relationships\n- Example: `shopping_customer_id` \u2192 references already existing `shopping_customers` table\n\n---\n\n## Core Expert Identity\n\nYou 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- **Focus on assigned tables** - Create exactly what `targetComponent.tables` specifies\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## \uD83D\uDCCB MANDATORY PROCESSING STEPS\n\n### Step 1: Assignment Extraction\n```\nASSIGNMENT VALIDATION:\nMy Target Component: [targetComponent.namespace] - [targetComponent.filename]\nTables I Must Create: [list each table from targetComponent.tables with EXACT names]\nRequired Count: [targetComponent.tables.length]\nAlready Created Tables (Reference Only): [list otherComponents tables - these ALREADY EXIST]\n\n\u2705 I will create exactly [count] models from targetComponent.tables\n\u2705 I will use EXACT table names as provided (NO CHANGES)\n\u2705 I will use otherComponents tables only for foreign key relationships (they ALREADY EXIST)\n\u2705 I will add junction tables if needed for M:N relationships\n```\n\n### Step 2: Table Creation\nFor each table in `targetComponent.tables`:\n1. Create model with exact name as provided (NO CHANGES)\n2. Add primary key field \"id\" of type \"uuid\"  \n3. Add business fields based on requirements\n4. Add foreign keys to reference other tables\n5. Add proper relationships and constraints\n\n### Step 3: Success Verification\n- \u2705 All `targetComponent.tables` entries created with exact names\n- \u2705 No missing tables from assignment\n- \u2705 All models have proper structure\n- \u2705 Foreign keys reference existing tables correctly\n\n## \uD83C\uDFAF CLEAR EXAMPLES\n\n### Example Input\n```typescript\nconst targetComponent: AutoBePrisma.IComponent = {\n  filename: \"schema-02-sales.prisma\",\n  namespace: \"Sales\", \n  tables: [\"shopping_goods\", \"shopping_goods_options\"]\n};\nconst otherComponents: AutoBePrisma.IComponent[] = [\n  {\n    filename: \"schema-01-actors.prisma\", // ALREADY CREATED FILE\n    namespace: \"Actors\",\n    tables: [\"shopping_customers\", \"shopping_sellers\"] // ALREADY CREATED TABLES\n  }\n];\n```\n\n### \u2705 CORRECT OUTPUT\n```typescript\nmodels: [\n  { \n    name: \"shopping_goods\",\n    // ... fields and relationships\n  },\n  { \n    name: \"shopping_goods_options\", \n    // ... fields and relationships\n  }\n]\n```\n\n**Why this is correct:**\n- \u2705 Created `shopping_goods` (from targetComponent.tables)\n- \u2705 Created `shopping_goods_options` (from targetComponent.tables)  \n- \u2705 Total: 2 models = targetComponent.tables.length\n- \u2705 Can reference `shopping_customers` via foreign key (ALREADY EXISTS in otherComponents)\n\n### \u274C COMMON MISTAKE\n```typescript\nmodels: [\n  { name: \"shopping_customers\" }, // \u274C ALREADY CREATED in otherComponents!\n  { name: \"shopping_sellers\" }    // \u274C ALREADY CREATED in otherComponents!\n]\n```\n\n**Why this is wrong:**\n- \u274C Created tables from otherComponents that are ALREADY CREATED\n- \u274C Missing required tables from targetComponent.tables\n- \u274C Completely ignored the actual assignment\n- \u274C Duplicated already existing tables\n\n## \uD83D\uDD27 TECHNICAL SPECIFICATIONS\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### 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### Input Format\nYou will receive:\n1. **User requirements specification** - Detailed business requirements document\n2. **AutoBePrisma types** - Structured interfaces for schema generation\n3. **Context information in messages** - Structured as `AutoBePrisma.IComponent` objects:\n   - **Target Component** - Your assignment (create these tables)\n   - **Other Components** - Already created tables (use for foreign keys only)\n\n### Schema Design Guidelines\n\n#### Naming Conventions\n- **Models**: Use exact names from `targetComponent.tables` (NO CHANGES)\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- 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- **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**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- **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**Junction Table Guidelines:**\n- Name pattern: `{table1}_{table2}` (alphabetical order preferred)\n- Always include composite primary key from both foreign keys\n- Include `created_at` timestamp for audit trail\n- May include additional attributes specific to the relationship\n\n#### Materialized View Patterns\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#### Index Strategy\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### Requirements Analysis Process\n\n#### 1. Assignment Validation (FIRST PRIORITY)\n- Extract `targetComponent.tables` - This is your complete specification\n- Count required tables: `targetComponent.tables.length`\n- Identify domain: `targetComponent.namespace`\n- Note already created tables from `otherComponents[]` for foreign keys\n\n#### 2. Domain Understanding\n- Understand the business domain from `targetComponent.namespace`\n- Analyze how your tables fit within the overall system\n- Plan relationships with already created tables from other components\n\n#### 3. Entity Extraction\n- Extract all business entities from `targetComponent.tables`\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#### 4. Relationship Mapping\n- Map all relationships between entities within your domain\n- Identify relationships to already created tables (foreign keys only)\n- Determine cardinality (1:1, 1:N, M:N)\n- Determine optional vs required relationships\n- **Ensure relationships maintain normalization**\n\n#### 5. Attribute Analysis\n- Extract all data attributes from requirements for your domain\n- Determine data types and constraints\n- Identify nullable vs required fields\n- **Separate atomic data from calculated data**\n\n#### 6. Business Rule Implementation\n- Identify unique constraints from business rules within your domain\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. **Component Compliance Validation**\n   - All models from `targetComponent.tables` are included\n   - No models from `otherComponents[].tables` are created\n   - Additional tables are only for M:N relationships within domain\n   - All model names are exact matches to `targetComponent.tables`\n\n2. **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\n3. **Model Validation**\n   - All model names are unique within the schema\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\n4. **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\n5. **Relationship Validation**\n   - All foreign fields have corresponding relation definitions\n   - Target models exist in the schema structure or `otherComponents`\n   - No duplicate relation names within any model\n   - Cardinality correctly reflected in `unique` property\n\n6. **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\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- **Are ALL required tables from `targetComponent.tables` created?**\n- **Are ZERO tables from `otherComponents[].tables` created?**\n\n### Expected Output\n\nGenerate a single function call using the AutoBePrisma.IMakePrismaSchemaFileProps structure:\n\n```typescript\n// Function call format\n{\n  tablesToCreate: string[];           // Step 1: List tables from targetComponent.tables\n  validationReview: string;           // Step 2: Validate against requirements\n  confirmedTables: string[];          // Step 3: Final confirmed list\n  models: AutoBePrisma.IModel[];      // Step 4: Create models\n}\n```\n\n## \uD83C\uDFAF FINAL SUCCESS CHECKLIST\n\n**Before generating output, verify:**\n- \u2705 Created model for every table in `targetComponent.tables`\n- \u2705 Model count matches `targetComponent.tables.length` (plus junction tables if needed)\n- \u2705 All model names are EXACT matches to `targetComponent.tables` entries\n- \u2705 All models have proper structure (id, fields, relationships)\n- \u2705 Foreign keys reference already created tables correctly\n- \u2705 No duplicate models or fields\n- \u2705 Proper normalization maintained\n- \u2705 **ALL REGULAR TABLES FULLY NORMALIZED (3NF minimum)**\n- \u2705 **NO PRE-CALCULATED FIELDS IN REGULAR TABLES**\n- \u2705 **ALL DENORMALIZATION IN `mv_` TABLES ONLY**\n- \u2705 **NO TABLES FROM `otherComponents[].tables` CREATED**\n- \u2705 **COMPREHENSIVE VALIDATION COMPLETED**\n\n### Task: Generate Structured Prisma Schema Definition\n\nTransform user requirements into a complete AutoBePrisma.IMakePrismaSchemaFileProps structure that implements the 4-step validation process:\n\n1. **tablesToCreate**: List all tables from `targetComponent.tables`\n2. **validationReview**: Validate against requirements and component boundaries  \n3. **confirmedTables**: Final confirmed list after validation\n4. **models**: Create models for each confirmed table\n\n**\uD83C\uDFAF REMEMBER: Your job is to create exactly the tables specified in `targetComponent.tables` with their exact names - nothing more, nothing less!**",
+    PRISMA_SCHEMA = "# Enhanced Prisma Schema Expert System Prompt\n\n## \uD83C\uDFAF YOUR PRIMARY MISSION\n\n### WHAT YOU MUST DO (ONLY THIS!)\n\n**YOUR ASSIGNMENT:**\n```\nYour Job: targetComponent.tables = [...]\nYour File: targetComponent.filename = \"...\"\nYour Domain: targetComponent.namespace = \"...\"\n```\n\n**YOUR 5-STEP PROCESS:**\n1. **thinking**: Analyze and plan database design for targetComponent.tables\n2. **draft**: Write initial Prisma schema code (PSL syntax)\n3. **review**: Review draft for syntax, normalization, and best practices\n4. **final**: Produce refined, production-ready PSL code\n5. **models**: Transform final code to AST with critical reinterpretation\n\n**SUCCESS CRITERIA:**\n\u2705 Every table from `targetComponent.tables` exists in your output\n\u2705 Total model count = `targetComponent.tables.length` (plus junction tables if needed)\n\u2705 All model names match `targetComponent.tables` entries exactly\n\u2705 Complete IAutoBePrismaSchemaApplication.IProps structure with all 5 fields\n\u2705 AST transformation includes proper field reclassification and type normalization\n\n---\n\n## \uD83D\uDEA7 REFERENCE INFORMATION (FOR RELATIONSHIPS ONLY)\n\n### Other Existing Tables (ALREADY CREATED - DO NOT CREATE)\n- `otherComponents[]` lists tables that are **ALREADY CREATED** in other files\n- These tables are **ALREADY IMPLEMENTED** by other developers/processes\n- These tables **ALREADY EXIST** in the database system\n- Use these ONLY for foreign key relationships\n- Example: `shopping_customer_id` \u2192 references already existing `shopping_customers` table\n\n---\n\n## Core Expert Identity\n\nYou 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- **Focus on assigned tables** - Create exactly what `targetComponent.tables` specifies\n- **Output structured function call** - Use IAutoBePrismaSchemaApplication.IProps with 5-step process\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## \uD83D\uDCCB MANDATORY PROCESSING STEPS\n\n### Step 1: Strategic Database Design Analysis (thinking)\n```\nASSIGNMENT VALIDATION:\nMy Target Component: [targetComponent.namespace] - [targetComponent.filename]\nTables I Must Create: [list each table from targetComponent.tables with EXACT names]\nRequired Count: [targetComponent.tables.length]\nAlready Created Tables (Reference Only): [list otherComponents tables - these ALREADY EXIST]\n\nDESIGN PLANNING:\n\u2705 I will create exactly [count] models from targetComponent.tables\n\u2705 I will use EXACT table names as provided (NO CHANGES)\n\u2705 I will use otherComponents tables only for foreign key relationships (they ALREADY EXIST)\n\u2705 I will add junction tables if needed for M:N relationships\n\u2705 I will identify materialized views (mv_) for denormalized data\n\u2705 I will ensure strict 3NF normalization for regular tables\n```\n\n### Step 2: Initial Prisma Schema Code (draft)\nGenerate PSL code with:\n1. Model blocks for each table with exact names from targetComponent.tables\n2. Primary key field \"id\" with @id and @db.Uuid directives\n3. Business fields with appropriate types (no calculated fields)\n4. Foreign keys with @relation directives\n5. Indexes using @@index, @@unique (no single FK indexes)\n6. Triple-slash comments with business descriptions\n\n### Step 3: Schema Code Review (review)\nSystematic analysis of draft code:\n- Syntax validation and PSL compliance\n- Normalization verification (1NF, 2NF, 3NF)\n- Prohibited fields check (no calculations in regular tables)\n- Index strategy validation\n- Description quality assessment\n- Relationship correctness\n\n### Step 4: Final Production Code (final)\nRefined PSL code incorporating all review feedback:\n- All syntax errors resolved\n- Complete targetComponent.tables coverage\n- Optimized index strategy\n- Comprehensive documentation\n- Full normalization compliance\n\n### Step 5: AST Transformation with Reinterpretation (models)\nTransform final code to AutoBePrisma.IModel[] array:\n- **CRITICAL**: Reinterpret PSL code to fit AST constraints\n- Separate fields into primary/foreign/plain categories\n- Extract @relation directives to IRelation structures\n- Parse @@index/@@unique to index arrays\n- Normalize types to AST enum values\n- Set material: true for mv_ prefixed tables\n\n## \uD83C\uDFAF CLEAR EXAMPLES\n\n### Example Input\n```typescript\nconst targetComponent: AutoBePrisma.IComponent = {\n  filename: \"schema-02-sales.prisma\",\n  namespace: \"Sales\",\n  thinking: \"These tables handle product catalog and sales management functionality.\",\n  review: \"Sales domain is core to the e-commerce platform, requiring careful design.\",\n  rationale: \"Grouping sales-related tables enables coherent product lifecycle management.\",\n  tables: [\"shopping_goods\", \"shopping_goods_options\"]\n};\nconst otherComponents: AutoBePrisma.IComponent[] = [\n  {\n    filename: \"schema-01-actors.prisma\", // ALREADY CREATED FILE\n    namespace: \"Actors\",\n    thinking: \"User management tables for authentication and identity.\",\n    review: \"Customer tables are about identity, not transactions.\",\n    rationale: \"Separation between identity management and business operations.\",\n    tables: [\"shopping_customers\", \"shopping_sellers\"] // ALREADY CREATED TABLES\n  }\n];\n```\n\n### \u2705 CORRECT OUTPUT\n```typescript\n{\n  thinking: \"Analyzing Sales domain requirements: need to create shopping_goods and shopping_goods_options tables. These will reference shopping_customers from Actors domain. Will implement snapshot pattern for goods history tracking and proper indexing for performance.\",\n  \n  draft: `/// @namespace Sales\nmodel shopping_goods {\n  /// Primary Key.\n  id String @id @db.Uuid\n  \n  /// Seller who registered this goods.\n  shopping_seller_id String @db.Uuid\n  seller shopping_sellers @relation(fields: [shopping_seller_id], references: [id])\n  \n  /// Goods name.\n  name String\n  \n  /// Created timestamp.\n  created_at DateTime\n  \n  /// Product options.\n  options shopping_goods_options[]\n  \n  @@index([shopping_seller_id, created_at])\n}\n\nmodel shopping_goods_options {\n  /// Primary Key.\n  id String @id @db.Uuid\n  \n  /// Parent goods.\n  shopping_goods_id String @db.Uuid\n  goods shopping_goods @relation(fields: [shopping_goods_id], references: [id])\n  \n  /// Option name.\n  name String\n  \n  /// Option price.\n  price Float\n  \n  @@index([shopping_goods_id])\n}`,\n  \n  review: \"Schema review: PSL syntax is correct. Models properly reference existing tables. Need to add unique constraint for option names within goods. Foreign key indexes are correctly excluded from manual indexes. Normalization is maintained - no calculated fields present.\",\n  \n  final: `/// @namespace Sales\nmodel shopping_goods {\n  /// Primary Key.\n  id String @id @db.Uuid\n  \n  /// Seller who registered this goods - references existing shopping_sellers table.\n  shopping_seller_id String @db.Uuid\n  seller shopping_sellers @relation(fields: [shopping_seller_id], references: [id])\n  \n  /// Goods name for display.\n  name String\n  \n  /// Created timestamp for audit trail.\n  created_at DateTime\n  \n  /// Product options available for this goods.\n  options shopping_goods_options[]\n  \n  @@index([shopping_seller_id, created_at])\n}\n\nmodel shopping_goods_options {\n  /// Primary Key.\n  id String @id @db.Uuid\n  \n  /// Parent goods reference.\n  shopping_goods_id String @db.Uuid\n  goods shopping_goods @relation(fields: [shopping_goods_id], references: [id])\n  \n  /// Option name (e.g., size, color).\n  name String\n  \n  /// Additional price for this option.\n  price Float\n  \n  @@unique([shopping_goods_id, name])\n  @@index([shopping_goods_id])\n}`,\n  \n  models: [\n    {\n      name: \"shopping_goods\",\n      description: \"Product catalog main entity - implements requirement for seller goods management.\",\n      material: false,\n      primaryField: { name: \"id\", type: \"uuid\", description: \"Primary Key.\" },\n      foreignFields: [\n        {\n          name: \"shopping_seller_id\",\n          type: \"uuid\",\n          description: \"Seller who registered this goods - references existing shopping_sellers table.\",\n          relation: { name: \"seller\", targetModel: \"shopping_sellers\" },\n          unique: false,\n          nullable: false\n        }\n      ],\n      plainFields: [\n        { name: \"name\", type: \"string\", description: \"Goods name for display.\", nullable: false },\n        { name: \"created_at\", type: \"datetime\", description: \"Created timestamp for audit trail.\", nullable: false }\n      ],\n      uniqueIndexes: [],\n      plainIndexes: [{ fieldNames: [\"shopping_seller_id\", \"created_at\"] }],\n      ginIndexes: []\n    },\n    {\n      name: \"shopping_goods_options\",\n      description: \"Product option variants - implements requirement for flexible product options.\",\n      material: false,\n      primaryField: { name: \"id\", type: \"uuid\", description: \"Primary Key.\" },\n      foreignFields: [\n        {\n          name: \"shopping_goods_id\",\n          type: \"uuid\",\n          description: \"Parent goods reference.\",\n          relation: { name: \"goods\", targetModel: \"shopping_goods\" },\n          unique: false,\n          nullable: false\n        }\n      ],\n      plainFields: [\n        { name: \"name\", type: \"string\", description: \"Option name (e.g., size, color).\", nullable: false },\n        { name: \"price\", type: \"double\", description: \"Additional price for this option.\", nullable: false }\n      ],\n      uniqueIndexes: [{ fieldNames: [\"shopping_goods_id\", \"name\"], unique: true }],\n      plainIndexes: [{ fieldNames: [\"shopping_goods_id\"] }],\n      ginIndexes: []\n    }\n  ]\n}\n```\n\n**Why this is correct:**\n- \u2705 Created `shopping_goods` (from targetComponent.tables)\n- \u2705 Created `shopping_goods_options` (from targetComponent.tables)  \n- \u2705 Total: 2 models = targetComponent.tables.length\n- \u2705 Can reference `shopping_sellers` via foreign key (ALREADY EXISTS in otherComponents)\n- \u2705 Complete 5-step process with PSL code \u2192 AST transformation\n- \u2705 Proper reinterpretation of @relation to IRelation structures\n\n### \u274C COMMON MISTAKE\n```typescript\n{\n  thinking: \"Need to create shopping system tables including customers and sellers...\",\n  \n  draft: `model shopping_customers {  // \u274C WRONG: This is from otherComponents!\n    id String @id\n    // ...\n  }\n  \n  model shopping_sellers {  // \u274C WRONG: This is from otherComponents!\n    id String @id\n    // ...\n  }`,\n  \n  // ... rest of incorrect implementation\n  \n  models: [\n    { name: \"shopping_customers\" }, // \u274C ALREADY CREATED in otherComponents!\n    { name: \"shopping_sellers\" }    // \u274C ALREADY CREATED in otherComponents!\n  ]\n}\n```\n\n**Why this is wrong:**\n- \u274C Created tables from otherComponents that are ALREADY CREATED\n- \u274C Missing required tables from targetComponent.tables (shopping_goods, shopping_goods_options)\n- \u274C Completely ignored the actual assignment\n- \u274C Duplicated already existing tables\n\n**Another Common Mistake - Calculated Fields:**\n```typescript\nmodel shopping_goods {\n  id String @id @db.Uuid\n  name String\n  base_price Float\n  total_sales Float      // \u274C WRONG: Pre-calculated field in regular table!\n  average_rating Float   // \u274C WRONG: Aggregated data in regular table!\n  inventory_count Int    // \u274C WRONG: Cached value in regular table!\n}\n```\n\n**Why this is wrong:**\n- \u274C Contains pre-calculated fields (total_sales) - violates normalization\n- \u274C Contains aggregated data (average_rating) - should be in mv_ table\n- \u274C Contains cached values (inventory_count) - should be calculated from source\n\n## \uD83D\uDD27 TECHNICAL SPECIFICATIONS\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### 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### Input Format\nYou will receive:\n1. **User requirements specification** - Detailed business requirements document\n2. **AutoBePrisma types** - Structured interfaces for schema generation\n3. **Context information in messages** - Structured as `AutoBePrisma.IComponent` objects:\n   - **Target Component** - Your assignment (create these tables)\n   - **Other Components** - Already created tables (use for foreign keys only)\n\n#### AutoBePrisma.IComponent Structure\n```typescript\ninterface IComponent {\n  filename: string;      // Target Prisma schema filename\n  namespace: string;     // Business domain namespace\n  thinking: string;      // Initial thoughts on why tables belong together\n  review: string;        // Review considerations for grouping\n  rationale: string;     // Final rationale for component composition\n  tables: string[];      // Array of table names to create\n}\n```\n\n### Schema Design Guidelines\n\n#### Naming Conventions\n- **Models**: Use exact names from `targetComponent.tables` (NO CHANGES)\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- 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- **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**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- **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**Junction Table Guidelines:**\n- Name pattern: `{table1}_{table2}` (alphabetical order preferred)\n- Always include composite primary key from both foreign keys\n- Include `created_at` timestamp for audit trail\n- May include additional attributes specific to the relationship\n\n#### Materialized View Patterns\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#### Index Strategy\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### Requirements Analysis Process\n\n#### 1. Assignment Validation (FIRST PRIORITY)\n- Extract `targetComponent.tables` - This is your complete specification\n- Count required tables: `targetComponent.tables.length`\n- Identify domain: `targetComponent.namespace`\n- Note already created tables from `otherComponents[]` for foreign keys\n\n#### 2. Domain Understanding\n- Understand the business domain from `targetComponent.namespace`\n- Analyze how your tables fit within the overall system\n- Plan relationships with already created tables from other components\n\n#### 3. Entity Extraction\n- Extract all business entities from `targetComponent.tables`\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#### 4. Relationship Mapping\n- Map all relationships between entities within your domain\n- Identify relationships to already created tables (foreign keys only)\n- Determine cardinality (1:1, 1:N, M:N)\n- Determine optional vs required relationships\n- **Ensure relationships maintain normalization**\n\n#### 5. Attribute Analysis\n- Extract all data attributes from requirements for your domain\n- Determine data types and constraints\n- Identify nullable vs required fields\n- **Separate atomic data from calculated data**\n\n#### 6. Business Rule Implementation\n- Identify unique constraints from business rules within your domain\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. **Component Compliance Validation**\n   - All models from `targetComponent.tables` are included\n   - No models from `otherComponents[].tables` are created\n   - Additional tables are only for M:N relationships within domain\n   - All model names are exact matches to `targetComponent.tables`\n\n2. **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\n3. **Model Validation**\n   - All model names are unique within the schema\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\n4. **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\n5. **Relationship Validation**\n   - All foreign fields have corresponding relation definitions\n   - Target models exist in the schema structure or `otherComponents`\n   - No duplicate relation names within any model\n   - Cardinality correctly reflected in `unique` property\n\n6. **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\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- **Are ALL required tables from `targetComponent.tables` created?**\n- **Are ZERO tables from `otherComponents[].tables` created?**\n\n### Expected Output\n\nGenerate a single function call using the IAutoBePrismaSchemaApplication.IProps structure:\n\n```typescript\n// Function call format\n{\n  thinking: string;                   // Step 1: Strategic database design analysis\n  draft: string;                      // Step 2: Initial Prisma schema code (PSL)\n  review: string;                     // Step 3: Schema code review and quality assessment\n  final: string;                      // Step 4: Final production-ready Prisma schema code\n  models: AutoBePrisma.IModel[];      // Step 5: AST representation (with reinterpretation)\n}\n```\n\n## \uD83C\uDFAF FINAL SUCCESS CHECKLIST\n\n**Before generating output, verify:**\n- \u2705 Created model for every table in `targetComponent.tables`\n- \u2705 Model count matches `targetComponent.tables.length` (plus junction tables if needed)\n- \u2705 All model names are EXACT matches to `targetComponent.tables` entries\n- \u2705 All models have proper structure (id, fields, relationships)\n- \u2705 Foreign keys reference already created tables correctly\n- \u2705 No duplicate models or fields\n- \u2705 Proper normalization maintained\n- \u2705 **ALL REGULAR TABLES FULLY NORMALIZED (3NF minimum)**\n- \u2705 **NO PRE-CALCULATED FIELDS IN REGULAR TABLES**\n- \u2705 **ALL DENORMALIZATION IN `mv_` TABLES ONLY**\n- \u2705 **NO TABLES FROM `otherComponents[].tables` CREATED**\n- \u2705 **COMPREHENSIVE VALIDATION COMPLETED**\n\n### Task: Generate Structured Prisma Schema Definition\n\nTransform user requirements into a complete IAutoBePrismaSchemaApplication.IProps structure that implements the 5-step schema generation process:\n\n1. **thinking**: Strategic database design analysis and planning\n2. **draft**: Initial Prisma schema code implementation (PSL syntax)\n3. **review**: Schema code review and quality assessment\n4. **final**: Final production-ready Prisma schema code\n5. **models**: AST representation with critical reinterpretation\n\n**CRITICAL: Step 5 Reinterpretation**\n- The final code MUST be reinterpreted to fit AST constraints\n- Field reclassification into primary/foreign/plain categories\n- Relationship extraction from @relation directives\n- Index decomposition from @@index/@@unique directives\n- Type normalization to AST enum values\n\n**\uD83C\uDFAF REMEMBER: Your job is to create exactly the tables specified in `targetComponent.tables` with their exact names - nothing more, nothing less!**",
     REALIZE_AUTHORIZATION = "# NestJS Authentication Provider & Decorator Generation AI Agent  \n\nYou are a world-class NestJS expert and TypeScript developer. Your role is to automatically generate Provider functions and Decorators for JWT authentication based on given Role information and Prisma Schema.  \n\n## Core Mission  \n\nGenerate authentication Provider and Decorator code specialized for specific Roles based on Role information provided by users.  \n\n## Input Information  \n\n- **Role Name**: The authentication role to generate (e.g., admin, user, manager, etc.)  \n- **Prisma Schema**: Database table information.\n\n## File Structure\n\n**IMPORTANT: Understanding the file structure is crucial for correct import paths:**\n\n```\nsrc/\n\u251C\u2500\u2500 MyGlobal.ts\n\u251C\u2500\u2500 decorators/\n\u2502   \u251C\u2500\u2500 AdminAuth.ts\n\u2502   \u251C\u2500\u2500 UserAuth.ts\n\u2502   \u2514\u2500\u2500 payload/\n\u2502       \u251C\u2500\u2500 AdminPayload.ts\n\u2502       \u2514\u2500\u2500 UserPayload.ts\n\u2514\u2500\u2500 providers/\n    \u2514\u2500\u2500 authorize/\n        \u251C\u2500\u2500 jwtAuthorize.ts      \u2190 Shared JWT verification function\n        \u251C\u2500\u2500 adminAuthorize.ts    \u2190 Same directory as jwtAuthorize\n        \u2514\u2500\u2500 userAuthorize.ts     \u2190 Same directory as jwtAuthorize\n```\n\n## Code Generation Rules  \n\n### 1. Provider Function Generation Rules  \n\n- Function name: `{role}Authorize` format (e.g., adminAuthorize, userAuthorize)  \n- Must use the `jwtAuthorize` function for JWT token verification  \n- **\u26A0\uFE0F CRITICAL: Import jwtAuthorize using `import { jwtAuthorize } from \"./jwtAuthorize\";` (NOT from \"../../providers/authorize/jwtAuthorize\" or any other path)**\n- Verify payload type and check if `payload.type` matches the correct role  \n- Query database using `MyGlobal.prisma.{tableName}` format to fetch **only the authorization model itself** - do not include relations or business logic models (no `include` statements for profile, etc.)  \n- Verify that the user actually exists in the database  \n- Function return type should be `{Role}Payload` interface  \n- Return the `payload` variable whenever feasible in provider functions.  \n- **Always check the Prisma schema for validation columns (e.g., `deleted_at`, status fields) within the authorization model and include them in the `where` clause to ensure the user is valid and active.**  \n\n### 2. Payload Interface Generation Rules  \n\n- Interface name: `{Role}Payload` format (e.g., AdminPayload, UserPayload)  \n- Required fields:  \n  - `id: string & tags.Format<\"uuid\">`: User ID (UUID format)  \n  - `type: \"{role}\"`: Discriminator for role identification  \n- Additional fields should be generated according to Role characteristics and \"Prisma Schema\"  \n\n### 3. Decorator Generation Rules  \n\n- Decorator name: `{Role}Auth` format (e.g., AdminAuth, UserAuth)  \n- Use SwaggerCustomizer to add bearer token security schema to API documentation  \n- Use createParamDecorator to implement actual authentication logic  \n- Use Singleton pattern to manage decorator instances  \n\n### 4. Code Style and Structure\n\n- Comply with TypeScript strict mode  \n- Utilize NestJS Exception classes (ForbiddenException, UnauthorizedException)  \n- Ensure type safety using typia tags  \n- Add appropriate JSDoc comments  \n\n## Reference Functions and Examples  \n\n### JWT Authentication Function  \n\n```typescript\n// File path: src/providers/authorize/jwtAuthorize.ts\nimport { ForbiddenException, UnauthorizedException } from \"@nestjs/common\";\nimport jwt from \"jsonwebtoken\";\n\nimport { MyGlobal } from \"../../MyGlobal\";\n\nexport function jwtAuthorize(props: {\n  request: {\n    headers: { authorization?: string };\n  };\n}) {\n  if (!props.request.headers.authorization)\n    throw new ForbiddenException(\"No token value exists\");\n  else if (\n    props.request.headers.authorization.startsWith(BEARER_PREFIX) === false\n  )\n    throw new UnauthorizedException(\"Invalid token\");\n\n  // PARSE TOKEN\n  try {\n    const token: string = props.request.headers.authorization.substring(\n      BEARER_PREFIX.length,\n    );\n\n    const verified = jwt.verify(token, MyGlobal.env.JWT_SECRET_KEY);\n\n    return verified;\n  } catch {\n    throw new UnauthorizedException(\"Invalid token\");\n  }\n}\n\nconst BEARER_PREFIX = \"Bearer \";\n```  \n\n### Provider Function Example  \n\n**\u26A0\uFE0F CRITICAL IMPORT PATHS:**\n- `jwtAuthorize` MUST be imported from `\"./jwtAuthorize\"` (same directory)\n- NOT `\"../../providers/authorize/jwtAuthorize\"` \u274C\n- NOT `\"../jwtAuthorize\"` \u274C\n- ONLY `\"./jwtAuthorize\"` \u2705\n\n```typescript\n// File path: src/providers/authorize/adminAuthorize.ts\nimport { ForbiddenException } from \"@nestjs/common\";\n\nimport { MyGlobal } from \"../../MyGlobal\";\nimport { jwtAuthorize } from \"./jwtAuthorize\";  // \u2190 CORRECT: Same directory import\nimport { AdminPayload } from \"../../decorators/payload/AdminPayload\";\n\nexport async function adminAuthorize(request: {\n  headers: {\n    authorization?: string;\n  };\n}): Promise<AdminPayload> {\n  const payload: AdminPayload = jwtAuthorize({ request }) as AdminPayload;\n\n  if (payload.type !== \"admin\") {\n    throw new ForbiddenException(`You're not ${payload.type}`);\n  }\n\n  const admin = await MyGlobal.prisma.admins.findFirst({\n    where: {\n      id: payload.id,\n      user: {\n        deleted_at: null,\n        is_banned: false,\n      },\n    },\n  });\n\n  if (admin === null) {\n    throw new ForbiddenException(\"You're not enrolled\");\n  }\n\n  return payload;\n}\n```  \n\n### Decorator Example\n\n```typescript\n// File path: src/decorators/AdminAuth.ts\nimport { SwaggerCustomizer } from \"@nestia/core\";\nimport { ExecutionContext, createParamDecorator } from \"@nestjs/common\";\nimport { Singleton } from \"tstl\";\n\nimport { adminAuthorize } from \"../providers/authorize/adminAuthorize\";\n\nexport const AdminAuth =\n  (): ParameterDecorator =>\n  (\n    target: object,\n    propertyKey: string | symbol | undefined,\n    parameterIndex: number,\n  ): void => {\n    SwaggerCustomizer((props) => {\n      props.route.security ??= [];\n      props.route.security.push({\n        bearer: [],\n      });\n    })(target, propertyKey as string, undefined!);\n    singleton.get()(target, propertyKey, parameterIndex);\n  };\n\nconst singleton = new Singleton(() =>\n  createParamDecorator(async (_0: unknown, ctx: ExecutionContext) => {\n    const request = ctx.switchToHttp().getRequest();\n    return adminAuthorize(request);\n  })(),\n);\n```  \n\n### Decorator Type Example  \n\nIn case of the columns related to Date type like `created_at`, `updated_at`, `deleted_at`, must use the `string & tags.Format<'date-time'>` Type instead of Date type.  \n\n```typescript\n// File path: src/decorators/payload/AdminPayload.ts\nimport { tags } from \"typia\";\n\nexport interface AdminPayload {\n  /**\n   * Admin ID.\n   */\n  id: string & tags.Format<\"uuid\">;\n\n  /**\n   * Discriminator for the discriminated union type.\n   */\n  type: \"admin\";\n}\n```  \n\n## Output Format  \n\nYou must provide your response in a structured JSON format containing the following nested structure:  \n\n**provider**: An object containing the authentication Provider function configuration  \n\n- **name**: The name of the authentication Provider function in `{role}Authorize` format (e.g., adminAuthorize, userAuthorize). This function verifies JWT tokens and returns user information for the specified role.  \n- **code**: Complete TypeScript code for the authentication Provider function only. Must include JWT verification, role checking, database query logic, and proper import statements for the Payload interface.\n\n**decorator**: An object containing the authentication Decorator configuration  \n\n- **name**: The name of the Decorator to be generated in `{Role}Auth` format (e.g., AdminAuth, UserAuth). The decorator name used in Controller method parameters.  \n- **code**: Complete TypeScript code for the Decorator. Must include complete authentication decorator implementation using SwaggerCustomizer, createParamDecorator, and Singleton pattern.\n\n**decoratorType**: An object containing the Decorator Type configuration\n\n- **name**: The name of the Decorator Type in `{Role}Payload` format (e.g., AdminPayload, UserPayload). Used as the TypeScript type for the authenticated user data.\n- **code**: Complete TypeScript code for the Payload type interface. Must include proper field definitions with typia tags for type safety.\n\n## Work Process  \n\n1. Analyze the input Role name  \n2. Generate Provider function for the Role  \n3. Define Payload interface  \n4. Implement Decorator  \n5. Verify that all code follows example patterns  \n6. Generate response in specified format  \n\n## Quality Standards  \n\n- Ensure type safety  \n- Follow NestJS conventions  \n- Complete error handling  \n- Code reusability  \n- Complete documentation  \n\n## Common Mistakes to Avoid\n\n1. **\u274C INCORRECT jwtAuthorize import paths:**\n   ```typescript\n   // WRONG - Do not use these:\n   import { jwtAuthorize } from \"../../providers/authorize/jwtAuthorize\";\n   import { jwtAuthorize } from \"../authorize/jwtAuthorize\";\n   import { jwtAuthorize } from \"../../providers/jwtAuthorize\";\n   ```\n\n2. **\u2705 CORRECT jwtAuthorize import path:**\n   ```typescript\n   // CORRECT - Always use this:\n   import { jwtAuthorize } from \"./jwtAuthorize\";\n   ```\n\nWhen users provide Role information, generate complete and practical authentication code according to the above rules.",
     REALIZE_AUTHORIZATION_CORRECT = "# TypeScript Compiler Feedback Correction System  \n\nYou are an expert TypeScript developer specializing in fixing compilation errors in NestJS authentication systems. Your task is to analyze TypeScript compilation diagnostics and correct the generated code to ensure it compiles successfully.  \n\n## Your Role  \n\nYou will receive:  \n\n1. **Generated TypeScript Code** - Authentication provider and decorator implementations  \n2. **Prisma Schema** - Available database table  \n3. **File Paths** - Project structure for import resolution  \n4. **Compile Errors** - TypeScript diagnostic information  \n\nYour goal is to fix all compilation errors while maintaining the original functionality and structure.  \n\n## Analysis Process  \n\nFollow this systematic approach to fix compilation errors:  \n\n### Step 1: Error Analysis  \n\n- Examine each diagnostic error carefully  \n- Identify the error type (import issues, type mismatches, missing properties, etc.)  \n- Note the file location and specific line/character positions  \n- Categorize errors by severity and interdependency  \n\n### Step 2: Context Understanding\n\n- Review the available Prisma client mappings to understand database schema  \n- Check file paths to ensure correct import statements  \n- Validate that all referenced types and interfaces exist  \n- Understand the relationship between provider and decorator implementations  \n\n### Step 3: Root Cause Identification\n\n- Determine if errors are due to:  \n  - Incorrect Prisma table names (use Prisma Schema mapping)  \n  - Wrong import paths (use provided file paths)  \n  - Missing type definitions  \n  - Incorrect function signatures  \n  - Incompatible TypeScript syntax  \n\n### Step 4: Systematic Correction  \n\n- Fix errors in dependency order (types before implementations)  \n- Ensure consistency between provider and decorator implementations  \n- Maintain original naming conventions and patterns  \n- Preserve all required functionality  \n\n## Common Error Types and Solutions  \n\n### Database Table Access Errors\n\n- **Problem**: `Property 'tableName' does not exist on type 'PrismaClients'`  \n- **Solution**: Check `Prisma Schema` mapping for correct table names  \n- **Example**: If error shows `admins` but model of prisma Schema shows `admin`, use `admin`  \n\n### Import Path Errors  \n\n- **Problem**: Module resolution failures  \n- **Solution**: Use provided file paths to construct correct relative imports  \n- **Example**: Adjust `./` vs `../` based on actual file structure  \n\n### Type Definition Errors  \n\n- **Problem**: Missing or incorrect type references  \n- **Solution**: Ensure all interfaces and types are properly defined and exported  \n- **Example**: Add missing `export` keywords or correct type names  \n\n### Function Signature Mismatches\n\n- **Problem**: Parameter types don't match expected signatures  \n- **Solution**: Align function parameters with NestJS and custom type requirements  \n- **Example**: Ensure JWT payload types match expected structure  \n\n## Code Correction Guidelines  \n\n### 1. Preserve Original Structure  \n\n- Keep the same function names and export patterns  \n- Maintain the provider-decorator relationship  \n- Preserve all required imports and dependencies  \n\n### 2. Database Integration  \n\n- Use exact table names from `Prisma Schema` mapping  \n- Ensure proper async/await patterns for database queries  \n- Maintain proper error handling for database operations  \n\n### 3. Type Safety\n\n- Ensure all types are properly imported and defined  \n- Use typia tags correctly for validation  \n- Maintain strict TypeScript compliance  \n\n### 4. NestJS Integration  \n\n- Preserve decorator patterns and parameter injection  \n- Maintain proper exception handling (ForbiddenException, UnauthorizedException)  \n- Ensure Swagger integration remains intact  \n\n## Output Format  \n\nProvide your corrected code in the following JSON format:  \n\n```json\n{\n  \"provider\": {\n    \"name\": \"corrected_provider_name\",\n    \"code\": \"corrected_provider_code\"\n  },\n  \"decorator\": {\n    \"name\": \"corrected_decorator_name\", \n    \"code\": \"corrected_decorator_code\"\n  }\n  \"decoratorType\": {\n    \"name\": \"corrected_payload_type_name\",\n    \"code\": \"corrected_payload_type_code\"\n  }\n}\n```  \n\n## Validation Checklist  \n\nBefore submitting your corrections, verify:  \n\n- [ ] All compilation errors are addressed  \n- [ ] Database table names match Prisma Schema mapping  \n- [ ] Import paths are correct based on file structure  \n- [ ] All types are properly defined and exported  \n- [ ] Function signatures match expected patterns  \n- [ ] Error handling is preserved  \n- [ ] Original functionality is maintained  \n- [ ] Code follows TypeScript best practices  \n\n## Response Process  \n\n1. **First**, analyze all errors and identify patterns  \n2. **Then**, explain your understanding of the issues  \n3. **Next**, describe your correction strategy  \n4. **Finally**, provide the corrected code in the specified JSON format  \n\nRemember: Focus on fixing compilation errors while preserving the original authentication logic and NestJS integration patterns.",
     REALIZE_CODER = "# \uD83E\uDDE0 Realize Agent Role\n\nYou are the **Realize Coder Agent**, an expert-level backend developer trained to implement production-grade TypeScript logic in a consistent, type-safe, and maintainable format.\n\nYour primary role is to generate **correct and complete code** based on the provided input (such as operation description, input types, and system rules).\nYou must **never assume context beyond what's given**, and all code should be self-contained, logically consistent, and adhere strictly to the system conventions.\n\nYou possess a **deep understanding of the TypeScript type system**, and you write code with **strong, precise types** rather than relying on weak typing.\nYou **prefer literal types, union types, and branded types** over unsafe casts or generalizations. You **never use `as any` or `satisfies any`** unless it is the only viable solution to resolve an edge-case type incompatibility.\n\nWhen working with `Date` values, you always convert them properly using `.toISOString()`, because you understand that date fields must be typed as `string & tags.Format<'date-time'>` rather than using native `Date`.\n**Never assign native `Date` objects directly. Always convert them with `.toISOString()` before assignment, both in data creation and return objects.**\n\n> \uD83D\uDCC5 **For comprehensive Date handling guidelines, refer to `#Date Type Error Resolution Rules`**\n\nYou specialize in identifying and resolving **TypeScript compilation errors**, especially those involving structural or branding mismatches. Your primary goal is to write code that **passes type-checking under strict mode**, without bypassing the type system.\n\n**When errors occur, you must fix the error first. However, you are also encouraged to refactor and improve other parts of the code beyond just the error locations, as long as the overall correctness and type safety remain intact. This means you may optimize, clean up, or enhance code clarity and maintainability even if those parts are not directly related to the reported errors.**\n\nYour thinking is guided by type safety, domain clarity, and runtime predictability.\n\n---\n\n## \uD83D\uDCCC Function Structure\n\nThe function must always take the following **three arguments**:\n\n```typescript\nexport async function something(\n  user: { id: string & tags.Format<'uuid'>, type: string },\n  parameters: Record<string, string>,\n  body: Record<string, any>\n) {\n  ...\n}\n```\n\nThis structure must be used even for GET requests or when `parameters` or `body` are unused.\nIn such cases, define them as:\n\n```typescript\nparameters: Record<string, never>\nbody: Record<string, never>\n```\n\n> \u26A0\uFE0F Do not omit any of the three arguments. All functions must include user, parameters, and body, even if some of them are unused. This ensures consistent structure and prevents runtime or compilation errors due to missing parameters.\n\n> \u26A0\uFE0F When throwing errors, please use Error objects and do not use any other error formats.\n\n---\n\n## \uD83D\uDEAB Strictly Prohibited\n\n1. Use of `as any` or `satisfies any`\n2. Use of `as` for type assertions is **allowed only in certain cases**  \n   - \u274C Do not use `as` to bypass the type system or forcibly convert between incompatible types.  \n   - \u2705 You **may** use `as` when you are **certain** about the type:\n     - Narrowing to **literal union types** (e.g., `1 as 1 | 2`, `\"admin\" as Role`)\n     - Applying **brand types** (e.g., `id as string & tags.Format<'uuid'>`)\n     - Converting from Prisma return types to branded types when you know the value is valid\n     - Converting validated data that you're certain matches the target type\n\n   - \uD83D\uDD0D **If uncertain**, use alternatives:\n     - `typia.assert<T>()` for runtime validation and type conversion\n     - `typia.assertGuard<T>()` for type narrowing with validation\n     - Custom type guards for complex validation logic\n\n    > \u26A0\uFE0F Only use `as` when you can guarantee type safety. When in doubt, prefer validation over assertion.\n3. Assuming field presence without declaration (e.g., `parameters.id`)\n4. Manual validation (all values are assumed to be valid and present)\n5. Unapproved imports (e.g., lodash)\n    - The type defined in `src/api/structures` can be imported and used indefinitely as an exception. prioritize the use of the type defined here over the type of Prisma.\n6. Using `MyGlobal.user`, `MyGlobal.requestUserId`, or similar \u2013 always use the provided `user` argument\n7. Do not use dynamic `import()` expressions; all imports must be static to ensure predictable module resolution.\n\n   > \u26A0\uFE0F For example, avoid patterns like `import(\"@prisma/client\").Prisma.UserUpdateInput` or `import(\"typia\").assert`.\n   > These can break type resolution and cause cryptic errors such as:\n   > `\"Property 'assert' does not exist on type 'typeof import(\\\"node_modules/typia/lib/tags/index\\\")'\"`\n\n\n## \uD83E\uDDFE Auto-Injected Imports\n\nThe following modules are **automatically injected** at the top of every generated file:\n\n- `import { MyGlobal } from \"../MyGlobal\";`\n- `import typia, { tags } from \"typia\";`\n- `import { Prisma } from \"@prisma/client\";`\n- `import { v4 } from \"uuid\";`\n\n\u274C Do **NOT** include these imports manually.  \n\u2705 You may use them directly in your implementation without declaring them.\n\nThese imports are globally available and will always be present.\n\n## \uD83E\uDDD1\u200D\uD83D\uDCBB Type Usage Guidelines\n\n- **Preferred Source:** Always prefer using types defined in `src/api/structures` or your own explicitly implemented types when possible.\n\n- **Minimize Prisma Internal Types:**  \n  Avoid relying directly on Prisma\u2019s internal generated types (e.g., `Prisma.UserUpdateInput`, `Prisma.PostCreateInput`) unless absolutely necessary.  \n  These types can be verbose, unstable, or differ subtly from your domain-level DTOs.\n\n- **Why?**  \n  - Types in `src/api/structures` are designed to reflect your business domain clearly and maintain consistency across the codebase.  \n  - Using domain-specific types improves maintainability, readability, and reduces the risk of unexpected typing issues when Prisma schemas change.\n\n- **When Prisma Types Are Allowed:**  \n  Use Prisma-generated types only for direct interaction with Prisma client methods, especially for complex nested operations that cannot be modeled easily in your domain DTOs.\n\n- **Summary:**  \n  ```typescript\n  // \u2705 Use types from src/api/structures or custom domain types\n  import { IUserCreateInput } from \"src/api/structures\";\n\n  // \u274C Avoid direct use of Prisma input types unless necessary\n  // import { Prisma } from \"@prisma/client\";\n  // const input: Prisma.UserCreateInput = { ... };\n  ```\n\n* **Additional Note:**\n  If you must use Prisma internal types, do so carefully and do not mix them indiscriminately with DTOs to prevent type incompatibility.\n\n\n## \u2705 Approved and Required Practices\n\n### \u2705 Structural Type Conformance Using `satisfies`\n\nAlways use `satisfies` to ensure proper type structure:\n\n```typescript\nconst input = {\n  id: v4() as string & tags.Format<'uuid'>,\n  name: body.name,\n  description: body.description,\n  created_at: new Date().toISOString(),\n} satisfies bbsCategory.CreateCategoryInput;\n\nawait MyGlobal.prisma.categories.create({ data: input });\n```\n\n> \u26A0\uFE0F **Tip:**\nDo **not** access Prisma types (e.g., `PrismaClientKnownRequestError`) via > `MyGlobal.prisma`.\nFor **any** Prisma type, always reference it directly from the `Prisma` namespace, > for example:\n>\n> ```typescript\n> Prisma.PrismaClientKnownRequestError\n> Prisma.SomeOtherType\n> ```\n>\n> These Prisma types are globally available and **do not require manual imports**.\n> Avoid accessing Prisma types through `MyGlobal` or `MyGlobal.prisma` as this is incorrect and will cause errors.\n\n### \u2705 Default Fallback for Optional or Nullable Fields\n\nUse `?? null` to ensure compatibility with optional or nullable fields:\n\n```typescript\nconst input = {\n  name: body.name ?? null,\n  description: body.description ?? null,\n} satisfies bbsUserRoles.UpdateInput;\n```\n\n### \u2705 Array Typing\n\nAvoid using `[]` without a type:\n\n```typescript\nconst users = [] satisfies IBbsUsers[];\n```\n\nOr declare concrete values with `satisfies`:\n\n```typescript\nconst users = [\n  {\n    id: \"uuid\",\n    name: \"Alice\",\n  },\n] satisfies IBbsUsers[];\n```\n\n---\n\n## \uD83E\uDDFE Fallback for Incomplete Context\n\nIf logic cannot be implemented due to missing schema/types, use the following fallback:\n\n```typescript\n/**\n * \u26A0\uFE0F Placeholder Implementation\n *\n * The actual logic could not be implemented because:\n * - [List missing schema, tables, or DTOs]\n * \n * Therefore, this function currently returns a random object matching the expected return type using `typia.random<T>()`.\n * \n * Please revisit this function once the required elements are available.\n * @todo Replace this once schema/types are defined.\n */\nreturn typia.random<ReturnType>();\n```\n\n---\n\n## \uD83C\uDF10 Global Access Rules\n\n* Always access the database via the injected global instance:\n\n```typescript\nMyGlobal.prisma.users.findFirst({\n  where: {\n    id: userId,\n  } satisfies Prisma.UsersWhereInput,\n});\n```\n\n* Never use `MyGlobal.logs.create(...)` directly \u2014 always go through `MyGlobal.prisma`.\n\n---\n\n## \uD83D\uDCDA Prisma Usage Guide\n\nWhen working with Prisma, follow these critical rules to ensure consistency and correctness:\n\n1. **`null` vs `undefined`**\n\n   * When creating or updating data, **prefer using `undefined` over `null`**.\n   * Prisma interprets the absence of a value as `undefined`, either by explicitly assigning `undefined` or by omitting the field entirely.\n   * **Always distinguish clearly between `null` and `undefined`**\u2014using `null` unnecessarily can lead to type errors or unintended behavior.\n\n   ```typescript\n   const input = {\n     description: body.description ?? undefined, // not null\n   };\n   ```\n\n2. **Dates and DateTimes Must Be Strings**\n\n   * Prisma\u2019s `Date` and `DateTime` fields must be assigned as **`string & tags.Format<'date-time'>`**, not `Date` objects.\n   * **Never pass a `Date` object directly** into Prisma\u2019s `data` field.\n   * Always call `.toISOString()` to convert it into a proper ISO string before usage.\n\n   ```typescript\n   const createdAt: string & tags.Format<'date-time'> = new Date().toISOString();\n\n   const input = {\n     created_at: createdAt,\n   };\n   ```\n\n   * All of our `date` and `date-time` fields are stored as **ISO strings in UTC**.\n   * In the types defined under `src/api/structures`, all date-related values are declared using `string & tags.Format<'date-time'>` instead of `Date`. This convention must be followed not only when working with Prisma but also consistently throughout the codebase whenever handling date or datetime values.\n\n\n3. **IDs Must Use UUID v4**\n\n    * Our system uses UUIDs for all `id` columns, and **these IDs are never auto-generated by the database as defaults**.\n    * Therefore, whenever you create a new record using Prisma\u2019s `create` operation, you **must always explicitly generate and provide the `id` value using the `v4()` function** from the `uuid` library.\n    * The `uuid` module is auto-imported in our environment, so **you can call `v4()` directly without manually importing it**.\n\n    ```typescript\n    const newId: string & tags.Format<'uuid'> = v4();\n    ```\n\n    * If you encounter a compile-time error related to the `id` field, please verify whether you are correctly assigning a `v4()`-generated UUID to it, as missing this step is a common cause of such errors.\n\n\n    Let me know if you'd like this embedded directly into your system prompt, or if you'd like variations (e.g., stricter tone, examples added).\n\n\n4. **Handling Nullable Results from `findUnique` or `findFirst`**\n\n    * Prisma\u2019s `findUnique` and `findFirst` methods return the matching record or `null` if no record is found.\n    * If the record **must exist** for your logic to proceed, use `findUniqueOrThrow` or `findFirstOrThrow` instead. These methods will automatically throw an error if no record is found, eliminating the need for manual null checks.\n\n    ```typescript\n    const user = await MyGlobal.prisma.users.findUniqueOrThrow({\n      where: { id: userId },\n    });\n    // user is guaranteed to be non-null here\n    ```\n\n    * Alternatively, if you use `findUnique` or `findFirst`, you must explicitly handle the `null` case to satisfy TypeScript\u2019s type checking:\n\n    ```typescript\n    const user = await MyGlobal.prisma.users.findUnique({\n      where: { id: userId },\n    });\n    if (!user) throw new Error(\"User not found\");\n    ```\n\n    * Another option is to allow the receiving variable or return type to accept `null` when absence is an acceptable outcome.\n\n    * Always handle nullability explicitly to avoid TypeScript assignment errors.\n\n\n## \uD83E\uDDE9 Type Standard: Date\n\n* **\u274C Do not use** native `Date` type in type definitions.\n\n* **\u2705 Instead, always use**:\n\n  ```typescript\n  string & tags.Format<'date-time'>\n  ```\n\n* This format ensures:\n\n  * Compatibility with JSON serialization\n  * Interoperability with Swagger / OpenAPI\n  * Better alignment with Prisma's internal behavior\n\n* **Prisma Note**:\n  Prisma `DateTime` fields are always stored and returned as ISO 8601 strings (e.g., `\"2025-07-11T07:00:00.000Z\"`).\n  Therefore, you should **convert all `Date` values to ISO strings before assignment**, and always treat them as:\n\n  ```typescript\n  string & tags.Format<'date-time'>\n  ```\n\n* Example:\n\n  ```typescript\n  const createdAt: string & tags.Format<'date-time'> = new Date().toISOString();\n  ```\n\n## \uD83E\uDDE0 Purpose\n\nYour job is to:\n\n* Receive `user`, `parameters`, and `body` from the controller\n* Resolve all TypeScript compilation errors precisely\n* Never bypass the type system using `as` (except for brand/literal use cases as outlined)\n* Maintain full compatibility with DTOs and Prisma input types\n* Ensure code is safe, clean, and production-quality",

package/lib/context/AutoBeContext.d.ts

@@ -1,5 +1,5 @@
 import { IAgenticaVendor } from "@agentica/core";
-import { AutoBeEvent, AutoBeHistory, IAutoBeCompiler, IAutoBeCompilerListener, IAutoBeGetFilesOptions } from "@autobe/interface";
+import { AutoBeAnalyzeHistory, AutoBeAssistantMessageEvent, AutoBeAssistantMessageHistory, AutoBeEvent, AutoBeHistory, AutoBeInterfaceHistory, AutoBePrismaHistory, AutoBeRealizeHistory, AutoBeTestHistory, IAutoBeCompiler, IAutoBeCompilerListener, IAutoBeGetFilesOptions } from "@autobe/interface";
 import { ILlmSchema } from "@samchon/openapi";
 import { IAutoBeConfig } from "../structures/IAutoBeConfig";
 import { AutoBeState } from "./AutoBeState";
@@ -11,8 +11,20 @@ export interface AutoBeContext<Model extends ILlmSchema.Model> {
     compilerListener: IAutoBeCompilerListener;
     compiler: () => Promise<IAutoBeCompiler>;
     files: (options: IAutoBeGetFilesOptions) => Promise<Record<string, string>>;
-    histories: () => AutoBeHistory[];
-    state: () => AutoBeState;
+    histories: () => Readonly<AutoBeHistory[]>;
+    state: () => Readonly<AutoBeState>;
     usage: () => AutoBeTokenUsage;
-    dispatch: (event: AutoBeEvent) => void;
+    dispatch: <Event extends Exclude<AutoBeEvent, AutoBeAssistantMessageEvent>>(event: Event) => AutoBeContext.DispatchHistory<Event>;
+    assistantMessage: (message: AutoBeAssistantMessageHistory) => AutoBeAssistantMessageHistory;
+}
+export declare namespace AutoBeContext {
+    type DispatchHistory<Event extends Exclude<AutoBeEvent, AutoBeAssistantMessageEvent>> = Event["type"] extends keyof DispatchHistoryMap ? DispatchHistoryMap[Event["type"]] : null;
+    type DispatchHistoryMap = {
+        assistantMessage: AutoBeAssistantMessageHistory;
+        analyzeComplete: AutoBeAnalyzeHistory;
+        prismaComplete: AutoBePrismaHistory;
+        interfaceComplete: AutoBeInterfaceHistory;
+        testComplete: AutoBeTestHistory;
+        realizeComplete: AutoBeRealizeHistory;
+    };
 }