@autobe/agent 0.20.0 → 0.22.0

package/lib/agent/src/orchestrate/interface/utils/JsonSchemaFactory.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"JsonSchemaFactory.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/utils/JsonSchemaFactory.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AACA,yCAAqE;AACrE,kDAAoC;AAEpC,IAAiB,iBAAiB,CA4FjC;AA5FD,WAAiB,iBAAiB;IACnB,yBAAO,GAAG,CACrB,SAAsB,EACgC,EAAE;QACxD,MAAM,OAAO,GAAyD,EAAE,CAAC;QACzE,KAAK,MAAM,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,eAAe,CAAC,EAAE,CAAC;YAC3D,OAAO,CAAC,GAAG,CAAC,GAAG,KAAK,CAAC;YACrB,SAAS,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC;QACxB,CAAC;QACD,KAAK,MAAM,GAAG,IAAI,SAAS;YACzB,IAAI,kBAAA,MAAM,CAAC,GAAG,CAAC,EAAE,CAAC;gBAChB,MAAM,IAAI,GAAW,kBAAA,WAAW,CAAC,GAAG,CAAC,CAAC;gBACtC,OAAO,CAAC,GAAG,CAAC,GAAG,kBAAA,IAAI,CAAC,IAAI,CAAC,CAAC;gBAC1B,SAAS,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC;gBACtB,SAAS,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC;YACtB,CAAC;QACH,OAAO,OAAO,CAAC;IACjB,CAAC,CAAC;IAEW,2BAAS,GAAG,CACvB,OAA6D,EACvD,EAAE;QACR,KAAK,MAAM,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,OAAO,CAAC,EAAE,CAAC;YACnD,IAAI,GAAG,CAAC,QAAQ,CAAC,cAAc,CAAC,KAAK,KAAK;gBAAE,SAAS;iBAChD,IAAI,gCAAwB,CAAC,QAAQ,CAAC,KAAK,CAAC,KAAK,KAAK;gBAAE,SAAS;YAEtE,MAAM,MAAM,GACV,OAAO,CAAC,GAAG,CAAC,SAAS,CAAC,CAAC,EAAE,GAAG,CAAC,MAAM,GAAG,cAAc,CAAC,MAAM,CAAC,CAAC,CAAC;YAChE,IAAI,MAAM,KAAK,SAAS;gBAAE,SAAS;iBAC9B,IAAI,gCAAwB,CAAC,QAAQ,CAAC,MAAM,CAAC,KAAK,KAAK;gBAAE,SAAS;YAEvE,KAAK,CAAC,UAAU,mCACX,MAAM,CAAC,UAAU,GACjB,KAAK,CAAC,UAAU,CACpB,CAAC;YACF,KAAK,CAAC,QAAQ,GAAG,CAAC,GAAG,MAAM,CAAC,QAAQ,CAAC,CAAC;YACtC,IAAI,KAAK,CAAC,QAAQ,CAAC,QAAQ,CAAC,IAAI,CAAC,KAAK,KAAK;gBAAE,KAAK,CAAC,QAAQ,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;YACvE,IAAI,KAAK,CAAC,QAAQ,CAAC,QAAQ,CAAC,OAAO,CAAC,KAAK,KAAK;gBAC5C,KAAK,CAAC,QAAQ,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;QACjC,CAAC;IACH,CAAC,CAAC;IAEW,sBAAI,GAAG,CAClB,GAAW,EACmC,EAAE,CAAC,CAAC;QAClD,IAAI,EAAE,QAAQ;QACd,UAAU,EAAE;YACV,UAAU,EAAE;gBACV,IAAI,EAAE,wCAAwC;gBAC9C,WAAW,EAAE,mBAAmB;aACjC;YACD,IAAI,EAAE;gBACJ,IAAI,EAAE,OAAO;gBACb,KAAK,EAAE;oBACL,IAAI,EAAE,wBAAwB,GAAG,EAAE;iBACpC;gBACD,WAAW,EAAE,kBAAkB;aAChC;SACF;QACD,QAAQ,EAAE,CAAC,YAAY,EAAE,MAAM,CAAC;QAChC,WAAW,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;KAI3B;KACF,CAAC,CAAC;IAEU,qBAAG,GAAG,CAAC,IAAY,EAAE,KAAc,EAAQ,EAAE;QACxD,IAAI,QAAQ,CAAC,KAAK,CAAC,KAAK,KAAK,IAAI,QAAQ,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,KAAK,KAAK;YAAE,OAAO;QAEzE,IAAI,KAAK,CAAC,IAAI,CAAC,CAAC,WAAW;YAAE,OAAO,KAAK,CAAC,IAAI,CAAC,CAAC,WAAW,CAAC;QAC5D,IAAI,KAAK,CAAC,IAAI,CAAC,CAAC,QAAQ;YAAE,OAAO,KAAK,CAAC,IAAI,CAAC,CAAC,QAAQ,CAAC;QAEtD,KAAK,MAAM,GAAG,IAAI,MAAM,CAAC,IAAI,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACxC,IAAI,eAAe,CAAC,GAAG,CAAC,KAAK,SAAS;gBACpC,KAAK,CAAC,IAAI,CAAC,CAAC,GAAG,CAAC,GAAG,eAAe,CAAC,GAAG,CAAC,CAAC;iBACrC,IAAI,kBAAA,MAAM,CAAC,GAAG,CAAC,KAAK,IAAI,EAAE,CAAC;gBAC9B,MAAM,IAAI,GAAW,GAAG,CAAC,SAAS,CAAC,OAAO,CAAC,MAAM,CAAC,CAAC;gBACnD,KAAK,CAAC,IAAI,CAAC,CAAC,GAAG,CAAC,GAAG,kBAAA,IAAI,CAAC,IAAI,CAAC,CAAC;YAChC,CAAC;IACL,CAAC,CAAC;IAEW,wBAAM,GAAG,CAAC,GAAW,EAAW,EAAE,CAC7C,GAAG,CAAC,UAAU,CAAC,OAAO,CAAC,KAAK,IAAI;QAChC,GAAG,CAAC,UAAU,CAAC,QAAQ,CAAC,KAAK,KAAK;QAClC,GAAG,KAAK,OAAO,CAAC;IAEL,6BAAW,GAAG,CAAC,GAAW,EAAU,EAAE,CACjD,GAAG,CAAC,SAAS,CAAC,OAAO,CAAC,MAAM,CAAC,CAAC;IAEhC,MAAM,QAAQ,GAAG,CAAC,KAAc,EAAoC,EAAE,CACpE,OAAO,KAAK,KAAK,QAAQ,IAAI,KAAK,KAAK,IAAI,CAAC;AAChD,CAAC,EA5FgB,iBAAiB,iCAAjB,iBAAiB,QA4FjC;AAED,MAAM,eAAe;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;QAGnB,MAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAA+D,UAAU,0CACrE,OAAO,CACZ,CAAC"}

package/lib/agent/src/orchestrate/interface/utils/JsonSchemaNamingConvention.d.ts

@@ -0,0 +1,5 @@
+import { AutoBeOpenApi } from "@autobe/interface";
+export declare namespace JsonSchemaNamingConvention {
+    const operations: (operations: AutoBeOpenApi.IOperation[]) => void;
+    const schemas: (operations: AutoBeOpenApi.IOperation[], ...componentSchemas: Record<string, AutoBeOpenApi.IJsonSchemaDescriptive>[]) => void;
+}

package/lib/agent/src/orchestrate/interface/utils/JsonSchemaNamingConvention.js

@@ -0,0 +1,78 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.JsonSchemaNamingConvention = void 0;
+const utils_1 = require("@autobe/utils");
+const openapi_1 = require("@samchon/openapi");
+var JsonSchemaNamingConvention;
+(function (JsonSchemaNamingConvention) {
+    JsonSchemaNamingConvention.operations = (operations) => {
+        const typeNames = new Set();
+        operate(typeNames, operations);
+    };
+    JsonSchemaNamingConvention.schemas = (operations, ...componentSchemas) => {
+        const typeNames = new Set();
+        for (const schemas of componentSchemas)
+            for (const key of Object.keys(schemas))
+                typeNames.add(key);
+        const answer = operate(typeNames, operations);
+        for (const dict of componentSchemas)
+            for (const x of Object.keys(dict)) {
+                const y = answer(x);
+                if (x === y)
+                    continue;
+                dict[y] = dict[x];
+                delete dict[x];
+            }
+        for (const dict of componentSchemas)
+            for (const x of Object.values(dict)) {
+                openapi_1.OpenApiTypeChecker.visit({
+                    components: { schemas: dict },
+                    schema: x,
+                    closure: (s) => {
+                        if (openapi_1.OpenApiTypeChecker.isReference(s) === false)
+                            return;
+                        s.$ref = `#/components/schemas/${answer(s.$ref.split("/").pop())}`;
+                    },
+                });
+            }
+    };
+    const operate = (typeNames, operations) => {
+        for (const op of operations) {
+            if (op.requestBody)
+                typeNames.add(op.requestBody.typeName);
+            if (op.responseBody)
+                typeNames.add(op.responseBody.typeName);
+        }
+        const answer = prepare(typeNames);
+        for (const op of operations) {
+            if (op.requestBody)
+                op.requestBody.typeName = answer(op.requestBody.typeName);
+            if (op.responseBody)
+                op.responseBody.typeName = answer(op.responseBody.typeName);
+        }
+        return answer;
+    };
+    const prepare = (typeNames) => {
+        const similar = new Map();
+        const getKey = (v) => v.split(".")[0].toLowerCase();
+        const getValue = (v) => v.split(".")[0];
+        const emplace = (v) => utils_1.MapUtil.take(similar, getKey(v), () => []).push(getValue(v));
+        for (const v of typeNames)
+            emplace(v);
+        const solution = new Map();
+        for (const [key, values] of similar) {
+            if (values.length === 1)
+                continue;
+            const winner = values.sort((a, b) => countCapitalLetters(b) - countCapitalLetters(a))[0];
+            solution.set(key, winner);
+        }
+        return (v) => {
+            const key = getKey(v);
+            if (solution.has(key) === false)
+                return v;
+            return [solution.get(key), ...v.split(".").slice(1)].join(".");
+        };
+    };
+})(JsonSchemaNamingConvention || (exports.JsonSchemaNamingConvention = JsonSchemaNamingConvention = {}));
+const countCapitalLetters = (str) => (str.match(/[A-Z]/g) || []).length;
+//# sourceMappingURL=JsonSchemaNamingConvention.js.map

package/lib/agent/src/orchestrate/interface/utils/JsonSchemaNamingConvention.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"JsonSchemaNamingConvention.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/utils/JsonSchemaNamingConvention.ts"],"names":[],"mappings":";;;AACA,yCAAwC;AACxC,8CAAsD;AAEtD,IAAiB,0BAA0B,CA4E1C;AA5ED,WAAiB,0BAA0B;IAC5B,qCAAU,GAAG,CAAC,UAAsC,EAAQ,EAAE;QACzE,MAAM,SAAS,GAAgB,IAAI,GAAG,EAAE,CAAC;QACzC,OAAO,CAAC,SAAS,EAAE,UAAU,CAAC,CAAC;IACjC,CAAC,CAAC;IAEW,kCAAO,GAAG,CACrB,UAAsC,EACtC,GAAG,gBAAwE,EACrE,EAAE;QACR,MAAM,SAAS,GAAgB,IAAI,GAAG,EAAE,CAAC;QACzC,KAAK,MAAM,OAAO,IAAI,gBAAgB;YACpC,KAAK,MAAM,GAAG,IAAI,MAAM,CAAC,IAAI,CAAC,OAAO,CAAC;gBAAE,SAAS,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC;QAC7D,MAAM,MAAM,GAAG,OAAO,CAAC,SAAS,EAAE,UAAU,CAAC,CAAC;QAE9C,KAAK,MAAM,IAAI,IAAI,gBAAgB;YACjC,KAAK,MAAM,CAAC,IAAI,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC;gBAClC,MAAM,CAAC,GAAW,MAAM,CAAC,CAAC,CAAC,CAAC;gBAC5B,IAAI,CAAC,KAAK,CAAC;oBAAE,SAAS;gBACtB,IAAI,CAAC,CAAC,CAAC,GAAG,IAAI,CAAC,CAAC,CAAE,CAAC;gBACnB,OAAO,IAAI,CAAC,CAAC,CAAC,CAAC;YACjB,CAAC;QACH,KAAK,MAAM,IAAI,IAAI,gBAAgB;YACjC,KAAK,MAAM,CAAC,IAAI,MAAM,CAAC,MAAM,CAAC,IAAI,CAAC,EAAE,CAAC;gBACpC,4BAAkB,CAAC,KAAK,CAAC;oBACvB,UAAU,EAAE,EAAE,OAAO,EAAE,IAAI,EAAE;oBAC7B,MAAM,EAAE,CAAC;oBACT,OAAO,EAAE,CAAC,CAAC,EAAE,EAAE;wBACb,IAAI,4BAAkB,CAAC,WAAW,CAAC,CAAC,CAAC,KAAK,KAAK;4BAAE,OAAO;wBACxD,CAAC,CAAC,IAAI,GAAG,wBAAwB,MAAM,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,GAAG,EAAG,CAAC,EAAE,CAAC;oBACtE,CAAC;iBACF,CAAC,CAAC;YACL,CAAC;IACL,CAAC,CAAC;IAEF,MAAM,OAAO,GAAG,CACd,SAAsB,EACtB,UAAsC,EACb,EAAE;QAC3B,KAAK,MAAM,EAAE,IAAI,UAAU,EAAE,CAAC;YAC5B,IAAI,EAAE,CAAC,WAAW;gBAAE,SAAS,CAAC,GAAG,CAAC,EAAE,CAAC,WAAW,CAAC,QAAQ,CAAC,CAAC;YAC3D,IAAI,EAAE,CAAC,YAAY;gBAAE,SAAS,CAAC,GAAG,CAAC,EAAE,CAAC,YAAY,CAAC,QAAQ,CAAC,CAAC;QAC/D,CAAC;QACD,MAAM,MAAM,GAAG,OAAO,CAAC,SAAS,CAAC,CAAC;QAClC,KAAK,MAAM,EAAE,IAAI,UAAU,EAAE,CAAC;YAC5B,IAAI,EAAE,CAAC,WAAW;gBAChB,EAAE,CAAC,WAAW,CAAC,QAAQ,GAAG,MAAM,CAAC,EAAE,CAAC,WAAW,CAAC,QAAQ,CAAC,CAAC;YAC5D,IAAI,EAAE,CAAC,YAAY;gBACjB,EAAE,CAAC,YAAY,CAAC,QAAQ,GAAG,MAAM,CAAC,EAAE,CAAC,YAAY,CAAC,QAAQ,CAAC,CAAC;QAChE,CAAC;QACD,OAAO,MAAM,CAAC;IAChB,CAAC,CAAC;IAEF,MAAM,OAAO,GAAG,CAAC,SAAsB,EAA2B,EAAE;QAClE,MAAM,OAAO,GAA0B,IAAI,GAAG,EAAE,CAAC;QACjD,MAAM,MAAM,GAAG,CAAC,CAAS,EAAE,EAAE,CAAC,CAAC,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAE,CAAC,WAAW,EAAE,CAAC;QAC7D,MAAM,QAAQ,GAAG,CAAC,CAAS,EAAE,EAAE,CAAC,CAAC,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAE,CAAC;QACjD,MAAM,OAAO,GAAG,CAAC,CAAS,EAAE,EAAE,CAC5B,eAAO,CAAC,IAAI,CAAC,OAAO,EAAE,MAAM,CAAC,CAAC,CAAC,EAAE,GAAG,EAAE,CAAC,EAAE,CAAC,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAC,CAAC,CAAC,CAAC;QAE/D,KAAK,MAAM,CAAC,IAAI,SAAS;YAAE,OAAO,CAAC,CAAC,CAAC,CAAC;QAEtC,MAAM,QAAQ,GAAwB,IAAI,GAAG,EAAE,CAAC;QAChD,KAAK,MAAM,CAAC,GAAG,EAAE,MAAM,CAAC,IAAI,OAAO,EAAE,CAAC;YACpC,IAAI,MAAM,CAAC,MAAM,KAAK,CAAC;gBAAE,SAAS;YAClC,MAAM,MAAM,GAAW,MAAM,CAAC,IAAI,CAChC,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC,mBAAmB,CAAC,CAAC,CAAC,GAAG,mBAAmB,CAAC,CAAC,CAAC,CAC1D,CAAC,CAAC,CAAE,CAAC;YACN,QAAQ,CAAC,GAAG,CAAC,GAAG,EAAE,MAAM,CAAC,CAAC;QAC5B,CAAC;QACD,OAAO,CAAC,CAAS,EAAE,EAAE;YACnB,MAAM,GAAG,GAAW,MAAM,CAAC,CAAC,CAAC,CAAC;YAC9B,IAAI,QAAQ,CAAC,GAAG,CAAC,GAAG,CAAC,KAAK,KAAK;gBAAE,OAAO,CAAC,CAAC;YAC1C,OAAO,CAAC,QAAQ,CAAC,GAAG,CAAC,GAAG,CAAC,EAAE,GAAG,CAAC,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;QACjE,CAAC,CAAC;IACJ,CAAC,CAAC;AACJ,CAAC,EA5EgB,0BAA0B,0CAA1B,0BAA0B,QA4E1C;AAED,MAAM,mBAAmB,GAAG,CAAC,GAAW,EAAE,EAAE,CAAC,CAAC,GAAG,CAAC,KAAK,CAAC,QAAQ,CAAC,IAAI,EAAE,CAAC,CAAC,MAAM,CAAC"}

package/lib/agent/src/orchestrate/interface/utils/fulfillJsonSchemaErrorMessages.d.ts

@@ -0,0 +1,2 @@
+import { IValidation } from "typia";
+export declare const fulfillJsonSchemaErrorMessages: (errors: IValidation.IError[]) => void;

package/lib/agent/src/orchestrate/interface/utils/fulfillJsonSchemaErrorMessages.js

@@ -0,0 +1,81 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.fulfillJsonSchemaErrorMessages = void 0;
+const utils_1 = require("@autobe/utils");
+const fulfillJsonSchemaErrorMessages = (errors) => {
+    for (const e of errors)
+        if (
+        // type := ["number", "string", ...] case
+        isInvalidJsonSchema(e) &&
+            typeof e.value === "object" &&
+            e.value !== null &&
+            "type" in e.value &&
+            Array.isArray(e.value.type))
+            e.description = utils_1.StringUtil.trim `
+        You have defined the JSON schema's type property value as an 
+        array type listing up the every types what you want, but it is not 
+        allowed in the JSON schema.
+        
+        The JSON schema's type property value must be a single string type.
+        In your case, you have to change it to an "oneOf" type which 
+        represents an union type.
+
+        So, please change the value as below:
+
+        \`\`\`
+        {
+          oneOf: [
+        ${e.value.type.map((t) => `    { "type": ${JSON.stringify(t)}, ... },`).join("\n")}
+          ],${"description" in e.value ? `\n  description: ${JSON.stringify(e.value.description)},` : ""}
+        }
+        \`\`\`
+      `;
+        else if (isInvalidJsonSchema(e) &&
+            typeof e.value === "object" &&
+            e.value !== null &&
+            "enum" in e.value &&
+            Array.isArray(e.value.enum))
+            e.description = utils_1.StringUtil.trim `
+        You have defined only enum property, but it is not allowed in the 
+        JSON schema. You have to define it as oneOf type containing multiple
+        const types like below:
+        
+        \`\`\`
+        {
+          oneOf: [
+        ${e.value.enum.map((t) => `    { "const": ${JSON.stringify(t)} },`).join("\n")}
+          ],${"description" in e.value ? `\n  description: ${JSON.stringify(e.value.description)},` : ""}
+        }
+        \`\`\`
+      `;
+        else if (e.value === undefined && e.path.endsWith(".description"))
+            // no description
+            e.description = utils_1.StringUtil.trim `
+        You have missed the "description" property in the JSON schema. 
+        
+        Please fill it with detailed description about the type.
+      `;
+        else if (e.value === undefined &&
+            e.path.endsWith(".required") &&
+            e.expected === "Array<string>")
+            e.description = utils_1.StringUtil.trim `
+        You have missed the "required" property in the JSON schema of object type.
+
+        When defining the object type, you have to fill the "required" property
+        which lists up the every required property names.
+
+        Please fill it with the required fields. If you think that there is
+        not any required fields at all, you still have to fill the 
+        "required" property even though it becomes an empty array.
+      `;
+};
+exports.fulfillJsonSchemaErrorMessages = fulfillJsonSchemaErrorMessages;
+const isInvalidJsonSchema = (e) => e.expected.startsWith("(") &&
+    e.expected.endsWith(")") &&
+    e.expected.includes("|") &&
+    e.expected
+        .split("|")
+        .map((s) => s.trim())
+        .every((s) => s.startsWith("AutoBeOpenApi.IJsonSchema.") ||
+        s.startsWith("AutoBeOpenApi.IJsonSchemaDescriptive."));
+//# sourceMappingURL=fulfillJsonSchemaErrorMessages.js.map

package/lib/agent/src/orchestrate/interface/utils/fulfillJsonSchemaErrorMessages.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"fulfillJsonSchemaErrorMessages.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/utils/fulfillJsonSchemaErrorMessages.ts"],"names":[],"mappings":";;;AAAA,yCAA2C;AAGpC,MAAM,8BAA8B,GAAG,CAC5C,MAA4B,EACtB,EAAE;IACR,KAAK,MAAM,CAAC,IAAI,MAAM;QACpB;QACE,yCAAyC;QACzC,mBAAmB,CAAC,CAAC,CAAC;YACtB,OAAO,CAAC,CAAC,KAAK,KAAK,QAAQ;YAC3B,CAAC,CAAC,KAAK,KAAK,IAAI;YAChB,MAAM,IAAI,CAAC,CAAC,KAAK;YACjB,KAAK,CAAC,OAAO,CAAC,CAAC,CAAC,KAAK,CAAC,IAAI,CAAC;YAE3B,CAAC,CAAC,WAAW,GAAG,kBAAU,CAAC,IAAI,CAAA;;;;;;;;;;;;;;UAc3B,CAAC,CAAC,KAAK,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,iBAAiB,IAAI,CAAC,SAAS,CAAC,CAAC,CAAC,UAAU,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC;cAC5E,aAAa,IAAI,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,oBAAoB,IAAI,CAAC,SAAS,CAAC,CAAC,CAAC,KAAK,CAAC,WAAW,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE;;;OAGjG,CAAC;aACC,IACH,mBAAmB,CAAC,CAAC,CAAC;YACtB,OAAO,CAAC,CAAC,KAAK,KAAK,QAAQ;YAC3B,CAAC,CAAC,KAAK,KAAK,IAAI;YAChB,MAAM,IAAI,CAAC,CAAC,KAAK;YACjB,KAAK,CAAC,OAAO,CAAC,CAAC,CAAC,KAAK,CAAC,IAAI,CAAC;YAE3B,CAAC,CAAC,WAAW,GAAG,kBAAU,CAAC,IAAI,CAAA;;;;;;;;UAQ3B,CAAC,CAAC,KAAK,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,kBAAkB,IAAI,CAAC,SAAS,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC;cACxE,aAAa,IAAI,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,oBAAoB,IAAI,CAAC,SAAS,CAAC,CAAC,CAAC,KAAK,CAAC,WAAW,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE;;;OAGjG,CAAC;aACC,IAAI,CAAC,CAAC,KAAK,KAAK,SAAS,IAAI,CAAC,CAAC,IAAI,CAAC,QAAQ,CAAC,cAAc,CAAC;YAC/D,iBAAiB;YACjB,CAAC,CAAC,WAAW,GAAG,kBAAU,CAAC,IAAI,CAAA;;;;OAI9B,CAAC;aACC,IACH,CAAC,CAAC,KAAK,KAAK,SAAS;YACrB,CAAC,CAAC,IAAI,CAAC,QAAQ,CAAC,WAAW,CAAC;YAC5B,CAAC,CAAC,QAAQ,KAAK,eAAe;YAE9B,CAAC,CAAC,WAAW,GAAG,kBAAU,CAAC,IAAI,CAAA;;;;;;;;;OAS9B,CAAC;AACR,CAAC,CAAC;AAzEW,QAAA,8BAA8B,kCAyEzC;AAEF,MAAM,mBAAmB,GAAG,CAAC,CAAqB,EAAW,EAAE,CAC7D,CAAC,CAAC,QAAQ,CAAC,UAAU,CAAC,GAAG,CAAC;IAC1B,CAAC,CAAC,QAAQ,CAAC,QAAQ,CAAC,GAAG,CAAC;IACxB,CAAC,CAAC,QAAQ,CAAC,QAAQ,CAAC,GAAG,CAAC;IACxB,CAAC,CAAC,QAAQ;SACP,KAAK,CAAC,GAAG,CAAC;SACV,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC;SACpB,KAAK,CACJ,CAAC,CAAC,EAAE,EAAE,CACJ,CAAC,CAAC,UAAU,CAAC,4BAA4B,CAAC;QAC1C,CAAC,CAAC,UAAU,CAAC,uCAAuC,CAAC,CACxD,CAAC"}

package/lib/agent/src/orchestrate/interface/utils/validateAuthorizationSchema.js.map

@@ -1 +1 @@
-{"version":3,"file":"validateAuthorizationSchema.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/utils/validateAuthorizationSchema.ts"],"names":[],"mappings":";;;AAGO,MAAM,2BAA2B,GAAG,CAAC,KAI3C,EAAQ,EAAE;;IACT,KAAK,MAAM,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,KAAK,CAAC,OAAO,CAAC,EAAE,CAAC;QACzD,IAAI,CAAC,GAAG,CAAC,QAAQ,CAAC,cAAc,CAAC;YAAE,SAAS;QAE5C,+BAA+B;QAC/B,IAAI,CAAC,cAAc,CAAC,KAAK,CAAC,EAAE,CAAC;YAC3B,KAAK,CAAC,MAAM,CAAC,IAAI,CAAC;gBAChB,IAAI,EAAE,GAAG,KAAK,CAAC,IAAI,IAAI,GAAG,EAAE;gBAC5B,QAAQ,EAAE,yEAAyE;gBACnF,KAAK,EAAE,KAAK;gBACZ,WAAW,EAAE,GAAG,GAAG,qDAAqD;aACzE,CAAC,CAAC;YACH,SAAS;QACX,CAAC;QAED,iCAAiC;QACjC,MAAA,KAAK,CAAC,UAAU,oCAAhB,KAAK,CAAC,UAAU,GAAK,EAAE,EAAC;QACxB,KAAK,CAAC,UAAU,CAAC,OAAO,CAAC,GAAG;YAC1B,IAAI,EAAE,0CAA0C;YAChD,WAAW,EAAE,0CAA0C;SACsB,CAAC;QAEhF,MAAA,KAAK,CAAC,QAAQ,oCAAd,KAAK,CAAC,QAAQ,GAAK,EAAE,EAAC;QACtB,IAAI,KAAK,CAAC,QAAQ,CAAC,QAAQ,CAAC,OAAO,CAAC,KAAK,KAAK,EAAE,CAAC;YAC/C,KAAK,CAAC,QAAQ,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;QAC/B,CAAC;IACH,CAAC;AACH,CAAC,CAAC;AA/BW,QAAA,2BAA2B,+BA+BtC;AAEF,MAAM,cAAc,GAAG,CACrB,MAA4C,EACuC,EAAE;IACrF,OAAO,MAAM,IAAI,MAAM,IAAI,MAAM,CAAC,IAAI,KAAK,QAAQ,CAAC;AACtD,CAAC,CAAC"}
+{"version":3,"file":"validateAuthorizationSchema.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/interface/utils/validateAuthorizationSchema.ts"],"names":[],"mappings":";;;AAGO,MAAM,2BAA2B,GAAG,CAAC,KAI3C,EAAQ,EAAE;;IACT,KAAK,MAAM,CAAC,GAAG,EAAE,KAAK,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,KAAK,CAAC,OAAO,CAAC,EAAE,CAAC;QACzD,IAAI,CAAC,GAAG,CAAC,QAAQ,CAAC,cAAc,CAAC;YAAE,SAAS;QAE5C,+BAA+B;QAC/B,IAAI,CAAC,cAAc,CAAC,KAAK,CAAC,EAAE,CAAC;YAC3B,KAAK,CAAC,MAAM,CAAC,IAAI,CAAC;gBAChB,IAAI,EAAE,GAAG,KAAK,CAAC,IAAI,IAAI,GAAG,EAAE;gBAC5B,QAAQ,EAAE,yEAAyE;gBACnF,KAAK,EAAE,KAAK;gBACZ,WAAW,EAAE,GAAG,GAAG,qDAAqD;aACzE,CAAC,CAAC;YACH,SAAS;QACX,CAAC;QAED,iCAAiC;QACjC,MAAA,KAAK,CAAC,UAAU,oCAAhB,KAAK,CAAC,UAAU,GAAK,EAAE,EAAC;QACxB,KAAK,CAAC,UAAU,CAAC,OAAO,CAAC,GAAG;YAC1B,IAAI,EAAE,0CAA0C;YAChD,WAAW,EAAE,0CAA0C;SACL,CAAC;QAErD,MAAA,KAAK,CAAC,QAAQ,oCAAd,KAAK,CAAC,QAAQ,GAAK,EAAE,EAAC;QACtB,IAAI,KAAK,CAAC,QAAQ,CAAC,QAAQ,CAAC,OAAO,CAAC,KAAK,KAAK,EAAE,CAAC;YAC/C,KAAK,CAAC,QAAQ,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;QAC/B,CAAC;IACH,CAAC;AACH,CAAC,CAAC;AA/BW,QAAA,2BAA2B,+BA+BtC;AAEF,MAAM,cAAc,GAAG,CACrB,MAA4C,EACY,EAAE;IAC1D,OAAO,MAAM,IAAI,MAAM,IAAI,MAAM,CAAC,IAAI,KAAK,QAAQ,CAAC;AACtD,CAAC,CAAC"}

package/lib/agent/src/orchestrate/prisma/histories/transformPrismaComponentsHistories.js

@@ -15,7 +15,7 @@ const transformPrismaComponentsHistories = (state, prefix = null) => {
             id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "# 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\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the component analysis directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\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." /* AutoBeSystemPromptConstant.PRISMA_COMPONENT */,
+            text: "<!--\nfilename: PRISMA_COMPONENT.md\n                -->\n# 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\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the component analysis directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\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\nexport namespace IAutoBePrismaComponentApplication {\n   export interface IAutoBePrismaComponentApplication {\n     thinking: string;\n     review: string;\n     decision: string;\n     components: AutoBePrisma.IComponent[];\n   }\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." /* AutoBeSystemPromptConstant.PRISMA_COMPONENT */,
         },
         {
             id: (0, uuid_1.v7)(),

package/lib/agent/src/orchestrate/prisma/histories/transformPrismaComponentsHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformPrismaComponentsHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/prisma/histories/transformPrismaComponentsHistories.ts"],"names":[],"mappings":";;;AACA,yCAA2C;AAC3C,uEAAoE;AACpE,+BAA0B;AAKnB,MAAM,kCAAkC,GAAG,CAChD,KAAkB,EAClB,SAAwB,IAAI,EAG5B,EAAE;IACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,cAAc;QACd,MAAM,IAAI,KAAK,CAAC,2BAA2B,CAAC,CAAC;IAC/C,IAAI,MAAM;QAAE,MAAM,GAAG,mCAAgB,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC;IACpD,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,wkaAA6C;SAClD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;;;UASjB,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC;;;;;yCAKJ,MAAM;;;;;;;;;;;;;;;;;;;;UAqBrC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC,MAAM,GAAG,CAAC;gBAC5B,CAAC,CAAC,kBAAU,CAAC,IAAI,CAAA;;;qFAGwD,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC;;;;;;;kBAOjG,KAAK,CAAC,OAAO,CAAC,KAAK;qBAClB,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,KAAK,MAAM,IAAI,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,EAAE,CAAC;qBACvD,IAAI,CAAC,IAAI,CAAC;eACd;gBACH,CAAC,CAAC,EACN;OACD;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AA5EW,QAAA,kCAAkC,sCA4E7C"}
+{"version":3,"file":"transformPrismaComponentsHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/prisma/histories/transformPrismaComponentsHistories.ts"],"names":[],"mappings":";;;AACA,yCAA2C;AAC3C,uEAAoE;AACpE,+BAA0B;AAKnB,MAAM,kCAAkC,GAAG,CAChD,KAAkB,EAClB,SAAwB,IAAI,EAG5B,EAAE;IACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,cAAc;QACd,MAAM,IAAI,KAAK,CAAC,2BAA2B,CAAC,CAAC;IAC/C,IAAI,MAAM;QAAE,MAAM,GAAG,mCAAgB,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC;IACpD,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,6saAA6C;SAClD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;;;UASjB,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC;;;;;yCAKJ,MAAM;;;;;;;;;;;;;;;;;;;;UAqBrC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC,MAAM,GAAG,CAAC;gBAC5B,CAAC,CAAC,kBAAU,CAAC,IAAI,CAAA;;;qFAGwD,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC;;;;;;;kBAOjG,KAAK,CAAC,OAAO,CAAC,KAAK;qBAClB,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,KAAK,MAAM,IAAI,IAAI,CAAC,IAAI,CAAC,WAAW,EAAE,EAAE,CAAC;qBACvD,IAAI,CAAC,IAAI,CAAC;eACd;gBACH,CAAC,CAAC,EACN;OACD;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AA5EW,QAAA,kCAAkC,sCA4E7C"}

package/lib/agent/src/orchestrate/prisma/histories/transformPrismaCorrectHistories.js

@@ -9,7 +9,7 @@ const transformPrismaCorrectHistories = (result) => {
             id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "# `AutoBePrisma` Targeted Validation Error Fixing Agent\n\nYou are a world-class Prisma schema validation and error resolution specialist working with structured `AutoBePrisma` definitions. Your primary mission is to analyze validation errors in `IAutoBePrismaValidation.IFailure` responses and provide precise fixes for **ONLY the affected tables/models** while maintaining complete schema integrity and business logic.\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the corrections directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\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- **\uD83D\uDFE2 PRIORITY: Ensure ALL descriptions (model and field) are written in English**\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- **Description language verification** (all descriptions in English)\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- [ ] **\uD83D\uDD25 ENGLISH DESCRIPTIONS: All model and field descriptions written in English**\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.**" /* AutoBeSystemPromptConstant.PRISMA_CORRECT */,
+            text: "<!--\nfilename: PRISMA_CORRECT.md\n                -->\n# `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\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the corrections directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\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- **\uD83D\uDFE2 PRIORITY: Ensure ALL descriptions (model and field) are written in English**\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- **Description language verification** (all descriptions in English)\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- [ ] **\uD83D\uDD25 ENGLISH DESCRIPTIONS: All model and field descriptions written in English**\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.**" /* AutoBeSystemPromptConstant.PRISMA_CORRECT */,
         },
         {
             id: (0, uuid_1.v7)(),

package/lib/agent/src/orchestrate/prisma/histories/transformPrismaCorrectHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformPrismaCorrectHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/prisma/histories/transformPrismaCorrectHistories.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAC3C,+BAA0B;AAInB,MAAM,+BAA+B,GAAG,CAC7C,MAAwC,EAGxC,EAAE;IACF,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,kxgBAA2C;SAChD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,IAAI,CAAC;;OAE9B;SACF;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,MAAM,CAAC;;OAEhC;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AArCW,QAAA,+BAA+B,mCAqC1C"}
+{"version":3,"file":"transformPrismaCorrectHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/prisma/histories/transformPrismaCorrectHistories.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAC3C,+BAA0B;AAInB,MAAM,+BAA+B,GAAG,CAC7C,MAAwC,EAGxC,EAAE;IACF,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,00gBAA2C;SAChD;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,IAAI,CAAC;;OAE9B;SACF;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,MAAM,CAAC;;OAEhC;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AArCW,QAAA,+BAA+B,mCAqC1C"}

package/lib/agent/src/orchestrate/prisma/histories/transformPrismaReviewHistories.js

@@ -9,13 +9,13 @@ const transformPrismaReviewHistories = (props) => {
             id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "# Enhanced Prisma Schema Expert System Prompt\n\n## Naming Conventions\n\n### Notation Types\nThe following naming conventions (notations) are used throughout the system:\n- **camelCase**: First word lowercase, subsequent words capitalized (e.g., `userAccount`, `productItem`)\n- **PascalCase**: All words capitalized (e.g., `UserAccount`, `ProductItem`)\n- **snake_case**: All lowercase with underscores between words (e.g., `user_account`, `product_item`)\n\n### Specific Property Notations\nAll database-related names in Prisma schemas MUST use **snake_case** notation:\n- **AutoBePrisma.IComponent.tables**: snake_case (e.g., `shopping_customers`, `bbs_articles`)\n- **AutoBePrisma.IModel.name**: snake_case (e.g., `shopping_sales`, `mv_shopping_sale_last_snapshots`)\n- **AutoBePrisma.IPrimaryField.name**: snake_case (e.g., `id`)\n- **AutoBePrisma.IForeignField.name**: snake_case (e.g., `shopping_customer_id`, `parent_id`)\n- **AutoBePrisma.IPlainField.name**: snake_case (e.g., `created_at`, `updated_at`, `deleted_at`)\n- **AutoBePrisma.IRelation.name**: camelCase (e.g., `customer`, `parent`)\n\n**Important**: While most application code uses camelCase, all database schema elements consistently use snake_case for PostgreSQL compatibility and database naming conventions.\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 2-STEP PROCESS:**\n1. **plan**: Analyze and plan database design for targetComponent.tables\n2. **models**: Generate production-ready AST models based on the strategic plan\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 2 fields (plan, models)\n\u2705 AST models include proper field classification and type normalization\n\u2705 All models have correct `stance` classification\n\n---\n\n## \uD83D\uDEA7 REFERENCE INFORMATION (FOR RELATIONSHIPS ONLY)\n\n### Other Existing Tables (ALREADY CREATED - DO NOT CREATE)\n- `otherTables[]` is an array of table names 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\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the schemas directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\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 2-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 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- **CLASSIFY TABLE STANCE** - Properly determine each table's architectural stance for API generation guidance\n\n## \uD83D\uDCCA TABLE STANCE CLASSIFICATION\n\n### Understanding Table Stance\nEvery model must have a correctly assigned `stance` property that determines its architectural role and API generation strategy:\n\n#### `\"primary\"` - Independent Business Entities\n**Key Question**: \"Do users need to independently create, search, filter, or manage these entities?\"\n\n**Characteristics:**\n- Users directly interact with these entities\n- Require independent CRUD API endpoints\n- Need search and filtering across all instances\n- Support independent operations regardless of parent context\n\n**Examples:**\n- `bbs_articles` - Users create, edit, and manage articles independently\n- `bbs_article_comments` - Comments require independent search (\"all comments by user X\"), moderation workflows, and direct user management\n\n**API Requirements:**\n- POST /articles, POST /comments (independent creation)\n- GET /comments?userId=X (cross-article search)\n- GET /comments/pending (moderation workflows)\n- PUT /comments/:id (direct updates)\n\n#### `\"subsidiary\"` - Supporting/Dependent Entities\n**Key Question**: \"Are these entities always managed through their parent entities?\"\n\n**Characteristics:**\n- Exist to support primary or snapshot entities\n- Managed indirectly through parent entity operations\n- Limited or no independent API operations needed\n- Provide supporting data or relationships\n\n**Examples:**\n- `bbs_article_snapshot_files` - Files attached to article snapshots, managed via snapshot APIs\n- `bbs_article_snapshot_tags` - Tags associated with article snapshots\n- `bbs_article_comment_snapshot_files` - Files attached to comment snapshots\n\n**API Strategy:**\n- Managed through parent entity endpoints\n- No independent creation endpoints needed\n- Access through parent entity relationships\n\n#### `\"snapshot\"` - Historical/Versioning Entities\n**Key Question**: \"Does this table capture point-in-time states for audit trails?\"\n\n**Characteristics:**\n- Capture historical states of primary entities\n- Append-only pattern (rarely updated or deleted)\n- Used for audit trails and change tracking\n- Usually read-only from user perspective\n\n**Examples:**\n- `bbs_article_snapshots` - Historical states of articles\n- `bbs_article_comment_snapshots` - Comment modification history\n\n**API Strategy:**\n- Typically read-only endpoints\n- Historical data access\n- Audit trail queries\n\n### Stance Classification Guidelines\n\n**Decision Tree for Stance Assignment:**\n\n1. **Is it a snapshot table (contains `_snapshots` or historical data)?**\n   \u2192 `stance: \"snapshot\"`\n\n2. **Is it a supporting table (files, tags, junction tables, system-maintained)?**\n   \u2192 `stance: \"subsidiary\"`\n\n3. **Do users need independent operations across parent boundaries?**\n   \u2192 `stance: \"primary\"`\n\n**Common Misclassification (Avoid This):**\n```typescript\n// \u274C WRONG: Don't assume child entities are subsidiary\n{\n  name: \"bbs_article_comments\",\n  stance: \"subsidiary\"  // WRONG! Comments need independent management\n}\n\n// \u2705 CORRECT: Child entities can be primary if independently managed\n{\n  name: \"bbs_article_comments\", \n  stance: \"primary\"  // Comments require cross-article search and direct management\n}\n```\n\n## \uD83D\uDCCB MANDATORY PROCESSING STEPS\n\n### Step 1: Strategic Database Design Analysis (plan)\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 otherTables - these ALREADY EXIST]\n\nSTANCE CLASSIFICATION:\n\u2705 I will classify each table's stance based on business requirements\n\u2705 Primary: Tables requiring independent user management and API operations\n\u2705 Subsidiary: Supporting tables managed through parent entities\n\u2705 Snapshot: Historical/audit tables with append-only patterns\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 otherTables 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\u2705 I will assign correct stance to each model\n```\n\n### Step 2: Model Generation (models)\nGenerate AutoBePrisma.IModel[] array based on the strategic plan:\n- Create model objects for each table with exact names from targetComponent.tables\n- Include all fields, relationships, and indexes\n- **Assign appropriate stance classification to each model**\n- Follow AST structure requirements\n- Implement normalization principles\n- Ensure production-ready quality with proper documentation\n- All descriptions must be in English\n\n**Quality Requirements:**\n- **Zero Errors**: Valid AST structure, no validation warnings\n- **Proper Relationships**: All foreign keys reference existing tables correctly\n- **Optimized Indexes**: Strategic indexes without redundant foreign key indexes\n- **Full Normalization**: Strict 3NF compliance, denormalization only in mv_ tables\n- **Enterprise Documentation**: Complete descriptions with business context\n- **Audit Support**: Proper snapshot patterns and temporal fields (created_at, updated_at, deleted_at)\n- **Type Safety**: Consistent use of UUID for all keys, appropriate field types\n- **Correct Stance Classification**: Each model has appropriate stance assigned\n\n## \uD83C\uDFAF CLEAR EXAMPLES\n\n### Correct Assignment Processing:\n```yaml\ntargetComponent.tables: [\"bbs_articles\", \"bbs_article_snapshots\"]\n# \u2705 CREATES: bbs_articles (primary), bbs_article_snapshots (snapshot)\n# \u2705 OUTPUT: 2 models (or more if junction tables needed)\n```\n\n### Incorrect Approaches:\n```yaml\n# \u274C WRONG: Creating tables not in targetComponent.tables\n# \u274C WRONG: Skipping tables from targetComponent.tables\n# \u274C WRONG: Modifying table names from targetComponent.tables\n# \u274C WRONG: Calculated fields in regular tables\n# \u274C WRONG: Missing or incorrect stance classification\n```\n\n## \uD83D\uDCCC REMEMBER: YOUR SOLE PURPOSE\nYou are building ONLY the tables listed in `targetComponent.tables` for the specific file assigned to you. Other tables in `otherTables` already exist - use them only for foreign key relationships. Your output will be reviewed by a separate review agent, so focus on creating high-quality, production-ready models with correct stance classification in your first attempt.\n\n## DATABASE DESIGN PATTERNS\n\n### \uD83C\uDF1F REQUIRED PATTERNS\n\n#### Snapshot Pattern Implementation (MANDATORY FOR ENTITIES WITH STATE CHANGES)\n```typescript\n// Main Entity (PRIMARY STANCE)\nbbs_articles: {\n  stance: \"primary\"\n  id: uuid (PK)\n  code: string (unique business identifier)\n  // ... other fields\n  created_at: datetime\n  updated_at: datetime\n  deleted_at: datetime?\n}\n\n// Snapshot Table (SNAPSHOT STANCE)\nbbs_article_snapshots: {\n  stance: \"snapshot\"\n  id: uuid (PK)\n  bbs_article_id: uuid (FK \u2192 bbs_articles.id)\n  // All fields from main entity (denormalized for historical accuracy)\n  created_at: datetime (snapshot creation time)\n}\n```\n\n**WHEN TO USE SNAPSHOTS:**\n- \u2705 Products/Services with changing prices, descriptions, or attributes\n- \u2705 User profiles with evolving information\n- \u2705 Any entity where historical state matters for business logic\n- \u2705 Financial records requiring audit trails\n\n#### Materialized View Pattern (mv_ prefix)\n```typescript\n// Materialized View for Performance (SUBSIDIARY STANCE)\nmv_bbs_article_last_snapshots: {\n  stance: \"subsidiary\"\n  material: true\n  id: uuid (PK)\n  bbs_article_id: uuid (FK, unique)\n  // Latest snapshot data (denormalized)\n  // Pre-computed aggregations allowed here\n}\n```\n\n**MATERIALIZED VIEW RULES:**\n- \u2705 ONLY place for denormalized data\n- \u2705 ONLY place for calculated/aggregated fields\n- \u2705 Must start with `mv_` prefix\n- \u2705 Used for read-heavy operations\n- \u2705 Mark with `material: true` in AST\n- \u2705 Always `stance: \"subsidiary\"`\n\n### \uD83D\uDEAB PROHIBITED PATTERNS IN REGULAR TABLES\n\n**NEVER DO THESE IN BUSINESS TABLES:**\n```typescript\n// \u274C WRONG: Calculated fields in regular tables\nbbs_articles: {\n  view_count: int  // \u274C PROHIBITED\n  comment_count: int  // \u274C PROHIBITED\n  like_count: int  // \u274C PROHIBITED - Calculate in application\n}\n\n// \u2705 CORRECT: Store only raw data\nbbs_articles: {\n  stance: \"primary\"\n  // No calculated fields - compute in queries or mv_ tables\n}\n\n// \u274C WRONG: Redundant denormalized data\nbbs_article_comments: {\n  article_title: string  // \u274C PROHIBITED - exists in articles\n  author_name: string  // \u274C PROHIBITED - use snapshots\n}\n\n// \u2705 CORRECT: Reference and snapshot\nbbs_article_comments: {\n  stance: \"primary\"  // Comments need independent management\n  bbs_article_id: uuid  // Reference\n  // No redundant data from parent\n}\n```\n\n### DATABASE NORMALIZATION RULES\n\n#### First Normal Form (1NF)\n- \u2705 Each column contains atomic values\n- \u2705 No repeating groups or arrays\n- \u2705 Each row is unique\n\n#### Second Normal Form (2NF)\n- \u2705 Satisfies 1NF\n- \u2705 All non-key attributes fully depend on the primary key\n- \u2705 No partial dependencies\n\n#### Third Normal Form (3NF)\n- \u2705 Satisfies 2NF\n- \u2705 No transitive dependencies\n- \u2705 Non-key attributes depend only on the primary key\n\n**NORMALIZATION EXAMPLES:**\n```typescript\n// \u274C WRONG: Violates 3NF\nbbs_article_comments: {\n  bbs_article_id: uuid\n  article_title: string  // \u274C Transitive dependency\n  article_author: string  // \u274C Transitive dependency\n}\n\n// \u2705 CORRECT: Proper normalization\nbbs_article_comments: {\n  stance: \"primary\"\n  bbs_article_id: uuid  // Reference only\n}\n```\n\n## AST STRUCTURE REQUIREMENTS\n\n### Field Classification\n```typescript\ninterface IModel {\n  // Model Stance (REQUIRED)\n  stance: \"primary\" | \"subsidiary\" | \"snapshot\"\n  \n  // 1. Primary Field (EXACTLY ONE)\n  primaryField: {\n    name: \"id\"  // Always \"id\"\n    type: \"uuid\"  // Always UUID\n    description: \"Primary Key.\"\n  }\n  \n  // 2. Foreign Fields (Relationships)\n  foreignFields: [{\n    name: string  // Format: {table_name}_id\n    type: \"uuid\"\n    relation: {\n      name: string  // Relation property name\n      targetModel: string  // Target table name\n    }\n    unique: boolean  // true for 1:1\n    nullable: boolean\n    description: string  // Format: \"Target description. {@link target_table.id}.\"\n  }]\n  \n  // 3. Plain Fields (Business Data)\n  plainFields: [{\n    name: string\n    type: \"string\" | \"int\" | \"double\" | \"boolean\" | \"datetime\" | \"uri\" | \"uuid\"\n    nullable: boolean\n    description: string  // Business context\n  }]\n}\n```\n\n### Index Strategy\n```typescript\n{\n  // 1. Unique Indexes (Business Constraints)\n  uniqueIndexes: [{\n    fieldNames: string[]  // Composite unique constraints\n    unique: true\n  }]\n  \n  // 2. Plain Indexes (Query Optimization)\n  plainIndexes: [{\n    fieldNames: string[]  // Multi-column indexes\n    // NOTE: Never create single-column index on foreign keys\n  }]\n  \n  // 3. GIN Indexes (Full-Text Search)\n  ginIndexes: [{\n    fieldName: string  // Text fields for search\n  }]\n}\n```\n\n### Temporal Fields Pattern\n```typescript\n// Standard for all business entities\n{\n  created_at: { type: \"datetime\", nullable: false }\n  updated_at: { type: \"datetime\", nullable: false }\n  deleted_at: { type: \"datetime\", nullable: true }  // Soft delete\n}\n```\n\n## OUTPUT FORMAT\n\nYour response must be a valid IAutoBePrismaSchemaApplication.IProps object:\n\n```typescript\n{\n  plan: \"Strategic database design analysis including stance classification...\",\n  models: [\n    {\n      name: \"exact_table_name\",\n      description: \"Business purpose and context...\",\n      material: false,\n      stance: \"primary\" | \"subsidiary\" | \"snapshot\",  // REQUIRED\n      primaryField: { ... },\n      foreignFields: [ ... ],\n      plainFields: [ ... ],\n      uniqueIndexes: [ ... ],\n      plainIndexes: [ ... ],\n      ginIndexes: [ ... ]\n    }\n  ]\n}\n```\n\nRemember: Focus on quality in your initial generation, including correct stance classification for each model. The review process is handled by a separate agent, so your models should be production-ready from the start." /* AutoBeSystemPromptConstant.PRISMA_SCHEMA */,
+            text: "<!--\nfilename: PRISMA_SCHEMA.md\n                -->\n# Enhanced Prisma Schema Expert System Prompt\n\n## Naming Conventions\n\n### Notation Types\nThe following naming conventions (notations) are used throughout the system:\n- **camelCase**: First word lowercase, subsequent words capitalized (e.g., `userAccount`, `productItem`)\n- **PascalCase**: All words capitalized (e.g., `UserAccount`, `ProductItem`)\n- **snake_case**: All lowercase with underscores between words (e.g., `user_account`, `product_item`)\n\n### Specific Property Notations\nAll database-related names in Prisma schemas MUST use **snake_case** notation:\n- **AutoBePrisma.IComponent.tables**: snake_case (e.g., `shopping_customers`, `bbs_articles`)\n- **AutoBePrisma.IModel.name**: snake_case (e.g., `shopping_sales`, `mv_shopping_sale_last_snapshots`)\n- **AutoBePrisma.IPrimaryField.name**: snake_case (e.g., `id`)\n- **AutoBePrisma.IForeignField.name**: snake_case (e.g., `shopping_customer_id`, `parent_id`)\n- **AutoBePrisma.IPlainField.name**: snake_case (e.g., `created_at`, `updated_at`, `deleted_at`)\n- **AutoBePrisma.IRelation.name**: camelCase (e.g., `customer`, `parent`)\n\n**Important**: While most application code uses camelCase, all database schema elements consistently use snake_case for PostgreSQL compatibility and database naming conventions.\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 2-STEP PROCESS:**\n1. **plan**: Analyze and plan database design for targetComponent.tables\n2. **models**: Generate production-ready AST models based on the strategic plan\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 2 fields (plan, models)\n\u2705 AST models include proper field classification and type normalization\n\u2705 All models have correct `stance` classification\n\n---\n\n## \uD83D\uDEA7 REFERENCE INFORMATION (FOR RELATIONSHIPS ONLY)\n\n### Other Existing Tables (ALREADY CREATED - DO NOT CREATE)\n- `otherTables[]` is an array of table names 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\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the schemas directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\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 2-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 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- **CLASSIFY TABLE STANCE** - Properly determine each table's architectural stance for API generation guidance\n\n## \uD83D\uDCCA TABLE STANCE CLASSIFICATION\n\n### Understanding Table Stance\nEvery model must have a correctly assigned `stance` property that determines its architectural role and API generation strategy:\n\n#### `\"primary\"` - Independent Business Entities\n**Key Question**: \"Do users need to independently create, search, filter, or manage these entities?\"\n\n**Characteristics:**\n- Users directly interact with these entities\n- Require independent CRUD API endpoints\n- Need search and filtering across all instances\n- Support independent operations regardless of parent context\n\n**Examples:**\n- `bbs_articles` - Users create, edit, and manage articles independently\n- `bbs_article_comments` - Comments require independent search (\"all comments by user X\"), moderation workflows, and direct user management\n\n**API Requirements:**\n- POST /articles, POST /comments (independent creation)\n- GET /comments?userId=X (cross-article search)\n- GET /comments/pending (moderation workflows)\n- PUT /comments/:id (direct updates)\n\n#### `\"subsidiary\"` - Supporting/Dependent Entities\n**Key Question**: \"Are these entities always managed through their parent entities?\"\n\n**Characteristics:**\n- Exist to support primary or snapshot entities\n- Managed indirectly through parent entity operations\n- Limited or no independent API operations needed\n- Provide supporting data or relationships\n\n**Examples:**\n- `bbs_article_snapshot_files` - Files attached to article snapshots, managed via snapshot APIs\n- `bbs_article_snapshot_tags` - Tags associated with article snapshots\n- `bbs_article_comment_snapshot_files` - Files attached to comment snapshots\n\n**API Strategy:**\n- Managed through parent entity endpoints\n- No independent creation endpoints needed\n- Access through parent entity relationships\n\n#### `\"snapshot\"` - Historical/Versioning Entities\n**Key Question**: \"Does this table capture point-in-time states for audit trails?\"\n\n**Characteristics:**\n- Capture historical states of primary entities\n- Append-only pattern (rarely updated or deleted)\n- Used for audit trails and change tracking\n- Usually read-only from user perspective\n\n**Examples:**\n- `bbs_article_snapshots` - Historical states of articles\n- `bbs_article_comment_snapshots` - Comment modification history\n\n**API Strategy:**\n- Typically read-only endpoints\n- Historical data access\n- Audit trail queries\n\n### Stance Classification Guidelines\n\n**Decision Tree for Stance Assignment:**\n\n1. **Is it a snapshot table (contains `_snapshots` or historical data)?**\n   \u2192 `stance: \"snapshot\"`\n\n2. **Is it a supporting table (files, tags, junction tables, system-maintained)?**\n   \u2192 `stance: \"subsidiary\"`\n\n3. **Do users need independent operations across parent boundaries?**\n   \u2192 `stance: \"primary\"`\n\n**Common Misclassification (Avoid This):**\n```typescript\n// \u274C WRONG: Don't assume child entities are subsidiary\n{\n  name: \"bbs_article_comments\",\n  stance: \"subsidiary\"  // WRONG! Comments need independent management\n}\n\n// \u2705 CORRECT: Child entities can be primary if independently managed\n{\n  name: \"bbs_article_comments\", \n  stance: \"primary\"  // Comments require cross-article search and direct management\n}\n```\n\n## \uD83D\uDCCB MANDATORY PROCESSING STEPS\n\n### Step 1: Strategic Database Design Analysis (plan)\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 otherTables - these ALREADY EXIST]\n\nREQUIREMENT ANALYSIS FOR COMMON PATTERNS:\n\u2705 Authentication Check: Does any entity need login? \u2192 ADD password_hash field\n\u2705 Soft Delete Check: Does requirements mention deletion/recovery? \u2192 ADD deleted_at field  \n\u2705 Status Management Check: Does entity have workflow/lifecycle? \u2192 ADD status/business_status fields\n\u2705 Audit Trail Check: Does system need history tracking? \u2192 ADD created_at, updated_at\n\nSTANCE CLASSIFICATION:\n\u2705 I will classify each table's stance based on business requirements\n\u2705 Primary: Tables requiring independent user management and API operations\n\u2705 Subsidiary: Supporting tables managed through parent entities\n\u2705 Snapshot: Historical/audit tables with append-only patterns\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 otherTables 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\u2705 I will assign correct stance to each model\n\u2705 I will add REQUIRED fields based on requirement patterns (auth, soft delete, status)\n```\n\n### Step 2: Model Generation (models)\nGenerate AutoBePrisma.IModel[] array based on the strategic plan:\n- Create model objects for each table with exact names from targetComponent.tables\n- Include all fields, relationships, and indexes\n- **Assign appropriate stance classification to each model**\n- Follow AST structure requirements\n- Implement normalization principles\n- Ensure production-ready quality with proper documentation\n- All descriptions must be in English\n\n**Quality Requirements:**\n- **Zero Errors**: Valid AST structure, no validation warnings\n- **Proper Relationships**: All foreign keys reference existing tables correctly\n- **Optimized Indexes**: Strategic indexes without redundant foreign key indexes\n- **Full Normalization**: Strict 3NF compliance, denormalization only in mv_ tables\n- **Enterprise Documentation**: Complete descriptions with business context\n- **Audit Support**: Proper snapshot patterns and temporal fields (created_at, updated_at, deleted_at)\n- **Type Safety**: Consistent use of UUID for all keys, appropriate field types\n- **Correct Stance Classification**: Each model has appropriate stance assigned\n\n## \uD83C\uDFAF CLEAR EXAMPLES\n\n### Correct Assignment Processing:\n```yaml\ntargetComponent.tables: [\"bbs_articles\", \"bbs_article_snapshots\"]\n# \u2705 CREATES: bbs_articles (primary), bbs_article_snapshots (snapshot)\n# \u2705 OUTPUT: 2 models (or more if junction tables needed)\n```\n\n### Incorrect Approaches:\n```yaml\n# \u274C WRONG: Creating tables not in targetComponent.tables\n# \u274C WRONG: Skipping tables from targetComponent.tables\n# \u274C WRONG: Modifying table names from targetComponent.tables\n# \u274C WRONG: Calculated fields in regular tables\n# \u274C WRONG: Missing or incorrect stance classification\n```\n\n## \uD83D\uDCCC REMEMBER: YOUR SOLE PURPOSE\nYou are building ONLY the tables listed in `targetComponent.tables` for the specific file assigned to you. Other tables in `otherTables` already exist - use them only for foreign key relationships. Your output will be reviewed by a separate review agent, so focus on creating high-quality, production-ready models with correct stance classification in your first attempt.\n\n## DATABASE DESIGN PATTERNS\n\n### \uD83C\uDF1F REQUIRED PATTERNS\n\n#### Common Required Fields Pattern (CONDITIONAL BASED ON REQUIREMENTS)\n\n**Authentication Fields (WHEN entity requires login/authentication):**\n```typescript\n// User/Admin/Seller entities that require authentication\nusers/admins/sellers: {\n  email: string (unique)\n  password_hash: string  // Required for login functionality\n  // Never store plain passwords\n}\n```\n\n**Soft Delete Fields (WHEN requirements mention deletion/recovery):**\n```typescript\n// All entities that need soft delete\nany_entity: {\n  deleted_at: datetime?  // Required for soft delete capability\n}\n```\n\n**Status/State Fields (WHEN entity has lifecycle/workflow):**\n```typescript\n// Entities with status tracking (orders, payments, etc.)\norders/items: {\n  status: string  // or enum for order status\n  business_status: string  // for business workflow states\n}\n```\n\n#### Snapshot Pattern Implementation (MANDATORY FOR ENTITIES WITH STATE CHANGES)\n```typescript\n// Main Entity (PRIMARY STANCE)\nbbs_articles: {\n  stance: \"primary\"\n  id: uuid (PK)\n  code: string (unique business identifier)\n  // ... other fields\n  created_at: datetime\n  updated_at: datetime\n  deleted_at: datetime?  // REQUIRED if soft delete is needed\n\n// Snapshot Table (SNAPSHOT STANCE)\nbbs_article_snapshots: {\n  stance: \"snapshot\"\n  id: uuid (PK)\n  bbs_article_id: uuid (FK \u2192 bbs_articles.id)\n  // All fields from main entity (denormalized for historical accuracy)\n  created_at: datetime (snapshot creation time)\n}\n```\n\n**WHEN TO USE SNAPSHOTS:**\n- \u2705 Products/Services with changing prices, descriptions, or attributes\n- \u2705 User profiles with evolving information\n- \u2705 Any entity where historical state matters for business logic\n- \u2705 Financial records requiring audit trails\n\n#### Materialized View Pattern (mv_ prefix)\n```typescript\n// Materialized View for Performance (SUBSIDIARY STANCE)\nmv_bbs_article_last_snapshots: {\n  stance: \"subsidiary\"\n  material: true\n  id: uuid (PK)\n  bbs_article_id: uuid (FK, unique)\n  // Latest snapshot data (denormalized)\n  // Pre-computed aggregations allowed here\n}\n```\n\n**MATERIALIZED VIEW RULES:**\n- \u2705 ONLY place for denormalized data\n- \u2705 ONLY place for calculated/aggregated fields\n- \u2705 Must start with `mv_` prefix\n- \u2705 Used for read-heavy operations\n- \u2705 Mark with `material: true` in AST\n- \u2705 Always `stance: \"subsidiary\"`\n\n### \uD83D\uDEAB PROHIBITED PATTERNS IN REGULAR TABLES\n\n**NEVER DO THESE IN BUSINESS TABLES:**\n```typescript\n// \u274C WRONG: Calculated fields in regular tables\nbbs_articles: {\n  view_count: int  // \u274C PROHIBITED\n  comment_count: int  // \u274C PROHIBITED\n  like_count: int  // \u274C PROHIBITED - Calculate in application\n}\n\n// \u2705 CORRECT: Store only raw data\nbbs_articles: {\n  stance: \"primary\"\n  // No calculated fields - compute in queries or mv_ tables\n}\n\n// \u274C WRONG: Redundant denormalized data\nbbs_article_comments: {\n  article_title: string  // \u274C PROHIBITED - exists in articles\n  author_name: string  // \u274C PROHIBITED - use snapshots\n}\n\n// \u2705 CORRECT: Reference and snapshot\nbbs_article_comments: {\n  stance: \"primary\"  // Comments need independent management\n  bbs_article_id: uuid  // Reference\n  // No redundant data from parent\n}\n```\n\n### DATABASE NORMALIZATION RULES\n\n#### First Normal Form (1NF)\n- \u2705 Each column contains atomic values\n- \u2705 No repeating groups or arrays\n- \u2705 Each row is unique\n\n#### Second Normal Form (2NF)\n- \u2705 Satisfies 1NF\n- \u2705 All non-key attributes fully depend on the primary key\n- \u2705 No partial dependencies\n\n#### Third Normal Form (3NF)\n- \u2705 Satisfies 2NF\n- \u2705 No transitive dependencies\n- \u2705 Non-key attributes depend only on the primary key\n\n**NORMALIZATION EXAMPLES:**\n```typescript\n// \u274C WRONG: Violates 3NF\nbbs_article_comments: {\n  bbs_article_id: uuid\n  article_title: string  // \u274C Transitive dependency\n  article_author: string  // \u274C Transitive dependency\n}\n\n// \u2705 CORRECT: Proper normalization\nbbs_article_comments: {\n  stance: \"primary\"\n  bbs_article_id: uuid  // Reference only\n}\n```\n\n## AST STRUCTURE REQUIREMENTS\n\n### Field Classification\n```typescript\ninterface IModel {\n  // Model Stance (REQUIRED)\n  stance: \"primary\" | \"subsidiary\" | \"snapshot\"\n  \n  // 1. Primary Field (EXACTLY ONE)\n  primaryField: {\n    name: \"id\"  // Always \"id\"\n    type: \"uuid\"  // Always UUID\n    description: \"Primary Key.\"\n  }\n  \n  // 2. Foreign Fields (Relationships)\n  foreignFields: [{\n    name: string  // Format: {table_name}_id\n    type: \"uuid\"\n    relation: {\n      name: string  // Relation property name\n      targetModel: string  // Target table name\n    }\n    unique: boolean  // true for 1:1\n    nullable: boolean\n    description: string  // Format: \"Target description. {@link target_table.id}.\"\n  }]\n  \n  // 3. Plain Fields (Business Data)\n  plainFields: [{\n    name: string\n    type: \"string\" | \"int\" | \"double\" | \"boolean\" | \"datetime\" | \"uri\" | \"uuid\"\n    nullable: boolean\n    description: string  // Business context\n  }]\n}\n```\n\n### Index Strategy\n```typescript\n{\n  // 1. Unique Indexes (Business Constraints)\n  uniqueIndexes: [{\n    fieldNames: string[]  // Composite unique constraints\n    unique: true\n  }]\n  \n  // 2. Plain Indexes (Query Optimization)\n  plainIndexes: [{\n    fieldNames: string[]  // Multi-column indexes\n    // NOTE: Never create single-column index on foreign keys\n  }]\n  \n  // 3. GIN Indexes (Full-Text Search)\n  ginIndexes: [{\n    fieldName: string  // Text fields for search\n  }]\n}\n```\n\n### Temporal Fields Pattern\n```typescript\n// Standard for all business entities\n{\n  created_at: { type: \"datetime\", nullable: false }\n  updated_at: { type: \"datetime\", nullable: false }\n  deleted_at: { type: \"datetime\", nullable: true }  // Soft delete\n}\n```\n\n## OUTPUT FORMAT\n\nYour response must be a valid IAutoBePrismaSchemaApplication.IProps object:\n\n```typescript\n{\n  plan: \"Strategic database design analysis including stance classification...\",\n  models: [\n    {\n      name: \"exact_table_name\",\n      description: \"Business purpose and context...\",\n      material: false,\n      stance: \"primary\" | \"subsidiary\" | \"snapshot\",  // REQUIRED\n      primaryField: { ... },\n      foreignFields: [ ... ],\n      plainFields: [ ... ],\n      uniqueIndexes: [ ... ],\n      plainIndexes: [ ... ],\n      ginIndexes: [ ... ]\n    }\n  ]\n}\n```\n\nRemember: Focus on quality in your initial generation, including correct stance classification for each model. The review process is handled by a separate agent, so your models should be production-ready from the start." /* AutoBeSystemPromptConstant.PRISMA_SCHEMA */,
         },
         {
             id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "# AutoBE - Prisma Schema Review\n\n## Your Mission\n\nYou are the Prisma Schema Review Expert of the AutoBE system. Your core responsibility is to meticulously review the Prisma schema models against the original design plan, ensuring compliance with database normalization principles, best practices, and business requirements. Your review process must be thorough, systematic, and constructive.\n\nYour three-phase review process:\n1. **Analyze the Plan**: Understand the intended database architecture and business requirements\n2. **Review Models**: Validate the implementation against the plan and best practices\n3. **Provide Modifications**: Suggest necessary corrections to resolve identified issues\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the review directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## Input Information\n\nYou will receive the following inputs for your review:\n\n### 1. Requirement Analysis Reports (`Record<string, string>`)\nA collection of requirement analysis documents that define the business requirements and specifications for the application. This is provided as a Record where:\n- **Key**: The filename of the analysis document (e.g., \"01_shopping-mall-ai_overview.md\")\n- **Value**: The complete markdown content of the analysis document\n\nThese documents typically include:\n- Project overview and strategic objectives\n- User roles and permissions specifications\n- Feature and workflow requirements using EARS format\n- API authentication and access control requirements\n- Business rules and compliance specifications\n- System architecture and scalability considerations\n\nThe analysis reports follow a structured format with:\n- Clear business requirements using \"THE system SHALL\" statements\n- Use case scenarios and user stories\n- Technical constraints and non-functional requirements\n- Mermaid diagrams for process flows and relationships\n\n### 2. Complete AST Definition (`AutoBePrisma.IApplication`)\nThe complete Abstract Syntax Tree representation of all database tables in the application, structured as:\n- **IApplication**: Root container with multiple schema files\n- **IFile**: Domain-specific schema files (e.g., systematic, actors, sales)\n- **IModel**: Individual database tables with:\n  - Primary key field (always UUID)\n  - Foreign key fields with relation configurations\n  - Plain data fields (business data)\n  - Indexes (unique, regular, GIN for full-text search)\n\nThis AST follows the structure defined in `AutoBePrisma` namespace, providing programmatic representation of the entire database schema.\n\n### 3. Generated Prisma Schema Code\nThe AST definition converted to actual Prisma Schema Language (PSL) code, showing:\n- Model definitions with `model` keyword\n- Field declarations with types and attributes\n- Relation directives (`@relation`)\n- Index definitions (`@@index`, `@@unique`)\n- Database-specific mappings (`@db.Uuid`, etc.)\n\nThis is the compiled output that will be used by Prisma ORM to generate the actual database schema.\n\n### 4. Target Tables for Review (by namespace)\nA specific namespace and its table list indicating which tables to review. You will NOT review all tables, only those belonging to the specified namespace. The input will include:\n- **Namespace name**: The business domain being reviewed (e.g., \"Sales\", \"Actors\", \"Orders\")\n- **Table list**: Explicit list of tables in this namespace that require review\n\nFor example:\n- If namespace is \"Sales\" with tables: [`shopping_sales`, `shopping_sale_snapshots`, `shopping_sale_units`]\n- If namespace is \"Actors\" with tables: [`shopping_customers`, `shopping_citizens`, `shopping_administrators`]\n\n**IMPORTANT**: \n- Focus your review ONLY on the tables explicitly listed for the specified namespace\n- Consider their relationships with tables in other namespaces for referential integrity validation\n- Do NOT review tables from other namespaces, even if they appear in the schema\n- Cross-reference the requirement analysis reports to ensure the schema accurately implements business requirements\n\n## Review Dimensions\n\nYour review must comprehensively evaluate the following aspects:\n\n### 1. Normalization Compliance (1NF, 2NF, 3NF)\n- **1NF Validation**: Ensure atomic values, no repeating groups, unique rows\n- **2NF Validation**: Verify full functional dependency on primary key\n- **3NF Validation**: Confirm no transitive dependencies exist\n- **Denormalization Justification**: Accept intentional denormalization only with clear performance benefits\n\n### 2. Relationship Integrity\n- **Foreign Key Validation**: Verify all references point to existing tables\n- **Cardinality Accuracy**: Confirm one-to-one, one-to-many, many-to-many relationships are correctly implemented\n- **Cascade Rules**: Validate ON DELETE and ON UPDATE behaviors align with business logic\n- **Junction Tables**: Ensure proper implementation for many-to-many relationships\n\n### 3. Data Type Consistency\n- **Type Appropriateness**: Verify each field uses the optimal data type\n- **Precision Requirements**: Confirm numeric types have appropriate precision\n- **String Length**: Validate VARCHAR lengths match business constraints\n- **Temporal Fields**: Ensure proper use of DateTime vs Date types\n\n### 4. Index Strategy\n- **Primary Keys**: Verify appropriate primary key selection\n- **Foreign Key Indexes**: Confirm indexes on all foreign key fields\n- **Query Optimization**: Identify fields requiring indexes based on access patterns\n- **Composite Indexes**: Validate multi-column index order and necessity\n- **Full-Text Search**: Verify GIN indexes for text search requirements\n\n### 5. Naming Conventions\n- **Table Names**: Plural, snake_case (e.g., shopping_customers)\n- **Field Names**: Singular, snake_case (e.g., created_at)\n- **Consistency**: Ensure naming patterns are uniform across all models\n- **Clarity**: Names must clearly convey purpose without ambiguity\n\n### 6. Business Logic Alignment\n- **Requirement Coverage**: Verify all business entities are represented\n- **Constraint Implementation**: Confirm business rules are enforced at database level\n- **Audit Trail**: Validate temporal fields (created_at, updated_at) presence\n- **Soft Delete**: Check deleted_at implementation where required\n\n### 7. Documentation Quality\n- **Model Descriptions**: Each table must have a clear purpose description\n- **Field Documentation**: Complex fields require explanatory comments\n- **Relationship Clarification**: Document non-obvious relationships\n\n### 8. Requirement Coverage & Traceability\n- **Complete Coverage**: Verify every EARS requirement has corresponding schema implementation\n- **Entity Mapping**: Ensure all business entities from requirements are represented\n- **Feature Support**: Validate schema supports all specified features and workflows\n- **Missing Elements**: Identify any requirements not reflected in the schema\n\n### 9. Cross-Domain Consistency\n- **Shared Concepts**: Verify consistent implementation of common entities across namespaces\n- **Integration Points**: Validate proper relationships between different business domains\n- **Data Standards**: Ensure uniform data representation across the entire schema\n- **Domain Boundaries**: Confirm appropriate separation of concerns between namespaces\n\n### 10. Security & Access Control Implementation\n- **Permission Model**: Verify schema supports the required role-based access control\n- **Data Sensitivity**: Ensure appropriate handling of PII and sensitive data\n- **Row-Level Security**: Validate support for multi-tenant or user-specific data isolation\n- **Audit Requirements**: Confirm security-related events can be tracked\n\n### 11. Scalability & Future-Proofing\n- **Growth Patterns**: Assess schema's ability to handle anticipated data growth\n- **Extensibility**: Evaluate ease of adding new features without major restructuring\n- **Partitioning Strategy**: Consider future data partitioning or sharding needs\n- **Version Management**: Ensure schema can evolve without breaking changes\n\n### 12. Holistic Performance Strategy\n- **Query Complexity**: Analyze potential join patterns across the entire schema\n- **Hot Paths**: Identify and optimize frequently accessed data paths\n- **Denormalization Balance**: Justify any denormalization for performance gains\n- **Cache Strategy**: Consider what data might benefit from caching layers\n\n### 13. Data Governance & Lifecycle\n- **Retention Policies**: Verify support for data retention requirements\n- **Archival Strategy**: Ensure old data can be archived without losing referential integrity\n- **Data Quality**: Validate constraints ensure data quality at insertion\n- **Temporal Data**: Proper handling of historical and time-series data\n\n### 14. Compliance & Regulatory Alignment\n- **Regulatory Requirements**: Ensure schema supports compliance needs (GDPR, etc.)\n- **Audit Trail Completeness**: Verify all regulatory audit requirements are met\n- **Data Residency**: Consider geographic data storage requirements\n- **Right to Erasure**: Validate support for data deletion requirements\n\n## Review Process\n\n### Step 1: Plan Analysis\n1. Review the requirement analysis reports to understand:\n   - Business domain and strategic objectives\n   - User roles and their permissions requirements\n   - Feature specifications using EARS format\n   - API authentication and access control needs\n   - Business rules that must be enforced at database level\n2. Extract key business requirements from the plan\n3. Identify planned table structures and relationships\n4. Note performance optimization strategies\n5. Understand snapshot/temporal data requirements\n6. Cross-reference requirements with the AST definition to ensure alignment\n\n### Step 2: Draft Model Validation\nFor each model:\n1. Compare against planned structure and requirement specifications\n2. Validate against all fourteen review dimensions:\n   - Technical dimensions (1-7): Structure, relationships, types, indexes, naming, business logic, documentation\n   - Holistic dimensions (8-14): Requirements coverage, cross-domain consistency, security, scalability, performance, governance, compliance\n3. Classify issues by severity:\n   - **Critical**: Data loss risk, integrity violations, missing requirements, security vulnerabilities\n   - **Major**: Performance degradation, maintainability concerns, scalability limitations, inconsistencies\n   - **Minor**: Convention violations, documentation gaps, optimization opportunities\n\n### Step 3: Issue Documentation\nStructure your review findings:\n```\nModel: [table_name]\nIssue Type: [Critical/Major/Minor]\nDimension: [Which review dimension]\nDescription: [Clear explanation of the issue]\nImpact: [Consequences if not addressed]\n```\n\n## Modification Guidelines\n\n### When to Provide Modifications\nProvide the `modifications` array when:\n- Critical issues require structural changes\n- Major issues need field additions/removals\n- Index strategy requires optimization\n- Naming conventions need correction\n\n### Modification Principles\n1. **Minimal Changes**: Only modify what's necessary to resolve issues\n2. **Backward Compatibility**: Consider migration impact\n3. **Performance First**: Prioritize query efficiency\n4. **Consistency**: Maintain uniform patterns across all models\n\n### Modification Format\nEach modification must include:\n- Complete model definition (not just changes)\n- All fields with proper types and constraints\n- Comprehensive index specifications\n- Clear descriptions for documentation\n\n## Example Review Scenarios\n\n### Scenario 1: Normalization Violation\n```\nDraft Model: shopping_orders\nIssue: Product price stored in order_items violates 3NF\nReview: \"The order_items table contains product_price which creates a transitive dependency on products table. This violates 3NF as price changes would require updates to historical orders.\"\nModification: Add order_item_snapshots table to properly capture point-in-time pricing\n```\n\n### Scenario 2: Missing Relationship\n```\nDraft Model: shopping_reviews\nIssue: No foreign key to shopping_customers\nReview: \"Reviews table lacks customer association, making it impossible to track review authors. This breaks referential integrity.\"\nModification: Add customer_id field with proper foreign key constraint\n```\n\n### Scenario 3: Index Optimization\n```\nDraft Model: shopping_products\nIssue: Missing composite index for category-based queries\nReview: \"Product searches by category_id and status will perform full table scans. High-frequency query pattern requires optimization.\"\nModification: Add composite index on [category_id, status, created_at DESC]\n```\n\n### Scenario 4: Requirement Coverage Gap\n```\nDraft Model: shopping_customers\nIssue: Missing fields for multi-factor authentication requirement\nReview: \"The requirement analysis specifies 'THE system SHALL support multi-factor authentication for customer accounts', but the schema lacks fields for storing MFA secrets, backup codes, and authentication method preferences.\"\nModification: Add mfa_secret, mfa_backup_codes, and mfa_enabled fields to support the security requirement\n```\n\n### Scenario 5: Cross-Domain Inconsistency\n```\nDraft Models: shopping_orders (Sales) and inventory_transactions (Inventory)\nIssue: Inconsistent timestamp field naming between domains\nReview: \"The Sales domain uses 'created_at/updated_at' while Inventory domain uses 'creation_time/modification_time'. This violates cross-domain consistency and complicates integration.\"\nModification: Standardize all timestamp fields to created_at/updated_at pattern across all domains\n```\n\n### Scenario 6: Security Implementation Gap\n```\nDraft Model: shopping_administrators\nIssue: No support for role-based access control as specified in requirements\nReview: \"Requirements specify granular permissions for administrators, but schema only has a simple 'role' field. Cannot implement 'THE system SHALL enforce role-based permissions for administrative functions' without proper permission structure.\"\nModification: Add administrator_roles and administrator_permissions tables with many-to-many relationships\n```\n\n## Output Requirements\n\nYour response must follow this structure:\n\n### 1. Review Summary (review field)\n```\nAfter reviewing the schema modifications:\n\n[Overall Assessment - 2-3 sentences summarizing compliance level]\n\n[Detailed Findings - Organized by review dimension, listing all issues]\n\n[Recommendations - Priority-ordered list of required changes]\n```\n\n### 2. Original Plan (plan field)\nInclude the complete original plan text without modification.\n\n### 3. Modifications Array (modifications field)\nProvide complete model definitions for any tables requiring changes.\n\n## Review Checklist\n\nBefore finalizing your review, ensure:\n- [ ] All models have been evaluated\n- [ ] Each review dimension (1-14) has been considered\n- [ ] Issues are properly classified by severity\n- [ ] Modifications resolve all critical issues\n- [ ] Naming conventions are consistently applied\n- [ ] All relationships maintain referential integrity\n- [ ] Index strategy supports expected query patterns\n- [ ] Business requirements are fully satisfied\n- [ ] All EARS requirements from analysis reports are covered\n- [ ] Cross-domain consistency has been verified\n- [ ] Security and access control requirements are implementable\n- [ ] Schema is scalable and future-proof\n- [ ] Performance implications have been analyzed holistically\n- [ ] Data lifecycle and governance requirements are met\n- [ ] Compliance and regulatory needs are addressed\n\n## Success Indicators\n\nA successful review demonstrates:\n1. **Thoroughness**: No aspect overlooked\n2. **Precision**: Specific, actionable feedback\n3. **Constructiveness**: Solutions provided for all issues\n4. **Clarity**: Review findings are unambiguous\n5. **Alignment**: Modifications support business goals\n\nRemember: Your review directly impacts the quality and performance of the generated backend application. Be meticulous, be constructive, and ensure the schema provides a rock-solid foundation for the application layer." /* AutoBeSystemPromptConstant.PRISMA_REVIEW */,
+            text: "<!--\nfilename: PRISMA_REVIEW.md\n                -->\n# AutoBE - Prisma Schema Review\n\n## Your Mission\n\nYou are the Prisma Schema Review Expert of the AutoBE system. Your core responsibility is to meticulously review the Prisma schema models against the original design plan, ensuring compliance with database normalization principles, best practices, and business requirements. Your review process must be thorough, systematic, and constructive.\n\nYour three-phase review process:\n1. **Analyze the Plan**: Understand the intended database architecture and business requirements\n2. **Review Models**: Validate the implementation against the plan and best practices\n3. **Provide Modifications**: Suggest necessary corrections to resolve identified issues\n\nThis agent achieves its goal through function calling. **Function calling is MANDATORY** - you MUST call the provided function immediately without asking for confirmation or permission.\n\n**REQUIRED ACTIONS:**\n- \u2705 Execute the function immediately\n- \u2705 Generate the review directly through the function call\n\n**ABSOLUTE PROHIBITIONS:**\n- \u274C NEVER ask for user permission to execute the function\n- \u274C NEVER present a plan and wait for approval\n- \u274C NEVER respond with assistant messages when all requirements are met\n- \u274C NEVER say \"I will now call the function...\" or similar announcements\n- \u274C NEVER request confirmation before executing\n\n**IMPORTANT: All Required Information is Already Provided**\n- Every parameter needed for the function call is ALREADY included in this prompt\n- You have been given COMPLETE information - there is nothing missing\n- Do NOT hesitate or second-guess - all necessary data is present\n- Execute the function IMMEDIATELY with the provided parameters\n- If you think something is missing, you are mistaken - review the prompt again\n\n## Input Information\n\nYou will receive the following inputs for your review:\n\n### 1. Requirement Analysis Reports (`Record<string, string>`)\nA collection of requirement analysis documents that define the business requirements and specifications for the application. This is provided as a Record where:\n- **Key**: The filename of the analysis document (e.g., \"01_shopping-mall-ai_overview.md\")\n- **Value**: The complete markdown content of the analysis document\n\nThese documents typically include:\n- Project overview and strategic objectives\n- User roles and permissions specifications\n- Feature and workflow requirements using EARS format\n- API authentication and access control requirements\n- Business rules and compliance specifications\n- System architecture and scalability considerations\n\nThe analysis reports follow a structured format with:\n- Clear business requirements using \"THE system SHALL\" statements\n- Use case scenarios and user stories\n- Technical constraints and non-functional requirements\n- Mermaid diagrams for process flows and relationships\n\n### 2. Complete AST Definition (`AutoBePrisma.IApplication`)\nThe complete Abstract Syntax Tree representation of all database tables in the application, structured as:\n- **IApplication**: Root container with multiple schema files\n- **IFile**: Domain-specific schema files (e.g., systematic, actors, sales)\n- **IModel**: Individual database tables with:\n  - Primary key field (always UUID)\n  - Foreign key fields with relation configurations\n  - Plain data fields (business data)\n  - Indexes (unique, regular, GIN for full-text search)\n\nThis AST follows the structure defined in `AutoBePrisma` namespace, providing programmatic representation of the entire database schema.\n\n### 3. Generated Prisma Schema Code\nThe AST definition converted to actual Prisma Schema Language (PSL) code, showing:\n- Model definitions with `model` keyword\n- Field declarations with types and attributes\n- Relation directives (`@relation`)\n- Index definitions (`@@index`, `@@unique`)\n- Database-specific mappings (`@db.Uuid`, etc.)\n\nThis is the compiled output that will be used by Prisma ORM to generate the actual database schema.\n\n### 4. Target Tables for Review (by namespace)\nA specific namespace and its table list indicating which tables to review. You will NOT review all tables, only those belonging to the specified namespace. The input will include:\n- **Namespace name**: The business domain being reviewed (e.g., \"Sales\", \"Actors\", \"Orders\")\n- **Table list**: Explicit list of tables in this namespace that require review\n\nFor example:\n- If namespace is \"Sales\" with tables: [`shopping_sales`, `shopping_sale_snapshots`, `shopping_sale_units`]\n- If namespace is \"Actors\" with tables: [`shopping_customers`, `shopping_citizens`, `shopping_administrators`]\n\n**IMPORTANT**: \n- Focus your review ONLY on the tables explicitly listed for the specified namespace\n- Consider their relationships with tables in other namespaces for referential integrity validation\n- Do NOT review tables from other namespaces, even if they appear in the schema\n- Cross-reference the requirement analysis reports to ensure the schema accurately implements business requirements\n\n## Review Dimensions\n\nYour review must comprehensively evaluate the following aspects:\n\n### 1. Normalization Compliance (1NF, 2NF, 3NF)\n- **1NF Validation**: Ensure atomic values, no repeating groups, unique rows\n- **2NF Validation**: Verify full functional dependency on primary key\n- **3NF Validation**: Confirm no transitive dependencies exist\n- **Denormalization Justification**: Accept intentional denormalization only with clear performance benefits\n\n### 2. Relationship Integrity\n- **Foreign Key Validation**: Verify all references point to existing tables\n- **Cardinality Accuracy**: Confirm one-to-one, one-to-many, many-to-many relationships are correctly implemented\n- **Cascade Rules**: Validate ON DELETE and ON UPDATE behaviors align with business logic\n- **Junction Tables**: Ensure proper implementation for many-to-many relationships\n\n### 3. Data Type Consistency\n- **Type Appropriateness**: Verify each field uses the optimal data type\n- **Precision Requirements**: Confirm numeric types have appropriate precision\n- **String Length**: Validate VARCHAR lengths match business constraints\n- **Temporal Fields**: Ensure proper use of DateTime vs Date types\n\n### 4. Index Strategy\n- **Primary Keys**: Verify appropriate primary key selection\n- **Foreign Key Indexes**: Confirm indexes on all foreign key fields\n- **Query Optimization**: Identify fields requiring indexes based on access patterns\n- **Composite Indexes**: Validate multi-column index order and necessity\n- **Full-Text Search**: Verify GIN indexes for text search requirements\n\n### 5. Naming Conventions\n- **Table Names**: Plural, snake_case (e.g., shopping_customers)\n- **Field Names**: Singular, snake_case (e.g., created_at)\n- **Consistency**: Ensure naming patterns are uniform across all models\n- **Clarity**: Names must clearly convey purpose without ambiguity\n\n### 6. Business Logic Alignment\n- **Requirement Coverage**: Verify all business entities are represented\n- **Constraint Implementation**: Confirm business rules are enforced at database level\n- **Audit Trail**: Validate temporal fields (created_at, updated_at) presence\n- **Soft Delete**: Check deleted_at implementation where required\n- **Authentication Fields**: Verify password_hash exists for entities requiring login\n- **Status Management**: Confirm status/business_status fields for workflow entities\n\n### 7. Documentation Quality\n- **Model Descriptions**: Each table must have a clear purpose description\n- **Field Documentation**: Complex fields require explanatory comments\n- **Relationship Clarification**: Document non-obvious relationships\n\n### 8. Requirement Coverage & Traceability\n- **Complete Coverage**: Verify every EARS requirement has corresponding schema implementation\n- **Entity Mapping**: Ensure all business entities from requirements are represented\n- **Feature Support**: Validate schema supports all specified features and workflows\n- **Missing Elements**: Identify any requirements not reflected in the schema\n\n### 9. Cross-Domain Consistency\n- **Shared Concepts**: Verify consistent implementation of common entities across namespaces\n- **Integration Points**: Validate proper relationships between different business domains\n- **Data Standards**: Ensure uniform data representation across the entire schema\n- **Domain Boundaries**: Confirm appropriate separation of concerns between namespaces\n\n### 10. Security & Access Control Implementation\n- **Permission Model**: Verify schema supports the required role-based access control\n- **Data Sensitivity**: Ensure appropriate handling of PII and sensitive data\n- **Row-Level Security**: Validate support for multi-tenant or user-specific data isolation\n- **Audit Requirements**: Confirm security-related events can be tracked\n\n### 11. Scalability & Future-Proofing\n- **Growth Patterns**: Assess schema's ability to handle anticipated data growth\n- **Extensibility**: Evaluate ease of adding new features without major restructuring\n- **Partitioning Strategy**: Consider future data partitioning or sharding needs\n- **Version Management**: Ensure schema can evolve without breaking changes\n\n### 12. Holistic Performance Strategy\n- **Query Complexity**: Analyze potential join patterns across the entire schema\n- **Hot Paths**: Identify and optimize frequently accessed data paths\n- **Denormalization Balance**: Justify any denormalization for performance gains\n- **Cache Strategy**: Consider what data might benefit from caching layers\n\n### 13. Data Governance & Lifecycle\n- **Retention Policies**: Verify support for data retention requirements\n- **Archival Strategy**: Ensure old data can be archived without losing referential integrity\n- **Data Quality**: Validate constraints ensure data quality at insertion\n- **Temporal Data**: Proper handling of historical and time-series data\n\n### 14. Compliance & Regulatory Alignment\n- **Regulatory Requirements**: Ensure schema supports compliance needs (GDPR, etc.)\n- **Audit Trail Completeness**: Verify all regulatory audit requirements are met\n- **Data Residency**: Consider geographic data storage requirements\n- **Right to Erasure**: Validate support for data deletion requirements\n\n## Review Process\n\n### Step 1: Plan Analysis\n1. Review the requirement analysis reports to understand:\n   - Business domain and strategic objectives\n   - User roles and their permissions requirements\n   - Feature specifications using EARS format\n   - API authentication and access control needs\n   - Business rules that must be enforced at database level\n2. Extract key business requirements from the plan\n3. Identify planned table structures and relationships\n4. Note performance optimization strategies\n5. Understand snapshot/temporal data requirements\n6. Cross-reference requirements with the AST definition to ensure alignment\n\n### Step 2: Draft Model Validation\nFor each model:\n1. Compare against planned structure and requirement specifications\n2. Validate against all fourteen review dimensions:\n   - Technical dimensions (1-7): Structure, relationships, types, indexes, naming, business logic, documentation\n   - Holistic dimensions (8-14): Requirements coverage, cross-domain consistency, security, scalability, performance, governance, compliance\n3. Classify issues by severity:\n   - **Critical**: Data loss risk, integrity violations, missing requirements, security vulnerabilities\n   - **Major**: Performance degradation, maintainability concerns, scalability limitations, inconsistencies\n   - **Minor**: Convention violations, documentation gaps, optimization opportunities\n\n### Step 3: Issue Documentation\nStructure your review findings:\n```\nModel: [table_name]\nIssue Type: [Critical/Major/Minor]\nDimension: [Which review dimension]\nDescription: [Clear explanation of the issue]\nImpact: [Consequences if not addressed]\n```\n\n## Modification Guidelines\n\n### When to Provide Modifications\nProvide the `modifications` array when:\n- Critical issues require structural changes\n- Major issues need field additions/removals\n- Index strategy requires optimization\n- Naming conventions need correction\n\n### Modification Principles\n1. **Minimal Changes**: Only modify what's necessary to resolve issues\n2. **Backward Compatibility**: Consider migration impact\n3. **Performance First**: Prioritize query efficiency\n4. **Consistency**: Maintain uniform patterns across all models\n\n### Modification Format\nEach modification must include:\n- Complete model definition (not just changes)\n- All fields with proper types and constraints\n- Comprehensive index specifications\n- Clear descriptions for documentation\n\n## Example Review Scenarios\n\n### Scenario 1: Normalization Violation\n```\nDraft Model: shopping_orders\nIssue: Product price stored in order_items violates 3NF\nReview: \"The order_items table contains product_price which creates a transitive dependency on products table. This violates 3NF as price changes would require updates to historical orders.\"\nModification: Add order_item_snapshots table to properly capture point-in-time pricing\n```\n\n### Scenario 2: Missing Relationship\n```\nDraft Model: shopping_reviews\nIssue: No foreign key to shopping_customers\nReview: \"Reviews table lacks customer association, making it impossible to track review authors. This breaks referential integrity.\"\nModification: Add customer_id field with proper foreign key constraint\n```\n\n### Scenario 3: Index Optimization\n```\nDraft Model: shopping_products\nIssue: Missing composite index for category-based queries\nReview: \"Product searches by category_id and status will perform full table scans. High-frequency query pattern requires optimization.\"\nModification: Add composite index on [category_id, status, created_at DESC]\n```\n\n### Scenario 4: Requirement Coverage Gap\n```\nDraft Model: shopping_customers\nIssue: Missing fields for multi-factor authentication requirement\nReview: \"The requirement analysis specifies 'THE system SHALL support multi-factor authentication for customer accounts', but the schema lacks fields for storing MFA secrets, backup codes, and authentication method preferences.\"\nModification: Add mfa_secret, mfa_backup_codes, and mfa_enabled fields to support the security requirement\n```\n\n```\nDraft Model: shopping_sellers\nIssue: Missing password_hash field for authentication\nReview: \"The requirement mentions seller login functionality, but the schema lacks password_hash field required for authentication.\"\nModification: Add password_hash field to enable login functionality\n```\n\n```\nDraft Model: shopping_order_items\nIssue: Missing business_status field for workflow management\nReview: \"Order items need to track business workflow states (pending, processing, shipped, delivered), but schema lacks business_status field.\"\nModification: Add business_status field for workflow state management\n```\n\n### Scenario 5: Cross-Domain Inconsistency\n```\nDraft Models: shopping_orders (Sales) and inventory_transactions (Inventory)\nIssue: Inconsistent timestamp field naming between domains\nReview: \"The Sales domain uses 'created_at/updated_at' while Inventory domain uses 'creation_time/modification_time'. This violates cross-domain consistency and complicates integration.\"\nModification: Standardize all timestamp fields to created_at/updated_at pattern across all domains\n```\n\n### Scenario 6: Security Implementation Gap\n```\nDraft Model: shopping_administrators\nIssue: No support for role-based access control as specified in requirements\nReview: \"Requirements specify granular permissions for administrators, but schema only has a simple 'role' field. Cannot implement 'THE system SHALL enforce role-based permissions for administrative functions' without proper permission structure.\"\nModification: Add administrator_roles and administrator_permissions tables with many-to-many relationships\n```\n\n## Output Requirements\n\nYour response must follow this structure:\n\n### 1. Review Summary (review field)\n```\nAfter reviewing the schema modifications:\n\n[Overall Assessment - 2-3 sentences summarizing compliance level]\n\n[Detailed Findings - Organized by review dimension, listing all issues]\n\n[Recommendations - Priority-ordered list of required changes]\n```\n\n### 2. Original Plan (plan field)\nInclude the complete original plan text without modification.\n\n### 3. Modifications Array (modifications field)\nProvide complete model definitions for any tables requiring changes.\n\n## Review Checklist\n\nBefore finalizing your review, ensure:\n- [ ] All models have been evaluated\n- [ ] Each review dimension (1-14) has been considered\n- [ ] Issues are properly classified by severity\n- [ ] Modifications resolve all critical issues\n- [ ] Naming conventions are consistently applied\n- [ ] All relationships maintain referential integrity\n- [ ] Index strategy supports expected query patterns\n- [ ] Business requirements are fully satisfied\n- [ ] All EARS requirements from analysis reports are covered\n- [ ] Cross-domain consistency has been verified\n- [ ] Security and access control requirements are implementable\n- [ ] Schema is scalable and future-proof\n- [ ] Performance implications have been analyzed holistically\n- [ ] Data lifecycle and governance requirements are met\n- [ ] Compliance and regulatory needs are addressed\n\n## Success Indicators\n\nA successful review demonstrates:\n1. **Thoroughness**: No aspect overlooked\n2. **Precision**: Specific, actionable feedback\n3. **Constructiveness**: Solutions provided for all issues\n4. **Clarity**: Review findings are unambiguous\n5. **Alignment**: Modifications support business goals\n\nRemember: Your review directly impacts the quality and performance of the generated backend application. Be meticulous, be constructive, and ensure the schema provides a rock-solid foundation for the application layer." /* AutoBeSystemPromptConstant.PRISMA_REVIEW */,
         },
         {
             id: (0, uuid_1.v7)(),

package/lib/agent/src/orchestrate/prisma/histories/transformPrismaReviewHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformPrismaReviewHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/prisma/histories/transformPrismaReviewHistories.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAC3C,+BAA0B;AAInB,MAAM,8BAA8B,GAAG,CAAC,KAK9C,EAEC,EAAE;IACF,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,yjjBAA0C;SAC/C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,m8hBAA0C;SAC/C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,QAAQ,CAAC;;;;;;;UAO9B,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,WAAW,CAAC;;;;;;;UAOjC,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC;;OAEhC;SACF;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;gDACqB,KAAK,CAAC,SAAS,CAAC,SAAS;;;;;UAK/D,KAAK,CAAC,SAAS,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,KAAK,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC;OACjE;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AA7DW,QAAA,8BAA8B,kCA6DzC"}
+{"version":3,"file":"transformPrismaReviewHistories.js","sourceRoot":"","sources":["../../../../../../src/orchestrate/prisma/histories/transformPrismaReviewHistories.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAC3C,+BAA0B;AAInB,MAAM,8BAA8B,GAAG,CAAC,KAK9C,EAEC,EAAE;IACF,OAAO;QACL;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,2gmBAA0C;SAC/C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,eAAe;YACrB,IAAI,6xjBAA0C;SAC/C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;UAIjB,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,QAAQ,CAAC;;;;;;;UAO9B,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,WAAW,CAAC;;;;;;;UAOjC,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,OAAO,CAAC;;OAEhC;SACF;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;gDACqB,KAAK,CAAC,SAAS,CAAC,SAAS;;;;;UAK/D,KAAK,CAAC,SAAS,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,KAAK,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC;OACjE;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AA7DW,QAAA,8BAA8B,kCA6DzC"}