@t2000/engine 1.17.1 → 1.18.0

package/dist/index.d.ts

@@ -96,10 +96,10 @@ interface RecipeStep {
     cost_per_unit?: string;
     /**
      * [SPEC 7 P2.5 Layer 4] When true, this step is part of a multi-write
-     * Payment Stream bundle group. Steps with `bundle: true` MUST resolve
+     * Payment Intent compile group. Steps with `bundle: true` MUST resolve
      * to confirm-tier write tools that carry `bundleable: true` in
      * `TOOL_FLAGS` (validated at recipe load time). The loader fails fast
-     * on auto-tier writes / read-only tools / non-bundleable confirm tools
+     * on auto-tier writes / read-only tools / non-`bundleable` confirm tools
      * (`pay_api`, `save_contact`) inside a `bundle: true` group.
      *
      * The engine emits parallel `tool_use` blocks for `bundle: true`
@@ -915,7 +915,7 @@ interface PendingActionModifiableField {
     asset?: string;
 }
 /**
- * [SPEC 7 v0.4 Layer 2] One step inside a multi-write Payment Stream
+ * [SPEC 7 v0.4 Layer 2] One step inside a multi-write Payment Intent
  * `PendingAction`. Single-write actions never carry `steps[]`; the
  * legacy `toolName`/`toolUseId`/`input`/`attemptId` fields cover them.
  */
@@ -1005,7 +1005,7 @@ interface PendingAction {
      * exists to kill. Also survives session persistence so the resume call
      * can read it back from the rehydrated `PendingAction`.
      *
-     * **Bundles:** when `steps !== undefined` (multi-write Payment Stream),
+     * **Bundles:** when `steps !== undefined` (multi-write Payment Intent),
      * the top-level `attemptId` mirrors `steps[0].attemptId` per SPEC 7
      * § Layer 2 line 463 ("`steps[0]` mirrors the top-level
      * toolName/toolUseId/input/attemptId for hosts that haven't been
@@ -1019,7 +1019,7 @@ interface PendingAction {
     attemptId: string;
     /**
      * [SPEC 7 v0.4 Layer 2] When set, this `pending_action` represents a
-     * multi-write Payment Stream. Single-step bundles are NOT created — the
+     * multi-write Payment Intent. Single-step bundles are NOT created — the
      * engine emits the legacy single-write shape when N=1. Hosts that haven't
      * been updated read `toolName`/`toolUseId`/`input` (which mirror
      * `steps[0]`); newer hosts iterate `steps`.
@@ -1091,7 +1091,7 @@ interface PermissionResponse {
      * Each carries the step's `toolUseId` + `attemptId` so the host's resume
      * route can update the matching `TurnMetrics` row.
      *
-     * **Atomic semantics:** PTB execution is atomic at the Sui layer. If the
+     * **Atomic semantics:** Payment Intent execution is atomic at the Sui layer. If the
      * host detects a bundle-level failure, it should populate every entry
      * with `isError: true` carrying the same error message (so the LLM
      * narrates the failure once, not N times).
@@ -1204,7 +1204,7 @@ interface ToolFlags {
     maxRetries?: number;
     /**
      * [SPEC 7 v0.4 Layer 2] Opt-in: this write tool can participate in a
-     * multi-write Payment Stream. When the LLM emits ≥2 `tool_use` blocks
+     * multi-write Payment Intent. When the LLM emits ≥2 `tool_use` blocks
      * in a single assistant turn AND every block resolves to a `confirm`-tier
      * write tool with `bundleable: true`, the engine collapses them into one
      * `pending_action` with `steps[]` instead of yielding N times. Default
@@ -1215,8 +1215,8 @@ interface ToolFlags {
      * **Permanently non-bundleable:**
      *  - `pay_api` — recipient/amount/currency aren't known at LLM intent
      *    time (gateway 402 challenge resolves them at route time, after a
-     *    network round-trip the engine has no knowledge of). PTB cannot be
-     *    composed at compose time.
+     *    network round-trip the engine has no knowledge of). Payment Intent
+     *    cannot be composed at compose time.
      *  - `save_contact` — Postgres-only, no on-chain effect.
      */
     bundleable?: boolean;
@@ -1690,7 +1690,7 @@ declare function validateHistory(messages: Message[]): Message[];
 /**
  * SPEC 7 v0.3 Quote-Refresh ReviewCard — per-tool result freshness budgets.
  *
- * When a Payment Stream `pending_action` is composed at T=0 from upstream
+ * When a Payment Intent `pending_action` is composed at T=0 from upstream
  * read results, the user may take 30–60s to read + tap APPROVE. By that
  * time some upstream results have drifted (Cetus quotes refresh in
  * ~30s; NAVI APYs change slower). The host renders a "QUOTE Ns OLD"
@@ -1755,15 +1755,15 @@ declare const REGENERATABLE_READ_TOOLS: ReadonlySet<string>;
  *    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
+ *    inside the same atomic Payment Intent.** 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.
+ * each pre-fetch their own coin from the wallet inside the Payment Intent.
+ * Atomic settlement at the Payment Intent level holds either way.
  *
  * **Phase 3b (deferred):** `swap_execute → swap_execute` whitelist add
  * for explicit multi-hop swap chains (rare; flag-gated when shipped).
@@ -1785,7 +1785,7 @@ declare const MAX_BUNDLE_OPS = 4;
  *
  * | Pair | Why it works at compose time today |
  * |---|---|
- * | `swap_execute → send_transfer` | Swap's `tx.transferObjects([result.coin], sender)` lands the swap output in the wallet for the same PTB; send's `selectAndSplitCoin` finds it. |
+ * | `swap_execute → send_transfer` | Swap's `tx.transferObjects([result.coin], sender)` lands the swap output in the wallet for the same Payment Intent; send's `selectAndSplitCoin` finds it. |
  * | `swap_execute → save_deposit` | Same mechanism — swap output is back in wallet for save's coin fetch. (P0 caveat: this currently *fails* if the wallet has zero of `swap.to` BEFORE the swap step. Phase 1's `inputCoinFromStep` fixes that. For now we accept the pair but warn the LLM in the prompt rule that wallet must hold ≥0 of target asset.) |
  * | `swap_execute → repay_debt` | Same as save. Same caveat. |
  * | `withdraw → swap_execute` | Withdraw's output is transferred to user; swap's coin fetch finds it. Same wallet caveat in reverse. |
@@ -1913,7 +1913,7 @@ declare function composeBundleFromToolResults(input: BundleCompositionInput): Pe
 /**
  * SPEC 7 v0.3 Quote-Refresh ReviewCard — engine-side bundle regeneration.
  *
- * When a user takes 30–60s to read a multi-step Payment Stream
+ * When a user takes 30–60s to read a multi-step Payment Intent
  * `pending_action`, the upstream read results that fed bundle composition
  * (Cetus quotes, NAVI APYs, wallet balances) drift. Today the user has to
  * either approve with stale data (Sui dry-run is the safety gate, but the
@@ -2179,11 +2179,12 @@ declare class MemorySessionStore implements SessionStore {
  *   producesArtifact — returns images, documents, generated content
  *   costAware       — has a monetary cost the user should know about
  *   maxRetries      — max calls with same input (default: unlimited for reads, 1 for writes)
- *   bundleable      — [SPEC 7 Layer 2] can participate in a multi-write Payment Stream
- *                     PTB. Set on every confirm-tier write whose on-chain effect is
- *                     fully expressible at compose time. Excluded: `pay_api` (recipient/
- *                     amount/currency unknown until gateway 402 challenge resolves at
- *                     route time) and `save_contact` (Postgres-only, no on-chain effect).
+ *   bundleable      — [SPEC 7 Layer 2] can participate in a multi-write Payment
+ *                     Intent. Set on every confirm-tier write whose on-chain effect
+ *                     is fully expressible at compose time. Excluded: `pay_api`
+ *                     (recipient/amount/currency unknown until gateway 402 challenge
+ *                     resolves at route time) and `save_contact` (Postgres-only, no
+ *                     on-chain effect).
  */
 declare const TOOL_FLAGS: Record<string, ToolFlags>;
 /**