> ## Documentation Index
> Fetch the complete documentation index at: https://docs.attensira.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Changes

> Every piece of work an agent files is a change: planned, drafted, shipping, live and checked. How the 48-hour window, the Weekly Ship, review and Undo work, and what cannot be undone.

A **change** is one piece of work an agent filed for you: a page fix, a rewrite, an article, a listing, a pitch, a post. Every door shows the same change: the app, your [Inbox](https://docs.attensira.com/agent/inbox.md), email, Slack, the [REST API](https://docs.attensira.com/api/endpoints.md#changes) and the [MCP server](https://docs.attensira.com/mcp/tools.md#changes-and-autonomy).

Each change carries its lane (`own_site`, `offsite`, `outreach` or `social`), its class (safe, claim or never, see [the classes](https://docs.attensira.com/agent/approval.md#what-attensira-changes-on-its-own-and-what-it-always-asks-about)), and whether it can be undone. Together with the lane's [autonomy level](https://docs.attensira.com/agent/autonomy-levels.md), those decide whether it waits for you.

## What a change goes through

| Stage | In the app | What it means |
| - | - | - |
| `planned` | Planned | Filed, with nothing drafted yet. |
| `drafted` | Draft ready | The draft exists and waits: for your yes, or for you to put it live yourself. A change written to your editor as an unpublished draft is here too. |
| `shipping` | Shipping | On its way: you approved it, or its lane's level scheduled it to ship when its 48-hour window ends, or it is being written now. |
| `live` | Live | It took effect: its pull request merged, an integration published it, or you marked it shipped. |
| `checked` | Checked | A [check](https://docs.attensira.com/measure/before-and-after.md) wrote a verdict, any verdict. Whether it worked is the verdict on its [receipt](https://docs.attensira.com/measure/receipts.md), not this stage. |

A change can also end in one of four ways:

| End | In the app | What it means |
| - | - | - |
| `stopped` | Stopped | You stopped it inside its 48-hour window. It will not ship. |
| `reverted` | Undone | It shipped and was undone. |
| `failed` | Couldn't ship | Publishing tried and gave up. Your Inbox has the reason. |
| `declined` | Declined | You, or a teammate, said no. |

`GET /v1/changes?lifecycle=` filters by stage (`GET /v1/changes` and `GET /v1/changes/{id}` are served on `webapp.attensira.com` and not on `api.attensira.com` yet, which answers `404`; over MCP, `list` with type `change` and `get` on a change's address read through them), and the `change.shipping`, `change.live` and `change.reverted` [events](https://docs.attensira.com/api/endpoints.md#change-events) follow a change without polling.

## Reviewing a change

Open a change from your Inbox to read it before it ships: the draft, the page it is for, the evidence behind it and the result of the [draft check](https://docs.attensira.com/agent/approval.md#the-draft-check).

* **Approve** ships it as written, **Edit** ships your version, and **Decline** takes a reason so the same change does not come back. An approval is bound to the version you read; if the draft was revised since, you are asked to read it again. See [Acting on a row](https://docs.attensira.com/agent/inbox.md#acting-on-a-row).
* **Section by section.** A longer draft is split at its headings. You can accept, reject or edit each section, or have the sections nobody decided written again; every edit and rewrite passes the draft check before it is kept. Over the API: `GET /v1/changes/{id}/diff` and the section actions of [`POST /v1/actions`](https://docs.attensira.com/api/endpoints#post-/v1/actions).
* **A pull request** can be read live from GitHub inside Attensira, and merged from there with a second, separate yes. See [Reviewing a pull request in Attensira](https://docs.attensira.com/agent/github.md#reviewing-a-pull-request-in-attensira).

## The 48-hour window

In a lane at **L3**, a safe change that can be undone is approved for you with a window: it ships **48 hours** after it is filed unless you stop it. The change says when ("Ships Wed 21 Oct 12:00 EEST unless you stop it"), and carries `ships_at`.

* **Stop** keeps it from shipping. It takes a reason, which keeps the same change from coming back. A stop that arrives a moment after the change started shipping is refused with `veto_lost_race`, never ignored: undo it instead once it is live.
* **Ship now** ends the window and ships it on the next publish pass, a minute or so later. It is a yes like any other, so it is held to the same rules as approving: a key needs an `approve` scope covering the change's lane and effect class, and never ships something that cannot be undone. Over the API: `POST /v1/changes/{id}/actions` with `{"action": "ship_now"}`. A change that was stopped, declined or never scheduled is a `409` that says which. Ship now is not on MCP yet.
* **If you lower the lane** before the window ends, the change does not ship; it waits for your yes instead.

The full rules, including what happens when a stop and the ship arrive at the same moment, are in [Stopping a change in its 48 hours](https://docs.attensira.com/agent/approval.md#stopping-a-change-in-its-48-hours).

## The Weekly Ship

Once a week, your own site's changes are put together into one decision: the **Weekly Ship**. Instead of a row for each fix, you get one row in your Inbox, titled with what is in it, for example "Weekly Ship: 9 changes (4 page fixes, 3 rewrites, 2 articles)".

**When.** At 09:00 on Monday in your workspace's time zone (UTC when none is set). A set is only made when at least **2** changes can join it, and holds at most **40**; anything past that waits for the next week.

**What joins.** Open changes to your own site (page fixes, rewrites and articles) that are classed **safe**, can be undone, and that the draft check passes. A change that is waiting for your yes joins, and so does one already counting down its own 48-hour window. A claim, a change that cannot be undone, and a draft the draft check holds never join: each keeps its own row and its own yes, so one change never makes the whole week wait. Listings, pitches and posts are never in a Weekly Ship.

**Deciding the set.**

* In a lane at **L3**, the set is scheduled like any other change: it ships 48 hours after it was made, unless you stop it. Joining a set never ends a change's own window sooner.
* At **L2** or below, the set waits for your yes. Until you decide, changes drafted later in the week are added to it, and its version moves, so a yes always covers the set you read.
* **Approving** the set approves each change in it at the version the set took in. **Stopping** the set stops every change in it. **Declining** it declines the drafted changes and stops the scheduled ones.
* The changes in a set are listed with `GET /v1/changes?bundle={id}` (on `webapp.attensira.com`); the set itself is a change of `kind: bundle`.

**How it ships.** Each change goes out the way it would alone, together:

* **Through a repository:** one pull request per repository, on one branch (`attensira/weekly-ship-…`), with **one commit per change**, so you can review it commit by commit or as one diff. The pull request lists every change in it. See [The Weekly Ship on GitHub](https://docs.attensira.com/agent/github.md#the-weekly-ship).
* **Through your CMS or Notion:** each change is written in the same pass, one draft or update each, because those editors have no way to hold several pages as one draft. They are approved, stopped and undone with the set.
* **With nothing connected:** the changes go into one **paste pack**: a single page with each item, the page it belongs on, the passage it replaces and what to paste. One Inbox row says "Your Weekly Ship paste pack is ready: 3 items to put live". Paste each one into your site, then mark it shipped with its live link, one item at a time; we never say an item is live that you did not mark. Over the API, mark each item with `POST /v1/inbox/{id}/shipped` and its live URL.

**What can leave the set.** Before anything ships, each change is asked again everything it would be asked alone: its class, its lane's level, the caps, the connection, and whether the page changed. One that fails is taken out of the set, with the reason on its own timeline ("Left out of this week's Weekly Ship: …"), and the rest ship. A change whose page moved since it was drafted comes back with a fresh diff for you to review. A change that was revised after the set took it in needs its own look, because your yes was to the earlier version.

A set is closed once every change in it went live, was decided or left it. If none of them went live, it closes saying so, never as a set that shipped.

## Undo

A change we shipped can be undone for **30 days** after we made it. Press **Undo** on the change, or call `POST /v1/changes/{id}/actions` with `{"action": "undo"}` (over MCP, `act_on_change` with `undo`). It is the same undo through every door, and asking twice starts nothing new.

How the undo works depends on where the change went:

| Where it went | What Undo does |
| - | - |
| A pull request nobody merged | Closes it and deletes our branch. Nothing reached your site. |
| A merged pull request | Opens a pull request that puts the file back. Who merges it is described under [Undo on GitHub](https://docs.attensira.com/agent/github.md#undo). |
| A field in Webflow, WordPress or Shopify | Writes back the value it had before our change, only while the field still says what we wrote. See [Undo in your CMS](https://docs.attensira.com/agent/cms.md#undo). |
| An article we created in your CMS | Takes it off your site and back to a draft. We never delete it. |
| A Notion page | Puts an update back as it was, or archives a page we created. See [Notion](https://docs.attensira.com/agent/notion.md#undo). |

**An undo never writes over a person's edit.** Before writing, we read the page or file again. If somebody changed it after us, nothing is written: the undo stops and tells you what is there now and how to put it back by hand keeping the edit you want.

While it runs the change shows **Undoing…**, and when it is done, **Undone**, with what is back on its timeline. A change that is partly undone (a revert pull request that waits for your merge, for example) says which step is yours. If the undo fails after its retries, one row in your Inbox gives the reason and the step to do it yourself. Nobody at Attensira does an undo by hand.

On the API, every change carries `undo`: its `state` (`available`, `undoing`, `undone`, `undo_partial`, `undo_failed`, `expired` or `not_reversible`), the `sentence` a person reads, the `step` when one is yours, `until` (when the 30 days end) and `url` (the revert pull request, once there is one). An undo that finishes sends `change.reverted`, and the change's receipt says it was reverted.

## What cannot be undone

Some changes have no way back that we can take:

* **A sent pitch or email.** Mail cannot be recalled.
* **A listing, a profile update, a post or an answer on another site.** Those live on someone else's site or your own account there; you remove them there.
* **Spending money.**

These are exactly the changes that wait for your yes at every level. They never ship when a window ends, and they never join a Weekly Ship.

For such a change there is no Undo button. Asking for one over the API answers `409` `not_reversible` with the sentence, and, where we can name the place, the step that does it yourself, for example "Edit /pricing back to how it was." The same answer comes back for a change past its 30 days ("The 30-day undo window closed on Oct 3."), with the step for a pull request: "Open pull request #12 on GitHub and use its Revert button, then merge the revert."

## Related

* [Autonomy levels](https://docs.attensira.com/agent/autonomy-levels.md): what each lane does on its own.
* [Approval modes](https://docs.attensira.com/agent/approval.md): the classes, the draft check and the caps.
* [Before and after](https://docs.attensira.com/measure/before-and-after.md) and [Receipts](https://docs.attensira.com/measure/receipts.md): what a change moved.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.