> ## Documentation Index
> Fetch the complete documentation index at: https://docs.claboard.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Pipeline & Auto-Queue

> DAG-aware auto-queue with crash recovery, periodic polling, and smart scheduling

The pipeline system manages task execution with dependency tracking, automatic retries, crash recovery, and continuous queue monitoring. Enable auto-queue per project and Claude Board handles the rest.

## How It Works

<Steps>
  <Step title="Enable auto-queue">
    Open project settings and toggle **Auto-Queue** on. Set the **max concurrent agents** (1-5).
  </Step>

  <Step title="Add tasks to backlog">
    Create tasks as usual. Each new backlog task is automatically considered for execution.
  </Step>

  <Step title="Continuous execution">
    The queue continuously monitors for free slots every 15 seconds and starts ready tasks. When a task completes, dependent children start immediately.
  </Step>
</Steps>

## Crash Recovery

If the application crashes or closes while tasks are running:

1. **On restart**, all orphaned `in_progress` tasks are automatically reset to `backlog`
2. Tasks in `testing` state (auto-test was running) are automatically re-tested if auto-test is enabled
3. The auto-queue immediately re-evaluates and starts ready tasks
4. No manual intervention required

<Info>The recovery system checks actual process state, not just database status. This prevents zombie tasks from blocking queue slots.</Info>

## Smart Scheduling

The queue uses **real process state** for slot counting — not just database status. This means:

* Zombie tasks (crashed processes) don't block slots
* Slot calculation: `available = max_concurrent - actually_running_processes`
* Tasks with `awaiting_subtasks` flag don't count as occupying a slot once their Claude process exits

## DAG-Aware Execution

When tasks have [dependencies](/features/dependencies), the queue respects the full dependency graph including conditional workflows:

* **Always/On Success** — Parent must reach `done` or `testing`
* **On Failure** — Parent must have permanently failed (retries exhausted)
* Wave-based parallel execution within concurrency limits

## Retry Logic

Configure `max_retries` per project. When a task fails:

1. If retries remain: task returns to backlog with incremented retry count
2. If retries exhausted: task is marked as permanently failed
3. **On Failure** dependent tasks are then unblocked and can start

## Sub-task Awareness

When a parent task has spawned sub-tasks:

1. Parent's Claude process finishes but task stays in `in_progress` (awaiting)
2. Sub-tasks are queued and executed normally
3. When all sub-tasks complete, parent automatically moves to `testing`/`done`
4. Auto-test and dependent cascade proceed normally

## Priority Ordering

Tasks are picked from the backlog in this order:

1. **Priority** — High (3) -> Medium (2) -> Low (1) -> None (0)
2. **Queue position** — Manual drag-and-drop ordering
3. **Creation time** — Older tasks first (FIFO)

## Smart Queue Priority

Beyond the basic priority ordering above, the queue also considers **critical path** when selecting the next task:

* Tasks that block the most dependents are prioritized
* This ensures that bottleneck tasks run first, maximizing parallelism in later waves
* Critical path priority is applied as a tiebreaker within the same priority level

## Circuit Breaker

The queue supports an automatic pause mechanism when too many tasks fail consecutively. See [Circuit Breaker](/features/circuit-breaker) for configuration and details.

<Warning>Dependencies override queue position. Even if a task has position #1, it won't start until all parent dependencies are met.</Warning>