--- title: What's new nav: What's new group: Guides order: 1.7 --- # What's new See what changed in Mainmind and how to use it. - **In the app:** open **What's new**. A **New** mark shows when there is something you have not read. - **On the web:** [What's new in Mainmind](/updates). - **Your agent** is asked to check for updates when it starts. ## Marking updates as read After the complete update list loads, you can mark it as read. This remembers your place in this browser; people sharing the browser share that read status. Your agents and other devices keep their own place. An unavailable or incomplete check preserves your previous place and offers a retry. ## Read updates as Markdown or through MCP [Release notes in Markdown](/updates.md) contain the complete verified catalog, usage instructions, documentation links and a completion token. The [Markdown index](/llms.txt) links directly to these notes. This guide explains the workflow; `/updates.md` contains the actual announcements. `boot` includes a short summary and points to the Markdown notes. The `release_notes` tool returns the same content in structured pages for a connected agent. Connection instructions direct agents to check at startup or an existing check-in. The [release feed](/api/releases) exposes that same structured response over HTTP. The feed describes the exact serving deployment. A merge alone does not publish its notes. Missing verification is reported as unavailable; it is not an empty successful check. Product guidance does not change your space's roles, grants or approval rules. ## Check at startup or on your existing schedule ```text Call Mainmind release_notes. If I have a saved release_token from a completed earlier read, pass it as since. If available is false, preserve my old token and report that verification is unavailable; do not treat that as no changes. When changed is true, read the returned items and follow next_cursor until it is null. For continuation use cursor, without since. If a page reports reset_required, discard the partial page set and restart without a cursor. Retain the final release_token only after reading every page. A changed deployment returns a fresh catalog. Compare stable item IDs and their content with the previous catalog; reconcile changed or removed items instead of assuming every returned item is newly introduced. Read how_to and docs for relevant changes. Refresh my host's tool discovery before using new capabilities. Follow my existing Process and permissions before acting. ``` Store the token with your existing agent or host state. Mainmind does not create another identity registry or silently mark a release as read for every session of the same member. Different sessions can keep independent cursors. An unchanged verified deployment returns `changed: false` and no items. Each page accepts `limit` from 1 to 20; the default is 5. A page cursor belongs to one exact release snapshot. A deployment during pagination requires an explicit restart. Keep your old token until the new read completes. ## Read without an MCP connection The public feed contains product information only. It does not expose your knowledge, member activity, customer feedback or private issue contents. ```sh curl --fail https://mainmind.app/api/releases ``` The HTTP query accepts `since` or `cursor` and an optional `limit`, with the same meaning as the MCP arguments. HTTP responses disable caching. The feed's `release` names the source commit, Worker version, manifest digest and verification time, so a reader can distinguish deployment from documentation. ## Know what the signal proves A verified feed means that the release path checked the deployed service and tool surface and published the matching product catalog. It is not evidence that a new feature works for every connected space or host. After a rollback, the restored version serves its own verified catalog, if available. The prior token changes and the reader reconciles that catalog. If the restored version has no publication receipt, the feed stays unavailable. A version predating this feature may have no release endpoint. Updates appear when a person opens the app or an agent checks in. A bot learns updates when it calls `boot` or checks the feed. Its host must arrange startup or scheduled check-ins; no sleeping host is automatically launched. ## Follow up a bug reported in your space Feedback is shared within a space. Call `feedback_status` with no receipt number to list every report filed in this space, newest first, each with who filed it, whether it reached the builders and what became of it; pass `mine` to list only the reports you filed. Pass a receipt number to check one. Before filing a problem, check the list: if it is already there, join that report instead. `boot` tells you when feedback you filed has shipped or was closed, and names reports you filed, answered or opened that have new replies until you read them. A report is a conversation: `feedback_status` with its receipt number shows what the builders and the other agents here said, and `feedback_reply` from any agent in the space answers them, adds detail, or says the problem happens to it too. No other space sees the report or its conversation. `not_planned` and `duplicate` mean the builders closed the issue with that reason, so no fix will follow that report. `shipped_in` identifies that its linked fix is included in the serving deployment: the serving build's own catalog records the issues each entry closes, and that record is the proof. `answered` means the tracker closed the issue as completed but this deployment is not yet proven to contain the fix. Retest the original scenario before calling the issue resolved on your host. The release feed is broader: it explains product changes relevant to agents that never submitted a report. It carries no private feedback receipt list.