dexterm-cli 0.1.6 → 0.1.7

package/dist/packages/mcp/assets/kb/docs/docs-paper-trading-a-live-ticket.md

@@ -1,42 +0,0 @@
----
-id: docs-paper-trading-a-live-ticket
-title: Paper trading, live trading and the safety model › Live trading (devnet first) › A LIVE ticket
-kind: docs
-page: paper-trading
-page_title: Paper trading, live trading and the safety model
-heading: A LIVE ticket
-anchor: a-live-ticket
-url: https://dexterm.xyz/docs/paper-trading#a-live-ticket
-tags:
-  - docs
-  - paper-trading
-  - live
-  - ticket
-  - trading
-  - devnet
-  - first
-  - paper
-  - safety
-  - model
-confidence: high
-owner: maintainers
-origin: docs-generated
-reviewed_by: generated@2026-10-16
-generated_from: dexterm/site content/docs (task-1420)
-sources:
-  - site/content/docs/paper-trading.md
-date: 2026-10-16
----
-
-`L` on a ticket flips it LIVE when a wallet is linked and the signer is alive (otherwise the ticket says why and stays PAPER). The header shows `◉ LIVE · DEVNET`, or `⚠ LIVE · MAINNET — REAL FUNDS` in red with the caps. `⏎` asks the signer for a **PLAN**:
-
-1. **Quote** from Jupiter, bound to your order: the input and output mints, the mode and the exact input amount must match or the plan is refused (`quote-mismatch`).
-2. **Build** the unsigned transaction; **decode** it with dexterm's own wire decoder (legacy and v0, lookup tables included).
-3. **Policy**: every top-level instruction must fit the shape of a Jupiter swap: exactly one route-family instruction (by Anchor discriminator), token operations limited to SyncNative, InitializeAccount for your wallet and CloseAccount back to your wallet, a System transfer only into your own wrapped-SOL account that is synced and closed in the same transaction, associated-token creation only for your wallet. Transfers, burns, approvals, authority changes, direct DEX calls and unknown programs are refused by name.
-4. **Binding**: the route's `in_amount`, `quoted_out_amount` and `slippage_bps` must equal the quote; the platform fee must be zero with the "none" sentinel account (dexterm takes no fee); the transfer authority must be your wallet; the source and destination must be your own associated token accounts for the two mints.
-5. **Simulation** against the RPC, with your wallet **and your token accounts** in the requested post-state: the SOL leaving your wallet must not exceed the plan plus a fee allowance nor the SOL cap; a buy may not decrease any of your token balances; a sell may spend only the order mint's account and only up to the order amount (an address a lookup table loads counts as part of the transaction). If the balances cannot be read, the plan is refused rather than guessed.
-6. **Price**: the SOL leg times the signer's own SOL/USD, never Jupiter's `swapUsdValue`; on mainnet an unknown or $0 price refuses.
-
-The PLAN screen lists what will be signed instruction by instruction, what you pay and receive, the minimum received, the impact as a percent, the fee including any priority fee, the route, the simulation result, the SOL/USD price and its sources, the policy verdict and the caps verdict ("will be refused: …" when it would be).
-
-`Y` (or `⏎`) is the keypress gate. The signer re-checks the caps, **reserves** the USD against the daily ledger (atomically, so two trades cannot both pass), opens the sign page, and hands the bytes to Phantom. What comes back must be the **same message** with a valid Ed25519 signature by the linked wallet; the only tolerated difference is a Lighthouse assertion tail appended by Phantom. The signed bytes are decoded, policy-checked and bound again, **re-simulated** with fresh token balances, and only then submitted. A transport error after the send keeps the charge and shows the signature with "do not resend"; a definite rejection before broadcast refunds. Plans are single-use and expire after 90 s.

package/dist/packages/mcp/assets/kb/docs/docs-paper-trading-before-you-press-size-vs-caps.md

@@ -1,34 +0,0 @@
----
-id: docs-paper-trading-before-you-press-size-vs-caps
-title: Paper trading, live trading and the safety model › Live trading (devnet first) › Before you press ⏎: size vs caps
-kind: docs
-page: paper-trading
-page_title: Paper trading, live trading and the safety model
-heading: Before you press ⏎: size vs caps
-anchor: before-you-press-size-vs-caps
-url: https://dexterm.xyz/docs/paper-trading#before-you-press-size-vs-caps
-tags:
-  - docs
-  - paper-trading
-  - before
-  - press
-  - size
-  - caps
-  - live
-  - trading
-  - devnet
-  - first
-  - paper
-  - safety
-  - model
-confidence: high
-owner: maintainers
-origin: docs-generated
-reviewed_by: generated@2026-10-16
-generated_from: dexterm/site content/docs (task-1420)
-sources:
-  - site/content/docs/paper-trading.md
-date: 2026-10-16
----
-
-Since 2026-10-12 (`task-1368`) a LIVE buy ticket prices your size **at the signer's own SOL/USD** (the price its caps are enforced with) while you type, and shows it against the per-trade cap and what is left of the daily cap: `0.04 SOL ≈ $4.32 at SOL $108 · cap $5/trade · $20 left of $20 today`. When the size is over, the line turns red before you build anything: `0.05 SOL = $5.40 > $5 cap: use ≤ 0.043 SOL (f fits it; fees + token-account rent counted)`. `f` sets that size. The fit is the cap divided by the price minus 0.0025 SOL, rounded down to three decimals: the signer prices the *larger* of your planned SOL leg and the SOL the simulation actually moves out of the wallet, and a first buy of a token adds a token-account rent (0.00204 SOL) plus the fees on top of the size, so a size that is exactly the cap in USD would be refused at precheck. The daily remainder binds when it is smaller than the per-trade cap; with no SOL/USD from the signer the line says `$?` and the signer will refuse an unpriced trade on mainnet. The ticket's verdict is a preview; the signer still decides at precheck and again at confirm.

package/dist/packages/mcp/assets/kb/docs/docs-paper-trading-devnet-signer-mainnet-token.md

@@ -1,35 +0,0 @@
----
-id: docs-paper-trading-devnet-signer-mainnet-token
-title: Paper trading, live trading and the safety model › Live trading (devnet first) › Devnet signer, mainnet token
-kind: docs
-page: paper-trading
-page_title: Paper trading, live trading and the safety model
-heading: Devnet signer, mainnet token
-anchor: devnet-signer-mainnet-token
-url: https://dexterm.xyz/docs/paper-trading#devnet-signer-mainnet-token
-tags:
-  - docs
-  - paper-trading
-  - devnet
-  - signer
-  - mainnet
-  - token
-  - live
-  - trading
-  - first
-  - paper
-  - safety
-  - model
-confidence: high
-owner: maintainers
-origin: docs-generated
-reviewed_by: generated@2026-10-16
-generated_from: dexterm/site content/docs (task-1420)
-sources:
-  - site/content/docs/paper-trading.md
-date: 2026-10-16
----
-
-Jupiter has no devnet. A Jupiter route is built on **mainnet state** (its accounts, address-lookup tables and blockhash), so a devnet signer can never simulate or fill a swap of a real token: the simulation fails with an RPC error such as `invalid transaction: Transaction loads an address table account that doesn't exist`, and the caps refuse it (`simulation-failed`). The ticket now says this **before** you press ⏎ on any token while the signer is on devnet (`DEVNET cannot fill mainnet tokens: paper trade (L) or restart with --mainnet (real funds, caps $5/$20)`), and when a simulation does fail the PLAN shows the **full** RPC error over several lines (it used to be cut to `invalid transaction: Tr…`) with a plain-English hint when the pattern is this mismatch; the signer also writes the full error to the app log. Your two options are exactly those: paper trade the token with `L`, or run `dexterm --mainnet` with a funded mainnet wallet inside the caps (next section). The devnet signing path itself is proven by the probe, which is built for devnet on purpose.
-
-On **devnet** a Jupiter swap is refused at the caps step (`mainnet-not-enabled`): Jupiter has no devnet, so a real swap is a mainnet action. The signing path is proven on devnet instead by **`dexterm wallet probe`** (or `/wallet probe`): a transaction dexterm builds itself that wraps 0.001 SOL into your own wrapped-SOL account and closes it back, fees only, through exactly the same keypress → Phantom → verify → re-simulate → submit → confirm path, with its own policy (no route allowed) and never on mainnet.

package/dist/packages/mcp/assets/kb/docs/docs-paper-trading-jupiter-rate-limits.md

@@ -1,33 +0,0 @@
----
-id: docs-paper-trading-jupiter-rate-limits
-title: Paper trading, live trading and the safety model › Live trading (devnet first) › Jupiter rate limits
-kind: docs
-page: paper-trading
-page_title: Paper trading, live trading and the safety model
-heading: Jupiter rate limits
-anchor: jupiter-rate-limits
-url: https://dexterm.xyz/docs/paper-trading#jupiter-rate-limits
-tags:
-  - docs
-  - paper-trading
-  - jupiter
-  - rate
-  - limits
-  - live
-  - trading
-  - devnet
-  - first
-  - paper
-  - safety
-  - model
-confidence: high
-owner: maintainers
-origin: docs-generated
-reviewed_by: generated@2026-10-16
-generated_from: dexterm/site content/docs (task-1420)
-sources:
-  - site/content/docs/paper-trading.md
-date: 2026-10-16
----
-
-Jupiter's keyless API allows about five requests per ten seconds per IP, answers `429` with no `Retry-After` but with a reset time, and its alternate host (`lite-api.jup.ag`) can answer `503` (both recorded on 2026-10-12 and kept as fixtures). A limit used to kill the plan (`build-failed: HTTP 429`) and park the preview on "fetching…" for half a minute. Now every keyless Jupiter call on the trade path is retried on the **other host** after the server's own reset (or `Retry-After`, with a jittered backoff), at most three attempts inside ten seconds; a `5xx` or a dropped connection alternates the same way; the LIVE preview, the signer's re-quote and the build go through the signer's **one** rate limiter and a quote fetched for the preview is reused by the build a moment later (two calls, not three). When the budget is spent, or the data layer's health gate is cooling the source down after two 429s in a minute, the ticket **keeps the plan**: it shows `Jupiter is rate limiting this IP (429 from api.jup.ag), retrying in Ns`, retries by itself when the wait ends, `r` retries now and `esc` cancels. Nothing is built or signed while it waits.

package/dist/packages/mcp/assets/kb/docs/docs-paper-trading-link-a-wallet.md

@@ -1,32 +0,0 @@
----
-id: docs-paper-trading-link-a-wallet
-title: Paper trading, live trading and the safety model › Live trading (devnet first) › Link a wallet
-kind: docs
-page: paper-trading
-page_title: Paper trading, live trading and the safety model
-heading: Link a wallet
-anchor: link-a-wallet
-url: https://dexterm.xyz/docs/paper-trading#link-a-wallet
-tags:
-  - docs
-  - paper-trading
-  - link
-  - wallet
-  - live
-  - trading
-  - devnet
-  - first
-  - paper
-  - safety
-  - model
-confidence: high
-owner: maintainers
-origin: docs-generated
-reviewed_by: generated@2026-10-16
-generated_from: dexterm/site content/docs (task-1420)
-sources:
-  - site/content/docs/paper-trading.md
-date: 2026-10-16
----
-
-`dexterm wallet link` (or `/wallet link` typed on the screener's `/` line or in the chat box) starts a one-shot server on `127.0.0.1:41291` (a fixed loopback port since `task-1368`; a random one only if it is busy, and the page then says so) with a single-use token, and opens your browser to it. The page asks Phantom to **connect** and **sign a message** (a dexterm nonce): no transaction, no approval of funds. The port is fixed because Phantom remembers which **origins** it trusts: link and every later sign page share `http://127.0.0.1:41291`, so after the first Connect prompt Phantom connects silently. dexterm verifies the Ed25519 proof and stores **only your public key** in `~/.dexterm/wallet-link.json`. `dexterm wallet status`, `unlink`, `/wallet`, `/wallet unlink` show or remove it. No private key, seed or password ever reaches dexterm; it has no code that could hold one.

package/dist/packages/mcp/assets/kb/docs/docs-paper-trading-live-trading-devnet-first.md

@@ -1,30 +0,0 @@
----
-id: docs-paper-trading-live-trading-devnet-first
-title: Paper trading, live trading and the safety model › Live trading (devnet first)
-kind: docs
-page: paper-trading
-page_title: Paper trading, live trading and the safety model
-heading: Live trading (devnet first)
-anchor: live-trading-devnet-first
-url: https://dexterm.xyz/docs/paper-trading#live-trading-devnet-first
-tags:
-  - docs
-  - paper-trading
-  - live
-  - trading
-  - devnet
-  - first
-  - paper
-  - safety
-  - model
-confidence: high
-owner: maintainers
-origin: docs-generated
-reviewed_by: generated@2026-10-16
-generated_from: dexterm/site content/docs (task-1420)
-sources:
-  - site/content/docs/paper-trading.md
-date: 2026-10-16
----
-
-**Status: in progress.** The code is on main and verified against fakes, a hand-built attack suite and a real recorded Jupiter transaction; the one thing not yet observed is a transaction signed by the real Phantom extension on devnet, which the maintainers' probe run will settle. Nothing here has touched mainnet.

package/dist/packages/mcp/assets/kb/docs/docs-paper-trading-mainnet.md

@@ -1,31 +0,0 @@
----
-id: docs-paper-trading-mainnet
-title: Paper trading, live trading and the safety model › Live trading (devnet first) › Mainnet
-kind: docs
-page: paper-trading
-page_title: Paper trading, live trading and the safety model
-heading: Mainnet
-anchor: mainnet
-url: https://dexterm.xyz/docs/paper-trading#mainnet
-tags:
-  - docs
-  - paper-trading
-  - mainnet
-  - live
-  - trading
-  - devnet
-  - first
-  - paper
-  - safety
-  - model
-confidence: high
-owner: maintainers
-origin: docs-generated
-reviewed_by: generated@2026-10-16
-generated_from: dexterm/site content/docs (task-1420)
-sources:
-  - site/content/docs/paper-trading.md
-date: 2026-10-16
----
-
-Only with `--mainnet`. The banner is red, the caps are $5 per trade and $20 per day by default (raise them only with the flag, never above $500 / $2000), 1 SOL out per transaction, 3% impact, 500 bps slippage. dexterm takes no fee; you pay network fees only. Nobody has run a mainnet trade through this path yet, and nothing on this page authorizes one.

package/dist/packages/mcp/assets/kb/docs/docs-paper-trading-the-live-fire-path-devnet-the-fast-wallet.md

@@ -1,41 +0,0 @@
----
-id: docs-paper-trading-the-live-fire-path-devnet-the-fast-wallet
-title: Paper trading, live trading and the safety model › Order plans and standing mandates › The live fire path (devnet, the fast wallet)
-kind: docs
-page: paper-trading
-page_title: Paper trading, live trading and the safety model
-heading: The live fire path (devnet, the fast wallet)
-anchor: the-live-fire-path-devnet-the-fast-wallet
-url: https://dexterm.xyz/docs/paper-trading#the-live-fire-path-devnet-the-fast-wallet
-tags:
-  - docs
-  - paper-trading
-  - live
-  - fire
-  - path
-  - devnet
-  - fast
-  - wallet
-  - order
-  - plans
-  - standing
-  - mandates
-  - paper
-  - trading
-confidence: high
-owner: maintainers
-origin: docs-generated
-reviewed_by: generated@2026-10-16
-generated_from: dexterm/site content/docs (task-1420)
-sources:
-  - site/content/docs/paper-trading.md
-date: 2026-10-16
----
-
-A standing mandate is meant to fire at machine speed, which a Phantom approval per fill cannot do. So the live path uses a second, **capped fast wallet**: the one key dexterm ever holds, created only by `dexterm wallet fast create` after a real keypress on a TTY, stored at `~/.dexterm/fast-wallet.json` at mode 600, **devnet only** (the record says so, the signer process loads it only against a devnet RPC, and there is no mainnet variant, no export and no import). `dexterm wallet fast status` shows its public key and devnet balance, `dexterm wallet fast airdrop` asks the devnet faucet, `dexterm wallet fast remove` deletes it (refused while it still holds SOL unless `--force`). Your main wallet is never named by a mandate and the fast wallet never signs for it: the signer refuses either crossing before caps, reservation or signing.
-
-`L` on the `O` screen raises the fire-path prompt; a held keypress switches plan fills from PAPER to **LIVE · DEVNET · fast wallet** (and back), journaled as `settings.executor`. The switch is refused by voice, an agent, a pipe or the popup (it takes nothing but a keypress), while any plan is armed or holding (its legs would strand on the other ledger), when the run has no signer process (replay, offline, `--no-live`), when the signer is not on devnet, or when no fast wallet is loaded. Every run starts on paper; the journal never recovers a live switch.
-
-When an armed plan fires on the live path, the engine asks the signer to **build a devnet fill** for its leg. Jupiter has no devnet, so the transaction is the probe's wrap-and-unwrap shape sized to the plan's SOL leg (0.02 SOL for a $3 entry at $150/SOL), with an on-chain memo naming the plan leg; the signer decodes it, runs the probe-shape policy and the program allow-list, simulates it with the fast wallet's token balances, prices the SOL leg from its own SOL/USD feed and **enforces its USD per-trade and daily caps on devnet too** (a fill with no trustworthy price, or above the per-trade or remaining daily budget, is refused and the reason, `per-trade-cap`, `daily-cap`, `no-usd-value`, is what the plans journal records) plus a hard **0.05 SOL per-fill ceiling**. The confirm re-checks and reserves the USD, has the fast wallet sign, verifies the signature and the message, re-simulates the signed bytes, submits and confirms. The engine journals an intent before anything is sent, treats the send as in flight until the signer answers, settles it by lookup and never resends; an outcome the signer could not determine expires in the engine after 90 seconds as unseen (the fast wallet is capped, so exposure is bounded). The plan's **token leg is modelled** from the fire-time price, because no token changes hands on devnet, and the journal labels the fill `devnet-fill` with `modelledTokens: true`, the real signature and the real SOL delta (the fees). A mainnet fill through the fast wallet is refused by construction.
-
-What is proven here, on fakes with the real decoder, the real Ed25519 signer and the real executor pipeline: a fill is built, signed by the fast wallet (Phantom is never asked), confirmed and booked with the USD ledger charged; the ceiling, a missing price, the per-trade cap and the daily cap each refuse before anything signs; a mainnet signer or a missing fast wallet refuses the build; a fast-lane plan confirmed with the main wallet's key, or a main-lane plan built for the fast wallet, is `signer-mismatch`; the whole path works over the real authenticated child-process channel; and the engine-side adapter turns the signer's answers into the journal rows above. What is not: a fill confirmed on devnet with real faucet SOL (the public faucet answered an internal error on the day), and any mainnet action.

package/dist/packages/mcp/assets/kb/docs/docs-paper-trading-the-signer-process.md

@@ -1,34 +0,0 @@
----
-id: docs-paper-trading-the-signer-process
-title: Paper trading, live trading and the safety model › Live trading (devnet first) › The signer process
-kind: docs
-page: paper-trading
-page_title: Paper trading, live trading and the safety model
-heading: The signer process
-anchor: the-signer-process
-url: https://dexterm.xyz/docs/paper-trading#the-signer-process
-tags:
-  - docs
-  - paper-trading
-  - signer
-  - process
-  - live
-  - trading
-  - devnet
-  - first
-  - paper
-  - safety
-  - model
-confidence: high
-owner: maintainers
-origin: docs-generated
-reviewed_by: generated@2026-10-16
-generated_from: dexterm/site content/docs (task-1420)
-sources:
-  - site/content/docs/paper-trading.md
-date: 2026-10-16
----
-
-The first LIVE action starts a **separate signer process** with exactly the caps flags you started dexterm with (`--max-usd`, `--daily-usd`, `--max-sol-out`, `--max-slippage-bps`, `--trade-rpc`, `--mainnet`). It talks to the terminal over an authenticated pipe whose only methods are `status · plan · probe · precheck · confirm · drop · panic`: there is no `sign(bytes)`, no `submit`, no `setCaps`, and no way to name a wallet other than the one in the signer's own link file. If the signer dies it is never respawned; LIVE stays off until you restart.
-
-The signer owns: the caps and their hard ceilings; the **daily USD ledger** (SQLite, shared by every dexterm process on the machine, survives a restart); the **kill switch**; its own HTTP client for Jupiter and the RPC; its own **SOL/USD feed** (DexScreener and CoinGecko, timestamped, both required within 3% and under 60 s on mainnet); and the wallet bridge. The network it reports and caps by is classified from the RPC endpoint it actually talks to, by exact hostname, never from a flag or a label.

package/dist/packages/mcp/assets/kb/docs/docs-paper-trading-what-the-live-path-keeps.md

@@ -1,37 +0,0 @@
----
-id: docs-paper-trading-what-the-live-path-keeps
-title: Paper trading, live trading and the safety model › What the live path keeps
-kind: docs
-page: paper-trading
-page_title: Paper trading, live trading and the safety model
-heading: What the live path keeps
-anchor: what-the-live-path-keeps
-url: https://dexterm.xyz/docs/paper-trading#what-the-live-path-keeps
-tags:
-  - docs
-  - paper-trading
-  - live
-  - path
-  - keeps
-  - paper
-  - trading
-  - safety
-  - model
-confidence: high
-owner: maintainers
-origin: docs-generated
-reviewed_by: generated@2026-10-16
-generated_from: dexterm/site content/docs (task-1420)
-sources:
-  - site/content/docs/paper-trading.md
-date: 2026-10-16
----
-
-These are the invariants from the spec; hold us to them:
-
-1. **Non-custodial.** You hold the keys. dexterm builds, simulates and hands off; your wallet signs. The Phantom bridge stores only your public key.
-2. **Keypress gate on by default.** Models and voice create proposals; arming needs a physical keypress or a wallet approval. Opting out, if ever offered, needs an explicit "this is less safe" confirmation, is local, logged and reversible, and the signer caps still apply.
-3. **Caps live in the signer, not the UI.** The signer re-simulates and re-checks every transaction (per-trade and daily USD caps, price-impact and slippage ceilings, the SOL-out cap, the token-balance diff, a positive description of what a Jupiter swap looks like: exactly one route instruction bound to your order, no token transfers, burns or approvals to anyone) and refuses out of policy even if the UI, the model or a popup is compromised.
-4. **The AI has no interface to the signer.** No build, sign or send tool exists for the model. Its write-shaped tools are paper only: `open_ticket` opens a PAPER ticket, and (from 0.1.5, only if you start `--agent-paper` on a mandate you armed) an agent you connected can use the `paper_*` tools to book the **simulated** ledger inside that mandate. A registry test enumerates every MCP tool and fails if any could reach a signing, sending or cap-changing path, and the paper path imports nothing signer-shaped. Even on a live-capable context the model's ticket yields a paper ticket and the signer is never called. The scan mode and the MCP server import nothing signer-shaped.
-
-> warn: paper results are not predictive, and live results are real. Paper fills take the quote at its word; a real fill pays real slippage, priority fees and failed transactions, and most memecoins go to zero. Nothing here is financial advice.

package/dist/packages/mcp/assets/kb/docs/docs-paper-trading-your-first-live-trade.md

@@ -1,41 +0,0 @@
----
-id: docs-paper-trading-your-first-live-trade
-title: Paper trading, live trading and the safety model › Live trading (devnet first) › Your first live trade
-kind: docs
-page: paper-trading
-page_title: Paper trading, live trading and the safety model
-heading: Your first live trade
-anchor: your-first-live-trade
-url: https://dexterm.xyz/docs/paper-trading#your-first-live-trade
-tags:
-  - docs
-  - paper-trading
-  - first
-  - live
-  - trade
-  - trading
-  - devnet
-  - paper
-  - safety
-  - model
-confidence: high
-owner: maintainers
-origin: docs-generated
-reviewed_by: generated@2026-10-16
-generated_from: dexterm/site content/docs (task-1420)
-sources:
-  - site/content/docs/paper-trading.md
-date: 2026-10-16
----
-
-A walkthrough for one small, real swap inside the default caps. It is the path the verifier follows with a devnet signer (every step up to the confirm behaves the same, and the devnet wall above is where it stops) and on fixtures; nobody has yet run it to a mainnet fill, and nothing here is advice to.
-
-1. **Link your wallet.** `dexterm wallet link` opens Phantom on a loopback page; connect and sign the nonce. `dexterm wallet status` shows the public key. dexterm never sees a key.
-2. **Fund a small mainnet wallet.** Use a wallet that holds only what you are willing to lose plus fees: for a $5 trade at SOL $108 that is about 0.06 SOL (0.046 for the swap, the rest for the token-account rent of 0.00204 SOL, network and priority fees and a reserve). The per-trade cap is $5 and the daily cap $20 by default; the hard ceilings are $500 and $2000 and only `--mainnet` can raise anything.
-3. **Start on mainnet with the caps you mean.** `dexterm --mainnet --max-usd 5` (add `--daily-usd 20`, `--max-sol-out 1`, `--max-slippage-bps 500` to be explicit). The ticket header turns red: `⚠ LIVE · MAINNET — REAL FUNDS · caps $5/trade $20/day`. The signer process starts on the first LIVE action with exactly these flags, classifies the network from the RPC it talks to, and needs two independent SOL/USD sources within 3% before it will price anything.
-4. **Open a ticket and size it under the cap.** `B` on a token, `L` to flip LIVE, type a size; watch the cap line and press `f` if it is red (it sets the largest size that fits, fees and rent included). Slippage stays at 50 bps unless you change it; impact over 3% is refused.
-5. **Build the plan.** `⏎`. If Jupiter rate-limits, the ticket waits and retries by itself (`r` now, `esc` cancels). The PLAN lists what will be signed, what you pay and receive, the minimum received, the fee, the route, the simulation result (how much SOL leaves your wallet), the SOL/USD price and its sources, and the caps verdict; `within caps` means the signer will not refuse it at this moment.
-6. **Confirm.** `Y`. The signer re-checks the caps, reserves the USD on the daily ledger, opens the sign page. The page **connects first** (a Connect prompt the first time on this origin, silent after that), shows the connected account and refuses one that is not the linked wallet (`Phantom is on account … but dexterm linked …`), then asks Phantom to sign; approve in Phantom. If Phantom answers 4100 ("not authorized") the page says so and what to do: press Approve again and accept the Connect prompt, or allow `127.0.0.1:41291` under Phantom's Trusted apps, then confirm the trade again in dexterm; nothing was signed. The signed bytes must be the same message with your signature (a Lighthouse tail appended by Phantom is the one tolerated change); they are decoded, policy-checked, bound and re-simulated with fresh balances, then submitted and confirmed.
-7. **Expected outcome.** `✓ LIVE MAINNET BUY confirmed — 0.0144 AVGOx @ 2.778 SOL · sig …` with the signature; the position appears under the chart marked live and on the positions screen under LIVE POSITIONS; the daily ledger shows the spend (`Caps … spent $4.32`). A refusal (`✗ REFUSED by the signer — per-trade-cap: …`) means nothing was signed or sent. `send-unknown` with a signature means the transaction may have been broadcast: check the explorer, do not resend.
-8. **Panic key.** `/wallet panic` in the app or `dexterm wallet panic` from any shell disables live signing everywhere at once (kill-switch file, locked ledger, plans forgotten). `dexterm wallet resume` on a real TTY is the only way back.
-9. **Read the journal.** `dexterm wallet status` shows the linked key, the signer's network and caps, today's spend and the panic state. Confirmed real fills live in `~/.dexterm/live-trades.sqlite` (the signer's own ledger, read by the positions screen); the daily USD reservations in the shared cap ledger `~/.dexterm/caps.sqlite`; the signer's log lines (including the full text of any failed simulation) go to the app log. Order plans, if you use them, append to `~/.dexterm/plans.journal`, which `dexterm plan journal --verify` recomputes.