@autobe/agent 0.25.5 → 0.25.7

package/lib/orchestrate/analyze/orchestrateAnalyze.js

@@ -15,7 +15,7 @@ const executeCachedBatch_1 = require("../../utils/executeCachedBatch");
 const orchestrateAnalyzeReview_1 = require("./orchestrateAnalyzeReview");
 const orchestrateAnalyzeScenario_1 = require("./orchestrateAnalyzeScenario");
 const orchestrateAnalyzeWrite_1 = require("./orchestrateAnalyzeWrite");
-const orchestrateAnalyze = (ctx) => (props) => __awaiter(void 0, void 0, void 0, function* () {
+const orchestrateAnalyze = (ctx) => __awaiter(void 0, void 0, void 0, function* () {
     var _a, _b;
     // Initialize analysis state
     const step = ((_b = (_a = ctx.state().analyze) === null || _a === void 0 ? void 0 : _a.step) !== null && _b !== void 0 ? _b : -1) + 1;
@@ -23,12 +23,11 @@ const orchestrateAnalyze = (ctx) => (props) => __awaiter(void 0, void 0, void 0,
     ctx.dispatch({
         type: "analyzeStart",
         id: (0, uuid_1.v7)(),
-        reason: props.instruction,
         step,
         created_at: startTime.toISOString(),
     });
     // Generate analysis scenario
-    const scenario = yield (0, orchestrateAnalyzeScenario_1.orchestrateAnalyzeScenario)(ctx, props.instruction);
+    const scenario = yield (0, orchestrateAnalyzeScenario_1.orchestrateAnalyzeScenario)(ctx);
     if (scenario.type === "assistantMessage")
         return ctx.assistantMessage(scenario);
     else
@@ -44,7 +43,6 @@ const orchestrateAnalyze = (ctx) => (props) => __awaiter(void 0, void 0, void 0,
             file,
             progress: writeProgress,
             promptCacheKey,
-            instruction: props.instruction,
         });
         return event.file;
     })));

package/lib/orchestrate/analyze/orchestrateAnalyze.js.map

@@ -1 +1 @@
-{"version":3,"file":"orchestrateAnalyze.js","sourceRoot":"","sources":["../../../src/orchestrate/analyze/orchestrateAnalyze.ts"],"names":[],"mappings":";;;;;;;;;;;;AAUA,+BAA0B;AAI1B,uEAAoE;AACpE,yEAAsE;AACtE,6EAA0E;AAC1E,uEAAoE;AAE7D,MAAM,kBAAkB,GAC7B,CAAiC,GAAyB,EAAE,EAAE,CAC9D,CACE,KAA8B,EACiC,EAAE;;IACjE,4BAA4B;IAC5B,MAAM,IAAI,GAAW,CAAC,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC;IAC3D,MAAM,SAAS,GAAS,IAAI,IAAI,EAAE,CAAC;IAEnC,GAAG,CAAC,QAAQ,CAAC;QACX,IAAI,EAAE,cAAc;QACpB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,MAAM,EAAE,KAAK,CAAC,WAAW;QACzB,IAAI;QACJ,UAAU,EAAE,SAAS,CAAC,WAAW,EAAE;KACpC,CAAC,CAAC;IAEH,6BAA6B;IAC7B,MAAM,QAAQ,GACZ,MAAM,IAAA,uDAA0B,EAAC,GAAG,EAAE,KAAK,CAAC,WAAW,CAAC,CAAC;IAC3D,IAAI,QAAQ,CAAC,IAAI,KAAK,kBAAkB;QACtC,OAAO,GAAG,CAAC,gBAAgB,CAAC,QAAQ,CAAC,CAAC;;QACnC,GAAG,CAAC,QAAQ,CAAC,QAAQ,CAAC,CAAC;IAE5B,kBAAkB;IAClB,MAAM,aAAa,GAA4B;QAC7C,KAAK,EAAE,QAAQ,CAAC,KAAK,CAAC,MAAM;QAC5B,SAAS,EAAE,CAAC;KACb,CAAC;IACF,MAAM,QAAQ,GAAwB,MAAM,IAAA,uCAAkB,EAC5D,QAAQ,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAO,cAAc,EAAE,EAAE;QACpD,MAAM,KAAK,GAA4B,MAAM,IAAA,iDAAuB,EAClE,GAAG,EACH;YACE,QAAQ;YACR,IAAI;YACJ,QAAQ,EAAE,aAAa;YACvB,cAAc;YACd,WAAW,EAAE,KAAK,CAAC,WAAW;SAC/B,CACF,CAAC;QACF,OAAO,KAAK,CAAC,IAAI,CAAC;IACpB,CAAC,CAAA,CAAC,CACH,CAAC;IAEF,mBAAmB;IACnB,MAAM,cAAc,GAA4B;QAC9C,KAAK,EAAE,QAAQ,CAAC,MAAM;QACtB,SAAS,EAAE,CAAC;KACb,CAAC;IACF,MAAM,QAAQ,GAAwB,MAAM,IAAA,uCAAkB,EAC5D,QAAQ,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAO,cAAc,EAAE,EAAE;QAC9C,IAAI,CAAC;YACH,MAAM,KAAK,GACT,MAAM,IAAA,mDAAwB,EAAC,GAAG,EAAE;gBAClC,QAAQ;gBACR,QAAQ,EAAE,QAAQ,EAAE,YAAY;gBAChC,MAAM,EAAE,IAAI;gBACZ,QAAQ,EAAE,cAAc;gBACxB,cAAc;aACf,CAAC,CAAC;YACL,uCACK,KAAK,CAAC,IAAI,KACb,OAAO,EAAE,KAAK,CAAC,OAAO,IACtB;QACJ,CAAC;QAAC,WAAM,CAAC;YACP,OAAO,IAAI,CAAC;QACd,CAAC;IACH,CAAC,CAAA,CAAC,CACH,CAAC;IAEF,wBAAwB;IACxB,OAAO,GAAG,CAAC,QAAQ,CAAC;QAClB,IAAI,EAAE,iBAAiB;QACvB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,KAAK,EAAE,QAAQ,CAAC,KAAK;QACrB,MAAM,EAAE,QAAQ,CAAC,MAAM;QACvB,KAAK,EAAE,QAAQ;QACf,IAAI;QACJ,OAAO,EAAE,IAAI,IAAI,EAAE,CAAC,OAAO,EAAE,GAAG,SAAS,CAAC,OAAO,EAAE;QACnD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;KACrC,CAAgC,CAAC;AACpC,CAAC,CAAA,CAAC;AAlFS,QAAA,kBAAkB,sBAkF3B"}
+{"version":3,"file":"orchestrateAnalyze.js","sourceRoot":"","sources":["../../../src/orchestrate/analyze/orchestrateAnalyze.ts"],"names":[],"mappings":";;;;;;;;;;;;AAUA,+BAA0B;AAG1B,uEAAoE;AACpE,yEAAsE;AACtE,6EAA0E;AAC1E,uEAAoE;AAE7D,MAAM,kBAAkB,GAAG,CAChC,GAAyB,EACsC,EAAE;;IACjE,4BAA4B;IAC5B,MAAM,IAAI,GAAW,CAAC,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC;IAC3D,MAAM,SAAS,GAAS,IAAI,IAAI,EAAE,CAAC;IAEnC,GAAG,CAAC,QAAQ,CAAC;QACX,IAAI,EAAE,cAAc;QACpB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,IAAI;QACJ,UAAU,EAAE,SAAS,CAAC,WAAW,EAAE;KACpC,CAAC,CAAC;IAEH,6BAA6B;IAC7B,MAAM,QAAQ,GACZ,MAAM,IAAA,uDAA0B,EAAC,GAAG,CAAC,CAAC;IACxC,IAAI,QAAQ,CAAC,IAAI,KAAK,kBAAkB;QACtC,OAAO,GAAG,CAAC,gBAAgB,CAAC,QAAQ,CAAC,CAAC;;QACnC,GAAG,CAAC,QAAQ,CAAC,QAAQ,CAAC,CAAC;IAE5B,kBAAkB;IAClB,MAAM,aAAa,GAA4B;QAC7C,KAAK,EAAE,QAAQ,CAAC,KAAK,CAAC,MAAM;QAC5B,SAAS,EAAE,CAAC;KACb,CAAC;IACF,MAAM,QAAQ,GAAwB,MAAM,IAAA,uCAAkB,EAC5D,QAAQ,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAO,cAAc,EAAE,EAAE;QACpD,MAAM,KAAK,GAA4B,MAAM,IAAA,iDAAuB,EAClE,GAAG,EACH;YACE,QAAQ;YACR,IAAI;YACJ,QAAQ,EAAE,aAAa;YACvB,cAAc;SACf,CACF,CAAC;QACF,OAAO,KAAK,CAAC,IAAI,CAAC;IACpB,CAAC,CAAA,CAAC,CACH,CAAC;IAEF,mBAAmB;IACnB,MAAM,cAAc,GAA4B;QAC9C,KAAK,EAAE,QAAQ,CAAC,MAAM;QACtB,SAAS,EAAE,CAAC;KACb,CAAC;IACF,MAAM,QAAQ,GAAwB,MAAM,IAAA,uCAAkB,EAC5D,QAAQ,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,CAAO,cAAc,EAAE,EAAE;QAC9C,IAAI,CAAC;YACH,MAAM,KAAK,GAA6B,MAAM,IAAA,mDAAwB,EACpE,GAAG,EACH;gBACE,QAAQ;gBACR,QAAQ,EAAE,QAAQ,EAAE,YAAY;gBAChC,MAAM,EAAE,IAAI;gBACZ,QAAQ,EAAE,cAAc;gBACxB,cAAc;aACf,CACF,CAAC;YACF,uCACK,KAAK,CAAC,IAAI,KACb,OAAO,EAAE,KAAK,CAAC,OAAO,IACtB;QACJ,CAAC;QAAC,WAAM,CAAC;YACP,OAAO,IAAI,CAAC;QACd,CAAC;IACH,CAAC,CAAA,CAAC,CACH,CAAC;IAEF,wBAAwB;IACxB,OAAO,GAAG,CAAC,QAAQ,CAAC;QAClB,IAAI,EAAE,iBAAiB;QACvB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,KAAK,EAAE,QAAQ,CAAC,KAAK;QACrB,MAAM,EAAE,QAAQ,CAAC,MAAM;QACvB,KAAK,EAAE,QAAQ;QACf,IAAI;QACJ,OAAO,EAAE,IAAI,IAAI,EAAE,CAAC,OAAO,EAAE,GAAG,SAAS,CAAC,OAAO,EAAE;QACnD,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;KACrC,CAAgC,CAAC;AACpC,CAAC,CAAA,CAAC;AAhFW,QAAA,kBAAkB,sBAgF7B"}

package/lib/orchestrate/analyze/orchestrateAnalyzeScenario.d.ts

@@ -1,4 +1,4 @@
 import { AutoBeAnalyzeScenarioEvent, AutoBeAssistantMessageHistory } from "@autobe/interface";
 import { ILlmSchema } from "@samchon/openapi";
 import { AutoBeContext } from "../../context/AutoBeContext";
-export declare const orchestrateAnalyzeScenario: <Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, instruction: string) => Promise<AutoBeAnalyzeScenarioEvent | AutoBeAssistantMessageHistory>;
+export declare const orchestrateAnalyzeScenario: <Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>) => Promise<AutoBeAnalyzeScenarioEvent | AutoBeAssistantMessageHistory>;

package/lib/orchestrate/analyze/orchestrateAnalyzeScenario.js

@@ -52,7 +52,7 @@ const typia_1 = __importDefault(require("typia"));
 const uuid_1 = require("uuid");
 const assertSchemaModel_1 = require("../../context/assertSchemaModel");
 const transformAnalyzeScenarioHistories_1 = require("./histories/transformAnalyzeScenarioHistories");
-const orchestrateAnalyzeScenario = (ctx, instruction) => __awaiter(void 0, void 0, void 0, function* () {
+const orchestrateAnalyzeScenario = (ctx) => __awaiter(void 0, void 0, void 0, function* () {
     var _a, _b, _c;
     const start = new Date();
     const pointer = {
@@ -64,7 +64,7 @@ const orchestrateAnalyzeScenario = (ctx, instruction) => __awaiter(void 0, void
             model: ctx.model,
             build: (value) => (pointer.value = value),
         }),
-        histories: (0, transformAnalyzeScenarioHistories_1.transformAnalyzeSceHistories)(ctx, instruction),
+        histories: (0, transformAnalyzeScenarioHistories_1.transformAnalyzeSceHistories)(ctx),
         enforceFunctionCall: false,
         message: utils_1.StringUtil.trim `
       Design a complete list of documents and user roles for this project.

package/lib/orchestrate/analyze/orchestrateAnalyzeScenario.js.map

@@ -1 +1 @@
-{"version":3,"file":"orchestrateAnalyzeScenario.js","sourceRoot":"","sources":["../../../src/orchestrate/analyze/orchestrateAnalyzeScenario.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAQA,yCAA2C;AAG3C,kDAA0B;AAC1B,+BAA0B;AAG1B,uEAAoE;AACpE,qGAA6F;AAGtF,MAAM,0BAA0B,GAAG,CAGxC,GAAyB,EACzB,WAAmB,EACkD,EAAE;;IACvE,MAAM,KAAK,GAAS,IAAI,IAAI,EAAE,CAAC;IAC/B,MAAM,OAAO,GAA8D;QACzE,KAAK,EAAE,IAAI;KACZ,CAAC;IACF,MAAM,EAAE,SAAS,EAAE,UAAU,EAAE,GAAG,MAAM,GAAG,CAAC,UAAU,CAAC;QACrD,MAAM,EAAE,iBAAiB;QACzB,UAAU,EAAE,gBAAgB,CAAQ;YAClC,KAAK,EAAE,GAAG,CAAC,KAAK;YAChB,KAAK,EAAE,CAAC,KAAK,EAAE,EAAE,CAAC,CAAC,OAAO,CAAC,KAAK,GAAG,KAAK,CAAC;SAC1C,CAAC;QACF,SAAS,EAAE,IAAA,gEAA4B,EAAC,GAAG,EAAE,WAAW,CAAC;QACzD,mBAAmB,EAAE,KAAK;QAC1B,OAAO,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;0CAIc,GAAG,CAAC,MAAM;KAC/C;KACF,CAAC,CAAC;IACH,IAAI,CAAA,MAAA,SAAS,CAAC,EAAE,CAAC,CAAC,CAAC,CAAC,0CAAE,IAAI,MAAK,kBAAkB;QAC/C,OAAO,gCACD,SAAS,CAAC,EAAE,CAAC,CAAC,CAAC,CAAsC,KACzD,UAAU,EAAE,KAAK,CAAC,WAAW,EAAE,EAC/B,YAAY,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE,EACtC,EAAE,EAAE,IAAA,SAAE,GAAE,GAC+B,CAAC;SACvC,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI,EAAE,CAAC;QAChC,cAAc;QACd,MAAM,IAAI,KAAK,CAAC,qCAAqC,CAAC,CAAC;IACzD,CAAC;IACD,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,MAAM,EAAE,OAAO,CAAC,KAAK,CAAC,MAAM;QAC5B,QAAQ,EAAE,OAAO,CAAC,KAAK,CAAC,QAAQ;QAChC,KAAK,EAAE,OAAO,CAAC,KAAK,CAAC,KAAK;QAC1B,KAAK,EAAE,OAAO,CAAC,KAAK,CAAC,KAAK;QAC1B,UAAU;QACV,IAAI,EAAE,CAAC,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC,CAAC,CAAC,GAAG,CAAC;QAC3C,UAAU,EAAE,KAAK,CAAC,WAAW,EAAE;KAChC,CAAC;AACJ,CAAC,CAAA,CAAC;AA/CW,QAAA,0BAA0B,8BA+CrC;AAEF,SAAS,gBAAgB,CAAiC,KAGzD;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAC/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACwD,CAAC;IACtE,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,SAAS;QACf,WAAW;QACX,OAAO,EAAE;YACP,OAAO,EAAE,CAAC,KAAK,EAAE,EAAE;gBACjB,KAAK,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC;YACrB,CAAC;SAC0C;KAC9C,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAGT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAGJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;CACd,CAAC"}
+{"version":3,"file":"orchestrateAnalyzeScenario.js","sourceRoot":"","sources":["../../../src/orchestrate/analyze/orchestrateAnalyzeScenario.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAQA,yCAA2C;AAG3C,kDAA0B;AAC1B,+BAA0B;AAG1B,uEAAoE;AACpE,qGAA6F;AAGtF,MAAM,0BAA0B,GAAG,CAGxC,GAAyB,EAC4C,EAAE;;IACvE,MAAM,KAAK,GAAS,IAAI,IAAI,EAAE,CAAC;IAC/B,MAAM,OAAO,GAA8D;QACzE,KAAK,EAAE,IAAI;KACZ,CAAC;IACF,MAAM,EAAE,SAAS,EAAE,UAAU,EAAE,GAAG,MAAM,GAAG,CAAC,UAAU,CAAC;QACrD,MAAM,EAAE,iBAAiB;QACzB,UAAU,EAAE,gBAAgB,CAAQ;YAClC,KAAK,EAAE,GAAG,CAAC,KAAK;YAChB,KAAK,EAAE,CAAC,KAAK,EAAE,EAAE,CAAC,CAAC,OAAO,CAAC,KAAK,GAAG,KAAK,CAAC;SAC1C,CAAC;QACF,SAAS,EAAE,IAAA,gEAA4B,EAAC,GAAG,CAAC;QAC5C,mBAAmB,EAAE,KAAK;QAC1B,OAAO,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;0CAIc,GAAG,CAAC,MAAM;KAC/C;KACF,CAAC,CAAC;IACH,IAAI,CAAA,MAAA,SAAS,CAAC,EAAE,CAAC,CAAC,CAAC,CAAC,0CAAE,IAAI,MAAK,kBAAkB;QAC/C,OAAO,gCACD,SAAS,CAAC,EAAE,CAAC,CAAC,CAAC,CAAsC,KACzD,UAAU,EAAE,KAAK,CAAC,WAAW,EAAE,EAC/B,YAAY,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE,EACtC,EAAE,EAAE,IAAA,SAAE,GAAE,GAC+B,CAAC;SACvC,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI,EAAE,CAAC;QAChC,cAAc;QACd,MAAM,IAAI,KAAK,CAAC,qCAAqC,CAAC,CAAC;IACzD,CAAC;IACD,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,MAAM,EAAE,OAAO,CAAC,KAAK,CAAC,MAAM;QAC5B,QAAQ,EAAE,OAAO,CAAC,KAAK,CAAC,QAAQ;QAChC,KAAK,EAAE,OAAO,CAAC,KAAK,CAAC,KAAK;QAC1B,KAAK,EAAE,OAAO,CAAC,KAAK,CAAC,KAAK;QAC1B,UAAU;QACV,IAAI,EAAE,CAAC,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC,CAAC,CAAC,GAAG,CAAC;QAC3C,UAAU,EAAE,KAAK,CAAC,WAAW,EAAE;KAChC,CAAC;AACJ,CAAC,CAAA,CAAC;AA9CW,QAAA,0BAA0B,8BA8CrC;AAEF,SAAS,gBAAgB,CAAiC,KAGzD;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAC/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACwD,CAAC;IACtE,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,SAAS;QACf,WAAW;QACX,OAAO,EAAE;YACP,OAAO,EAAE,CAAC,KAAK,EAAE,EAAE;gBACjB,KAAK,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC;YACrB,CAAC;SAC0C;KAC9C,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAGT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAGJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;CACd,CAAC"}

package/lib/orchestrate/analyze/orchestrateAnalyzeWrite.d.ts

@@ -5,7 +5,6 @@ import { AutoBeContext } from "../../context/AutoBeContext";
 export declare const orchestrateAnalyzeWrite: <Model extends ILlmSchema.Model>(ctx: AutoBeContext<Model>, props: {
     scenario: AutoBeAnalyzeScenarioEvent;
     file: AutoBeAnalyzeFile.Scenario;
-    instruction: string;
     progress: AutoBeProgressEventBase;
     promptCacheKey: string;
 }) => Promise<AutoBeAnalyzeWriteEvent>;

package/lib/orchestrate/analyze/orchestrateAnalyzeWrite.js.map

@@ -1 +1 @@
-{"version":3,"file":"orchestrateAnalyzeWrite.js","sourceRoot":"","sources":["../../../src/orchestrate/analyze/orchestrateAnalyzeWrite.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AASA,kDAA0B;AAC1B,+BAA0B;AAG1B,uEAAoE;AACpE,+FAA4F;AAGrF,MAAM,uBAAuB,GAAG,CACrC,GAAyB,EACzB,KAMC,EACiC,EAAE;;IACpC,MAAM,EAAE,IAAI,EAAE,QAAQ,EAAE,cAAc,EAAE,GAAG,KAAK,CAAC;IACjD,MAAM,OAAO,GAA2D;QACtE,KAAK,EAAE,IAAI;KACZ,CAAC;IACF,MAAM,EAAE,UAAU,EAAE,GAAG,MAAM,GAAG,CAAC,UAAU,CAAC;QAC1C,MAAM,EAAE,cAAc;QACtB,UAAU,EAAE,gBAAgB,CAAQ;YAClC,KAAK,EAAE,GAAG,CAAC,KAAK;YAChB,OAAO;SACR,CAAC;QACF,SAAS,EAAE,IAAA,+DAA8B,EAAC,GAAG,EAAE,KAAK,CAAC;QACrD,mBAAmB,EAAE,IAAI;QACzB,cAAc;QACd,OAAO,EAAE,oCAAoC;KAC9C,CAAC,CAAC;IACH,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI;QACxB,MAAM,IAAI,KAAK,CAAC,kDAAkD,CAAC,CAAC;IAEtE,MAAM,KAAK,GAA4B;QACrC,IAAI,EAAE,cAAc;QACpB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,IAAI,kCACC,IAAI,KACP,OAAO,EAAE,OAAO,CAAC,KAAK,CAAC,OAAO,GAC/B;QACD,UAAU,EAAE,UAAU;QACtB,IAAI,EAAE,CAAC,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC,CAAC,CAAC,GAAG,CAAC;QAC3C,KAAK,EAAE,QAAQ,CAAC,KAAK;QACrB,SAAS,EAAE,EAAE,QAAQ,CAAC,SAAS;QAC/B,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;KACrC,CAAC;IACF,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC;IACpB,OAAO,KAAK,CAAC;AACf,CAAC,CAAA,CAAC;AA3CW,QAAA,uBAAuB,2BA2ClC;AAEF,SAAS,gBAAgB,CAAiC,KAGzD;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAC/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACwD,CAAC;IACtE,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,UAAU;QAChB,WAAW;QACX,OAAO,EAAE;YACP,KAAK,EAAE,CAAO,KAAK,EAAE,EAAE;gBACrB,KAAK,CAAC,OAAO,CAAC,KAAK,GAAG,KAAK,CAAC;YAC9B,CAAC,CAAA;SACuC;KAC3C,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAGT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAoE;IAC3E,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;CACd,CAAC"}
+{"version":3,"file":"orchestrateAnalyzeWrite.js","sourceRoot":"","sources":["../../../src/orchestrate/analyze/orchestrateAnalyzeWrite.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AASA,kDAA0B;AAC1B,+BAA0B;AAG1B,uEAAoE;AACpE,+FAA4F;AAGrF,MAAM,uBAAuB,GAAG,CACrC,GAAyB,EACzB,KAKC,EACiC,EAAE;;IACpC,MAAM,EAAE,IAAI,EAAE,QAAQ,EAAE,cAAc,EAAE,GAAG,KAAK,CAAC;IACjD,MAAM,OAAO,GAA2D;QACtE,KAAK,EAAE,IAAI;KACZ,CAAC;IACF,MAAM,EAAE,UAAU,EAAE,GAAG,MAAM,GAAG,CAAC,UAAU,CAAC;QAC1C,MAAM,EAAE,cAAc;QACtB,UAAU,EAAE,gBAAgB,CAAQ;YAClC,KAAK,EAAE,GAAG,CAAC,KAAK;YAChB,OAAO;SACR,CAAC;QACF,SAAS,EAAE,IAAA,+DAA8B,EAAC,GAAG,EAAE,KAAK,CAAC;QACrD,mBAAmB,EAAE,IAAI;QACzB,cAAc;QACd,OAAO,EAAE,oCAAoC;KAC9C,CAAC,CAAC;IACH,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI;QACxB,MAAM,IAAI,KAAK,CAAC,kDAAkD,CAAC,CAAC;IAEtE,MAAM,KAAK,GAA4B;QACrC,IAAI,EAAE,cAAc;QACpB,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,IAAI,kCACC,IAAI,KACP,OAAO,EAAE,OAAO,CAAC,KAAK,CAAC,OAAO,GAC/B;QACD,UAAU,EAAE,UAAU;QACtB,IAAI,EAAE,CAAC,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC,CAAC,CAAC,GAAG,CAAC;QAC3C,KAAK,EAAE,QAAQ,CAAC,KAAK;QACrB,SAAS,EAAE,EAAE,QAAQ,CAAC,SAAS;QAC/B,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;KACrC,CAAC;IACF,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC;IACpB,OAAO,KAAK,CAAC;AACf,CAAC,CAAA,CAAC;AA1CW,QAAA,uBAAuB,2BA0ClC;AAEF,SAAS,gBAAgB,CAAiC,KAGzD;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAC/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACwD,CAAC;IACtE,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,UAAU;QAChB,WAAW;QACX,OAAO,EAAE;YACP,KAAK,EAAE,CAAO,KAAK,EAAE,EAAE;gBACrB,KAAK,CAAC,OAAO,CAAC,KAAK,GAAG,KAAK,CAAC;YAC9B,CAAC,CAAA;SACuC;KAC3C,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAGT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAoE;IAC3E,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;CACd,CAAC"}

package/lib/orchestrate/facade/transformFacadeStateMessage.js

@@ -4,7 +4,7 @@ exports.transformFacadeStateMessage = transformFacadeStateMessage;
 const utils_1 = require("@autobe/utils");
 function transformFacadeStateMessage(state) {
     const currentState = getCurrentState(state);
-    return "<!--\nfilename: FACADE.md\n-->\n# AutoBE Main Agent System Prompt\n\nYou are the AutoBE Main Agent, an orchestrator for backend server development automation. Your role is to manage the conversation with users about their backend requirements and coordinate the execution of five specialized functional agents through function calling.\n\n## Core Responsibilities\n\n1. **Requirements Gathering**: Engage in detailed conversations with users to understand their backend server needs, asking clarifying questions about business logic, data models, API endpoints, and technical requirements.\n\n2. **Agent Orchestration**: Execute the appropriate functional agents in the correct sequence based on the development stage and user needs.\n\n3. **Progress Communication**: Keep users informed about the current development stage, what has been completed, and what steps remain.\n\n## Functional Agents Overview\n\nYou have access to five functional agents that must be executed in a specific order:\n\n1. **Analyze Agent** - Converts conversations into structured requirements specifications\n2. **Prisma Agent** - Generates database schemas and ERD documentation\n3. **Interface Agent** - Creates API interfaces with OpenAPI schemas and TypeScript code\n4. **Test Agent** - Generates comprehensive E2E test suites\n5. **Realize Agent** - Implements actual business logic for service providers\n\n## Execution Rules\n\n### 1. Sequential Dependencies\n\n- **analyze()**: Can only be called when sufficient requirements have been gathered.\n- **prisma()**: Requires successful completion of analyze()\n- **interface()**: Requires successful completion of prisma()\n- **test()**: Requires successful completion of interface()\n- **realize()**: Requires successful completion of interface()\n\n### 2. Requirements Gathering and analyze() Calling Criteria\n\n- Since users are not developers, it is okay if they do not understand technical terms like \u201Cendpoints\u201D or \u201Cdata models.\u201D  \n\n- Your job is to help users clearly express their intended **features** by asking many questions.  \n\n- Use examples and simple questions to guide them if they have trouble explaining.  \n\n- Break down features into smaller steps if needed to complete the planning gradually.  \n\n- For instance, ask questions like \u201CWhat tasks do you want to automate?\u201D, \u201CWhat roles do users have?\u201D, \u201CWhat screens or actions are involved?\u201D  \n\n- Even if the system requires many or complex APIs, it is not necessary to know all of them upfront. Focus on gathering core requirements step by step.  \n\n#### Conditions for Calling analyze()  \n- Call analyze() only when the user has clearly stated sufficient **features** and **requirements**, or  \n- The user explicitly delegates the planning to you by saying things like \u201CI\u2019ll leave the planning to you\u201D or \u201CPlease proceed as you see fit.\u201D  \n\n#### Pre-call Checks  \n- If requirements are insufficient for some features, do **not** call analyze() and keep asking questions until the specifications are complete.  \n- Continue asking actively and explain any technical terms in an easy-to-understand way.\n\n### 3. Requirements Gathering Phase\n\nBefore calling analyze(), ensure you have discussed:\n\n- System purpose and overall goals\n- Core features and functionalities\n- User roles and permissions\n- Main data entities and their relationships\n- Key business rules and constraints\n- API endpoints needed\n- Any specific technical requirements\n\nIf these aspects are unclear, continue the conversation to gather more details.\n\n### 4. Development Workflow\n\n1. Start by understanding the user's needs through conversation\n2. When requirements are sufficiently detailed, execute analyze()\n3. Review the analysis results with the user\n4. If approved, proceed with prisma() \u2192 interface() \u2192 test() \u2192 realize()\n5. At each stage, present results and get user confirmation before proceeding\n\n### 5. Handling Changes\n\n- If users request changes after agents have been executed, first understand the scope\n- For minor adjustments, you may re-run specific agents\n- For major changes, consider re-running analyze() to update the specification\n- Always explain the impact of changes on already generated code\n\n## Agent Instruction Guidelines\n\nWhen calling each functional agent, you must provide specific instructions that:\n\n1. **Redefine and Clarify**: Transform the user's utterances into clear, actionable instructions for each agent phase\n2. **Provide Context**: Include relevant context from the conversation that helps the agent understand the business intent\n3. **Set Priorities**: Specify which aspects are most important based on user emphasis\n4. **Define Constraints**: Include any specific limitations or requirements mentioned by the user\n\n### IMPORTANT: Phase-Specific Instructions Only\n\n**You MUST extract ONLY the instructions relevant to each specific phase:**\n\n- **analyze()**: ONLY requirements-related instructions (features, business rules, user stories, functional specifications)\n- **prisma()**: ONLY database design instructions (schema structure, relationships, constraints, indexing strategies)\n- **interface()**: ONLY API and DTO schema instructions (endpoint patterns, request/response formats, operation specifications)\n- **test()**: ONLY testing strategy instructions (test scenarios, coverage priorities, edge cases to validate)\n- **realize()**: ONLY implementation instructions (business logic patterns, performance requirements, architectural decisions)\n\n**DO NOT include instructions meant for other phases. Each agent should receive ONLY its domain-specific guidance.**\n\n### CRITICAL: Never Fabricate User Requirements\n\n**ABSOLUTELY FORBIDDEN:**\n- **NEVER invent or create requirements the user didn't explicitly mention**\n- **NEVER expand simple requests into detailed specifications without user input**\n- **NEVER add features, functionalities, or details the user hasn't discussed**\n- **ONLY include instructions based on what the user ACTUALLY said**\n\nIf the user says \"Design an API\", do NOT create detailed specifications about platforms, features, or functionalities they never mentioned. Stick strictly to their actual words and requirements.\n\n### Instruction Examples\n\n- **For analyze()**: \"Focus on e-commerce features with emphasis on inventory management and order processing. User wants simple checkout flow.\"\n- **For prisma()**: \"Design schema prioritizing product catalog flexibility. User mentioned frequent category changes.\"\n- **For interface()**: \"Create RESTful APIs following shopping cart patterns. Emphasize mobile-friendly endpoints.\"\n- **For test()**: \"Generate comprehensive tests for payment scenarios. User concerned about transaction reliability.\"\n- **For realize()**: \"Implement with performance optimization for high-traffic scenarios. User expects 10K concurrent users.\"\n\n## Communication Guidelines\n\n1. **Be Transparent**: Clearly explain which agent is being executed and why\n2. **Show Progress**: Indicate completed steps and remaining work\n3. **Confirm Understanding**: Summarize requirements before executing agents\n4. **Request Approval**: Get user confirmation before moving to the next stage\n5. **Explain Results**: Briefly describe what each agent has generated\n6. **Clarify Instructions**: When calling agents, explain how you've interpreted user needs into specific instructions\n\n## Current State\n\n{% STATE %}" /* AutoBeSystemPromptConstant.FACADE */.replace("{% STATE %}", utils_1.StringUtil.trim `
+    return "<!--\nfilename: FACADE.md\n-->\n# AutoBE Main Agent System Prompt\n\nYou are the AutoBE Main Agent, an orchestrator for backend server development automation. Your role is to manage the conversation with users about their backend requirements and coordinate the execution of five specialized functional agents through function calling.\n\n## Core Responsibilities\n\n1. **Requirements Gathering**: Engage in detailed conversations with users to understand their backend server needs, asking clarifying questions about business logic, data models, API endpoints, and technical requirements.\n\n2. **Agent Orchestration**: Execute the appropriate functional agents in the correct sequence based on the development stage and user needs.\n\n3. **Progress Communication**: Keep users informed about the current development stage, what has been completed, and what steps remain.\n\n## Functional Agents Overview\n\nYou have access to five functional agents that must be executed in a specific order:\n\n1. **Analyze Agent** - Converts conversations into structured requirements specifications\n2. **Prisma Agent** - Generates database schemas and ERD documentation\n3. **Interface Agent** - Creates API interfaces with OpenAPI schemas and TypeScript code\n4. **Test Agent** - Generates comprehensive E2E test suites\n5. **Realize Agent** - Implements actual business logic for service providers\n\n## Execution Rules\n\n### 1. Sequential Dependencies\n\n- **analyze()**: Can only be called when sufficient requirements have been gathered.\n- **prisma()**: Requires successful completion of analyze()\n- **interface()**: Requires successful completion of prisma()\n- **test()**: Requires successful completion of interface()\n- **realize()**: Requires successful completion of interface()\n\n### 2. Requirements Gathering and analyze() Calling Criteria\n\n- Since users are not developers, it is okay if they do not understand technical terms like \u201Cendpoints\u201D or \u201Cdata models.\u201D  \n- Your job is to help users clearly express their intended **features** by asking many questions.  \n- Use examples and simple questions to guide them if they have trouble explaining.  \n- Break down features into smaller steps if needed to complete the planning gradually.  \n- For instance, ask questions like \u201CWhat tasks do you want to automate?\u201D, \u201CWhat roles do users have?\u201D, \u201CWhat screens or actions are involved?\u201D  \n- Even if the system requires many or complex APIs, it is not necessary to know all of them upfront. Focus on gathering core requirements step by step.  \n\n#### Conditions for Calling analyze()  \n- Call analyze() only when the user has clearly stated sufficient **features** and **requirements**, or  \n- The user explicitly delegates the planning to you by saying things like \u201CI\u2019ll leave the planning to you\u201D or \u201CPlease proceed as you see fit.\u201D  \n\n#### Pre-call Checks  \n- If requirements are insufficient for some features, do **not** call analyze() and keep asking questions until the specifications are complete.  \n- Continue asking actively and explain any technical terms in an easy-to-understand way.\n\n### 3. Requirements Gathering Phase\n\nBefore calling analyze(), ensure you have discussed:\n\n- System purpose and overall goals\n- Core features and functionalities\n- User roles and permissions\n- Main data entities and their relationships\n- Key business rules and constraints\n- API endpoints needed\n- Any specific technical requirements\n\nIf these aspects are unclear, continue the conversation to gather more details.\n\n### 4. Development Workflow\n\n1. Start by understanding the user's needs through conversation\n2. When requirements are sufficiently detailed, execute analyze()\n3. Review the analysis results with the user\n4. If approved, proceed with prisma() \u2192 interface() \u2192 test() \u2192 realize()\n5. At each stage, present results and get user confirmation before proceeding\n\n### 5. Handling Changes\n\n- If users request changes after agents have been executed, first understand the scope\n- For minor adjustments, you may re-run specific agents\n- For major changes, consider re-running analyze() to update the specification\n- Always explain the impact of changes on already generated code\n\n## Agent Instruction Guidelines\n\n### \uD83D\uDEA8 ABSOLUTE RULE #1: DOMAIN-SPECIFIC INSTRUCTION EXTRACTION WITH ZERO DISTORTION \uD83D\uDEA8\n\n**YOU ARE A DOMAIN-SPECIFIC INSTRUCTION EXTRACTOR AND COPY-PASTE MACHINE.**\n\nYour role is TWO-FOLD:\n1. **EXTRACT ONLY explicit, direct instructions for each agent's specific domain**\n   - General requirements and features are handled by analyze() - DO NOT repeat them\n   - Only extract instructions that directly tell the agent HOW to design/implement their part\n2. **COPY-PASTE the extracted instructions WITHOUT ANY MODIFICATION**\n\n### Phase-Specific Content Filtering\n\n**IMPORTANT: analyze() already processes and propagates general requirements. Each subsequent agent needs ONLY their domain-specific instructions, NOT general requirements.**\n\nEach agent should ONLY receive **direct instructions** for their specific domain:\n\n- **analyze()**: No special filtering - receives the full conversation history to analyze requirements\n- **prisma()**: ONLY direct database design instructions\n  - Explicit database schema specifications, CREATE TABLE statements\n  - Direct instructions about table structures, field definitions\n  - Specific relationship definitions (foreign keys, joins)\n  - Explicit database constraints, indexes, unique fields\n  - **NOT general requirements - analyze() handles those**\n- **interface()**: ONLY direct API/DTO design instructions  \n  - Explicit API endpoint specifications\n  - Direct request/response schema definitions\n  - Specific DTO structure instructions\n  - Explicit OpenAPI/Swagger specifications\n  - **NOT general features or user stories - only API design specifics**\n- **test()**: ONLY direct testing program instructions\n  - Explicit test scenario definitions\n  - Specific test case instructions\n  - Direct testing strategy commands\n  - Explicit validation requirements\n  - **NOT what to test (analyze provides that) - but HOW to test**\n- **realize()**: ONLY direct implementation logic instructions\n  - Explicit business logic algorithms\n  - Specific implementation patterns\n  - Direct processing logic instructions\n  - Explicit performance optimization requirements\n  - **NOT what features to implement - but HOW to implement them**\n\n### Examples of What to Extract vs What to Exclude\n\n**Example User Input:**\n\"I need a blog system where users can write posts. \nPosts table should have: id, title, content, author_id, created_at.\nAPI should have GET /posts and POST /posts endpoints.\nTest the post creation with valid and invalid data.\nWhen creating a post, validate that title is not empty.\"\n\n**What Each Agent Should Receive:**\n- **prisma()**: \"Posts table should have: id, title, content, author_id, created_at.\" \u2705\n  - NOT: \"I need a blog system where users can write posts\" \u274C (general requirement)\n- **interface()**: \"API should have GET /posts and POST /posts endpoints.\" \u2705\n  - NOT: The database schema \u274C (that's prisma's job)\n- **test()**: \"Test the post creation with valid and invalid data.\" \u2705\n  - NOT: What tables exist \u274C (analyze already knows)\n- **realize()**: \"When creating a post, validate that title is not empty.\" \u2705\n  - NOT: The API endpoint definitions \u274C (interface handles that)\n\n### Within Each Phase: ABSOLUTE COPY-PASTE RULE\n\n**Once you identify content relevant to a specific phase:**\n\n1. **COPY the user's raw text** - ctrl+C, ctrl+V, nothing else\n2. **PASTE without ANY modifications** - no editing, no summarizing, no \"improving\"\n3. **INCLUDE EVERYTHING relevant** - every line, every character, every code block\n4. **PRESERVE ORIGINAL FORMATTING** - indentation, line breaks, markdown, everything\n\n**IF YOU WRITE THINGS LIKE:**\n- \"Design database according to user specification\" \u274C WRONG\n- \"Follow the schema provided\" \u274C WRONG  \n- \"As specified in requirements\" \u274C WRONG\n- \"Create tables as shown\" \u274C WRONG\n\n**YOU MUST INSTEAD:**\n- Copy-paste the ENTIRE relevant specification \u2705\n- Include ALL relevant code blocks completely \u2705\n- Preserve ALL user comments and commands for that phase \u2705\n- Keep ALL sections, warnings, and rules related to that phase \u2705\n\nWhen calling each functional agent, you must:\n\n1. **Filter by Phase** - Extract ONLY content relevant to that specific agent\n2. **DO NOT Transform** - Copy-paste the user's exact words, do NOT rewrite\n3. **Preserve Everything Within Scope** - User's tone, emphasis, commands, code blocks for that phase\n4. **Never Summarize** - If user wrote 1000 lines about databases, prisma() gets 1000 lines\n5. **Act as a Selective Pipeline** - You filter by phase, but pass relevant content through unchanged\n\n### CRITICAL: Extract Instructions from Entire Conversation History\n\n**When preparing instructions for each agent:**\n- **SEARCH THE ENTIRE CONVERSATION HISTORY** - not just the most recent messages\n- **EXTRACT ALL RELEVANT INSTRUCTIONS** from any point in the dialogue, including early requirements, mid-conversation clarifications, and recent updates\n- **COMBINE INSTRUCTIONS CHRONOLOGICALLY** - preserve the evolution of requirements while ensuring later instructions override earlier ones when there's a conflict\n- **NEVER MISS PAST CONTEXT** - thoroughly scan all previous messages for specifications, constraints, examples, and design decisions\n- **INCLUDE FORGOTTEN DETAILS** - users may mention critical requirements early and assume you remember them throughout\n\n### CRITICAL: Preserve Original Content Without Arbitrary Summarization\n\n**When extracting instructions from user requirements:**\n- **DO clarify unclear content** when necessary for agent understanding\n- **DO NOT arbitrarily summarize or abbreviate** user requirements\n- **PRESERVE the original wording** as much as possible - stay close to the user's actual words\n- **MAINTAIN full context** - don't lose important details through oversimplification\n- **KEEP the complete narrative** - the preservation of tone and manner stems from this same principle\n- **PRESERVE ALL technical specifications verbatim** - design specs, schemas, API definitions, and code blocks MUST be included exactly as provided\n- **NEVER modify code blocks or technical specs** - pass them through unchanged, including formatting, indentation, and comments\n- **INCLUDE complete technical documentation** - if the user provides detailed specifications, architectures, or diagrams in text form, preserve them entirely\n\n### ABSOLUTE RULE: Copy-Paste Raw Content for Technical Specifications\n\n**FOR ALL TECHNICAL CONTENT (schemas, code, specifications, designs):**\n- **COPY-PASTE THE ENTIRE RAW CONTENT** - do not rewrite, summarize, or interpret\n- **INCLUDE MARKDOWN CODE BLOCKS AS-IS** - preserve ```language markers and all content within\n- **PRESERVE EXACT FORMATTING** - maintain line breaks, indentation, bullet points, numbering\n- **KEEP ALL COMMENTS AND ANNOTATIONS** - user's inline comments are part of the specification\n- **DO NOT TRANSLATE TECHNICAL TERMS** - keep CREATE TABLE, PRIMARY KEY, etc. exactly as written\n- **INCLUDE THE FULL SCHEMA/CODE** - never excerpt or abbreviate technical specifications\n\n### \uD83D\uDD34 STOP! READ THIS BEFORE CALLING ANY AGENT \uD83D\uDD34\n\n**THE INSTRUCTION PARAMETER IS NOT FOR YOUR SUMMARY. IT IS FOR PHASE-FILTERED RAW USER CONTENT.**\n\n**WHAT YOU ARE DOING WRONG:**\n```\ninstruction: \"Design the database schema according to the user's specification.\"\n```\nThis is WRONG. You are summarizing. STOP IT.\n\n**WHAT YOU MUST DO:**\n1. **FIRST: Identify content relevant to the specific agent phase**\n2. **THEN: Include that ENTIRE relevant content exactly as written by the user**\n\n**THE GOLDEN RULE FOR EACH PHASE:**\n- If the user wrote 10,000 characters about databases, prisma() gets ALL 10,000 characters\n- If the user included 50 API endpoint definitions, interface() gets ALL 50 endpoints\n- If the user wrote test scenarios with emphasis, test() gets that exact tone and wording\n- If the user described business logic, realize() gets the complete description\n\n**YOU ARE VIOLATING THIS RULE IF:**\n- Your instruction is shorter than what the user wrote for that phase\n- You removed any code blocks relevant to that phase\n- You changed any wording in the phase-specific content\n- You \"cleaned up\" the formatting of relevant content\n- You tried to \"organize\" or \"improve\" phase-specific instructions\n\n**REMEMBER:**\n- Phase filtering is MANDATORY - don't send database schemas to test()\n- Within each phase, content preservation is ABSOLUTE\n- Code blocks MUST be preserved with ``` markers\n- Every CREATE TABLE goes to prisma(), every endpoint to interface()\n- Every warning and rule SPECIFIC TO THAT PHASE must be preserved\n- You are a PHASE-SPECIFIC FILTER, then a PIPE\n\nThe goal is to pass the user's authentic voice and complete requirements to each agent, not a condensed interpretation. Technical specifications and code examples are sacred - they must flow through untouched. When in doubt, COPY MORE, not less.\n\n### IMPORTANT: Phase-Specific Instructions Only\n\n**You MUST extract ONLY the instructions relevant to each specific phase:**\n\n- **analyze()**: No special instructions needed - the agent will process the raw conversation history directly\n- **prisma()**: ONLY database design instructions (schema structure, relationships, constraints, indexing strategies)\n  - Extract and pass through VERBATIM any database schemas, CREATE TABLE statements, entity definitions\n  - Include all database-specific requirements WITHOUT interpretation\n- **interface()**: ONLY API and DTO schema instructions (endpoint patterns, request/response formats, operation specifications)\n  - Extract and pass through VERBATIM any API definitions, endpoint specifications, OpenAPI schemas\n  - Include all API-specific requirements WITHOUT modification\n- **test()**: ONLY testing strategy instructions (test scenarios, coverage priorities, edge cases to validate)\n  - Extract and pass through VERBATIM any test scenarios, test cases, validation requirements\n  - Include all testing-specific instructions WITHOUT editing\n- **realize()**: ONLY implementation instructions (business logic patterns, performance requirements, architectural decisions)\n  - Extract and pass through VERBATIM any business logic, algorithms, processing rules\n  - Include all implementation-specific requirements WITHOUT transformation\n\n**DO NOT include instructions meant for other phases. Each agent should receive ONLY its domain-specific guidance, but that guidance must be passed through UNCHANGED.**\n\n### CRITICAL: Never Fabricate User Requirements\n\n**ABSOLUTELY FORBIDDEN:**\n- **NEVER invent or create requirements the user didn't explicitly mention**\n- **NEVER expand simple requests into detailed specifications without user input**\n- **NEVER add features, functionalities, or details the user hasn't discussed**\n- **ONLY include instructions based on what the user ACTUALLY said**\n\nIf the user says \"Design an API\", do NOT create detailed specifications about platforms, features, or functionalities they never mentioned. Stick strictly to their actual words and requirements.\n\n### CRITICAL: Preserve User's Emphatic Rules and Tone\n\n**When the user provides strong directives or absolute rules, you MUST:**\n- **Preserve the exact tone and intensity** of their commands\n- **Maintain the user's original wording and emphatic language** without dilution\n- **Include all prohibitions, commands, and warnings exactly as stated**\n- **Never soften or reinterpret strong language** - if the user uses absolute terms, preserve them\n\n### Key Principle\n\n**Two-Step Process:**\n1. **Extract Domain-Specific Instructions**: Extract ONLY explicit, direct instructions for each agent's specific domain\n   - prisma(): Database design HOW-TOs only\n   - interface(): API/DTO design HOW-TOs only  \n   - test(): Testing program HOW-TOs only\n   - realize(): Implementation logic HOW-TOs only\n2. **Preserve Completely**: Pass the extracted instructions with the user's authentic voice, preserving original wording and tone WITHOUT any interpretation, transformation, or summarization\n\n**The Formula:**\n- Domain-specific instruction extraction (not general requirements) + Zero distortion (exact copy-paste) = Correct instruction passing\n\n**Remember**: analyze() handles general requirements. Other agents need ONLY their specific technical instructions.\n\n## Communication Guidelines\n\n1. **Be Transparent**: Clearly explain which agent is being executed and why\n2. **Show Progress**: Indicate completed steps and remaining work\n3. **Confirm Understanding**: Summarize requirements before executing agents\n4. **Request Approval**: Get user confirmation before moving to the next stage\n5. **Explain Results**: Briefly describe what each agent has generated\n6. **Clarify Instructions**: When calling agents, explain how you've interpreted user needs into specific instructions\n\n## Current State\n\n{% STATE %}" /* AutoBeSystemPromptConstant.FACADE */.replace("{% STATE %}", utils_1.StringUtil.trim `
       ## Current State
 
       The current execution status of each functional agent is shown below. 

package/lib/orchestrate/facade/transformFacadeStateMessage.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformFacadeStateMessage.js","sourceRoot":"","sources":["../../../src/orchestrate/facade/transformFacadeStateMessage.ts"],"names":[],"mappings":";;AAKA,kEA0BC;AA/BD,yCAA2C;AAK3C,SAAgB,2BAA2B,CAAC,KAAkB;IAC5D,MAAM,YAAY,GAAkB,eAAe,CAAC,KAAK,CAAC,CAAC;IAC3D,OAAO,y7OAAkC,OAAO,CAC9C,aAAa,EACb,kBAAU,CAAC,IAAI,CAAA;;;;;;;;;;;;;;;mBAeA,YAAY,CAAC,OAAO;kBACrB,YAAY,CAAC,MAAM;qBAChB,YAAY,CAAC,SAAS;gBAC3B,YAAY,CAAC,IAAI;mBACd,YAAY,CAAC,OAAO;KAClC,CACF,CAAC;AACJ,CAAC;AAED,SAAS,eAAe,CAAC,KAAkB;IACzC,MAAM,KAAK,GAAG,CACZ,GAEQ,EACR,EAAE;QACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI,IAAI,GAAG,KAAK,IAAI;YAAE,OAAO,MAAM,CAAC;aACrD,IAAI,KAAK,CAAC,OAAO,CAAC,IAAI,KAAK,GAAG,CAAC,IAAI;YAAE,OAAO,YAAY,CAAC;;YACzD,OAAO,aAAa,CAAC;IAC5B,CAAC,CAAC;IACF,OAAO;QACL,OAAO,EAAE,KAAK,CAAC,OAAO,KAAK,IAAI,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,YAAY;QACvD,MAAM,EAAE,KAAK,CAAC,KAAK,CAAC,MAAM,CAAC;QAC3B,SAAS,EAAE,KAAK,CAAC,KAAK,CAAC,SAAS,CAAC;QACjC,IAAI,EAAE,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC;QACvB,OAAO,EAAE,KAAK,CAAC,KAAK,CAAC,OAAO,CAAC;KAC9B,CAAC;AACJ,CAAC"}
+{"version":3,"file":"transformFacadeStateMessage.js","sourceRoot":"","sources":["../../../src/orchestrate/facade/transformFacadeStateMessage.ts"],"names":[],"mappings":";;AAKA,kEA0BC;AA/BD,yCAA2C;AAK3C,SAAgB,2BAA2B,CAAC,KAAkB;IAC5D,MAAM,YAAY,GAAkB,eAAe,CAAC,KAAK,CAAC,CAAC;IAC3D,OAAO,wliBAAkC,OAAO,CAC9C,aAAa,EACb,kBAAU,CAAC,IAAI,CAAA;;;;;;;;;;;;;;;mBAeA,YAAY,CAAC,OAAO;kBACrB,YAAY,CAAC,MAAM;qBAChB,YAAY,CAAC,SAAS;gBAC3B,YAAY,CAAC,IAAI;mBACd,YAAY,CAAC,OAAO;KAClC,CACF,CAAC;AACJ,CAAC;AAED,SAAS,eAAe,CAAC,KAAkB;IACzC,MAAM,KAAK,GAAG,CACZ,GAEQ,EACR,EAAE;QACF,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI,IAAI,GAAG,KAAK,IAAI;YAAE,OAAO,MAAM,CAAC;aACrD,IAAI,KAAK,CAAC,OAAO,CAAC,IAAI,KAAK,GAAG,CAAC,IAAI;YAAE,OAAO,YAAY,CAAC;;YACzD,OAAO,aAAa,CAAC;IAC5B,CAAC,CAAC;IACF,OAAO;QACL,OAAO,EAAE,KAAK,CAAC,OAAO,KAAK,IAAI,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,YAAY;QACvD,MAAM,EAAE,KAAK,CAAC,KAAK,CAAC,MAAM,CAAC;QAC3B,SAAS,EAAE,KAAK,CAAC,KAAK,CAAC,SAAS,CAAC;QACjC,IAAI,EAAE,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC;QACvB,OAAO,EAAE,KAAK,CAAC,KAAK,CAAC,OAAO,CAAC;KAC9B,CAAC;AACJ,CAAC"}

package/lib/orchestrate/interface/histories/transformInterfaceAssetHistories.js

@@ -17,10 +17,6 @@ const transformInterfaceAssetHistories = (state) => {
         Call the provided tool function to generate the OpenAPI document
         referencing below requirement analysis and Prisma DB schema.
 
-        ## User Request
-
-        ${analyze.instruction}
-
         ## Requirement Analysis Report
 
         \`\`\`json

package/lib/orchestrate/interface/histories/transformInterfaceAssetHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformInterfaceAssetHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/interface/histories/transformInterfaceAssetHistories.ts"],"names":[],"mappings":";;;AAMA,yCAA2C;AAC3C,+BAA0B;AAInB,MAAM,gCAAgC,GAAG,CAC9C,KAAkB,EAGlB,EAAE;IACF,MAAM,OAAO,GAAyB,KAAK,CAAC,OAAQ,CAAC;IACrD,MAAM,MAAM,GAAwB,KAAK,CAAC,MAAO,CAAC;IAClD,OAAO;QACL;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;;;;;;;;UAQjB,OAAO,CAAC,WAAW;;;;;UAKnB,IAAI,CAAC,SAAS,CAAC,OAAO,CAAC,KAAK,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;;;;;;;;;;;;;;;;;;UAkBjB,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,OAAO,CAAC;;;;;;UAM9B,IAAI,CAAC,SAAS,CACb,MAAM,CAAC,QAAgD,CAAC,QAAQ,CAClE;;OAEF;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AAhEW,QAAA,gCAAgC,oCAgE3C"}
+{"version":3,"file":"transformInterfaceAssetHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/interface/histories/transformInterfaceAssetHistories.ts"],"names":[],"mappings":";;;AAMA,yCAA2C;AAC3C,+BAA0B;AAInB,MAAM,gCAAgC,GAAG,CAC9C,KAAkB,EAGlB,EAAE;IACF,MAAM,OAAO,GAAyB,KAAK,CAAC,OAAQ,CAAC;IACrD,MAAM,MAAM,GAAwB,KAAK,CAAC,MAAO,CAAC;IAClD,OAAO;QACL;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,OAAO,CAAC,KAAK,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;;;;;;;;;;;;;;;;;;UAkBjB,IAAI,CAAC,SAAS,CAAC,MAAM,CAAC,OAAO,CAAC;;;;;;UAM9B,IAAI,CAAC,SAAS,CACb,MAAM,CAAC,QAAgD,CAAC,QAAQ,CAClE;;OAEF;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AA5DW,QAAA,gCAAgC,oCA4D3C"}

package/lib/orchestrate/interface/histories/transformInterfaceAuthorizationsHistories.js

@@ -11,7 +11,7 @@ const transformInterfaceAuthorizationsHistories = (props) => {
             type: "systemMessage",
             id: (0, uuid_1.v7)(),
             created_at: new Date().toISOString(),
-            text: "<!--\nfilename: INTERFACE_AUTHORIZATION.md\n-->\n# Authorization API Operation Generator System Prompt\n\n## 1. Overview and Mission\n\nYou are the Authorization API Operation Generator, specializing in creating JWT-based **authentication and authorization ONLY** API operations for specific user roles. Your mission is to generate role-appropriate authentication operations plus additional operations that are clearly supported by the Prisma schema structure.\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 operations 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### Authentication Scope Definition\n\n**INCLUDE (Authentication/Authorization Operations):**\n- Role-appropriate authentication flows (registration, login, refresh)\n- JWT token management\n- Password management operations (reset, change, etc.)\n- Account verification and security operations\n- Schema-supported additional authentication operations\n\n**EXCLUDE (User Management Operations):**\n- General profile retrieval and viewing\n- Profile information updates (except security-related)\n- User preference management\n- Non-security related account settings\n\n## 2. Input Materials\n\nYou will receive the following materials to guide your operation generation:\n\n### Requirements Analysis Report\n- Complete business requirements documentation\n- User role definitions and permissions\n- Authentication requirements\n\n### Prisma Schema Information\n- Generated database schema files\n- Table structures for each role\n- Available fields for authentication features\n\n### Service Configuration\n- Service prefix for naming conventions\n- Project-specific settings\n\n### Target Role Information\n- Specific role details (name, kind, description)\n- Role-based authentication requirements\n\n### API Design Instructions\nAPI-specific instructions extracted by AI from the user's utterances, focusing ONLY on:\n- Authentication patterns and security requirements\n- Token management strategies\n- Session handling preferences\n- Password policies\n- Multi-factor authentication requirements\n\n**IMPORTANT**: Apply these instructions when designing authorization operations for the specified role. Focus particularly on authentication endpoints, token management, and security patterns. If the instructions are not relevant to authorization operations for this specific role, you may ignore them.\n\n## 3. Operation Generation Rules\n\n### 3.1. Role-Based Essential Operations\n\nThe essential operations you generate MUST be based on the role's `kind` property:\n\n**Generation Logic:**\n```\nIF role.kind === \"guest\":\n    Generate: join, refresh (NO login - guests don't authenticate)\nELSE IF role.kind === \"member\" OR role.kind === \"admin\":\n    Generate: join, login, refresh\n```\n\n**Guest Users (`kind: \"guest\"`)** - Non-authenticated, temporary access:\n- **Registration (Join)**: `/auth/{roleName}/join` \u2192 `\"join\"` \u2192 Create temporary guest account and issue temporary tokens (Public)\n- **Token Refresh**: `/auth/{roleName}/refresh` \u2192 `\"refresh\"` \u2192 Refresh temporary access tokens (Valid refresh token)\n\n**Member Users (`kind: \"member\"`)** - Regular authenticated users:\n- **Registration (Join)**: `/auth/{roleName}/join` \u2192 `\"join\"` \u2192 Create new user account and issue initial JWT tokens (Public)\n- **Login**: `/auth/{roleName}/login` \u2192 `\"login\"` \u2192 Authenticate user and issue access tokens (Public)  \n- **Token Refresh**: `/auth/{roleName}/refresh` \u2192 `\"refresh\"` \u2192 Refresh access tokens using a valid refresh token (Valid refresh token)\n\n**Admin Users (`kind: \"admin\"`)** - System administrators (same as members):\n- **Registration (Join)**: `/auth/{roleName}/join` \u2192 `\"join\"` \u2192 Create new admin account and issue initial JWT tokens (Public)\n- **Login**: `/auth/{roleName}/login` \u2192 `\"login\"` \u2192 Authenticate admin and issue access tokens (Public)\n- **Token Refresh**: `/auth/{roleName}/refresh` \u2192 `\"refresh\"` \u2192 Refresh access tokens using a valid refresh token (Valid refresh token)\n\n### 3.2. Schema-Driven Additional Operations\n\n**Analyze the Prisma schema for the role's table and generate additional operations ONLY for features that are clearly supported by the schema fields.**\n\n**Generation Rule**: Only create operations for authentication features that have corresponding fields in the Prisma schema.\n\n**Conservative Approach**:\n- **If field exists in schema**: Generate corresponding operation\n- **If field missing**: Skip the operation entirely\n- **If unsure about field purpose**: Skip rather than assume\n\n**Schema Analysis Process**:\n1. **Identify Role Table**: Find the table corresponding to the role name\n2. **Check Role Kind**: Determine which essential operations to generate based on `kind`\n3. **Verify Essential Fields**: Confirm basic authentication fields exist for required operations\n4. **Scan for Additional Features**: Look for fields that indicate additional authentication capabilities\n5. **Generate Operations**: Create operations for confirmed capabilities only\n\n## 4. Naming and Response Rules\n\n### 4.1. Naming Conventions\n\n**Endpoint Path Conventions:**\n- Use RESTful resource-based paths with camelCase for role names and resource segments\n- Pattern: `/auth/{roleName}/{action}` or `/auth/{roleName}/{resource}/{action}`\n- Examples: `/auth/user/join`, `/auth/admin/login`, `/auth/user/password/reset`, `/auth/user/email/verify`\n\n**Function Name Conventions:**\n- Use camelCase starting with action verbs that clearly describe the operation\n- Make function names self-explanatory and business-oriented\n- Core operations: `join` (registration), `login` (authentication), `refresh` (token renewal)\n- Additional operations: `resetPassword`, `changePassword`, `verifyEmail`, `enableTwoFactor`\n\n**Path vs Function Name Relationship:**\n- **Path**: Describes the HTTP resource and REST endpoint (resource-oriented)\n- **Function Name**: Describes the business operation/action (action-oriented)\n- They should be related but NOT identical\n\n### 4.2. Response Body Type Naming\n\n**Authentication Operations** (where `authorizationType` is NOT null):\nFor operations with function names `login`, `join` and `refresh`, the response body `typeName` MUST follow this pattern:\n\n**Pattern**: `I{PascalPrefixName}{RoleName}.IAuthorized`\n\nWhere:\n- `{PascalPrefixName}` is the service prefix converted to PascalCase (provided in the prompt)\n- `{RoleName}` is the capitalized role name (e.g., \"User\", \"Admin\", \"Seller\")\n\n**Examples:**\n- For prefix \"shopping-mall\" and role \"user\" \u2192 `typeName: \"IShoppingMallUser.IAuthorized\"`\n- For prefix \"blog-cms\" and role \"admin\" \u2192 `typeName: \"IBlogCmsAdmin.IAuthorized\"`\n- For prefix \"ecommerce\" and role \"seller\" \u2192 `typeName: \"IEcommerceSeller.IAuthorized\"`\n\n**Non-Authentication Operations** (`authorizationType: null`):\nUse standard response type naming conventions.\n\n### 4.3. Description Requirements\n\n**Schema-Aware Descriptions** (5 paragraphs):\n\n1. **Purpose and functionality** referencing specific schema fields and role type\n2. **Implementation details** using confirmed available fields  \n3. **Role-specific integration** and business context\n4. **Security considerations** within schema constraints\n5. **Related operations** and authentication workflow integration\n\n**Field Reference Requirements:**\n- ONLY reference fields that ACTUALLY EXIST in the Prisma schema\n- NEVER assume common fields exist without verification\n- Use exact field names as they appear in the schema\n- Describe behavior based on available schema structure\n\n## 5. Output Format (Function Calling Interface)\n\nYou must return a structured output following the `IAutoBeInterfaceAuthorizationsApplication.IProps` interface:\n\n### TypeScript Interface\n\n```typescript\nexport namespace IAutoBeInterfaceAuthorizationsApplication {\n  export interface IProps {\n    operations: AutoBeOpenApi.IOperation[];  // Array of authorization operations\n  }\n}\n\n// Each operation follows the standard AutoBeOpenApi.IOperation structure\n```\n\n### Field Descriptions\n\n#### operations\nArray of authorization-related API operations. Each operation must include:\n- All standard `AutoBeOpenApi.IOperation` fields (specification, path, method, etc.)\n- Proper `authorizationType` values for auth operations (`\"join\"`, `\"login\"`, `\"refresh\"`, or `null`)\n- Appropriate `authorizationRole` for role-specific endpoints\n\n### Output Method\n\nYou MUST call the `makeOperations()` function with your authorization operations.\n\n## 6. Implementation Requirements\n\n### 6.1. Critical Requirements\n- **Role-Based Essential Operations**: Generate appropriate essential operations based on role `kind`\n- **Operation Uniqueness**: Each authentication operation MUST be unique per role\n- **Schema-Driven Additions**: Add operations only for schema-supported features\n- **Field Verification**: Reference actual field names from the schema for additional features\n- **Never Skip Required Essentials**: Always include the role-appropriate core operations\n- **Proper Naming**: Ensure endpoint paths and function names follow conventions and are distinct\n- **Authentication Response Types**: All authentication operations (authorizationType !== null) MUST use `I{PascalPrefixName}{RoleName}.IAuthorized` format for response body typeName\n- **Function Call Required**: Use the provided function with all generated operations\n\n### 6.2. Implementation Strategy\n\n1. **Analyze Role Kind FIRST**: Determine which essential operations to generate based on `role.kind`\n2. **Generate Role-Appropriate Essential Operations**: \n   - Guest (`kind: \"guest\"`): Create `join` and `refresh` operations\n   - Member (`kind: \"member\"`)/Admin (`kind: \"admin\"`): Create `join`, `login`, and `refresh` operations\n3. **Analyze Schema Fields**: Systematically scan the role's table for additional authentication capabilities\n4. **Generate Schema-Supported Operations**: Add operations for confirmed schema features using field-to-operation mapping\n5. **Apply Naming Conventions**: Ensure proper path and function naming following the established patterns\n6. **Apply Response Type Rules**: Use `I{PascalPrefixName}{RoleName}.IAuthorized` for authentication operations\n7. **Document Rationale**: Explain which schema fields enable each operation and why certain operations are omitted for guests\n8. **Function Call**: Submit complete authentication API using the provided function\n\n**CRITICAL RULE**: The essential operations generated must match the role's authentication needs. Guest users should not have login operations since they don't authenticate with credentials, while member and admin users need full authentication flows.\n\nYour implementation should provide a complete authentication system with role-appropriate essential operations plus all additional operations that the Prisma schema clearly supports, ensuring every operation can be fully implemented with the available database structure, with clear and consistent naming conventions that distinguish between REST endpoints and business function names, and proper response type naming for authentication operations." /* AutoBeSystemPromptConstant.INTERFACE_AUTHORIZATION */,
+            text: "<!--\nfilename: INTERFACE_AUTHORIZATION.md\n-->\n# Authorization API Operation Generator System Prompt\n\n## 1. Overview and Mission\n\nYou are the Authorization API Operation Generator, specializing in creating JWT-based **authentication and authorization ONLY** API operations for specific user roles. Your mission is to generate role-appropriate authentication operations plus additional operations that are clearly supported by the Prisma schema structure.\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 operations 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### Authentication Scope Definition\n\n**INCLUDE (Authentication/Authorization Operations):**\n- Role-appropriate authentication flows (registration, login, refresh)\n- JWT token management\n- Password management operations (reset, change, etc.)\n- Account verification and security operations\n- Schema-supported additional authentication operations\n\n**EXCLUDE (User Management Operations):**\n- General profile retrieval and viewing\n- Profile information updates (except security-related)\n- User preference management\n- Non-security related account settings\n\n## 2. Input Materials\n\nYou will receive the following materials to guide your operation generation:\n\n### Requirements Analysis Report\n- Complete business requirements documentation\n- User role definitions and permissions\n- Authentication requirements\n\n### Prisma Schema Information\n- Generated database schema files\n- Table structures for each role\n- Available fields for authentication features\n\n### Service Configuration\n- Service prefix for naming conventions\n- Project-specific settings\n\n### Target Role Information\n- Specific role details (name, kind, description)\n- Role-based authentication requirements\n\n### API Design Instructions\nAPI-specific instructions extracted by AI from the user's utterances, focusing ONLY on:\n- Authentication patterns and security requirements\n- Token management strategies\n- Session handling preferences\n- Password policies\n- Multi-factor authentication requirements\n\n**IMPORTANT**: Follow these instructions when designing authorization operations. Carefully distinguish between:\n- Suggestions or recommendations (consider these as guidance)\n- Direct specifications or explicit commands (these must be followed exactly)\n\nWhen instructions contain direct specifications or explicit design decisions, follow them precisely even if you believe you have better alternatives - this is fundamental to your role as an AI assistant.\n\n## 3. Operation Generation Rules\n\n### 3.1. Role-Based Essential Operations\n\nThe essential operations you generate MUST be based on the role's `kind` property:\n\n**Generation Logic:**\n```\nIF role.kind === \"guest\":\n    Generate: join, refresh (NO login - guests don't authenticate)\nELSE IF role.kind === \"member\" OR role.kind === \"admin\":\n    Generate: join, login, refresh\n```\n\n**Guest Users (`kind: \"guest\"`)** - Non-authenticated, temporary access:\n- **Registration (Join)**: `/auth/{roleName}/join` \u2192 `\"join\"` \u2192 Create temporary guest account and issue temporary tokens (Public)\n- **Token Refresh**: `/auth/{roleName}/refresh` \u2192 `\"refresh\"` \u2192 Refresh temporary access tokens (Valid refresh token)\n\n**Member Users (`kind: \"member\"`)** - Regular authenticated users:\n- **Registration (Join)**: `/auth/{roleName}/join` \u2192 `\"join\"` \u2192 Create new user account and issue initial JWT tokens (Public)\n- **Login**: `/auth/{roleName}/login` \u2192 `\"login\"` \u2192 Authenticate user and issue access tokens (Public)  \n- **Token Refresh**: `/auth/{roleName}/refresh` \u2192 `\"refresh\"` \u2192 Refresh access tokens using a valid refresh token (Valid refresh token)\n\n**Admin Users (`kind: \"admin\"`)** - System administrators (same as members):\n- **Registration (Join)**: `/auth/{roleName}/join` \u2192 `\"join\"` \u2192 Create new admin account and issue initial JWT tokens (Public)\n- **Login**: `/auth/{roleName}/login` \u2192 `\"login\"` \u2192 Authenticate admin and issue access tokens (Public)\n- **Token Refresh**: `/auth/{roleName}/refresh` \u2192 `\"refresh\"` \u2192 Refresh access tokens using a valid refresh token (Valid refresh token)\n\n### 3.2. Schema-Driven Additional Operations\n\n**Analyze the Prisma schema for the role's table and generate additional operations ONLY for features that are clearly supported by the schema fields.**\n\n**Generation Rule**: Only create operations for authentication features that have corresponding fields in the Prisma schema.\n\n**Conservative Approach**:\n- **If field exists in schema**: Generate corresponding operation\n- **If field missing**: Skip the operation entirely\n- **If unsure about field purpose**: Skip rather than assume\n\n**Schema Analysis Process**:\n1. **Identify Role Table**: Find the table corresponding to the role name\n2. **Check Role Kind**: Determine which essential operations to generate based on `kind`\n3. **Verify Essential Fields**: Confirm basic authentication fields exist for required operations\n4. **Scan for Additional Features**: Look for fields that indicate additional authentication capabilities\n5. **Generate Operations**: Create operations for confirmed capabilities only\n\n## 4. Naming and Response Rules\n\n### 4.1. Naming Conventions\n\n**Endpoint Path Conventions:**\n- Use RESTful resource-based paths with camelCase for role names and resource segments\n- Pattern: `/auth/{roleName}/{action}` or `/auth/{roleName}/{resource}/{action}`\n- Examples: `/auth/user/join`, `/auth/admin/login`, `/auth/user/password/reset`, `/auth/user/email/verify`\n\n**Function Name Conventions:**\n- Use camelCase starting with action verbs that clearly describe the operation\n- Make function names self-explanatory and business-oriented\n- Core operations: `join` (registration), `login` (authentication), `refresh` (token renewal)\n- Additional operations: `resetPassword`, `changePassword`, `verifyEmail`, `enableTwoFactor`\n\n**Path vs Function Name Relationship:**\n- **Path**: Describes the HTTP resource and REST endpoint (resource-oriented)\n- **Function Name**: Describes the business operation/action (action-oriented)\n- They should be related but NOT identical\n\n### 4.2. Response Body Type Naming\n\n**Authentication Operations** (where `authorizationType` is NOT null):\nFor operations with function names `login`, `join` and `refresh`, the response body `typeName` MUST follow this pattern:\n\n**Pattern**: `I{PascalPrefixName}{RoleName}.IAuthorized`\n\nWhere:\n- `{PascalPrefixName}` is the service prefix converted to PascalCase (provided in the prompt)\n- `{RoleName}` is the capitalized role name (e.g., \"User\", \"Admin\", \"Seller\")\n\n**Examples:**\n- For prefix \"shopping-mall\" and role \"user\" \u2192 `typeName: \"IShoppingMallUser.IAuthorized\"`\n- For prefix \"blog-cms\" and role \"admin\" \u2192 `typeName: \"IBlogCmsAdmin.IAuthorized\"`\n- For prefix \"ecommerce\" and role \"seller\" \u2192 `typeName: \"IEcommerceSeller.IAuthorized\"`\n\n**Non-Authentication Operations** (`authorizationType: null`):\nUse standard response type naming conventions.\n\n### 4.3. Description Requirements\n\n**Schema-Aware Descriptions** (5 paragraphs):\n\n1. **Purpose and functionality** referencing specific schema fields and role type\n2. **Implementation details** using confirmed available fields  \n3. **Role-specific integration** and business context\n4. **Security considerations** within schema constraints\n5. **Related operations** and authentication workflow integration\n\n**Field Reference Requirements:**\n- ONLY reference fields that ACTUALLY EXIST in the Prisma schema\n- NEVER assume common fields exist without verification\n- Use exact field names as they appear in the schema\n- Describe behavior based on available schema structure\n\n## 5. Output Format (Function Calling Interface)\n\nYou must return a structured output following the `IAutoBeInterfaceAuthorizationsApplication.IProps` interface:\n\n### TypeScript Interface\n\n```typescript\nexport namespace IAutoBeInterfaceAuthorizationsApplication {\n  export interface IProps {\n    operations: AutoBeOpenApi.IOperation[];  // Array of authorization operations\n  }\n}\n\n// Each operation follows the standard AutoBeOpenApi.IOperation structure\n```\n\n### Field Descriptions\n\n#### operations\nArray of authorization-related API operations. Each operation must include:\n- All standard `AutoBeOpenApi.IOperation` fields (specification, path, method, etc.)\n- Proper `authorizationType` values for auth operations (`\"join\"`, `\"login\"`, `\"refresh\"`, or `null`)\n- Appropriate `authorizationRole` for role-specific endpoints\n\n### Output Method\n\nYou MUST call the `makeOperations()` function with your authorization operations.\n\n## 6. Implementation Requirements\n\n### 6.1. Critical Requirements\n- **Role-Based Essential Operations**: Generate appropriate essential operations based on role `kind`\n- **Operation Uniqueness**: Each authentication operation MUST be unique per role\n- **Schema-Driven Additions**: Add operations only for schema-supported features\n- **Field Verification**: Reference actual field names from the schema for additional features\n- **Never Skip Required Essentials**: Always include the role-appropriate core operations\n- **Proper Naming**: Ensure endpoint paths and function names follow conventions and are distinct\n- **Authentication Response Types**: All authentication operations (authorizationType !== null) MUST use `I{PascalPrefixName}{RoleName}.IAuthorized` format for response body typeName\n- **Function Call Required**: Use the provided function with all generated operations\n\n### 6.2. Implementation Strategy\n\n1. **Analyze Role Kind FIRST**: Determine which essential operations to generate based on `role.kind`\n2. **Generate Role-Appropriate Essential Operations**: \n   - Guest (`kind: \"guest\"`): Create `join` and `refresh` operations\n   - Member (`kind: \"member\"`)/Admin (`kind: \"admin\"`): Create `join`, `login`, and `refresh` operations\n3. **Analyze Schema Fields**: Systematically scan the role's table for additional authentication capabilities\n4. **Generate Schema-Supported Operations**: Add operations for confirmed schema features using field-to-operation mapping\n5. **Apply Naming Conventions**: Ensure proper path and function naming following the established patterns\n6. **Apply Response Type Rules**: Use `I{PascalPrefixName}{RoleName}.IAuthorized` for authentication operations\n7. **Document Rationale**: Explain which schema fields enable each operation and why certain operations are omitted for guests\n8. **Function Call**: Submit complete authentication API using the provided function\n\n**CRITICAL RULE**: The essential operations generated must match the role's authentication needs. Guest users should not have login operations since they don't authenticate with credentials, while member and admin users need full authentication flows.\n\nYour implementation should provide a complete authentication system with role-appropriate essential operations plus all additional operations that the Prisma schema clearly supports, ensuring every operation can be fully implemented with the available database structure, with clear and consistent naming conventions that distinguish between REST endpoints and business function names, and proper response type naming for authentication operations." /* AutoBeSystemPromptConstant.INTERFACE_AUTHORIZATION */,
         },
         ...(0, transformInterfaceAssetHistories_1.transformInterfaceAssetHistories)(props.state),
         {
@@ -38,15 +38,18 @@ const transformInterfaceAuthorizationsHistories = (props) => {
             text: utils_1.StringUtil.trim `
         ## API Design Instructions
 
-        The following API-specific instructions were extracted by AI from
-        the user's utterances. These focus ONLY on API interface design aspects
+        The following API-specific instructions were extracted from
+        the user's requirements. These focus on API interface design aspects
         such as endpoint patterns, request/response formats, DTO schemas,
         and operation specifications.
 
-        Apply these instructions when designing authorization-related API operations
-        for the ${props.role.name} role. Focus particularly on authentication endpoints,
-        token management, and security patterns. If the instructions are not relevant
-        to authorization operations for this specific role, you may ignore them.
+        Follow these instructions when designing authorization operations for ${props.role.name}.
+        Carefully distinguish between:
+        - Suggestions or recommendations (consider these as guidance)
+        - Direct specifications or explicit commands (these must be followed exactly)
+        
+        When instructions contain direct specifications or explicit design decisions, 
+        follow them precisely even if you believe you have better alternatives.
 
         ${props.instruction}
 

package/lib/orchestrate/interface/histories/transformInterfaceAuthorizationsHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformInterfaceAuthorizationsHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/interface/histories/transformInterfaceAuthorizationsHistories.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAC3C,+BAA0B;AAI1B,yFAAsF;AAE/E,MAAM,yCAAyC,GAAG,CAAC,KAIzD,EAEC,EAAE;IACF,MAAM,OAAO,GAAyB,KAAK,CAAC,KAAK,CAAC,OAAQ,CAAC;IAC3D,OAAO;QACL;YACE,IAAI,EAAE,eAAe;YACrB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,wmYAAoD;SACzD;QACD,GAAG,IAAA,mEAAgC,EAAC,KAAK,CAAC,KAAK,CAAC;QAChD;YACE,IAAI,EAAE,eAAe;YACrB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;sBAEL,OAAO,CAAC,MAAM;iCACH,OAAO,CAAC,MAAM;iBACpC,KAAK,CAAC,MAAM,CAAC;iBACb,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;iBAClD,IAAI,CAAC,EAAE,CAAC;mCACgB,OAAO,CAAC,MAAM;iBACtC,KAAK,CAAC,MAAM,CAAC;iBACb,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;iBAClD,IAAI,CAAC,EAAE,CAAC;OACZ;SACF;QACD;YACE,IAAI,EAAE,kBAAkB;YACxB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;;;kBAST,KAAK,CAAC,IAAI,CAAC,IAAI;;;;UAIvB,KAAK,CAAC,WAAW;;;;;;;UAOjB,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,IAAI,CAAC;;OAE7B;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AA9DW,QAAA,yCAAyC,6CA8DpD"}
+{"version":3,"file":"transformInterfaceAuthorizationsHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/interface/histories/transformInterfaceAuthorizationsHistories.ts"],"names":[],"mappings":";;;AAEA,yCAA2C;AAC3C,+BAA0B;AAI1B,yFAAsF;AAE/E,MAAM,yCAAyC,GAAG,CAAC,KAIzD,EAEC,EAAE;IACF,MAAM,OAAO,GAAyB,KAAK,CAAC,KAAK,CAAC,OAAQ,CAAC;IAC3D,OAAO;QACL;YACE,IAAI,EAAE,eAAe;YACrB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,uwYAAoD;SACzD;QACD,GAAG,IAAA,mEAAgC,EAAC,KAAK,CAAC,KAAK,CAAC;QAChD;YACE,IAAI,EAAE,eAAe;YACrB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;sBAEL,OAAO,CAAC,MAAM;iCACH,OAAO,CAAC,MAAM;iBACpC,KAAK,CAAC,MAAM,CAAC;iBACb,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;iBAClD,IAAI,CAAC,EAAE,CAAC;mCACgB,OAAO,CAAC,MAAM;iBACtC,KAAK,CAAC,MAAM,CAAC;iBACb,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,GAAG,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC;iBAClD,IAAI,CAAC,EAAE,CAAC;OACZ;SACF;QACD;YACE,IAAI,EAAE,kBAAkB;YACxB,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAU,CAAC,IAAI,CAAA;;;;;;;;gFAQqD,KAAK,CAAC,IAAI,CAAC,IAAI;;;;;;;;UAQrF,KAAK,CAAC,WAAW;;;;;;;UAOjB,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,IAAI,CAAC;;OAE7B;SACF;KACF,CAAC;AACJ,CAAC,CAAC;AAjEW,QAAA,yCAAyC,6CAiEpD"}

package/lib/orchestrate/interface/histories/transformInterfaceCommonHistories.d.ts

@@ -0,0 +1,3 @@
+import { IAgenticaHistoryJson } from "@agentica/core";
+import { AutoBeState } from "../../../context/AutoBeState";
+export declare const transformInterfaceCommonHistories: (state: AutoBeState) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage> | null;

package/lib/orchestrate/interface/histories/{transformInterfaceCommonPrerequisiteHistories.js → transformInterfaceCommonHistories.js}

@@ -1,8 +1,8 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.transformInterfaceCommonPrerequisiteHistories = void 0;
+exports.transformInterfaceCommonHistories = void 0;
 const uuid_1 = require("uuid");
-const transformInterfaceCommonPrerequisiteHistories = (state) => {
+const transformInterfaceCommonHistories = (state) => {
     if (state.analyze === null)
         return [
             {
@@ -59,5 +59,5 @@ const transformInterfaceCommonPrerequisiteHistories = (state) => {
         ];
     return null;
 };
-exports.transformInterfaceCommonPrerequisiteHistories = transformInterfaceCommonPrerequisiteHistories;
-//# sourceMappingURL=transformInterfaceCommonPrerequisiteHistories.js.map
+exports.transformInterfaceCommonHistories = transformInterfaceCommonHistories;
+//# sourceMappingURL=transformInterfaceCommonHistories.js.map

package/lib/orchestrate/interface/histories/transformInterfaceCommonHistories.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"transformInterfaceCommonHistories.js","sourceRoot":"","sources":["../../../../src/orchestrate/interface/histories/transformInterfaceCommonHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAInB,MAAM,iCAAiC,GAAG,CAC/C,KAAkB,EAGX,EAAE;IACT,IAAI,KAAK,CAAC,OAAO,KAAK,IAAI;QACxB,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,4CAA4C;oBAC5C,mCAAmC;oBACnC,8CAA8C;iBAC/C,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,MAAM,KAAK,IAAI;QAC5B,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,mDAAmD;oBACnD,mCAAmC;oBACnC,qDAAqD;iBACtD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,OAAO,CAAC,IAAI,KAAK,KAAK,CAAC,MAAM,CAAC,IAAI;QAC/C,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,kDAAkD;oBAClD,sCAAsC;oBACtC,mCAAmC;oBACnC,wDAAwD;iBACzD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;SACC,IAAI,KAAK,CAAC,MAAM,CAAC,QAAQ,CAAC,IAAI,KAAK,SAAS;QAC/C,OAAO;YACL;gBACE,EAAE,EAAE,IAAA,SAAE,GAAE;gBACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;gBACpC,IAAI,EAAE,eAAe;gBACrB,IAAI,EAAE;oBACJ,kDAAkD;oBAClD,sCAAsC;oBACtC,mCAAmC;oBACnC,wDAAwD;iBACzD,CAAC,IAAI,CAAC,GAAG,CAAC;aACZ;SACF,CAAC;IACJ,OAAO,IAAI,CAAC;AACd,CAAC,CAAC;AA5DW,QAAA,iCAAiC,qCA4D5C"}