Fagan is an MCP-native autonomous SDLC (software development lifecycle) pipeline, with the core idea of "spend tokens on judgment, not on typing." Frontier models are billed per token and excel at judgment, while local models run for free and are sufficient for typing work, so the pipeline splits software engineering along this line: frontier models are responsible for decomposing work, making plans, reviewing diffs, and adjudicating anything risky, while local models write implementations at zero marginal cost.
The design draws on Michael Fagan's 1976 research at IBM: formal inspections found 82% of defects in released products (38 per thousand lines of code, versus 8 per thousand lines of code for unit tests). Quality lives in the gates, not in the author's hands. Therefore the project spends its budget on gates: mandatory TDD before implementation, independent review rounds, acceptance oracle scoring, a risk-tiered overlord (which stops and waits for a human on any irreversible operation), and a merge gate - rerunning the test suite on the rebased branch before merge is allowed. The goal is clear and specific: achieve enterprise-grade engineering discipline on a $20 per month budget - decomposition, TDD, code review, and dependency-ordered delivery.
Purpose and positioning: This is an autonomous coding pipeline that integrates with tools such as Claude Code through an MCP server, decomposing goals into epics/stories, dispatching implementation, review, and merge one by one. It is suitable for developers or teams that want engineering discipline at low cost, but the project explicitly warns that this is an autonomous coding pipeline with real and documented failure modes, and is not yet a fully hands-off "describe a feature, get a PR" tool; before use, read the reliability and limitations section.
Main capabilities: frontier model planning and review; local model implementation; TDD enforcement; independent review; acceptance oracle scoring; a risk-tiered overlord that pauses and waits for a human on irreversible operations; a merge gate that reruns tests on the rebased branch; a dashboard kanban; a scheduler that advances unattended; an independent run mode (dashboard + scheduler, without an MCP server); and a companion MCP server (only overlord and acceptance-oracle). It provides provider selection for 9 roles, supporting role configuration by schedule, a registry roles block, environment variables, and caller fallback, in decreasing priority order. The registry deliberately does not preset roles routing; operators must choose for themselves.
Usage: One-click installation is supported (clone to ~/.fagan and run scripts/install.sh); the installation script creates .venv, installs dependencies, and checks tools such as git, gh, and the claude CLI, and can be safely run repeatedly. You need to register the MCP server and copy the personas, then restart Claude Code. From a Claude Code session: have the product-analyst subagent turn the goal into epics/stories, or hand-write the plan according to the schema; save the plan with mcp__pipeline__save_plan, with repo_root pointing to the target project; use mcp__pipeline__list_ready_stories to view unblocked stories, and use mcp__pipeline__dispatch_story to claim and start one. Use the dashboard to view progress (scripts/dashboard.sh start, open http://localhost:8000）。无人值守可运行调度器 .venv/bin/python3 -m pipeline.scheduler_daemon. It is recommended to start with PIPELINE_AUTONOMY=dry-run (plan and log only, no dispatch and no merge), then switch after trusting the gate. You can also run .venv/bin/python scripts/smoke_getting_started.py for a smoke test, provider-neutral, where exit code 0 means pass, 1 means claude backend and CLI missing, 2 means the configured provider is empty or unrecognized, 3 means bounded polling timed out, 4 means the story failed.
Provider selection and authorization: this is a required step. The registry model_registry.json declares each provider's models but does not include roles routing. Selection order: plan role configuration > registry roles block > PIPELINE_BACKEND_<ROLE> environment variables > caller fallback. You can run .venv/bin/python scripts/choose_providers.py to interactively select nine roles, showing the current provider/model and source one by one, switching by number, and validating before writing. It supports PIPELINE_MODEL_REGISTRY_PATH pointing to any registry JSON, or using the gitignored model_registry.local.json. Selecting a provider means selecting the required credentials, and install_checks.py will detect and report unauthorized status. Ollama :cloud tags go through the local ollama daemon via https://ollama.com proxy, using its own credentials; pure local tags only require the daemon to be running.
Standalone operation: the dashboard exposes the same operations as the MCP tools (save/ingest plan, decompose goals, dispatch stories, advance, review, approve merge), and can be scripted via HTTP API. It supports a single command up to start the dashboard and scheduler, provision a temporary data directory (default ~/pipeline-standalone), write the shared operator env file, and report success only after health checks pass; down stops the processes while preserving data; status prints paths and status. Both processes read .pipeline.env first, then .dashboard.env, and the latter overrides the former.
Platform support: daily development and operation are on macOS. The core (MCP server, dashboard, Claude backend dispatch/review, full test suite) is pure Python, and CI tests on Ubuntu with Python 3.12–3.14. launchd/*.plist and MLX (PIPELINE_LOCAL_PROVIDER=mlx) are macOS-specific; on Linux you can use scripts/generate_systemd_units.sh to generate systemd units, or run directly in the foreground; local dispatch on Linux can use Ollama or LM Studio. Windows is untested.
Limitations and cautions: the project explicitly states that this is an autonomous coding pipeline with real and documented failure modes, not a fully hands-off tool. The first run does not require a local model; dispatch and review fall back to the claude backend, but this is a starting configuration rather than the intended configuration, and cost splitting can only be achieved by deliberately routing implementation roles to local models. Using the claude path also requires two credentials: gh auth login and the Claude Code CLI's own login. PIPELINE_AUTONOMY defaults to gated, and low-risk stories that pass review can be merged unattended. See REFERENCE.md for detailed reference.
Specific features, fees, prices, platform effects, and other details not provided in the materials are not yet available.
