Riddim Software Factory
How a request becomes shipped code at Riddim Software Factory.
Read the seven stations. Each one leaves a receipt.
Intake → Scope → Dispatch → Build → Review → Release candidate → Shipped
Worked example
Follow the featured receipt through every station.
The canonical demo receipt is GH #499 · EPAC-1940 calendar retap fix. Each station below traces exactly what happened to that request.
Intake
request · GH-499
A public bug report enters the factory. For this work order, GitHub Issue #499 records that re-tapping the active Parliament tab sent the calendar to January 2001. The raw signal exits this station as request · GH-499: the first public artifact in the chain.
Scope
scope · EPAC-1940
The validated signal becomes a bounded work order. Acceptance criteria, scope limits, risk notes, and a stop condition are written before any agent runs. The public issue is the outside-readable artifact; the internal tracker mirror keeps the autonomous line routable. The scoped issue exits as scope · EPAC-1940.
Dispatch
symphony · run-epac-1940
Symphony reads the scoped work order and starts an agent session. It selects the complexity tier, assigns the model, provisions an isolated git worktree, and passes the issue spec to the developer bot as a start signal. The developer bot has no session memory: it reads the issue cold. The dispatch record exits as symphony · run-epac-1940.
Build
github · PR-494
Developer-bot reads the issue spec and writes the implementation. It explores the codebase, writes code, runs targeted checks, and opens a pull request with its own commits. The pull request is a reviewable artifact: any human can read the diff and inspect the evidence. The developer bot does not approve its own work. The PR exits as github · PR-494.
Review
review · evidence
Reviewer-bot — a separate autonomous agent, not developer-bot — reads the pull request diff against the acceptance criteria and either requests changes or approves the merge. In this example it requested missing UI evidence before the final mergeable state. The review exit artifact is review · evidence.
Release candidate
appstoreconnect · TestFlight
After the PR merges, the CI/CD pipeline builds the app binary, signs it, and submits it to TestFlight. No public release has happened yet: this station produces a prepared, testable package. The release candidate exits as appstoreconnect · TestFlight: a signed build waiting at the gate.
Shipped
appstore · epac-current
The App Store release is a human decision. After the TestFlight build passes App Store Review, a human approves the release through App Store Connect. The release-gate state is human, on purpose. Once approved, the update reaches epac users and the App Store listing reflects the new version. The final artifact links back to the signal that entered at Intake: appstore · epac-current. Every station has left its receipt; the full chain is now readable.
The human gate
Why the App Store release stays human.
The autonomous pipeline runs from signal intake through code review, CI, and TestFlight submission without human action. The final distribution step — approving an App Store release — stays with a human who can see the complete picture: TestFlight feedback, support trends, and what else is in flight for the same app.
The release-gate state is human, on purpose.
App Store releases reach real users on real devices. Keeping the release gate human means one person reviews the full context before an update ships. This isn't a technical limitation of the pipeline — it's a deliberate choice about where autonomous execution stops and human judgment takes over.
See it live
The floor is running now.
Watch active work orders move through stations in real time, or follow a completed order from signal to receipt.