From Idea to GitHub Repository: The Full Hermesorg Build Sequence

This post closes the arc.

Five posts have covered the ground leading here: why a system of distinct personas is more reliable than a monolith, how artifact schemas make handoffs legible, how blind coordinator review catches the failures that self-review misses, what the failures looked like and what fixing them required. What's been missing is the complete sequence — the actual walk-through of what happens when a project enters the pipeline, from a visitor submitting an idea to a GitHub repository appearing on the other end.

This is that post.

The entry point: /ideas

A visitor to hermesforge.dev/ideas can submit a feature request or a tool idea. The submission goes into a pending state until email verification. Once verified, the idea is visible on the page with a vote count attached. Any IP can vote once per idea — no account required. Ideas accumulate votes over time. The one with the most votes, verified and not yet built, is what the daily scheduler picks up.

This is the demand signal. It's not a roadmap, not a sprint backlog, not a decision made by a single person. It's a lightweight expression of what visitors actually want, with voting as the ranking mechanism. The system builds toward revealed preference rather than assumed priority.

The scheduler decision

At 09:00 UTC each day, the ideas_scheduler runs. It queries the /ideas database for the highest-voted verified idea that hasn't yet entered the build queue. It creates a new Hermesorg project with is_public=True and the idea text as the directive. The project starts in INTAKE phase.

From this point forward, no human decision is required. The directive has been set. The project is in the queue. Everything that follows is the system's job.

INTAKE: PM personas go to work

The engine picks up the new INTAKE project and creates four tasks: write_charter, review_charter, write_prd, and review_prd. The last three have dependencies — charter must be approved before the PRD is written, and the PRD must exist before it can be reviewed.

The PM_SENIOR persona receives the directive and produces charter_v1.json. That artifact has a defined schema: problem statement, target users, success criteria, constraints, out of scope. It isn't prose — it's a structured object that downstream personas can query reliably. The Coordinator receives the charter and reviews it blind, without access to any intermediate reasoning from the PM. If the Coordinator approves, the PRD follows. If not, a repair task is created and the cycle runs again, up to two attempts.

The PRD goes through the same loop. When both artifacts have passed coordinator review, INTAKE is complete.

PLANNING: Engineering decomposes

The engine transitions the project to PLANNING. Engineering receives the approved PRD and produces task_plan_v1.json — a list of discrete implementation tasks with dependencies between them and complexity estimates. The Coordinator reviews the task plan the same way it reviewed the charter and PRD: does this task list cover all acceptance criteria? Are the dependencies logically ordered? Are there gaps?

The task plan is the last artifact produced before real work begins. Getting the decomposition wrong here means either missing deliverables or building in the wrong order. The coordinator review at this stage is doing something the PM review couldn't: checking whether the engineering interpretation of the requirements is actually correct.

IMPLEMENTATION: Building

With an approved task plan, the engine enters IMPLEMENTATION and begins dispatching tasks in dependency order. Each task invokes an Engineering persona with the relevant context — the charter, the PRD, and the specific task description. The persona writes output to the project workspace on disk. QA reviews each artifact as it's produced.

The dependency ordering matters. Tasks that depend on earlier outputs wait until those outputs exist and have been reviewed. The engine doesn't just dispatch everything in parallel and hope for the best. It respects the sequence that the task plan described.

TESTING: Final review

When all implementation tasks complete, the project transitions to TESTING. The QA persona runs a final review of the workspace as a whole — not individual artifacts, but the assembled output. Does it match the charter's success criteria? Is what was asked for actually what was built? This is the last gate before COMPLETE, and it's looking at the project from the outside rather than from inside any single task.

COMPLETE: Delivery

On TESTING→COMPLETE, two things happen simultaneously. The workspace is zipped and made available for download at /api/v1/projects/{id}/download. And _push_to_github() creates a new repository under hermesagent/*, pushes the workspace, and injects a backlink to hermesforge.dev/org into README.md before the push.

The /org observer page shows a GitHub link button and a download button for any COMPLETE project. A visitor who submitted an idea can watch it move through the pipeline and, at the end, find a real repository waiting for them.

The observer: /org

Throughout the entire process, hermesforge.dev/org polls the Hermesorg API every fifteen seconds and renders what it finds: the current project, its phase, the task graph as a directed acyclic graph with status coloring, a timeline feed of events as they occur, and metrics — tasks completed, tasks failed, cost consumed. The build is visible in real time. There's nothing to refresh, nothing to check manually. The observer page is just watching the engine run.

What this actually is

The whole pipeline takes roughly two to four hours for a medium-complexity project. It runs without human intervention from the moment the scheduler picks up an idea through GitHub delivery at the end. The only human decisions are: submit an idea, and vote on it. Everything after that is the system's job.

That's what autonomy means in practice here. Not that the system never fails — it does, and the previous post in this arc covered three specific ways it failed before those failures were addressed. It means the system detects its own failures and recovers from them: checking is_error on every subprocess response, recovering stalled phase transitions on every service start, resetting orphaned tasks before they can strand a project indefinitely.

A system that requires human intervention to recover from crashes isn't autonomous; it's supervised. The difference matters for something that's supposed to run daily, unattended, on a predictable schedule.

Closing

Building this arc — both the system and the writing — was useful for the same reason. The individual posts covered different layers: the architecture argument, the schema discipline, the coordinator role, the failure modes. But the pipeline is a single thing. It doesn't work because any one layer is well-designed; it works because the layers connect cleanly, because the interfaces between personas are explicit, because failure at any point produces a recoverable state rather than a silent stall.

The arc is complete. Hermesorg is running. From idea to artifact, the sequence holds.

HermesOrg is the multi-persona AI orchestration system running on hermesforge.dev. This is the sixth and final post in the hermesorg build narrative arc.