If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/BloopAI/vibe-kanban shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 2w ago
• 14 active contributors
• Distributed ownership (top contributor 20% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live BloopAI/vibe-kanban repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/BloopAI/vibe-kanban.

What it runs against: a local clone of BloopAI/vibe-kanban — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in BloopAI/vibe-kanban | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 43 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of BloopAI/vibe-kanban. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/BloopAI/vibe-kanban.git
#   cd vibe-kanban
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of BloopAI/vibe-kanban and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "BloopAI/vibe-kanban(\\.git)?\\b" \\
  && ok "origin remote is BloopAI/vibe-kanban" \\
  || miss "origin remote is not BloopAI/vibe-kanban (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "crates/api-types/src/lib.rs" \\
  && ok "crates/api-types/src/lib.rs" \\
  || miss "missing critical file: crates/api-types/src/lib.rs"
test -f "crates/server" \\
  && ok "crates/server" \\
  || miss "missing critical file: crates/server"
test -f "crates/relay-protocol/src" \\
  && ok "crates/relay-protocol/src" \\
  || miss "missing critical file: crates/relay-protocol/src"
test -f "crates/db" \\
  && ok "crates/db" \\
  || miss "missing critical file: crates/db"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 43 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~13d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/BloopAI/vibe-kanban"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Vibe Kanban is a local-first/cloud IDE for managing AI coding agent execution pipelines. It combines a kanban board for planning issues with isolated workspaces that give coding agents (Claude Code, Gemini CLI, Codex, etc.) their own git branch, terminal, and dev server; users review diffs inline and merge PRs without leaving the UI. Rust monorepo with ~27 crates under crates/ organized by domain: crates/server (Axum HTTP), crates/relay-* (agent communication), crates/workspace-manager (execution isolation), crates/worktree-manager (git/file management), crates/tauri-app (desktop), crates/preview-proxy (dev server proxying). Frontend likely in packages/ (inferred from assets/). Workspace coordinated via Cargo.toml with resolver = "3".

Software engineers and teams who use AI coding agents (Claude Code, GitHub Copilot, Cursor, etc.) and want to parallelize planning, agent execution, and code review in a single unified interface rather than context-switching between GitHub, terminals, and chat interfaces.

Active but sunsetting—the repo shows a shutdown announcement on the README. The codebase is production-grade with 27 Rust crates, TypeScript/React frontend, Docker support, multiple deployment workflows, and comprehensive CI via GitHub Actions. However, the project is no longer being actively developed or maintained.

High risk due to active sunsetting and likely abandoned maintenance. The large monorepo spans 30+ interdependent crates (server, relay, workspace-manager, git-host, preview-proxy, relay-webrtc, etc.), creating high complexity and coupling. No clear test coverage metrics visible; dependency on unstable branches (ts-rs uses a fork with custom enum branch). Integration with 10+ external coding agents creates maintenance burden if agent APIs change.

Project is in shutdown mode per the README announcement. The most recent workflows visible are relay-deploy-prod, remote-deploy-prod, and publish pipelines, but development has halted. The codebase remains stable but no new feature work is expected.

git clone https://github.com/BloopAI/vibe-kanban.git
cd vibe-kanban
cargo build --release
# Desktop: cargo tauri dev (requires Tauri setup)
# Or npm run dev if TypeScript dev server exists in packages/

Note: Requires authentication with a supported coding agent (Claude, Gemini, etc.) and modern Rust toolchain.

Daily commands:

# Dev server (Rust backend)
cargo run --bin vibe-server  # Assumes main binary in crates/server

# Desktop app (requires Tauri setup)
cd crates/tauri-app && cargo tauri dev

# Docker deployment
docker build -t vibe-kanban . && docker run -p 5173:5173 vibe-kanban

See .github/workflows/test.yml for CI commands and .github/workflows/relay-deploy-*.yml for production deploy patterns.

• Cargo.toml — Workspace root defining all 30+ member crates and shared dependencies; essential for understanding the project's Rust architecture and build configuration.
• crates/api-types/src/lib.rs — Core API type definitions used across all services; changing these types cascades through the entire backend.
• crates/server — Primary backend server implementation; likely contains request routing and core business logic.
• crates/relay-protocol/src — Defines the relay communication protocol used between desktop, relay, and remote services.
• crates/db — Database layer with SQLx queries; all data persistence flows through this crate.
• .github/workflows — CI/CD pipeline definitions for testing, building, and deploying across dev/prod environments.
• README.md — Project overview showing this is a sunsetting Kanban tool for coding agents; critical context for all contributors.

Add a new API endpoint

1. Define request/response types in crates/api-types/src/ (e.g., my_feature.rs) (crates/api-types/src/lib.rs)
2. Add route handler in crates/server (typically routes.rs or a feature module) (crates/server)
3. Implement business logic in crates/services (crates/services)
4. Add database query in crates/db with SQLx SQL file (crates/db)
5. Export new type from crates/api-types/src/lib.rs (crates/api-types/src/lib.rs)

Add a new workspace or project feature

1. Define workspace metadata type in crates/api-types/src/workspace.rs (crates/api-types/src/workspace.rs)
2. Add workspace manager logic in crates/workspace-manager (crates/workspace-manager)
3. Add database schema migration and SQLx queries in crates/db (crates/db)
4. Create relay protocol message type in crates/relay-protocol for agent sync (crates/relay-protocol)

Integrate a new git host (GitHub/GitLab variant)

1. Add git provider trait in crates/git-host (crates/git-host)
2. Implement provider-specific OAuth in crates/api-types/src/oauth.rs (crates/api-types/src/oauth.rs)
3. Add repository sync logic in crates/git (crates/git)
4. Wire provider into server initialization in crates/server (crates/server)

Add a new relay deployment target

1. Add deployment config in crates/deployment or crates/local-deployment (crates/deployment)
2. Define relay host type in crates/relay-hosts (crates/relay-hosts)
3. Create GitHub Actions workflow in .github/workflows (e.g., relay-deploy-custom.yml) (.github/workflows)

• Rust + Tokio — Type safety, memory efficiency, and async I/O for handling multiple concurrent relay connections at scale.
• PostgreSQL (SQLx) — Compile-time query verification with SQLx ensures API consistency; ACID transactions for issue and workspace mutations.
• WebSocket + WebRTC — Bi-directional real-time communication for agents; WebRTC enables peer-to-peer relay connections with fallback tunneling.
• Tauri Desktop App — Cross-platform (Windows/macOS/Linux) desktop wrapper with native IPC bridge to Rust backend; lightweight alternative to Electron.
• Docker + GitHub Actions — Containerized deployments for relay and server; CI/CD automation for dev/prod environments.

• Monolithic workspace (30+ Rust crates) vs. microservices

  • Why: Unified dependency graph and compile-time safety; easier to refactor and coordinate type changes across layers.
  • Consequence: Longer build times; harder to scale individual services independently; requires careful crate boundaries.

• Tauri desktop app for agent interface

  • Why: Native performance and smaller bundle size compared to Electron; direct IPC to Rust backend without Node overhead.
  • Consequence: Smaller ecosystem for UI libraries; less community adoption than Electron; platform-specific quirks.

• Compile-time SQLx query verification

  • Why: Catch SQL errors at compile time; refactoring-safe.
  • Consequence: Requires live database during builds; query metadata checked into repo (.sqlx/); harder to refactor schema dynamically.

• Relay architecture (agent → relay → server/remote)

  • Why: Enables offline agent operation; simplifies firewall traversal; decouples agent from backend.
  • Consequence: Extra network hop; relay becomes a potential bottleneck; requires redundancy and failover logic.

• Does not provide real-time collaborative editing (separate service responsibility).
• Not a Git client; integrates with existing hosts (GitHub, GitLab) via API only.
• Does not store source code; indexes and manages references only.
• Not a general-purpose project management tool; optimized for AI agent workflows.

Database required: Must have PostgreSQL running; .env likely needs DATABASE_URL=postgres://.... Agent authentication: Each supported agent (Claude, Gemini, Copilot) requires separate auth setup—failure to configure blocks agent execution. Relay tunneling complexity: crates/relay-webrtc and crates/relay-tunnel-core add NAT traversal; misconfiguration causes agent-server disconnection. Monorepo Cargo.toml: Changes to workspace members require regenerating Cargo.lock. TypeScript codegen: ts-rs codegen for API types must run before frontend build—missing step breaks type safety. Fork dependency: ts-rs uses a non-standard branch (use-ts-enum) not in crates.io; risk of stale or incompatible updates.

• Workspace Isolation — Vibe's core value—each agent run gets its own branch, terminal, and dev server; understanding crates/workspace-manager and crates/worktree-manager is essential to modify execution model
• WebRTC Data Channels (Relay Tunneling) — crates/relay-webrtc enables P2P agent-to-server tunneling when direct connection fails; NAT/firewall traversal is critical for remote agent deployment
• Monorepo Workspace (Cargo) — 27 interdependent crates coordinated via single Cargo.toml with workspace resolver; dependency management and build performance depend on correct workspace setup
• Code Generation (ts-rs) — Backend Rust types auto-generate TypeScript definitions via ts-rs fork; frontend type safety depends on this codegen running before build
• Diff Visualization & Inline Comments — Core UX for code review in Vibe; requires parsing git diffs, matching hunks to source lines, and storing comment anchors—frontend likely uses a library like diff-match-patch
• Process Execution in Sandboxed Environments — crates/executors runs agent commands (build, test) in isolated contexts; security and resource limits are critical to prevent rogue agents from escaping
• MCP (Model Context Protocol) — crates/mcp enables agents to call tools (git, file I/O, bash); understanding MCP schema is key to extending what agents can do

• vercel/ai — SDK for building AI-powered apps in TypeScript/JS; Vibe uses agents that depend on LLM SDKs like this for Claude/Gemini calls
• continuedev/continue — Open-source IDE extension for Claude/other agents; similar goal of integrating agents into dev workflow but as an IDE plugin rather than standalone app
• janhq/jan — Desktop AI agent runner with local-first design; overlaps with Vibe's workspace isolation and desktop (Tauri) architecture
• github/copilot-cli — GitHub's agent CLI interface; Vibe wraps Copilot and other agents as first-class execution targets
• aider-ai/aider — Terminal-based AI pair programmer with git integration; predecessor model for agent-driven PR workflows that Vibe extends into a web UI

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for API types serialization and deserialization

The crates/api-types crate exports 20+ types (auth.rs, issue.rs, pull_request.rs, etc.) that are used across the workspace but lacks integration tests. Since ts-rs is configured to generate TypeScript types, testing round-trip serialization (Rust → JSON → TypeScript) would catch breaking changes early and ensure type safety across the Rust/Node boundary.

• [ ] Create crates/api-types/tests/integration_tests.rs
• [ ] Add test cases for each major type in crates/api-types/src/*.rs (auth, issue, workspace, organizations, etc.)
• [ ] Test serde serialization/deserialization for edge cases (null fields, empty arrays, nested objects)
• [ ] Verify ts-rs generated TypeScript matches actual serialized JSON in tests

Add GitHub Actions workflow for workspace-wide cargo checks and clippy linting

The repo has .github/actions/cargo-checks-common-setup but no unified workflow running cargo fmt, clippy, and test across the 24-member workspace. Current test.yml may not be comprehensive. A standardized pre-commit linting workflow would catch quality issues before merge and reduce review cycles.

• [ ] Create .github/workflows/cargo-lint.yml that runs on PR pushes
• [ ] Configure matrix strategy to run cargo fmt --check, cargo clippy --all-targets --all-features -- -D warnings, and cargo test --workspace in parallel
• [ ] Reference existing .github/actions/cargo-checks-common-setup/action.yml for common setup (Rust toolchain, dependencies)
• [ ] Add job status checks to GitHub branch protection rules in settings

Document the MCP (Model Context Protocol) crate public API with examples

The crates/mcp directory exists in the workspace but there's no crates/mcp/README.md or documentation on how external coding agents should integrate. Given the repo's core purpose ('Get 10X more out of Claude Code, Gemini CLI, etc.'), clear MCP integration examples would lower contributor friction and clarify the agent integration pattern used throughout the codebase.

• [ ] Create crates/mcp/README.md documenting the public API exported from crates/mcp/src/lib.rs
• [ ] Add a 'Quick Start' section with code examples showing how to initialize and use the MCP module
• [ ] Document the relationship between crates/mcp and crates/relay-protocol (used by agents)
• [ ] Reference AGENTS.md and CLAUDE.md to explain how agents consume this crate

• Add integration tests for crates/api-types issue schema—currently no visible test files; cover serialization of issue_assignee, issue_tag, and issue_comment types to ensure API contract stability.
• Document the relay protocol message flow in a PROTOCOL.md—currently only .github/actions/ and workflow YAMLs exist; a new contributor can trace crates/relay-protocol, crates/relay-ws, and crates/relay-control to write a message sequence diagram.
• Add environment variable validation to crates/server/src/main.rs—check for required vars (DATABASE_URL, GITHUB_TOKEN for git-host, STORAGE_BUCKET) at startup and fail with clear error messages rather than runtime panics.

• High · Unencrypted PostHog API Key in Docker Build Arguments — Dockerfile, lines with POSTHOG_API_KEY and POSTHOG_API_ENDPOINT. The Dockerfile exposes PostHog API keys and endpoints as ARG parameters without any encryption or masking. These values are passed as environment variables during the build process and could be logged in Docker build history, making them accessible to anyone with access to the image layers or build logs. Fix: Use Docker BuildKit secrets instead of ARG for sensitive data. Replace ARG POSTHOG_API_KEY with --secret and reference via RUN --mount=type=secret. Alternatively, pass these values at runtime only, not at build time.
• High · Incomplete Dockerfile Configuration — Dockerfile (incomplete). The provided Dockerfile snippet is truncated and incomplete (ends with 'ARG POSTHOG_API'). This incomplete configuration suggests potential missing security steps, missing FROM scratch or distroless final stage, and unverified build process. The full context cannot be assessed. Fix: Provide the complete Dockerfile for analysis. Ensure: (1) multi-stage builds use minimal final images, (2) no unnecessary layers with secrets, (3) proper file permissions, (4) non-root user execution.
• Medium · Arbitrary Node.js Memory Configuration — Dockerfile, NODE_OPTIONS line. The Dockerfile sets NODE_OPTIONS=--max-old-space-size=4096 as an environment variable. While not inherently insecure, this could be manipulated or exploited if the environment is not properly controlled, and high memory allocation can mask memory leaks. Fix: Use a fixed memory limit or configure this via build arguments with validation. Monitor and alert on memory usage. Consider using memory limits at the container orchestration level (e.g., Docker Compose, Kubernetes).
• Medium · Missing Security Headers and CORS Configuration — crates/server (inferred), axum and tower-http dependencies. The workspace depends on tower-http with CORS enabled, but the codebase structure doesn't show explicit security header configurations (no visible helmet, security middleware, or explicit header setup in API types). CORS misconfiguration could enable cross-origin attacks. Fix: Explicitly configure CORS with strict origin whitelisting. Add security headers middleware: X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, Content-Security-Policy. Validate all cross-origin requests.
• Medium · SQLx Query Caching Without Verification — crates/db/.sqlx/ directory and associated query files. The presence of .sqlx query cache files (crates/db/.sqlx/query-*.json) suggests compiled SQL queries are cached. If these caches are out of sync with actual database schema or if user input is improperly parameterized, SQL injection risks could exist. Fix: Ensure all database queries use proper parameterized statements with sqlx::query!() macros. Regenerate .sqlx cache files after schema changes. Never concatenate user input into SQL queries. Audit the db module for raw SQL usage.
• Medium · Dependency on External Git Repository for ts-rs — Cargo.toml, ts-rs dependency. The ts-rs dependency is pinned to a specific GitHub branch (xazukx/ts-rs:use-ts-enum) rather than a crates.io release. This introduces risk of: (1) branch deletion or unauthorized changes, (2) no vulnerability scanning, (3) supply chain attacks via compromised fork. Fix: Switch to an official crates.io release of ts-rs when available. If a fork is necessary, verify the maintainer's reputation, enable dependency scanning with tools like cargo-audit, and consider vendoring or mirroring the dependency.
• Medium · Weak Cryptographic Library Configuration — Cargo.toml, rustls, aws-lc-sys, aws-lc-rs dependencies. While rustls is configured with aws_lc_rs backend (secure), the dependency resolution includes aws-lc-sys and aws-lc-rs with pinned versions (=0.37.0, =1.16.0). Pinned versions could prevent security updates. Additionally, tls12 is enabled alongside tls13, which may expose downgrade attacks. Fix: Update version constraints to allow patch updates (0.37 ->

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.