@crediolabs/policy-synth 0.1.14 → 0.1.15

package/dist-cjs/run/index.js

@@ -225,9 +225,9 @@ async function runVerifyPolicy(raw) {
  *  Returns the unsigned Soroban transaction envelope (base64 XDR) the
  *  wallet signs. The wallet signature IS the user-confirmation step - no
  *  `action_id` two-call pair (the server is stateless, see server.ts:10-12).
- *  Per design decision 4, only CALL 1 (account.add_context_rule) is
- *  emitted; CALL 2 (interpreter.install) requires the rule id the account
- *  assigns in call 1 and is documented under `followUp` in the response.
+ *  One call installs the policy outright: `add_context_rule` carries the
+ *  predicate to the interpreter in its `policies` install_param, so no
+ *  separate `interpreter.install` call is needed or possible.
  *
  *  Default-deny: an interpreter policy address other than the pinned
  *  testnet interpreter is REFUSED (the smart account would delegate to

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@crediolabs/policy-synth",
-  "version": "0.1.14",
+  "version": "0.1.15",
   "license": "MIT",
   "description": "Off-chain TypeScript synthesis core for the OZ Accounts Policy Builder. Records Soroban transactions, synthesises the minimal policy that permits exactly that flow, verifies it, and returns an unsigned install transaction.",
   "type": "module",

package/src/install/build-install-policy.ts

@@ -13,9 +13,12 @@
 // (b) key material the server does not have, so we ship the simpler ONE-CALL
 // shape. The wallet signature covers the change.
 //
-// `buildInstallPolicyXdr` returns CALL 1 ONLY. Call 2 (interpreter.install)
-// needs the rule id the account assigns in call 1, so it cannot be pre-built
-// and is documented in the response envelope under `followUp`.
+// `buildInstallPolicyXdr` installs the policy in ONE call. `add_context_rule`
+// takes `policies` as a `Map<policy_address, install_param>` and the account
+// forwards each install_param to that policy, so the interpreter stores the
+// predicate document as part of this same transaction. Earlier revisions
+// documented a second `interpreter.install` call; that was wrong, and issuing
+// it fails - the account re-enters the interpreter while it is mid-install.
 
 import { createHash } from 'node:crypto'
 import {
@@ -216,19 +219,17 @@ export interface BuildInstallPolicyResult {
   smartAccount: string
   /** Source account (echo) - the address that must sign. */
   sourceAccount: string
-  /** The host-call target + fn name. Call 2 (interpreter.install) is NOT
-   *  emitted here; the account assigns the rule id in call 1 and call 2
-   *  needs that id to bind its `context_rule_ids`. See `followUp` below. */
+  /** The host-call target + fn name. This single call installs the policy
+   *  outright: `add_context_rule` takes `policies` as a
+   *  `Map<policy_address, install_param>`, and the account forwards each
+   *  install_param to that policy. For an interpreter policy the param
+   *  carries the predicate and its hash, so the interpreter stores the
+   *  document as part of this transaction. There is no second call.
+   *
+   *  Verified on testnet 2026-08-01: a rule created by this builder alone
+   *  permits a matching operator call and denies a non-matching one with
+   *  interpreter code #100 - not #206 MissingState. */
   call: { contract: string; fn: 'add_context_rule' }
-  /** The follow-up call the caller MUST issue after this one confirms.
-   *  The rule id the account assigns in call 1 is required to bind the
-   *  interpreter's `install` auth context. */
-  followUp: {
-    contract: 'interpreter'
-    fn: 'install'
-    requiresRuleIdFromCallOne: true
-    hint: string
-  }
   /** Human-readable description of the install call, decoded FROM the
    *  built unsigned XDR (not from the input args). The wallet signature
    *  binds to bytes; the review card has to bind to the same bytes, so
@@ -243,9 +244,6 @@ export interface BuildInstallPolicyResult {
   rootInvocationXdr: string
 }
 
-const FOLLOWUP_HINT =
-  'after this tx confirms, read the rule id via account.get_context_rules_count()-1 (or get the receipt events), then call runInstallPolicy a second time with the interpreter as the target and the rule id in context_rule_ids - OR hand-build the install() call directly with the OZ auth pattern.'
-
 /** Build the unsigned transaction envelope for `account.add_context_rule(...)`.
  *  The output XDR is signed by the wallet, not by us. */
 export async function buildInstallPolicyXdr(
@@ -363,12 +361,6 @@ export async function buildInstallPolicyXdr(
     smartAccount: args.smartAccount,
     sourceAccount: args.sourceAccount,
     call: { contract: args.smartAccount, fn: 'add_context_rule' },
-    followUp: {
-      contract: 'interpreter',
-      fn: 'install',
-      requiresRuleIdFromCallOne: true,
-      hint: FOLLOWUP_HINT,
-    },
     describes,
     authNonce: original.credentials().address().nonce().toString(),
     authValidUntilLedger: validUntilLedger,

package/src/run/index.ts

@@ -300,9 +300,9 @@ export async function runVerifyPolicy(raw: unknown): Promise<ToolResponse<true>>
  *  Returns the unsigned Soroban transaction envelope (base64 XDR) the
  *  wallet signs. The wallet signature IS the user-confirmation step - no
  *  `action_id` two-call pair (the server is stateless, see server.ts:10-12).
- *  Per design decision 4, only CALL 1 (account.add_context_rule) is
- *  emitted; CALL 2 (interpreter.install) requires the rule id the account
- *  assigns in call 1 and is documented under `followUp` in the response.
+ *  One call installs the policy outright: `add_context_rule` carries the
+ *  predicate to the interpreter in its `policies` install_param, so no
+ *  separate `interpreter.install` call is needed or possible.
  *
  *  Default-deny: an interpreter policy address other than the pinned
  *  testnet interpreter is REFUSED (the smart account would delegate to