Developer guide

📄️ Develop Core DSH plugins in an isolated Wework instance

The bundled Wework Plugin Developer is a Wework plugin. It may carry a

📄️ Wework Chat State Sources

This document records the state sources for the Wework chat path. The goal is to make UI code read one explicit derived status instead of letting the send button, message stream, queue, and runtime task list override each other.

📄️ Wework background terminals

Codex commands can continue running after their AI turn finishes. The conversation environment summary lists these commands and their count under Background processes. Selecting a command opens a read-only terminal tab on the right with live output and a No output yet placeholder when empty. An exited process disappears from the running list; an open log tab remains available to read and close.

📄️ Project Execution State-of-Truth Refactoring

Implementation status: the state-of-truth path and concurrency extension are complete; full Backend, Wework, and Executor regression, MySQL migration rollback/upgrade, and real Electron desktop acceptance have passed.

📄️ Wework Plugin Marketplace V2 Technical Design

For plugin development, open-source migration, and local integration, start with the Plugin Marketplace Developer Guide. This document is the implementation and acceptance contract for Wework plugin sharing, enterprise-wide publication, GitLab review, and marketplace Releases.

📄️ Cloud Git Worktree Goal Mode and Parallel Development Plan

1. Document status

📄️ Feature: Wework Plugin Sharing and Enterprise-wide Publication Interaction Design

0. Document status and design basis

📄️ Wework Plugin Marketplace Developer Guide

For developers who need to build, migrate, or publish Wework plugins. See Plugin Marketplace V2 for architecture and operations, Codex Plugin Runtime for local runtime details, and Plugin Icon Guide for light/dark logos.

📄️ Local Data Directory

Wework stores its local runtime data under ~/.wework in the user's home

📄️ Wework Plugin Icon Guide (wework-plugins)

For maintainers of wework-plugins (and internal plugin repos): how to ship logo / logoDark so icons stay readable in light and dark UI.

📄️ Codex sidebar state parity

The Wework desktop app follows the Codex App sidebar state model. Project and live task content comes from the Codex app-server, while sidebar metadata comes from .codex-global-state.json in the target device's CODEX_HOME. While a remote device is online, Wework also stores a local task-list summary for startup recovery after that device goes offline.

📄️ Wework desktop releases

The Wework desktop application uses Electron. Formal builds and releases are

📄️ Wework Windows development and builds

The Wework Windows desktop application uses Electron and shares the same

📄️ Targeted plugin synchronization and cache reuse

Installation, reinstallation, updates, enablement and component changes synchronize only the affected plugins. Uninstallation sends explicit removals. Manual refresh and device reconnection retain complete desired-state reconciliation. Account installation records describe desired state; device acknowledgements describe local materialization.

📄️ Wework device diagnostics

The read-only deviceDiagnostics.microphone capability is available to core DSH and independent

📄️ Local-First Cloud Connection

Wework remains a complete local app by default. Local Codex, local model configs, the local executor, local workspaces, and local conversations do not require Backend login or cloud devices. Cloud connection is an optional capability layer: after the user enters a Backend URL from the sidebar and signs in with the WeWork login flow, server models, cloud devices, and cloud Codex auth sync join the same workbench.

📄️ Codex Plugin Runtime

Wework's plugin feature is compatible with Codex plugins, skills, and apps. The plugin pages handle discovery, installation, creation, and management; the chat runtime passes user-selected skills and apps to the Codex app-server as structured mentions instead of treating display text as plain prompt content.

📄️ Performance Diagnostics

Wework includes an opt-in frontend performance diagnostics switch for investigating release builds that become slow after running for a while. The diagnostics code only runs after it is explicitly enabled; when disabled, the app does not install React Profiler and does not collect interval samples.

📄️ wework-dsh-ui-plugins

Core DSH and newly created Smart apps default to 0.2.0-rc.2; existing apps can still select 0.1.0-rc.8 through their manifests. Client slot services now come from @deepseek-ai/dsh-client-ui-renderer instead of dsh-client-runtime. The new DSH native module loader requires a matching Electron runtime fingerprint, so Wework pins the supported Electron 44.7.0.

📄️ E2E Automation

Desktop E2E fixtures use GPT 5.6 Luna. Real runtime catalogs advertise both GPT-5.6 Luna and GPT 5.6 Luna, so default-model selection assertions accept these two display names while retaining model ID and provider checks. Task restoration assertions retain the fixture's original display name.

📄️ Workspace File Preview

The Wework file panel renders Markdown documents as formatted content, sends other code and text files to Pierre CodeView, and sends binary files to Flyfish Viewer browser-side renderers. Preview data is read only from authorized local workspaces and is never uploaded to third-party services.

📄️ MCP Apps

Wework runs MCP Apps alongside tool results in Codex tasks. An MCP server supplies HTML, and the app communicates with Wework through the standard MCP Apps protocol.

📄️ Debug Instance Labels

Wework can launch a debug Wework instance from the built-in Terminal of another running Wework window. To keep multiple worktrees and dev apps distinguishable, Wework passes the parent window context into the Terminal, and wework/scripts/dev-mac-app.sh forwards it to the debug instance.

📄️ DSH Session Extensions for Executor Tasks

Wework Core DSH projects Executor-managed running tasks into standard

📄️ Decision Models and the Decision Workbench

Configuration and Access

📄️ Plugin Interactive Forms

Wework supports interactive forms from plugins during a running conversation. The user sees a form card in chat, selects or enters answers, and submits the response back to the running plugin. Plugin authors should trigger this through MCP elicitation. requestuserinput is an internal render protocol between executor and Wework and should not be emitted directly by plugins.

📄️ Wework Transcript and Preference Cloud Sync

The Wework Core DSH plugin @wegent/dsh-transcript-sync synchronizes native

📄️ Applications and MCP Elicitation Desktop E2E

This document defines the real desktop regression plan for Wework application entry points and MCP business forms. The tests reuse the existing desktop runner and checkpoints. They do not add local-only scripts or replace Electron, Executor, or Codex with browser mocks.

📄️ Embedded Browser

Wework's embedded browser displays an interactive web page inside the desktop workbench right panel and lets the local runtime control the same page through the Electron browser view bridge. It is not a screenshot preview, and it should not open a separate external Chrome window.

📄️ AI Verification Sessions

Wework can start an isolated development verification session so an AI can operate and assert against the real Electron application. It reuses the desktop E2E WebView control channel, never drives an external Chrome window, and does not attach to a developer's everyday Wework window.