feat: strengthen /workspace-review beyond high-signal-only

The old workspace-review prompt only hunted for catastrophic bugs and
omitted everything it wasn't highly certain about, so it usually returned
'No high-signal issues found' and felt useless.

Rework it to first understand the diff's intent and judge whether the
implementation actually achieves it and is adequate (smallest correct
solution, completeness), then review correctness across concrete failure
modes (concurrency, lifecycle, state fanout, comparators, a11y,
regressions, targeted-test gaps) plus a security/supply-chain lens, and
classify findings by severity (blocker / non-blocker / nit). Keeps the
existing false-positive discipline (diff is source of truth, validation
pass, no nitpicks, cite rules) and stays review-only by default.

Adapted from a battle-tested PR-review prompt, minus the GitHub-specific
parts that don't apply to a local workspace diff. Updates command and
settings descriptions across locales.

packages/ui/src/lib/magicPrompts.ts

@@ -543,44 +543,64 @@ Respond in the same language the user used most in the conversation.`,
     id: 'session.review.instructions',
     title: 'Workspace Review Instructions',
     group: 'Session',
-    description: 'Hidden instructions attached to the /workspace-review command. Reviews current workspace changes for high-signal issues only.',
-    template: `
-Report only real, high-signal issues introduced by these changes.
+    description: 'Hidden instructions attached to the /workspace-review command. Reviews the workspace diff for intent, correctness, and adequacy, with severity-classified findings.',
+    template: `Review the changes in this workspace and judge whether they are correct and adequate — not just whether they contain catastrophic bugs.
 
-The diff is the source of truth. Use the local repo only as ancillary context when you need to validate a specific claim or check an applicable rule.
+The diff is the source of truth. Read the relevant code around the diff too, not only the diff itself, so you understand the change in context.
 
-Focus on:
-- runtime bugs
-- incorrect logic
-- broken assumptions in the changed code
-- clear regressions introduced by the changes
+First, understand the intent and whether it was achieved:
+- Work out what these changes are trying to do — the intent behind them — from the diff and the surrounding code.
+- Judge whether the implementation actually achieves that intent, and whether it is the smallest correct way to do it. Call out where the change is incomplete, only partially solves the goal, misses cases it clearly set out to handle, or solves it in a way that will not hold up.
+
+Then look for concrete problems. Report real failure modes, not abstract suspicions, and do not nitpick without impact.
+
+Correctness focus:
+- race conditions, stale async results, event ordering
+- data loss or failed writes
+- lifecycle and cleanup (listeners, timers, subscriptions, resources)
+- non-transitive comparators or unstable sorting
+- state/store fanout and render performance
+- optimistic state rollback and reconciliation
+- accessibility semantics
+- regressions introduced by the changes
 - missing implementations across affected modules or targets when the diff clearly introduced the gap
+- missing targeted tests for risky or regression-prone changes
 - clear CLAUDE.md or AGENTS.md violations that apply to the changed files
 
+Security and supply-chain focus (when the diff touches these):
+- dependencies, build/release/CI scripts
+- auth, tokens, secrets, credentials
+- filesystem boundaries and path traversal
+- shell execution
+- network calls, telemetry, exfiltration
+- IPC, native bridge, updater, desktop shell
+- hidden behavior behind small diffs or broad refactors
+
 Do not report:
 - pre-existing issues unrelated to the diff
-- pedantic nitpicks a senior engineer would not flag
-- issues a linter would catch
-- subjective style preferences not explicitly required by CLAUDE.md or AGENTS.md
-- speculative concerns or anything you cannot verify with high confidence
-- missing tests or coverage gaps unless an applicable CLAUDE.md or AGENTS.md explicitly requires them for the changed area
+- pedantic nitpicks a senior engineer would not flag, or issues a linter would catch
+- subjective style preferences not required by CLAUDE.md or AGENTS.md
+- speculative concerns you cannot tie to a concrete failure
 - rules mentioned in CLAUDE.md or AGENTS.md but explicitly silenced in the code
 
 Validation pass:
-- Before reporting an issue, re-check it against the diff plus only the local context you actually needed to read.
+- Before reporting an issue, re-check it against the diff plus only the context you actually read.
 - For CLAUDE.md or AGENTS.md violations, verify the rule applies to the affected file path and cite the exact rule.
-- If you are not certain an issue is real, omit it.
+- If you cannot tie a finding to a concrete impact, drop it.
+
+Classify each finding:
+- blocker: likely regression, data loss, security issue, broken invariant, or a serious correctness problem — or the change does not actually achieve its intent
+- non-blocker: a real but minor issue, a test gap, or a maintainability concern
+- nit: mention only if useful, never treat as blocking
+
+This is a review only — do not edit, fix, or commit anything unless the user asks you to.
 
 Output:
-- If no high-signal issues are found, respond with exactly: No high-signal issues found.
-- Otherwise, return a concise numbered list.
-- For each issue include:
-  - short title
-  - why it is a real problem
-  - affected file path
-  - category: bug or rule violation
+- Start with one or two sentences: what the change does and whether it achieves its intent.
+- Then list findings grouped by severity. For each: short title, why it is a real problem, the affected file path, and category (correctness / security / rule violation / adequacy gap).
+- If you find nothing real, say so plainly instead of inventing findings.
 
-Keep the review concise and practical.`,
+Keep the review concise and practical. Respond in the same language the user uses.`,
   },
   {
     id: 'session.plan.visible',