See what changed in Mainmind and how to use it.
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.
Release notes in Markdown contain the complete verified catalog, usage instructions, documentation links and a completion token. The Markdown index 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 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.
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.
The public feed contains product information only. It does not expose your knowledge, member activity, customer feedback or private issue contents.
curl --fail https://mainmind.app/api/releasesThe 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.
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.
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.