# Questions and brief changes Every asset has a conversation beside its brief. The brief is the current instruction; the conversation is how the people who request, review and make an asset agree on it. Use it whenever a brief is unclear, or a review note asks for something the brief doesn't say, before anyone makes another file. ## Ask before you make A fulfiller who isn't sure what is wanted asks on the asset: ```text agh ask hero.hero_3.concerned "The brief still asks for a connected braid. Only this portrait, all three expressions, or the reference and icon too?" ``` On the web page, open **Ask a question about this request** (or **Conversation**) on the request, under **Open requests** or **My claims**, and tick **Ask as a question**. Over MCP, call `post_asset_message` with `question` true. A request with an open question is on hold: `agh next`, **Claim next** and `claim_next_request` skip it, and it leaves the open requests list. A claim you already hold stays yours, and you can still claim the request by its id. The question counts in the inbox of the people who request assets, under **Questions** on the web page and `questions to answer` in `agh inbox`, until someone other than you writes on the asset. When someone answers, the request opens again, and your inbox counts it under **Questions** (`replies to your questions`) until you write back or the request moves on. ## Attach files A question or an answer can carry up to five files, so you can show what you mean instead of describing it: a reference sheet or a rough model with "does this match what you want?", or a marked-up image in the answer. ```text agh ask char.npc.lantern_keeper "Does the proportion match before I start the full model?" --file turnaround.png --file blockout.glb agh reply char.npc.lantern_keeper "Close. Bigger lantern and a longer coat, see the marks." --file turnaround_marked.png ``` On the web page, choose **Attach files** under the message box. Over MCP, upload each file with `start_upload`, giving `attachment` the file's name, then list the uploads in `post_asset_message`'s `attachments`. Guests attach files the same way on their link's page. - A message takes images, models, audio, video, text and PDF files, up to 100 MB each. Other kinds, such as programs and archives, are refused. - Pictures, models, audio and video show in the conversation in the same viewers as review. `agh show` lists each file with its id; `agh attachment get ` or `get_file_link` with `attachment` downloads it. - Files never change the request, its claim or its deliveries, and they are never published or counted in the AI disclosure. To deliver the real thing, deliver it as usual. ### How long files are kept - While the asset is open (requested, claimed, delivered or accepted), its files are kept. - Once the asset is published or cancelled, its files are kept for 90 more days, then deleted. If a revision reopens the asset, the 90 days start again the next time it closes. The page shows the date a file is kept until. - The person who posted a file, or an admin, can remove it at any time (**Remove file** on the web page, `agh attachment remove`, or `remove_attachment` over MCP). It is deleted for everyone. - A removed or expired file leaves its name in the conversation, with who removed it or "File expired", so the conversation still reads. The message's text always stays. - When a guest link expires, the guest can no longer see the files. Nothing is deleted. ## Answer, then change the brief Anyone who can see the asset can reply: ```text agh reply hero.hero_3.concerned "Only this portrait for now. Keep everything else the same." ``` A reply doesn't change the brief. Fulfillers, and the next fulfiller in particular, work from the brief, so once you agree what is wanted, change it (admins and developers): ```text agh mark hero.hero_3.concerned --brief "Hero 3, concerned expression, hair loose with no braid" --reason "Client: no braid, this portrait only" ``` On the web page, **Change brief** under **Questions** does the same. Over MCP, it is `change_brief`. Change each asset the decision covers. A change to one asset never spreads to related ones by itself. An agent can change its own requests the same way until a person approves them: while they sit in its draft batch, or in a batch waiting for approval. Once a request is approved, the agent's change to its brief, spec or notes is *proposed* instead, with the reason required. The request keeps its brief, and fulfillers keep working from it, until an admin or developer decides: - On the web page, proposals wait under **Approve > Brief changes**, with the current and proposed brief side by side, and the Inbox and the asset show that one waits. - From the CLI, `agh brief-change list`, then `agh brief-change approve ` or `agh brief-change decline --note "..."`. - Over MCP, `review_brief_change`. Approving replaces the brief like any other change. Declining keeps it, and the note is posted in the conversation, where the agent reads it. A newer proposal replaces one still waiting. Tags and `used_in` stay with admins and developers. The old brief, spec and notes are kept in the asset's brief history with who replaced them and why, and the reason is posted in the conversation. `agh show` lists both, and `get_asset` returns them as `briefHistory` and `conversation`. ## Reject: doesn't meet brief, or change brief A rejection says which it is: - **Doesn't meet brief** (the default): the file doesn't do what the brief asks. The brief stays, and your note tells the next fulfiller what to fix. - **Change brief**: the file may be fine, but the person who asked now wants something different. Give the new brief, spec or notes with the rejection, and your note is kept as the reason. ```text agh review hero.hero_3.concerned --reject --note "Too dark; keep the face lit" agh review hero.hero_3.concerned --reject --changes-brief --brief "Hero 3, concerned, hair loose (no braid)" --note "Client dropped the braid" ``` On **Review** these are **Reject: doesn't meet brief** and **Reject: change brief…**. Over MCP, `review_delivery` takes `reason` `misses-brief` or `changes-brief`. If what a change covers is unclear, ask in the conversation first rather than rejecting with a note that contradicts the brief. A rejection note from before a later brief change is shown as history ("before the brief changed"), so it doesn't override the brief. ## Accepted and published assets To change an asset that already has an accepted or published file, ask for a revision (`agh guide revise`). The revision's note is posted in the conversation, any brief change is kept in the brief history, and a published file stays in use until its replacement is accepted and its pull request merges.