skalpel 3.2.11 → 3.2.13

package/INSTALL.md

@@ -47,14 +47,14 @@ Post-W4 (OAuth port): first run is a guided TUI walkthrough plus browser-loopbac
 
 This flow corresponds to Journey 1 — First launch, fresh authentication — in `SPEC.md`. That narrative describes what the user feels at each step; this document describes what the install machinery actually does.
 
-If the user runs `skalpel` without first running `skalpel login`, the walkthrough prompts them to sign in inline (Enter), skip for now (`s`), turn interception off (`o`), or quit (`q`). The walkthrough also surfaces the website onboarding URL (`https://launch.skalpel.ai/signup`) and notes that a wizard activation command can be pasted directly — npm frequently hides `postinstall` output, so this CLI-side hint is where self-serve `npm install -g` users reliably learn how to activate. To sign out of an existing account on this machine, run `skalpel logout` from a shell — the CLI revokes the backend session (best-effort) and removes `auth.json` via `internal/auth.Delete`.
+If the user runs `skalpel` without first running `skalpel login`, the walkthrough prompts them to sign in inline (Enter), skip for now (`s`), turn interception off (`o`), or quit (`q`). The walkthrough also surfaces the website onboarding URL (`https://skalpel.ai/signup`) and notes that a wizard activation command can be pasted directly — npm frequently hides `postinstall` output, so this CLI-side hint is where self-serve `npm install -g` users reliably learn how to activate. To sign out of an existing account on this machine, run `skalpel logout` from a shell — the CLI revokes the backend session (best-effort) and removes `auth.json` via `internal/auth.Delete`.
 
 ### Guided activation vs. self-serve global install
 
 The primary, guided path is the website signup wizard, which mints a one-time, version-pinned-to-`latest` command:
 
 ```bash
-npx --yes skalpel@<latest> login --activation <token> && npm install -g skalpel@<latest>
+npm install -g skalpel@<latest> && skalpel login --activation <token>
 ```
 
 The `&& npm install -g` step puts `skalpel` on your PATH so shell wrappers from setup work in new terminals; it only runs if activation succeeds.
@@ -63,7 +63,7 @@ The shell wrappers — and the `skalpel active` / `skalpel inactive` indicator e
 
 `login --activation` is **auth-only with respect to the TUI**: it claims the token, writes `auth.json`, and never launches the TUI (the magic flow is a deliberate terminal handoff). Before exiting it chains directly into harness setup so the single pasted command also walks the user through wrapping their coding agents: in an interactive terminal it runs the same detection + checkbox prompt as `skalpel setup`; in a non-interactive shell (CI, piped) it only prints what it detected and points at `skalpel setup`, never editing shell startup files unattended. Browser-loopback `skalpel login` is unchanged and still lands the user on the dashboard.
 
-A user who independently runs `npm install -g skalpel` is still supported: `postinstall` prints a best-effort pointer to `https://launch.skalpel.ai/signup`, and the first `skalpel` run repeats that pointer where output is guaranteed.
+A user who independently runs `npm install -g skalpel` is still supported: `postinstall` prints a best-effort pointer to `https://skalpel.ai/signup`, and the first `skalpel` run repeats that pointer where output is guaranteed.
 
 ### `skalpel setup` — detect and wrap coding agents
 
@@ -153,6 +153,47 @@ When the TUI connects to the daemon at launch, the handshake includes a version
 
 The handshake is also where the TUI reads the daemon's engine list and the daemon's per-agent detection results (per `SPEC.md` §6 and §9). A version-coupled handshake is also a guarantee that the TUI is reading those results from a daemon whose schema it understands. When the bundle promises versions match, the TUI does not need a defensive parse-and-recover path for the daemon's responses; the schema is whatever the bundle's joint version says it is.
 
+## Advanced: chaining `skalpeld` through a local interception proxy
+
+By default `skalpeld` is the host's HTTP proxy for coding agents. If you
+also run a separate local interception proxy (e.g. an mitmproxy that
+records traffic for research), you can have the daemon **chain** its
+outbound provider traffic through it without either rig fighting over the
+proxy role. This is opt-in and controlled by two environment variables on
+the **daemon** process:
+
+| Variable | Values | Default | Effect |
+|---|---|---|---|
+| `SKALPEL_VIA_MITM` | `true` \| `false` \| `bypass` | `true` | `true`: the daemon routes its **provider** calls (Anthropic / OpenAI / …) through the proxy at `MITM_PROXY_URL`, while its own **control-plane** calls to `api.skalpel.ai` and the **Cognito** auth hop bypass the proxy (so your recordings never contain Skalpel control-plane chatter). `false` / `bypass`: the daemon talks direct to providers, no chaining; `bypass` is the explicit "turn everything off" debugging value. An unset or unrecognised value behaves as `true`. |
+| `MITM_PROXY_URL` | a proxy URL | `http://127.0.0.1:8888` | The interception-proxy address to chain through when `SKALPEL_VIA_MITM=true`. The daemon's own live proxy address-file and `SKALPEL_PROXY_URL` take precedence over this if set. |
+
+The bypass list is fixed and suffix-based — it covers the Skalpel control
+plane (`api.skalpel.ai`, `.skalpel.ai`), Cognito and AWS
+(`amazoncognito.com`, `amazonaws.com`), object stores
+(`r2.cloudflarestorage.com`), the package registries the install path
+reaches (`pypi.org`, `crates.io`, `*.github.com`), and loopback. Provider
+hosts are NOT on the list, so they route through the proxy.
+
+Because the daemon is service-managed, set these via a systemd drop-in
+rather than an interactive shell:
+
+```ini
+# ~/.config/systemd/user/skalpeld.service.d/proxy-chain.conf
+[Service]
+Environment=SKALPEL_VIA_MITM=true
+Environment=MITM_PROXY_URL=http://127.0.0.1:8888
+```
+
+```bash
+systemctl --user daemon-reload
+systemctl --user restart skalpeld
+```
+
+To disable chaining, set `SKALPEL_VIA_MITM=bypass` (or `false`) and
+restart the daemon. The interception proxy must trust nothing extra for
+this to work; the chain is purely a network-layer redirect of the
+daemon's outbound sockets.
+
 ## Open questions
 
 A small set of bundling questions are recorded here for the build phase. Each will be resolved before v1 ships; none affect the design commitments above.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "skalpel",
-  "version": "3.2.11",
+  "version": "3.2.13",
   "description": "Skalpel — local proxy and TUI for coding agents (skalpel + skalpeld bundle).",
   "license": "Apache-2.0",
   "homepage": "https://skalpel.ai",
@@ -58,10 +58,10 @@
     "x64"
   ],
   "optionalDependencies": {
-    "@skalpelai/skalpel-darwin-arm64": "3.2.11",
-    "@skalpelai/skalpel-darwin-x64": "3.2.11",
-    "@skalpelai/skalpel-linux-arm64": "3.2.11",
-    "@skalpelai/skalpel-linux-x64": "3.2.11",
-    "@skalpelai/skalpel-win32-x64": "3.2.11"
+    "@skalpelai/skalpel-darwin-arm64": "3.2.13",
+    "@skalpelai/skalpel-darwin-x64": "3.2.13",
+    "@skalpelai/skalpel-linux-arm64": "3.2.13",
+    "@skalpelai/skalpel-linux-x64": "3.2.13",
+    "@skalpelai/skalpel-win32-x64": "3.2.13"
   }
 }

package/postinstall/lib/launch.js

@@ -19,7 +19,7 @@ const log = require('./log');
 // product flow is the website signup wizard (which mints a one-time
 // activation command), not `npm install -g`. We surface it here so a
 // self-serve global install still has a clean path to activation.
-const ONBOARDING_URL = 'https://launch.skalpel.ai/signup';
+const ONBOARDING_URL = 'https://skalpel.ai/signup';
 
 function run({ dryRun }) {
   const hint = `next: activate your account at ${ONBOARDING_URL}`;