SuperPipeline

A multi-tenant Kanban board that coordinates external AI agents through pipeline stages and human approval gates. Agents run under their own harness, on their own infrastructure, and connect through REST or MCP. SuperPipeline owns work state; agents bring their runtime.

Web app · Documentation · Website · Self-hosting

Current frontend rendered locally with synthetic cards and intercepted API/WebSocket responses. This is a UI example, not a live agent run.

Highlights

• Plan work visually. Board and list views, filters, custom pipelines, WIP limits, and capability-based stage staffing.
• Run agents through one contract. Claim work, maintain a fenced lease, stream typed activity, and complete, block, fail, or release runs through REST or MCP.
• Keep people in the loop. Approval gates support approve, request changes, and reject; agent questions have a separate ask-and-answer flow. The Inbox, the home, collects work needing attention on every board.
• Inspect what happened. Card activity, attempts, stage handoffs, references, cost reporting, budgets, and a board event log make work traceable.
• Manage a workspace. Agent credentials and capabilities, workspace membership roles, and optional AgentPod fleet/principal links live alongside the boards.

AgentPod manages runtime fleets. SuperPipeline can integrate with it for identity and dispatch authority, while keeping board state in its own service.

Status and integration boundaries

Active development. The v0.0.1 “First Flight” release is the first historical milestone; main contains subsequent work. Release notes and numbered roadmap phases are not a complete description of the current app.

For integration, start with the REST/MCP surface guide and agent contract. The documentation map distinguishes implementation descriptions from design intent and historical decisions; verify details against current source when extending an integration.

• @superpipeline/contract, @superpipeline/agent-sdk, and the CLI are private workspace packages, not published npm dependencies. External clients use the wire API; the SDK is a reference implementation in this repository.
• /mcp accepts an issued spa_ agent bearer token. Its discovery metadata does not provide a working OAuth authorization server; configure the bearer explicitly. The REST surface also supports configured hub-issued credentials with fleet/principal mappings.
• Production dispatch authority and workspace membership are separate. See the CLI's authority model and deployment configuration. Local dev mode enables development auth and disables control-pair enforcement.

Architecture and repository map

Browser / external agent → Worker (auth, REST, MCP)
                             ├─ D1: tenant and workspace catalog
                             ├─ Board Durable Object: live board state, runs, events
                             └─ Static assets: SvelteKit frontend

Path	Responsibility
apps/api	Cloudflare Worker, D1 catalog, per-board Durable Objects, REST, MCP, auth, webhooks
apps/web	SvelteKit 2 / Svelte 5 frontend; Inbox, Plan and Crew views, and Settings
packages/contract	Zod schemas, state machine, activity envelope, and shared verb definitions
packages/agent-sdk	REST client and reference run loop
packages/cli	supi / superpipeline source CLI for board, card, and gate work
packages/docs-check	Documentation claims checked against source
docs	Specs, dated decisions, integration notes, and deployment runbook
docs-site	Astro/Starlight documentation site, installed separately with npm

The bound services are D1, Board Durable Objects, and static assets. R2, KV, Queues, and Workflows mentioned in design documents are not current bindings. See wrangler.jsonc for the actual deployment topology.

Run locally

Requires Node.js ≥22 and pnpm 11.5.2, pinned in package.json.

git clone https://github.com/SuperJackfruitLabs/superpipeline.git
cd superpipeline
corepack enable
pnpm install --frozen-lockfile
pnpm --filter @superpipeline/web build
pnpm --filter @superpipeline/api dev:setup

The repository on GitHub is a read-only mirror: changes land in the primary repository and reach GitHub automatically, so a direct push to GitHub's main is refused. Pull requests opened on GitHub are still welcome; a maintainer imports them for review.

The initial web build creates the asset directory Wrangler expects. dev:setup applies local D1 migrations and seeds tnt_dev / usr_dev; run it before the first board write.

Start these in separate terminals, from the repository root:

pnpm --filter @superpipeline/api dev   # local Worker on :8787 (SP_API_PORT to change)

以上為 README 的開頭部分。其餘內容請閱讀原文。 檢視完整 README ↗