dexterm-cli 0.1.4 → 0.1.6

package/dist/packages/mcp/assets/kb/docs/docs-getting-started-install.md

@@ -23,6 +23,16 @@ sources:
 date: 2026-10-16
 ---
 
+The repository README's short path is: choose one installer, then start dexterm.
+
+```sh repository quick start
+$ npm i -g dexterm-cli
+$ brew install dexterm-xyz/dexterm/dexterm
+$ dexterm
+```
+
+Do not run both install lines. The first is npm; the second is the one-line Homebrew alternative for macOS.
+
 ```sh install with npm
 $ npm i -g dexterm-cli
 $ dexterm doctor
@@ -31,10 +41,10 @@ $ dexterm doctor
 The package is named `dexterm-cli` because npm refuses the name `dexterm` as too similar to `xterm`. The command it installs is `dexterm`. The package ships compiled JavaScript, so it needs no build step. Every GitHub release carries a build-provenance attestation and `SHA256SUMS` you can verify (see the trust page (https://dexterm.xyz/trust/)).
 
 ```sh install from the release
-$ # download dexterm-0.1.3-src.tar.gz and SHA256SUMS from the releases page, then:
+$ # download dexterm-0.1.6-src.tar.gz and SHA256SUMS from the releases page, then:
 $ shasum -a 256 -c SHA256SUMS --ignore-missing
-$ gh attestation verify dexterm-0.1.3-src.tar.gz --repo dexterm-xyz/dexterm
-$ tar -xzf dexterm-0.1.3-src.tar.gz && cd dexterm-0.1.3
+$ gh attestation verify dexterm-0.1.6-src.tar.gz --repo dexterm-xyz/dexterm
+$ tar -xzf dexterm-0.1.6-src.tar.gz && cd dexterm-0.1.6
 $ ./install.sh
 $ dexterm doctor
 ```

package/dist/packages/mcp/assets/kb/docs/docs-getting-started-requirements.md

@@ -32,4 +32,4 @@ date: 2026-10-16
 | optional: a free RPC key | the ranked top-20 holder list and faster chain reads | Helius, Alchemy, QuickNode or Ankr free tier; see configuration (https://dexterm.xyz/docs/configuration). |
 | optional: Rust (`cargo`) | the native docked chart window | without it the chart popup opens in your browser; see popup chart (https://dexterm.xyz/docs/popup-chart). |
 
-> note: dexterm 0.1.3 is out (2026-10-16), open source under AGPL-3.0-only at github.com/dexterm-xyz/dexterm (https://github.com/dexterm-xyz/dexterm). It is early: trading is experimental and has known bugs. The release ships checksums, a build-provenance attestation and an SBOM, and its VirusTotal result (including flags we explain) is on the trust page (https://dexterm.xyz/trust/). It is also on npm as `dexterm-cli` (https://www.npmjs.com/package/dexterm-cli); the command it installs is still `dexterm`.
+> note: dexterm 0.1.6 is out (2026-10-20), open source under AGPL-3.0-only at github.com/dexterm-xyz/dexterm (https://github.com/dexterm-xyz/dexterm). It is early: trading is experimental and has known bugs. The release ships checksums, a build-provenance attestation and an SBOM, and its VirusTotal result (including flags we explain) is on the trust page (https://dexterm.xyz/trust/). It is also on npm as `dexterm-cli` (https://www.npmjs.com/package/dexterm-cli); the command it installs is still `dexterm`.

package/dist/packages/mcp/assets/kb/docs/docs-getting-started-running-the-tests.md

@@ -25,7 +25,7 @@ sources:
 date: 2026-10-16
 ---
 
-From a source checkout, `npm install` and then `npm test` runs the typecheck and three test lanes, in order (from 0.1.4, not in a release yet):
+From a source checkout, `npm install` and then `npm test` runs the typecheck and three test lanes, in order (since 0.1.4):
 
 - **parallel**: every `packages/*/test/*.test.ts` file at once, one process each.
 - **serial** (`npm run test:serial`, `packages/*/test/serial/`): the tests that drive a real terminal through a pty, run the real binary, or assert a wall-clock bound (the under-a-second quit, the 50 ms filter fuzz). They run one file at a time after the parallel lane, so they never share the CPU with it.

package/dist/packages/mcp/assets/kb/docs/docs-getting-started-supported-platforms.md

@@ -30,8 +30,8 @@ This table says what each platform has actually been through, not what we expect
 |---|---|---|
 | Linux x64, Node 22 and 24 | tested | the full suite on every push in CI (Ubuntu), and the same steps in Docker (`node:22-bookworm`, `node:24-bookworm`), including the install smoke |
 | macOS on Intel | tested | the full suite on every change, the install smoke, and a Homebrew install (slow: Homebrew builds Node from source on Intel) |
-| macOS on Apple Silicon | not yet tested | a CI leg on an Apple Silicon runner (`macos-14`) and a manual Homebrew job (tap, trust, install, `brew test`) are written and lint clean; they run for the first time with the next release |
-| Windows x64 | experimental, not yet tested | a CI leg (`windows-latest`) is written: typecheck and the install smoke must pass, the test suite may fail without failing the run. It has not run yet. Known gaps are listed below |
+| macOS on Apple Silicon | tested in CI (0.1.4) | the full suite on an Apple Silicon runner (`macos-14`) passed on the 0.1.4 release candidate. The manual Homebrew job (tap, trust, install, `brew test`) has not run yet |
+| Windows x64 | experimental, tested in CI (0.1.4) | the `windows-latest` leg runs the full suite and it passed on the 0.1.4 release candidate (a few tests that need POSIX file permissions or Unix-only tools are skipped, and ACL-based file isolation is not verified). Known gaps are listed below |
 | WSL2 | not tested separately | it is Linux, so expect the Linux behaviour |
 
 Known gaps on Windows (none of them affect key safety: dexterm never holds a wallet key on any platform):

package/dist/packages/mcp/assets/kb/docs/docs-larp-measured-accuracy.md

@@ -25,12 +25,11 @@ date: 2026-10-16
 
 **The part of the LARP check that can be replayed on history is weak, and the model stage cannot be replayed at all. dexterm prints only what it measured, including the weak numbers.**
 
-The public measurement scorecard (https://dexterm.xyz/scorecard/) is generated directly from the checked-in research JSON. It includes the held-out dataset, confidence intervals, rolling skill-care result, frozen canary and every currently unmeasured stage; the weak 0.054 links-only MCC is not rounded into a favorable claim.
-
 **Skills backtest (0.1.2).** `dexterm backtest --subject skills` replays the replayable parts of the default analyst skills on recorded history: 1,054 coins from the project's recorder, labelled by a 72 h keyless outcome (bad = rug or dead). Tuning only ever sees the train split; the numbers below are the later, held-out test split of 328 coins, of which 18.6 % went bad.
 
 - **LARP check, links only.** The links-based baseline is a weak signal: MCC 0.039 before tuning, 0.054 after. Its tuned `LARP` grade caught 4 of 14 bad coins, too few to rate. `EARLY_BUT_REAL` coins still went bad 10.3 % of the time, and coins with no website 29.2 %. The skill now treats the baseline as a weak prior and never calls `LARP` from links alone.
 - **Rug check.** The verdict rules improved from MCC 0.043 to 0.159. Liquidity under $5k is the one strong signal (`SPECULATIVE` coins went bad 54.8 % of the time, `WATCH` 14.4 %). Dev percentage, organic score and top-10 share did not predict a worse 72 h outcome and now only lower confidence.
+- **LARP score, link-shape part** (`dexterm backtest --subject larp-score`, task-1471). Points fitted on the train split only. On the 328 held-out coins its AUROC is 0.69 (0.73 on train): a modest ranking signal. 27 of 218 low-band coins went bad (12.4 %), 34 of 110 medium-band coins (30.9 %), against 18.6 % overall; no coin reaches the high band from link shape alone. The page, domain, GitHub and X points are not measured: that evidence was not recorded at the time, and looking it up now would leak the outcome (dead coins' sites and accounts disappear).
 - **Not measured.** The model stage (fetched pages, RDAP, GitHub) cannot be replayed: a past page cannot be fetched as it was. It is measured going forward with `dexterm backtest --subject larp`, below.
 
 The method, every number and the limits are in the repository at `packages/packs/eval/README.md`. A grade is a risk flag, not a certificate.

package/dist/packages/mcp/assets/kb/docs/docs-larp-the-larp-score.md

@@ -0,0 +1,60 @@
+---
+id: docs-larp-the-larp-score
+title: LARP detector › The LARP score
+kind: docs
+page: larp
+page_title: LARP detector
+heading: The LARP score
+anchor: the-larp-score
+url: https://dexterm.xyz/docs/larp#the-larp-score
+tags:
+  - docs
+  - larp
+  - score
+  - detector
+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/larp.md
+date: 2026-10-16
+---
+
+`larp_check` also returns a **LARP score from 0 to 100**: the sum of named flags, each with its points and the evidence that raised it. Higher means more of the things that went with LARP coins showed up. It summarises the flags; it is not a verdict and does not replace the one above.
+
+| band | score | |
+|---|---|---|
+| low | under 25 | few flags |
+| medium | 25 to 49 | several flags; link shape alone tops out here |
+| high | 50 or more | needs page, domain, GitHub or X evidence, not link shape alone |
+
+| flag | points | weight |
+|---|---|---|
+| no Telegram advertised | 12 | fitted |
+| no X account advertised | 10 | fitted |
+| no website advertised | 9 | fitted |
+| X link is a single post or a community, not an account | 5 | fitted |
+| the "website" is a social page | 1 | fitted |
+| the domain does not name the token · throwaway-priced TLD | 0 | fitted (did not go with bad outcomes, so not listed) |
+| launchpad / link-hub / free-host page as the website | 4 / 2 / 2 | prior (too rare to fit) |
+| sources advertise different sites or X accounts | 8 | prior |
+| wallet-drainer markers on the page | 30 | prior |
+| default or placeholder page | 15 | prior |
+| asks to connect a wallet · never names the token | 8 · 8 | prior |
+| domain under 30 days old · registrant privacy | 8 · 2 | prior |
+| no GitHub advertised · archived · a fork · no push in 180 days | 2 · 4 · 4 · 4 | prior |
+| X account suspended · does not exist | 20 · 15 | prior |
+| X account under 7 days old (or under 30 days) | 12 (6) | prior |
+| under 50 followers · no posts in 30 days | 5 · 6 | prior |
+| the website's X link and the advertised account differ | 10 | prior |
+| a linked post now shows another handle · the account does not link the site | 5 · 3 | prior |
+
+**Fitted** points come from the recorded history below (link shape is the only part of the check that history can replay). **Prior** points were written from the skill's rules before any data and are labelled `prior` in every result.
+
+**Missing data never lowers the score.** A page that could not be read, an RDAP or X lookup that failed, goes to a `missing` list with the points it could have added, and the result shows the range: "37, could be up to 58". Nothing unread is scored as clean.
+
+Where it shows: the `larp_check` MCP result (`score`, `band`, and `larp_score` with every flag, its points, its weight and its evidence, the range and the `missing` list; the existing fields are unchanged), the analyst panel after a LARP check (a gauge with the three biggest reasons, drawn from the tool's own result, never from the model's text).
+
+> warn: a LARP verdict is a risk flag, not a certificate. Public HTML cannot prove a working product, a team's identity or who owns an account; domain age, a clean script scan and a GitHub with commits are evidence, not proof, and a real product can still go to zero.

package/dist/packages/mcp/assets/kb/docs/docs-larp-the-verdict.md

@@ -25,5 +25,3 @@ date: 2026-10-16
 The `larp-check` skill returns a structured assessment: `REAL_PRODUCT` · `EARLY_BUT_REAL` · `LARP` · `UNVERIFIABLE` · `AMBIGUOUS`, with a confidence, a status per claim (supported, contradicted, unverifiable), `missing_data`, the facts and flags it used, `injection_detected` and a short summary. It is separate from the dossier's risk verdict and does not replace it.
 
 Once computed, a badge appears in the screener's FLAGS column and in the token screen's title strip for that mint only: **LARP** (red), **REAL** (green), **REAL?** (mixed), **UNKNOWN** for unverifiable or ambiguous. Nothing shows before you vet a coin. A `LARP` verdict also vetoes an AI scan (https://dexterm.xyz/docs/scan) lock on that coin.
-
-> warn: a LARP verdict is a risk flag, not a certificate. Public HTML cannot prove a working product, a team's identity or who owns an account; domain age, a clean script scan and a GitHub with commits are evidence, not proof, and a real product can still go to zero.

package/dist/packages/mcp/assets/kb/docs/docs-larp-what-it-looks-at.md

@@ -29,5 +29,8 @@ date: 2026-10-16
 | the domain | RDAP lookup of the exact advertised domain (`check_domain`) | registration age, registrar, registrant privacy. A days-old domain behind privacy is a mild signal, not proof. Novelty TLDs without an RDAP server come back as unverifiable. |
 | GitHub | the keyless GitHub API (`check_github`) for a `github.com/owner/repo` link | created and last-push dates, stars, open issues, archived or fork, up to five real commit hashes with dates |
 | pump.fun metadata | the metadata URI GoPlus reports, through the same safe fetch | the advertised description and links, when they exist |
+| the X account | a keyless public lookup (`check_x`): FxTwitter, then vxtwitter's cached copy, then X's own oEmbed. No login, no API key, one handle per check, cached 30 minutes, at least a second between calls to each host | whether the account exists, is suspended or is gone; when it was created; followers, following and posts; the last post date; whether the bio names the token and links the site; whether the website's own X link matches the advertised one; and, for a link to a single post, whether that post now shows another handle |
 
-X is usually login-walled keyless, so account age and follower counts are reported as unverifiable rather than guessed. Every fetched string reaches the model through the prompt firewall: normalised, control and bidi characters stripped, URLs and addresses masked, wrapped as untrusted data, tags stripped so a planted closing tag cannot break out.
+**How the X lookup decides.** No single source is trusted on its own. On 2026-10-19 FxTwitter answered "user not found" for accounts that exist on roughly one call in six, so one "not found" is never enough: an account is `not_found` only when two independent sources (vxtwitter and X oEmbed) agree, `suspended` when a source says so, and otherwise `unavailable`. vxtwitter serves a cached copy, so its counts carry the time it was taken. Nitter-style mirrors and the X embed timeline were down or rate-limited every time and are not used. Each source has a circuit breaker and backs off when it keeps failing. Anything the lookup could not read is listed as unavailable, never guessed and never counted as clean. The bio is untrusted text like any page.
+
+Every fetched string reaches the model through the prompt firewall: normalised, control and bidi characters stripped, URLs and addresses masked, wrapped as untrusted data, tags stripped so a planted closing tag cannot break out.

package/dist/packages/mcp/assets/kb/docs/docs-larp.md

@@ -19,6 +19,6 @@ sources:
 date: 2026-10-16
 ---
 
-Vet the product behind a coin: its website, domain registration and GitHub, read-only, only when you ask.
+Vet the product behind a coin: its website, domain registration, GitHub and X account, read-only, only when you ask, with a 0-100 LARP score that shows every point.
 
 A memecoin's advertised website, X and Telegram are claims. The LARP detector fetches what it can, reads it mechanically, and lets the analyst grade the claims against what it found. It runs only when you press `V` on a live token; nothing is fetched automatically.

package/dist/packages/mcp/assets/kb/docs/docs-paper-trading-letting-an-agent-paper-trade-experimental.md

@@ -0,0 +1,32 @@
+---
+id: docs-paper-trading-letting-an-agent-paper-trade-experimental
+title: Paper trading, live trading and the safety model › Letting an agent paper trade (experimental)
+kind: docs
+page: paper-trading
+page_title: Paper trading, live trading and the safety model
+heading: Letting an agent paper trade (experimental)
+anchor: letting-an-agent-paper-trade-experimental
+url: https://dexterm.xyz/docs/paper-trading#letting-an-agent-paper-trade-experimental
+tags:
+  - docs
+  - paper-trading
+  - letting
+  - agent
+  - paper
+  - trade
+  - experimental
+  - trading
+  - live
+  - 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
+---
+
+If you want to, you can let an agent connected over `dexterm mcp` run the whole PAPER loop (open, size, confirm and close) inside a **trading mandate** you armed, by starting `dexterm --spectate-mcp --agent-paper <mandate-id>`. It is paper only. The agent can never sign, send a real transaction, touch keys or raise a cap, a size over your caps is refused, and you can pause, take over or stop it at any time. See Agent paper trading (https://dexterm.xyz/docs/agents#agent-paper-trading). It is experimental and off by default, and simulated figures are not a result.

package/dist/packages/mcp/assets/kb/docs/docs-paper-trading-order-plans-and-standing-mandates.md

@@ -33,12 +33,4 @@ Merged 2026-10-11 (`task-1355`) and labelled **in progress**: the engine, the ty
 
 An **order plan** is "buy this coin if it dips to 300k market cap, sell half at 600k, keep the rest as a moon bag", written down once: one entry trigger (market cap or price, below or above, or immediate), a ladder of take-profit tranches (each an above-trigger with a fraction; whatever the fractions leave is the moon bag), an optional stop (a below-trigger, below the entry), slippage and impact ceilings and an expiry (4 h by default, 7 days at most). `dexterm plan propose --mint M --size 20 --entry mc-below:300k --tp mc-above:600k:50% --stop mc-below:150k` writes one; so does saying it to Jarvis (https://dexterm.xyz/docs/voice) or an agent's `propose_order_plan` tool. All three produce the same thing: an **inert proposal** with a SHA-256 hash of its material fields and a plain-language read-back. A proposal fires nothing.
 
-A **standing mandate** is the budget a set of plans may spend: a total, a per-trade cap, a per-coin cap, a daily-loss cap, the highest confirmation tier it accepts and a time-to-live. Every cap is clamped to a hard ceiling ($2000 total, $500 per trade, $1000 per coin, $2000 daily loss, 24 h) and nothing is ever coerced upward: there is no "raise cap" anywhere; a different cap is a new draft that needs a new arming gesture. `dexterm mandate draft --total 100 --per-trade 20 --ttl-hours 4` writes one.
-
-**Arming** a plan under a mandate is the only step that lets anything fire, and it is a physical gesture: a key held at the terminal on the `O` screen (`a`) or `dexterm plan arm <id> --mandate <id>` on a real TTY, which refuses a pipe or a subprocess. The gesture proof is bound to the plan hash, single-use and expiring, so an edited plan voids every earlier confirmation. Once armed, a monitor fed by the prices the terminal already shows (the screener rows, the watchlist, the open token; never fixture data) fires the entry, each take-profit tranche and the stop **only inside the armed plan and only through the executor**, which re-checks the mandate caps on every fill (and, on the live path, the signer re-checks its own caps, allow-lists and the panic marker on top). `dexterm plan amend <id> --size 25 --entry mc-below:280k` edits a **proposed** plan: the edit is a new plan with a new hash, the old proposal is superseded and every earlier confirmation is void, so arming it is a new keypress; an armed plan cannot be edited (cancel it first). Cancel (`c`), revoke (`r`) and panic (`!`, or `dexterm wallet panic`) stop a plan at once; nothing resumes a paused plan without a new keypress.
-
-Two **confirmation tiers** beyond the keypress exist in the model and are off by default: `ptt-held` (push-to-talk held while you speak the confirmation) fires at 0.5× the per-trade cap and `hands-free` at 0.25×, and neither can arm a mandate or a batch. Turning hands-free on is the only "less safe" switch in dexterm: `G` on the `O` screen raises a prompt that says so, it is accepted by a keypress only (a spoken, agent or Phantom "yes" is refused), it is journaled, it expires after 24 h and `G` again restores the gate.
-
-The **journal** (`~/.dexterm/plans.journal`) is append-only and hash-chained; every proposal, arm, fire, fill, cancel, revoke, gate change and refusal is a row, `dexterm plan journal --verify` recomputes the chain and `--export` dumps it, and it is the source the service recovers from after a crash. The popup is a read-only HUD fed view models only (never a key, a secret or an arm capability); its single write is "cancel this plan", re-validated at the server allow-list and again at the terminal.
-
-What is proven, on fixtures and a fake clock: the north-star plan fills end to end on the paper executor; a replayed price stream fires each leg once; and a compromised-model suite shows that spoken text, agent text, a forged proof, a replayed proof, a widened mandate and an edited plan with an old confirmation all fail to arm, raise a cap, widen a mandate, resume a paused plan, accept the risk prompt or switch the fire path.
+A **standing mandate** is the budget a set of plans may spend: a total, a per-trade cap, a per-coin cap, a daily-loss cap, the highest confirmation tier it accepts and a time-to-live. Every cap is clamped to a hard ceiling ($2000 total, $500 per trade, $1000 per coin, $2000 daily loss, 24 h) and nothing is ever coerced upward: there is no "raise cap" anywhere; a different cap is a new draft that needs a new arming gesture. `dexterm mandate draft --total 100 --per-trade 20 --ttl-hours 4` writes one; `--max-open N` and `--max-impact PCT` set the open-position and price-impact limits (clamped the same way).

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

@@ -0,0 +1,41 @@
+---
+id: docs-paper-trading-paper-only-mandates
+title: Paper trading, live trading and the safety model › Order plans and standing mandates › Paper-only mandates
+kind: docs
+page: paper-trading
+page_title: Paper trading, live trading and the safety model
+heading: Paper-only mandates
+anchor: paper-only-mandates
+url: https://dexterm.xyz/docs/paper-trading#paper-only-mandates
+tags:
+  - docs
+  - paper-trading
+  - paper-only
+  - mandates
+  - order
+  - plans
+  - standing
+  - paper
+  - trading
+  - live
+  - 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 mandate draft --paper` drafts a **paper-only** mandate for agent paper trading (https://dexterm.xyz/docs/agents#agent-paper-trading). It has its own, higher paper ceilings ($10,000 total, $2000 per trade, $2000 per coin, $10,000 daily loss, 10% price impact) so an agent can practise at a realistic size, and it still needs your physical keypress to arm. Only the agent paper desk reads it: the plan engine refuses to arm a plan into it, fire a plan under it or run copy trading through it, so it can never reach a signer, and every other mandate keeps the ceilings above. The agent still gets a quarter of its per-trade cap, and every fill is priced on a live quote, so a bigger simulated size pays its real price impact.
+
+**Arming** a plan under a mandate is the only step that lets anything fire, and it is a physical gesture: a key held at the terminal on the `O` screen (`a`) or `dexterm plan arm <id> --mandate <id>` on a real TTY, which refuses a pipe or a subprocess. The gesture proof is bound to the plan hash, single-use and expiring, so an edited plan voids every earlier confirmation. Once armed, a monitor fed by the prices the terminal already shows (the screener rows, the watchlist, the open token; never fixture data) fires the entry, each take-profit tranche and the stop **only inside the armed plan and only through the executor**, which re-checks the mandate caps on every fill (and, on the live path, the signer re-checks its own caps, allow-lists and the panic marker on top). `dexterm plan amend <id> --size 25 --entry mc-below:280k` edits a **proposed** plan: the edit is a new plan with a new hash, the old proposal is superseded and every earlier confirmation is void, so arming it is a new keypress; an armed plan cannot be edited (cancel it first). Cancel (`c`), revoke (`r`) and panic (`!`, or `dexterm wallet panic`) stop a plan at once; nothing resumes a paused plan without a new keypress.
+
+Two **confirmation tiers** beyond the keypress exist in the model and are off by default: `ptt-held` (push-to-talk held while you speak the confirmation) fires at 0.5× the per-trade cap and `hands-free` at 0.25×, and neither can arm a mandate or a batch. Turning hands-free on is the only "less safe" switch in dexterm: `G` on the `O` screen raises a prompt that says so, it is accepted by a keypress only (a spoken, agent or Phantom "yes" is refused), it is journaled, it expires after 24 h and `G` again restores the gate.
+
+The **journal** (`~/.dexterm/plans.journal`) is append-only and hash-chained; every proposal, arm, fire, fill, cancel, revoke, gate change and refusal is a row, `dexterm plan journal --verify` recomputes the chain and `--export` dumps it, and it is the source the service recovers from after a crash. The popup is a read-only HUD fed view models only (never a key, a secret or an arm capability); its single write is "cancel this plan", re-validated at the server allow-list and again at the terminal.
+
+What is proven, on fixtures and a fake clock: the north-star plan fills end to end on the paper executor; a replayed price stream fires each leg once; and a compromised-model suite shows that spoken text, agent text, a forged proof, a replayed proof, a widened mandate and an edited plan with an old confirmation all fail to arm, raise a cap, widen a mandate, resume a paused plan, accept the risk prompt or switch the fire path.

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

@@ -32,6 +32,6 @@ 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 only write-shaped tool opens a PAPER ticket, and a test proves that even on a live-capable context it yields a paper ticket and the signer is never called. The scan mode and the MCP server import nothing signer-shaped.
+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-popup-chart-market-cap-axis.md

@@ -25,4 +25,4 @@ sources:
 date: 2026-10-16
 ---
 
-When the terminal is in market cap mode (https://dexterm.xyz/docs/configuration#price-display-mode) (`$`), the popup follows it within a tick: the Y axis, the last-value and position-line labels, the EMA / VWAP values and the header read **market cap** in K / M / B (`300K`, `1.2M`), and the crosshair legend shows the market cap with the price in parentheses (`C 1.2M ($0.0₃12)`). The window title says `mcap (current supply)`: every bar is scaled by today's supply (market cap ÷ price at the latest tick, as the terminal knows it), so older bars are not the exact market cap of their time. The bars themselves stay USD prices, so the entry, stop and target lines and the fill markers keep their meaning; only the labels change. When the coin has no known supply the popup keeps prices and the title says `supply unknown · showing price`. The position row reads AVG MC / MCAP; profit and loss stay in USD.
+The Y axis shows **market cap by default**. The **MCAP | PRICE** control in the toolbar, `A` or `y` in the popup, or `A` on the terminal's token screen switches it; the terminal saves the choice (`display.chartAxis`, see chart Y axis (https://dexterm.xyz/docs/configuration#chart-y-axis)) and the popup follows within a tick. In market cap the Y axis, the last-value and position-line labels (ENTRY, STOP, TARGET), the EMA / VWAP values and the header read **market cap** in compact form with a lowercase k (`4.9k`, `487k`, `1.2M`, `1.3B`), and the crosshair legend shows the market cap with the price in parentheses (`C 1.2M ($0.0₃12)`). The volume pane stays USD, also compact (`$20k`). In price mode the axis uses the subscript form for tiny prices (`0.0₅493`), never scientific notation. The window title says `mcap (current supply)`: every bar is scaled by today's supply (market cap ÷ price at the latest tick, as the terminal knows it), so older bars are not the exact market cap of their time. The bars themselves stay USD prices, so the entry, stop and target lines and the fill markers keep their meaning; only the labels change. When the coin has no known supply the popup keeps prices and the title says `price (mcap unavailable)`. The position row reads AVG MC / MCAP; profit and loss stay in USD.

package/dist/packages/mcp/assets/kb/docs/docs-popup-chart-what-it-shows.md

@@ -27,4 +27,5 @@ date: 2026-10-16
 - the last-price line, and a dotted **LIVE** price line while the terminal's fast lane is streaming the coin; a `◌ STALE Ns` badge when no tick has arrived for 20 s.
 - buy and sell markers from the trade tape, EMA 9/21, VWAP (anchored to the UTC day), a volume 20-MA, horizontal and trend lines you draw (page memory only; they go when the popup closes).
 - when you hold a PAPER position in the coin: an ENTRY line labelled with size and PnL %, BUY and SELL fill markers for the current position, STOP and TARGET lines when a ledger sets them, and the same position row the terminal shows under its chart.
+- while an auto mode runs and a position is open (an agent you follow holds a PAPER position, or AI scan mode with your own position), the PnL chip (https://dexterm.xyz/docs/spectator#the-brain-view-and-the-pnl-chip) under the toolbar, with the same fields as the terminal's. It is about the held coin, which need not be the coin on the chart. Display only.
 - the six timeframes are the popup's own. 5m and 15m are derived from the cached 1m base, 4h and 1d from the cached 1h base, so switching costs no fetch; a base the terminal has not fetched yet shows an honest "warming … no extra requests" banner until it lands. **1s is not offered:** the only trade source is a ≤60-trade tape refreshed at most every 20 s, so 1-second bars would be sparse and stale.

package/dist/packages/mcp/assets/kb/docs/docs-scan-the-read.md

@@ -23,3 +23,5 @@ date: 2026-10-16
 ---
 
 A lock opens the coin exactly as `⏎` would (the same loader, the same fetches that token costs anyway) and starts a chat turn asking for the short read, with the WHY reasons passed as **numbers only, never token text**. Refreshes ask the same warm session what changed. Answers follow the short style (https://dexterm.xyz/docs/analyst#answer-style): call, why, levels, size, one risk.
+
+While the scan is on, the token screen's analyst panel is the scan's **brain view** (on the locked coin, or on any coin while it is still scanning). It shows the scan's own log (on, locks with their score and reasons, refreshes, releases, cancels and blocked actions) with the scan analyst's answer streaming under it, the vetting checklist and data strip for the coin with the app's numbers, and a `SCAN LOG` with `locks · reads · ai usage · observe-only · never trades`. It is the same layout as the agent brain view (https://dexterm.xyz/docs/spectator#the-brain-view-and-the-pnl-chip), with no position block, because the scan never trades. Typing into the analyst, or stopping the scan, brings the normal panel back. While the scan runs and you hold a paper or live position yourself, the PnL chip (https://dexterm.xyz/docs/spectator#the-brain-view-and-the-pnl-chip) shows it on the band under the header of every screen and on the chart popup. It shows the coin the scan locked if you hold it, otherwise the coin on screen, otherwise your first open position. The peak is this session's highest mark, and TP is the ledger's target (`TP not set` when there is none). The scan still never trades.

package/dist/packages/mcp/assets/kb/docs/docs-screens-dev-history.md

@@ -0,0 +1,47 @@
+---
+id: docs-screens-dev-history
+title: Screens tour › Dev history
+kind: docs
+page: screens
+page_title: Screens tour
+heading: Dev history
+anchor: dev-history
+url: https://dexterm.xyz/docs/screens#dev-history
+tags:
+  - docs
+  - screens
+  - dev
+  - history
+  - tour
+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/screens.md
+date: 2026-10-16
+---
+
+*Since 0.1.5.* "Has this deployer rugged before?" The ON-CHAIN panel adds the creator's **recorded** track record, from dexterm's own history recorder (https://dexterm.xyz/docs/configuration#history-recorder), keyless:
+
+| row | what it shows | example |
+| --- | --- | --- |
+| Dev rugs | rugs out of the creator's **labelled** prior launches, the sample, and how long ago the newest of those labels settled; red at two or more (the `serial_rugger` flag), `unknown` with no labelled record | `2/5 · n=5 · rec 3d` |
+| Dev launches | prior launches the recorder linked to this wallet, how long ago the newest was seen, and which feed named the creator (`jup`, `pump`, `rc`) | `n=5 · rec 2h · dev:jup` |
+| Dev sold bag | median minutes from launch to the dev's exit on prior launches (held over 0.5 % of supply, then 0.1 % or less), the sample, and the age of the newest exit seen | `med 20m · n=3 · rec 1d` |
+| Dev linked | the creator's funder or the linked cluster it sits in (same funder, same-block bundle, transfers) from the wallet-intel scan (https://dexterm.xyz/docs/screens#bubble-map), and how long ago that scan ran | `funder 3w · scan 4m` |
+| Linked dev rugs | labelled rugs by the other wallets in that cluster that dexterm saw launching coins, how many such wallets, and the age of their newest label | `1 · n=1 devs · rec 7d` |
+
+`rec` is dexterm's own recorder, `scan` the wallet-intel scan; every age is how old the newest datum behind the number is.
+
+- **Where the creator comes from.** The wallet a keyless source names when dexterm sees the coin: Jupiter's `dev` field on every token row, a PumpPortal create, or RugCheck's new-token feed. The first source wins and is recorded with the time. GoPlus is asked only by the MCP tool, as a last resort.
+- **Where the outcomes come from.** The recorder's code-only labels (rug, dead, fade, flat, runner; the 72-hour label when known, else the longest one settled). They are the keyless-proxy tier: a rug is a liquidity collapse the recorder saw, not a verified on-chain drain.
+- **Honest by construction.** Every row names its source, its sample and the age of its newest datum. No record is `unknown`, never "clean". Only coins this machine's recorder saw count, so a deployer's launches dexterm never saw are missing; run `dexterm record` (https://dexterm.xyz/docs/configuration#headless-recorder-dexterm-record) to keep it fed. It is a risk flag from observed history, never a certificate. On a window too short for every ON-CHAIN row, the red, then amber rows stay and the last line says how many rows are hidden (`+3 rows hidden`).
+- **Alerts.** The rule field `devrugs` is the creator's labelled rugs (unknown = no match). A brand-new pair from a wallet with a record joins the rule rows, so this fires on launch:
+
+```text
+when devrugs >= 2 then alert(warn, "new coin from a wallet that rugged before") scope newpairs
+```
+
+- **For agents.** The read-only `dev_history` MCP tool returns the same report by mint or creator wallet; `get_dev_history` and the dossier fill prior launches and rugs from it (tier `local-history`), so the deterministic analysis pack raises `serial_rugger` on recorded history.

package/dist/packages/mcp/assets/kb/docs/docs-screens-how-well-it-predicts-measured-held-out.md

@@ -0,0 +1,46 @@
+---
+id: docs-screens-how-well-it-predicts-measured-held-out
+title: Screens tour › Dev history › How well it predicts (measured, held out)
+kind: docs
+page: screens
+page_title: Screens tour
+heading: How well it predicts (measured, held out)
+anchor: how-well-it-predicts-measured-held-out
+url: https://dexterm.xyz/docs/screens#how-well-it-predicts-measured-held-out
+tags:
+  - docs
+  - screens
+  - well
+  - predicts
+  - measured
+  - held
+  - out
+  - dev
+  - history
+  - tour
+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/screens.md
+date: 2026-10-16
+---
+
+Measured 2026-10-18 on the history recorder's own coins, with the same held-out window as the skill backtest (https://dexterm.xyz/docs/larp) (the newest 30 % of coins by first sighting, never used to tune anything; the rule is fixed in advance: `serial_rugger` = two or more labelled rugs). Each coin is judged only on what was known at its first sighting: prior launches recorded before it, and labels already settled by then. Outcomes are the recorder's 72-hour labels (keyless-proxy tier): **rug**, and **bad** = rug or dead. The labelled history covers 2026-10-10 to 2026-10-13.
+
+- **Too few repeat deployers to measure the rug-history signal yet.** Of 9405 creator wallets behind 24724 recorded coins, 2127 launched two or more of them. In the held-out window 1 of 143 coins (skill-backtest set) and 4 of 387 (all 72-hour-labelled coins) had a creator with a prior labelled rug; across all 1289 labelled coins, 4. There is no number to publish for "a prior rug predicts a rug" until the record is longer. The panel says `unknown` in exactly this case.
+- **What the held-out window does show.** Base rates: rug 5.7% (22/387, 95% CI 3.8–8.5%), bad 41.6% (161/387, 95% CI 36.8–46.6%). Coins whose creator had labelled prior launches and no rug: rug 6.4% (5/78, 95% CI 2.8–14.1%), bad 30.8% (24/78, 95% CI 21.6–41.7%); that is a small sample and the intervals overlap the base rate, so it is not evidence that a "clean" record means anything.
+- **Exploratory, chosen after seeing the result above** (so treat it as a lead, not a finding): coins whose creator had three or more labelled prior launches, mostly *not* rug or dead, went bad 16.1% (5/31, 95% CI 7.1–32.6%) of the time in the held-out window, against 44.0% (155/352, 95% CI 38.9–49.3%) for coins with fewer labelled priors; only 4 coins had a creator whose priors were mostly bad, too few to say anything.
+- **Why so thin:** the recorder's labelled history is about a week old, and a prior launch only counts once its own label had settled before the coin was first seen.
+- **Jupiter's count of coins this dev minted** (keyless, at first sighting, held-out, 367 coins with a value; base bad rate 39.5% (145/367, 95% CI 34.6–44.6%)):
+
+| dev minted | coins | rug | bad (rug or dead) |
+| --- | --- | --- | --- |
+| 1 | 128 | 3.9% (5/128, 95% CI 1.7–8.8%) | 43.8% (56/128, 95% CI 35.5–52.4%) |
+| 2-5 | 59 | 0.0% (0/59, 95% CI 0.0–6.1%) | 20.3% (12/59, 95% CI 12.0–32.3%) |
+| 6-20 | 28 | 3.6% (1/28, 95% CI 0.6–17.7%) | 28.6% (8/28, 95% CI 15.2–47.1%) |
+| 21+ | 152 | 4.6% (7/152, 95% CI 2.2–9.2%) | 45.4% (69/152, 95% CI 37.7–53.3%) |
+
+We will re-run this as the recorder grows and publish the result, good or bad. It is a risk flag from observed history, never a certificate.

package/dist/packages/mcp/assets/kb/docs/docs-spectator-follow-over-mcp-in-the-running-terminal.md

@@ -32,7 +32,7 @@ date: 2026-10-16
 An agent connected over MCP (Claude Code, Claude Desktop, Cursor, Codex — set up with `dexterm mcp install`) runs the `dexterm mcp` server as its own process, which the app cannot see into. Since 0.1.4, run the app with `dexterm --spectate-mcp` and the running terminal **follows** that agent:
 
 - While the flag is on, the app writes a small local rendezvous under `~/.dexterm` (mode 0600). The `dexterm mcp` server notices it and starts emitting one record per tool call to a local channel the app tails. When you are not following, the file is absent and the server writes nothing — there is no cost when nobody is watching.
-- A **navigation** call (open a token, switch screen or feed, set a filter, highlight a row, open the paper ticket) moves the real screen, with a status line like `agent <name>: opened BONK`. These are the same read-only moves the analyst makes; nothing an agent does here can size, confirm, sign, send or raise a cap.
+- A **navigation** call (open a token, switch screen or feed, set a filter, highlight a row, open the paper ticket) moves the real screen. The agent HUD (https://dexterm.xyz/docs/spectator#the-agent-hud-spectator-v2) shows the move (a terminal shorter than 24 rows gets a status line like `agent <name>: opened BONK` instead). These are the same read-only moves the analyst makes; nothing an agent does here can size, confirm, sign, send or raise a cap. From 0.1.5, if you start with `--agent-paper <mandate-id>`, the agent's **simulated** trades show here too as `PAPER …` rows. They never move your screen, and Ctrl+P, Ctrl+K and taking over halt them (agent paper trading (https://dexterm.xyz/docs/agents#agent-paper-trading)).
 - The controls are at your keyboard: **ctrl+p** pauses and resumes the mirroring, **ctrl+k** stops following (it removes the rendezvous, so the server stops emitting), and **any other key** hands control back to you — the agent can never move the screen out from under you.
 - A read-only, loopback, token-gated stream opens too, so `dexterm spectate --info` shows its endpoint while you follow. Every record is authenticated by the rendezvous token before it is folded, and every shared copy is redacted (see what is redacted (https://dexterm.xyz/docs/spectator#what-is-redacted)). This is on the owner's own machine, so follow mode itself shows full detail.
 

package/dist/packages/mcp/assets/kb/docs/docs-spectator-limits.md

@@ -29,6 +29,8 @@ Stated plainly, as of `(generated from the app: see https://dexterm.xyz/docs/spe
 
 - **The AGENT ACTIVITY window is a separate window with its own screen model.** Its `screen` line shows the screen the agent *asked for*, built from its navigation events, and the bus runs in its own process (`dexterm agent serve`), so that window is not a mirror of your terminal. The running terminal itself **does** move when you follow with `dexterm --spectate-mcp` (follow mode) — that is a different surface from the popup window.
 - **MCP agents are shown in follow mode, which you turn on.** Agents connected through `dexterm mcp` (Claude Code, Claude Desktop, Cursor or Codex, set up with `dexterm mcp install`) appear once you run the app with `dexterm --spectate-mcp`; the terminal then follows them and a read-only stream opens. Without the flag the MCP server emits nothing. The built-in analyst drives the terminal through its own action channel and shows `analyst did X`.
+- **The thought ribbon only shows what the agent writes down.** dexterm cannot read an agent's mind: without `--spectate-thoughts FILE`, the ribbon narrates the calls themselves. The agent label in the dock is the one this terminal gives it (`mcp-agent`); the MCP server does not tell the app which client is calling.
+- **The mark PnL is approximate.** It is the move of the coin's price since the paper entry, at this terminal's last price for it (or the last price a tool call returned), before fees. The paper ledger's own numbers are on the fill, the position panel and the result card.
 - **Replay is text.** `dexterm spectate --replay` prints the session in the terminal. It does not reopen the window.
 - **No stream viewer ships.** The raw stream is for your own tooling.
 - **Redaction matches patterns.** It masks anything shaped like an address or a key. Other text, such as a token symbol, a filter or a number, is shown as it is.

package/dist/packages/mcp/assets/kb/docs/docs-spectator-the-agent-hud-spectator-v2.md

@@ -0,0 +1,58 @@
+---
+id: docs-spectator-the-agent-hud-spectator-v2
+title: Spectator view (watch the agent cook) › Follow over MCP in the running terminal › The agent HUD (spectator v2)
+kind: docs
+page: spectator
+page_title: Spectator view (watch the agent cook)
+heading: The agent HUD (spectator v2)
+anchor: the-agent-hud-spectator-v2
+url: https://dexterm.xyz/docs/spectator#the-agent-hud-spectator-v2
+tags:
+  - docs
+  - spectator
+  - agent
+  - hud
+  - follow
+  - over
+  - mcp
+  - running
+  - terminal
+  - view
+  - watch
+  - cook
+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/spectator.md
+date: 2026-10-16
+---
+
+While the terminal follows an MCP agent, it shows the agent working, not a list of calls. The app's own screen renders a few rows shorter, so nothing of it is hidden, and an **agent dock** sits under it:
+
+- **The heartbeat and the phase rail.** A heartbeat trace beats faster as the agent calls more tools. The rail `SCANNING ─ VETTING ─ SIZING ─ EXECUTING ─ HOLDING ─ EXITING` lights the phase it is in. While it holds a position and checks other coins, the rail stays on HOLDING and shows the side activity next to it.
+- **The thought ribbon.** The agent's own words, typed in as it thinks, when you pass `--spectate-thoughts FILE` (see below). Otherwise dexterm narrates what each call did, from the call's own numbers ("scanning 12 rows · 3 moving up", "verdict WATCH · rug heuristic 11%").
+- **The call timeline.** Each call is a node, newest on the right, spaced by the time between calls. Under each node is a result chip: green for ok, amber for slow, red for a failure or a refusal. PAPER calls are marked.
+- **`PAPER` and the controls are always on screen**: **^P** pause, **^K** kill.
+
+Over the screen itself:
+
+- The **rows the agent scans glow**, with a beam sweeping down them. The row it opens gets the **agent cursor** (`▶ … ◀ AGENT`), and the token screen assembles top-down as it opens.
+- A **vetting card** fills in the checks the agent ran (price, tape, chart, holders, rug, dev, LARP, verdict). Its **LARP gauge** sweeps to the number of evidence flags `larp_check` found; that number is evidence, not a verdict.
+- **The PAPER execution moment** (with `--agent-paper`): an order ticket assembles with the size, your per-trade cap and the gate as it really is (your keypress armed the mandate; inside it there is no keypress per paper trade, and the desk enforces the caps). Then the fill lands with a flash and the entry from the paper fill, and the ticket turns into a **position panel**. That panel shows the mark PnL as a big number with a trace, the peak and the time held. The mark is this terminal's own price for the coin, or the price a tool call returned, never a number the agent typed. Each exit flashes. When the position is flat, a **result card** shows the realized PAPER result, the hold time and the exits.
+- **Kill is a hard stop.** **^K** cuts the screen with a red flash and a short glitch, stamps `KILLED`, closes the agent's session and stops its paper desk for the rest of the run. The dock then stays on `AGENT KILLED`. **^P** pauses (the band under the header says so and the screen is framed in amber), and any other key hands the screen to you.
+
+Every number the HUD shows comes from the app: a tool's own result (the rows a scan returned, the verdict, the paper ticket, fill and position, the caps the desk replayed) or this terminal's price. The agent's text is display only: it is scrubbed and clipped, and nothing in it is acted on.
+
+**Motion and colour.** Calm mode (`--calm` or the `C` key) is the reduced-motion setting here as everywhere else. The sweeps, flashes, the glitch and the typing go away, and every card and number appears at once. With `NO_COLOR` the meaning stays in glyphs: `▸` marks the active phase, chips carry `✓ ! ✗`, and the cursor is `▶`. A terminal shorter than 24 rows gets no HUD; the status lines are shown as toasts instead, and the PnL chip moves to the band under the header.
+
+#### The thought ribbon: `--spectate-thoughts FILE`
+
+dexterm cannot see inside your agent, so its words come from a file the agent writes. Pass `--spectate-thoughts FILE` (with `--spectate-mcp`). The file can be:
+
+- Claude Code's stream output (`claude -p --output-format stream-json --verbose … > FILE`): text and thinking blocks;
+- a JSONL file with `{"thought": "…"}` lines.
+
+The file is tailed for display only, and each line is scrubbed: control and bidirectional characters are removed, addresses are masked and markdown is dropped. One message becomes one short line.

package/dist/packages/mcp/assets/kb/docs/docs-spectator-the-brain-view-and-the-pnl-chip.md

@@ -0,0 +1,46 @@
+---
+id: docs-spectator-the-brain-view-and-the-pnl-chip
+title: Spectator view (watch the agent cook) › Follow over MCP in the running terminal › The brain view and the PnL chip
+kind: docs
+page: spectator
+page_title: Spectator view (watch the agent cook)
+heading: The brain view and the PnL chip
+anchor: the-brain-view-and-the-pnl-chip
+url: https://dexterm.xyz/docs/spectator#the-brain-view-and-the-pnl-chip
+tags:
+  - docs
+  - spectator
+  - brain
+  - view
+  - pnl
+  - chip
+  - follow
+  - over
+  - mcp
+  - running
+  - terminal
+  - watch
+  - agent
+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/spectator.md
+date: 2026-10-16
+---
+
+While the agent is active (it made a call in the last 3 minutes, or it holds a PAPER ticket or position), the **ANALYST panel on the token screen becomes the agent's BRAIN VIEW** instead of the "press a for a dossier" help. Top to bottom:
+
+- **REASONING.** The agent's thoughts (from `--spectate-thoughts`) typing in, newest at the bottom, each with its clock time and the phase it was in (`SCANNING`, `VETTING`, `SIZING`, ...). Older lines dim, and long lines are clipped. With no thoughts feed, the header says `dexterm narration · no thoughts feed` and the lines are dexterm's own narration of each call. Lines a demo or stand-in feed marks as scripted (`"demo": true`) carry the coral `claude lines: demo text` tag.
+- **VETTING $COIN.** The checklist for the coin on screen: momentum, liquidity against the $10K floor, tape buys/sells and wallet count, top-10 concentration, mint/freeze authority, LP lock, dev history, LARP flags, the rug heuristic and the verdict. Each box shows the number the app computed and `pass`, `warn`, `fail` or `pending` (pending = that number is not in yet). `◆` marks the checks the agent itself ran.
+- **DATA.** Market cap, price, liquidity, 5m and 1h moves, buy/sell flow and holders, with a candle trace. These are the numbers already on screen; there is no extra fetch.
+- **PLAN / POSITION** (while a PAPER ticket or position is open): entry, size, the take-profit and stop the agent *said* (labelled `agent's plan`, or `no stop`), mark PnL in % and paper $, peak, drawdown from the peak, time held, and what it is waiting for. A desk refusal is stamped here.
+- **DECISIONS.** The session log (`rejected DECOY · verdict AVOID`, `entered`, `sold`, `desk refused`) and a scoreboard: `PAPER simulated · vetted · entries · closed · realized SOL`.
+
+The normal analyst panel returns when the agent is killed, goes quiet, or before its first call, and also while you type into the analyst. Smaller panels drop blocks in order: the decision log first, then the data strip, then the checklist folds into two columns. The plan and the reasoning stay.
+
+**The PnL chip.** While the agent holds a PAPER position, a chip shows it: `PAPER $COIN │ ▲ +24.0% +$2.40 │ peak +31.0% │ $0.0100 → $0.0124 │ held 1m04s │ dd −5.3% │ TP +40%`. It is on every terminal screen (screener, new pairs, watchlist, token screen, analyst) and on the chart popup (https://dexterm.xyz/docs/popup-chart#what-it-shows). On a terminal with 24 rows or more it sits in the dock's top row. On a shorter terminal there is no dock, and the chip sits on the band under the header instead. It updates on every mark tick and flashes on a new peak (a `★` under calm mode and `NO_COLOR`). Fields drop from the right on narrower terminals. The held coin stays in the fast price lane, so the chip keeps marking after the coin scrolls off the screener. In AI scan mode (https://dexterm.xyz/docs/scan#the-read) the same chip shows your own open paper or live position. The chip only shows in these two auto modes. The other popups (token, bubble map, feeds) do not carry it.
+
+Both are display only. They have no input and cannot arm, size, sign, confirm or raise a cap. The agent's text is scrubbed and clipped, and addresses are shortened.

package/dist/packages/mcp/assets/kb/docs/docs-spectator-the-three-surfaces.md

@@ -30,7 +30,7 @@ All three read the same events from one in-memory hub, which `agent serve` creat
 
 | surface | start it with | what you get |
 | --- | --- | --- |
-| AGENT ACTIVITY window | `dexterm agent serve --spectator-popup` | a window titled "watch the agent cook" with live activity and the pause, take over and kill controls |
+| AGENT ACTIVITY window | `dexterm agent serve --spectator-popup` | a window titled "watch the agent cook": the agent's phase rail and heartbeat, its thought ribbon, a call timeline with result chips, the coin it is vetting and its PAPER trade, over the live activity, with the pause, take over and kill controls |
 | read-only stream | `dexterm agent serve --spectate` | a loopback WebSocket that sends events out and accepts no commands |
 | save and replay | `dexterm agent serve --record FILE`, then `dexterm spectate --replay FILE` | a redacted JSONL file of the session that you can replay offline |
 

package/dist/packages/mcp/assets/kb/docs/docs-spectator.md

@@ -22,7 +22,7 @@ sources:
 date: 2026-10-16
 ---
 
-Watch a connected agent work in real time. An AGENT ACTIVITY window with pause, take over and kill, a read-only loopback stream, and redacted save and replay. Covers what is redacted, the security model, how to capture it for a stream, and its limits.
+Watch a connected agent work in real time. The agent HUD in the running terminal (phase rail, heartbeat, thought ribbon, call timeline, the PAPER execution moment), an AGENT ACTIVITY window with pause, take over and kill, a read-only loopback stream, and redacted save and replay. Covers what is redacted, the security model, how to capture it for a stream, and its limits.
 
 The spectator view lets you watch an agent work: each time a connected agent calls a tool (opens a token, runs a LARP check, scans new pairs, reads a bubble map, makes a proposal, gets refused), the call shows up with its result, how long it took and how old its data was. It is for watching and for demos ("watch the agent cook"). It adds no new power: agents stay untrusted (https://dexterm.xyz/docs/agents#untrusted-by-default), and nothing in the spectator view can arm, sign, confirm or send anything.
 

package/dist/packages/mcp/assets/kb/docs/docs-troubleshooting-doctor-lines.md

@@ -29,6 +29,8 @@ date: 2026-10-16
 | `! Terminal colour: 256-colour only` | the terminal cannot do 24-bit colour | use a truecolor terminal (iTerm2, WezTerm, Ghostty, Kitty, Alacritty, Windows Terminal) or set `COLORTERM=truecolor`. The app runs, flattened. |
 | `! Terminal colour: no colour` | `NO_COLOR` is set, or a monochrome terminal | unset `NO_COLOR` for the full look; dexterm works in monochrome. |
 | `! Claude CLI: not found` | `claude` is not on PATH | only the analyst needs it: install Claude Code and run `claude` once to log in. Everything else works. |
+| `! Codex CLI: … not logged in` | the optional Codex engine is installed but logged out | `codex login`, or keep the analyst on Claude. |
+| `! Codex CLI: … older than 0.163.0` | the read-only lock needs a newer codex | `npm i -g @openai/codex@latest`. |
 | `! Helius RPC: no key` | no key configured | optional. Holders and some safety fields show `needs key`; see configuration (https://dexterm.xyz/docs/configuration#the-optional-free-rpc-key). |
 | `✗ Data sources: unreachable …` | a required host did not answer | check your connection, VPN or firewall. If only some hosts fail they may be blocked on your network. `--fixtures` or `DEXTERM_OFFLINE=1` browse offline demo data. |
 | `! Data sources: … PumpPortal …` | only the new-pairs host is down | the rest works; new pairs may be blocked on your network. |