feat(den-web): preview organization prompt cards while authoring them

[benjaminshafii]

Problem

Administrators author the organization prompt cards that members see on a new session completely blind. There is no preview, and the field mapping is genuinely counter-intuitive:

• the admin's field labelled "Description" becomes the member's card title
• the "Prompt" text becomes the card body and the composer text

The only way to check your work today is to save and ask a member to reload. An admin about to author department-specific prompt sets is guessing.

Change

Dashboard-only. In desktop-policy-editor-screen.tsx:

1. Live preview of the member's cards as the admin types — same title/body mapping, same Sparkles treatment, same "Try one of your organization's prompts:" header, and the same real fallback (Organization prompt 1|2|3) when a description is blank.
2. Fields relabelled for what they become, so the inversion stops being a trap. Existing char counters kept.
3. States that clicking does not send — admins assume the card auto-runs; it fills the composer.
4. Surfaces the winner-takes-all priority rule, which differs from how the boolean policies OR-union and is a real footgun.

Follows the existing preview precedent in brand-appearance-screen.tsx (same side-by-side grid, bordered panel, uppercase "Preview" label) and uses the existing Den* primitives. No new component library.

Constraints honored

• No schema, API, or desktop rendering change — nothing any member currently sees is altered. git diff --stat origin/dev...HEAD -- apps/ is empty.
• No import from apps/app into ee/apps/den-web; the card presentation is reimplemented locally with a comment pointing at task-suggestions.tsx as the source of truth so drift is detectable.
• Used an inline SVG matching the Sparkles path because den-web does not depend on @heroicons/react.

Verification

pnpm typecheck                              clean
pnpm --filter @openwork-ee/den-web build     succeeded
pnpm --filter @openwork-ee/den-web test      73 pass, 0 fail

New unit test covers the resolver: description becomes title, blank description falls back to Organization prompt N, prompt becomes body.

[vercel]

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

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
openwork-diagnostics	Skipped		Jul 25, 2026 1:01pm

[benjaminshafii]

Validation: real app, isolated Linux sandbox, matched A/B

All nine branches of this series were merged into one integration branch (f91884c3) and driven as a real user through CDP in a fresh Daytona sandbox. Baseline dev was run in a separate, identically-provisioned fresh sandbox with the same model (GPT-4o mini) so the comparison is apples-to-apples.

core-flow step	clean dev (2fda6070)	this series (f91884c3)
App boots to a usable session surface	✅ 105ms	✅ 94ms
User creates a fresh task in the workspace	✅ 674ms	✅ 662ms
User writes a message and runs it (real inference)	✅ 2768ms	✅ 111405ms
User closes and reopens; the session survives	❌ not persisted	❌ not persisted

Step 4 fails identically on clean dev (Session ses_… was not listed after reopen (not persisted)), so it is pre-existing on dev and not introduced here. Against the canonical core flow this series is inert, which is exactly the claim for a cleanup/wiring series.

Validated frames: core-flow-01-booted.png, core-flow-02-session-created.png, core-flow-03-task-response.png — including the assertion "Visible text does not include 'Something went wrong'".

A real regression this caught, in this series

Booting the real app initially failed with:

TypeError: Unknown file extension ".ts" for packages/types/src/skill-markdown.ts
→ "OpenWork server did not finish starting. Please restart OpenWork."

@openwork/types is a source-only package — every exports entry resolves to raw ./src/*.ts. apps/server is built with plain tsc (no bundling), so a runtime import there survives into emitted JS and Node cannot load it. Only the bun build-bundled files under src/opencode-plugins/ may import it.

pnpm typecheck and both bun suites passed straight through this, because bun loads .ts natively and Vite bundles for the renderer. Only booting the real product surfaced it. It is fixed in #3112, and that PR adds an automated guard that fails if any non-bundled apps/server file imports @openwork/types, plus a plain-node import proof of the built output.

Static verification on the merged result

pnpm typecheck                                        clean
pnpm --filter @openwork/app test                      435 pass,  0 fail
pnpm --filter openwork-server test                    526 pass,  0 fail
pnpm --filter @openwork-ee/den-web test                73 pass,  0 fail
pnpm --filter @openwork-ee/den-web build              succeeded
den-api desktop-policy suites (real MySQL)              9 pass,  0 fail

Honest gaps

• No per-PR fraimz flow was authored; this is the canonical core-flow inertness proof plus the matched baseline, which is the right standard for a series that is mostly wiring, deletion, and policy gating.
• The cloud prompt-card behavior in feat(desktop-policies): let organization prompts launch a named skill #3115 is covered by unit + real-DB API tests, not by a driven cloud fraimz — that needs the Den stack and a seeded org.
• Local macOS pnpm dev could not be used: every worktree shares one userData dir, so app.requestSingleInstanceLock() makes any second instance quit before creating a window (CDP stays up, so it looks like a hang). Worth a separate DX fix.