🏭 Factory Workbench Pipeline

Status: On going longterm project

What Is This Project?

I am building an autonomous software production assembly line. There is a 6-stage pipeline that takes raw ChatGPT conversations and progressively tightens them into structured requirements, tested features, AI-generated code, and validated Git branches. The pipeline spans multiple separate Laravel applications on the same local machine. Theoretically this should simulate a, from my experience, what a functional Software Developer team does.

1. Goals

What this pipeline must achieve to be considered valuable

Automated Context-Driven Development (CCDF): Gather and inject all necessary requirements, goals, and context seamlessly to orchestrate a “vibecoding” environment where A.I. frameworks are efficient and not bogged down by excess information.
Behavior-Driven Development (BDD) via TYS Loops: Implement true “Shift Left” development. The pipeline must ensure that tests and behavior are locked down (Code Coverage Sprints) before applying Bob Martin’s “Clean Code” principles through automated agents, continuously triggering via event-driven architecture.
Production Deployment with Human Oversight: Serve as the gatekeeper to the production environment, allowing the automated system to prepare fully reviewed Pull Requests while keeping a human in the loop for final approval and deployment.

2. Success Metrics

How we will empirically know the pipeline is succeeding:

Pull Request Generation Rate: The volume of completed, pass-testing Pull Requests generated and pushed to GitHub without initial human intervention.

Automated Story Completion: Ticket status successfully moving from “To Do” to “Done” (Closed) autonomously.

Full Integration of Vera/Agents: The system (Vera or equivalent) can operate with full systemic access (browser, programs, deep OS interactions) to perform end-to-end testing just like a human (similar to the Antigravity architecture).

CI/CD Parity: The pipeline rivals enterprise tools (like Jira + Bamboo) for automated deployments, rollback setups, sprint planning, and goal tracking.

Autonomous Agent Collaboration: Measurable interactions between specialized agent personas (Piper, Mason, Tess, Vera, Moltbot) communicating dynamically within the tickets themselves via WebSockets/Livewire.

Reflection: I would like for this system to be self improving. At the very least be able to see reocurring bugs and be able to fix them faster or learn what causes them and does what it can to avoid them.

The Pipeline (6 Stages)

ChatProjects → Lean Inception → The Writers Room → The Dev Backlog → Code Factory → QA → Git/Reflection

Stage	Application	Philosophy
1. Lean Inception 🏭 Idea Furnace	`ChatProjects` (PostgreSQL)	Lean Inception
2. 📋 Writers Room	`TheWritersRoom` + handoff to `TheDevBacklog`	The `Writers Room`
3. Dev Backlog 📚 Backlog Warehouse	`TheDevBacklog`	Agile Scrum
4. 🤖 Code Factory 🚀 Git Launch Pad	I’m trying multiple things, one of them is using Godot.	A work in progress.
5-6. QA and Reflection	`No solid application yet`.	Architecture docs live here Future database of lessons learned. The idea is to setup a learning system.

QA plan is to start my own CI/CD pipeline
The Reflection is quite far away and I won’t plan too much until I see 4. Code Factory and 5 Reflection / Retrospectives working.

What Has Been Completed ✅

Phase 1: ChatGpt → ChatProjects

Feed the ChatGpt to a database called ChatProjects
its just called Projects in github but the idea is to synchronize the ideas in the conversations with the intake system that is inspired by Lean Inceptions.

Stories and sprints are created and queued up.

What Remains (Phases 4,5 & 6) ❌

Phase 4: Code Factory → QA

The Code is created but not in git yet.
Create work_runs and task_runs tables in TheDevBacklog
Create qa_runs table
assignee_agent column already exists on story_tasks (done in Phase 3)

Phase 5: Git Repos → Reflection

Create git_repos, git_branches, git_commits tables
Build event listeners to mirror Deckard/OpenClaw outputs into the DB
Feed QA and Git events back into Story/Feature status

Important Gotchas & Lessons Learned

I want to call this the Retrospective, and lessons learned are retrospections.

The following points are an example of what Reflection or Lessons learned might be like (Generated by Gemini)

ChatProjects uses PostgreSQL (port default), TheDevBacklog uses MySQL on port 3309. Don’t mix up the database engines when writing migrations.
The inception_features table is NOT something I can easily see right now, and I want to be able to allow the user to view it when opening up projects in ChatProjects.
Laravel log permissions in TheDevBacklog can sometimes cause storage/logs/laravel.log permission denied errors. The underlying migration may still succeed even if the error log write fails check the database directly.
Migration ordering matters — if two migrations share a timestamp, Laravel runs them alphabetically. This caused feature_tests to run before features initially (since c < f). Fixed by bumping the feature_tests timestamp to 171630.
The StoryTaskObserver (from bd integration) is registered in AppServiceProvider alongside the new FeatureObserver. Both fire on model events.

The Lessons I’ve learned:

It isn’t easy to vibecode a vibecoding system, I am now shifting to new strategies and I might just completely redo the part that does the actual code generation.
What I have learned is often you have to swap between a.i. assisted coding and vibecoding. I often ask the agents to document thoughts.md which is a document explaining why they are doing what they are doing.
It turns out when you ask an A.I. to tell you what their thoughts are they say “Thats impossible” 🙂
I also do something I’ll call A.I. dogfooding. I tell it to use the Factory Workbench Pipeline to generate the code it is trying to write, and if they find any blockers they are then permitted to modify the pipeline code directly.

What I want to do next (Phases 4 & 5 again)

Phase 4/5: Create the Construction site.

The Code is created but not in git yet and I need to fix that.
But unlike the whole system described above I want the development to happen with branches being created first. because that is how I develop code (While I’m employed)

Phase 4 — Arcane Arcade Machine Code Factory

The goal of this phase is to transform backlog tasks into executable work units.

The Constructicon Factory will introduce an agent-based development workflow coordinated by a dispatcher called Tess.

The workflow will follow a role-based pipeline similar to a real engineering team:

Piper → Mason → Ollan → Vera

Where:

Agent	Responsibility
Piper	Clarifies scope, acceptance criteria, and requirements
Mason	Generates implementation plans and file targets
Ollan	Performs repository edits and code generation
Vera	Executes QA validation, tests, and code checks
Tess	Dispatches tasks and coordinates workflow execution

The Constructicon runtime will also introduce structured agent communication packets instead of raw prompts.

Example packet types:

AssignmentPacket
PlanPacket
BuildResultPacket
QaResultPacket

These packets allow agents to collaborate deterministically and provide clear debugging visibility.

Phase 4 Technical Goals

Implement the Tess Dispatcher inside the Context Controlled Development Factory (CCDF).

Key components:

Task Execution Tracking

Create new tables in TheDevBacklog:

work_runs
task_runs
qa_runs

These tables will track:

which agent executed a task
execution duration
test results
retry attempts

Agent Assignment

Use the existing assignee_agent field on story_tasks to dispatch tasks to agents.

Example workflow:

story_task → Mason planning
story_task → Ollan implementation
story_task → Vera QA validation

Repository Integration

Add repository awareness to the pipeline.

Introduce database tables:

git_repos
git_branches
git_commits

These will allow the pipeline to track generated branches and commits produced by the Code Factory.

Phase 5 — Reflection System

The Reflection system will act as a continuous improvement engine for the pipeline.

Instead of simply executing tasks, the system will record and analyze how the pipeline behaves.

The goal is to identify:

recurring test failures
slow agent workflows
repeated bug patterns
QA rejection reasons

This data will allow the system to gradually improve development efficiency.

Phase 5 Technical Goals

Create a Replay Ledger that records important pipeline events.

Each stage of the pipeline will emit structured events such as:

task claimed
assignment dispatched
plan generated
code generated
QA pass / fail
retry scheduled

These events will be stored in an append-only event log to allow deterministic replay of development workflows.

Example event structure:

task_id
run_id
agent
event_type
timestamp
artifact_reference

The Reflection system will then be able to:

replay development sessions
analyze agent performance
generate retrospectives
identify bottlenecks

Long Term Goal

The long-term vision of the Factory Workbench Pipeline is to simulate a self-improving software development organization.

Instead of a single AI tool generating code, the system models a collaborative development team composed of specialized agents with clearly defined roles.

The intended outcome is a development environment where:

ideas become structured requirements
requirements become tasks
tasks become code
code becomes validated pull requests
lessons learned improve the system itself

All while maintaining human oversight at critical decision points.

What I Will Demonstrate Next

The next milestone I plan to demonstrate on this project will be:

The first Tess-dispatched task
Mason generating a structured implementation plan
Ollan producing code changes
Vera performing QA validation
A fully generated Git branch and Pull Request

This will represent the first complete end-to-end pipeline execution.

Codebase Locations

Repo	Path	Purpose
ChatProjects	`/home/myhome/Code/ChatProjects`	Conversations, Inceptions, Artifacts
TheWritersRoom	`/home/myhome/Code/TheWritersRoom`	Epics, Stories, Sprint dispatch
TheDevBacklog	`/home/myhome/Code/TheDevBacklog`	Features, Tasks, Sprint mgmt, Deckard
CCDF	`/home/myhome/Code/ContextControlledDevelopmentFactory`	Code Factory / Tess Engine
TheReflection	`/home/myhome/Code/TheReflection`	Architecture docs, pipeline docs
PiperStoryArchitect	`/home/myhome/Code/PiperStoryArchitect`	AI Story Architect agent
ThePostalService	`/home/myhome/Code/ThePostalService`	Inter-service message delivery
ISBD	`/home/myhome/Code/InceptionAndStoryBridgeToDev`	Bridge between WritersRoom and DevBacklog
Portfolio	`/home/myhome/Code/Portfolio`	Craig’s portfolio site

This is actually becoming a problem

There are too many little modular parts of the whole but eventually I want to have one repo that controls them all.

I want to turn all these folders git submodules.
Have a install programmer similar to old windows apps.
Setup dependencies, databases, and environment variables.
Identify what is left behind by trying to reproduce the system on a computer with none of the parts.

Why I’m Building This

This project is not only intended as a portfolio piece. It is also an open experiment in software development architecture.

Over the years I have noticed that many developer teams are structure a

backlog systems
CI/CD pipelines
QA automation
deployment strategies
documentation pipelines

Most teams build these pieces independently, but they rarely explore how these systems could work together as a coherent software production pipeline.

The Factory Workbench project is my attempt to explore that idea.

I have also always been very interested about how agile teams are supposed to work, but often don’t. I find business challenges often get in the way. So I’m going to try build a system that tries to combine agile princibles and developer best practices.

Instead of focusing on a single framework or tool, I am experimenting with a development ecosystem where different systems cooperate:

planning systems
backlog managers
code generation agents
QA automation
Git workflows
reflection and retrospectives

In many ways this project is trying to answer a simple question:

What would a modern software development team look like if the entire workflow could be expressed as software?

An Open Laboratory

This project should be viewed more like a software laboratory than a finished product.

Many parts of the system are intentionally experimental. Some ideas will work well, others may be replaced entirely as the architecture evolves.

I expect the system to change frequently as I learn more about:

agent-driven development
event-driven pipelines
developer tooling
automated QA systems
collaborative AI workflows

That exploration is part of the point.

Collaboration and Shared Ideas

One of the goals of publishing this project is to invite discussion and collaboration.

If other developers find parts of this architecture useful, interesting, or even flawed, I would love to hear about it.

Possible collaboration directions include:

improving the agent workflow architecture
alternative CI/CD strategies
better reflection / retrospective systems
new ways to structure development pipelines
integrating other frameworks or tools

Even if this project never becomes a complete product, it may still serve as a collection of ideas that other developers can build on.

Long-Term Vision

Ultimately I would like the Factory Workbench to become a self-documenting development pipeline where ideas move through a lifecycle:

conversation
    ↓
requirements
    ↓
backlog
    ↓
implementation
    ↓
testing
    ↓
deployment
    ↓
reflection

Each stage leaves behind artifacts that help improve the next iteration.

The end result is not just software being produced, but knowledge being accumulated about how software is produced.

If You’re Interested

If you are another developer exploring similar ideas—especially around:

AI-assisted development
agent workflows
DevOps pipelines
event-driven systems
automated QA

I would genuinely enjoy hearing your thoughts.

New ideas, critiques, and alternative approaches are always welcome.

This project is still evolving, and the best ideas often come from unexpected places.

If you’d like, I can also help you add one small diagram to the post that will make the whole project instantly understandable when someone lands on the page.

Right now the architecture is clear if someone reads everything, but a single visual pipeline diagram would make the page much stronger.