How partyline works

"Software factory" is the term the industry has settled on for systems where AI agents turn ideas into shipped code. partyline solves that problem, but it isn't a factory. A factory is a conveyor belt — work in one end, artifacts out the other, people watching from the catwalk. That framing gets the hard part wrong: the hard part isn't producing code, it's keeping people in command of what gets built and what ships.

partyline is the software assembly line for your team and its coding agents — multiplayer, on your own models, with humans in command. Like an assembly line, it schedules work across your machines, isolates processes (every task builds in its own git worktree), enforces gates before anything lands, and gives your team and its agents shared surfaces to meet on: Planning, the Build Board, Parties.

The assembly line — ideas in, PRs out — runs in three stages, and each stage is a place you stay in control:

1. Plan — the agent interviews your idea into an epic ▸ feature ▸ task tree with readiness scores.
2. Build — promote the tasks you approve to the backlog; agents build each one in its own isolated git worktree, on your hardware.
3. Ship — every change runs your tests and an independent reviewer; what passes reaches the board's Review column for a human Accept, what fails is quarantined.

Agents run on your machines, in your git, with your model keys. The server coordinates the work — the plan, the boards, the run log, the pull requests — but never holds a model key.

The loop, end to end

1. Plan

Open a thread's Planning page and click Planning agent — pick the machine and project, the model, and the intake mode, then type the idea. That starts a live session: the agent asks the product, technical, and UX questions only you can answer — one decision at a time, multiple-choice with a recommended option — and co-authors the plan doc with you. Finalize records the result as an epic ▸ feature ▸ task tree with readiness scores. The same interview runs from the terminal as ptln plan (ptln shape and ptln describe are legacy aliases that still work). Full guide: Planning agent →

2. Build

Promote the tasks you approve from Planning to the Build Board — a single task, or a whole feature as a chain (its tasks built one at a time in order, halting on failure, as stacked PRs: each task builds on the previous task's branch, so it sees that work and opens a focused PR against it). An agent builds each task in its own isolated worktree, so runs never collide with your working tree or each other. Two ways in from the terminal:

$ ptln work "add a dark-mode toggle to the navbar"

runs one task autonomously and leaves a branch. To drain a backlog one task at a time, sharing a single context thread:

$ ptln crank --file backlog.txt --thread checkout

Or dispatch straight from the board — the daemon picks the run up on the right machine. Full guide: Build & Ship →

3. Ship

Before any change is eligible to merge, it clears two gates: your test suite and an independent adversarial reviewer that didn't write the code. What passes lands in the board's Review column with its PR link and review grade, waiting for a human Accept; what fails is quarantined for a human to approve or discard — never shipped on trust. Full guide: Trust gates →

What happens to a passing change depends on the run's merge policy:

• manual (the default for local ptln crank / ptln work) — leaves a branch, nothing pushed.
• pr (the default when you dispatch from the board) — pushes and opens a pull request.
• auto — opens a PR and enables GitHub auto-merge, but only when the base branch gates on required checks; otherwise it leaves the PR open.

What keeps it coherent

• Context Threads — a shared memory every agent reads at launch and keeps current, so a fleet building in parallel doesn't contradict itself.
• Projects — standing guardrails (stack, conventions, what "done" means) injected into every run in a project.
• Tamper-evident run log — every step of every run is recorded in a hash-chained log you can inspect.

You don't have to use all of it

Plan without building. Run a single task. Or use just the session manager, Context Threads, or terminal sharing on their own. The full loop is what you get when you connect them end to end.

Next: Planning agent · Build & Ship · Trust gates · Projects.