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

# How Flowfield Tasks, Milestones, and Dependencies Work

> Understand how Flowfield tasks express agreed outcomes, how milestones group related work, and how task dependencies control execution order.

Tasks are the core unit of work in Flowfield. Each task expresses an agreed outcome with explicit success criteria — not just a to-do item, but a shared contract between you and the coordinator about what done means. Every task has a stable key, a feed that records its entire history, and optionally a set of predecessor tasks that must complete before it can run.

## Tasks

A task is defined by a few key properties that stay stable across the browser, CLI, and MCP.

**Stable keys** — When you initialize a project, you choose a short prefix such as `APP`. Flowfield assigns sequential keys from that prefix: `APP-1`, `APP-2`, and so on. The prefix locks after the first task is created. Use these keys everywhere — in the browser, in CLI commands, and when asking your coordinator about specific work.

```sh theme={null}
flowfield task show APP-1
flowfield task activity APP-1
flowfield task relationships APP-1
```

**Intent** — Each task has a description and success criteria, captured and maintained by your coordinator through MCP. The coordinator shapes this definition through your conversation; you confirm it before the task enters the queue. Clear, specific success criteria help workers produce results you're happy to approve.

**Task feeds** — The feed is the single authoritative timeline for everything that happens on a task. Every definition, revision, worker attempt, question, answer, testing observation, and result appears in the feed in order. There's no separate log to check — the feed tells the full story.

**Dependencies** — A task can depend on other tasks in the same project. If a prerequisite task isn't done yet, the dependent task stays blocked and won't start even if the queue is running. This lets you describe real sequencing constraints — for example, a task that needs a database schema migration to complete before application logic can be implemented.

## Milestones

Milestones let you group related tasks into a named collection — useful for organizing a sprint, a feature, or a release. A milestone gives you a way to see the overall progress of a set of related tasks at a glance.

However, milestones do **not** create dependencies. If you need task B to wait for task A, add an explicit dependency from B to A. Putting both tasks in the same milestone has no effect on execution order. Dependencies connect tasks directly — milestone membership is purely organizational.

## The Task Feed

The feed is a unified timeline of everything that has happened on a task. Unlike a simple comment thread, the feed weaves together structured entries from every participant — the coordinator, the worker, and you.

Entries you'll see in a task feed include:

* **Intent and revisions** — the task definition as it was captured, plus any updates the coordinator makes over time
* **Worker attempts** — each time a worker starts and the stages it moves through
* **Questions** — when a worker needs clarification before continuing
* **Answers** — your responses that let work resume
* **Testing observations** — notes you record while trying a result
* **Results** — the worker's submitted outcome, checks output, and any limitations

Two rules govern how feed entries interact with work:

1. **Answering a question continues work.** When you answer a question in the feed (or via Needs You), the service treats that as input and the worker can proceed.
2. **Recording a test observation does NOT approve code.** You can write detailed testing notes in the feed and no approval is granted. Approval requires an explicit Approve and Integrate action.

Earlier results remain inspectable in the feed even after a new worker attempt has produced a newer result.

<Info>
  The coordinator prepares and maintains task definitions through MCP. You control priorities and review — ask the coordinator to update task intent if the agreed outcome changes, rather than editing the definition directly.
</Info>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.