# Revising an asset

Every asset keeps one request, one current file and a history of the files that didn't make it. How you get a new version depends on where the asset is.

| The asset is | Who | How | What happens to the files |
| --- | --- | --- | --- |
| `delivered`, your own delivery | the fulfiller who delivered it | Deliver again (`agh fill`, or `deliver_upload`, `deliver_file`, `deliver_text`). No claim is needed. | The new file waits for review. The one it replaces moves to the history, noted "Replaced by a newer delivery before review". |
| `delivered`, someone else's | a developer | Reject it with a note (`agh review --reject`), or revise it. | The delivery moves to the history with the note, and the request reopens for anyone to claim. |
| `accepted`, not published yet | a developer | `agh review --undo` (or **Back to review** on **Publish**) returns it to review. `agh revise` asks for a new version straight away. | Undo: the file waits for review again. Revise: the file moves to the history. Either way, the file it had replaced becomes current again. |
| `proposed`, in an open pull request | a developer | Merge the pull request, then revise it as published. Or close the pull request without merging: the asset is accepted again, and the row above applies. | Nothing changes while the pull request is open. |
| `published` | a developer or a coding agent | `agh revise`, **Ask for a new version** on the asset in **Library**, the **Revise** button under Published on **Publish**, or the `request_revision` MCP tool. | The published file stays current in agh and in the repository until a replacement is accepted and its pull request merges. That publish overwrites it at the same path. |
| `requested` or `claimed` | a developer | Nothing to reopen. Change the request with `agh mark --brief ... --reason ...`, or **Change brief** under Questions. | No file yet. The old brief is kept in the brief history. |

Fulfillers can't reopen an asset themselves. Delivered, accepted, proposed and published assets are never claimable, so a new version always starts with a reviewer's rejection or a revision.

## Revise

A revision needs a note saying what should change. It can also change the brief, spec, notes and tags:

```text
agh revise card.ember_wolf.art --note "Embers should glow orange, not red"
agh revise card.ember_wolf.art --note "Taller crop for the new frame" --spec size=768x1152
```

- **From a developer or admin**, the request reopens at once, with the note as `reviewNote`, so the next fulfiller sees it.
- **From a coding agent** (`agh revise` or `request_revision`), the revision goes into the agent's draft batch, like a new request. Submit it with `agh submit` or `submit_batch`, and it reopens once a person approves the batch. Approval is where spending is decided, and a revision costs as much as a new asset.

Calling `agh request` or `request_assets` again with an existing id doesn't revise it. That works only while the request sits in your own draft batch, including a revision you just made. Anywhere else, it is refused with a pointer to `agh revise`. A request that already has files keeps its path and kind; to move an asset, request a new id.

## History

Nothing delivered is thrown away, and no brief is either: every brief change keeps the old brief, spec and notes with who changed it and why, and the asset's conversation keeps every question, answer, rejection and revision note. `agh guide conversations` covers asking and changing a brief.

 `agh show <asset-id>` lists every rejected or replaced file with its note. `agh get <asset-id> --which rejected --attempt 1` downloads the oldest, and the Review page shows them under each delivery as earlier attempts. The current file, whether accepted or published, stays until another file is accepted in its place.