2.5 KiB
Repository Guidelines
Project Structure & Module Organization
The root package is the Bun-based CLI and local server. Main code lives in src/: entrypoints/ for startup paths, screens/ and components/ for the Ink TUI, commands/ for slash commands, services/ for API/MCP/OAuth logic, and tools/ for agent tool implementations. bin/claude-haha is the executable entrypoint. The desktop app is isolated in desktop/ with React UI code in desktop/src/ and Tauri glue in desktop/src-tauri/. Documentation is in docs/ and builds with VitePress. Treat root screenshots and docs/images/ as reference assets, not source code.
Build, Test, and Development Commands
Install root dependencies with bun install, then install desktop dependencies in desktop/ if you are touching the app UI.
./bin/claude-hahaorbun run start: run the CLI locally.SERVER_PORT=3456 bun run src/server/index.ts: start the local API/WebSocket server used bydesktop/.bun run docs:dev/bun run docs:build: preview or build the VitePress docs.cd desktop && bun run dev: run the desktop frontend in Vite.cd desktop && bun run build: type-check and produce a production web build.cd desktop && bun run test: run Vitest suites.cd desktop && bun run lint: run TypeScript no-emit checks.
Coding Style & Naming Conventions
Use TypeScript with 2-space indentation, ESM imports, and no semicolons to match the existing code. Prefer PascalCase for React components, camelCase for functions, hooks, and stores, and descriptive file names like teamWatcher.ts or AgentTranscript.tsx. Keep shared UI in desktop/src/components/, API clients in desktop/src/api/, and avoid adding new dependencies unless the existing utilities cannot cover the change.
Testing Guidelines
Desktop tests use Vitest with Testing Library in a jsdom environment. Name tests *.test.ts or *.test.tsx; colocate focused tests near the file or place broader coverage in desktop/src/__tests__/. No coverage gate is configured, so add regression tests for any behavior you change and run the relevant suites before opening a PR.
Commit & Pull Request Guidelines
Recent history follows Conventional Commit prefixes such as feat:, fix:, and docs:. Keep subjects imperative and scoped to one change. PRs should explain the user-visible impact, list verification steps, link related issues, and include screenshots for desktop or docs UI changes. Keep diffs reviewable and call out any follow-up work or known gaps.