diff --git a/.agents/skills/e2e/SKILL.md b/.agents/skills/e2e/SKILL.md index 1a16bd4e21..af9f409af5 100644 --- a/.agents/skills/e2e/SKILL.md +++ b/.agents/skills/e2e/SKILL.md @@ -272,6 +272,13 @@ cd apps/web && npx playwright test --config e2e/playwright.config.ts --shard=2/1 E2E tests run against the **production build** (`next build`), not dev mode. Always rebuild with `make build-web` (or `pnpm --filter @kandev/web build`) after code changes before running E2E tests locally. +```bash +# Unzip a shard's blob report from CI artifacts +unzip report-*.zip -d report-shard && cat report-shard/*.jsonl +``` + +When a CI shard fails, download its report-*.zip artifact and unzip it; the report is a *.jsonl event stream. Build a testId map by walking the events: test titles and locations come from the testBegin events, and final status plus duration come from the testEnd events. Match them by test id. This surfaces the slow but passing specs (the timing markers in Playwright output) that never show up as outright failures but are latent flake risks. Specs whose duration approaches the 60s per-test timeout (defined in playwright.config.ts) are the flake candidates to harden. Typically by converting raw chat-flow assertions to the waitForChatIdle() / expectChatResponseVisible() recovery helpers documented earlier in this file. + ### Flake triage: intrinsic race vs. contention A test that flakes under parallel/sharded load is one of two things — decide which **before** touching it: diff --git a/README.md b/README.md index 5c14dca2f7..e917a18606 100644 --- a/README.md +++ b/README.md @@ -29,16 +29,16 @@ Open source, multi-provider, no telemetry, not tied to any cloud. ## Features -- **Multi-agent support** - Claude Code, Codex, GitHub Copilot, Gemini CLI, Amp, Auggie, OpenCode, Cursor, Qwen, Factory Droid, iFlow, Kilocode, Pi, Kimi, AWS Kiro, Qoder, Trae +- **Multi-agent support** - Claude Code, Codex, GitHub Copilot, Gemini CLI, Amp, Auggie, OpenCode, Cursor, Qwen, Factory Droid, iFlow, Kilocode, Pi, Kimi, AWS Kiro, Qoder, Trae, Oh My Pi - **Parallel task execution** – start and manage multiple tasks from different sources simultaneously, boosting productivity with AI agents - **Integrated workspace** - Built-in terminal, code editor with LSP, git changes panel, embedded vscode and chat in one IDE-like view - **Kanban task management** - Drag-and-drop boards, columns, and workflow automation -- **Agentic workflows** - Multi-step pipelines that mix-and-match agents per step - for example, Claude Code Opus to design a plan, GitHub Copilot Sonnet to implement it, and Codex GPT 5.4 to review the changes. See [docs/workflows.md](docs/workflow-tips.md) +- **Agentic workflows** - Multi-step pipelines that mix-and-match agents per step - for example, Claude Code Opus to design a plan, GitHub Copilot Sonnet to implement it, and Codex GPT 5.4 to review the changes. See [docs/workflow-tips.md](docs/workflow-tips.md) - **Sub-tasks** - Agents can spawn sub-tasks that resume from the parent task's session. Useful for splitting a task that has grown too big, or producing several PRs from the same starting point. - **CLI passthrough** - Drop into raw agent CLI mode for direct terminal interaction with any supported agent, leverage the full power of their TUIs - **Workspace isolation** - Git worktrees prevent concurrent agents from conflicting - **Multi-repository tasks** - Span a single task across multiple repositories, with one worktree per repo, per-repo branches, per-repo PRs, and per-repo grouping in the Changes panel and review dialog -- **Flexible runtimes** - Run agents as local processes, in isolated Docker containers or in remote executors like sprites.dev +- **Flexible runtimes** - Run agents as local processes, in isolated Docker containers, on remote servers via SSH, or in cloud executors like sprites.dev - **Session management** - Resume and review agent conversations - **Stats** - Track your productivity with stats on the completed tasks, agent turns, etc @@ -49,6 +49,8 @@ Open source, multi-provider, no telemetry, not tied to any cloud. Jira Linear Sentry + GitLab + Slack

Connect Kandev to the tools your team already uses — pull issues into the kanban, link tasks to PRs, and surface review activity inline. @@ -74,6 +76,7 @@ Connect Kandev to the tools your team already uses — pull issues into the kanb | **Kiro** | `kiro-cli-chat acp` *(install Kiro CLI from AWS)* | | **Qoder** | `qodercli --acp` *(install Qoder CLI)* | | **Trae** | `traecli acp serve` *(install Trae IDE CLI)* | +| **Oh My Pi** | `omp acp` *(install `bun install -g @oh-my-pi/pi-coding-agent`)* | > All agents communicate via [ACP](https://agentclientprotocol.com) (Agent Client Protocol). Some agents support ACP natively, while others use ACP adapter packages that bridge their native protocols. **CLI Passthrough mode** is also available for direct terminal interaction with any agent CLI. If your agent isn't supported yet, open an issue or submit a PR with the integration. See [Adding a New Agent CLI](docs/add-agent-cli.md) for a step-by-step guide. @@ -87,6 +90,7 @@ There is support for running any agent as TUI inside a terminal. Just add the cl |:--------:|-------------| | **Local Process** | Runs the agent as a local process on the host machine | | **Docker** | Runs the agent in an isolated Docker container | +| **SSH** | Runs the agent on a remote server over SSH | | **Sprites** | Runs the agent in a remote cloud environment via [sprites.dev](https://sprites.dev) | Each executor uses git worktrees for workspace isolation, preventing concurrent agents from conflicting. @@ -146,7 +150,7 @@ graph LR Backend["Backend (Orchestrator)"] - Backend --> W1 & W2 + Backend --> W1 & W2 & W3 & W4 subgraph W1[Local Process] Agent1[Agent CLI] --- WT1[Worktree] @@ -155,11 +159,18 @@ graph LR subgraph W2[Docker Container] Agent2[Agent CLI] --- WT2[Worktree] end + + subgraph W3[SSH Remote] + Agent3[Agent CLI] --- WT3[Worktree] + end + + subgraph W4[Sprites Cloud] + Agent4[Agent CLI] --- WT4[Worktree] + end ``` -We also want to add support for these remote runtimes: -- Remote SSH - run agents on remote servers over SSH, using docker or local processes with workspace isolation -- K8s operator - run agents in a Kubernetes cluster, with auto-scaling and resource management. +We also want to add support for this remote runtime: +- **K8s operator** - run agents in a Kubernetes cluster, with auto-scaling and resource management.
Development @@ -171,12 +182,13 @@ apps/ ├── backend/ # Go backend (orchestrator, lifecycle, agentctl, WS gateway) ├── web/ # Next.js frontend (SSR, Zustand, real-time subscriptions) ├── cli/ # CLI tool (npx kandev launcher) +├── landing/ # Landing page └── packages/ # Shared UI components & types ``` ### Prerequisites -- Go 1.21+ +- Go 1.26+ - Node.js 18+ - pnpm - Docker (optional) @@ -218,8 +230,8 @@ pre-commit install There are a few similar tools in this space, and new ones appearing everyday. Here's what sets this one apart: - **Server-first architecture** - Not a desktop app. Runs as a server you can access from any device, including your phone. Start a task away from your computer and check in on it later. -- **Remote runtimes** - Run agents on remote servers and Docker hosts, not just your local machine. -- **Multi-provider** - Use Claude Code, Codex, Copilot, Gemini, Amp, Auggie, OpenCode, Cursor, Qwen, Droid, iFlow, Kilocode, Pi, Kimi, Kiro, Qoder, and Trae side by side. Not locked to one vendor. +- **Remote runtimes** - Run agents on remote servers via SSH, Docker hosts, and cloud environments, not just your local machine. +- **Multi-provider** - Use Claude Code, Codex, Copilot, Gemini, Amp, Auggie, OpenCode, Cursor, Qwen, Droid, iFlow, Kilocode, Pi, Kimi, Kiro, Qoder, Trae, and Oh My Pi side by side. Not locked to one vendor. - **CLI passthrough and chat** - Interact with agents through structured chat messages or drop into raw CLI mode for full agent TUI capabilities. - **Open source and self-hostable** - No vendor lock-in, no telemetry, runs on your infrastructure.