fix(app): surface skill reveal failures and localize the reveal label

[benjaminshafii]

⚠️ Draft — Windows runtime behavior is UNPROVEN

I am on macOS. I could not exercise the actual Windows Explorer path. Do not merge on my evidence alone; this needs a Windows check. Everything below is what I did verify.

What

Reported via OpenWork feedback (Scott Zahn, Jun 17, v0.17.0, Windows): viewing a skill in the extensions section and clicking "Reveal in Finder" does nothing.

Two confirmed defects:

1. extension-detail-modal.tsx:373 hardcoded the literal English Reveal in Finder — in a file that imports no i18n at all, and on Windows there is no Finder. Suitable keys already existed (en.ts:750,788,1748-1750).
2. mcp-view.tsx:836 called void revealDesktopItemInDir(path) — no platform branch, no catch. The correct pattern already existed 300 lines up in the same file (mcp-view.tsx:506-510) for the MCP config reveal: isWindowsPlatform() branch + try/catch + visible error + swapped label.

Root cause of "nothing happens"

shell.showItemInFolder returns void, so a Windows failure is structurally undetectable — the handler reported success unconditionally. But the failure that most likely bit this user is reportable: detailSkill.path is produced by the server (apps/server/src/skills.ts:78, roots at :123-137), so it can be a path the Electron main process cannot existsSync. In that case main.mjs:1913 returns an error string — which the bare void discarded.

How

• Modal takes a revealLabel prop, so the design-system component stays presentational; mcp-view passes the already-localized, platform-correct label.
• revealSkill() gets the platform branch + try/catch. Errors surface via toast, not configError — configError only renders inside the Advanced settings panel (mcp-view.tsx:1426), which is the wrong surface when a skill modal is open over the page.
• Extracted the main-process handler to reveal-item-in-dir.mjs so its branching is unit-testable (precedent: open-external.mjs). Behavior is unchanged — see below.

Deliberately NOT done

An earlier pass made Windows open the parent directory via openPath (which returns an error string) instead of showItemInFolder. I reverted that: it buys error detectability for a rare case by losing item selection for every Windows user in the common case. Not a good trade. The Electron limitation is documented in the helper instead.

Tests run

$ pnpm --filter @openwork/desktop test
ℹ tests 116   ℹ pass 115   ℹ fail 0   ℹ skipped 1

$ pnpm --filter @openwork/app typecheck
$ tsc -p tsconfig.json --noEmit   (exit 0)

$ pnpm --filter @openwork/desktop typecheck:electron   (exit 0)

__revealItemInDir had zero coverage before this. Added 5 cases: existing file, missing file with existing parent, neither exists, Windows still selects the item, Windows path semantics for the parent, and parent-open failure propagation.

Proven vs unproven

Proven: typecheck, 116 desktop unit tests, non-Windows branch logic via injected deps.
Unproven: real Windows Explorer behavior; no fraimz/CDP run.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-app	Ready	Preview, Comment	Jul 24, 2026 11:57pm
openwork-den	Ready	Preview, Comment	Jul 24, 2026 11:57pm
openwork-den-worker-proxy	Ready	Preview, Comment	Jul 24, 2026 11:57pm
openwork-landing	Ready	Preview, Comment, Open in v0	Jul 24, 2026 11:57pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
openwork-diagnostics	Skipped		Jul 24, 2026 11:57pm