---
title: Interruption and Resumption
description: Where you can resume interrupted work and which files record progress
seo:
  image: /ogp.png
---
Long pipelines stop midway. Sessions disconnect, or a reviewer surfaces a blocker that requires a human decision.
NexusArchitect writes progress to files as it advances, so **running the same command again resumes from where it left off**.

Progress is recorded in separate locations for the product pipeline and the backlog side.

| Record file | Who writes it | What it contains |
|---|---|---|
| `work/pipeline-progress.json` | `/product:start` and each phase | Per-phase state (`pending` / `in_progress` / `completed` / `failed` / `skipped`), validation gate verdicts, output destinations |
| `reports/backlog/backlog-manifest.json` | `export-backlog` and implementation skills | `impl.status` per Epic / Sub-Epic / Issue, and the URL of each created Issue |
| `status::*` labels on GitLab/GitHub | Implementation skills | The current stage of each Issue. See [Status Label State Machine](/concepts/status-labels) |

## Checking your current position

```
/product:report-status --once
```

This displays the state of each phase, how many declared output files exist, validation gate verdicts,
and the next slash command to run.
The `--once` flag renders a single snapshot; without it, the display refreshes every 10 seconds as a live screen.

You can also view non-product pipeline status on the same screen by switching tabs with the Tab key.
The three tabs are Architect (architect pipeline), Code Generation, and Backlog Delivery.
For a detailed walkthrough of the screen, see [Live Dashboard](/concepts/live-dashboard).

## Resuming planning (product)

```
/product:start --profile=<same profile as before>
```

Phases already marked `completed` in `pipeline-progress.json` are skipped, and execution continues from where it stopped. Specify the same profile you used previously.
Passing a different profile changes the set of phases that will run.

## Resuming the backlog

`export-backlog` is designed to be **idempotent — running it multiple times produces the same result**.
Items that already have a `remote.url` (a link to a created Issue) are skipped, so the same Issue will never be created twice.

From implementation onward, resumption is based on each Issue's stage.

```
/architect:deliver-backlog --epic=E1
```

Completed Issues are skipped, and in-progress Issues continue from their current stage.
The entry stage is determined from `impl.status` and `status::*` labels, so no explicit specification is normally needed.
Use `--from` only when you want to override that determination.

```
/architect:deliver-backlog --epic=E1 --from=review
```

:::note[The source of truth for state is fixed]
On resumption, the system reads `impl.status` and the tracker's `status::*` labels.
The `labels` array in the manifest holds the initial values written by `export-backlog` at creation time and is not updated as work progresses.
Markdown checkboxes are also not an input source for state (see [Checklist Triple-Layer Contract](/concepts/checklist-contract)).
If `impl.status` and labels disagree, **the tracker side is treated as authoritative** and the manifest is updated.
:::

## When stopped by a blocker

If the auto-fix loop in `review-issue` reaches its limit (3 attempts by default) without resolving the issue,
the Issue moves to `status::blocked` and a comment requesting a decision is posted.
This is not an abnormal exit — it signals that a point requiring human judgment has been reached.
Once you address the comment, you can resume with the same command.

:::warning[When the shared-context pack is stale]
After rewriting design documents under `reports/`, the [Shared-Context pack](/concepts/shared-context)
still contains the old content. Rebuild it by passing `--build-context`.

```
/architect:implement-backlog --build-context
```
:::
