[nicknisi]

release-please's publish job (`release.yml`) uses `pnpm/action-setup@v6` with no `version` input, which resolves pnpm from package.json's `packageManager` field — a field this repo didn't have. CI only worked because `ci.yml` passed an explicit `version: 10`, so the gap would have surfaced at the worst moment: the first automated npm publish, which would fail at pnpm setup.

This adopts the authkit-nextjs pattern wholesale (the repo `release.yml` was copied from):

• `package.json`: add `"packageManager": "pnpm@10.28.0"` — the single version source of truth
• `ci.yml`: drop the explicit `version: 10` and move both jobs to the same `action-setup@v6` pin `release.yml` uses

Verified: pnpm@10.28.0 honors `pnpm-workspace.yaml`'s `allowBuilds` (electron/esbuild postinstalls run), local pnpm auto-switches via the field, and lint/typecheck/tests are green.

This commit was pushed to the previous branch moments after PR #1 was squash-merged, so it needs its own PR.

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[greptile-apps]

Greptile Summary

This PR has two distinct concerns bundled together: the stated CI fix (pinning pnpm via packageManager so release.yml's pnpm/action-setup@v6 can resolve the version without a hard-coded version: input), and a substantive new feature (auth-error broadcasting) that surfaces sign-in failures — denied/cancelled ceremonies, failed code exchanges, and unreachable auth servers — to the renderer via useAuth().error.

• CI fix: package.json gains "packageManager": "pnpm@10.28.0" as the single version source of truth; both ci.yml jobs are upgraded from action-setup v4 to v6; three new workflows are added (release-please.yml, release.yml, lint-pr-title.yml).
• Auth-error feature: A new authkit:auth-error IPC channel, AuthErrorPayload type, broadcastAuthError helper, and onAuthError preload bridge method allow the main process to push safe { code, message } payloads to every renderer window on any sign-in failure; AuthKitProvider subscribes and exposes error through useAuth(), cleared on the next successful sign-in.
• Window ceremony fix: captured = true is set before closeWindow() in the loadURL catch block, preventing a double error broadcast when the auth server is unreachable.

Confidence Score: 3/5

The release.yml publish step is missing npm authentication, meaning the first automated release it enables will still fail.

The pnpm wiring and the auth-error feature are well-implemented with thorough test coverage. However, release.yml's publish step has no NODE_AUTH_TOKEN (or equivalent) set: setup-node with registry-url writes a .npmrc that references this env var, but the var is never populated, so pnpm publish will fail with an auth error on the first automated release — the exact failure mode the PR is trying to prevent. The engines.node narrowing (20→22.11) is also undocumented and could affect consumers.

.github/workflows/release.yml needs an npm authentication token on the publish step; package.json's engines.node bump warrants a note in the changelog or PR description.

Important Files Changed

Filename	Overview
.github/workflows/ci.yml	Upgrades both jobs from pnpm/action-setup v4 (explicit version: 10) to v6 (reads from packageManager field); straightforward and correct.
.github/workflows/release.yml	New reusable publish workflow; pnpm setup correctly reads packageManager, but the publish step is missing NODE_AUTH_TOKEN for npm authentication — the first automated release will fail.
.github/workflows/release-please.yml	New release orchestration workflow; permissions, token generation, and workflow_call wiring look correct.
package.json	Adds packageManager field (the core fix), promotes lint to --deny-warnings, and silently narrows the engines.node floor from >=20 to >=22.11.0.
src/main/ipc-handlers.ts	Adds broadcastAuthError and a shared sendToAllWindows helper; signIn handler now broadcasts an auth-error on failure before returning ok:false.
src/main/create-auth-kit.ts	Wires broadcastError into both the deep-link callback and the IPC handler path; adds idempotent registerProtocol guard.
src/react/auth-kit-provider.tsx	Subscribes to onAuthError, surfaces failures via error state, and clears it on the next successful sign-in; cleanup correctly unsubscribes both listeners.
src/main/ceremony/window.ts	Fixes a double-broadcast bug: sets captured=true before closeWindow() in the loadURL catch block so the closed handler doesn't also emit a synthetic window_closed URL.

Sequence Diagram

sequenceDiagram
    participant R as Renderer (useAuth)
    participant P as Preload Bridge
    participant IPC as ipcMain
    participant SM as SessionManager
    participant C as Ceremony (open)

    R->>P: signIn()
    P->>IPC: invoke(authkit:sign-in)
    IPC->>SM: beginSignIn()
    SM->>C: ceremony.open(authUrl)

    alt Ceremony succeeds → callback arrives
        C-->>IPC: deep-link callback URL
        IPC->>SM: authenticateWithCode()
        alt Exchange succeeds
            SM-->>IPC: AuthResult
            IPC->>P: broadcast(authkit:auth-changed, payload)
            P-->>R: "onAuthChange → user set, error = null"
        else Exchange fails
            IPC->>P: "broadcast(authkit:auth-error, {code, message})"
            P-->>R: onAuthError → error set
        end
    else Ceremony denied / cancelled
        C-->>IPC: "?error=access_denied / ?error=window_closed"
        IPC->>P: "broadcast(authkit:auth-error, {code, message})"
        P-->>R: onAuthError → error set
        IPC-->>P: "invoke result {ok:true, data:null}"
    else Ceremony open() throws (unreachable auth server)
        C-->>IPC: throws SignInOpenError
        IPC->>P: "broadcast(authkit:auth-error, {code, message})"
        P-->>R: onAuthError → error set
        IPC-->>P: "invoke result {ok:false, error}"
        P-->>R: signIn() rejects
    end

Loading

Comments Outside Diff (1)

1. package.json, line 242-244 (link)

   Undocumented narrowing of the supported Node.js range

   The minimum Node.js version jumps from >=20.0.0 to >=22.11.0. Node 20 is an active LTS release, so any consumer pinned to it would break silently — their install succeeds, but the engines check at runtime would warn or fail depending on the package manager. This change is not mentioned in the PR description, the commit title, or the CHANGELOG.md delta, so it is easy to overlook in a semver bump.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: package.json
   Line: 242-244
   
   Comment:
   **Undocumented narrowing of the supported Node.js range**
   
   The minimum Node.js version jumps from `>=20.0.0` to `>=22.11.0`. Node 20 is an active LTS release, so any consumer pinned to it would break silently — their install succeeds, but the engines check at runtime would warn or fail depending on the package manager. This change is not mentioned in the PR description, the commit title, or the `CHANGELOG.md` delta, so it is easy to overlook in a semver bump.
   
   How can I resolve this? If you propose a fix, please make it concise.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
.github/workflows/release.yml:28-30
**Missing npm authentication token on publish step**

The `pnpm publish` step has no `NODE_AUTH_TOKEN` (or equivalent) set. `actions/setup-node` with `registry-url` configures `.npmrc` to use `NODE_AUTH_TOKEN`, but if that env var is absent at publish time, the command will fail with an authentication error. OIDC (`id-token: write`) provides the provenance attestation, not the npm auth; a separate npm token is still required unless this package has been enrolled in npm's Trusted Publishers program. The very failure mode the PR is trying to prevent (first automated publish silently breaking) would still occur.

### Issue 2 of 2
package.json:242-244
**Undocumented narrowing of the supported Node.js range**

The minimum Node.js version jumps from `>=20.0.0` to `>=22.11.0`. Node 20 is an active LTS release, so any consumer pinned to it would break silently — their install succeeds, but the engines check at runtime would warn or fail depending on the package manager. This change is not mentioned in the PR description, the commit title, or the `CHANGELOG.md` delta, so it is easy to overlook in a semver bump.

_{Reviews (1): Last reviewed commit: "ci: pin pnpm via packageManager for the ..." | Re-trigger Greptile}

[greptile-apps]

Missing npm authentication token on publish step

The pnpm publish step has no NODE_AUTH_TOKEN (or equivalent) set. actions/setup-node with registry-url configures .npmrc to use NODE_AUTH_TOKEN, but if that env var is absent at publish time, the command will fail with an authentication error. OIDC (id-token: write) provides the provenance attestation, not the npm auth; a separate npm token is still required unless this package has been enrolled in npm's Trusted Publishers program. The very failure mode the PR is trying to prevent (first automated publish silently breaking) would still occur.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/release.yml
Line: 28-30

Comment:
**Missing npm authentication token on publish step**

The `pnpm publish` step has no `NODE_AUTH_TOKEN` (or equivalent) set. `actions/setup-node` with `registry-url` configures `.npmrc` to use `NODE_AUTH_TOKEN`, but if that env var is absent at publish time, the command will fail with an authentication error. OIDC (`id-token: write`) provides the provenance attestation, not the npm auth; a separate npm token is still required unless this package has been enrolled in npm's Trusted Publishers program. The very failure mode the PR is trying to prevent (first automated publish silently breaking) would still occur.

How can I resolve this? If you propose a fix, please make it concise.