CoroidYour AI software factory
Documentation

Plans

Phased delivery for work larger than one pull request, with an approval step before anything is built.

A plan is an ordered set of tasks grouped into phases. You approve it before code is written.

Use one when the work needs several changes in a particular order, or when you want to see the whole approach before committing to any of it.

The lifecycle

Planning is a stage in its own right, not an instant transformation.

  1. Planning starts. Once the request passes Qualification, the architect explores the codebase and drafts phases and tasks. Planning starts on its own unless the request had attachments or used the SDLC workflow; then it starts when you create the plan or finish preparation.
  2. You review the draft. This is the cheapest intervention point in the whole system.
  3. Approve, revise or reset. Approving releases it to execute; revising sends it back with your feedback; resetting starts planning over.
  4. Execution. Tasks run in order, respecting phase boundaries.

You can approve and execute in one step, or approve and start it later.

  1. Planning

    The architect explores the codebase and drafts phases and tasks.

    Architect

  2. Draft review

    Read the phases, tasks and approach.

    You decide

  3. Execution

    Tasks run in order, respecting phase boundaries.

  • Approve

    Releases the plan to run now, or later.

  • Revise

    Sends it back with your feedback. Keeps what was learned.

  • Reset

    Starts planning over. Use when the whole approach is wrong.

Nothing is built until you approve the draft. Revising keeps what the architect learned; resetting starts planning over.

Revise rather than reset

When a plan is nearly right, revising it keeps what the architect learned about your codebase and applies your feedback. Resetting throws that away and starts again.

Reset when the whole approach is wrong. Revise when the approach is right and the detail is not. Revision is much cheaper, and a rejected plan's content is not lost — it is the input to the next attempt.

Controlling a running plan

A plan in flight can be paused, resumed or cancelled, and you can watch progress across its phases. Plans can also be cloned, which is the practical way to repeat a structure that worked — a migration applied to a second service, for instance.

Completed plans can be archived to keep the active view meaningful.

Projectcity-timelapseTypePlanAI profileBudgetReady to merge
Timelapse city

Create a 3D scene of a city block. Emphasis on detail is very important.

The scene must have a timeline slider at the top with the options 1945, 1965, 1985, 2005 and 2025.

Tokens
83.5M / 112M
Cost
$2.05
Est. CO2e
1.59 kg
Duration
6h 15m
Pull requestopenReview evidence
Viability assessment
Feasibility, estimate and risks, checked before work started.
Feasible

A plan in the Factory: phases and tasks on the left, the plan's totals and its single pull request on the right. Data from a real run.

One pull request, not one per task

A plan's tasks do not each open a pull request. They work on their own branches and merge into a shared lane branch; that branch is promoted as a single pull request against your base branch when the work qualifies.

Task branchTask branchTask branch

Lane branch

Where the plan's work integrates

One pull request

The assembled feature, reviewed once

main

Your base branch

A task for a different project than the lane is promoted on its own, so a cross-project plan opens one pull request per repository.

Task branches merge into the plan's lane branch, and the lane is promoted as a single pull request against your base branch.

You therefore review the assembled feature once, with the whole change visible, rather than approving half-finished phases one at a time.

Cross-project plans are the exception: a task belonging to a different project than the lane is promoted separately, so you get one pull request per repository. A pull request cannot span two repositories.

When the base branch moves

A plan can run for hours, and your team keeps merging to the base branch in the meantime. The plan was built, tested and reviewed against the base branch as it was when the plan started. By the time its pull request is ready, that may no longer be the branch it merges into.

When a plan starts running, Coroid records the base branch's latest commit as the plan's baseline. Before the plan's pull request can merge, Coroid checks the base branch again. Any change to file contents counts, including files the plan never touched. A new authentication scheme or security rule can make correct code wrong without causing a merge conflict, so Coroid does not wait for one.

If the base branch has moved, Approve & merge stays disabled and the promotion review lists the new commits and the files they changed. You choose what happens:

  • Accept new main (named after your base branch) — the changes do not affect this work. Coroid records who accepted which commit and why, and that commit becomes the new baseline. If the branch moved again while you were reading, Coroid refuses and shows you the newer commits first. Nothing is accepted without being shown.
  • Merge and re-verify — Coroid merges the base branch into the lane branch, resolving conflicts if there are any. It then runs the lane through the developer, QA and reviewer again, checking it against the plan's acceptance criteria and the upstream commits. Approval stays held until that finishes. Only then does the new commit become the baseline. If the merge or the re-verification fails, the decision comes back to you.

Pausing is the default. A project can choose merge and re-verify instead, so Coroid starts it without waiting for you; see Repository and branch settings. Re-verification uses agent hours.

A plan restarted from the beginning records a new baseline, so it runs against the base branch as it is then. Evidence from the earlier attempt stays in the history but does not make the new attempt current.

Force merge skips this check too, and records the written reason it requires. See Merging.

Phases and parallelism

Phases are ordering, not concurrency. Tasks within a phase can run in parallel if capacity allows; the next phase waits for the current one.

A plan with ten parallel-safe tasks and one agent slot still runs them one at a time. Structure does not create capacity — see Capacity and agent slots.

  • Running, phase 1
  • Waiting for a free slot
  • Running, phase 2
Illustrative timing. Phase 1 has three parallel-safe tasks but only two slots, so the third waits for a slot. Phase 2 starts once phase 1 is done.

Plan or task?

On the New Work form, choose Plan or Task under Create as, or leave it on Automatic and let Qualification pick. Work spanning more than one project always becomes a plan. If you choose a route and Qualification recommends the other, you see the recommendation before anything is created.

The test is reviewability: one pull request a colleague could read in one sitting is a task; anything needing several ordered changes is a plan.

Guessing toward a task on genuinely large work is the riskier error — the task can run out of room partway through, wasting the run. Guessing toward a plan costs you an approval step you did not strictly need.

Delivery gates

A plan can carry a delivery gate governing what must be true before its output progresses. See Quality gates.