Possibilities Matrix

Sometimes a task is already done by the time a developer agent picks it up — the commits exist, the PR is open, every acceptance criterion is covered, and there's nothing outstanding to fix. Without this capability, the agent still walks the full multi-turn plan-and-verify sequence to arrive at exactly the same conclusion. The possibilities matrix is a fast path: when the work genuinely is already done, i_am_done can submit straight to QA in one call instead of re-deriving what's already obvious.

It's off by default.

What it does

  • The preconditions, all four required. The task already has commits, an open PR, every acceptance criterion marked addressed, and no open review findings against it. Miss any one of those and the fast path doesn't apply — the agent runs the normal flow.
  • One call instead of several. When it applies, the developer's single i_am_done call carries the task from claimed/in-progress straight through self-verification and into awaiting_qa, instead of the usual plan → verify → submit sequence.
  • CI-green stands in for the local gate. If the PR already has a green CI run, that check is trusted as the quality signal — there's no reason to re-run the same suite locally. A red CI check refuses the fast path outright rather than shipping known-failing work to QA.
  • No CI configured falls back to the real gate. If the PR carries no CI signal at all, the fast path doesn't guess — it runs the standard local quality gate (and the toolchain-matching interpreter check, if that's armed) before submitting.
  • The strict gates are never skipped. Architectural-conventions block-level findings and the requirement that every open review finding be resolved both still run in full, every time — the fast path only ever shortens redundant work, never a real check.
What it saves

This isn't about letting agents skip quality bars — every gate that would normally stop a bad submission still runs. It only removes the re-derivation of a conclusion the task's own state already proves: don't ask an agent to prove its work is done three different ways when the commits, the PR, and the acceptance criteria already say so.

How it works in v0.25.0

The fast path is armed by the ROBOCO_POSSIBILITIES_MATRIX_ENABLED toggle (or the matching panel feature flag). When it is on, i_am_done checks whether the task's state already proves the work is done and, if so, moves it straight to the WORK_ALREADY_DONE orchestrator state and submits to QA in one call.

Eligible statuses

Only two task statuses are eligible for the fast path:

  • claimed
  • in_progress

If the task is in any other status — verifying included, which routes through its own resume path — the fast path does not apply and the normal i_am_done flow runs.

The four preconditions

All four must be true. Missing one falls back to the standard flow.

  1. Commits exist. The task branch has at least one commit linked to it.
  2. A PR is open. There is an open pull request for the task branch.
  3. Every acceptance criterion is addressed. Each criterion has a referencing artifact (commit, file change, progress entry, or note) showing it is satisfied.
  4. No open findings. There are no unresolved QA, PR-review, or PM-review findings against the task or its PR.

Ownership assertion

The orchestrator asserts that the agent calling i_am_done owns the task and the work on the branch. If the task has been reassigned since the commits or PR were created, the ownership assertion fails and the task is forced through the normal flow. This prevents a new assignee from fast-pathing over work they did not produce.

Architectural-conventions gate is kept

The fast path never skips the architectural-conventions block-level gate. If the diff contains a misplaced definition, a thin route/component, a god class, or any other block-level convention violation, i_am_done refuses the fast path and the agent must fix it through the normal flow.

CI verdict behavior

The PR's CI status decides how the quality gate is satisfied:

  • CI green — the CI run is trusted as the quality signal and the local gate is not re-run.
  • CI failing — the fast path is refused outright; the agent must fix the failure through the normal flow.
  • No CI / unknown — the orchestrator falls back to running the local quality gate (and the toolchain-matching interpreter check, if armed) before submitting.

Orchestrator state

When the fast path succeeds, the orchestrator records the task in the WORK_ALREADY_DONE state before transitioning it to awaiting_qa. That state is the explicit signal that the task closed without redundant re-verification because its own commits, PR, and acceptance criteria already proved it was done.

Enable it

Settings → Feature Flags → "Possibilities matrix" arms it.

Takes effect on the next backend restart

The feature flag persists in the settings store and applies on the next backend restart.

See the environment reference for the full flag list.

What changes when it's on

  • With the flag off, every task follows the standard i_am_done flow regardless of how complete it already looks.
  • With the flag on, a task that already has commits, an open PR, full acceptance-criteria coverage, and no open findings can close in one call — with CI standing in for the local gate when the PR has a green run, and the local gate still running when it doesn't.
  • Conventions and findings enforcement are identical either way; nothing about what counts as "done" gets looser.

Next

→ PR Review — the in-path gate that still checks the assembled PR regardless of how a leaf task closed. → Task Lifecycle — the standard flow this fast path shortcuts. → back to Optional subsystems.

llms.txt