@tripwire-sh/cli 0.1.14 → 0.1.15

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/README.md +62 -0
  2. package/dist/tripwire.js +334 -269
  3. package/package.json +3 -2
package/README.md ADDED
@@ -0,0 +1,62 @@
1
+ # Tripwire CLI
2
+
3
+ Production: `npx @tripwire-sh/cli@latest login`.
4
+
5
+ Staging: `npx @tripwire-sh/cli@staging login`, then
6
+ `npx @tripwire-sh/cli@staging status` or `npx @tripwire-sh/cli@staging --help`.
7
+ Sign in with the staging account in the browser. To set up coding agents, run
8
+ `npx @tripwire-sh/cli@staging install`.
9
+
10
+ The staging release defaults to MCP at
11
+ `https://tripwire-mcp-preview-tripwire.unkey.app/mcp` and auth at
12
+ `https://staging.tripwire.sh/api/auth`. These match the Unkey preview deployment
13
+ and its OAuth discovery metadata. Production defaults stay at
14
+ `https://mcp.tripwire.sh/mcp` and `https://app.tripwire.sh/api/auth`.
15
+
16
+ Staging installs the MCP server as `tripwire-staging` and the skills as
17
+ `tripwire-staging-get-started` and `tripwire-staging-workflows`, alongside the
18
+ production entries. For example, sign the staging MCP in with
19
+ `codex mcp login tripwire-staging` or `claude mcp login tripwire-staging`.
20
+
21
+ Credentials are separate in the macOS keychain, Linux Secret Service and the
22
+ file fallback. Production keeps `tripwire-cli` / `default` and
23
+ `~/.config/tripwire/credentials.json`. Other targets use an account and filename
24
+ containing the environment and a hash of the auth and MCP URLs. A stored
25
+ credential must match both configured URLs before it can be used or revoked.
26
+ `XDG_CONFIG_HOME` and `TRIPWIRE_CREDENTIAL_STORE=file` still apply.
27
+
28
+ For CI, staging reads `TRIPWIRE_STAGING_TOKEN`; production reads `TRIPWIRE_TOKEN`.
29
+ Staging ignores `TRIPWIRE_TOKEN`. Keep tokens in the CI secret store.
30
+
31
+ `TRIPWIRE_ENV=staging` also selects staging when running from source, for example
32
+ `TRIPWIRE_ENV=staging bun run apps/cli/src/index.ts login`. Explicit
33
+ `TRIPWIRE_MCP_URL` and `TRIPWIRE_AUTH_URL` overrides still work, with separate
34
+ credentials for each URL pair. Existing production credentials continue to work;
35
+ custom URL overrides require a fresh login rather than reusing the old singleton.
36
+
37
+ ## Release
38
+
39
+ After this change is merged into `staging/visual`, run:
40
+
41
+ ```sh
42
+ bun run cli:release patch --staging
43
+ ```
44
+
45
+ This dispatches the existing `release-cli.yml` workflow on `staging/visual`
46
+ with `channel=staging`. The equivalent command is:
47
+
48
+ ```sh
49
+ gh workflow run release-cli.yml --ref staging/visual -f channel=staging -f bump=patch
50
+ ```
51
+
52
+ The workflow checks the CLI, chooses a version such as `0.1.1-staging.42`, bundles
53
+ it and publishes `@tripwire-sh/cli` with npm tag `staging`. It creates a GitHub
54
+ prerelease. The `latest` tag stays on production. Publishing requires the existing
55
+ npm trusted publisher and the repository's `npm` environment to allow the staging
56
+ branch. `bun run cli:release patch --staging --dry-run` checks version selection
57
+ without dispatching.
58
+
59
+ For a local package, run `bun run scripts/cli-release/prepare.ts bump patch staging`,
60
+ then `bun run --cwd apps/cli build` and `npm pack ./apps/cli`. The prepare step
61
+ changes the local package version; restore it after packing. The tarball runs with
62
+ `npx --package /absolute/path/to/tripwire-sh-cli-VERSION.tgz tripwire login`.