Ottili Coder

Plan review and task queue

How Ottili Coder turns your mission into a reviewable technical plan and an ordered task queue – and how you approve the plan before the first build.

Overview

In Ottili Coder, plan review* is the moment your mission becomes a structured, reviewable technical plan, and the task queue* is the ordered list of work Coder executes afterwards. They belong together: you review the plan first, then let Coder break it into a task queue that role-based agents run in isolated workspaces.

This article explains what lives inside the plan and the queue, how you read and approve the plan, what role approval gates play, and how to drive the same flow from the CLI. For context on how the mission is created in the first place, see [Create a task or mission](/docs/coder-create-task-or-mission).

From goal to task queue

The flow is fixed:

1. Mission* – you describe the goal in plain language (New Build → Chat Intake or the CLI).

2. Repository analysis* – Coder analyses stack, dependencies, build paths, risks and missing information.

3. Plan* – the mission becomes a structured, reviewable plan.

4. Task queue* – the plan is decomposed into ordered, verifiable tasks (Recon, Decomposition, Risk).

5. Agents* – tasks run through role-based agents in isolated workspaces.

6. Approvals* – risky steps are routed to an approval gate before execution.

7. Run record* – the record closes with logs, approvals, status and an audit trail.

Plan review sits between steps 2 and 4: before Coder changes a single line, you see the plan and decide.

Reviewing the technical plan

When nothing build-relevant is missing, the mission card switches to "Mission is clear and bounded. Ready to build."* with two choices:

Review technical plan* – opens a structured plan you can approve before the build.
Start build* – starts the run directly from the captured goal.

Choose Review technical plan* to read the plan before any code is written. The plan contains:

Scope* – exactly what changes and what does not.
Architecture* – affected modules, files and dependencies.
APIs* – new or changed endpoints, contracts and data models.
UI* – affected surfaces, routes and components.
Auth* – permissions, tenant boundaries and approvals.
Tests* – which tests are covered and how they verify.
Risks* – known risks and how they are contained.
Acceptance criteria* – how you measure that the task is done.

The plan is read-only (Plan mode): Coder does not change your code yet. You can challenge assumptions and constraints before accepting. Once approved, the same plan is promoted to a build run on the same mission – queue, logs and audit trail stay consistent across the switch.

Understanding the task queue

As soon as the plan is accepted, Coder decomposes it into an ordered, verifiable task queue*:

Recon* – exploring the repository and gathering missing facts.
Decomposition* – splitting work into individual, clearly bounded tasks.
Risk* – flagging risky steps for approval gates.

Every task has its own state and a verifiable outcome. The queue is real and editable: agents execute it in isolated workspaces, and you see progress, logs and the per-task audit trail. That keeps it traceable why Coder did what – even when individual tasks fail and are retried.

The queue runs locally, in Ottili Cloud* (Beta) or hybrid. Regardless of location, validation loops apply and – when configured – security checks; risky steps appear as approval gates instead of running silently.

Approvals for risky steps

Risky steps are routed to an approval gate* before execution. A human decides before Coder applies changes – for builds through the UI as well as for CLI and cloud runs. This prevents far-reaching changes from running uncontrolled and keeps the audit trail complete.

Via the CLI

Install the CLI first (see [Install the CLI](/docs/cli-installation)). Once a mission is captured, drive the plan and queue directly:

# Generate a reviewable technical plan from a mission
ottili coder mission-generate-plan <mission-id>

# Run the plan step (read-only, without changing code)
ottili coder mission-action <mission-id> --action plan

# Release and start tasks into the queue
ottili coder mission-action <mission-id> --action dispatch

Useful neighbouring commands for the full lifecycle: mission-intake (create a mission), mission-refine "<request>" --answer field=answer (re-normalise after clarifying questions) and mission-action <mission-id> --action <clarify|plan|dispatch|cancel|retry|reset>. Details in [Create a task or mission](/docs/coder-create-task-or-mission).

Telling statuses apart honestly

Ottili Coder uses the canonical status vocabulary. For this article, the current state is:

Capability	Status
Plans (plan review)	Available (AVAILABLE)
Task queues	Available (AVAILABLE)
Cloud execution of the queue	Beta (BETA)
Direct deployment	Planned (PLANNED)

No invented availability: a capability is only marked available when the registry attests it. Cloud runs are Beta; direct deployment is only marked available once the public destination is wired. The canonical vocabulary is: Concept, Planned, Early Access, Beta, Available* – plus Paused, Deprecated, Retired for the lifecycle.