claude-use 1.0.0 → 1.1.0

package/README.md

@@ -566,6 +566,8 @@ The release workflow's `publish-npm` job builds this bundle and publishes it as
 
 The published JSON Schemas under `schema/` should self-reference (and, if ever submitted to a public schema catalog, be registered) via a **version-pinned** GitHub Release asset URL — `releases/download/<tag>/<file>` — never a live branch reference, which silently changes underneath every consumer on every push with no way to pin a version. This is deliberately a different URL form from [installing the binaries](#install)'s own `releases/latest/download/...`: the installer *wants* the newest release every time, but a schema an editor references long-term needs to stay stable at whatever version a given config file was written against, not shift underfoot on every future release.
 
+The same build is also published as a second, scoped alias, `@exadev/claude-use`, to GitHub Packages (`npm.pkg.github.com`) by its own `publish-github-packages` job — useful for anyone with an org-scoped registry configured who would rather never touch npmjs.com. This is a genuinely separate job rather than an extra step in `publish-npm` above: GitHub Packages has no OIDC trusted-publishing exchange, and pnpm/npm attempt that exchange whenever a job holds `id-token: write` regardless of which registry a given step actually targets, so a shared job fails the GitHub Packages leg with a 401. `publish-github-packages` therefore never requests `id-token: write` at all, authenticating instead with a plain `packages: write`-scoped `GITHUB_TOKEN` — no separate secret needed. Because GitHub Packages requires a scoped name, the job rewrites the checked-out `package.json`'s `name` and `publishConfig.registry` in place with `npm pkg set` (the latter has to be set explicitly since it otherwise takes precedence over the `.npmrc` `registry-url` `actions/setup-node` wrote, silently sending the publish back to npmjs.org) rather than maintaining a second `package.json` that could drift from the real one.
+
 ## Testing strategy
 
 the resolver's cascade and materialisation logic is exactly the kind of thing that's easy to get subtly wrong, so it gets thorough unit tests before anything else is built on it:

package/dist/cli.cjs

@@ -221857,7 +221857,7 @@ var categories_default_default = {
 // package.json
 var package_default = {
   name: "claude-use",
-  version: "1.0.0",
+  version: "1.1.0",
   description: "A profile manager and launcher for Claude Code that lets one person run multiple logins from one machine while controlling what gets shared between them.",
   license: "Apache-2.0",
   author: "Joseph Mearman <joseph@mearman.co.uk>",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-use",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "description": "A profile manager and launcher for Claude Code that lets one person run multiple logins from one machine while controlling what gets shared between them.",
   "license": "Apache-2.0",
   "author": "Joseph Mearman <joseph@mearman.co.uk>",