DevCue One is an open-source Electron + React desktop workspace for multi-session, voice-driven software development. It combines project-bound sessions, voice turns, text turns, local control flows, diagnostics, playback, and macOS release automation in one desktop app.
- Website: https://devcue.one/
- Chinese README: README_CN.md
- Bilibili Demo: https://www.bilibili.com/video/BV1oJXVBhESc/?share_source=copy_web&vd_source=54186efa4ddd36c2c793ae694ef28b7f
- Author on X: https://x.com/fukui_wuzhi
- License: MIT
DevCue One is designed as a persistent desktop developer workspace rather than a one-shot voice trigger.
Current product direction:
- Only the active session accepts microphone input.
- Each session can bind to a stable project profile and working directory.
- Background tasks continue while you switch to another session.
- Voice turns, text turns, local actions, task logs, diagnostics, and playback remain in the same session history.
- Voice acknowledgement, playback, diagnostics, and recovery paths are explicit rather than relying on a single happy path.
- Create, activate, rename, and manage multiple long-lived sessions
- Keep queued and running tasks alive while switching sessions
- Scope the left session column with
All / Current Project - Persist session history, status, and diagnostics per session
- Bind each session to a stable project profile
- Store working directory, default prompt context, and usage notes
- Optionally override the developer-tool choice per project without duplicating executable paths
- Restore project context when switching sessions
- Active-session-only voice capture
- Direct text submission and staged "next-turn supplement" input
- Clear handling for short transcripts, ignored turns, local actions, and supplement-assisted turns
- Recognition chime, acknowledgement cue, error chime, and result playback with fallback behavior
Supported developer tools:
- Codex
- Claude Code
- Cursor CLI
- Gemini CLI
- Qwen Code
Current path model:
- Global settings remember one executable path per supported tool and show the resolved runtime path actually used by the desktop app
- Project profiles only choose the tool override; they do not maintain a second path field
Supported STT / TTS modes:
- Browser / System
- Fake
- OpenAI
- Groq
- Alibaba Model Studio
- Volcengine Speech
- OpenAI-compatible custom HTTP endpoints
- Session-level diagnostics with session ID, the active backend's runtime session ID, task summary, and event stream
- Startup and runtime orphan-task recovery
- Browser-only mock mode and deterministic fake backend for UI/testing work
- Automated tests for state storage, developer-tool args, voice heuristics, packaging, signing, and notarization helpers
- Apple Silicon and Intel packaging
- Developer ID signing
- Apple notarization
- Gatekeeper validation
- Environment-driven local release flow with project-specific scripts and docs
- Bilibili product demo: https://www.bilibili.com/video/BV1oJXVBhESc/?share_source=copy_web&vd_source=54186efa4ddd36c2c793ae694ef28b7f
- Node.js
22+ nvmavailable locally; the repo ships with.nvmrc- At least one supported developer-tool CLI installed and logged in
- At least one usable STT / TTS provider if you want the real voice flow
git clone git@github.wzfukui:wzfukui/DevCueOne.git
cd DevCueOne
nvm install 22
nvm use 22
npm install
npm run dev:desktopRecommended first-run flow:
- choose a working directory for the first project
- grant microphone permission
- configure STT / TTS, or temporarily switch to
fake/testMode - configure the developer-tool CLI and verify its executable path
- confirm the resolved runtime path in global settings matches the binary you expect the desktop app to launch
# Electron + Vite development
npm run dev:desktop
# Browser-only UI development
npm run dev
# Automated tests
npm test
# Lint
npm run lint
# Build
npm run build
# Current-platform packaging
npm run release:local
# Preferred macOS packaging path
npm run release:mac:localRecommended entry point:
npm run release:mac:localRelated docs:
docs/operations/release-automation.mddocs/operations/macos-signing-and-notarization.mdenv/macos-signing.example.env
Preview-only alternatives:
npm run package:mac
npm run package:mac:arm64
npm run package:mac:x64electron/: Electron main process, IPC, state store, voice heuristics, developer-tool adapterssrc/: React renderer UI and voice hooksscripts/: release, notarization, and audio helper scriptsdocs/: architecture, product, operations, testing, and integration notestest/: automated tests for runtime helpers and release toolingwebsite/: marketing site and static website assets
- Real API keys, certificates,
.p8,.p12, and notarization credentials should never be committed - Keep local secrets in
.env,.env.local,.env.signing.local, or system environment variables - Signing and notarization docs in this repo use placeholders only
- Chinese product README:
README_CN.md - Technical runbook:
docs/operations/technical-runbook.md - Turn pipeline and project context:
docs/architecture/turn-pipeline-and-project-profile-context.md - Gemini CLI integration practice:
docs/integrations/gemini-cli-integration-practice.md - Release automation:
docs/operations/release-automation.md - macOS signing and notarization:
docs/operations/macos-signing-and-notarization.md - Product design archive:
docs/product/phase-2/product-design.md
- The current VAD is still engineering-grade prototype logic, not a production-grade speech segmentation system
- Local routing still covers only a limited set of high-frequency actions
- The app is currently optimized for developer workstations rather than zero-config end-user distribution
- A YouTube demo is planned, but the public demo link is Bilibili-only for now
Issues and pull requests are welcome. Before sending changes:
- use Node.js
22+ - keep secrets out of the repository
- run
npm run lint,npm test, andnpm run build
This project is released under the MIT License. See LICENSE.