Request and review

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:

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.

For agents: this page as Markdown is at /docs/revise.md, and the CLI prints it with agh guide revise.