Contributing to ADHDev

April 4, 2026 ยท View on GitHub

Thank you for your interest in contributing to ADHDev! ๐Ÿฆฆ

๐Ÿ”Œ Adding a New Provider

Are you looking to add support for a new IDE, CLI, or ACP agent?

Providers live in the external vilmire/adhdev-providers repository. The daemon automatically downloads these providers on startup and mirrors the category-based structure in your local ~/.adhdev/providers/ directory.

๐Ÿ‘‰ Start with the Provider Contribution Guide in the providers repository.

For a deeper walkthrough, see the provider guide on docs.adhf.dev.


๐Ÿ› ๏ธ Contributing to ADHDev Core

If you want to contribute to the core ADHDev engine (the daemon, the web dashboard, or the DevConsole), you are in the right place.

Development Setup

git clone https://github.com/vilmire/adhdev.git
cd adhdev
npm install

# Canonical full build (encodes the current package order)
npm run build

# Common focused builds while iterating
npm run build -w packages/daemon-core
npm run build -w packages/web-standalone
npm run build -w packages/daemon-standalone

# Run the daemon (dashboard at http://localhost:3847)
node packages/daemon-standalone/dist/index.js

# Or use dev mode (Vite hot-reload for dashboard)
npm run dev

๐Ÿ“ Project Structure

packages/
โ”œโ”€โ”€ daemon-core/           # Core engine โ€” CDP, providers, commands, lifecycle
โ”œโ”€โ”€ daemon-standalone/     # Self-hosted HTTP/WS server (localhost:3847)
โ”œโ”€โ”€ session-host-core/     # Session registry + transport protocol
โ”œโ”€โ”€ session-host-daemon/   # Long-lived session runtime (adhdev-sessiond)
โ”œโ”€โ”€ terminal-mux-core/     # Terminal mux runtime
โ”œโ”€โ”€ terminal-mux-control/  # Terminal mux control/storage helpers
โ”œโ”€โ”€ terminal-mux-cli/      # adhmux client
โ”œโ”€โ”€ terminal-render-web/   # Web terminal renderer
โ”œโ”€โ”€ ghostty-vt-node/       # Ghostty VT bindings
โ”œโ”€โ”€ web-core/              # Shared React components, pages, CSS design system
โ”œโ”€โ”€ web-standalone/        # Standalone React dashboard (Vite + React)
โ””โ”€โ”€ web-devconsole/        # DevConsole โ€” provider debugging tools

Key Source Files

PackageKey FilePurpose
daemon-coresrc/boot/daemon-lifecycle.tsinitDaemonComponents() / shutdownDaemonComponents()
daemon-coresrc/cdp/initializer.tsDaemonCdpInitializer โ€” multi-IDE CDP management
daemon-coresrc/commands/router.tsDaemonCommandRouter โ€” unified command routing
daemon-coresrc/providers/provider-loader.tsProviderLoader โ€” load/update provider.js
daemon-standalonesrc/index.tsHTTP/WS server + lifecycle integration
web-coresrc/pages/Dashboard.tsxMain dashboard page

๐Ÿ—๏ธ Build Order

Use the root npm run build whenever possible. It already encodes the current dependency order, including the session-host and terminal-mux packages.

If you need to build selectively, keep the dependency chain in mind:

1. session-host-core / ghostty-vt-node
2. daemon-core / terminal-mux-core / terminal-mux-control
3. terminal-mux-cli / session-host-daemon / terminal-render-web
4. web-core
5. web-standalone / web-devconsole
6. daemon-standalone

๐Ÿงช Testing

# Type-check (no emit)
npx tsc --noEmit -p packages/daemon-core/tsconfig.json
npx tsc --noEmit -p packages/session-host-daemon/tsconfig.json
npx tsc --noEmit -p packages/daemon-standalone/tsconfig.json

# Run standalone daemon
node packages/daemon-standalone/dist/index.js
# Dashboard at http://localhost:3847

# Verify the build
head -1 packages/daemon-standalone/dist/index.js | grep '#!/usr/bin/env node'

๐Ÿ“ Code Style

  • TypeScript strict mode
  • Prefer explicit types over any โ€” use unknown for generic data, cast with type guards
  • JSDoc comments on public interfaces and exported functions
  • Use standard React hooks for the frontend (no class components)

๐Ÿ”„ Development Workflow

  1. Fork the repository and create a branch: git checkout -b feat/my-new-feature
  2. Implement your changes in the appropriate package.
  3. Build affected packages in dependency order.
  4. Test by running the standalone daemon locally.
  5. Submit a PR to the main branch.

โ“ Need Help?

If you find a bug or have a feature request for the core engine, please open an Issue.

๐Ÿ“œ Contributor License Agreement (CLA)

Before your Pull Request can be merged, you must sign our CLA.

When you open a PR, a bot will automatically prompt you. Reply with:

I have read the CLA Document and I hereby sign the CLA

This is a one-time step that allows ADHDev to distribute your contribution under both AGPL-3.0 and commercial licenses.