Louis Knight-Webb 7de87e9b3a Add QA mode for automated testing with mock executor and hardcoded repos (Vibe Kanban) (#1940)
* The QA mode implementation is complete. Here's a summary of what was implemented:

## Summary

I've successfully implemented the QA mode feature for the vibe-kanban application. Here's what was created/modified:

### New Files
1. **`crates/services/src/services/qa_repos.rs`** - QA repos module that:
   - Defines two hardcoded QA repo URLs (`internal-qa-1` and `internal-qa-2`)
   - Clones repos to a persistent temp directory on first access using `git2`
   - Returns `DirectoryEntry` compatible with existing API

2. **`crates/executors/src/executors/qa_mock.rs`** - Mock executor that:
   - Implements `StandardCodingAgentExecutor` trait
   - Performs random file operations (create, delete, modify)
   - Streams 10 mock log entries in ClaudeJson format over 10 seconds
   - Reuses Claude's log processor for normalization

### Modified Files
1. **Cargo.toml files** - Added `qa-mode` feature flags to:
   - `crates/executors/Cargo.toml`
   - `crates/services/Cargo.toml`
   - `crates/server/Cargo.toml`

2. **`crates/executors/src/executors/mod.rs`** - Added:
   - Conditional `qa_mock` module export
   - `QaMock` variant to `CodingAgent` enum
   - Updated `capabilities()` match arm

3. **`crates/executors/src/mcp_config.rs`** - Added `QaMock` handling

4. **`crates/services/src/services/filesystem.rs`** - Override `list_git_repos` and `list_common_git_repos` in QA mode

5. **`crates/services/src/services/container.rs`** - Override `normalize_logs` executor lookup in QA mode

6. **`crates/executors/src/actions/coding_agent_initial.rs`** - Override spawn in QA mode

7. **`crates/executors/src/actions/coding_agent_follow_up.rs`** - Override spawn in QA mode

8. **`vibe-kanban/package.json`** - Added QA build scripts:
   - `backend:dev:qa`
   - `backend:dev:watch:qa`
   - `dev:qa`

### Usage
```bash
# Run backend in QA mode
cargo run --features qa-mode

# Or with pnpm
pnpm run dev:qa
```

When QA mode is enabled:
- `GitPanelCreate` will show only `internal-qa-1` and `internal-qa-2` as recent repos
- Starting any task will perform mock file operations and stream 10 logs over 10 seconds
- Logs follow the ClaudeJson format for compatibility with the existing log processor

* Cleanup script changes for workspace 15499061-ec87-4c1c-81b9-994e84d0e75b

* The TLS error fix is complete. I've replaced the `git2::Repository::clone` call with the `git` CLI approach in `qa_repos.rs`:

**Changes made:**
- Updated `clone_qa_repos_if_needed` function to use `Command::new("git")` with `["clone", "--depth", "1", url, path]` arguments instead of `git2::Repository::clone`
- Added `--depth 1` for shallow cloning (faster)
- Updated error handling to capture stderr output from the git command

The fix uses the git CLI which has reliable TLS support, avoiding the TLS configuration issues that git2 can have on some systems. This matches patterns used elsewhere in the codebase (e.g., `crates/remote/src/github_app/service.rs`).

You can now run `pnpm run backend:dev:qa` or `pnpm run dev:qa` and the QA repos should clone successfully.

* Cleanup script changes for workspace 15499061-ec87-4c1c-81b9-994e84d0e75b

* Done! I've made the mock logs strongly typed by:

1. **Added imports** for `ClaudeJson`, `ClaudeMessage`, `ClaudeContentItem`, and `ClaudeToolData` from the Claude executor

2. **Replaced `generate_mock_logs()`** to use strongly-typed structs:
   - Each log entry is now a proper `ClaudeJson` enum variant
   - Uses `ClaudeMessage` with proper fields (`id`, `message_type`, `role`, `model`, `content`, `stop_reason`)
   - Uses `ClaudeContentItem` variants (`Thinking`, `ToolUse`, `ToolResult`, `Text`)
   - Uses `ClaudeToolData` variants (`Read`, `Write`, `Bash`)
   - Serializes to JSON using `serde_json::to_string()` for correct escaping

3. **Updated tests** to verify the logs deserialize back to `ClaudeJson` types

This ensures:
- All fields match what `ClaudeLogProcessor::process_logs()` expects
- No manual JSON escaping needed (serde handles it)
- Compile-time type checking prevents malformed logs
- Session IDs are consistent across all entries

* Cleanup script changes for workspace 15499061-ec87-4c1c-81b9-994e84d0e75b

* Done! I've fixed the log display issue by replacing the shell echo approach with a temp file approach:

**Changes made to `crates/executors/src/executors/qa_mock.rs`:**

1. **Write logs to a temp file** instead of embedding them in a shell script:
   - Creates a temp file at `$TMPDIR/qa_mock_logs_{uuid}.jsonl`
   - Writes all logs as newline-delimited JSON

2. **Use `IFS= read -r` to read the file** - this preserves exact content:
   - `IFS=` prevents word splitting
   - `-r` prevents backslash interpretation
   - `echo "$line"` outputs the exact line content

3. **Clean up the temp file** after reading with `rm -f`

**Benefits:**
- No shell escaping needed - file contents are read verbatim
- Each line is output exactly as serialized by serde_json
- Avoids issues with single quotes, backslashes, and escape sequences
- Temp file is automatically cleaned up after use

This should fix the issue where logs were appearing as raw JSON or with corrupted content due to shell escaping issues.

* fix formatting

* Build succeeds. I've applied the same fix to the two remaining locations that had newlines in their content:

1. **Line 234** - README tool result: Changed `\n\n` to `\\n\\n`
2. **Line 302** - Bash tool result: Changed `\n` to `\\n`

This matches the pattern the user established in the assistant final message (line 318) where `\\n` is used instead of `\n` to ensure newlines are properly preserved through the serialization and display pipeline.

* Cleanup script changes for workspace 15499061-ec87-4c1c-81b9-994e84d0e75b

* simplify scripts

* update agents.md
2026-01-11 15:39:07 +00:00
2025-08-08 13:53:27 +01:00
2026-01-09 18:36:00 +00:00
2025-11-14 15:37:56 +00:00
2025-12-16 10:55:27 +00:00
2025-11-14 15:37:56 +00:00
2026-01-08 11:29:44 +00:00
2025-07-11 15:57:30 +01:00
2025-12-15 19:42:13 +00:00
2025-07-11 16:31:08 +01:00
2026-01-08 22:14:38 +00:00
2025-11-14 15:37:56 +00:00
2025-06-25 09:27:29 +01:00

Vibe Kanban Logo

Get 10X more out of Claude Code, Gemini CLI, Codex, Amp and other coding agents...

npm Build status Ask DeepWiki

We're hiring!

Overview

AI coding agents are increasingly writing the world's code and human engineers now spend the majority of their time planning, reviewing, and orchestrating tasks. Vibe Kanban streamlines this process, enabling you to:

  • Easily switch between different coding agents
  • Orchestrate the execution of multiple coding agents in parallel or in sequence
  • Quickly review work and start dev servers
  • Track the status of tasks that your coding agents are working on
  • Centralise configuration of coding agent MCP configs
  • Open projects remotely via SSH when running Vibe Kanban on a remote server

You can watch a video overview here.

Installation

Make sure you have authenticated with your favourite coding agent. A full list of supported coding agents can be found in the docs. Then in your terminal run:

npx vibe-kanban

Documentation

Please head to the website for the latest documentation and user guides.

Support

We use GitHub Discussions for feature requests. Please open a discussion to create a feature request. For bugs please open an issue on this repo.

Contributing

We would prefer that ideas and changes are first raised with the core team via GitHub Discussions or Discord, where we can discuss implementation details and alignment with the existing roadmap. Please do not open PRs without first discussing your proposal with the team.

Development

Prerequisites

Additional development tools:

cargo install cargo-watch
cargo install sqlx-cli

Install dependencies:

pnpm i

Running the dev server

pnpm run dev

This will start the backend. A blank DB will be copied from the dev_assets_seed folder.

Building the frontend

To build just the frontend:

cd frontend
pnpm build

Build from source (macOS)

  1. Run ./local-build.sh
  2. Test with cd npx-cli && node bin/cli.js

Environment Variables

The following environment variables can be configured at build time or runtime:

Variable Type Default Description
POSTHOG_API_KEY Build-time Empty PostHog analytics API key (disables analytics if empty)
POSTHOG_API_ENDPOINT Build-time Empty PostHog analytics endpoint (disables analytics if empty)
PORT Runtime Auto-assign Production: Server port. Dev: Frontend port (backend uses PORT+1)
BACKEND_PORT Runtime 0 (auto-assign) Backend server port (dev mode only, overrides PORT+1)
FRONTEND_PORT Runtime 3000 Frontend dev server port (dev mode only, overrides PORT)
HOST Runtime 127.0.0.1 Backend server host
DISABLE_WORKTREE_ORPHAN_CLEANUP Runtime Not set Disable git worktree cleanup (for debugging)

Build-time variables must be set when running pnpm run build. Runtime variables are read when the application starts.

Remote Deployment

When running Vibe Kanban on a remote server (e.g., via systemctl, Docker, or cloud hosting), you can configure your editor to open projects via SSH:

  1. Access via tunnel: Use Cloudflare Tunnel, ngrok, or similar to expose the web UI
  2. Configure remote SSH in Settings → Editor Integration:
    • Set Remote SSH Host to your server hostname or IP
    • Set Remote SSH User to your SSH username (optional)
  3. Prerequisites:
    • SSH access from your local machine to the remote server
    • SSH keys configured (passwordless authentication)
    • VSCode Remote-SSH extension

When configured, the "Open in VSCode" buttons will generate URLs like vscode://vscode-remote/ssh-remote+user@host/path that open your local editor and connect to the remote server.

See the documentation for detailed setup instructions.

Description
Get 10X more out of Claude Code, Codex or any coding agent
https://www.vibekanban.com/
Readme Apache-2.0 48 MiB
Languages
Rust 51.1%
TypeScript 46.6%
CSS 1.1%
JavaScript 0.7%
PLpgSQL 0.2%
Other 0.2%