An idea in. Shipped, tested software out.

One factory.
Four products.
A pipeline you can govern.

The Factory family turns a plan into merge-ready, verified software through a chain of autonomous services — each useful on its own, each built to hand off to the next, all following the PARR loop.

PFactory · Prepare AIFactory · Act TFactory · Reflect CFactory · Review

PPreparePFactory plans & governs — grounded in your real infrastructure.

AActAIFactory turns governed issues into merge-ready code.

RReflectTFactory generates & grades tests on a 5-signal verdict.

RReviewCFactory observes the whole pipeline and steers it — with you in the loop.

The CFactory cockpit's execution DAG for a finished run: five build subtasks, dependency edges fanning into a serial chain, every node green and stamped, stage complete — One real run, watched from the cockpit. The execution DAG is the build's own task graph — every box a unit of work, every edge a dependency — and it lights up as the work lands. Here: plan signed off, build green end to end, verification returned. The stamp on each node means a machine did it, not a person.

flowchart LR
    P["PFactory<br/>Prepare · Plan"] --> A["AIFactory<br/>Act · Code"]
    A --> T["TFactory<br/>Reflect · Verify"]
    T --> S(["Shipped"])
    C["CFactory · Review<br/>observe &amp; steer"] -.-> P
    C -.-> A
    C -.-> T
    classDef pf fill:#2b3a37,stroke:#83a598,stroke-width:2px,color:#cfe6de,font-weight:bold;
    classDef af fill:#3a2b18,stroke:#fe8019,stroke-width:2px,color:#f6cfa6,font-weight:bold;
    classDef tf fill:#33360f,stroke:#b8bb26,stroke-width:2px,color:#e2e4a0,font-weight:bold;
    classDef cf fill:#3a3115,stroke:#fabd2f,stroke-width:2px,color:#f6dd98,font-weight:bold;
    classDef sh fill:#26331a,stroke:#b8bb26,stroke-width:2px,color:#cfe6b0,font-weight:bold;
    class P pf; class A af; class T tf; class C cf; class S sh;

This is the repository for the whole program — cross-cutting plans, the shared pipeline, and the place the four products come together.

New: The Guarded PARR Pipeline — every step and decision from handover to merge, the sixteen guards that protect task & execution, and real adoption scenarios from solo builders to regulated enterprises.

The products

Prepare / Plan + Review

PFactory — governed planning, grounded in your infrastructure

The planning layer that sits in front of coding agents. It ingests plans, enriches them with live organizational context (Kubernetes, AWS/Azure/GCP, Backstage, internal wikis), runs architecture / security / feasibility review gates with citations, records human approval, and emits governed GitHub issues.

Context-grounded planning from real cloud + catalog state
Hybrid deterministic + LLM review gates, every verdict cited
Human-approval gate before any work is emitted
Kanban board, feasibility & cost estimates, living templates

PFactory portal — portal — plans overview

PFactory pipeline — enrich → decompose → review pipeline

PFactory review gates — review gates with citations

See the full PFactory tour → · Visit PFactory → · GitHub

Act

AIFactory — spec-first execution that ships merge-ready code

The swappable execution core — the Act stage of the pipeline. A planner writes a reviewable spec, a coder implements it in an isolated git worktree, and a QA agent validates against the spec — multi-provider, able to delegate to GitHub Copilot or GitLab Duo, and enterprise-grade. Because Prepare, Reflect and Review live in separate products, the engine that actually writes code can be replaced without touching the governance, verification or observability around it.

Spec-first: every run starts from a written, editable spec
Isolated worktrees — nothing touches main until you merge
Multi-provider, per-phase model selection; MCP control plane
Enterprise: SAML/SCIM, tenant isolation, audit, LiteLLM gateway

AIFactory mission control — mission control — the PARR pipeline over the board

AIFactory PARR logs — the PARR loop, streamed live

AIFactory observability — per-task token & resource observability

AIFactory live console — live agent console — QA suite passing

See the full AIFactory tour → · Visit AIFactory → · GitHub

Reflect / Review

TFactory — tests you can trust, not just a green bar

Autonomous test generation + execution across modality lanes (unit, browser, API, integration, mutation). It grades every generated test on a 5-signal verdict — coverage delta, stability re-runs, mutation kills, lint, semantic relevance — and posts a ranked triage report to your PR.

Five-signal verdict: meaningful tests, not coverage theatre
Modality lanes with real evidence (screenshots, video, HAR, mutants)
Bidirectional handback: failures route back to AIFactory’s QA fixer
Works from any AC source (markdown / Gherkin / EARS) or MCP

TFactory unit run — unit lane — generate, run, grade

TFactory polyglot run — polyglot — one spec, many languages

TFactory API lane — API lane with HAR evidence

TFactory verdict — graded, ranked triage report

See the full TFactory tour → · Visit TFactory → · GitHub

Review / Observe & Steer — new

CFactory — the control tower over all three

The newest member and the piece that turns the others into a suite. CFactory threads every unit of work across the three services into one WorkItem (keyed by GitHub issue), shows it on a single live cockpit, and adds an agentic copilot that explains pipeline state and proposes human-confirmed actions.

One pane of glass: where is every feature across plan → code → test
Agentic copilot: “why is #182 stuck?”, answered from real cross-service state
Advise + confirm: the copilot prepares actions; a human always clicks
Built on the family skeleton; reuses AIFactory’s enterprise security

Time-lapse of the CFactory execution DAG for work item 451, from ten queued build subtasks to ten complete — the same graph, time-lapsed as a real build lands

CFactory three-column pipeline board with running, in-review, queued and failed filters — every work item at its current stage, filterable

CFactory mission control — mission control — Plan · Code · Test, live

CFactory pipeline — one work item threaded by GitHub issue

CFactory copilot — agentic copilot — advise & confirm

CFactory audit — HMAC-chained audit of every action

See the full CFactory tour → · CFactory on GitHub →

How they cooperate

The products are independently useful, but their real power is the handoff chain — the cooperation we’re building out:

PFactory → AIFactory. PFactory emits governed GitHub issues; AIFactory picks them up and builds, carrying the issue number as provenance.
AIFactory → TFactory. A finished feature on a branch is handed to TFactory, which generates and grades a test suite against the acceptance criteria.
TFactory → AIFactory (handback). When tests fail, TFactory routes a correction request back to AIFactory’s QA fixer — a bounded, closed loop.
CFactory over everything. A shared correlation key — the GitHub issue number — threads plan → code → branch/PR → tests, so CFactory can show and steer the whole pipeline from one place.

flowchart LR PF["PFactory"] -- "issue #" --> AF["AIFactory"] AF -- "branch / PR · issue #" --> TF["TFactory"] TF -. "handback" .-> AF C["CFactory
observes every step ·
threads by issue #"] -.-> PF C -.-> AF C -.-> TF classDef pf fill:#2b3a37,stroke:#83a598,stroke-width:2px,color:#cfe6de,font-weight:bold; classDef af fill:#3a2b18,stroke:#fe8019,stroke-width:2px,color:#f6cfa6,font-weight:bold; classDef tf fill:#33360f,stroke:#b8bb26,stroke-width:2px,color:#e2e4a0,font-weight:bold; classDef cf fill:#3a3115,stroke:#fabd2f,stroke-width:2px,color:#f6dd98,font-weight:bold; class PF pf; class AF af; class TF tf; class C cf;

The connective tissue — a shared correlation key, a normalized completion-event schema, and a canonical local port map — is tracked as the PARR-spine epic in this repo.

See the full architecture → · Program roadmap → · Follow the blog →