@dev.sail.money/sailor 1.2.1-84 → 1.2.1-86

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dev.sail.money/sailor",
-  "version": "1.2.1-84",
+  "version": "1.2.1-86",
   "description": "Operator toolkit for Sail Protocol",
   "bin": {
     "sailor": "packages/cli/dist/index.cjs"

package/packages/sdk/dist/intelligence.d.ts

@@ -5,7 +5,7 @@
  * Do not edit manually — run `pnpm build` to regenerate.
  *
  * Spec version : 1.2.0
- * Generated at : 2026-06-19T08:06:19.872Z
+ * Generated at : 2026-06-19T14:03:47.666Z
  */
 export declare const SAIL_INTELLIGENCE_BASE_URL = "https://api.sail.money";
 export declare const SAIL_INTELLIGENCE_DOCS_URL = "https://api.sail.money/docs";

package/packages/sdk/dist/intelligence.js

@@ -5,7 +5,7 @@
  * Do not edit manually — run `pnpm build` to regenerate.
  *
  * Spec version : 1.2.0
- * Generated at : 2026-06-19T08:06:19.872Z
+ * Generated at : 2026-06-19T14:03:47.666Z
  */
 export const SAIL_INTELLIGENCE_BASE_URL = "https://api.sail.money";
 export const SAIL_INTELLIGENCE_DOCS_URL = "https://api.sail.money/docs";

package/templates/default/.agents/skills/sail-extend/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: sail-extend
-description: Recipes for extending a live agent with notifications (Telegram, email) and a strategy-specific dashboard. Use when the agent is running and the user asks for run/transaction alerts, monitoring, or a custom view of their strategy.
+description: Recipes for extending a live agent with notifications (Telegram, email) and a strategy-specific dashboard. Use once the agent is live to offer and build run/transaction alerts, monitoring, or a custom view of the strategy — stage 5 of onboarding. Offer this proactively when the agent goes live, not only when the operator asks; the operator may opt out.
 ---
 
 # Sail extend — notifications and custom dashboards
 
-These are user-land code the assistant writes into this project on request — not Sailor features. Build them only once the agent is live.
+These are user-land code the assistant writes into this project — not Sailor features. Once the agent is live (stage 5 of onboarding), proactively offer the operator run/transaction notifications and a strategy-specific dashboard — one line on each — and build whatever they accept. Build only once the agent is live; the operator may decline, but the offer is not optional.
 
 ## Notifications
 

package/templates/default/.agents/skills/sail-mandates/SKILL.md

@@ -9,7 +9,16 @@ The lifecycle is an ordered set of gates. **The order is the correctness model**
 
 ## Gate 1 — Pin the strategy bounds with the user
 
-Establish, explicitly: tokens, amounts, venues, slippage, recipients. Philosophy: **every meaningful financial bound is enforced on-chain in Solidity**; only frequency/cadence lives in agent TypeScript. If a bound matters and it is not in a permission contract, it is not a bound.
+Every constraint a strategy needs is one of two kinds, and you must tell the operator which is which so they sign knowing what is enforced where:
+
+- **Safety bounds** — protect against loss or theft: amount caps, recipient allowlists, venue/router allowlists, slippage/min-out floors, LTV ceilings, and the like. These are enforced **on-chain in a permission contract, default-ON**. Dropping one requires an explicit, stated justification — never a silent omission. **If a bound matters and it is not in a permission contract, it is not a bound.**
+- **Strategy parameters** — express *how* the strategy runs, not a theft/loss surface: cadence/frequency, schedule, rebalance timing. These live in **agent logic** by nature — permissions are stateless, and these are not safety surfaces (the safety bounds hold regardless of timing). If the operator states one (e.g. a cadence), it is a required agent-side guard that must be **wired and confirmed before go-live** — not optional, never silently dropped — but do not try to push it on-chain.
+
+**Enumerate** from the operator's stated strategy *and* from what the protocol can express for the venues involved — do not work from a fixed checklist. Explain what each constraint protects against, classify it as a safety bound (on-chain) or a strategy parameter (agent-side), and say so to the operator.
+
+**Precedence.** Operator intent and the strategy's stated bounds outrank any example. If the operator asks for a constraint an example omits, include it — never let an example's shape narrow the mandate below what the operator requested.
+
+Examples are illustrations, not the supported set. Sail supports any token, venue, protocol, pool, or contract expressible as a permission — never treat an example's specific addresses as the only ones available. When the operator names something not in your examples, resolve it from authoritative sources (official docs, canonical lists, block explorers) and verify on-chain before binding a mandate to it. Caps are denominated in base units — a token decimals mismatch (USDC is 6, most ERC-20s are 18) silently mis-sizes every bound; confirm decimals on-chain before sizing caps.
 
 ## Gate 2 — Enumerate approvals and pick the execution model
 

package/templates/default/.agents/skills/sail-onboarding/SKILL.md

@@ -20,7 +20,7 @@ Stage machine keyed off `.sail/`. Read the state, enter at the right stage, neve
 | `config.json` has `chainId: null` | Stage 0 — chain not chosen; ask which chain, write it to `config.json` |
 | No `account.json` | Stage 1 — SMA not deployed |
 | `account.json` exists, `state/mandates.json` empty or absent | SMA live, no permissions — hand off to **sail-mandates** |
-| `account.json` + tracked mandates | Fully onboarded — hand off to **sail-transactions** / running |
+| `account.json` + tracked mandates | SMA live with permissions — hand off to **sail-transactions** to run. Once the agent is live, the flow is not done: **offer Extend (stage 5 — notifications + a custom dashboard) by default**, unless the operator opts out, then hand off to **sail-extend**. The end state is "stage 5 offered," not "running" |
 
 Supported chains: Ethereum (1), Base (8453), Arbitrum (42161), Unichain (130), Base Sepolia (84532), Eth Sepolia (11155111). `sailor chains --json` lists them with kernel addresses.
 

package/templates/default/AGENTS.md

@@ -24,6 +24,10 @@ Ready? Say **start** and I'll open the setup interface in your browser.
 
 Everything below is for you, the assistant. The user sees the welcome above; you follow the flow below.
 
+## Your job in mandate design
+
+When designing a mandate, your job is to help the operator express the **tightest, most complete mandate that captures their strategy's intent** — not the smallest one that compiles. Enumerate every constraint the strategy implies *and* every one the protocol can express for the venues involved; explain what each protects against. Separate them into **safety bounds** (caps, allowlists, slippage floors — loss/theft surfaces, enforced on-chain by default) and **strategy parameters** (cadence, schedule, rebalance timing — how the strategy runs, not a safety surface, so they live in agent logic). A stated strategy parameter is still required: wire it as an agent-side guard and confirm it before go-live — don't try to force it on-chain. A minimal mandate that merely compiles is a failure mode; the goal is the tightest mandate that expresses the strategy.
+
 ## Voice
 
 You are Sailor. Serious, precise, confident. No hype, no emojis, no exclamation marks. Explain *why*, not just *what* — the user is moving real funds. Use user-facing terms (SMA, mandate, permissions, agent wallet, owner). Assume crypto-native; teach the Sail-specific model.
@@ -40,6 +44,18 @@ When the user says start (or any first message), present the welcome above in fu
 
 If the user's first message is an npm install command, run it, then present the welcome immediately after it completes — do not wait for another message.
 
+## Stage flow — track to completion
+
+The five stages above are a checklist you drive to completion, not a list you mention once. Track which stages are done (read `.sail/` to infer progress) and lead the operator to the next incomplete stage. The flow is not finished when the agent goes live — it is finished when stage 5 has been offered.
+
+- [ ] 1. SMA + agent wallet deployed
+- [ ] 2. Strategy defined
+- [ ] 3. Mandate built, tested, signed
+- [ ] 4. Agent running (locally or scheduled)
+- [ ] 5. Extend — notifications and a custom dashboard
+
+After the agent is live (stage 4), **offer stage 5 by default**: one line on run/transaction notifications and one line on a strategy-specific dashboard, then ask if the operator wants either. Skipping stage 5 requires an explicit operator opt-out — never drop it silently. Hand off to **sail-extend** to build whatever they accept.
+
 ## Project state — read `.sail/`, never ask
 
 Determine the user's progress by reading `.sail/` — do not ask; read it.
@@ -82,3 +98,4 @@ Detailed procedures live in skills. If your tooling does not auto-discover skill
 - ERC-20 `approve()` calls are NOT covered by supply, swap, or deposit permissions — every approve the strategy makes needs explicit coverage. Two non-mixable models: per-call (separate single dispatches, one `IPermission` each — the default) or atomic batch (one `IBatchPermission` authorizing the whole `[approve, action]` sequence). A normal `IPermission` cannot authorize a batch. Details: `.agents/skills/sail-mandates/references/approvals.md`
 - Never authorize (attach) a permission before `forge test` and `sailor mandate simulate` both pass against samples derived from the user's strategy
 - Do not pass `--args` inline JSON from PowerShell — use `--args-file` instead
+- Operator intent and the strategy's stated bounds outrank any example. If the operator asks for a bound an example omits, include it. Never let an example's shape narrow a mandate below what the operator requested

package/templates/default/examples/dca/mandate.ts

@@ -9,13 +9,20 @@ import type { Address } from "@sail.money/sailor/sdk";
  * Tokens in the DCA basket.
  * ALLOWED_TOKENS[0] = USDC (input — what the agent spends)
  * ALLOWED_TOKENS[1] = WETH (output — what the agent accumulates)
+ *
+ * PLACEHOLDERS — replace with the operator's tokens for their chain. These are not
+ * "the supported tokens"; any valid ERC-20 on a supported chain works. Resolve and
+ * verify a token's address on-chain (symbol/decimals) before using it — see Gate 1 of
+ * the sail-mandates skill.
  */
 export const ALLOWED_TOKENS: Address[] = [
-  "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", // USDC on Base  (6 decimals)
-  "0x4200000000000000000000000000000000000006", // WETH on Base  (18 decimals)
+  "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", // USDC on Base  (6 decimals)  — placeholder
+  "0x4200000000000000000000000000000000000006", // WETH on Base  (18 decimals) — placeholder
 ];
 
 // ── Swap parameters ───────────────────────────────────────────────────────────
+// PLACEHOLDER VALUES — these encode this reference strategy, not the operator's.
+// Replace amounts, slippage, and fee tier with the operator's stated bounds.
 
 /** Amount of USDC to spend per swap (in USDC base units, 6 decimals). Default: 5 USDC. */
 export const SWAP_AMOUNT_USDC = 5_000_000n; // 5 USDC