@t2000/engine 1.13.0 → 1.14.0

package/dist/index.d.ts

@@ -1715,41 +1715,46 @@ declare function bundleShortestTtl(toolUseIds: string[], toolNamesById: Record<s
 declare const REGENERATABLE_READ_TOOLS: ReadonlySet<string>;
 
 /**
- * [Phase 0 / SPEC 13 / 2026-05-03] Maximum number of writes per atomic bundle.
- *
- * **History.** This was 5 between F14-fix-2 (2026-05-03 morning) and
- * Phase 0 (2026-05-03 evening). The May 3 production review found that
- * the underlying problem was never the count — bundles fail because
- * SDK appenders pre-fetch coins from the wallet and the chained asset
- * doesn't exist there yet (e.g. `swap_execute(USDC→USDsui) +
- * save_deposit(USDsui)` reverts at PREPARE because USDsui isn't in the
- * wallet at compose time). SPEC 13 builds the chained-coin handoff
- * primitive. Until that ships in `1.13.0`, Phase 0 strict-tightens
- * bundles to:
- *
- *   - Cap = 2 ops (was 5).
- *   - Every adjacent pair MUST be in `VALID_PAIRS` (was: any 2
- *     bundleable tools).
- *
- * **Why 2.** Every multi-write production failure today reduces to
- * the same gap: a chained-asset bundle whose intermediate output
- * doesn't exist in the wallet yet. The `VALID_PAIRS` whitelist below
- * enumerates every (producer, consumer) couple where chaining either
- * works today (because the consumer takes a wallet coin that the
- * producer happens to leave there via `tx.transferObjects`) OR will
- * work after Phase 1. Anything outside the whitelist falls through
- * to sequential — same outcome the LLM was already producing as a
- * fallback, just without the wasted PREPARE round-trip.
- *
- * **Why not 3+.** 3-op chains require a graph validator (every adjacent
- * pair valid + DAG topology checks) — that's Phase 2. Cap stays at 2
- * until Phase 1 lands the validator.
+ * [Phase 0 → Phase 2 / SPEC 13] Maximum number of writes per atomic bundle.
+ *
+ * **History.**
+ *  - Pre-Phase-0: 5 (F14-fix-2, 2026-05-03 morning).
+ *  - Phase 0 (1.12.0, 2026-05-03 evening): tightened to 2 after the May 3
+ *    production review found bundle failures all reduced to chained-asset
+ *    gaps — the SDK pre-fetched coins from the wallet and the chained
+ *    asset didn't exist yet (e.g. `swap_execute(USDC→USDsui) +
+ *    save_deposit(USDsui)` reverted at PREPARE because USDsui wasn't in
+ *    the wallet at compose time).
+ *  - Phase 1 (1.13.0): cap stayed 2. SPEC 13 Phase 1 added the chained-
+ *    coin handoff primitive (`PendingActionStep.inputCoinFromStep` +
+ *    `composeTx` orchestration loop) but didn't widen the cap. The
+ *    primitive is what makes Phase 2's raise to 3 possible — without it,
+ *    every additional step is another wallet-fetch race.
+ *  - Phase 2 (1.14.0, this version): cap raised to 3. Composition rule
+ *    is strict-adjacency: every (step[i], step[i+1]) pair must be in
+ *    `VALID_PAIRS`. No new pairs added — Phase 2 is purely the cap raise
+ *    + adjacency-loop validation. The chain-mode population loop already
+ *    runs over every `(i, i+1)` since 1.13.0, so 3-op atomic bundles
+ *    like `withdraw → swap → send` thread two coin handles end-to-end
+ *    in one PTB.
+ *
+ * **Why strict adjacency?** Every consecutive pair must be whitelisted
+ * even if the consumer doesn't chain (no `inputCoinFromStep`). This
+ * keeps the validator simple and matches the spec's Phase 2 model. The
+ * looser DAG-aware variant (where non-chained adjacent steps can be
+ * any tool combo) is a Phase 3 follow-up — defer until we see real
+ * production flows that need it.
+ *
+ * **Phase 3+:** `swap_execute → swap_execute` (Demo 1 unlock) + DAG-aware
+ * validator + cap raise to 4. SPEC 13 §"Phase 3" / §"Phase 5" tracks
+ * these. Don't pre-emptively raise this constant past 3 without those
+ * landing.
  *
  * Hosts importing this constant for system-prompt construction get the
- * current cap automatically. Bumping the cap in Phase 1 + Phase 2 + …
- * is a one-line change here that propagates to prompts via the import.
+ * current cap automatically. Bumping the cap is a one-line change here
+ * that propagates to prompts via the import.
  */
-declare const MAX_BUNDLE_OPS = 2;
+declare const MAX_BUNDLE_OPS = 3;
 /**
  * [Phase 0 / SPEC 13] Whitelisted (producer, consumer) pairs for atomic
  * bundling. Every key has the shape `${producer}->${consumer}`. Bundles

package/dist/index.js

@@ -5506,7 +5506,8 @@ function describeAction(tool, call) {
   const input = call.input;
   switch (tool.name) {
     case "save_deposit": {
-      return `Save ${input.amount} USDC into lending`;
+      const sAsset = input.asset ?? "USDC";
+      return `Save ${input.amount} ${sAsset} into lending`;
     }
     case "withdraw": {
       const wAsset = input.asset ?? "";
@@ -5514,10 +5515,14 @@ function describeAction(tool, call) {
     }
     case "send_transfer":
       return `Send $${input.amount} to ${input.to}`;
-    case "borrow":
-      return `Borrow $${input.amount} against collateral`;
-    case "repay_debt":
-      return `Repay $${input.amount} of outstanding debt`;
+    case "borrow": {
+      const bAsset = input.asset ?? "USDC";
+      return `Borrow $${input.amount} ${bAsset} against collateral`;
+    }
+    case "repay_debt": {
+      const rAsset = input.asset ?? "USDC";
+      return `Repay $${input.amount} ${rAsset} of outstanding debt`;
+    }
     case "claim_rewards":
       return "Claim all pending protocol rewards";
     case "pay_api": {
@@ -6732,7 +6737,7 @@ var REGENERATABLE_READ_TOOLS = /* @__PURE__ */ new Set([
 ]);
 
 // src/compose-bundle.ts
-var MAX_BUNDLE_OPS = 2;
+var MAX_BUNDLE_OPS = 3;
 var VALID_PAIRS = /* @__PURE__ */ new Set([
   "swap_execute->send_transfer",
   "swap_execute->save_deposit",
@@ -6808,6 +6813,10 @@ function composeBundleFromToolResults(input) {
     const consumer = input.pendingWrites[i];
     if (shouldChainCoin(producer, consumer)) {
       steps[i].inputCoinFromStep = i - 1;
+      getTelemetrySink().counter("engine.bundle_chain_mode_set", {
+        producer: producer.name,
+        consumer: consumer.name
+      });
     }
   }
   const regenerateToolUseIds = input.readResults.filter((r) => REGENERATABLE_READ_TOOLS.has(r.toolName)).map((r) => r.toolUseId);
@@ -7907,13 +7916,22 @@ ${recipeCtx}`;
         const turnIndex = this.messages.filter((m) => m.role === "assistant").length;
         this.turnPaused = true;
         if (allBundleable) {
-          if (guardPassedWrites.length === 2) {
-            const producer = guardPassedWrites[0].call.name;
-            const consumer = guardPassedWrites[1].call.name;
-            const check = checkValidPair(producer, consumer);
-            if (!check.ok) {
+          if (guardPassedWrites.length >= 2) {
+            let badPair = null;
+            for (let i = 0; i < guardPassedWrites.length - 1; i++) {
+              const producer = guardPassedWrites[i].call.name;
+              const consumer = guardPassedWrites[i + 1].call.name;
+              const check = checkValidPair(producer, consumer);
+              if (!check.ok) {
+                badPair = check;
+                break;
+              }
+            }
+            if (badPair !== null) {
+              const N = guardPassedWrites.length;
+              const stepsPhrase = N === 2 ? "two steps" : `${N} steps`;
               const pairError = {
-                error: `Bundle pair '${check.pair}' is not in the Phase 0 chaining whitelist. Whitelisted pairs: ${[...VALID_PAIRS].join(", ")}. Run these two writes sequentially: tell the user "I'll do this in two steps", emit only the first write, then the second after it lands and confirms.`,
+                error: `Bundle pair '${badPair.pair}' is not in the chaining whitelist. Whitelisted pairs: ${[...VALID_PAIRS].join(", ")}. Run these ${N} writes sequentially: tell the user "I'll do this in ${stepsPhrase}", emit only the first write, then the next after it lands and confirms.`,
                 _gate: "pair_not_whitelisted"
               };
               for (const write of guardPassedWrites) {
@@ -7937,7 +7955,7 @@ ${recipeCtx}`;
               getTelemetrySink().counter("engine.turn_outcome", {
                 entry: freshPrompt !== null ? "submit" : "resume",
                 outcome: "pair_not_whitelisted_continue",
-                pair: check.pair
+                pair: badPair.pair
               });
               continue;
             }