@t2000/engine 1.13.1 → 1.15.0

package/dist/index.d.ts

@@ -1715,41 +1715,50 @@ 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 3a / 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): cap raised to 3. Composition rule was strict-
+ *    adjacency: every (step[i], step[i+1]) pair must be in `VALID_PAIRS`.
+ *    Strict adjacency rejected DAG shapes (`swap → save → send` —
+ *    last pair `save→send` not in whitelist even though step 3 doesn't
+ *    chain from step 2; it pulls a fresh wallet coin).
+ *  - **Phase 3a (1.15.0, this version): cap raised to 4. Composition rule
+ *    relaxed to DAG-aware: only pairs that actually chain via
+ *    `inputCoinFromStep` need whitelist checking. Standalone steps
+ *    interleaved between chained steps run wallet-mode independently
+ *    inside the same atomic PTB.** This unlocks Demo 1 ("swap 10% to
+ *    SUI, save 50% as USDsui, send $100 to Mom" — 4-op DAG with one
+ *    chain at step 1→2, three standalone wallet-mode steps).
+ *
+ * **DAG-aware semantics.** Pre-3a: every adjacent pair gates the entire
+ * bundle. Phase 3a+: each (i, i+1) pair contributes IF a chain is wired
+ * (via `shouldChainCoin`). Non-chained pairs are independent — they
+ * each pre-fetch their own coin from the wallet inside the PTB. Atomic
+ * settlement at the PTB level holds either way.
+ *
+ * **Phase 3b (deferred):** `swap_execute → swap_execute` whitelist add
+ * for explicit multi-hop swap chains (rare; flag-gated when shipped).
+ * **Phase 5+:** cap > 4 once production telemetry confirms zero edge-
+ * case revert rate at cap=4.
  *
  * 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 = 4;
 /**
  * [Phase 0 / SPEC 13] Whitelisted (producer, consumer) pairs for atomic
  * bundling. Every key has the shape `${producer}->${consumer}`. Bundles

package/dist/index.js

@@ -6737,7 +6737,7 @@ var REGENERATABLE_READ_TOOLS = /* @__PURE__ */ new Set([
 ]);
 
 // src/compose-bundle.ts
-var MAX_BUNDLE_OPS = 2;
+var MAX_BUNDLE_OPS = 4;
 var VALID_PAIRS = /* @__PURE__ */ new Set([
   "swap_execute->send_transfer",
   "swap_execute->save_deposit",
@@ -7885,7 +7885,7 @@ ${recipeCtx}`;
       }
       if (guardPassedWrites.length > MAX_BUNDLE_OPS) {
         const cappedError = {
-          error: `Atomic bundles are capped at ${MAX_BUNDLE_OPS} ops in Phase 0. You attempted ${guardPassedWrites.length}. Execute these as ${guardPassedWrites.length} sequential single-write transactions: tell the user "I'll do this in ${guardPassedWrites.length} steps", then emit only the FIRST write. After it lands and the user confirms each step, emit the next.`,
+          error: `Atomic bundles are capped at ${MAX_BUNDLE_OPS} ops. You attempted ${guardPassedWrites.length}. Execute these as ${guardPassedWrites.length} sequential single-write transactions: tell the user "I'll do this in ${guardPassedWrites.length} steps", then emit only the FIRST write. After it lands and the user confirms each step, emit the next.`,
           _gate: "max_bundle_ops"
         };
         for (const write of guardPassedWrites) {
@@ -7916,41 +7916,6 @@ ${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) {
-              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.`,
-                _gate: "pair_not_whitelisted"
-              };
-              for (const write of guardPassedWrites) {
-                yield {
-                  type: "tool_result",
-                  toolName: write.call.name,
-                  toolUseId: write.call.id,
-                  result: pairError,
-                  isError: true
-                };
-                toolResultBlocks.push({
-                  type: "tool_result",
-                  toolUseId: write.call.id,
-                  content: JSON.stringify(pairError),
-                  isError: true
-                });
-              }
-              this.turnPaused = false;
-              this.messages.push({ role: "assistant", content: acc.assistantBlocks });
-              this.messages.push({ role: "user", content: toolResultBlocks });
-              getTelemetrySink().counter("engine.turn_outcome", {
-                entry: freshPrompt !== null ? "submit" : "resume",
-                outcome: "pair_not_whitelisted_continue",
-                pair: check.pair
-              });
-              continue;
-            }
-          }
           const completedResults = toolResultBlocks.map((b) => ({
             toolUseId: b.toolUseId,
             content: b.content,