Admin console · animated

Click to expand

Releases

Route: /releases

The Releases page in Mushi Mushi drafts changelogs for each version of your app, crediting the reporters whose bug reports were fixed. Publishing tells each credited reporter that their fix shipped.

The tabs are Drafts, Published, Draft (generate a new one), Batch and App stores.

What it generates

For a new draft, Mushi Mushi:

1. Collects up to 50 reports marked fixed in the report window (30 days by default) that no earlier published release already shipped.
2. Asks the AI to write a user-facing changelog: a short summary and a Bug fixes list, each line crediting the reporter.
3. Records a credit for each reporter.

Creating a release

1. Open the Draft tab.
2. Enter the Version (e.g. 1.2.3) and, if you like, a Title (optional).
3. Set the Report window (days) (30 by default).
4. Click Generate draft with AI.
5. Open the draft under Drafts, edit the Changelog and click Save draft.
6. Click Publish + notify and confirm.

The same steps work from a script or an agent with an API key: reads (GET /v1/admin/releases, /stats, /:id) take mcp:read; drafting, editing, deleting a draft and publishing take mcp:write. Publishing messages every credited reporter, so give a key mcp:write only where you would let it do that. A key bound to one project only sees that project’s releases. An account-level key reaches every project you can reach, with your role in each: it opens any release in those projects, and /stats needs the project named with project_id (or the X-Mushi-Project-Id header).

Release automatically when you ship

Off by default. Turn on Release automatically when you ship on the Releases overview (project admins only, or PATCH /v1/admin/settings { "auto_release_enabled": true }). From then on, any of these ships a release on its own:

curl -X POST "$MUSHI_API_URL/v1/ingest/recipe/events" \
  -H "X-Mushi-Api-Key: $MUSHI_CI_KEY" -H "Content-Type: application/json" \
  -d '{ "events": [ { "type": "release.published", "targetId": "web", "version": "2.4.1" } ] }'

For each trigger, Mushi Mushi:

1. skips it if a release with that version already exists;
2. skips it if no report was marked fixed since the last published release (a deploy with nothing fixed makes no release);
3. skips it while another automatic draft is open (see below);
4. drafts the release from those reports and publishes it, so each reporter gets one “your fix is live” message and credits are stamped once delivered.

An automatic release is published without anyone reading it first, and report summaries come from your users. So its notes are not written by AI. Each fixed report becomes one line, with markdown escaped and links removed.

Only one automatic draft can be open per project, so a GitHub release and the deploy it triggers cannot both announce the same fixes. If publishing fails before the release goes live, the draft stays under Drafts, and auto-release pauses until you publish or delete that draft. The auto-release card on the Releases overview says so and links to it. If the release went live but messaging reporters failed part-way, the log says the release is published and some reporters were not told.

The version must be a plain tag, semver or sha (letters, digits, ., _, +, -, at most 64 characters), because reporters see it.

Send release.published with an agent key that has mcp:write, minted with mushi login or in the console and kept in CI secrets. A key that cannot release still has its event recorded, and the answer gives the reason:

One request releases at most once, for its last release.published event. The answer gives that version in autoReleaseVersion and lists any others in autoReleaseIgnoredVersions.

Batch tab: what ships next

The Batch tab shows, for each repo, the release train that is running now or leaves next. A release train collects your approved fix pull requests and merges them together, so they ship as one deploy. The tab only reads: re-run, merge and remove fixes from Pipeline.

• Each fix shows whether it rides or waits, the AI review’s verdict at its current commit (the console labels it Opus), its CI, and why it waits.
• Rules to ride count how many fixes pass each rule: Opus said merge at the current commit, not a draft, its own CI is green, it did not keep failing trains at that commit, and it is not urgent (urgent fixes merge on their own).
• Database migrations lists migration files in the fixes’ changes. Mushi Mushi looks in the folder your app recipe names (data.migrationsDir in mushi.recipe.json), or else in supabase/migrations, prisma/migrations and migrations. Mushi Mushi never runs them; apply them when you deploy. If a change could not be read, the list says it may be incomplete.
• Deploy after the last train says whether the merge commit was seen running, or a deploy was seen after the merge. With no deploy in 14 days it links to the setup gap that explains why reporters are not told.

GET /v1/admin/release-batch?projectId=   # one app, or every app you can open

Release fields

Published releases are not exposed through an SDK method; reporters hear about them through the widget’s notifications.

Related pages

• Fixes — the pull requests behind the fixed reports
• Reporter updates — the messages reporters receive
• Pipeline — re-run, merge or remove fixes in a release train