# Desktop Develop

> Develop, debug, and verify the OpenWork Tauri desktop shell and its daemon-served Qwen Web Shell with an agent-readable harness.

- Skill: `modelstudioai/desktop-develop` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add modelstudioai/desktop-develop`
- Raw SKILL.md: https://api.skillmd.com/api/skills/modelstudioai/desktop-develop/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: modelstudioai (https://skillmd.com/u/modelstudioai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/modelstudioai/desktop-develop

---


# Desktop Development Harness

## Overview

Use this skill to turn desktop work into a tight harness loop: gather runtime
context, reproduce with the UI and logs visible to the agent, make the smallest
fix, verify through the same path, and encode any missing affordance back into
the repo.

Read `references/harness-principles.md` when the task changes the development
workflow, observability, docs, tests, or agent-facing harness itself.

## Quick Context

For bug reports, UI failures, hangs, startup problems, messaging issues, or
anything involving the running desktop app, inspect the runtime logs directly.
Important paths on macOS:

- `~/Library/Logs/com.alibaba.openwork/desktop-runtime.log`
- `~/.qwen/` for Qwen runtime state and transcripts

Search logs before guessing:

```bash
rg -n "error|warn|failed|exception|crash|Unhandled|rejection" \
  "$HOME/Library/Logs/com.alibaba.openwork/desktop-runtime.log"
```

## Harness Loop

1. **Map the surface.** Identify whether the task touches Tauri Rust,
   bootstrap assets, Web Shell, bundled runtime, channels, or the browser
   child webview. Read nearby code and tests before editing.
2. **Collect live evidence.** Read and tail the relevant log while reproducing.
   Treat missing or ambiguous logs as part of the bug.
3. **Drive the UI.** Inspect the daemon-served Web Shell in a browser for DOM,
   accessibility, console, and network evidence; verify native behavior in the
   Tauri app and runtime log.
4. **Reproduce first.** For bugs, capture the exact observed behavior and the
   evidence that proves it. If reproduction differs from the user's report,
   compare environment, app state, build artifact, account, timing, and logs.
5. **Patch narrowly.** Keep changes scoped to the proven cause. Add structure
   only when it removes real repeated work or makes the app more readable to
   future agents.
6. **Verify through the same path.** Re-run the reproduction, inspect logs and
   DevTools again, then run focused tests/typechecks for touched packages.
7. **Improve the harness when needed.** If the fix required hidden knowledge,
   add a small doc, test, log field, or skill update so the next agent
   can see it directly.

## Running Desktop

Use desktop-specific commands from `packages/desktop-shell`:

```bash
cd packages/desktop-shell
npm install --workspaces=false
npm run build:runtime --workspaces=false
npm run dev --workspaces=false
```

Reuse the prepared runtime on later runs. Set
`OPENWORK_DESKTOP_WORKSPACE=/absolute/path` for an isolated workspace.

## Web Shell inspection

Run `npm run smoke:runtime --workspaces=false` to launch and probe the bundled
loopback runtime. Use `npm run dev --workspaces=false` for native behavior; do
not substitute the retired Electron renderer.

## Focused Verification

Choose the narrowest checks that cover the touched surface:

```bash
cd packages/desktop-shell && npm test --workspaces=false
cd packages/desktop-shell && npm run test:migration --workspaces=false
cd packages/desktop-shell && npm run test:release --workspaces=false
cd packages/desktop-shell && npm run smoke:runtime --workspaces=false
npm run typecheck --workspace=packages/web-shell
```

For root CLI/core changes, use the root repository commands from `AGENTS.md`
instead. For desktop-only changes, prefer desktop package commands first.

## Agent-Readable Changes

Favor changes that future agents can inspect and verify:

- Add structured log fields near failure boundaries instead of vague messages.
- Add accessible names or stable UI affordances when DevTools snapshots are
  hard to interpret.
- Keep docs as maps with links to deeper sources. Do not create giant manuals.
- Convert repeated manual debugging steps into docs, tests, or structured logs.
- Record non-trivial investigation notes in `.qwen/investigations/`.

Stop and ask the user only when the missing input cannot be discovered locally
and a reasonable assumption would risk changing the wrong behavior.