@gw-tools/gw 0.63.0-beta.73.3 → 0.63.0

package/README.md

@@ -25,7 +25,6 @@ A command-line tool for managing git worktrees, built with Deno.
     - [Auto-Detection](#auto-detection)
     - [Example Configuration](#example-configuration)
     - [Configuration Options](#configuration-options)
-  - [Telemetry (OpenTelemetry & Dash0)](#telemetry-opentelemetry--dash0)
   - [Commands](#commands)
     - [checkout](#checkout)
       - [Arguments](#arguments)
@@ -386,7 +385,6 @@ All fields are optional and safe to commit — no machine-specific paths or runt
 - **cleanThreshold**: Number of days before worktrees are considered stale for `gw clean` (defaults to 7, set via `gw init --clean-threshold`)
 - **autoClean**: Silently remove stale worktrees in the background when running `gw checkout` or `gw list` (defaults to false, set via `gw init --auto-clean`)
 - **updateStrategy**: Default strategy for `gw update` command: "merge" or "rebase" (defaults to "merge", set via `gw init --update-strategy`)
-- **telemetry**: Opt-in OpenTelemetry / Dash0 telemetry (disabled by default). See [Telemetry](#telemetry-opentelemetry--dash0)
 
 ### Local Overrides (`config.local.json`)
 
@@ -401,118 +399,6 @@ Create `.gw/config.local.json` to override any config value for your machine onl
 
 Local config is merged on top of `config.json` (shallow merge, local wins). Useful for adding personal files to `autoCopyFiles` without modifying the team config.
 
-## Telemetry (OpenTelemetry & Dash0)
-
-`gw` can send anonymous usage data to the maintainer's
-[Dash0](https://www.dash0.com/) instance so aggregate usage can be observed and
-releases correlated with error spikes. Telemetry is **opt-in and disabled by
-default** — nothing leaves your machine until you explicitly enable it.
-
-### Opting in and out
-
-```bash
-gw telemetry on      # enable on this machine
-gw telemetry off     # disable on this machine
-gw telemetry status  # show current effective state
-```
-
-`gw telemetry on/off` writes to `.gw/config.local.json`, which is gitignored,
-so your choice stays local and never affects other people who clone the repo.
-
-You can also use the env var `GW_TELEMETRY=1` to enable or `GW_TELEMETRY=0` to
-disable for a single session without touching any config file.
-
-`gw init` writes a `"telemetry": { "enabled": false }` block into your
-`.gw/config.json` so the option is easy to discover. Note that `enabled` in the
-committed `config.json` has no effect — opt-in is per-machine only (use
-`gw telemetry on` or `GW_TELEMETRY=1`).
-
-### What gets sent
-
-When enabled, each command emits **one span** and **one log record** via
-OTLP/HTTP to the maintainer's Dash0 instance:
-
-- **Span attributes:** `gw.command`, `gw.command.exit_code`,
-  `gw.command.duration_ms`, `service.version`
-- **Log level:** `INFO` on success, `ERROR` on failure (with a redacted
-  `error.message`)
-- **Resource attributes:** `service.name`, `service.version`,
-  `deployment.environment.name` (if configured)
-
-**What is NOT sent:** branch names, repository paths, file names, user identity,
-or any personally identifiable information. Error messages are client-side
-redacted before transmission — absolute paths, git refs, long hex SHAs, and
-`KEY=value` patterns are replaced with `<path>`, `<ref>`, `<sha>`, and
-`KEY=<redacted>` respectively.
-
-> **Fail-open design:** any export error is silently swallowed and never slows
-> down or breaks a command. Nothing is ever written to stdout (so shell-eval
-> commands like `gw cd` stay safe).
-
-### Privacy and the threat model
-
-The compiled `gw` binary bundles the maintainer's Dash0 ingest endpoint and a
-scoped ingest token. This is the same approach used by Sentry DSNs, Vercel CLI
-analytics, and Deno's own telemetry. The token is scoped to the `gw-cli`
-dataset and subject to ingest quotas — it cannot read back data or access other
-Dash0 resources. Anyone who disassembles the binary could extract the token, but
-the worst-case impact is noise in a single dataset, not a data breach.
-
-To completely opt out: `gw telemetry off` (or `GW_TELEMETRY=0`). The telemetry
-code path is never entered when disabled.
-
-### Routing to your own backend
-
-Power users can override the maintainer's endpoint and route telemetry to their
-own OTel backend instead. The precedence is: \*\*env vars > `.gw/config.local.json`
-
-> committed `.gw/config.json` > build defaults\*\*.
-
-```bash
-# Route to a local Collector
-export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4318"
-export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer <token>,Dash0-Dataset=my-dataset"
-gw telemetry on
-```
-
-Or in `.gw/config.local.json` (gitignored):
-
-```jsonc
-{
-  "telemetry": {
-    "enabled": true,
-    "endpoint": "http://localhost:4318",
-    "headers": { "Authorization": "Bearer <token>", "Dash0-Dataset": "my-dataset" },
-  },
-}
-```
-
-**Note:** `telemetry.enabled` in the committed `.gw/config.json` has no effect.
-Opt-in is per-machine only (local config or env var). This prevents repo
-maintainers from silently enrolling everyone who clones the repo.
-
-### Configuration reference
-
-| Setting       | `config.local.json` key | Env override                  | Default           |
-| ------------- | ----------------------- | ----------------------------- | ----------------- |
-| Enable        | `telemetry.enabled`     | `GW_TELEMETRY` (`1`/`0`)      | `false`           |
-| Endpoint      | `telemetry.endpoint`    | `OTEL_EXPORTER_OTLP_ENDPOINT` | _(build default)_ |
-| Environment   | `telemetry.environment` | `OTEL_RESOURCE_ATTRIBUTES`    | _(unset)_         |
-| Service name  | `telemetry.serviceName` | `OTEL_SERVICE_NAME`           | `gw`              |
-| Headers       | `telemetry.headers`     | `OTEL_EXPORTER_OTLP_HEADERS`  | _(build default)_ |
-| Flush timeout | `telemetry.timeoutMs`   | —                             | `1500`            |
-
-`OTEL_SDK_DISABLED=true` is honoured as a hard kill switch regardless of other
-settings. Set `GW_TELEMETRY_DEBUG=1` to log export problems to stderr.
-
-### Correlating deployments with errors
-
-The release pipeline (`scripts/release-ci.sh`) sends a `deployment.success`
-event to Dash0 after each publish, tagged with `service.version` and the git
-commit SHA. Because runtime error signals carry the same `service.version`,
-Dash0 can display a deployment marker on the error timeline and compare error
-rates before and after each release.
-
 ## Commands
 
 ### checkout

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gw-tools/gw",
-  "version": "0.63.0-beta.73.3",
+  "version": "0.63.0",
   "description": "A command-line tool for managing git worktrees - copy files between worktrees with ease",
   "keywords": [
     "git",