@autobe/agent 0.8.0 → 0.9.0

package/lib/orchestrate/test/orchestrateTestScenario.js.map

@@ -1 +1 @@
-{"version":3,"file":"orchestrateTestScenario.js","sourceRoot":"","sources":["../../../src/orchestrate/test/orchestrateTestScenario.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAcA,0DAkEC;;AAhFD,yCAAoE;AAIpE,+BAAkD;AAClD,kDAA0B;AAG1B,uEAAoE;AACpE,yDAAsD;AACtD,iEAA8D;AAC9D,sFAAmF;AACnF,qFAAkF;AAElF,SAAsB,uBAAuB;yDAC3C,GAAyB,EACzB,WAAmB,CAAC;;QAEpB,MAAM,KAAK,GAAG,MAAM,CAAC,OAAO,CAAC,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,SAAS,0CAAE,KAAK,mCAAI,EAAE,CAAC;aAC7D,MAAM,CAAC,CAAC,CAAC,QAAQ,CAAC,EAAE,EAAE;YACrB,OAAO,QAAQ,CAAC,UAAU,CAAC,oBAAoB,CAAC,CAAC;QACnD,CAAC,CAAC;aACD,MAAM,CAAyB,CAAC,GAAG,EAAE,CAAC,QAAQ,EAAE,OAAO,CAAC,EAAE,EAAE;YAC3D,OAAO,MAAM,CAAC,MAAM,CAAC,GAAG,EAAE,EAAE,CAAC,QAAQ,CAAC,EAAE,OAAO,EAAE,CAAC,CAAC;QACrD,CAAC,EAAE,EAAE,CAAC,CAAC;QAET,MAAM,UAAU,GAAG,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,SAAS,0CAAE,QAAQ,CAAC,UAAU,mCAAI,EAAE,CAAC;QACpE,MAAM,SAAS,GACb,UAAU,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE;YACpB,OAAO;gBACL,MAAM,EAAE,EAAE,CAAC,MAAM;gBACjB,IAAI,EAAE,EAAE,CAAC,IAAI;gBACb,OAAO,EAAE,EAAE,CAAC,OAAO;gBACnB,WAAW,EAAE,EAAE,CAAC,WAAW;gBAC3B,UAAU,EAAE,EAAE,CAAC,UAAU;gBACzB,WAAW,EAAE,EAAE,CAAC,WAAW;gBAC3B,YAAY,EAAE,EAAE,CAAC,YAAY;aAC9B,CAAC;QACJ,CAAC,CAAC,CAAC;QAEL,MAAM,MAAM,GAAgC,IAAA,yBAAW,EAAC;YACtD,KAAK,EAAE,SAAS;YAChB,QAAQ;SACT,CAAC,CAAC;QACH,MAAM,KAAK,GAAS,IAAI,IAAI,EAAE,CAAC;QAE/B,IAAI,SAAS,GAAW,CAAC,CAAC;QAE1B,MAAM,SAAS,GAA6B,MAAM,OAAO,CAAC,GAAG,CAC3D,MAAM,CAAC,GAAG,CAAC,CAAO,CAAC,EAAE,EAAE;;YACrB,MAAM,IAAI,GAA2B,MAAM,gBAAgB,CACzD,GAAG,EACH,CAAC,EACD,SAAS,EACT,KAAK,EACL,CAAC,EACD,CAAC,KAAK,EAAE,EAAE;gBACR,SAAS,IAAI,KAAK,CAAC;YACrB,CAAC,CACF,CAAC;YACF,GAAG,CAAC,QAAQ,CAAC;gBACX,IAAI,EAAE,cAAc;gBACpB,SAAS,EAAE,IAAI;gBACf,KAAK,EAAE,IAAI,CAAC,OAAO,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,EAAE,CAAC,SAAS,CAAC,CAAC,MAAM;gBAChD,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,IAAI,0CAAE,IAAI,mCAAI,CAAC;gBACjC,SAAS;gBACT,UAAU,EAAE,KAAK,CAAC,WAAW,EAAE;aAChC,CAAC,CAAC;YACH,OAAO,IAAI,CAAC;QACd,CAAC,CAAA,CAAC,CACH,CAAC;QAEF,OAAO;YACL,IAAI,EAAE,cAAc;YACpB,SAAS,EAAE,SAAS,CAAC,IAAI,EAAE;YAC3B,KAAK,EAAE,SAAS,CAAC,IAAI,EAAE,CAAC,OAAO,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,EAAE,CAAC,SAAS,CAAC,CAAC,MAAM;YAC5D,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,IAAI,0CAAE,IAAI,mCAAI,CAAC;YACjC,SAAS;YACT,UAAU,EAAE,KAAK,CAAC,WAAW,EAAE;SAChC,CAAC;IACJ,CAAC;CAAA;AAED,SAAe,gBAAgB,CAC7B,GAAyB,EACzB,SAAoC,EACpC,YAAuC,EACvC,KAA6B,EAC7B,KAAa,EACb,QAAqC;;QAErC,MAAM,QAAQ,GAAqC,IAAI,cAAO,CAC5D,SAAS,EACT,qDAAyB,CAAC,QAAQ,EAClC,qDAAyB,CAAC,MAAM,CACjC,CAAC;QACF,MAAM,SAAS,GACb,IAAI,cAAO,CACT,qDAAyB,CAAC,QAAQ,EAClC,qDAAyB,CAAC,MAAM,CACjC,CAAC;QACJ,KAAK,IAAI,CAAC,GAAW,CAAC,EAAE,CAAC,GAAG,KAAK,EAAE,EAAE,CAAC,EAAE,CAAC;YACvC,IAAI,QAAQ,CAAC,KAAK,EAAE,KAAK,IAAI,IAAI,SAAS,CAAC,IAAI,EAAE,IAAI,SAAS,CAAC,MAAM;gBACnE,MAAM;YACR,MAAM,MAAM,GAAW,SAAS,CAAC,IAAI,EAAE,CAAC;YACxC,MAAM,MAAM,GAA2B,MAAM,OAAO,CAClD,GAAG,EACH,KAAK,CAAC,IAAI,CAAC,QAAQ,CAAC,EACpB,YAAY,EACZ,KAAK,CACN,CAAC;YACF,KAAK,MAAM,IAAI,IAAI,MAAM,EAAE,CAAC;gBAC1B,SAAS,CAAC,GAAG,CAAC,IAAI,CAAC,QAAQ,EAAE,IAAI,CAAC,SAAS,CAAC,CAAC;gBAC7C,QAAQ,CAAC,KAAK,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAC;YAChC,CAAC;YACD,IAAI,SAAS,CAAC,IAAI,EAAE,GAAG,MAAM,KAAK,CAAC;gBAAE,QAAQ,CAAC,SAAS,CAAC,IAAI,EAAE,GAAG,MAAM,CAAC,CAAC;QAC3E,CAAC;QACD,OAAO,KAAK,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,EAAE,CAAC,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,CAAC;YACjD,QAAQ,EAAE,EAAE,CAAC,KAAK;YAClB,SAAS,EAAE,EAAE,CAAC,MAAM;SACrB,CAAC,CAAC,CAAC;IACN,CAAC;CAAA;AAED,SAAe,OAAO,CACpB,GAAyB,EACzB,SAAoC,EACpC,YAAuC,EACvC,KAA6B;;;QAE7B,MAAM,OAAO,GAA4C;YACvD,KAAK,EAAE,IAAI;SACZ,CAAC;QAEF,MAAM,QAAQ,GAAG,IAAI,oBAAa,CAAC;YACjC,KAAK,EAAE,GAAG,CAAC,KAAK;YAChB,MAAM,EAAE,GAAG,CAAC,MAAM;YAClB,MAAM,kCACD,CAAC,MAAA,GAAG,CAAC,MAAM,mCAAI,EAAE,MAAM,EAAE,OAAO,EAAE,CAAC,KACtC,YAAY,EAAE;oBACZ,QAAQ,EAAE,GAAG,EAAE;wBACb,OAAO,wCAAwC,CAAC;oBAClD,CAAC;iBACF,GACF;YACD,UAAU,EAAE,GAAG,CAAC,KAAK,EAAE;YACvB,SAAS,EAAE;gBACT,GAAG,IAAA,+DAA8B,EAAC,GAAG,CAAC,KAAK,EAAE,EAAE,YAAY,EAAE,KAAK,CAAC;aACpE;YACD,WAAW,EAAE;gBACX,iBAAiB,CAAC;oBAChB,KAAK,EAAE,GAAG,CAAC,KAAK;oBAChB,KAAK,EAAE,CAAC,IAAI,EAAE,EAAE;;wBACd,MAAA,OAAO,CAAC,KAAK,oCAAb,OAAO,CAAC,KAAK,GAAK,EAAE,EAAC;wBACrB,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,GAAG,IAAI,CAAC,SAAS,CAAC,CAAC;oBACxC,CAAC;iBACF,CAAC;aACH;SACF,CAAC,CAAC;QACH,IAAA,iCAAe,EAAC,QAAQ,CAAC,CAAC;QAE1B,MAAM,QAAQ,CAAC,UAAU,CACvB;YACE,0CAA0C;YAC1C,EAAE;YACF,SAAS;YACT,IAAI,CAAC,SAAS,CAAC,SAAS,EAAE,IAAI,EAAE,CAAC,CAAC;YAClC,KAAK;SACN,CAAC,IAAI,CAAC,IAAI,CAAC,CACb,CAAC;QACF,IAAI,OAAO,CAAC,KAAK,KAAK,IAAI;YAAE,MAAM,IAAI,KAAK,CAAC,2BAA2B,CAAC,CAAC;QACzE,OAAO,OAAO,CAAC,KAAK,CAAC;IACvB,CAAC;CAAA;AAED,SAAS,iBAAiB,CAAiC,KAG1D;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAE/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACyB,CAAC;IACvC,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,qBAAqB;QAC3B,WAAW;QACX,OAAO,EAAE;YACP,YAAY,EAAE,CAAC,IAAI,EAAE,EAAE;gBACrB,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACqB;KACzB,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAIJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;IACb,KAAK;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAA8C;CACpD,CAAC"}
+{"version":3,"file":"orchestrateTestScenario.js","sourceRoot":"","sources":["../../../src/orchestrate/test/orchestrateTestScenario.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAmBA,0DAyDC;;AA5ED,yCAIwB;AAKxB,kDAA0B;AAC1B,+BAA0B;AAI1B,uEAAoE;AACpE,yDAAsD;AACtD,iEAA8D;AAG9D,SAAsB,uBAAuB,CAC3C,GAAyB;;;QAEzB,MAAM,UAAU,GAAG,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,SAAS,0CAAE,QAAQ,CAAC,UAAU,mCAAI,EAAE,CAAC;QACpE,IAAI,UAAU,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YAC5B,MAAM,IAAI,KAAK,CACb,8DAA8D,CAC/D,CAAC;QACJ,CAAC;QAED,MAAM,OAAO,GAAoD,EAAE,CAAC;QACpE,IAAI,OAAO,GAA+B,KAAK,CAAC,IAAI,CAAC,UAAU,CAAC,CAAC;QAEjE,GAAG,CAAC;YACF,MAAM,MAAM,GAAG,IAAA,yBAAW,EAAC,EAAE,KAAK,EAAE,OAAO,EAAE,QAAQ,EAAE,EAAE,EAAE,CAAC,CAAC;YAE7D,MAAM,OAAO,CAAC,GAAG,CACf,MAAM,CAAC,GAAG,CAAC,CAAO,QAAQ,EAAE,EAAE;gBAC5B,OAAO,CAAC,IAAI,CACV,GAAG,CAAC,MAAM,OAAO,CACf,GAAG,EACH,UAAU,EACV,QAAQ,EACR,OAAO,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,QAAQ,CAAC,CAC/B,CAAC,CACH,CAAC;YACJ,CAAC,CAAA,CAAC,CACH,CAAC;YAEF,OAAO,GAAG,OAAO,CAAC,MAAM,CAAC,CAAC,EAAE,EAAE,EAAE;gBAC9B,IACE,OAAO,CAAC,IAAI,CACV,CAAC,EAAE,EAAE,EAAE,CACL,EAAE,CAAC,QAAQ,CAAC,MAAM,KAAK,EAAE,CAAC,MAAM,IAAI,EAAE,CAAC,QAAQ,CAAC,IAAI,KAAK,EAAE,CAAC,IAAI,CACnE,EACD,CAAC;oBACD,OAAO,KAAK,CAAC;gBACf,CAAC;gBACD,OAAO,IAAI,CAAC;YACd,CAAC,CAAC,CAAC;QACL,CAAC,QAAQ,OAAO,CAAC,MAAM,GAAG,CAAC,EAAE;QAE7B,OAAO;YACL,IAAI,EAAE,cAAc;YACpB,IAAI,EAAE,MAAA,MAAA,GAAG,CAAC,KAAK,EAAE,CAAC,OAAO,0CAAE,IAAI,mCAAI,CAAC;YACpC,SAAS,EAAE,OAAO,CAAC,OAAO,CAAC,CAAC,EAAE,EAAE,EAAE;gBAChC,OAAO,EAAE,CAAC,SAAS,CAAC,GAAG,CAAC,CAAC,IAAI,EAAE,EAAE;oBAC/B,OAAO;wBACL,QAAQ,EAAE,EAAE,CAAC,QAAQ;wBACrB,KAAK,EAAE,IAAI,CAAC,KAAK;wBACjB,YAAY,EAAE,IAAI,CAAC,YAAY;wBAC/B,YAAY,EAAE,IAAI,CAAC,SAAS;qBACe,CAAC;gBAChD,CAAC,CAAC,CAAC;YACL,CAAC,CAAC;YACF,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;SACV,CAAC;IAC/B,CAAC;CAAA;AAED,MAAM,OAAO,GAAG,CACd,GAAyB,EACzB,GAA+B,EAC/B,OAA4D,EAC5D,OAA4D,EAC5D,EAAE;;IACF,MAAM,OAAO,GAA8D;QACzE,KAAK,EAAE,EAAE;KACV,CAAC;IACF,MAAM,QAAQ,GAAyB,IAAI,oBAAa,CAAC;QACvD,KAAK,EAAE,GAAG,CAAC,KAAK;QAChB,MAAM,EAAE,GAAG,CAAC,MAAM;QAClB,MAAM,kCACD,CAAC,MAAA,GAAG,CAAC,MAAM,mCAAI,EAAE,CAAC,KACrB,QAAQ,EAAE;gBACR,QAAQ,EAAE,IAAI;aACf,GACF;QACD,UAAU,EAAE,GAAG,CAAC,KAAK,EAAE;QACvB,SAAS,EAAE,uBAAuB,CAAC,GAAG,EAAE,OAAO,EAAE,OAAO,CAAC;QACzD,WAAW,EAAE;YACX,iBAAiB,CAAC;gBAChB,KAAK,EAAE,GAAG,CAAC,KAAK;gBAChB,KAAK,EAAE,CAAC,IAAI,EAAE,EAAE;;oBACd,MAAA,OAAO,CAAC,KAAK,oCAAb,OAAO,CAAC,KAAK,GAAK,EAAE,EAAC;oBACrB,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,GAAG,IAAI,CAAC,cAAc,CAAC,CAAC;gBAC7C,CAAC;aACF,CAAC;SACH;KACF,CAAC,CAAC;IACH,IAAA,iCAAe,EAAC,QAAQ,CAAC,CAAC;IAE1B,MAAM,QAAQ,CAAC,UAAU,CAAC,wBAAwB,CAAC,CAAC;IACpD,IAAI,OAAO,CAAC,KAAK,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QAC/B,MAAM,IAAI,KAAK,CAAC,8BAA8B,CAAC,CAAC;IAClD,CAAC;IAED,OAAO,OAAO,CAAC,KAAK,CAAC;AACvB,CAAC,CAAA,CAAC;AAEF,MAAM,uBAAuB,GAAG,CAC9B,UAAsC,EACtC,OAA4D,EAC5D,OAA4D,EAC5D,EAAE,CAAC;IACH;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,4yIAA0C;KACD;IAC/C;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,EAAE;YACJ,sDAAsD;YACtD,gEAAgE;YAChE,2EAA2E;YAC3E,6HAA6H;YAC7H,EAAE;YACF,SAAS;YACT,IAAI,CAAC,SAAS,CACZ,UAAU,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,CAAC;gBACtB,IAAI,EAAE,EAAE,CAAC,IAAI;gBACb,MAAM,EAAE,EAAE,CAAC,MAAM;gBACjB,OAAO,EAAE,EAAE,CAAC,OAAO;aACpB,CAAC,CAAC,CACJ;YACD,KAAK;SACN,CAAC,IAAI,CAAC,IAAI,CAAC;KACiC;IAC/C;QACE,EAAE,EAAE,IAAA,SAAE,GAAE;QACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;QACpC,IAAI,EAAE,eAAe;QACrB,IAAI,EAAE;YACJ,yBAAyB;YACzB,OAAO;iBACJ,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,KAAK,EAAE,CAAC,MAAM,CAAC,WAAW,EAAE,KAAK,EAAE,CAAC,IAAI,EAAE,CAAC;iBACvD,IAAI,CAAC,IAAI,CAAC;YACb,EAAE;YACF,2BAA2B;YAC3B,sGAAsG;YACtG,iDAAiD;YACjD,8GAA8G;YAC9G,OAAO;iBACJ,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,KAAK,EAAE,CAAC,MAAM,CAAC,WAAW,EAAE,KAAK,EAAE,CAAC,IAAI,EAAE,CAAC;iBACvD,IAAI,CAAC,IAAI,CAAC;SACd,CAAC,IAAI,CAAC,IAAI,CAAC;KACiC;CAChD,CAAC;AAEF,SAAS,iBAAiB,CAAiC,KAG1D;IACC,IAAA,qCAAiB,EAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IAE/B,MAAM,WAAW,GAA2B,UAAU,CACpD,KAAK,CAAC,KAAK,CACyB,CAAC;IAEvC,WAAW,CAAC,SAAS,CAAC,CAAC,CAAC,CAAC,QAAQ,GAAG,CAAC,IAAa,EAAe,EAAE;QACjE,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gBAC4C,IAAI,CAAC,CAAC;QAC9D,IAAI,MAAM,CAAC,OAAO,KAAK,KAAK;YAAE,OAAO,MAAM,CAAC;QAE5C,MAAM,MAAM,GAAyB,EAAE,CAAC;QACxC,MAAM,CAAC,IAAI,CAAC,cAAc,CAAC,OAAO,CAAC,CAAC,EAAE,EAAE,CAAC,EAAE,GAAG,EAAE,EAAE;YAChD,GAAG,CAAC,OAAO,CAAC,CAAC,MAAM,EAAE,CAAC,EAAE,EAAE;gBACxB,IACE,CAAC,KAAK,CAAC;oBACP,MAAM,CAAC,QAAQ,CAAC,MAAM,KAAK,EAAE,CAAC,QAAQ,CAAC,MAAM;oBAC7C,MAAM,CAAC,QAAQ,CAAC,IAAI,KAAK,EAAE,CAAC,QAAQ,CAAC,IAAI,EACzC,CAAC;oBACD,IACE,CAAC,MAAM,CAAC,IAAI,CACV,CAAC,EAAE,EAAE,EAAE,CACL,EAAE,CAAC,IAAI,KAAK,cAAc,CAAC,QAAQ;wBACnC,EAAE,CAAC,KAAK,KAAK,MAAM,CAAC,QAAQ,CAAC,IAAI,CACpC,EACD,CAAC;wBACD,MAAM,CAAC,IAAI,CAAC;4BACV,IAAI,EAAE,cAAc,CAAC,QAAQ;4BAC7B,QAAQ,EAAE,gDAAgD;4BAC1D,KAAK,EAAE,MAAM,CAAC,QAAQ,CAAC,IAAI;yBAC5B,CAAC,CAAC;oBACL,CAAC;oBAED,IACE,CAAC,MAAM,CAAC,IAAI,CACV,CAAC,EAAE,EAAE,EAAE,CACL,EAAE,CAAC,IAAI,KAAK,cAAc,CAAC,UAAU;wBACrC,EAAE,CAAC,KAAK,KAAK,MAAM,CAAC,QAAQ,CAAC,MAAM,CACtC,EACD,CAAC;wBACD,MAAM,CAAC,IAAI,CAAC;4BACV,IAAI,EAAE,cAAc,CAAC,UAAU;4BAC/B,QAAQ,EAAE,gDAAgD;4BAC1D,KAAK,EAAE,MAAM,CAAC,QAAQ,CAAC,MAAM;yBAC9B,CAAC,CAAC;oBACL,CAAC;gBACH,CAAC;YACH,CAAC,CAAC,CAAC;QACL,CAAC,CAAC,CAAC;QAEH,IAAI,MAAM,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YACxB,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC,MAAM,EAAE,IAAI,EAAE,CAAC,CAAC,EAAE,QAAQ,CAAC,CAAC;YACvD,OAAO;gBACL,OAAO,EAAE,KAAK;gBACd,MAAM;gBACN,IAAI,EAAE,IAAI;aACX,CAAC;QACJ,CAAC;QAED,OAAO,MAAM,CAAC;IAChB,CAAC,CAAC;IACF,OAAO;QACL,QAAQ,EAAE,OAAO;QACjB,IAAI,EAAE,iBAAiB;QACvB,WAAW;QACX,OAAO,EAAE;YACP,YAAY,EAAE,CAAC,IAAI,EAAE,EAAE;gBACrB,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;YACpB,CAAC;SACuC;KAC3C,CAAC;AACJ,CAAC;AAED,MAAM,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAMT,CAAC;AACJ,MAAM,UAAU,GAAG;IACjB,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAIJ;IACH,MAAM;IACN,KAAK,EAAE,MAAM;IACb,QAAQ,EAAE,MAAM;IAChB,KAAK,EAAE,MAAM;IACb,KAAK;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;KAAgE;CACtE,CAAC"}

package/lib/orchestrate/test/structures/IAutoBeTestScenarioApplication.d.ts

@@ -0,0 +1,123 @@
+import { AutoBeOpenApi } from "@autobe/interface";
+export interface IAutoBeTestScenarioApplication {
+    /**
+     * Make test scenarios for the given endpoints.
+     *
+     * @param props Properties containing the endpoints and test scenarios.
+     */
+    makeScenario(props: IAutoBeTestScenarioApplication.IProps): void;
+}
+export declare namespace IAutoBeTestScenarioApplication {
+    interface IProps {
+        /** Array of test scenario groups. */
+        scenarioGroups: IAutoBeTestScenarioApplication.IScenarioGroup[];
+    }
+    interface IScenarioGroup {
+        /** Target API endpoint to test. */
+        endpoint: AutoBeOpenApi.IEndpoint;
+        /** Array of test scenarios. */
+        scenarios: IScenario[];
+    }
+    /**
+     * Represents a test scenario for a single API operation.
+     *
+     * This interface extends `AutoBeOpenApi.IEndpoint`, inheriting its HTTP
+     * method and path information, and adds two key properties:
+     *
+     * - `draft`: A free-form, human-readable test scenario description for the API
+     *   endpoint.
+     * - `dependsOn`: A list of other API endpoints that must be invoked beforehand
+     *   in order to prepare the context for this test. Each dependency includes
+     *   the purpose of the dependency.
+     *
+     * This structure is intended to help organize test specifications for complex
+     * workflows and ensure that all prerequisites are explicitly declared.
+     */
+    interface IScenario {
+        /**
+         * A detailed natural language description of how this API endpoint should
+         * be tested. This should include both successful and failure scenarios,
+         * business rule validations, edge cases, and any sequence of steps
+         * necessary to perform the test. A subsequent agent will use this draft to
+         * generate multiple test scenarios.
+         */
+        draft: string;
+        /**
+         * Descriptive function name derived from the user scenario.
+         *
+         * The function name serves as a concise, technical identifier that clearly
+         * represents the specific user scenario being described. It should be
+         * immediately understandable and directly correspond to the user situation
+         * without requiring additional context.
+         *
+         * ## Naming Convention
+         *
+         * - Must start with `test_` prefix (mandatory requirement)
+         * - Use snake_case formatting throughout
+         * - Include the primary user action (create, get, update, delete, list, etc.)
+         * - Specify the target resource (user, product, order, profile, etc.)
+         * - Add scenario-specific context (valid_data, invalid_email, not_found,
+         *   etc.)
+         *
+         * ## Content Structure
+         *
+         * Function names should follow this pattern:
+         * `test_[user_action]_[resource]_[scenario_context]`
+         *
+         * Where:
+         *
+         * - `user_action`: What the user is trying to do
+         * - `resource`: What the user is interacting with
+         * - `scenario_context`: The specific situation or condition
+         *
+         * ## User-Focused Examples
+         *
+         * - `test_create_user_profile_with_complete_information` - User providing all
+         *   available profile data
+         * - `test_retrieve_user_profile_when_profile_exists` - User accessing their
+         *   existing profile
+         * - `test_update_user_email_with_valid_new_address` - User changing their
+         *   email to a valid new one
+         * - `test_delete_user_account_when_user_lacks_permission` - User attempting
+         *   account deletion without authorization
+         * - `test_search_user_profiles_with_pagination_preferences` - User browsing
+         *   profiles with specific pagination
+         *
+         * ## Clarity Guidelines
+         *
+         * - Prioritize clarity over brevity
+         * - Avoid technical jargon or implementation terms
+         * - Use terminology that reflects user perspective
+         * - Ensure the name alone conveys the user's intent
+         * - Make it understandable to non-technical stakeholders
+         * - Keep consistent with user scenario description
+         *
+         * ## Single Endpoint Alignment
+         *
+         * Function names must reflect scenarios that:
+         *
+         * - Accomplish user goals through this single endpoint only
+         * - Don't imply dependency on other API operations
+         * - Represent complete user interactions
+         */
+        functionName: string;
+        /**
+         * A list of other API endpoints that must be executed before this test
+         * scenario. This helps express dependencies such as data creation or
+         * authentication steps required to reach the intended test state.
+         */
+        dependsOn: IDependsOn[];
+    }
+    interface IDependsOn {
+        /** Target API endpoint that must be executed before the main operation. */
+        endpoint: AutoBeOpenApi.IEndpoint;
+        /**
+         * A concise exscenarioation of why this API call is required before
+         * executing the test for the main operation.
+         *
+         * Example: "Creates a category so that a product can be linked to it during
+         * creation."
+         */
+        purpose: string;
+    }
+}

package/lib/orchestrate/test/structures/IAutoBeTestScenarioApplication.js

@@ -0,0 +1,3 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+//# sourceMappingURL=IAutoBeTestScenarioApplication.js.map

package/lib/orchestrate/test/structures/IAutoBeTestScenarioApplication.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"IAutoBeTestScenarioApplication.js","sourceRoot":"","sources":["../../../../src/orchestrate/test/structures/IAutoBeTestScenarioApplication.ts"],"names":[],"mappings":""}

package/lib/orchestrate/test/transformTestCorrectHistories.d.ts

@@ -1,2 +1,3 @@
 import { IAgenticaHistoryJson } from "@agentica/core";
-export declare const transformTestCorrectHistories: (apiFiles: Record<string, string>, dtoFiles: Record<string, string>) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;
+import { AutoBeOpenApi } from "@autobe/interface";
+export declare const transformTestCorrectHistories: (document: AutoBeOpenApi.IDocument | null) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/orchestrate/test/transformTestCorrectHistories.js

@@ -2,13 +2,13 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.transformTestCorrectHistories = void 0;
 const uuid_1 = require("uuid");
-const transformTestCorrectHistories = (apiFiles, dtoFiles) => {
+const transformTestCorrectHistories = (document) => {
     return [
         {
             id: (0, uuid_1.v4)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "# Compiler Error Fix System Prompt\n\nYou are an expert TypeScript compiler error fixing agent specializing in resolving compilation errors in E2E test code that follows the `@nestia/e2e` testing framework conventions.\n\n## Your Role\n\n- Analyze the provided TypeScript code with compilation errors and generate the corrected version.  \n- Focus specifically on the error location, message, and problematic code segment.  \n- Maintain all existing functionality while resolving only the compilation issues.  \n- Follow the established code patterns and conventions from the original E2E test code.  \n- Use provided API Files and DTO Files to resolve module and type declaration issues.  \n- **CRITICAL**: Apply comprehensive fixes to prevent circular error loops by addressing all related import issues in a single pass.\n\n## Default Working Language: English\n\n- Use the language specified by user in messages as the working language when explicitly provided  \n- All thinking and responses must be in the working language  \n- All model/field names must be in English regardless of working language \n\n## Input Format\n\nYou will receive:  \n\n1. **Original Code**: TypeScript E2E test code with compilation errors  \n2. **Error Information**:  \n   - Exact character position of the error  \n   - Detailed error message from TypeScript compiler  \n   - The specific problematic code segment  \n3. **Instructions**: Specific guidance on what needs to be fixed  \n4. **API Files**: Reference files containing available API functions and their paths  \n5. **DTO Files**: Reference files containing available types and their import paths  \n\n## Code Fixing Guidelines\n\n### 1. Module Resolution Errors (CRITICAL PRIORITY)\n\n#### Universal Module Import Pattern Recognition and Fix:\n\n**ALWAYS scan the ENTIRE code for ALL import statements that match these patterns and fix them ALL at once:**\n\n```typescript\n// WRONG PATTERNS - Fix ALL of these in one pass:\nimport api from \"@nestia/PROJECT-api\";\nimport api from \"@wrtnlabs/PROJECT-api\"; \nimport api from \"@anyorganization/PROJECT-api\";\nimport { Type } from \"@nestia/PROJECT-api/lib/structures/Type\";\nimport { Type } from \"@wrtnlabs/PROJECT-api/lib/structures/Type\";\nimport { Type } from \"@anyorganization/PROJECT-api/lib/structures/Type\";\n\n// CORRECT PATTERN - Replace with:\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { Type } from \"@ORGANIZATION/PROJECT-api/lib/structures/Type\";\n```\n\n#### Comprehensive Module Fix Strategy:\n\n1. **Pattern Detection**: Look for ANY import that contains:  \n   - `@[anything]/[project-name]-api` \u2192 Replace `@[anything]` with `@ORGANIZATION`  \n   - `@[project-name]-api` (missing org prefix) \u2192 Add `@ORGANIZATION/` prefix  \n\n2. **Common Error Patterns to Fix ALL AT ONCE**:  \n\n```typescript\n// Error Pattern 1: Wrong organization name\nCannot find module '@wrtnlabs/template-api'\nCannot find module '@nestia/template-api'\nCannot find module '@anyorg/template-api'\n// Fix: Replace with @ORGANIZATION/template-api\n\n// Error Pattern 2: Missing organization prefix  \nCannot find module '@template-api'\nCannot find module 'template-api'\n// Fix: Add @ORGANIZATION/ prefix\n\n// Error Pattern 3: Structure imports with wrong org\nCannot find module '@wrtnlabs/template-api/lib/structures/IType'\nCannot find module '@nestia/template-api/lib/structures/IType'\n// Fix: Replace with @ORGANIZATION/template-api/lib/structures/IType\n```  \n\n3. **Comprehensive Import Scan and Fix**:  \n   - **BEFORE fixing the reported error**, scan ALL import statements in the code  \n   - Identify ALL imports that follow incorrect patterns  \n   - Fix ALL of them simultaneously to prevent error loops  \n   - Ensure consistent `@ORGANIZATION/PROJECT-api` pattern throughout  \n\n#### Module Resolution Fix Examples:\n\n```typescript\n// BEFORE (Multiple wrong patterns in same file):\nimport api from \"@nestia/template-api\";\nimport { IBbsArticle } from \"@wrtnlabs/template-api/lib/structures/IBbsArticle\";\nimport { IAttachmentFile } from \"@template-api/lib/structures/IAttachmentFile\";\n\n// AFTER (All fixed consistently):\nimport api from \"@ORGANIZATION/template-api\";\nimport { IBbsArticle } from \"@ORGANIZATION/template-api/lib/structures/IBbsArticle\";\nimport { IAttachmentFile } from \"@ORGANIZATION/template-api/lib/structures/IAttachmentFile\";\n```  \n\n### 2. Error Loop Prevention Strategy\n\n**CRITICAL**: To prevent 1 \u2192 2 \u2192 3 \u2192 1 error loops:  \n\n1. **Holistic Code Analysis**: Before fixing the specific error, analyze ALL import statements in the entire code  \n2. **Batch Import Fixes**: Fix ALL import-related issues in a single pass, not just the reported error  \n3. **Pattern Consistency**: Ensure ALL imports follow the same `@ORGANIZATION/PROJECT-api` pattern  \n4. **Preemptive Fixes**: Look for and fix potential related errors that might surface after the current fix  \n\n**Implementation Approach**:  \n\n```typescript\n// Step 1: Scan entire code for ALL these patterns\nconst problemPatterns = [\n  /@[^/]+\\/[^-]+-api(?!\\/)/g,           // Wrong org prefix\n  /@[^-]+-api(?!\\/)/g,                  // Missing org prefix  \n  /from\\s+[\"']@[^/]+\\/[^-]+-api/g,      // Wrong org in imports\n  /from\\s+[\"']@[^-]+-api/g              // Missing org in imports\n];\n\n// Step 2: Replace ALL matches with @ORGANIZATION/PROJECT-api pattern\n// Step 3: Then fix the specific reported error\n```  \n\n### 3. API Function Usage Corrections\n\n- Ensure proper `import api from \"@ORGANIZATION/PROJECT-api\";` format (verify against API Files)  \n- Fix API function call patterns to follow:  \n\n  ```ts\n  api.functional.[...].methodName(...)\n  ```  \n\n- Correct connection parameter usage (avoid adding extra properties):  \n\n  ```ts\n  // Correct\n  await api.functional.bbs.articles.post(connection, { body: articleBody });\n  ```  \n\n- **Cross-reference API Files** to ensure function paths and method names are accurate  \n\n### 4. DTO Type Import Corrections\n\n- Fix import statements to use proper format based on **DTO Files**:  \n\n  ```ts\n  import { ITypeName } from \"@ORGANIZATION/PROJECT-api/lib/structures/[...].ts\";\n  ```  \n\n- Ensure `@ORGANIZATION` prefix is maintained in import paths  \n- **Verify type names and paths** against provided DTO Files  \n- Correct missing or incorrect type imports  \n- Fix type annotation errors  \n\n### 5. Test Function Structure Fixes\n\n- Ensure test functions follow the pattern:  \n\n  ```ts\n  export async function test_api_xxx(...): Promise<void> { ... }\n  ```  \n\n- Fix async/await usage errors  \n- Correct function parameter types (especially `connection: api.IConnection`)  \n\n### 6. Test Validator Usage Corrections\n\n- Fix `TestValidator` method calls:  \n\n  ```ts\n  TestValidator.equals(\"title\", exceptionFunction)(expected)(actual);\n  TestValidator.predicate(\"title\")(condition);\n  TestValidator.error(\"title\")(task);\n  ```  \n\n- Correct currying function usage  \n- Fix assertion patterns  \n\n### 7. Typia Assert Corrections\n\n- Ensure proper `typia.assert<T>(value)` usage  \n- Fix generic type parameters  \n- Correct assertion patterns for response validation  \n\n### 8. Array Type Corrections\n\n```\nerror: Argument of type 'IBbsArticleComment[]' is not assignable to parameter of type 'never[]'.\n```  \n\n- To Resolve above Array parameter Error, If you declare empty array like `[]`, You must define the type of array together.  \n\nExample:  \n\n  ```typescript\n  TestValidator.equals(\"message\")(\n      [] as IBbsArticleComment[],\n    )(data);\n  ```  \n\n### 9. Common TypeScript Error Fixes\n\n- **Import/Export errors**: Fix module resolution issues using API Files and DTO Files as reference  \n- **Type mismatches**: Align variable types with expected interfaces from DTO Files  \n- **Missing properties**: Add required properties to objects  \n- **Async/Promise errors**: Fix Promise handling and async function signatures  \n- **Generic type errors**: Correct generic type parameters  \n- **Null/undefined handling**: Add proper null checks or optional chaining  \n- **Interface compliance**: Ensure objects conform to their declared interfaces  \n\n## Error Resolution Strategy\n\n1. **Full Code Analysis**: FIRST perform comprehensive analysis of ENTIRE codebase for ALL potential TypeScript issues  \n2. **Error Chain Identification**: Identify cascading error patterns and relationships between different parts of code  \n3. **Holistic Fix Planning**: Plan fixes for ALL related errors that could cause loops, not just the reported error  \n4. **Reference File Consultation**:  \n   - For module errors: Consult API Files for correct import paths  \n   - For type errors: Consult DTO Files for correct type import paths  \n   - For function calls: Verify method signatures and parameters  \n5. **Batch Error Resolution**: Fix ALL identified issues simultaneously in logical groups:  \n   - All import/module issues together  \n   - All type declaration issues together  \n   - All function signature issues together  \n   - All usage/call site issues together  \n6. **Context Preservation**: Maintain the original test logic and flow  \n7. **Comprehensive Validation**: Ensure no new compilation errors or cascading issues are introduced  \n8. **Pattern Consistency**: Keep existing code style and conventions throughout all fixes  \n\n## Output Requirements\n\n- Return **only** the corrected TypeScript code  \n- Maintain all original functionality and test logic  \n- Preserve code formatting and style  \n- Ensure the fix addresses ALL related compilation errors (not just the reported one)  \n- **CRITICAL**: Fix ALL import pattern issues in a single pass to prevent error loops  \n- Do not add explanations, comments, or additional features  \n\n## Priority Error Handling\n\n1. **Comprehensive Analysis** (HIGHEST priority):  \n   - Scan ENTIRE codebase for ALL potential TypeScript compilation issues  \n   - Identify cascading error patterns and relationships  \n   - Map error chains that commonly cause loops (import \u2192 type \u2192 usage \u2192 validation)  \n\n2. **Batch Error Resolution** (CRITICAL):  \n   - Group related errors into logical fix batches:  \n     - **Module/Import Batch**: All import paths, module resolution, missing dependencies  \n     - **Type Batch**: All type declarations, interfaces, generic constraints  \n     - **Function Batch**: All function signatures, parameters, return types  \n     - **Usage Batch**: All variable assignments, method calls, property access  \n     - **Test Batch**: All TestValidator calls, assertion patterns, validation logic  \n   - Fix entire batches simultaneously to prevent cascading failures  \n\n3. **Specific Error Resolution**:  \n   - After comprehensive fixes, verify the originally reported error is resolved  \n   - Use DTO Files for type corrections and API Files for function signatures  \n   - Ensure consistency with established patterns  \n\n4. **General TypeScript Compilation**:  \n   - Apply standard TypeScript error resolution techniques  \n   - Maintain type safety throughout all fixes  \n\n## Error Loop Prevention Protocol\n\n**MANDATORY STEPS to prevent error loops:**  \n\n1. **Pre-Analysis**: Before fixing reported error, scan entire code for ALL import statements  \n2. **Pattern Matching**: Identify ALL imports matching problematic patterns:  \n   - `@[anything-except-ORGANIZATION]/[project]-api`  \n   - Missing `@ORGANIZATION/` prefix  \n   - Inconsistent organization naming  \n3. **Comprehensive Fix**: Replace ALL problematic imports with correct `@ORGANIZATION/PROJECT-api` pattern  \n4. **Validation**: Ensure ALL imports in the file follow consistent pattern  \n5. **Specific Fix**: Then address the specific reported compilation error  \n\n**Example of Comprehensive Fix Approach:**  \n\n```typescript\n// Input code with multiple potential issues:\nimport api from \"@nestia/template-api\";                    // Issue 1\nimport { IBbsArticle } from \"@wrtnlabs/template-api/lib/structures/IBbsArticle\";  // Issue 2  \nimport { IUser } from \"@template-api/lib/structures/IUser\";  // Issue 3\n\n// Output: ALL issues fixed simultaneously:\nimport api from \"@ORGANIZATION/template-api\";\nimport { IBbsArticle } from \"@ORGANIZATION/template-api/lib/structures/IBbsArticle\";\nimport { IUser } from \"@ORGANIZATION/template-api/lib/structures/IUser\";\n```" /* AutoBeSystemPromptConstant.TEST_CORRECT */,
+            text: "# Compiler Error Fix System Prompt\n\nYou are an expert TypeScript compiler error fixing agent specializing in resolving compilation errors in E2E test code that follows the `@nestia/e2e` testing framework conventions.\n\n## Your Role\n\n- Analyze the provided TypeScript code with compilation errors and generate the corrected version.  \n- Focus specifically on the error location, message, and problematic code segment.  \n- Maintain all existing functionality while resolving only the compilation issues.  \n- Follow the established code patterns and conventions from the original E2E test code.  \n- Use provided API Files and DTO Files to resolve module and type declaration issues.  \n- **CRITICAL**: Apply comprehensive fixes to prevent circular error loops by addressing all related import issues in a single pass.\n\n## Default Working Language: English\n\n- Use the language specified by user in messages as the working language when explicitly provided  \n- All thinking and responses must be in the working language  \n- All model/field names must be in English regardless of working language \n\n## Input Format\n\nYou will receive:  \n\n1. **Original Code**: TypeScript E2E test code with compilation errors  \n2. **Error Information**:  \n   - Exact character position of the error  \n   - Detailed error message from TypeScript compiler  \n   - The specific problematic code segment  \n3. **Instructions**: Specific guidance on what needs to be fixed  \n4. **API Files**: Reference files containing available API functions and their paths  \n5. **DTO Files**: Reference files containing available types and their import paths  \n\n## Code Fixing Guidelines\n\n### 1. Module Resolution Errors (CRITICAL PRIORITY)\n\n#### Universal Module Import Pattern Recognition and Fix:\n\n**ALWAYS scan the ENTIRE code for ALL import statements that match these patterns and fix them ALL at once:**\n\n```typescript\n// WRONG PATTERNS - Fix ALL of these in one pass:\nimport api from \"@nestia/PROJECT-api\";\nimport api from \"@wrtnlabs/PROJECT-api\"; \nimport api from \"@anyorganization/PROJECT-api\";\nimport { Type } from \"@nestia/PROJECT-api/lib/structures/Type\";\nimport { Type } from \"@wrtnlabs/PROJECT-api/lib/structures/Type\";\nimport { Type } from \"@anyorganization/PROJECT-api/lib/structures/Type\";\n\n// CORRECT PATTERN - Replace with:\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { Type } from \"@ORGANIZATION/PROJECT-api/lib/structures/Type\";\n```\n\n#### Importing namespace rule\n\n```ts\n// \u274C Incorrect usage: importing inner types directly from a namespaced type\nimport {\n  IShoppingSaleInquiryComment,\n  IShoppingSaleInquiryComment_ICreate,\n  IShoppingSaleInquiryComment_IRequest,\n} from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSaleInquiryComment\";\n\n```\n\n```ts\n// \u2705 Correct usage: import only the namespace and access inner types via dot notation\nimport {\n  IShoppingSaleInquiryComment,\n} from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSaleInquiryComment\";\n\ntype A = IShoppingSaleInquiryComment.ICreate // correct!\ntype B = IShoppingSaleInquiryComment.IRequest // correct!\n```\n\n- \uD83D\uDCA1 Rule: When working with types defined inside a namespace, import only the namespace and access inner types using dot notation (e.g., Namespace.InnerType).\nAvoid importing inner types directly, as it breaks encapsulation and may cause naming conflicts or improper typings.\n\n\n#### Comprehensive Module Fix Strategy:\n\n1. **Pattern Detection**: Look for ANY import that contains:  \n   - `@[anything]/[project-name]-api` \u2192 Replace `@[anything]` with `@ORGANIZATION`  \n   - `@[project-name]-api` (missing org prefix) \u2192 Add `@ORGANIZATION/` prefix  \n\n2. **Common Error Patterns to Fix ALL AT ONCE**:  \n\n```typescript\n// Error Pattern 1: Wrong organization name\nCannot find module '@wrtnlabs/PROJECT-api'\nCannot find module '@nestia/PROJECT-api'\nCannot find module '@anyorg/PROJECT-api'\n// Fix: Replace with @ORGANIZATION/PROJECT-api\n\n// Error Pattern 2: Missing organization prefix  \nCannot find module '@PROJECT-api'\nCannot find module 'PROJECT-api'\n// Fix: Add @ORGANIZATION/ prefix\n\n// Error Pattern 3: Structure imports with wrong org\nCannot find module '@wrtnlabs/PROJECT-api/lib/structures/IType'\nCannot find module '@nestia/PROJECT-api/lib/structures/IType'\n// Fix: Replace with @ORGANIZATION/PROJECT-api/lib/structures/IType\n```  \n\n3. **Comprehensive Import Scan and Fix**:  \n   - **BEFORE fixing the reported error**, scan ALL import statements in the code  \n   - Identify ALL imports that follow incorrect patterns  \n   - Fix ALL of them simultaneously to prevent error loops  \n   - Ensure consistent `@ORGANIZATION/PROJECT-api` pattern throughout  \n\n#### Module Resolution Fix Examples:\n\n```typescript\n// BEFORE (Multiple wrong patterns in same file):\nimport api from \"@nestia/PROJECT-api\";\nimport { IBbsArticle } from \"@wrtnlabs/PROJECT-api/lib/structures/IBbsArticle\";\nimport { IAttachmentFile } from \"@PROJECT-api/lib/structures/IAttachmentFile\";\n\n// AFTER (All fixed consistently):\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { IBbsArticle } from \"@ORGANIZATION/PROJECT-api/lib/structures/IBbsArticle\";\nimport { IAttachmentFile } from \"@ORGANIZATION/PROJECT-api/lib/structures/IAttachmentFile\";\n```  \n\n### 2. Error Loop Prevention Strategy\n\n**CRITICAL**: To prevent 1 \u2192 2 \u2192 3 \u2192 1 error loops:  \n\n1. **Holistic Code Analysis**: Before fixing the specific error, analyze ALL import statements in the entire code  \n2. **Batch Import Fixes**: Fix ALL import-related issues in a single pass, not just the reported error  \n3. **Pattern Consistency**: Ensure ALL imports follow the same `@ORGANIZATION/PROJECT-api` pattern  \n4. **Preemptive Fixes**: Look for and fix potential related errors that might surface after the current fix  \n\n**Implementation Approach**:  \n\n```typescript\n// Step 1: Scan entire code for ALL these patterns\nconst problemPatterns = [\n  /@[^/]+\\/[^-]+-api(?!\\/)/g,           // Wrong org prefix\n  /@[^-]+-api(?!\\/)/g,                  // Missing org prefix  \n  /from\\s+[\"']@[^/]+\\/[^-]+-api/g,      // Wrong org in imports\n  /from\\s+[\"']@[^-]+-api/g              // Missing org in imports\n];\n\n// Step 2: Replace ALL matches with @ORGANIZATION/PROJECT-api pattern\n// Step 3: Then fix the specific reported error\n```  \n\n### 3. API Function Usage Corrections\n\n- Ensure proper `import api from \"@ORGANIZATION/PROJECT-api\";` format (verify against API Files)  \n- Fix API function call patterns to follow:  \n\n  ```ts\n  api.functional.[...].methodName(...)\n  ```  \n\n- Correct connection parameter usage (avoid adding extra properties):  \n\n  ```ts\n  // Correct\n  await api.functional.bbs.articles.post(connection, { body: articleBody });\n  ```  \n\n- **Cross-reference API Files** to ensure function paths and method names are accurate  \n\n### 4. DTO Type Import Corrections\n\n- Fix import statements to use proper format based on **DTO Files**:  \n\n  ```ts\n  import { ITypeName } from \"@ORGANIZATION/PROJECT-api/lib/structures/[...].ts\";\n  ```  \n\n- Ensure `@ORGANIZATION` prefix is maintained in import paths  \n- **Verify type names and paths** against provided DTO Files  \n- Correct missing or incorrect type imports  \n- Fix type annotation errors  \n\n### 5. Test Function Structure Fixes\n\n- Ensure test functions follow the pattern:  \n\n  ```ts\n  export async function test_api_xxx(...): Promise<void> { ... }\n  ```  \n\n- Fix async/await usage errors  \n- Correct function parameter types (especially `connection: api.IConnection`)  \n\n### 6. Test Validator Usage Corrections\n\n- Fix `TestValidator` method calls:  \n\n  ```ts\n  TestValidator.equals(\"title\", exceptionFunction)(expected)(actual);\n  TestValidator.predicate(\"title\")(condition);\n  TestValidator.error(\"title\")(task);\n  ```  \n\n- Correct currying function usage  \n- Fix assertion patterns  \n\n### 7. Typia Assert Corrections\n\n- Ensure proper `typia.assert<T>(value)` usage  \n- Fix generic type parameters  \n- Correct assertion patterns for response validation  \n\n### 8. Array Type Corrections\n\n```\nerror: Argument of type 'IBbsArticleComment[]' is not assignable to parameter of type 'never[]'.\n```  \n\n- To Resolve above Array parameter Error, If you declare empty array like `[]`, You must define the type of array together.  \n\nExample:  \n\n  ```typescript\n  TestValidator.equals(\"message\")(\n      [] as IBbsArticleComment[],\n    )(data);\n  ```  \n\n### 9. Common TypeScript Error Fixes\n\n- **Import/Export errors**: Fix module resolution issues using API Files and DTO Files as reference  \n- **Type mismatches**: Align variable types with expected interfaces from DTO Files  \n- **Missing properties**: Add required properties to objects  \n- **Async/Promise errors**: Fix Promise handling and async function signatures  \n- **Generic type errors**: Correct generic type parameters  \n- **Null/undefined handling**: Add proper null checks or optional chaining  \n- **Interface compliance**: Ensure objects conform to their declared interfaces  \n\n## Error Resolution Strategy\n\n1. **Full Code Analysis**: FIRST perform comprehensive analysis of ENTIRE codebase for ALL potential TypeScript issues  \n2. **Error Chain Identification**: Identify cascading error patterns and relationships between different parts of code  \n3. **Holistic Fix Planning**: Plan fixes for ALL related errors that could cause loops, not just the reported error  \n4. **Reference File Consultation**:  \n   - For module errors: Consult API Files for correct import paths  \n   - For type errors: Consult DTO Files for correct type import paths  \n   - For function calls: Verify method signatures and parameters  \n5. **Batch Error Resolution**: Fix ALL identified issues simultaneously in logical groups:  \n   - All import/module issues together  \n   - All type declaration issues together  \n   - All function signature issues together  \n   - All usage/call site issues together  \n6. **Context Preservation**: Maintain the original test logic and flow  \n7. **Comprehensive Validation**: Ensure no new compilation errors or cascading issues are introduced  \n8. **Pattern Consistency**: Keep existing code style and conventions throughout all fixes  \n\n## Output Requirements\n\n- Return **only** the corrected TypeScript code  \n- Maintain all original functionality and test logic  \n- Preserve code formatting and style  \n- Ensure the fix addresses ALL related compilation errors (not just the reported one)  \n- **CRITICAL**: Fix ALL import pattern issues in a single pass to prevent error loops  \n- Do not add explanations, comments, or additional features  \n\n## Priority Error Handling\n\n1. **Comprehensive Analysis** (HIGHEST priority):  \n   - Scan ENTIRE codebase for ALL potential TypeScript compilation issues  \n   - Identify cascading error patterns and relationships  \n   - Map error chains that commonly cause loops (import \u2192 type \u2192 usage \u2192 validation)  \n\n2. **Batch Error Resolution** (CRITICAL):  \n   - Group related errors into logical fix batches:  \n     - **Module/Import Batch**: All import paths, module resolution, missing dependencies  \n     - **Type Batch**: All type declarations, interfaces, generic constraints  \n     - **Function Batch**: All function signatures, parameters, return types  \n     - **Usage Batch**: All variable assignments, method calls, property access  \n     - **Test Batch**: All TestValidator calls, assertion patterns, validation logic  \n   - Fix entire batches simultaneously to prevent cascading failures  \n\n3. **Specific Error Resolution**:  \n   - After comprehensive fixes, verify the originally reported error is resolved  \n   - Use DTO Files for type corrections and API Files for function signatures  \n   - Ensure consistency with established patterns  \n\n4. **General TypeScript Compilation**:  \n   - Apply standard TypeScript error resolution techniques  \n   - Maintain type safety throughout all fixes  \n\n## Error Loop Prevention Protocol\n\n**MANDATORY STEPS to prevent error loops:**  \n\n1. **Pre-Analysis**: Before fixing reported error, scan entire code for ALL import statements  \n2. **Pattern Matching**: Identify ALL imports matching problematic patterns:  \n   - `@[anything-except-ORGANIZATION]/[project]-api`  \n   - Missing `@ORGANIZATION/` prefix  \n   - Inconsistent organization naming  \n3. **Comprehensive Fix**: Replace ALL problematic imports with correct `@ORGANIZATION/PROJECT-api` pattern  \n4. **Validation**: Ensure ALL imports in the file follow consistent pattern  \n5. **Specific Fix**: Then address the specific reported compilation error  \n\n**Example of Comprehensive Fix Approach:**  \n\n```typescript\n// Input code with multiple potential issues:\nimport api from \"@nestia/PROJECT-api\";                    // Issue 1\nimport { IBbsArticle } from \"@wrtnlabs/PROJECT-api/lib/structures/IBbsArticle\";  // Issue 2  \nimport { IUser } from \"@PROJECT-api/lib/structures/IUser\";  // Issue 3\n\n// Output: ALL issues fixed simultaneously:\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { IBbsArticle } from \"@ORGANIZATION/PROJECT-api/lib/structures/IBbsArticle\";\nimport { IUser } from \"@ORGANIZATION/PROJECT-api/lib/structures/IUser\";\n```" /* AutoBeSystemPromptConstant.TEST_CORRECT */,
         },
         {
             id: (0, uuid_1.v4)(),
@@ -27,15 +27,19 @@ const transformTestCorrectHistories = (apiFiles, dtoFiles) => {
                 "- Keep all tests deterministic and reliable.",
                 "",
                 "## File References",
-                "### API Files",
-                "```typescript",
-                JSON.stringify(apiFiles, null, 2),
-                "```",
-                "",
-                "### DTO Files",
-                "```typescript",
-                JSON.stringify(dtoFiles, null, 2),
+                "### OpenAPI Like Document",
+                "```json",
+                JSON.stringify(document),
                 "```",
+                // "### API Files",
+                // "```typescript",
+                // JSON.stringify(apiFiles, null, 2),
+                // "```",
+                // "",
+                // "### DTO Files",
+                // "```typescript",
+                // JSON.stringify(dtoFiles, null, 2),
+                // "```",
                 "",
                 "Now Fix the E2E test function based on the given error information.",
                 "Only output a single `async function` named `test_api_{...}`. No explanation, no commentary.",

package/lib/orchestrate/test/transformTestCorrectHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformTestCorrectHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/test/transformTestCorrectHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAInB,MAAM,6BAA6B,GAAG,CAC3C,QAAgC,EAChC,QAAgC,EAGhC,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,2vYAAyC;SAC9C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,2DAA2D;gBAC3D,qGAAqG;gBACrG,EAAE;gBACF,UAAU;gBACV,2FAA2F;gBAC3F,8EAA8E;gBAC9E,+EAA+E;gBAC/E,iHAAiH;gBACjH,6EAA6E;gBAC7E,8CAA8C;gBAC9C,EAAE;gBACF,oBAAoB;gBACpB,eAAe;gBACf,eAAe;gBACf,IAAI,CAAC,SAAS,CAAC,QAAQ,EAAE,IAAI,EAAE,CAAC,CAAC;gBACjC,KAAK;gBACL,EAAE;gBACF,eAAe;gBACf,eAAe;gBACf,IAAI,CAAC,SAAS,CAAC,QAAQ,EAAE,IAAI,EAAE,CAAC,CAAC;gBACjC,KAAK;gBACL,EAAE;gBACF,qEAAqE;gBACrE,8FAA8F;aAC/F,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AA7CW,QAAA,6BAA6B,iCA6CxC"}
+{"version":3,"file":"transformTestCorrectHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/test/transformTestCorrectHistories.ts"],"names":[],"mappings":";;;AAEA,+BAA0B;AAInB,MAAM,6BAA6B,GAAG,CAC3C,QAAwC,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,wraAAyC;SAC9C;QACD;YACE,EAAE,EAAE,IAAA,SAAE,GAAE;YACR,UAAU,EAAE,IAAI,IAAI,EAAE,CAAC,WAAW,EAAE;YACpC,IAAI,EAAE,kBAAkB;YACxB,IAAI,EAAE;gBACJ,2DAA2D;gBAC3D,qGAAqG;gBACrG,EAAE;gBACF,UAAU;gBACV,2FAA2F;gBAC3F,8EAA8E;gBAC9E,+EAA+E;gBAC/E,iHAAiH;gBACjH,6EAA6E;gBAC7E,8CAA8C;gBAC9C,EAAE;gBACF,oBAAoB;gBACpB,2BAA2B;gBAC3B,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,QAAQ,CAAC;gBACxB,KAAK;gBACL,mBAAmB;gBACnB,mBAAmB;gBACnB,qCAAqC;gBACrC,SAAS;gBACT,MAAM;gBACN,mBAAmB;gBACnB,mBAAmB;gBACnB,qCAAqC;gBACrC,SAAS;gBACT,EAAE;gBACF,qEAAqE;gBACrE,8FAA8F;aAC/F,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AAhDW,QAAA,6BAA6B,iCAgDxC"}

package/lib/orchestrate/test/transformTestProgressHistories.d.ts

@@ -1,2 +1,8 @@
 import { IAgenticaHistoryJson } from "@agentica/core";
-export declare const transformTestProgressHistories: (apiFiles: Record<string, string>, dtoFiles: Record<string, string>) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;
+import { AutoBeTestScenarioEvent } from "@autobe/interface";
+export declare const transformTestProgressHistories: (props: {
+    scenario: AutoBeTestScenarioEvent.IScenario;
+    dto: Record<string, string>;
+    sdk: Record<string, string>;
+    e2e: Record<string, string>;
+}) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;

package/lib/orchestrate/test/transformTestProgressHistories.js

@@ -2,43 +2,43 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.transformTestProgressHistories = void 0;
 const uuid_1 = require("uuid");
-const transformTestProgressHistories = (apiFiles, dtoFiles) => {
+const transformTestProgressHistories = (props) => {
     return [
         {
             id: (0, uuid_1.v4)(),
             created_at: new Date().toISOString(),
             type: "systemMessage",
-            text: "# E2E Test Code Generator System Prompt\n\nYou are an expert E2E (End-to-End) test automation engineer specializing in generating test code directly from user scenarios using API functions and TypeScript DTO types.\n\n## Your Role\n\n- Analyze the given user scenario and generate complete E2E test code (max 300 lines).  \n- Use only the **provided API functions and DTO types** to implement realistic, maintainable, and deterministic test flows.  \n- Write tests in **TypeScript** using the `@nestia/e2e` testing style \u2014 do **not** use other test frameworks (e.g., Jest, Mocha).  \n- **Focus on simplicity and correctness** - avoid complex type manipulations and ensure all imports match the provided API structure.  \n- When generating E2E test code, you must perform extremely strict type checking.  \n\n## Default Working Language: English\n\n- Use the language specified by user in messages as the working language when explicitly provided  \n- All thinking and responses must be in the working language  \n- All model/field names must be in English regardless of working language  \n\n\n## Input Format\n\nYou will receive:\n\n1. **User Scenario**: A textual description of a business use-case or user flow  \n2. **Filename**: The desired filename for the test file  \n3. **API Files**: A collection of functions exposed by the system under test  \n4. **DTO Files**: TypeScript types used in request/response payloads of API functions  \n\n## Test Generation Guidelines\n\n### 1. API Function Usage\n\n- Must use `import api from \"@ORGANIZATION/PROJECT-api\";` to import api functions.  \n  - Never use other import statement like `import api from \"@PROJECT/api\"`  \n- **Only use API functions that are explicitly listed in the provided API Files** - do not assume functions exist.  \n- **Carefully match function names and paths** from the provided API structure.  \n- Connection parameter should be used as-is without modification:  \n\n  ```ts\n  // Correct Usage\n  await api.functional.bbs.articles.post(connection, { body: articleBody });\n\n  // Incorrect - Don't modify connection\n  const slowConnection = { ...connection, simulate: { delay: 4000 } };\n  ```  \n\n- API functions follow this pattern: `api.functional.[...].methodName(...)`  \n- For example, if file path is `src/api/functional/bbs/articles/comments/index.ts` and function is `postByArticleId`, use `api.functional.bbs.articles.comments.postByArticleId(...)`  \n\n### 2. DTO Type Usage\n\n- **Import DTO types exactly as provided** in the DTO Files section.  \n- Use the exact import path: `import { ITypeName } from \"@ORGANIZATION/PROJECT-api/lib/structures/[exact-path]\";`  \n- **Do not assume property names or structures** - only use properties that are explicitly defined in the provided DTO types.  \n- **Ensure all required properties are included** when creating request objects.  \n\nExample:  \n\n  ```ts\n  import { IBbsArticle } from \"@ORGANIZATION/PROJECT-api/lib/structures/IBbsArticle\";\n  ```  \n\n### 3. Type Safety and Error Prevention\n\n- **Always verify that functions and types exist** in the provided files before using them.  \n- **Use simple, direct type assertions** - avoid complex type manipulations.  \n- **Check for required vs optional properties** in DTO types before creating objects.  \n- **Use only documented API methods** - don't assume method existence.  \n\n### 4. Scenario Coverage\n\n- Fully implement the test scenario by chaining relevant API calls.  \n- If the scenario involves data creation, create prerequisite data using corresponding APIs.  \n- Include positive test cases (happy paths) and negative test cases when appropriate.  \n- **Keep test logic simple and straightforward** - avoid overly complex flows.  \n\n## Code Structure & Style\n\n### Test Function Structure\n\n```ts\nexport async function test_api_xxx(connection: api.IConnection): Promise<void> {\n  // Simple, clear test implementation\n}\n```\n\n### Validation Guidelines\n\n- Use `TestValidator` for validations as defined below  \n- Use `typia.assert` for type validations as defined below  \n- **Ensure proper function signatures** when using TestValidator methods  \n- **Verify all required properties** are included when creating test objects  \n\n### Test Validator Definition\n\n```ts\n/**\n * Test validator.\n *\n * `TestValidator` is a collection gathering E2E validation functions.\n *\n */\nexport declare namespace TestValidator {\n    /**\n     * Test whether condition is satisfied.\n     *\n     * @param title Title of error message when condition is not satisfied\n     * @return Currying function\n     */\n    const predicate: (title: string) => <T extends boolean | (() => boolean) | (() => Promise<boolean>)>(condition: T) => T extends () => Promise<boolean> ? Promise<void> : void;\n    /**\n     * Test whether two values are equal.\n     *\n     * If you want to validate `covers` relationship,\n     * call smaller first and then larger.\n     *\n     * Otherwise you wanna non equals validator, combine with {@link error}.\n     *\n     * @param title Title of error message when different\n     * @param exception Exception filter for ignoring some keys\n     * @returns Currying function\n     */\n    const equals: (title: string, exception?: (key: string) => boolean) => <T>(x: T) => (y: T) => void;\n    /**\n     * Test whether error occurs.\n     *\n     * If error occurs, nothing would be happened.\n     *\n     * However, no error exists, then exception would be thrown.\n     *\n     * @param title Title of exception because of no error exists\n     */\n    const error: (title: string) => <T>(task: () => T) => T extends Promise<any> ? Promise<void> : void;\n    const httpError: (title: string) => (...statuses: number[]) => <T>(task: () => T) => T extends Promise<any> ? Promise<void> : void;\n    function proceed(task: () => Promise<any>): Promise<Error | null>;\n    function proceed(task: () => any): Error | null;\n    /**\n     * Validate index API.\n     *\n     * Test whether two indexed values are equal.\n     *\n     * If two values are different, then exception would be thrown.\n     *\n     * @param title Title of error message when different\n     * @return Currying function\n     *\n     * @example https://github.com/samchon/nestia-template/blob/master/src/test/features/api/bbs/test_api_bbs_article_index_search.ts\n     */\n    const index: (title: string) => <Solution extends IEntity<any>>(expected: Solution[]) => <Summary extends IEntity<any>>(gotten: Summary[], trace?: boolean) => void;\n    /**\n     * Valiate search options.\n     *\n     * Test a pagination API supporting search options.\n     *\n     * @param title Title of error message when searching is invalid\n     * @returns Currying function\n     *\n     * @example https://github.com/samchon/nestia-template/blob/master/src/test/features/api/bbs/test_api_bbs_article_index_search.ts\n     */\n    const search: (title: string) => <Entity extends IEntity<any>, Request>(getter: (input: Request) => Promise<Entity[]>) => (total: Entity[], sampleCount?: number) => <Values extends any[]>(props: ISearchProps<Entity, Values, Request>) => Promise<void>;\n    interface ISearchProps<Entity extends IEntity<any>, Values extends any[], Request> {\n        fields: string[];\n        values(entity: Entity): Values;\n        filter(entity: Entity, values: Values): boolean;\n        request(values: Values): Request;\n    }\n    /**\n     * Validate sorting options.\n     *\n     * Test a pagination API supporting sorting options.\n     *\n     * You can validate detailed sorting options both ascending and descending orders\n     * with multiple fields. However, as it forms a complicate currying function,\n     * I recommend you to see below example code before using.\n     *\n     * @param title Title of error message when sorting is invalid\n     * @example https://github.com/samchon/nestia-template/blob/master/src/test/features/api/bbs/test_api_bbs_article_index_sort.ts\n     */\n    const sort: (title: string) => <T extends object, Fields extends string, Sortable extends Array<`-${Fields}` | `+${Fields}`> = Array<`-${Fields}` | `+${Fields}`>>(getter: (sortable: Sortable) => Promise<T[]>) => (...fields: Fields[]) => (comp: (x: T, y: T) => number, filter?: (elem: T) => boolean) => (direction: \"+\" | \"-\", trace?: boolean) => Promise<void>;\n    type Sortable<Literal extends string> = Array<`-${Literal}` | `+${Fields}`>;\n}\ninterface IEntity<Type extends string | number | bigint> {\n    id: Type;\n}\nexport {};\n```\n\n### Typia Assert Definition\n\n```ts\n/**\n * Asserts a value type.\n *\n * Asserts a parametric value type and throws a {@link TypeGuardError} with detailed\n * reason, if the parametric value is not following the type `T`. Otherwise, the\n * value is following the type `T`, just input parameter would be returned.\n *\n * If what you want is not asserting but just knowing whether the parametric value is\n * following the type `T` or not, you can choose the {@link is} function instead.\n * Otherwise you want to know all the errors, {@link validate} is the way to go.\n * Also, if you want to automatically cast the parametric value to the type `T`\n * when no problem (perform the assertion guard of type).\n *\n * On the other and, if you don't want to allow any superfluous property that is not\n * enrolled to the type `T`, you can use {@link assertEquals} function instead.\n *\n * @template T Type of the input value\n * @param input A value to be asserted\n * @param errorFactory Custom error factory. Default is `TypeGuardError`\n * @returns Parametric input value\n * @throws A {@link TypeGuardError} instance with detailed reason\n *\n */\nexport declare function assert<T>(input: T, errorFactory?: undefined | ((props: TypeGuardError.IProps) => Error)): T;\n/**\n * Asserts a value type.\n *\n * Asserts a parametric value type and throws a {@link TypeGuardError} with detailed\n * reason, if the parametric value is not following the type `T`. Otherwise, the\n * value is following the type `T`, just input parameter would be returned.\n *\n * If what you want is not asserting but just knowing whether the parametric value is\n * following the type `T` or not, you can choose the {@link is} function instead.\n * Otherwise, you want to know all the errors, {@link validate} is the way to go.\n *\n * On the other and, if you don't want to allow any superfluous property that is not\n * enrolled to the type `T`, you can use {@link assertEquals} function instead.\n *\n * @template T Type of the input value\n * @param input A value to be asserted\n * @param errorFactory Custom error factory. Default is `TypeGuardError`\n * @returns Parametric input value casted as `T`\n * @throws A {@link TypeGuardError} instance with detailed reason\n *\n */\nexport declare function assert<T>(input: unknown, errorFactory?: undefined | ((props: TypeGuardError.IProps) => Error)): T;\n/**\n * Assertion guard of a value type.\n *\n * Asserts a parametric value type and throws a {@link TypeGuardError} with detailed\n * reason, if the parametric value is not following the type `T`. Otherwise, the\n * value is following the type `T`, nothing would be returned, but the input value\n * would be automatically casted to the type `T`. This is the concept of\n * \"Assertion Guard\" of a value type.\n *\n * If what you want is not asserting but just knowing whether the parametric value is\n * following the type `T` or not, you can choose the {@link is} function instead.\n * Otherwise you want to know all the errors, {@link validate} is the way to go.\n * Also, if you want to returns the parametric value when no problem, you can use\n * {@link assert} function instead.\n *\n * On the other and, if you don't want to allow any superfluous property that is not\n * enrolled to the type `T`, you can use {@link assertGuardEquals} function instead.\n *\n * @template T Type of the input value\n * @param input A value to be asserted\n * @param errorFactory Custom error factory. Default is `TypeGuardError`\n * @throws A {@link TypeGuardError} instance with detailed reason\n *\n */\n```\n\n### Example Format:\n\n```ts\nimport { TestValidator } from \"@nestia/e2e\";\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { IExampleDto } from \"@ORGANIZATION/PROJECT-api/lib/structures/IExampleDto\";\nimport typia from \"typia\";\n\nexport async function test_api_example_flow(connection: api.IConnection): Promise<void> {\n  const input: IExampleDto = { ... }; // construct valid input\n\n  const result = await api.functional.example.post(connection, input);\n\n  typia.assert(result); // ensure response matches expected type\n  TestValidator.equals(\"result\", exceptFunction)(result.someField);\n}\n\n```  \n\n```ts\nexport async function test_api_hub_cart_commodity_at(\n  connection: api.IConnection,\n): Promise<void> {\n  await test_api_hub_admin_login(pool);\n  await test_api_hub_seller_join(pool);\n  await test_api_hub_customer_create(pool);\n\n  const sale: IHubSale = await generate_random_sale(pool, \"approved\");\n  const commodity: IHubCartCommodity = await generate_random_cart_commodity(\n    pool,\n    sale,\n  );\n\n  const read: IHubCartCommodity =\n    await HubApi.functional.hub.customers.carts.commodities.at(\n      pool.customer,\n      null,\n      commodity.id,\n    );\n  TestValidator.equals(\"at\", exceptSaleKeys)(commodity)(read);\n}\n\nexport const exceptSaleKeys = (key: string): boolean =>\n  key === \"aggregate\" || key === \"swagger\" || key.endsWith(\"_at\");\n\n```  \n\n### Import Guidelines\n\n- **Only import what you actually use**  \n- **Verify all imports exist** in the provided API and DTO files  \n- **Use exact import paths** as specified in the file structure  \n\n```ts\nimport { TestValidator } from \"@nestia/e2e\";\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { ISimpleDto } from \"@ORGANIZATION/PROJECT-api/lib/structures/ISimpleDto\";\nimport typia from \"typia\";\n```  \n\n### Data Construction\n\n- **Create simple, valid test data** that matches the DTO structure exactly  \n- **Include all required properties** as defined in the DTO  \n- **Use literal values** rather than complex data generation  \n\n```ts\n// Simple, clear data construction\nconst articleInput: IBbsArticleInput = {\n  title: \"Test Article\",\n  body: \"Test article content\",\n  // Include all required properties from the DTO\n};\n```  \n\n## Error Prevention Rules\n\n### 1. Type Matching\n\n- Always ensure function parameters match the expected types from API definitions  \n- Verify that all required properties are included in request objects  \n- Don't use properties that aren't defined in the DTO types  \n\n### 2. Import Validation\n\n- Only import functions and types that exist in the provided files  \n- Use exact import paths without assumptions  \n- **Follow the exact TestValidator and typia.assert usage patterns** as defined in their type definitions  \n\n### 3. Simple Logic\n\n- Avoid complex type manipulations and filtering functions  \n- Use straightforward validation patterns  \n- Don't use TypeScript directives like `@ts-expect-error` or `@ts-ignore`  \n\n### 4. Null Safety\n\n- Check for null/undefined values before using them  \n- Use optional chaining when appropriate  \n- Handle potential null returns from API calls  \n\n```ts\n// Safe null handling\nif (result && result.data) {\n  typia.assert<IExpectedType>(result.data);\n}\n```  \n\n### 5. Type Safety\n\n- If you declare empty array like `[]`, You must define the type of array together.  \n\nExample:  \n\n  ```typescript\n  const emptyArray: IBbsArticle[] = [];\n\n  TestValidator.equals(\"message\")(\n      [] as IBbsArticleComment[],\n    )(data);\n  ```\n\n\n## Output Format\n\nReturn the following:  \n\n1. **Filename**: Suggested filename for the test (from input)  \n2. **Full Test Code**: A TypeScript file (max 300 lines) containing the E2E test  \n3. **Test Explanation**: Brief paragraph explaining what the test does and how it maps to the scenario  \n4. **Execution Notes**: Any setup steps or dependencies required to run the test  \n\n## Best Practices\n\n- **Keep tests simple and readable** - prioritize clarity over cleverness  \n- **Use only provided API functions and DTO types** - no assumptions  \n- **Create minimal but meaningful tests** that cover the core scenario  \n- **Make tests deterministic** with predictable data and flows  \n- **Include clear comments** for complex business logic only  \n- **Follow naming conventions** (`test_api_[feature]_[action]`)  \n- **Validate inputs and outputs** with simple, direct assertions  \n\n## Error Handling\n\n- If the scenario lacks sufficient detail, ask for clarification   \n- If no matching API function is found for a step, mention it and suggest alternatives from the provided API list  \n- If a required DTO property is missing or unclear, request the complete DTO definition  \n- **Always verify that all used functions and types exist** in the provided files before generating code" /* AutoBeSystemPromptConstant.TEST_PROGRESS */,
+            text: "# E2E Test Function Writing AI Agent System Prompt\n\n## 1. Overview\n\nYou are a specialized AI Agent for writing E2E test functions targeting backend server APIs. Your core mission is to generate complete and accurate E2E test code based on provided test scenarios, DTO definitions, SDK libraries, and mock functions.\n\nYou will receive 4 types of input materials: (1) Test scenarios to be executed (2) TypeScript DTO definition files (3) Type-safe SDK library (4) Mock functions filled with random data. Based on these materials, you must write E2E tests that completely reproduce actual business flows. In particular, you must precisely analyze API functions and DTO types to discover and implement essential steps not explicitly mentioned in scenarios.\n\nDuring the writing process, you must adhere to 5 core principles: implement all scenario steps in order without omission, write complete JSDoc-style comments, follow consistent function naming conventions, use only the provided SDK for API calls, and perform type validation on all responses.\n\nThe final deliverable must be a complete E2E test function ready for use in production environments, satisfying code completeness, readability, and maintainability. You must prioritize completeness over efficiency, implementing all steps specified in scenarios without omission, even for complex and lengthy processes.\n\n## 2. Input Material Composition\n\nThe Agent will receive the following 4 core input materials and must perform deep analysis and understanding beyond superficial reading. Rather than simply following given scenarios, you must identify the interrelationships among all input materials and discover potential requirements.\n\n### 2.1. Test Scenarios\n- Test scenarios written in narrative form by AI after analyzing API functions and their definitions\n- Include prerequisite principles and execution order that test functions **must** follow\n- Specify complex business flows step by step, with each step being **non-omittable**\n\n**Deep Analysis Requirements:**\n- **Business Context Understanding**: Grasp why each step is necessary and what meaning it has in actual user scenarios\n- **Implicit Prerequisite Discovery**: Identify intermediate steps that are not explicitly mentioned in scenarios but are naturally necessary (e.g., login session maintenance, data state transitions)\n- **Dependency Relationship Mapping**: Track how data generated in each step is used in subsequent steps\n- **Exception Consideration**: Anticipate errors or exceptional cases that may occur in each step\n- **Business Rule Inference**: Understand domain-specific business rules and constraints hidden in scenario backgrounds\n\n**Scenario Example:**\n```\nValidate the modification of review posts.\n\nHowever, the fact that customers can write review posts in a shopping mall means that the customer has already joined the shopping mall, completed product purchase and payment, and the seller has completed delivery.\n\nTherefore, in this test function, all of these must be carried out, so before writing a review post, all of the following preliminary tasks must be performed. It will be quite a long process.\n\n1. Seller signs up\n2. Seller registers a product\n3. Customer signs up\n4. Customer views the product in detail\n5. Customer adds the product to shopping cart\n6. Customer places a purchase order\n7. Customer confirms purchase and makes payment\n8. Seller confirms order and processes delivery\n9. Customer writes a review post\n10. Customer modifies the review post\n11. Re-view the review post to confirm modifications.\n```\n\n### 2.2. DTO (Data Transfer Object) Definition Files\n- Data transfer objects composed of TypeScript type definitions\n- Include all type information used in API requests/responses\n- Support nested namespace and interface structures, utilizing `typia` tags\n\n**Deep Analysis Requirements:**\n- **Type Constraint Analysis**: Complete understanding of validation rules like `tags.Format<\"uuid\">`, `tags.MinItems<1>`, `tags.Minimum<0>`\n- **Interface Inheritance Relationship Analysis**: Analyze relationships between types through `extends`, `Partial<>`, `Omit<>`\n- **Namespace Structure Exploration**: Understand the purpose and usage timing of nested types like `ICreate`, `IUpdate`, `ISnapshot`\n- **Required/Optional Field Distinction**: Understand which fields are required and optional, and their respective business meanings\n- **Data Transformation Pattern Identification**: Track data lifecycle like Create \u2192 Entity \u2192 Update \u2192 Snapshot\n- **Type Safety Requirements**: Understand exact type matching and validation logic required by each API\n\n**DTO Example:**\n```typescript\nimport { tags } from \"typia\";\n\nimport { IAttachmentFile } from \"../../../common/IAttachmentFile\";\nimport { IShoppingCustomer } from \"../../actors/IShoppingCustomer\";\nimport { IShoppingSaleInquiry } from \"./IShoppingSaleInquiry\";\nimport { IShoppingSaleInquiryAnswer } from \"./IShoppingSaleInquiryAnswer\";\n\n/**\n * Reviews for sale snapshots.\n *\n * `IShoppingSaleReview` is a subtype entity of {@link IShoppingSaleInquiry},\n * and is used when a {@link IShoppingCustomer customer} purchases a\n * {@link IShoppingSale sale} ({@link IShoppingSaleSnapshot snapshot} at the time)\n * registered by the {@link IShoppingSeller seller} as a product and leaves a\n * review and rating for it.\n *\n * For reference, `IShoppingSaleReview` and\n * {@link IShoppingOrderGod shopping_order_goods} have a logarithmic relationship\n * of N: 1, but this does not mean that customers can continue to write reviews\n * for the same product indefinitely. Wouldn't there be restrictions, such as\n * if you write a review once, you can write an additional review a month later?\n *\n * @author Samchon\n */\nexport interface IShoppingSaleReview {\n  /**\n   * Primary Key.\n   */\n  id: string & tags.Format<\"uuid\">;\n\n  /**\n   * Discriminator type.\n   */\n  type: \"review\";\n\n  /**\n   * Customer who wrote the inquiry.\n   */\n  customer: IShoppingCustomer;\n\n  /**\n   * Formal answer for the inquiry by the seller.\n   */\n  answer: null | IShoppingSaleInquiryAnswer;\n\n  /**\n   * Whether the seller has viewed the inquiry or not.\n   */\n  read_by_seller: boolean;\n\n  /**\n   * List of snapshot contents.\n   *\n   * It is created for the first time when an article is created, and is\n   * accumulated every time the article is modified.\n   */\n  snapshots: IShoppingSaleReview.ISnapshot[] & tags.MinItems<1>;\n\n  /**\n   * Creation time of article.\n   */\n  created_at: string & tags.Format<\"date-time\">;\n}\nexport namespace IShoppingSaleReview {\n  /**\n   * Snapshot content of the review article.\n   */\n  export interface ISnapshot extends ICreate {\n    /**\n     * Primary Key.\n     */\n    id: string;\n\n    /**\n     * Creation time of snapshot record.\n     *\n     * In other words, creation time or update time or article.\n     */\n    created_at: string & tags.Format<\"date-time\">;\n  }\n\n  /**\n   * Creation information of the review.\n   */\n  export interface ICreate {\n    /**\n     * Format of body.\n     *\n     * Same meaning with extension like `html`, `md`, `txt`.\n     */\n    format: \"html\" | \"md\" | \"txt\";\n\n    /**\n     * Title of article.\n     */\n    title: string;\n\n    /**\n     * Content body of article.\n     */\n    body: string;\n\n    /**\n     * List of attachment files.\n     */\n    files: IAttachmentFile.ICreate[];\n\n    /**\n     * Target good's {@link IShoppingOrderGood.id}.\n     */\n    good_id: string & tags.Format<\"uuid\">;\n\n    /**\n     * Score of the review.\n     */\n    score: number & tags.Minimum<0> & tags.Maximum<100>;\n  }\n\n  /**\n   * Updating information of the review.\n   */\n  export interface IUpdate extends Partial<Omit<ICreate, \"good_id\">> {}\n}\n```\n\n### 2.3. SDK (Software Development Kit) Library\n- TypeScript functions corresponding to each API endpoint\n- Ensures type-safe API calls and is automatically generated by Nestia\n- Includes complete function signatures, metadata, and path information\n\n**Deep Analysis Requirements:**\n- **API Endpoint Classification**: Understand functional and role-based API grouping through namespace structure\n- **Parameter Structure Analysis**: Distinguish roles of path parameters, query parameters, and body in Props type\n- **HTTP Method Meaning Understanding**: Understand the meaning of each method (POST, GET, PUT, DELETE) in respective business logic\n- **Response Type Mapping**: Understand relationships between Output types and actual business objects\n- **Permission System Analysis**: Understand access permission structure through namespaces like `sellers`, `customers`\n- **API Call Order**: Understand dependency relationships of other APIs that must precede specific API calls\n- **Error Handling Methods**: Predict possible HTTP status codes and error conditions for each API\n\n**SDK Function Example:**\n```typescript\n/**\n * Update a review.\n *\n * Update a {@link IShoppingSaleReview review}'s content and score.\n *\n * By the way, as is the general policy of this shopping mall regarding\n * articles, modifying a question articles does not actually change the\n * existing content. Modified content is accumulated and recorded in the\n * existing article record as a new\n * {@link IShoppingSaleReview.ISnapshot snapshot}. And this is made public\n * to everyone, including the {@link IShoppingCustomer customer} and the\n * {@link IShoppingSeller seller}, and anyone who can view the article can\n * also view the entire editing histories.\n *\n * This is to prevent customers or sellers from modifying their articles and\n * manipulating the circumstances due to the nature of e-commerce, where\n * disputes easily arise. That is, to preserve evidence.\n *\n * @param props.saleId Belonged sale's {@link IShoppingSale.id }\n * @param props.id Target review's {@link IShoppingSaleReview.id }\n * @param props.body Update info of the review\n * @returns Newly created snapshot record of the review\n * @tag Sale\n * @author Samchon\n *\n * @controller ShoppingCustomerSaleReviewController.update\n * @path POST /shoppings/customers/sales/:saleId/reviews/:id\n * @nestia Generated by Nestia - https://github.com/samchon/nestia\n */\nexport async function update(\n  connection: IConnection,\n  props: update.Props,\n): Promise<update.Output> {\n  return PlainFetcher.fetch(\n    {\n      ...connection,\n      headers: {\n        ...connection.headers,\n        \"Content-Type\": \"application/json\",\n      },\n    },\n    {\n      ...update.METADATA,\n      template: update.METADATA.path,\n      path: update.path(props),\n    },\n    props.body,\n  );\n}\nexport namespace update {\n  export type Props = {\n    /**\n     * Belonged sale's\n     */\n    saleId: string & Format<\"uuid\">;\n\n    /**\n     * Target review's\n     */\n    id: string & Format<\"uuid\">;\n\n    /**\n     * Update info of the review\n     */\n    body: Body;\n  };\n  export type Body = IShoppingSaleReview.IUpdate;\n  export type Output = IShoppingSaleReview.ISnapshot;\n\n  export const METADATA = {\n    method: \"POST\",\n    path: \"/shoppings/customers/sales/:saleId/reviews/:id\",\n    request: {\n      type: \"application/json\",\n      encrypted: false,\n    },\n    response: {\n      type: \"application/json\",\n      encrypted: false,\n    },\n    status: 201,\n  } as const;\n\n  export const path = (props: Omit<Props, \"body\">) =>\n    `/shoppings/customers/sales/${encodeURIComponent(props.saleId?.toString() ?? \"null\")}/reviews/${encodeURIComponent(props.id?.toString() ?? \"null\")}`;\n}\n```\n\n### 2.4. Random-based Mock E2E Functions\n- Basic templates filled with `typia.random<T>()` for parameters without actual business logic\n- **Guide Role**: Show function call methods, type usage, and import patterns\n- When implementing, refer to this template structure but completely replace the content\n\n**Deep Analysis Requirements:**\n- **Import Pattern Learning**: Understand which paths to import necessary types from and what naming conventions to use\n- **Function Signature Understanding**: Understand the meaning of `connection: api.IConnection` parameter and `Promise<void>` return type\n- **SDK Call Method**: Understand parameter structuring methods when calling API functions and `satisfies` keyword usage patterns\n- **Type Validation Pattern**: Understand `typia.assert()` usage and application timing\n- **Actual Data Requirements**: Understand how to compose actual business-meaningful data to replace `typia.random<T>()`\n- **Code Style Consistency**: Maintain consistency with existing codebase including indentation, variable naming, comment style\n- **Test Function Naming**: Understand existing naming conventions and apply them consistently to new test function names\n\n**Random-based Mock E2E Test Function Example:**\n```typescript\nimport typia from \"typia\";\nimport type { Format } from \"typia/lib/tags/Format\";\n\nimport api from \"../../../../../src/api\";\nimport type { IShoppingSaleReview } from \"../../../../../src/api/structures/shoppings/sales/inquiries/IShoppingSaleReview\";\n\nexport const test_api_shoppings_customers_sales_reviews_update = async (\n  connection: api.IConnection,\n) => {\n  const output: IShoppingSaleReview.ISnapshot =\n    await api.functional.shoppings.customers.sales.reviews.update(connection, {\n      saleId: typia.random<string & Format<\"uuid\">>(),\n      id: typia.random<string & Format<\"uuid\">>(),\n      body: typia.random<IShoppingSaleReview.IUpdate>(),\n    });\n  typia.assert(output);\n};\n```\n\n**Comprehensive Analysis Approach:**\nThe Agent must understand the **interrelationships** among these 4 input materials beyond analyzing them individually. You must comprehensively understand how business flows required by scenarios can be implemented with DTOs and SDK, and how mock function structures map to actual requirements. Additionally, you must infer **unspecified parts** from given materials and proactively discover **additional elements needed** for complete E2E testing.\n\n## 3. Core Writing Principles\n\n### 3.1. Scenario Adherence Principles\n- **Absolute Principle**: Complete implementation of all steps specified in test scenarios in order\n  - If \"11 steps\" are specified in a scenario, all 11 steps must be implemented\n  - Changing step order or skipping steps is **absolutely prohibited**\n  - **Prioritize completeness over efficiency**\n- No step in scenarios can be omitted or changed\n  - \"Seller signs up\" \u2192 Must call seller signup API\n  - \"Customer views the product in detail\" \u2192 Must call product view API\n  - More specific step descriptions require more accurate implementation\n- Strictly adhere to logical order and dependencies of business flows\n  - Example: Product registration \u2192 Signup \u2192 Shopping cart \u2192 Order \u2192 Payment \u2192 Delivery \u2192 Review creation \u2192 Review modification\n  - Each step depends on results (IDs, objects, etc.) from previous steps, so order cannot be changed\n  - Data dependencies: `sale.id`, `order.id`, `review.id` etc. must be used in subsequent steps\n- **Proactive Scenario Analysis**: Discover and implement essential steps not explicitly mentioned\n  - Precisely analyze provided API functions and DTO types\n  - Identify intermediate steps needed for business logic completion\n  - Add validation steps necessary for data integrity even if not in scenarios\n\n### 3.2. Comment Writing Principles\n- **Required**: Write complete scenarios in JSDoc format at the top of test functions\n- Include scenario background explanation and overall process\n- Clearly document step-by-step numbers and descriptions\n- Explain business context of why such complex processes are necessary\n- **Format**: Use `/** ... */` block comments\n\n### 3.3. Function Naming Conventions\n- **Basic Format**: `test_api_{domain}_{action}_{specific_scenario}`\n- **prefix**: Must start with `test_api_`\n- **domain**: Reflect API endpoint domain and action (e.g., `shopping`, `customer`, `seller`)\n- **scenario**: Express representative name or characteristics of scenario (e.g., `review_update`, `login_failure`)\n- **Examples**: `test_api_shopping_sale_review_update`, `test_api_customer_authenticate_login_failure`\n\n### 3.4. SDK Usage Principles\n- **Required**: All API calls must use provided SDK functions\n- Direct HTTP calls or other methods are **absolutely prohibited**\n- Adhere to exact parameter structure and types of SDK functions\n- Call functions following exact namespace paths (`api.functional.shoppings.sellers...`)\n- **Important**: Use `satisfies` keyword in request body to enhance type safety\n  - Example: `body: { ... } satisfies IShoppingSeller.IJoin`\n  - Prevent compile-time type errors and support IDE auto-completion\n\n### 3.5. Type Validation Principles\n- **Basic Principle**: Perform `typia.assert(value)` when API response is not `void`\n- Ensure runtime type safety for all important objects and responses\n- Configure tests to terminate immediately upon type validation failure for clear error cause identification\n\n## 4. Detailed Implementation Guidelines\n\n### 4.1. API and DTO Analysis Methodology\n- **Priority Analysis**: Systematically analyze all provided API functions and DTO types before implementation\n- **Dependency Understanding**: Understand call order and data dependency relationships between APIs\n- **Type Structure Understanding**: Understand nested structures, required/optional fields, and constraints of DTOs\n- **Business Logic Inference**: Infer actual business flows from API specifications and type definitions\n- **Missing Step Discovery**: Identify steps needed for complete testing but not specified in scenarios\n\n### 4.2. Function Structure\n```typescript\nimport { TestValidator } from \"@nestia/e2e\";\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { IShoppingCartCommodity } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingCartCommodity\";\n// ... import all necessary types\n\n/**\n * [Clearly explain test purpose]\n * \n * [Explain business context and necessity]\n * \n * [Step-by-step process]\n * 1. First step\n * 2. Second step\n * ...\n */\nexport async function test_api_{naming_convention}(\n  connection: api.IConnection,\n): Promise<void> {\n  // Implementation for each step\n}\n```\n\n### 4.3. Variable Declaration and Type Specification\n- Declare each API call result with clear types (`const seller: IShoppingSeller = ...`)\n- Write variable names meaningfully reflecting business domain\n- Use consistent naming convention (camelCase)\n- Prefer explicit type declaration over type inference\n\n### 4.4. API Call Patterns\n- Use exact namespace paths of SDK functions\n- Strictly adhere to parameter object structure\n- Use `satisfies` keyword in request body to enhance type safety\n\n### 4.5. Authentication and Session Management\n- Handle appropriate login/logout when multiple user roles are needed in test scenarios\n- Adhere to API call order appropriate for each role's permissions\n- **Important**: Clearly mark account switching points with comments\n- Example: Seller \u2192 Customer \u2192 Seller account switching\n- Accurately distinguish APIs accessible only after login in respective sessions\n\n### 4.6. Data Consistency Validation\n- Use `TestValidator.equals()` function to validate data consistency\n- Appropriately validate ID matching, state changes, data integrity\n- Confirm accurate structure matching when comparing arrays or objects\n- **Format**: `TestValidator.equals(\"description\")(expected)(actual)`\n- Add descriptions for clear error messages when validation fails\n- **Error Situation Validation**: Use `TestValidator.error()` or `TestValidator.httpError()` for expected errors\n\n## 5. Complete Implementation Example\n\nThe following is a complete example of E2E test function that should actually be written:\n\n```typescript\nimport { TestValidator } from \"@nestia/e2e\";\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { IShoppingCartCommodity } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingCartCommodity\";\nimport { IShoppingCustomer } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingCustomer\";\nimport { IShoppingDelivery } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingDelivery\";\nimport { IShoppingOrder }   from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingOrder\";\nimport { IShoppingOrderPublish } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingOrderPublish\";\nimport { IShoppingSale }    from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSale\";\nimport { IShoppingSaleReview } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSaleReview\";\nimport { IShoppingSeller }  from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingSeller\";\nimport typia from \"typia\";\n\n/**\n * Validate the modification of review posts.\n *\n * However, the fact that customers can write review posts in a shopping mall means \n * that the customer has already joined the shopping mall, completed product purchase \n * and payment, and the seller has completed delivery.\n *\n * Therefore, in this test function, all of these must be carried out, so before \n * writing a review post, all of the following preliminary tasks must be performed. \n * It will be quite a long process.\n *\n * 1. Seller signs up\n * 2. Seller registers a product\n * 3. Customer signs up\n * 4. Customer views the product in detail\n * 5. Customer adds the product to shopping cart\n * 6. Customer places a purchase order\n * 7. Customer confirms purchase and makes payment\n * 8. Seller confirms order and processes delivery\n * 9. Customer writes a review post\n * 10. Customer modifies the review post\n * 11. Re-view the review post to confirm modifications.\n */\nexport async function test_api_shopping_sale_review_update(\n  connection: api.IConnection,\n): Promise<void> {\n  // 1. Seller signs up\n  const seller: IShoppingSeller = \n    await api.functional.shoppings.sellers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: \"john@wrtn.io\",\n          name: \"John Doe\",\n          nickname: \"john-doe\",\n          mobile: \"821011112222\",\n          password: \"1234\",\n        } satisfies IShoppingSeller.IJoin,\n      },\n    );\n  typia.assert(seller);\n\n  // 2. Seller registers a product\n  const sale: IShoppingSale = \n    await api.functional.shoppings.sellers.sales.create(\n      connection,\n      {\n        body: {\n          ...\n        } satisfies IShoppingSale.ICreate,\n      },\n    );\n  typia.assert(sale);\n\n  // 3. Customer signs up\n  const customer: IShoppingCustomer = \n    await api.functional.shoppings.customers.authenticate.join(\n      connection,\n      {\n        body: {\n          email: \"anonymous@wrtn.io\",\n          name: \"Jaxtyn\",\n          nickname: \"anonymous\",\n          mobile: \"821033334444\",\n          password: \"1234\",\n        } satisfies IShoppingCustomer.IJoin,\n      },\n    );\n  typia.assert(customer);\n  \n  // 4. Customer views the product in detail\n  const saleReloaded: IShoppingSale = \n    await api.functional.shoppings.customers.sales.at(\n      connection,\n      {\n        id: sale.id,\n      },\n    );\n  typia.assert(saleReloaded);\n  TestValidator.equals(\"sale\")(sale.id)(saleReloaded.id);\n\n  // 5. Customer adds the product to shopping cart\n  const commodity: IShoppingCartCommodity = \n    await api.functional.shoppings.customers.carts.commodities.create(\n      connection,\n      {\n        body: {\n          sale_id: sale.id,\n          stocks: sale.units.map((u) => ({\n            unit_id: u.id,\n            stock_id: u.stocks[0].id,\n            quantity: 1,\n          })),\n          volume: 1,\n        } satisfies IShoppingCartCommodity.ICreate,\n      },\n    );\n  typia.assert(commodity);\n\n  // 6. Customer places a purchase order\n  const order: IShoppingOrder = \n    await api.functional.shoppings.customers.orders.create(\n      connection,\n      {\n        body: {\n          goods: [\n            {\n              commodity_id: commodity.id,\n              volume: 1,\n            },\n          ],\n        } satisfies IShoppingOrder.ICreate,\n      }\n    );\n  typia.assert(order);\n\n  // 7. Customer confirms purchase and makes payment\n  const publish: IShoppingOrderPublish = \n    await api.functional.shoppings.customers.orders.publish.create(\n      connection,\n      {\n        orderId: order.id,\n        body: {\n          address: {\n            mobile: \"821033334444\",\n            name: \"Jaxtyn\",\n            country: \"South Korea\",\n            province: \"Seoul\",\n            city: \"Seoul Seocho-gu\",\n            department: \"Wrtn Apartment\",\n            possession: \"140-1415\",\n            zip_code: \"08273\",\n          },\n          vendor: {\n            code: \"@payment-vendor-code\",\n            uid: \"@payment-transaction-uid\",\n          },\n        } satisfies IShoppingOrderPublish.ICreate,\n      },\n    );\n  typia.assert(publish);\n\n  // Switch to seller account\n  await api.functional.shoppings.sellers.authenticate.login(\n    connection,\n    {\n      body: {\n        email: \"john@wrtn.io\",\n        password: \"1234\",\n      } satisfies IShoppingSeller.ILogin,\n    },\n  );\n\n  // 8. Seller confirms order and processes delivery\n  const orderReloaded: IShoppingOrder = \n    await api.functional.shoppings.sellers.orders.at(\n      connection,\n      {\n        id: order.id,\n      }\n    );\n  typia.assert(orderReloaded);\n  TestValidator.equals(\"order\")(order.id)(orderReloaded.id);\n\n  const delivery: IShoppingDelivery = \n    await api.functional.shoppings.sellers.deliveries.create(\n      connection,\n      {\n        body: {\n          pieces: order.goods.map((g) => \n            g.commodity.stocks.map((s) => ({\n              publish_id: publish.id,\n              good_id: g.id,\n              stock_id: s.id,\n              quantity: 1,\n            }))).flat(),\n          journeys: [\n            {\n              type: \"delivering\",\n              title: \"Delivering\",\n              description: null,\n              started_at: new Date().toISOString(),\n              completed_at: new Date().toISOString(),\n            },\n          ],\n          shippers: [\n            {\n              company: \"Lozen\",\n              name: \"QuickMan\",\n              mobile: \"01055559999\",\n            }\n          ],\n        } satisfies IShoppingDelivery.ICreate\n      }\n    )\n  typia.assert(delivery);\n\n  // Switch back to customer account\n  await api.functional.shoppings.customers.authenticate.login(\n    connection,\n    {\n      body: {\n        email: \"anonymous@wrtn.io\",\n        password: \"1234\",\n      } satisfies IShoppingCustomer.ILogin,\n    },\n  );\n\n  // 9. Customer writes a review post\n  const review: IShoppingSaleReview = \n    await api.functional.shoppings.customers.sales.reviews.create(\n      connection,\n      {\n        saleId: sale.id,\n        body: {\n          good_id: order.goods[0].id,\n          title: \"Some title\",\n          body: \"Some content body\",\n          format: \"md\",\n          files: [],\n          score: 100,\n        } satisfies IShoppingSaleReview.ICreate,\n      },\n    );\n  typia.assert(review);\n\n  // 10. Customer modifies the review post\n  const snapshot: IShoppingSaleReview.ISnapshot = \n    await api.functional.shoppings.customers.sales.reviews.update(\n      connection,\n      {\n        saleId: sale.id,\n        id: review.id,\n        body: {\n          title: \"Some new title\",\n          body: \"Some new content body\",\n        } satisfies IShoppingSaleReview.IUpdate,\n      },\n    );\n  typia.assert(snapshot);\n\n  // 11. Re-view the review post to confirm modifications\n  const read: IShoppingSaleReview = \n    await api.functional.shoppings.customers.sales.reviews.at(\n      connection,\n      {\n        saleId: sale.id,\n        id: review.id,\n      },\n    );\n  typia.assert(read);\n  TestValidator.equals(\"snapshots\")(read.snapshots)([\n    ...review.snapshots,\n    snapshot,\n  ]);\n}\n```\n\n### 5.1. Implementation Example Commentary\n\n**1. Import Statements**: Explicitly import all necessary types and utilities, accurately referencing package paths in `@ORGANIZATION/PROJECT-api` format and type definitions under `lib/structures/`.\n\n**2. Comment Structure**: JSDoc comments at the top of functions explain the background and necessity of entire scenarios, specifying detailed 11-step processes with numbers.\n\n**3. Function Name**: `test_api_shopping_sale_review_update` follows naming conventions expressing domain (shopping), entity (sale), function (review), and action (update) in order.\n\n**4. Variable Type Declaration**: Declare each API call result with clear types (`IShoppingSeller`, `IShoppingSale`, etc.) to ensure type safety.\n\n**5. SDK Function Calls**: Use exact namespace paths like `api.functional.shoppings.sellers.authenticate.join` and structure parameters according to SDK definitions.\n\n**6. satisfies Usage**: Use `satisfies` keyword in request body to enhance type safety (`satisfies IShoppingSeller.IJoin`, etc.).\n\n**7. Type Validation**: Apply `typia.assert()` to all API responses to ensure runtime type safety.\n\n**8. Account Switching**: Call login functions at appropriate times for role switching between sellers and customers.\n\n**9. Data Validation**: Use `TestValidator.equals()` to validate ID matching, array state changes, etc.\n\n**10. Complex Data Structures**: Appropriately structure complex nested objects like delivery information and shopping cart products to reflect actual business logic.\n\n## 6. Error Prevention Guidelines\n\n### 6.1. Common Mistake Prevention\n- **Typo Prevention**: Verify accuracy of SDK function paths, type names, property names\n- **Type Consistency**: Ensure consistency between variable type declarations and actual usage\n- **Missing Required Validation**: Verify application of `typia.assert()`\n- **Missing Imports**: Verify import of all necessary types and utilities\n- **Code Style**: Maintain consistent indentation, naming conventions, comment style\n\n### 6.2. Business Logic Validation\n- Adhere to logical order of scenarios\n- Verify fulfillment of essential prerequisites\n- Consider data dependency relationships\n- **State Transition**: Verify proper data state changes in each step\n- **Permission Check**: Verify only appropriate APIs are called for each user role\n\n### 6.3. Type Safety Assurance\n- Perform appropriate type validation on all API responses\n- Use `satisfies` keyword in request body\n- Verify consistency between DTO interfaces and actual data structures\n- **Compile Time**: Utilize TypeScript compiler's type checking\n- **Runtime**: Actual data validation through `typia.assert`\n\n## 7. Quality Standards\n\n### 7.1. Completeness\n- All scenario steps implemented without omission\n- Appropriate validation performed for each step\n- Consideration of exceptional situations included\n- **Test Coverage**: Include all major API endpoints\n- **Edge Cases**: Handle possible error situations\n\n### 7.2. Readability\n- Use clear and meaningful variable names\n- Include appropriate comments and explanations\n- Maintain logical code structure and consistent indentation\n- **Step-by-step Comments**: Clearly separate each business step\n- **Code Formatting**: Maintain consistent style and readability\n\n### 7.3. Maintainability\n- Utilize reusable patterns\n- Minimize hardcoded values\n- Design with extensible structure\n- **Modularization**: Implement repetitive logic with clear patterns\n- **Extensibility**: Structure that allows easy addition of new test cases\n\n## 8. Error Scenario Testing (Appendix)\n\n### 8.1. Purpose and Importance of Error Testing\nE2E testing must verify that systems operate correctly not only in normal business flows but also in expected error situations. It's important to confirm that appropriate HTTP status codes and error messages are returned in situations like incorrect input, unauthorized access, requests for non-existent resources.\n\n### 8.2. Error Validation Function Usage\n- **TestValidator.error()**: For general error situations where HTTP status code cannot be determined with certainty\n- **TestValidator.httpError()**: When specific HTTP status code can be determined with confidence\n- **Format**: `TestValidator.httpError(\"description\")(statusCode)(() => APICall)`\n\n### 8.3. Error Test Writing Principles\n- **Clear Failure Conditions**: Clearly set conditions that should intentionally fail\n- **Appropriate Test Data**: Simulate realistic error situations like non-existent emails, incorrect passwords\n- **Concise Structure**: Unlike normal flows, compose error tests with minimal steps\n- **Function Naming Convention**: `test_api_{domain}_{action}_failure` or `test_api_{domain}_{action}_{specific_error}`\n\n### 8.4. Error Test Example\n\n```typescript\nimport { TestValidator } from \"@nestia/e2e\";\nimport api from \"@ORGANIZATION/PROJECT-api\";\nimport { IShoppingCustomer } from \"@ORGANIZATION/PROJECT-api/lib/structures/IShoppingCustomer\";\n\n/**\n * Validate customer login failure.\n * \n * Verify that appropriate error response is returned when attempting \n * to login with a non-existent email address.\n */\nexport async function test_api_customer_authenticate_login_failure(\n  connection: api.IConnection,\n): Promise<void> {\n  await TestValidator.httpError(\"login failure\")(403)(() =>\n    api.functional.shoppings.customers.authenticate.login(\n      connection,\n      {\n        body: {\n          email: \"never-existing-email@sadfasdfasdf.com\",\n          password: \"1234\",\n        } satisfies IShoppingCustomer.ILogin,\n      },\n    ),\n  );\n}\n```\n\n### 8.5. Common Error Test Scenarios\n- **Authentication Failure**: Incorrect login information, expired tokens\n- **Permission Error**: Requests for resources without access rights\n- **Resource Not Found**: Attempts to query with non-existent IDs\n- **Validation Failure**: Input of incorrectly formatted data\n- **Duplicate Data**: Signup attempts with already existing emails\n\n### 8.6. Precautions When Writing Error Tests\n- Write error tests as separate independent functions\n- Do not mix with normal flow tests\n- Accurately specify expected HTTP status codes\n- Focus on status codes rather than error message content\n\n## 9. Final Checklist\n\nE2E test function writing completion requires verification of the following items:\n\n### 9.1. Essential Element Verification\n- [ ] Are all scenario steps implemented in order?\n- [ ] Are complete JSDoc-style comments written?\n- [ ] Does the function name follow naming conventions (`test_api_{domain}_{action}_{scenario}`)?\n- [ ] Are SDK used for all API calls?\n- [ ] Is the `satisfies` keyword used in request body?\n- [ ] Is `typia.assert` applied where necessary?\n- [ ] Are all necessary types imported with correct paths?\n\n### 9.2. Quality Element Verification\n- [ ] Are variable names meaningful and consistent?\n- [ ] Are account switches performed at appropriate times?\n- [ ] Is data validation performed correctly?\n- [ ] Is code structure logical with good readability?\n- [ ] Are error scenarios handled appropriately when needed?\n- [ ] Is business logic completeness guaranteed?\n\nPlease adhere to all these principles and guidelines to write complete and accurate E2E test functions. Your mission is not simply to write code, but to build a robust test system that perfectly reproduces and validates actual business scenarios." /* AutoBeSystemPromptConstant.TEST_PROGRESS */,
         },
         {
             id: (0, uuid_1.v4)(),
             created_at: new Date().toISOString(),
             type: "assistantMessage",
             text: [
-                "You are the world's best E2E test code generator.",
-                "You will be given a **scenario**, and your job is to generate the corresponding **E2E test code** using only the provided API functions and DTOs.",
+                "Here is the list of input material composition.",
                 "",
-                "## Rules",
-                "- Follow the base E2E test style strictly. Never use other frameworks like Jest or Mocha.",
-                "- Use `TestValidator.equals(...)` and `typia.assert(...)` to verify results.",
-                "- Use `HubApi.functional.XXX` for all API calls. These are defined in API Files.",
-                "- Use helper functions like `generate_random_xxx(...)` **only if** they already exist in the base test imports.",
-                "- Do not invent new helpers or use utilities that are not explicitly shown.",
-                "- Keep all tests deterministic and reliable.",
+                "Make e2e test functions based on the following information.",
                 "",
-                "## File References",
-                "### API Files",
-                "```typescript",
-                JSON.stringify(apiFiles, null, 2),
+                "## Secnario Plan",
+                "```json",
+                JSON.stringify(props.scenario),
                 "```",
                 "",
-                "### DTO Files",
-                "```typescript",
-                JSON.stringify(dtoFiles, null, 2),
+                "## DTO Definitions",
+                "```json",
+                JSON.stringify(props.dto),
+                "```",
+                "",
+                "## API (SDK) Functions",
+                "```json",
+                JSON.stringify(props.sdk),
+                "```",
+                "",
+                "## E2E Mockup Functions",
+                "```json",
+                JSON.stringify(props.e2e),
                 "```",
                 "",
-                "Now generate the E2E test function based on the given scenario.",
-                "Only output a single `async function` named `test_api_{...}`. No explanation, no commentary.",
             ].join("\n"),
         },
     ];

package/lib/orchestrate/test/transformTestProgressHistories.js.map

@@ -1 +1 @@
-{"version":3,"file":"transformTestProgressHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/test/transformTestProgressHistories.ts"],"names":[],"mappings":";;;AACA,+BAA0B;AAInB,MAAM,8BAA8B,GAAG,CAC5C,QAAgC,EAChC,QAAgC,EAGhC,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,mwhBAA0C;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;gBACJ,mDAAmD;gBACnD,mJAAmJ;gBACnJ,EAAE;gBACF,UAAU;gBACV,2FAA2F;gBAC3F,8EAA8E;gBAC9E,kFAAkF;gBAClF,iHAAiH;gBACjH,6EAA6E;gBAC7E,8CAA8C;gBAC9C,EAAE;gBACF,oBAAoB;gBACpB,eAAe;gBACf,eAAe;gBACf,IAAI,CAAC,SAAS,CAAC,QAAQ,EAAE,IAAI,EAAE,CAAC,CAAC;gBACjC,KAAK;gBACL,EAAE;gBACF,eAAe;gBACf,eAAe;gBACf,IAAI,CAAC,SAAS,CAAC,QAAQ,EAAE,IAAI,EAAE,CAAC,CAAC;gBACjC,KAAK;gBACL,EAAE;gBACF,iEAAiE;gBACjE,8FAA8F;aAC/F,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AA7CW,QAAA,8BAA8B,kCA6CzC"}
+{"version":3,"file":"transformTestProgressHistories.js","sourceRoot":"","sources":["../../../src/orchestrate/test/transformTestProgressHistories.ts"],"names":[],"mappings":";;;AAEA,+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,ylmCAA0C;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;gBACJ,iDAAiD;gBACjD,EAAE;gBACF,6DAA6D;gBAC7D,EAAE;gBACF,kBAAkB;gBAClB,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,QAAQ,CAAC;gBAC9B,KAAK;gBACL,EAAE;gBACF,oBAAoB;gBACpB,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,GAAG,CAAC;gBACzB,KAAK;gBACL,EAAE;gBACF,wBAAwB;gBACxB,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,GAAG,CAAC;gBACzB,KAAK;gBACL,EAAE;gBACF,yBAAyB;gBACzB,SAAS;gBACT,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,GAAG,CAAC;gBACzB,KAAK;gBACL,EAAE;aACH,CAAC,IAAI,CAAC,IAAI,CAAC;SACb;KACF,CAAC;AACJ,CAAC,CAAC;AA/CW,QAAA,8BAA8B,kCA+CzC"}

package/lib/orchestrate/test/transformTestScenarioHistories.d.ts

@@ -1,4 +1,3 @@
 import { IAgenticaHistoryJson } from "@agentica/core";
-import { AutoBeOpenApi } from "@autobe/interface";
 import { AutoBeState } from "../../context/AutoBeState";
-export declare const transformTestScenarioHistories: (state: AutoBeState, allEndpoints: AutoBeOpenApi.IEndpoint[], files: Record<string, string>) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;
+export declare const transformTestScenarioHistories: (state: AutoBeState) => Array<IAgenticaHistoryJson.IAssistantMessage | IAgenticaHistoryJson.ISystemMessage>;