Merge remote-tracking branch 'origin/main' into merge/main-into-dev

# Conflicts:
#	CLAUDE.md
#	nix/package.nix
#	packages/app/src/components/combined-model-selector.tsx
#	packages/app/src/hooks/use-sidebar-workspaces-list.ts
#	packages/app/src/screens/workspace/workspace-screen.tsx
#	packages/app/src/stores/session-store.test.ts
#	packages/server/src/client/daemon-client.ts
#	packages/server/src/server/agent/agent-manager.ts
#	packages/server/src/server/session.ts
#	packages/server/src/server/session.workspace-git-watch.test.ts
#	packages/server/src/server/session.workspaces.test.ts
#	packages/server/src/shared/messages.ts

docs/RELEASE.md

@@ -11,6 +11,12 @@ There are two supported ways to ship from `main`:
 
 ## Standard release (patch)
 
+Before running any stable patch release command:
+
+- Make sure the intended release commit is already committed to `main` and the working tree is clean.
+- Make sure local `npm run typecheck` passes on that commit.
+- Do not use `npm run release:patch` as a substitute for checking whether the current commit is actually ready.
+
 ```bash
 npm run release:patch
 ```
@@ -24,6 +30,7 @@ Use the direct stable path when the current `main` changes are ready to become t
 ## Manual step-by-step
 
 ```bash
+npm run typecheck            # Verify the exact commit you intend to release
 npm run release:check        # Typecheck, build, dry-run pack
 npm run version:all:patch    # Bump version, create commit + tag
 npm run release:publish      # Publish to npm
@@ -131,7 +138,7 @@ Load the `paseo` skill and launch a **Codex 5.4** agent with a prompt like:
 > Review the diff between the latest release tag and HEAD. Focus on:
 >
 > 1. **Breaking changes** — especially in the WebSocket protocol, agent lifecycle, and any server↔client contract.
-> 2. **Backward compatibility** — mobile apps lag behind desktop/daemon updates by days. Users will update desktop and daemon immediately but keep running the old app. Flag anything that requires both sides to update in lockstep.
+> 2. **Backward compatibility** — the important direction is old app clients talking to newly updated daemons. Users update desktop and daemon first, then keep running the old app for a while. Flag anything that breaks old clients against new daemons or requires both sides to update in lockstep.
 > 3. **Regressions** — anything that looks like it could break existing functionality.
 >
 > Diff: `git diff <latest-release-tag>..HEAD`
@@ -150,6 +157,8 @@ In other words, RCs are checkpoints along the way; the changelog only records th
 ## Completion checklist
 
 - [ ] Run the pre-release sanity check (see above) and address any findings
+- [ ] Ensure the intended release commit is already committed and the git worktree is clean before running any `release:*` patch/promote command
+- [ ] Ensure local `npm run typecheck` passes on that exact commit before running any `release:*` patch/promote command
 - [ ] Update `CHANGELOG.md` with user-facing release notes (features, fixes — not refactors)
 - [ ] Verify the changelog heading follows strict `## X.Y.Z - YYYY-MM-DD` format
 - [ ] `npm run release:patch` or `npm run release:promote` completes successfully

docs/plan-approval-normalization.md

@@ -0,0 +1,68 @@
+# Plan Approval Normalization
+
+## Goal
+
+Normalize plan approval across providers so the UI renders one consistent plan approval card and action row, while each provider keeps its own execution quirks behind the session permission interface.
+
+## Compatibility Constraints
+
+- Older clients must remain compatible with newer daemons.
+- All new wire fields must be optional.
+- Existing plan permissions without action metadata must still render and work.
+- Existing question permissions must keep their current behavior.
+
+## Design
+
+### Shared abstraction
+
+Add optional permission action definitions to the shared permission request/response types.
+
+- Permission requests may include `actions`.
+- Permission responses may include `selectedActionId`.
+- `kind: "plan"` remains the normalized concept for plan approval.
+- The UI renders actions from the permission request instead of hardcoding provider-specific buttons.
+
+### Claude
+
+Keep Claude's plan permission flow, but enrich it with explicit action definitions.
+
+- Always expose `Reject`.
+- Always expose `Implement`.
+- If the agent entered plan mode from a more permissive mode like `bypassPermissions`, also expose `Implement with <previous mode>`.
+- Resolve the selected action entirely inside `respondToPermission()`.
+
+### Codex
+
+Synthesize a normalized `kind: "plan"` permission after a Codex plan-mode turn completes with a plan result.
+
+- Emit a plan permission with `Reject` and `Implement` actions.
+- On `Implement`, disable `plan_mode`, disable `fast_mode`, and automatically start a follow-up implementation turn.
+- On `Reject`, resolve without starting a follow-up turn.
+- Keep the implementation prompt and state transitions inside the Codex provider.
+
+### Manager and state sync
+
+After permission resolution, refresh provider-derived state so the UI sees internal mode/feature changes without knowing provider quirks.
+
+- Refresh current mode
+- Refresh pending permissions
+- Refresh runtime info
+- Refresh features
+- Persist refreshed state
+
+### UI
+
+Render plan permissions through the existing plan card, but generate buttons from normalized permission actions.
+
+- If `actions` are absent, fall back to legacy buttons.
+- Plan cards should use `Implement` as the default primary label.
+- Do not add provider-specific rendering branches.
+
+## Verification
+
+1. Shared schema/type tests for optional `actions` and `selectedActionId`
+2. App tests for generic plan-action rendering
+3. Claude tests for third action when resuming from a more permissive mode
+4. Codex tests for synthetic plan approval and automatic implementation follow-up
+5. Manager tests for post-permission state refresh
+6. `npm run typecheck`