Source: https://fireflyframework.org/forge/
Language: en

Firefly Forge, a Python software factory built on pyfly

# From a product brief to verified software.

Define the product, give a coding agent a bounded task, and review what it built. Forge runs the checks and keeps the evidence for each change.

[View the source](https://github.com/fireflyframework/firefly-forge) [See the Agent Bridge](https://fireflyframework.org/forge/#developer-tooling)

Built on pyfly · Studio, HTTP API, CLI, MCP

How it works

## How one change moves through the factory.

Forge keeps product decisions, source changes, checks, and delivery in one recorded workflow.

1. ### Define

   Save the customer journeys, features, integration contracts, and measurable acceptance criteria.
2. ### Prepare

   Choose the repository, the stack, the coding provider, the policies, and the execution limits.
3. ### Build

   A coding agent edits a clone of the repository on its own run branch, on the Forge host.
4. ### Verify

   Forge runs the project’s checks and sends failures back to the agent for a fixed number of repairs.
5. ### Deliver

   Review the diff, publish a pull request when you choose, then deploy to an authorized target.
6. ### Observe

   Inspect the running application’s health and link follow-⁠up work to the evidence behind it.

Agents

## One coding agent per run, and people review its work.

Forge hands the agent the framework instructions and the selected policies, then verifies the result itself.

### Your signed-in coding CLI

Use Codex or Claude Code with the login already on the factory host, or Firefly Agentic with a provider API key.

### Roles tied to stages

Seven roles, from product manager and architect to QA, security, and docs, map to factory stages. Mandatory roles and platform checks can’t be switched off.

### A frozen handoff

Queuing a run freezes its brief, roles, instructions, and available tools under a digest. Later edits leave that run’s work unchanged.

### A repair budget

Each run gets up to three repairs, two by default. It stops early when two rounds in a row leave the same source and failure.

### Worker questions

A blocked agent asks one typed question and the run pauses. The question and its answer survive restarts, and resuming is explicit.

### Optional review

A reviewer agent can check the verified source in a fresh context. Findings must cite real lines, and a request for changes blocks delivery.

Evidence

## Each step leaves its own record.

Generation means the provider returned a result. Verification means the configured commands ran and passed. Publication means a branch or pull request exists. Forge records each of these separately.

A run keeps its brief, provider, profiles, progress events, check results, and change evidence. Before publication Forge checks the verified source tree again, so changed source needs fresh verification.

Plans, task states, and a hash-chained journal are stored durably. Interrupted work resumes from that record, and an uncertain external effect waits for an operator.

Stacks

## Start with pyfly or larafly.

Forge gives the agent each framework’s own contracts. Add an Angular, React, Next.js, or Vue frontend when the product needs one.

### pyfly

Typed models, controllers, dependency injection, async services, and the Starlette web adapter. The agent takes pyfly from its official GitHub Releases.

[Explore pyfly](https://fireflyframework.org/frameworks/python/)

### larafly

Laravel-native service composition, attributes, repositories, and typed models. The agent reads the official skeleton and CLI stubs before it uses a namespace.

[Explore larafly](https://fireflyframework.org/frameworks/php/)

Operations

## Run the factory as a service your team shares.

Studio, the CLI, the Python client, and MCP tools all call the same authenticated HTTP API. Workers run code on the machine that hosts Forge.

### API and worker roles

Run one combined service, or API replicas that admit work beside a single headless worker that executes it.

### Git hosts

Connect GitHub, GitLab, Bitbucket Cloud, Azure DevOps, Gitea, or a plain Git remote. Forge checks the grant again before cloning or publishing.

### Sign-in and project roles

A shared installation signs people in through Keycloak, and project roles decide who can read and change each product.

### DevSecOps pipelines

Forge renders pipeline files for GitHub Actions, GitLab CI, and Bitbucket Pipelines: secret and Trivy scans, SBOMs, image builds, and optional signing.

### Deploy and roll back

A target names its deploy, check, and rollback commands. Forge deploys only the verified source tree and records every result.

### Recovery

Cancel, resume, hand off to another provider, or retry as a new run. A rate limit pauses the task and keeps its workspace.

Developer tooling

## A local bridge to your signed-in coding CLI.

Firefly Agent Bridge runs on a developer’s own machine. It connects Firefly Forge, application SDKs, and coding-agent hosts to that developer’s signed-in Codex or Claude Code CLI. Forge calls it as an OpenAI-compatible model and runs its own workspace tools.

Submit a job, continue its conversation, or run an ordered workflow. A local console shows each job’s tool inputs and results and the files it read or changed.

Callers authenticate with scoped tokens and use the HTTP API, the CLI, or MCP tools. It runs with that developer’s permissions, so it belongs on a trusted machine. Its code is under the Apache License 2.0.

[View the bridge source](https://github.com/fireflyframework/firefly-agent-bridge)

Next step

## Start the factory on your own computer.

The repository’s README covers the local setup with a signed-in coding CLI. The Firefly Software Foundation publishes Forge’s code under the Apache License 2.0.

[View the source](https://github.com/fireflyframework/firefly-forge) [Explore pyfly](https://fireflyframework.org/frameworks/python/)
