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.

📄️ 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

📄️ 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 is the only plugin runtime for the Wework desktop UI.

📄️ E2E Automation

Wework provides a dedicated Playwright E2E entrypoint and a test-only frontend automation bridge for operating the Wework Vite/React frontend in CI. The default entrypoint runs in browser mode, which covers most frontend interactions; the desktop task-flow E2E below covers native-window and task-execution behavior.

📄️ 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.

📄️ 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

📄️ 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.