skalpel 3.4.19 → 4.0.0

package/{prosumer-hooks/skalpel-statusline.mjs → skalpel-statusline.mjs}

@@ -26,8 +26,7 @@ function main() {
   } catch {
     // Missing/corrupt first-run state is an honest zero, not a reason to hide the status line.
   }
-  const finiteOrZero = (value) =>
-    typeof value === "number" && Number.isFinite(value) ? value : 0;
+  const finiteOrZero = (value) => (typeof value === "number" && Number.isFinite(value) ? value : 0);
   const sess = finiteOrZero(s.session_hours).toFixed(1);
   const total = finiteOrZero(s.total_hours).toFixed(1);
   const steers = finiteOrZero(s.total_events);

package/INSTALL.md

@@ -1,250 +0,0 @@
-# Install and bundling — `skalpel` and `skalpeld`
-
-The `skalpel` npm package is the canonical distribution surface for the Skalpel client on a developer's machine. The package contains two executables: `skalpel`, the Bubble Tea terminal UI specified in `SPEC.md` (in this repo) and `docs/RUN_CLIENT_LOCALLY.md` (also in this repo), and `skalpeld`, the local proxy and daemon. Installing one always installs the other; the two are released, signed, and versioned as a single bundle. A user who runs `npx skalpel`, `npm install -g skalpel`, or pulls a GitHub Releases tarball receives both binaries in a single transaction. There is no separate `skalpeld` package, no separate version cadence, and no "TUI without daemon" install path.
-
-This document is the canonical specification for what gets installed where, how the first-run flow lands the user on the Engines tab, and how updates and uninstalls are handled. See `SPEC.md` for the TUI specification, `docs/RUN_CLIENT_LOCALLY.md` for the dev workflow, and the upstream infrastructure / cross-surface-contract documents (when available) for bundle composition and auth-handoff details.
-
-The bundling commitment is a product decision before it is an implementation decision. A user who installs the TUI receives the daemon in the same transaction because the configurator (TUI) and the proxy (`skalpeld`) are two halves of the same product surface. Splitting them into independently versioned packages would introduce a class of "TUI-newer-than-daemon" or "daemon-newer-than-TUI" failures that no recovery clause in `SPEC.md` §8 is designed to handle. The bundle is the unit of release; the version is the unit of identity; the install path is the unit of choice.
-
-## What gets installed
-
-The npm package places two executables on the user's machine. Both arrive together; neither is shipped without the other.
-
-| Binary | Role | On-disk location |
-|---|---|---|
-| `skalpel` | Bubble Tea terminal UI; the configurator the user invokes by typing `skalpel` in a shell. | A directory on the user's `PATH`. For `npx`, this is npm's transient cache. For `npm install -g`, this is the npm global prefix's `bin/` directory (typically `/usr/local/bin/skalpel` on macOS and Linux, `%AppData%\npm\skalpel.cmd` on Windows). |
-| `skalpeld` | Local proxy/daemon; intercepts traffic from coding agents (Cursor, Claude Code, Codex), applies engines, and forwards to upstream providers. | Co-located with `skalpel` in the same `bin/` directory. Per-OS service registration (launchd agent on macOS, systemd user unit on Linux, Task Scheduler entry on Windows) is performed by the `postinstall` script so the daemon survives reboot; see "Daemon lifecycle on subsequent launches" below and `../../Skalpel_Infrastructure/INFRASTRUCTURE.md` for the platform constraints. |
-
-Both binaries are produced from the same release workflow named in `INFRASTRUCTURE.md`'s CLI Distribution section. Both are signed keylessly via Sigstore / cosign. Both carry the same version string. Mismatch by version is impossible by construction on a machine that received either binary via a supported install path.
-
-### Platform support
-
-The release workflow targets three platforms in v1: macOS (arm64 and amd64), Linux (amd64; arm64 as a follow-on), and Windows (amd64). Each platform receives its own pair of binaries built from the same source revision. The npm package selects the right pair at install time based on the user's `os` and `cpu`; the GitHub Releases tarballs are named per-platform and the user picks. The configuration directory paths and service-registration entry points named elsewhere in this document differ per platform; the bundling and version-coupling commitments do not.
-
-### Configuration directory
-
-The configuration directory is per-OS, per `SPEC.md` §7. Both binaries read it: the TUI for `auth.json` and `config.toml`, the daemon for the same files plus its socket and logfile path. The directory is created by the wizard on first run and is owned by the user. It is not part of the npm package; it is created by the binaries on first invocation and survives uninstalls so that reinstalls can resume.
-
-## Install paths
-
-Three first-class install paths are supported. Each delivers both binaries; none can deliver one without the other.
-
-- **`npx skalpel`** — the zero-install path. npm fetches the package on demand and runs the `skalpel` binary. `skalpeld` is materialized in the same npx cache and is reachable on the same `PATH`-like resolution that npx uses for the lifetime of the invocation. This is the recommended path for users running Skalpel for the first time.
-- **`npm install -g skalpel`** — the persistent-install path. The package is installed into npm's global prefix; both binaries are placed in the global `bin/` directory and become available system-wide. Subsequent invocations resolve `skalpel` and `skalpeld` from `PATH` without the npm overhead. Recommended for users who want the binaries co-located with their other CLI tools.
-- **GitHub Releases tarballs** — the air-gapped path. Each release attaches per-platform tarballs containing both binaries plus their cosign signatures and checksums (per `INFRASTRUCTURE.md`'s CLI Distribution section, which mandates keyless Sigstore signing for every release artifact). Recommended for users on a machine that cannot reach the public npm registry, or for environments where supply-chain verification is performed manually before placing binaries on `PATH`.
-
-All three paths produce identical binaries — same SHAs, same cosign signatures, same version metadata. The choice between them is operational, not functional.
-
-## First-run flow
-
-Post-W4 (OAuth port): first run is a guided TUI walkthrough plus browser-loopback Cognito sign-in. The historical `sk-skalpel-*` API-key paste path is gone — the daemon no longer persists or sends api_keys on any code path. The flow is:
-
-1. The user installs (`npm install -g skalpel`) and runs `skalpel`.
-2. If `auth.json` is missing, `skalpel` renders a branded walkthrough in-terminal: daemon status, sign-in requirement, CA trust behavior, wrapper scope (new sessions only), and quick toggles (`skalpel off` / `skalpel on`).
-3. On Enter, `skalpel` opens a browser to the Skalpel hosted-UI sign-in page (Cognito), waits on a loopback HTTP callback, and validates the signed envelope returned by the callback.
-4. On a verified envelope, the CLI writes `auth.json` to the per-OS configuration directory (per `SPEC.md` §7). The file is owned by the user with `0600` permissions and carries the Cognito JWT bundle (access_token, refresh_token, expires_at).
-5. Login idempotently enables the `behavior_graph` actuator and installs or refreshes the managed Claude Code and Codex prompt/session hooks. This does not depend on `skalpel setup` or on a live daemon.
-6. Browser/paste login auto-launches the TUI and starts or resumes exactly one intent-graph worker, with progress on the Dashboard. Activation login stays TUI-free and launches the same worker in the background.
-
-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://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
-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.
-
-The shell wrappers — and the `skalpel active` / `skalpel inactive` indicator each new `claude` / `codex` session prints — **require a persistent global install** (`npm install -g skalpel`). The wrapper block is gated on `command -v skalpel`, so a block written while only an ephemeral `npx` binary is on PATH never activates. If you run only the `npx … login --activation` step (without the global install), harness setup detects that no persistent `skalpel` is on PATH and **tells you to run `npm install -g skalpel@latest`** instead of silently writing an inert block. Run the global install, then `skalpel setup` (or restart your shell), and the indicator appears.
-
-`login --activation` is **auth-only with respect to the TUI**: it claims the token, writes `auth.json`, heals behavior hooks, starts or resumes graph learning in the background, and never launches the TUI (the magic flow is a deliberate terminal handoff). External-shell wrapping remains a separate consent boundary: in an interactive terminal activation offers 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` still lands the user on the dashboard and shows graph progress there.
-
-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.
-
-When Claude Code is already present, the persistent install also registers Skalpel's local,
-read-only `statusLine` command. It is visible immediately as `~0.0h saved` and grows only from
-confirmed savings. Install alone does **not** opt the user into prompt/session hooks; the first
-successful `skalpel login` activates them. An existing custom Claude status line is preserved.
-
-### `skalpel setup` — repair wrappers and behavior hooks
-
-Normal authentication, hook activation, and graph learning require no setup command. `skalpel setup` remains as an explicit recovery/advanced command for re-running optional external-shell wrapping and repairing managed hooks. Harness wrapping is also offered interactively at the tail of `login --activation` (see above). `skalpel setup` detects which coding-agent harnesses are installed (cross-platform on Linux, Windows, and macOS) via PATH and per-user config probes:
-
-- **Claude Code** and **Codex CLI** — detected and wrappable.
-- **Cursor** — detected for display only (no Skalpel wrapper today).
-
-In an **interactive** terminal, `setup` shows a checkbox list (nothing pre-selected), matching Claude Code’s multi-select pattern: **↑/↓** to move, **enter** (or **space**) on an agent row toggles a green **[✓]**, then move to **Confirm and wrap selected** and press **enter** to apply. **esc** skips without changes. It does not use a free-text `>` prompt and does not wrap all detected agents unless you pass `--yes` / `-y` or run in a non-interactive shell (which wraps all detected agents for explicit `skalpel setup` only — the chained `login --activation` path never writes shell files unattended).
-
-Harness detection uses the same `internal/harness` probes as the published npm binary (`claude` / `codex` on PATH, or `~/.claude` / `~/.codex` config dirs). If nothing is found, the CLI prints what it looked for — that is not a dev-only stub.
-
-After wrapping, `setup` prints per-agent success lines and reminds you that new `claude` / `codex` sessions show **`skalpel active`** or **`skalpel inactive`** on stderr before the agent loads (via the shell wrapper calling `skalpel status`). Toggle interception without editing shell files: **`skalpel off`** / **`skalpel on`**.
-
-The wrapper block only fires when `skalpel` is **permanently on your PATH** (a global `npm install -g skalpel`, not an ephemeral `npx` run). If you invoke `setup` from a non-persistent `skalpel` (e.g. via `npx`), it will not write the rc block — it instead prints the exact `npm install -g skalpel@latest` command to run first, because the wrappers cannot activate without it.
-
-`setup` resolves the correct shell startup file for the current OS + shell (zsh/bash/fish rc files, or the PowerShell `$PROFILE` on Windows), writes a managed fenced block (identical fences to the install-time block, so `skalpel uninstall` removes either), and prints exactly which file changed plus undo instructions (`skalpel uninstall`, or `SKALPEL_NO_AGENT_WRAP=1` to disable wrapping). It never launches the TUI. On an unknown OS/shell it prints manual instructions instead of writing.
-
-Historical note: prior versions of skalpel supported pasting a `sk-skalpel-*` API key copied from the web dashboard as an alternative to `skalpel login`. The W4 OAuth-port grep-delete removed both the api_key-paste wizard and the daemon-side api_key sending path. Users on stale auth.json files (api_key-only, no Cognito bundle) need to run `skalpel login` once to refresh.
-
-## Daemon lifecycle on subsequent launches
-
-On every launch after the first, the TUI checks whether `skalpeld` is reachable. If it is, the TUI proceeds to Dashboard without further interaction. If it is not, the TUI attempts to start it (per spec §8.5) and shows the `Starting skalpeld…` splash for up to three seconds. If the daemon does not come up in that window, the TUI proceeds with the daemon-unreachable banner and the user is offered a `[r]` retry affordance.
-
-The TUI is not a process supervisor. Per `SPEC.md` §01: the TUI tries to start the daemon at launch and surfaces the daemon's state via the banner, but there is no "stop daemon," "restart daemon," or "view daemon logs" control in the TUI; those are shell-level concerns. The install machinery makes both binaries available; the runtime relationship between them is the TUI's start-on-launch attempt and nothing more.
-
-Per-OS service registration is performed by the npm `postinstall` script (`postinstall/lib/service-register.js`). On macOS the script renders and loads a launchd agent (`com.skalpel.skalpeld.plist`) and kickstarts it via `launchctl`; on Linux the script writes a systemd user unit (`skalpeld.service`) and starts it via `systemctl --user`; on Windows the script registers a Task Scheduler entry (`Task.xml`) and runs it via `schtasks /Run`. The `postinstall` script also starts the daemon immediately on first install so the user does not have to wait for the next TUI launch to bring `skalpeld` online; subsequent boots rely on the registered service entry, with the TUI's start-on-launch attempt as a defence-in-depth fallback. Both the bundling commitment (atomic install of TUI + daemon) and the TUI's runtime behaviour on launch are independent of the service registration mechanism.
-
-## Updates
-
-After install or upgrade, `skalpel --version` should report the same semver as `npm view skalpel version` (for example `skalpel v3.2.10` when the registry shows `3.2.10`). The release pipeline enforces that match before publish; if they diverge, reinstall with `npx --yes skalpel@latest`.
-
-`npx skalpel@latest` and `npm update -g skalpel` are the two update paths. Both update both binaries atomically: the new `skalpel` and the new `skalpeld` arrive together, and the old `skalpel` and old `skalpeld` are replaced together. There is no window during which the binaries are at different versions on disk.
-
-The CLI auto-update polling described in `INFRASTRUCTURE.md` (CLI Distribution, the `cli/latest` endpoint) surfaces a non-blocking notice when a newer version is available. The user runs the update command themselves; the TUI does not perform an in-place upgrade. After an update, the next `skalpel` invocation launches the new TUI, which in turn starts the new `skalpeld` if needed.
-
-GitHub Releases tarball users update by downloading the new tarball, verifying signatures and checksums, and replacing the binaries on `PATH`. Both replacements happen as a single user-initiated operation; partial updates are not a supported state.
-
-A user who has rolled back to a previous version (by running `npm install -g skalpel@<older>` or by replacing tarball binaries with archived ones) lands at a coherent older bundle: the older `skalpel` and the older `skalpeld` arrive together. There is no roll-back-the-TUI-only or roll-back-the-daemon-only operation. The same atomicity that protects forward updates protects rollbacks.
-
-## Uninstall
-
-```
-npx skalpel uninstall
-```
-
-is the canonical one-liner for a clean, full removal on every supported OS. The Go binary owns the state cleanup; the Node shim owns `npm uninstall -g`. The watchdog catches `npm uninstall -g skalpel` alone within ~60s. It works whether or not skalpel was previously installed globally:
-
-1. Unregisters the per-OS service entry (launchd on macOS, systemd user unit on Linux, Task Scheduler entry on Windows).
-2. Removes the managed shell-rc block injected on install.
-3. Deletes user state under the per-OS configuration directory: `auth.json`, `config.toml`, `skalpeld.lock`, `logs/`, and `cache/`.
-4. Auto-detects a global npm install (via `npm prefix -g`) and removes it via `npm uninstall -g skalpel`, so the `skalpel` binary leaves your `PATH` in the same command.
-
-Flags: `--keep-data` preserves user-data files (engine toggles, cached auth) for a future reinstall; `--keep-package` preserves the global npm package (only the state cleanup runs); `--dry-run` previews every action without writing anything.
-
-`skalpel uninstall` from a global install behaves identically — same flags, same auto-removal of the npm package. Pick whichever is convenient: `npx skalpel uninstall` requires no prior install; `skalpel uninstall` is faster on a machine that already has the binary on `PATH`.
-
-### Why `npm uninstall -g skalpel` is not the documented path
-
-npm 7+ removed the `preuninstall`/`uninstall`/`postuninstall` lifecycle scripts; the `npm uninstall` command runs Arborist's `reify` which simply deletes files from the global `node_modules` and returns. There is no hook left for skalpel to clean up the rc-file managed block, the service entry, or user data on `npm uninstall -g skalpel` alone. Running `npm uninstall -g skalpel` without first running `skalpel uninstall` (or `npx skalpel uninstall`) leaves orphaned shell-rc env vars pointing at a dead proxy port and an orphaned launchd/systemd/Task Scheduler entry trying to start a binary that no longer exists. The `npx skalpel uninstall` one-liner above does both the state cleanup and the package removal in a single command — that's why it's the documented path.
-
-The configuration directory itself (auth.json + config.toml + cache + logs) is deliberately wiped by the default uninstall so a reinstalled skalpel starts from a known state. Users who want to reinstall and keep their auth + engine toggles should pass `--keep-data`.
-
-### Watchdog and cleanup.lock
-
-`skalpel uninstall` is one path to a clean machine; `npm uninstall -g skalpel` followed by no further action is another. The daemon's **watchdog** subsystem closes the loop on the second path. Every ~30s, `skalpeld` polls its own executable path; when the binary disappears (because npm just nuked the global `node_modules`), it self-runs the same cleanup the Go CLI does, then exits.
-
-To opt out (e.g. on shared hosts where the daemon is centrally managed), set `[daemon] watchdog_enabled = false` in `~/.config/skalpel/config.toml`:
-
-```toml
-[daemon]
-watchdog_enabled = false
-```
-
-`cleanup.lock` is a small marker file `<configDir>/cleanup.lock` that `skalpel uninstall` writes before any destructive step. It contains `<pid>\n<unix_ms>\n`. The watchdog reads it every tick:
-
-- If the lock's PID is alive AND its timestamp is fresher than 10 minutes → stand down (a user-initiated uninstall owns this window).
-- Else (dead PID or stale timestamp) → ignore the lock and proceed as if it weren't there.
-
-`cleanup.lock` is safe to delete manually if you see one outside an active uninstall — the next watchdog tick will recover.
-
-## Version coupling
-
-`skalpel` and `skalpeld` carry the same version string at all times. The release workflow produces both from the same git tag; the npm package's `version` field, the binaries' embedded version metadata, and the cosign signatures all reference the same value. There is no path by which the two could diverge on a machine that received either via a supported install path.
-
-When the TUI connects to the daemon at launch, the handshake includes a version exchange. If the version reported by `skalpeld` does not match the version embedded in `skalpel` — a state that should be unreachable through the supported install paths — the TUI enters a degraded state per `SPEC.md` §8 and surfaces a banner instructing the user to reinstall the bundle. The handshake is a defence in depth; the install paths are designed so that the handshake should never fire on a mismatch.
-
-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.
-
-- **`npx` cache eviction and version-pinning UX.** `npx skalpel` caches per-version; a user who runs `npx skalpel@1.2.3` after `1.2.4` has shipped continues to execute `1.2.3` until npm's cache resolves. The auto-update notice surfaces in the TUI, but the underlying npx semantics are an open ergonomic question.
-- ~~**Signed-link pre-population of the API key.**~~ Obsolete post-W4 (OAuth-port grep-delete): the api_key-paste wizard the question referred to is gone. The first-run flow is browser-loopback Cognito sign-in via `skalpel login`. Left here as a historical breadcrumb for anyone tracing the pre-W4 design dockets.
-- **Bundle size budget.** The two binaries together set a download-size budget for first-time `npx` users; whether to ship a slim TUI front-end and a separately-downloaded `skalpeld` payload via a `postinstall` fetch (still in the same npm transaction) or to ship both in the package tarball directly is a build-phase decision. Either approach preserves the bundling commitment because both binaries are still resolved and authenticated within the same install operation.
-- **Install-time telemetry.** Whether the install path emits any telemetry event (e.g., "first install completed") is open. The TUI itself does not phone home in v1 (per the privacy stance in `SPEC.md` §05); whether the install wizard shares that posture or whether anonymous install counts are acceptable for release-quality measurement is a build-phase decision.
-- **Windows install ergonomics.** Whether `npx skalpel` on Windows requires Windows Terminal or a recent PowerShell to render the Bubble Tea TUI's adaptive colours and key bindings cleanly, and whether a fallback message should explain the requirement, is open. The bundling commitment is platform-agnostic; the first-run experience may not be.
-
-## References
-
-- `SPEC.md` — TUI specification: §1 (goals and non-goals; Install/uninstall flow is named as a non-goal there with a pointer here), §7 (configuration directory and file layout), §8 (degraded states and banners, including the version-mismatch banner), §16 (Install and distribution; cross-links here as the canonical source).
-- `SPEC.md` — Skalpel TUI design dockets: §01 (the daemon non-supervisor stance), §03 Journey 1 (first-launch fresh-authentication flow that this document's first-run flow corresponds to), §05 (privacy stance referenced in the install-time telemetry open question).
-- `../../design-dockets/cross-surface-contract.md` — Cross-surface contract: the Auth handoff section (machine-client identity, the `npx skalpel` install wizard arriving in the same transaction as the daemon), the ownership matrix's Post-signup install row.
-- `../../Skalpel_Infrastructure/INFRASTRUCTURE.md` — CLI Distribution section (npm, GitHub Releases, Sigstore signing, the `cli/latest` auto-update endpoint, emergency-release fallback path).
-
-## Codex setup (macOS)
-
-During `npm install -g skalpel` on macOS you will see a **one-time Touch ID / password prompt** from the system. This prompt is the macOS keychain asking you to trust the daemon's local intercept CA in your **login keychain**. The trust is needed because Codex CLI is Rust and validates TLS against the OS keychain — without the trust, `codex` would reject the daemon's MITM leaf certs and skalpel would never see Codex traffic.
-
-**Scope of trust:**
-
-- Per-user (your `login.keychain-db`), not system-wide.
-- Trusts only the daemon-minted local CA labelled `Skalpel Local Intercept CA`.
-- Used exclusively for `chatgpt.com` / `api.openai.com` traffic the daemon intercepts; every other host is blind-tunnelled untouched.
-
-**If you missed the prompt** or declined it, run `skalpel login` or invoke `codex` once — the postinstall step writes a deferred-install sentinel and the next entry point retries the trust-store install.
-
-**macOS — revoke trust:**
-
-1. Open **Keychain Access**.
-2. Select the `login` keychain.
-3. Search for `Skalpel Local Intercept CA`.
-4. Right-click → Delete.
-
-**Linux — revoke trust:**
-
-```bash
-sudo rm /usr/local/share/ca-certificates/skalpel-local-intercept-ca.crt
-sudo update-ca-certificates --fresh
-```
-
-**Linux install requirements:** postinstall (and the deferred retry on first `skalpel login` / `codex` invocation) copies the daemon CA to `/usr/local/share/ca-certificates/skalpel-local-intercept-ca.crt` and runs `update-ca-certificates`. This needs **root** or **passwordless `sudo`**. If `sudo` is unavailable, postinstall prints the manual commands and does not fail the install.
-
-After deletion, Codex traffic falls back to bare TLS (daemon won't see it). Re-install the CA via `skalpel login` if you change your mind.
-
-**Windows status:** the trust-store install path is **not yet shipped** on Windows. Codex MITM on Windows still requires manual cert trust until a `certutil` path lands.

package/LICENSE

@@ -1,201 +0,0 @@
-                                 Apache License
-                           Version 2.0, January 2004
-                        http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-      "License" shall mean the terms and conditions for use, reproduction,
-      and distribution as defined by Sections 1 through 9 of this document.
-
-      "Licensor" shall mean the copyright owner or entity authorized by
-      the copyright owner that is granting the License.
-
-      "Legal Entity" shall mean the union of the acting entity and all
-      other entities that control, are controlled by, or are under common
-      control with that entity. For the purposes of this definition,
-      "control" means (i) the power, direct or indirect, to cause the
-      direction or management of such entity, whether by contract or
-      otherwise, or (ii) ownership of fifty percent (50%) or more of the
-      outstanding shares, or (iii) beneficial ownership of such entity.
-
-      "You" (or "Your") shall mean an individual or Legal Entity
-      exercising permissions granted by this License.
-
-      "Source" form shall mean the preferred form for making modifications,
-      including but not limited to software source code, documentation
-      source, and configuration files.
-
-      "Object" form shall mean any form resulting from mechanical
-      transformation or translation of a Source form, including but
-      not limited to compiled object code, generated documentation,
-      and conversions to other media types.
-
-      "Work" shall mean the work of authorship, whether in Source or
-      Object form, made available under the License, as indicated by a
-      copyright notice that is included in or attached to the work
-      (an example is provided in the Appendix below).
-
-      "Derivative Works" shall mean any work, whether in Source or Object
-      form, that is based on (or derived from) the Work and for which the
-      editorial revisions, annotations, elaborations, or other modifications
-      represent, as a whole, an original work of authorship. For the purposes
-      of this License, Derivative Works shall not include works that remain
-      separable from, or merely link (or bind by name) to the interfaces of,
-      the Work and Derivative Works thereof.
-
-      "Contribution" shall mean any work of authorship, including
-      the original version of the Work and any modifications or additions
-      to that Work or Derivative Works thereof, that is intentionally
-      submitted to Licensor for inclusion in the Work by the copyright owner
-      or by an individual or Legal Entity authorized to submit on behalf of
-      the copyright owner. For the purposes of this definition, "submitted"
-      means any form of electronic, verbal, or written communication sent
-      to the Licensor or its representatives, including but not limited to
-      communication on electronic mailing lists, source code control systems,
-      and issue tracking systems that are managed by, or on behalf of, the
-      Licensor for the purpose of discussing and improving the Work, but
-      excluding communication that is conspicuously marked or otherwise
-      designated in writing by the copyright owner as "Not a Contribution."
-
-      "Contributor" shall mean Licensor and any individual or Legal Entity
-      on behalf of whom a Contribution has been received by Licensor and
-      subsequently incorporated within the Work.
-
-   2. Grant of Copyright License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      copyright license to reproduce, prepare Derivative Works of,
-      publicly display, publicly perform, sublicense, and distribute the
-      Work and such Derivative Works in Source or Object form.
-
-   3. Grant of Patent License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      (except as stated in this section) patent license to make, have made,
-      use, offer to sell, sell, import, and otherwise transfer the Work,
-      where such license applies only to those patent claims licensable
-      by such Contributor that are necessarily infringed by their
-      Contribution(s) alone or by combination of their Contribution(s)
-      with the Work to which such Contribution(s) was submitted. If You
-      institute patent litigation against any entity (including a
-      cross-claim or counterclaim in a lawsuit) alleging that the Work
-      or a Contribution incorporated within the Work constitutes direct
-      or contributory patent infringement, then any patent licenses
-      granted to You under this License for that Work shall terminate
-      as of the date such litigation is filed.
-
-   4. Redistribution. You may reproduce and distribute copies of the
-      Work or Derivative Works thereof in any medium, with or without
-      modifications, and in Source or Object form, provided that You
-      meet the following conditions:
-
-      (a) You must give any other recipients of the Work or
-          Derivative Works a copy of this License; and
-
-      (b) You must cause any modified files to carry prominent notices
-          stating that You changed the files; and
-
-      (c) You must retain, in the Source form of any Derivative Works
-          that You distribute, all copyright, patent, trademark, and
-          attribution notices from the Source form of the Work,
-          excluding those notices that do not pertain to any part of
-          the Derivative Works; and
-
-      (d) If the Work includes a "NOTICE" text file as part of its
-          distribution, then any Derivative Works that You distribute must
-          include a readable copy of the attribution notices contained
-          within such NOTICE file, excluding those notices that do not
-          pertain to any part of the Derivative Works, in at least one
-          of the following places: within a NOTICE text file distributed
-          as part of the Derivative Works; within the Source form or
-          documentation, if provided along with the Derivative Works; or,
-          within a display generated by the Derivative Works, if and
-          wherever such third-party notices normally appear. The contents
-          of the NOTICE file are for informational purposes only and
-          do not modify the License. You may add Your own attribution
-          notices within Derivative Works that You distribute, alongside
-          or as an addendum to the NOTICE text from the Work, provided
-          that such additional attribution notices cannot be construed
-          as modifying the License.
-
-      You may add Your own copyright statement to Your modifications and
-      may provide additional or different license terms and conditions
-      for use, reproduction, or distribution of Your modifications, or
-      for any such Derivative Works as a whole, provided Your use,
-      reproduction, and distribution of the Work otherwise complies with
-      the conditions stated in this License.
-
-   5. Submission of Contributions. Unless You explicitly state otherwise,
-      any Contribution intentionally submitted for inclusion in the Work
-      by You to the Licensor shall be under the terms and conditions of
-      this License, without any additional terms or conditions.
-      Notwithstanding the above, nothing herein shall supersede or modify
-      the terms of any separate license agreement you may have executed
-      with Licensor regarding such Contributions.
-
-   6. Trademarks. This License does not grant permission to use the trade
-      names, trademarks, service marks, or product names of the Licensor,
-      except as required for describing the origin of the Work and
-      reproducing the content of the NOTICE file.
-
-   7. Disclaimer of Warranty. Unless required by applicable law or
-      agreed to in writing, Licensor provides the Work (and each
-      Contributor provides its Contributions) on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
-      implied, including, without limitation, any warranties or conditions
-      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
-      PARTICULAR PURPOSE. You are solely responsible for determining the
-      appropriateness of using or redistributing the Work and assume any
-      risks associated with Your exercise of permissions under this License.
-
-   8. Limitation of Liability. In no event and under no legal theory,
-      whether in tort (including negligence), contract, or otherwise,
-      unless required by applicable law (such as deliberate and grossly
-      negligent acts) or agreed to in writing, shall any Contributor be
-      liable to You for damages, including any direct, indirect, special,
-      incidental, or consequential damages of any character arising as a
-      result of this License or out of the use or inability to use the
-      Work (including but not limited to damages for loss of goodwill,
-      work stoppage, computer failure or malfunction, or any and all
-      other commercial damages or losses), even if such Contributor
-      has been advised of the possibility of such damages.
-
-   9. Accepting Warranty or Support. While redistributing the Work or
-      Derivative Works thereof, You may choose to offer, and charge a
-      fee for, acceptance of support, warranty, indemnity, or other
-      liability obligations and/or rights consistent with this License.
-      However, in accepting such obligations, You may act only on Your
-      own behalf and on Your sole responsibility, not on behalf of any
-      other Contributor, and only if You agree to indemnify, defend,
-      and hold each Contributor harmless for any liability incurred by,
-      or claims asserted against, such Contributor by reason of your
-      accepting any such warranty or support.
-
-   END OF TERMS AND CONDITIONS
-
-   APPENDIX: How to apply the Apache License to your work.
-
-      To apply the Apache License to your work, attach the following
-      boilerplate notice, with the fields enclosed by brackets "[]"
-      replaced with your own identifying information. (Don't include
-      the brackets!)  The text should be enclosed in the appropriate
-      comment syntax for the file format. We also recommend that a
-      file or class name and description of purpose be included on the
-      same "printed page" as the copyright notice for easier
-      identification within third-party archives.
-
-   Copyright 2026 SkalpelAI Inc.
-
-   Licensed under the Apache License, Version 2.0 (the "License");
-   you may not use this file except in compliance with the License.
-   You may obtain a copy of the License at
-
-       http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing, software
-   distributed under the License is distributed on an "AS IS" BASIS,
-   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-   See the License for the specific language governing permissions and
-   limitations under the License.

package/design-tokens.json

@@ -1,52 +0,0 @@
-{
-  "$schema": "design-tokens.schema.json",
-  "version": 1,
-  "themes": {
-    "tokyo-night-storm": {
-      "base": "#1a1b26",
-      "mantle": "#16161e",
-      "crust": "#16161e",
-      "surface0": "#16161e",
-      "surface1": "#1f2335",
-      "surface2": "#24283b",
-      "overlay0": "#3b4261",
-      "overlay1": "#565f89",
-      "overlay2": "#737aa2",
-      "text": "#c0caf5",
-      "subtext0": "#a9b1d6",
-      "subtext1": "#a9b1d6",
-      "lilac": "#bb9af7",
-      "pink": "#f7768e",
-      "red": "#f7768e",
-      "maroon": "#f7768e",
-      "peach": "#ff9e64",
-      "lemon": "#e0af68",
-      "mint": "#9ece6a",
-      "teal": "#73daca",
-      "sky": "#7aa2f7",
-      "sapphire": "#7aa2f7",
-      "blue": "#7aa2f7",
-      "lavender": "#bb9af7"
-    }
-  },
-  "semantic": {
-    "tab.dashboard": "tokyo-night-storm.lilac",
-    "tab.engines": "tokyo-night-storm.sky",
-    "tab.sessions": "tokyo-night-storm.pink",
-    "tab.account": "tokyo-night-storm.mint",
-    "tab.graph": "tokyo-night-storm.teal",
-    "tab.logs": "tokyo-night-storm.lemon",
-    "selection.bg": "tokyo-night-storm.lilac",
-    "selection.fg": "tokyo-night-storm.crust",
-    "border.dim": "tokyo-night-storm.overlay0",
-    "footer.text": "tokyo-night-storm.overlay1",
-    "section.cost": "tokyo-night-storm.pink",
-    "section.engine": "tokyo-night-storm.lilac",
-    "section.quality": "tokyo-night-storm.mint",
-    "level.error": "tokyo-night-storm.red",
-    "level.warn": "tokyo-night-storm.lemon",
-    "level.info": "tokyo-night-storm.sky",
-    "level.success": "tokyo-night-storm.mint",
-    "level.debug": "tokyo-night-storm.overlay0"
-  }
-}