# Tasks

Tasks are the work the project has chosen to do. Audit may hold hundreds of findings; Tasks stays deliberately small so the queue reflects real priorities.

One task owns one issue family. Template-level crawl problems are grouped across every affected page. Page-level opportunities — click-through gaps, striking distance, content decay, and the landing-page and search-query families — are batched: one task carries up to ten pages of the same kind of work, so a site where fifty-five pages under-perform on click-through gets a single **Improve click-through on 10 pages**, not fifty-five near-identical rows. Its summary names the pages carrying the most of it, and its explanation totals the missed or lost visits across the whole batch.

The pages beyond the batch are not lost: they stay open findings on [Audit](/documentation/projects/audit), counted everywhere, and roll into a fresh batch task as soon as the current one is resolved or skipped. While a batch has room, a newly detected page joins it instead of creating a duplicate.

Every task has a project-wide number such as `#42`. Use it in chat, reports, and commits.

## Lanes

The list is four lanes, sorted by who moves each task next:

- **Your move** — waiting on you: a plan awaiting approval, work only you can do, or a task you own.
- **Engine is on it** — the engine is carrying it. Each row shows how far along it is on the planning → executing → verifying → measuring rail.
- **Open** — filed and ranked, but nothing has started.
- **Closed** — resolved with evidence, or deliberately skipped.

The lane rail carries live counts for the whole backlog, so switching lanes never hides how much is waiting elsewhere. Lanes are addressable: `?lane=your-move`, `?lane=engine`, `?lane=open`, `?lane=closed`. Older `?status=` links still land in the matching lane.

### Focus and Later

**Your move** opens as a **Focus** list of five rows, not a backlog. A plan waiting on your approval is never hidden — the engine is blocked until you answer it — so approvals come first however many there are; the remaining slots go to the highest-priority work, oldest first inside a priority. Everything else folds under **Later · 50**, one line you can click to expand. Selecting rows for a bulk action works across both.

Change how many rows Focus holds in project **Settings → Focus size** (1–20, five by default): *how many tasks Your move shows before the rest fold under Later*.

## Filtering and sorting

One toolbar narrows the lane in place: search on the left (it matches titles and task numbers, so typing `#42` jumps straight there), then the department menu, the **All / Issues / Opportunities** switch, and the sort control. Sorting offers **Priority**, **Oldest first**, and **Most at stake** — the last ranks by each task's measurement baseline, so the tasks with the most traffic riding on them come first. Filters survive a lane change; **Clear filters** restores the lane.

## Rows

Each row reads like an issue tracker: the task number, its priority band, and the title with its **Issue** or **Opportunity** label and department beside it, then one line saying what the work is costing today in plain words. On the right edge sit how many pages and searches it touches, how long since it last moved, and who holds it — your initial, or a spark for the engine.

The priority band is one of three: **P1** for work worth doing first, **P2** for work worth doing soon, and **P3** for when there is room. The exact 0–100 rank is still what the **Priority** sort orders by, and it is still what you set with the Priority verb.

## Acting on tasks

Every lane offers its own verbs on each row, and the same verbs work on a multi-selection:

- **Approve plan** — only shown while a task is waiting on your decision about a plan. It is the one verb that authorises a change to the site or a spend, and it runs the plan exactly as frozen. A task handed to you to do by hand has nothing to approve; it offers **Mark done** and **Skip** instead.
- **Skip** — set the work aside with an optional reason. It stays on record; if the evidence behind it changes, the engine brings it back.
- **Done** — record that you did the work yourself. The task moves to **verifying** and the engine checks the site for itself; your note goes in the thread. It is refused while the evidence behind the task is still open, unless you deliberately override it.
- **Start** / **Reassign to me** — hand the task to the engine or take it back. Handing it to the engine queues triage and is subject to the project's [autonomy policy](/documentation/projects/autonomy).
- **Priority** — set the 0–100 rank the lane sorts by.
- **Reopen** — bring a closed task back into **Open**.

Select rows with their checkboxes to apply Approve, Skip, Reopen, or Assign to all of them at once. Each task is reported separately, so one refusal never loses the rest of the gesture, and the reason for a refusal is shown.

Every one of these writes the same task event the engine would write for the same transition, so the thread reads identically whichever moved it.

## Manual tasks

**New task** files work of your own: a title, a department, optional pages and searches, and your notes. It arrives owned by you in **Your move**. Where an analysis model is configured, your words are drafted into the task's summary, its plain-language explanation, and an opening brief in the thread; otherwise your text is used exactly as written. Nothing is invented — a manual task carries no traffic numbers it was not given.

## What each task is measuring

A task created from evidence carries a measurement contract fixed the moment it was filed: the metric it set out to move, the page or search that metric is read on, and what that number read before anything was touched.

| Where the task came from | Metric | Read on |
| --- | --- | --- |
| Click-through gap | Click rate | The page |
| Striking distance | Rank | The search |
| Content decay | Visits from search | The page |
| Keyword cannibalization | Visits from search | The page already winning the search |
| Authority gap or lost links | Sites linking to you | The site |
| AI citation gap | AI citations | The site |

The baseline is a starting point, never a result. Work with no honest baseline — most crawl and template problems — is verified against the site instead of measured.

## Inside a task

Open a task to see its number and title, its status, class, department, owner (**Engine-owned** or **Assigned to you**), and its priority band. Click the band to set the exact 0–100 number. The same verbs the lanes offer sit under the header — Approve, Reject, Skip, Mark done, Assign, Reopen, Priority — and each one writes the same event the engine would write for that transition.

### Where the work has reached

Under the header is a six-step rail: **Found → Planned → Approved → Executed → Verified → Measured**, each with the date it was reached. The step the task is sitting on is highlighted, and when something is holding it there — an approval you have not given, an external action only you can take, a skip reason — that reason is shown on the step itself. A step is only marked reached when the evidence for it exists: a plan for Planned, a decision, an automatic run start, or a handoff to you for Approved (a handoff needs no decision), a successful run for Executed, verification or resolution for Verified, and a recorded measurement for Measured.

### Why this matters

The first card is the brief in plain words: what the problem is costing today, what fixing it is worth, and the next concrete move. Under it are the pages and searches the task touches, each linking to that page or search on [Performance](/documentation/projects/performance), plus the metric the task is measured on and the number it started from.

### Plan

Every version of the plan is listed, newest first. Older versions collapse to a one-line summary marked **superseded by v{n}**, with what changed — the steps added or dropped and how much the scope grew or shrank.

- An **Action plan** shows the risk level, reversibility, estimated spend, the affected pages or searches, the steps the engine will take, and any warnings. When it is awaiting approval you can **Approve plan** or **Reject**.
- A **Task brief** appears when the work is yours to do. It explains **Why this task exists**, **How it was identified**, the **Recommended edits** (current value, proposed value, and the reason), **What you need to do**, and **Done when**.

Each plan lists its runs. A run shows every frozen step with what happened to it — done, running now, or not started yet — the provider cost, any error, and the before and after records side by side when both exist.

### Did it work?

A task created from evidence is measured, not just closed. The outcome card reads the task's metric on the same page or search over a window the same length as the baseline's, ending on the last day the evidence covers, and shows it against the number the task started from with a small trend line.

It is honest about when it cannot answer: while the work is unfinished it says **measuring starts when the task is resolved**, and for the first window's worth of days after it closes it says how many days of how many have passed. Nothing is called a result before then.

### Activity

Below that, the feed records every comment, analysis, proposal, status change, action, verification, and measurement in order. Proposals carry their proposed changes, verifications carry the check and its result, measurements carry the numbers, and status changes read as thin markers rather than messages. Routine engine chatter behind work handed to you is folded away; **Show engine activity** brings all of it back.

Directory and profile tasks list each listing with its setup guide and a short recipe. Mark a listing **Mark submitted** once you have created it, or **Not relevant** if it does not fit the site. A later authority refresh verifies the result; creating a profile is never treated as proof of a link.

## Steering a task

The composer at the bottom of the thread is the task's comment box. Use it to add context, ask why the task exists, change the approach, or ask the assistant to explain the plan before you approve it. Your message becomes part of the permanent thread and can steer the engine's next step.

When the engine cannot proceed safely it explains exactly what it needs and the task waits in **Your move**.

## What the engine does on its own

Which tasks the engine executes without asking depends on the project's [autonomy policy](/documentation/projects/autonomy). Under **Copilot** it performs low-risk, reversible work and asks before anything risky, external, or paid. Under **Audit only / MCP** it files findings and plans but never changes the site. External agents connected over [MCP](/documentation/account/mcp) can read task threads, comment, and update status through the same guarded action workflow.

Tasks also reach the queue from **Audit** with **Create task**. The engine still closes and reopens tasks on its own from verification evidence; the lane verbs are for the decisions that are yours.