DEV Community: Mihai Perdum

Atlassian Team '26 Europe announcements: AMP, MCP

Mihai Perdum — Thu, 08 Oct 2026 06:00:08 +0000

The Atlassian Team '26 Europe announcements came out on Wednesday 7 October, the day of the Founder Keynote in Amsterdam, and they fill 11 rows on our status board. Three of them get the most space here: AMP (the Agentic Multiplayer Protocol), the Atlassian MCP Server and Rovo Work, a new mode in Rovo Chat. The morning after, our test organization had no Rovo Work. Its MCP server page did list 19 toolsets tagged New, and every new read, write and search one was already allowed.

Atlassian's platform post says AMP is "live across the Atlassian platform today", and the features under it carry their own labels, from generally available to beta, early access and Soon. What reaches you as an admin is mostly settings and Rovo credits.

Sami Shaik hit the same default and posted about it two days before the keynote. He found "a new write toolset switched on because 'allow new write toolsets by default' was on" (Four switches govern external AI access to your data).

Most of the announcements are still coming, but the switches are already here. I'd spend this week on the switches.

This is part 4 of our series. Part 1 is the hub with the event times, and part 3 covered Tuesday.

Five things we found, mostly on our test org

Of the 11 items on our board, only the Atlassian MCP Server carries a GA label, and its v2 has been GA since 8 September.
Our MCP Permissions tab listed 36 toolsets, 19 tagged New. Every read, write and search one was allowed, new ones included, and Delete and Manage were blocked.
Next door, the Teamwork Graph CLI allowed all 32 of its permissions, the 7 delete ones included.
Rovo Work wasn't in any Rovo Chat menu on our test site on 8 October, with beta features switched on.
Code context turns itself on for Rovo-connected Bitbucket workspaces, and it keeps indexed code in the United States.

AMP: the Agentic Multiplayer Protocol

Atlassian calls AMP "the collection of human-centric experiences, technologies, and patterns that shape how humans and agents work together". In practice, agents show up next to people: the press release says they "now appear in real-time presence bars and cursors alongside human teammates on canvases and whiteboards". The AMP page also describes registering an agent once and choosing where it shows up, on a Jira board, a Confluence page or in Rovo Chat, but gives no date for it. Mike Cannon-Brookes's founder update says "AMP begins rollout today", and no Atlassian page we read gives it a plan tier. You won't find a setting called AMP.

What you'll actually configure is identity. The press release says agents can "Run as User" or use dedicated service accounts. The closest settings that exist today are Rovo Studio's "User's account" and "Agent's account", though Atlassian doesn't say they're the same thing. For automation, its doc suggests the Agent's account "to minimize security risks". I compared Rovo agent permissions with the approval step in our own app, CogniRunner, in an earlier post.

Atlassian MCP Server (the Rovo MCP server): from dozens of tools to 200+

It's the only GA row on our board. Atlassian's MCP post says "Atlassian MCP is generally available now" with "220+ tools" (its platform post says 200+), and the press release says it uses up to 25% fewer tokens, "in internal benchmarking on Claude models". The changelog shows v2 reached GA on 8 September, so if you read the developer changelog, you've met it already. Your admin page still calls it the Rovo MCP server.

Go to Atlassian Administration, then Rovo, then Rovo MCP server, then Permissions. Ours said "New toolsets available". Read was 15 of 15 allowed, Write 15 of 15, Search 4 of 4. Eight write toolsets were tagged New, among them write_goals, write_projects and write_teams. We don't know when each tag appeared: Atlassian's changelog added most of these families in September. The permissions doc explains the rest: "New permissions won't require manual review by admins".

Read toolsets arriving on their own worry me less, since every action respects the user's existing permissions. Still, the new ones on ours included read_loom and read_talent, which reach Loom meeting recordings and Talent headcount metrics, so look through yours. Write is different, and I'd want to see each one first. That takes two steps. While Write says Allow all toolsets, its switches are greyed out. Change it to Allow some toolsets and you can set each one yourself, and Allow new write toolsets turns off with it. All 15 stay allowed until you clear them.

Delete and Manage were 0 of 1 on our org, with their allow-new switches off. Good, because delete_jira can "permanently delete issues, comments, and attachments".

Domain allowlists and the MCP control in data security policies only apply to OAuth connections. An AI tool using an API token skips the domain list, and so does one connected through enterprise managed authentication, which is in beta. Both were off on our org, so check yours.

Atlassian also adds tools inside toolsets: on 30 September, getJiraScreen and updateJiraScreen went into manage_jira, available to users who had already approved it. And on 1 March 2027, anything still on v1 starts using the v2 tools automatically. Every tool call lands in the audit log on all tiers (monitor MCP activity).

The Teamwork Graph CLI sits two items below the MCP server in the Rovo menu, and it surprised me more. On our org, "Allow all permissions by default" was on. View was 13 of 13, and Write and manage was 12 of 12. Delete was 7 of 7.

Rovo Work: announced, but not in Rovo Chat on our site yet

The platform post says Work "handles complex, multi-step tasks", that "A task can run for hours", and that it runs "in a secure sandbox your admins govern". Atlassian gives it no status, and we couldn't find a doc page. On our test site, with beta features switched on for the org, the reasoning menu offered Let Rovo decide, Quick answers, Think deeper and Deep Research. The + menu had skills, files, links, mentions and formatting. No Work.

Keep an eye on cost. The licensing FAQ lists "Work mode in Rovo Chat" under premium AI interactions with variable pricing. Extra usage billing for Rovo credits starts on 3 December 2026 at a list price of $0.01 a credit, and Atlassian's doc says extra usage "is enabled by default" (How Rovo credits work). On our test org it wasn't on yet: the Rovo credits page offered Enable extra usage. I want to try Work. I just can't tell you yet what one long task costs.

Agent accounts and a non-human identity inventory: Soon

The platform post says "Soon" for "agent accounts and non-human identity inventory": one place to see every agent, app and service account, and switch any of them off. Today our Directory has Users, Groups, Teams, Managed accounts, Service accounts and Domains. Rovo agents sit under Rovo, then Agents. The inventory isn't there yet.

Local EU AI inference: rolling out, with no setting we could find

Atlassian says it restricts "LLM processing exclusively to models hosted within the EU", and the founder update says it's "rolling out". We couldn't find a doc page. Our Data residency page has no inference setting either. Data residency pins where data is stored. This one is about where the model runs, so I'd ask your account team before telling your DPO you're covered.

Code context: open beta, code kept in the US

There are three names here: "Rovo Code Search" in the platform post, "Code Search app" in the press release, and code context in the docs. Atlassian doesn't say they're the same. I won't guess. Code context is "gradually rolling out ... through open beta" on Standard, Premium and Enterprise. Indexed code is "stored and processed in the United States", and data residency isn't supported (set up code context). For a paid Bitbucket workspace connected to a Jira site with Rovo, "Atlassian will automatically enable Code context". Our admin page puts it as "by January 2027".

The Artifacts app: in beta, private by default

AI-made plans and HTML views get permanent links you can embed in Confluence or Jira. The doc says "Atlassian Artifacts is in beta. It's available to all paid plans." New artifacts are private. A deleted one "can't be restored", so plan for that.

Atlassian Insights: a phased rollout

Structured data from your lakes and warehouses becomes Teamwork Graph context. The Insights post promises "a phased rollout starting after Team '26 Europe" for all paid Cloud customers. If your org uses Atlassian Analytics today, it's been renamed Insights, and your org admin chooses between the existing experience and Rovo Insights.

Agent Sessions and Interactive PR Reviews: closed EAP

Agent sessions link local and cloud agent runs back to work items. If you use Rovo agents, the Jira coding agent or a cloud coding agent like Claude, Cursor or GitHub Copilot, Jira can already link their sessions to work items (Use the Agents dashboard). Local sessions from IDEs and terminals are the new part, and Atlassian's SDLC post says "Agent Sessions and Interactive PR Reviews in Loom are in closed EAP". Record for Agent, where a quick screen-and-voice recording becomes a brief an agent can turn into Jira work items, is in open beta.

Atlassian Guard Premium: scanning you can use now

The platform post lists full-site historical scanning, scanning of content and attachments, and guardrails across Rovo Chat. If you have Guard Premium, both scans are documented already, one since April and the other since 2 September. The MCP control in data security policies was announced in the changelog on 29 September and needs Guard Standard (our earlier explainer).

New connectors: Zoom, Gong, Microsoft Entra ID and Google Identity

Atlassian names these among the additions to its 80+ connectors, which its docs call Teamwork Graph connectors. Zoom has a setup doc. If you're after Gong, Entra ID or Google Identity, we couldn't find a doc under those names yet. The nearest Google one is Connect Google Workspace Directory to Teamwork Graph, published 6 October, and Atlassian doesn't say it's the same thing.

Also announced: an OpenAI partnership, Flexera in Assets and more

Atlassian posted an OpenAI partnership on 6 October. On 7 October came a Flexera agreement bringing its Technopedia data into Jira Service Management and Assets. Three smaller items that aren't on our board carry a GA label: Workforce Management and AI Change Risk Assessment workflows in Jira Service Management, per the Service Collection post, and the DX AI Measurement solution, per the SDLC post. Atlassian also profiled its Forward Deployed Engineer programme, which started as a pilot late last year and is open to a select group of enterprise Cloud customers using Rovo.

For Forge builders, the MCP post says developers "can build custom MCP tools with Forge". The rovo:mcp module does that. It has been in Preview since 14 August. On 1 October the changelog moved one more part into Preview: connecting its tools to external AI clients like Claude Desktop, Codex and Cursor. The module reference still labels that part EAP. The SDLC post says Cognition's Devin, Factory and Warp "are all available on the Atlassian Marketplace today, with OpenAI Codex coming soon".

What I'd do this week

Open Rovo, then Rovo MCP server, then Permissions, then Write. Change Allow all toolsets to Allow some toolsets, clear any toolset you don't want, starting with the ones tagged New, and save. That also turns off Allow new write toolsets.
Keep Delete and Manage blocked unless someone asks with a reason. On the Authentication tab, make sure Allow API token authentication and Allow enterprise managed authentication are off unless something needs them.
Open Rovo, then Teamwork Graph CLI. If nobody needs it to delete, turn off "Allow all permissions by default", clear Delete, and choose Save and revoke sessions.
Open Insights, then Platform usage, then Rovo credits, before 3 December. If you see Update extra usage limit, set one. If Get more usage offers Enable extra usage, it isn't on for your org yet, so look again in December.
If you have a paid Bitbucket workspace connected to a Jira site with Rovo, open Rovo, then Code context. There's no switch to keep it off: the page only offers Request indexing. If your code mustn't be stored in the US, ask your account team now whether you can opt out, or be ready to disable it the day it turns on, which deletes the stored index.

What we're watching next

The Closing Keynote is scheduled for Thursday 8 October at 15:00 CEST, and Atlassian's on-demand library says recordings start on 12 October. Part 3 asked where Rovo agents land in Jira Service Management. The Service Collection post puts its AI agents in Slack, Teams and Claude through "service and operations context where you work", which is in closed EAP, and Atlassian's MCP post still lists Jira Service Management workflows as "coming soon". One update we've made to our hub: Atlassian's keynote session page now lists four speakers, not the five it listed on 5 October, and has it ending at 10:30. Its agenda still says 10:15. When Rovo Work or the identity inventory shows up on our org, it'll get its own write-up.

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.

Sentiment analysis in Jira Service Management

Mihai Perdum — Wed, 07 Oct 2026 05:00:46 +0000

I went to Rob Hean's workshop on Jira Service Management queues at Team '26 Europe, and it was excellent, sentiment analysis included. That's the AI field that marks a request Positive, Neutral or Negative. So on 7 October we ran the sentiment part through Jira's strict JQL validator on our two test sites. Sentiment = Negative is valid, Sentiment = Angry is rejected, and neither site had a single work item with a sentiment value.

The only Atlassian text we found that says you can build a queue on sentiment is a 2024 Community post, written when the feature was in beta. The current doc doesn't mention JQL at all. And Atlassian's own example for keeping queues fast, updateDate < 14d, fails Jira's validation outright.

The clause is valid. What I can't tell you is whether a queue built on it ever fills. That depends on your plan, the per-space toggle and what your customers write.

The rest of Tuesday 6 October is below too: the Atlassian Williams F1 show car, a smoothie bike, the partners we met, a short Forge section and what we planned to watch in the Founder Keynote on Wednesday 7 October. This is part 3 of our series. Part 1 is the hub with dates and livestream times, and part 2 covered Partner Accelerate on Monday. The keynote announcements get part 4, on 8 October.

Five things we found that you can act on

Don't copy Atlassian's updateDate < 14d queue tip. It fails validation. Use updated >= -14d.
Split a slow, complex queue into several simple ones. There's room: the cap is 300 queues per service space per work category.
On Premium or Enterprise with AI on, turn on Customer sentiment analysis per space. Old work items stay blank until the reporter comments again.
Build one Sentiment = Negative queue, put it in a priority group so it refreshes on the regular sync, and count what it catches after a week.
If your Forge app adds JQL clauses, time them in a queue with real volume. Atlassian tells admins to reduce Marketplace JQL when a queue underperforms.

Configure queues for agent triage in Jira Service Management

Rob Hean runs Hean Tech, which teaches Jira, Jira Service Management, Rovo and Confluence, and a YouTube channel of the same name. Atlassian lists him as an Atlassian Community Champion. He also has a six-minute explainer from March 2025, Jira Service Management Queues | Explained in 6 Minutes.

At Team I sat in on his Configure queues for agent triage, Tuesday 11:00 to 12:00 on Stage 2, Hall 2. It's a Learning session, listed as "an instructor-led hands-on workshop - Laptop required". Sentiment came up too, though it isn't in the published description.

If you missed it, it runs again on Thursday 8 October at 10:00 on Stage 3, Hall 2. Otherwise, this is the part of Atlassian's docs I'd read first.

Queues are filters. Atlassian calls them "a kind of filter for your requests", by type, status or a JQL statement, and you need to be a space admin to create a new queue.

There's a hard cap: "The total number of queues is limited to 300 per service space per work category across all sections." And a queue's count refreshes up to 999 work items, then just shows 999+ (What are queues?, updated 29 May 2026).

What refreshes depends on where the queue sits. Queues in Starred and in your priority groups refresh on a regular sync. Queues under View all queues don't. One queue can sit in several groups. Starring only changes your own view: starred queues "appear only in your view and won't impact your team's work".

Rovo can also write the JQL. In Rovo Chat, /manage-queue generates the filter and the column layout. It can't delete queues or queue groups.

Atlassian's own date example doesn't validate

Atlassian's best practices for managing queues at scale is blunt, and I agree with most of it. "Often it is better to have multiple simple queues than one complex one." Text search is "the worst of all". And it says "JQL clauses provided by Marketplace apps installed on your site can sometimes be problematic. Reduce their use if a queue is underperforming." That applies to app vendors, us included.

Its tip to "Show only recent work items, e.g. use updateDate < 14d in your JQL" is the one I'd fix. Don't copy it. On our wolfaenpak test site, strict validation answers "Field 'updateDate' does not exist or you do not have permission to view it." The field is updated, alias updatedDate. Spell it updatedDate < 14d and it validates, but it matched all 23,280 work items, because 14d without a minus sign means 14 days in the future. On 7 October, updated >= -14d matched 4,693. That's the form I'd put in a queue.

Putting Jira customer sentiment into a queue with JQL

Atlassian's doc, View customer sentiment on work items (updated 29 July 2026), says the feature "uses AI to determine how customers are feeling based on the content of their request and their recent comments". The result is Positive, Neutral or Negative, shown in the Sentiment field on the work item. It's "only available for Premium or Enterprise customers that have AI enabled for Jira Service Management", and AI features aren't in the Atlassian Government environment.

Switching it on is per space:

Next to your space name in the sidebar, select More actions (•••), then Space settings.
Select Features.
Under Work item view, turn on Customer sentiment analysis.

New work items get a value automatically. Existing ones get one only "when the reporter adds a new comment". The doc names the reporter, not the agent. So on day one, your old backlog is blank. I'd tell the team that before they judge the queue. Languages? The doc doesn't say. I'd test yours before trusting it.

On status, the record is messy. Atlassian announced it in beta on 15 August 2024. From the week of 16 December 2024, Atlassian's Cloud changes blog listed Customer sentiment among the Jira Service Management AI features that "are now generally available", marked Rolling out. Today's doc carries no status label at all. That 2024 beta post is also the only Atlassian text we found that says you can "use the sentiment field in JQL to create custom queues". The current JQL fields doc doesn't list it.

So we asked Jira directly. Strict JQL validation on both test sites accepted Sentiment = Negative and Sentiment in (Negative, Neutral). The JQL autocomplete offers exactly three values: Negative, Neutral, Positive. A made-up value fails with "The following sentiment IDs are not valid: Angry". The field is searchable and orderable, with =, !=, in, not in, is, is not and the range operators.

Now what we couldn't prove. Both sites returned 0 work items for Sentiment is not EMPTY. Neither is a live desk with customers writing in, and Jira's API reports the plan only as "PAID", not which one. So I won't read anything into that zero about how often sentiment fires. We also don't know whether it uses Rovo credits. Atlassian's Rovo credits page doesn't say.

One trap from our first run. A logged-out session got "Field 'Sentiment' does not exist or this field cannot be viewed by anonymous users". The field was there. The login wasn't.

On Premium or Enterprise with AI on, I'd do this. Turn sentiment on and make a queue with Sentiment = Negative AND updated >= -14d. Put it in your triage priority group. After a week, count what it has actually caught.

More of our JSM write-ups are on the Jira Service Management topic page, and our Refined for Jira Service Management review covers the customer portal side.

The Atlassian Williams F1 car and the sim racing rigs

I saw the car in a glass-walled hall of the RAI. Atlassian's event page promised "the official Atlassian Williams F1 Team show car" and racing simulators, and both were there.

Atlassian announced the partnership on 11 February 2025, as "the Official Title Partner and Official Technology Partner" of a team "known from today on as Atlassian Williams Racing". Williams' own release adds Official Collaboration Software partner and calls the multi-year deal "the biggest partnership deal in Williams' 48-year history". Neither names a figure. In November 2025 Williams announced the new name: "From January we will become Atlassian Williams F1 Team". Its 2026 car is the FW48, driven by Alex Albon and Carlos Sainz.

The part I care about as an Atlassian admin is what the team runs on. Atlassian's Williams page says Williams "has moved from scattered tools and spreadsheets to Jira Service Management and Assets", and uses Jira Product Discovery to "connect ideas to impact". A December 2025 case study has them putting simulation knowledge in Confluence, with Rovo so engineers can "ask complex questions, surface relevant findings, and get recommendations". There was a Williams breakout on Tuesday too, Designing for flow, at 11:00 in Elicium 2. It ran at the same hour as the queues workshop, which is where I was.

Bring a problem, leave with a plan (and a smoothie)

Atlassian Professional Services had an area with the sign "Bring a problem, leave with a plan", a whiteboard of diagrams and a bike that powered a blender. There's no official page for it that we could find.

Partners we met: VMotion (Cardinal Ruler), Kantega SSO and SmartBear (BearQ)

We talked to three vendors whose apps a Jira admin might actually install. What each one makes, from their own pages:

Cardinal Ruler comes from VMotion IT Solutions, an Atlassian Gold Solution Partner based in Limerick. It's for moving Jira configuration between sites under change control. You design a change on one site and it pre-flights it against the target. Approvers sign off the frozen plan, and the record goes into a Git repository you own. It runs on Forge. Jira Cloud only. Version 2.6.0 shipped on 2 October. Per its own site, workflows deploy today. Permission, notification and work type schemes are already packaged and pre-flighted, and deploy for them "arrives in early Q4'26", so it's due about now.

Kantega SSO, based in Trondheim, was set up as a subsidiary of the Kantega consultancy in 2018. Its single sign-on apps (SAML, OpenID Connect, Kerberos) are for Data Center. On Cloud, its apps include the User Management & License Optimizer, whose Jira version 7.91.0 shipped on 21 September. Per its listing it "aids sysadmins by analyzing user activity, auto-configuring access rules, and managing temporary access for external users".

SmartBear had BearQ with them, and I thought it was excellent. SmartBear launched it on 18 March 2026 as an agentic QA system. On 16 September it became an assignable agent in Jira. You can assign work to it, mention it in comments and add it to workflow transitions, and it can record tests and results in Zephyr. Teams set the autonomy level "to meet their desired level of human oversight". The assignable agent is what I'd look at first. You can try it now.

We also had a short chat with the team from Spirit Experts.

What Forge builders can take from the queues session

We checked this section against Atlassian's pages on 7 October. An app gets into a JSM queue's contents through JQL. The jiraServiceManagement:queuePage module adds an item to the Apps section of the queues sidebar and renders its own page. It doesn't add anything inside a queue, and there's no sentiment hook. A queue's conditions are JQL, so a searchable Forge custom field, or a JQL function, is how your app shows up in triage. JSM UI modifications for the portal and agent views are Preview, not GA. We built on the portal side once, in our portal property panel tutorial.

And that same scale guide says Marketplace JQL clauses "can sometimes be problematic" and tells admins to reduce their use when a queue underperforms. If your app adds JQL, make it cheap.

Separate from the queues session, here are four Forge changelog entries part 2 didn't mention. Display conditions on the sub-pages and sections of Jira admin, global, project, project settings and personal settings pages landed on 29 September. The dashboard:filters module went into EAP on 30 September. Manual packaging for functions and UI Kit has been in Preview since 28 September, and the TypeScript bundler EAP it replaces has been removed. And on 7 October the refreshed tag, lozenge and badge look became the default, in UI Kit too, with no feature flag. EAP isn't open to everyone. Preview isn't GA. If you moved off Connect recently, also read how Cloud Fortified still probes your old Connect URL.

What we expect from the Founder Keynote

Written in the early hours of 7 October, before the keynote. The Founder Keynote, "Your business knows better", was listed for Wednesday 7 October, 09:00 to 10:15 CEST on the Main Stage. Mike Cannon-Brookes, Sherif Mansour, Tamar Yehoshua, Taroon Mandhana and Josh Miller of The Browser Company are listed. Before it started, the description promised "the evolution of Atlassian's platform, AI, and real-world stories", and the only post on Atlassian's blog on Tuesday was about its OpenAI partnership.

I'm watching for three things. Anything new for Forge and the Marketplace. Where Rovo agents land inside JSM. And any status change on the features above. Part 4 will list only what Atlassian publishes, with its label. The Founder Keynote stream needs no registration. Some other keynotes do. Atlassian's FAQ and home page disagree on whether it starts at 08:30 or 08:45 CEST, so check the hub for both.

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.

Atlassian Partner Accelerate at Team '26 Europe

Mihai Perdum — Tue, 06 Oct 2026 05:10:48 +0000

Atlassian Partner Accelerate, the partner-only day before Team '26 Europe, ran on Monday 5 October at RAI Amsterdam, and for us it was above all a day of meeting solution partners and other Forge app builders. If you build or sell on the Atlassian Marketplace, here are the numbers to know. Atlassian's schedule puts its share at 17% on Forge apps and 25% on Connect apps from 1 October 2026, and partners keep 100% of Forge revenue up to $1 million in lifetime Forge revenue. Below that you'll find the partner tiers, the Connect date that moved, and a little Amsterdam, because we did go outside.

This is part 2 of our series. Part 1 is the hub, with the dates, the agenda and the keynote times, so this part sticks to the partner day.

Partner Accelerate Europe at the RAI: the Forge builders and partners we met

Atlassian describes the day as "a focused, partner-only day of ecosystem strategy delivered by Atlassian's senior leadership before Team '26 Europe begins" (Partner Accelerate page). It ran 9:30 to 17:30, it sold out, and there was no onsite registration. Morning keynotes, then four afternoon deep dives, moving from building AI solutions to selling by industry, driving adoption and co-selling with Atlassian.

The day was about people, though. We met people from Adaptavist, from Opus Guard and from Ricksoft. Three different shapes of partner, honestly. Adaptavist is a Platinum Atlassian Partner, and its group makes ScriptRunner. Opus Guard is a Marketplace Partner that makes Content Retention Manager for Confluence and Jira. Ricksoft makes project-management apps such as WBS Gantt-Chart for Jira, and says its whole app portfolio is now on Forge.

We're a two-person company. You don't get many chances to put faces to the names you see on Marketplace listings. For us, that was the most important part of the day.

Forge and Teamwork Graph connectors: what partners saw on stage

There was a lot about Forge on the screens. One slide called Forge "Atlassian's personalization layer. Where the future gets built." I couldn't find that wording on any public Atlassian page, so take it as a line from the stage, not a published position. The public version, on About Forge, is plainer: "Atlassian's serverless app development platform".

Another slide we photographed was the Teamwork Graph one: "More connections, richer context", drawn as a map where Forge apps and Marketplace apps sit next to tools like Salesforce, Google Drive, Figma and Microsoft Teams. The slide doesn't announce anything by itself. What makes it concrete is that Teamwork Graph Connectors "are now generally available via Forge", and "customers and partners can now build their own connectors to bring data from any source", with permissions intact. That's from Atlassian's Teamwork Graph post from May. The graph:connector module is how you do it. Its reference is more careful about permissions than the post: they carry over only when the connector declares replicatesPermissions: true, and if that's false, "all ingested data is visible to every user in the Atlassian workspace". The description of one afternoon breakout lists "MCP, Forge LLM, Forge CLI, the Teamwork Graph, and Assignable Agents" as the surfaces to build on.

The Forge changelog didn't sit still around the conference either, and here the status labels matter. On 1 October the rovo:mcp module went into Preview. It lets a Forge app offer its Rovo actions as tools to custom agents in Rovo Studio and to MCP clients such as Claude Desktop, Codex and Cursor, and that external access stays off until it's enabled for each installation. Check the label on the external part, though. The changelog says it's "now in Preview", but the module reference still marks connecting third-party AI clients as EAP, "not recommended for use in production environments". On 2 October the rovo:skill module moved from EAP to Preview, and the Forge LLMs limit went from 50,000 to 500,000 tokens per minute, per installation and per model. The rovo:agentConnector module, which connects an agent hosted outside Forge to Rovo over A2A, reached GA on 28 September. And on 6 October, the day this goes out, Confluence static macros moved from EAP to Preview. Preview isn't GA. Atlassian calls it suitable for early adopters in production, so read the entry before you build on one.

Atlassian Marketplace revenue share for Forge apps after 1 October 2026

This is the part I'd want if I were you. Atlassian's extended timeline post (3 November 2025) sets its share at 16% for Forge and 20% for Connect from 1 April 2026. From 1 October 2026 the same post moves them to 17% for Forge and 25% for Connect. If you're still on Connect, that's an eight-point gap.

Atlassian's pricing and billing docs say the same thing from the partner's side. You receive 83% on a Forge app and 75% on a Connect app, and the page still says "will change" even though the date has passed. To count as Forge, an app must contain no Connect modules, use OAuth authentication and use Forge UI.

Then there's the Forge incentive: "As of 1 January 2026, partners will receive 100% of gross revenue earned on Forge, up to $1 million in lifetime Forge revenue." That limit counts per partner, not per app. Atlassian's May 2025 post calls the 0% incentive "temporary" and promises at least six months' notice before changes to standard rates. Apps with the Runs on Atlassian badge got a three-month head start on it. I wrote about what Runs on Atlassian means for Sentinel Vault on 2 October.

The Connect date moved too. Atlassian's August 2026 post extends end of support for Jira and Confluence Connect apps "from December 2026 to January 31, 2027". After that, "Atlassian will only address critical security patches." If you've migrated already, check the leftovers. Mihai wrote up how Cloud Fortified still probes your old Connect URL after a move to Forge.

Atlassian Marketplace Partner Program tiers and what they ask in Forge revenue

The program page has three levels: Silver, Gold and Platinum. They're set on revenue, security and trust compliance, and customer support. The cloud gross sales minimums are $150K, $750K and $3M a year. Gold also needs at least $10K a year from Forge, and Platinum $150K. Platinum asks for SOC 2 Type 2 or ISO 27001:2022 and a third-party validated Trust Center.

One caveat. That page says "Last updated May 28, 2025", and Atlassian reserves the right to change the requirements. Read it yourself before you plan around a number.

There's a new trust programme to know about too. On 1 October Atlassian launched Atlassian Enterprise Certified (AEC), for apps that meet enterprise needs on compliance, security, reliability, privacy, accessibility and responsible AI use. It's open to eligible Forge cloud apps, and partners apply with their evidence. Cloud Fortified is on its way out. It stopped taking submissions on 1 September and will be retired on 31 December 2026.

On the services side, Solution Partners also come in Silver, Gold and Platinum, with specializations such as Cloud Migrations and Service Management. Atlassian's partner program page says the program "is by invitation only at this time".

Sharing LeanZero by QR code at Partner Accelerate

We also used the day to get people to know what LeanZero builds. We did that with the new share dialog on our site, a QR code for each thing we make. We merged it on the Monday morning. You'll find it as a small QR button in the header of leanzero.net.

It opens a share dialog, full screen on a phone, with one large QR code and a list of what you can share. There's the page you're on, our home page, each of our three Marketplace apps and every product page, 20 codes in all. The Marketplace codes use the short marketplace.atlassian.com/apps link, so they're less dense and scan from further away. The Full screen button, or a tap on the code, shows a plain white code and asks the phone to keep its screen on. Below the code you get Open listing (or Open page), X, LinkedIn and Copy link. Try it on your phone.

Amsterdam after Partner Accelerate: a tall ship, the Munttoren and NEMO

Now the lighter part. We'd flown in at sunrise.

The tall ship is the replica of the East Indiaman Amsterdam, moored at Het Scheepvaartmuseum since 1991. The original was built for the Dutch East India Company in the 18th century. The museum behind it is housed in a former naval storehouse, built in 1656.

We also saw the Munttoren on Muntplein. It was once part of a medieval city gate, and it got its spire in 1620. Then there was NEMO, Renzo Piano's copper-green science museum, which looks like it's rising out of the water at dusk. And the canal houses, which are worth looking at one front door at a time.

And we stopped at a bruin café, a brown bar, the kind of traditional Dutch pub I amsterdam calls "a quintessential part of Amsterdam's culture".

What we're watching at Wednesday's Founder Keynote

The Founder Keynote, "Your business knows better", is on Wednesday 7 October at 09:00 CEST. The hub has the livestream times, including where Atlassian's own pages disagree. We'll be listening for anything new on Forge, on Teamwork Graph connectors and on the Marketplace, because those decide what we build next. We'll see on Wednesday. Part 3 will cover the keynote announcements.

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.

Claude Sonnet 5.5 vs Opus 5.5 vs GPT-6.1 Sol

Mihai Perdum — Mon, 05 Oct 2026 07:01:38 +0000

Claude Sonnet 5.5 edged Claude Opus 5.5 on our general-programming benchmark, a payments app, 0.7984 to 0.7926, a margin I read as level. It built the better app, though: it earned 0.9894 to Opus's 0.8732 before a ceiling squeezed them together. Then Opus 5.5 outclassed it on an Atlassian Forge app, 0.9767 to 0.5508.

Same two models, same goose, same 150-call budget, same week. The order flipped and the gap went from 0.0058 to 0.4259. And each model took exactly one critical defect, each on the other's home ground. Two settings did differ between the boards, reasoning effort and internet access, and I come back to both.

I think the reason is the most useful thing on our benchmark boards right now. Gauntlet asks for a kind of app that's all over the public internet. Forge asks for an app on a niche platform that changes month to month, and the model builds it with no internet. One measures a generalist. The other finds out who studied.

Below is every check behind both results, GPT-6.1 Sol and Sol Pro on the same boards, how the benchmarks grade a running app, and then the other thing we did this fortnight: trying to make our own specialist, a fine-tuned 27B model, with the whole bill.

Claude Sonnet 5.5 vs Opus 5.5 benchmarks, with GPT-6.1 Sol on both boards

These are the boards as of Monday 5 October, 04:59 CEST. Runs are still landing, so the Gauntlet board and the Forge board are the current word, not this table.

model	Gauntlet 7.2	Forge 1.0
GPT-6.1 Sol Pro	0.9574	0.9664
Claude Sonnet 5.5	0.7984	0.5508
GPT-6.1 Sol	0.7978	0.9769
Pareto 26.10 Preview	0.7957	—
Claude Opus 5.5	0.7926	0.9767
MiMo-V2.6-Flash	0.7909	0.7919
Jev Router	0.6975	0.7978
DeepSeek Pro Latest	0.6591	—
GLM 5.3 FlashX	0.6303	—
DeepSeek V4.1 Flash	0.5910	0.3354
GPT-6 Luna	0.4797	0.3950
Qwen3.8 Omni Flash	0.4269	0.5529
GLM 5.3	0.1443	0.0292
GPT-6 Luna Pro	0.1343	—
Qwen3.8 27B	0.0915	0.1582
Solar Mini 4	0.0083	—

Sixteen runs on Gauntlet, eleven on Forge. Every one is a single model through OpenRouter, driven by goose, our fork of the open-source agent Block started. Jev Router and Pareto 26.10 Preview are typesafe/jev-router and unbiased/pareto-26.10-preview there. Qwen3.8 27B, OpenRouter's name for Qwen3.8-27B, is the untouched base model our own fine-tune starts from, as OpenRouter serves it. Its two runs, and GLM 5.3's Gauntlet run, landed overnight. Two settings differ between the boards: Forge pins reasoning effort to medium and cuts the building model off the internet, while Gauntlet runs each model at its default reasoning effort with the network open. Call counts for the Claude and GPT runs in this post include one short Gemini call that shows up in each of their telemetry.

One caveat, said once and meant for the whole piece. Each model has one run per board. Under an earlier scorer version, one model on the same host scored 0.799 on one run and 0.505 on the next. So I read 0.7984 against 0.7926 as level, and 0.9767 against 0.5508 as a real difference in this run, with a cause the scorer writes down. Would Sonnet hit that double-click again on a second run? One run can't tell you. Without it, the gap would still be about 0.08.

If you only want the one-line advice for Forge work, three runs scored above 0.96: Sol, Opus and Sol Pro. Jev Router earned 0.9762 too, but a check I think misfired capped it, and it published 0.7978 (more on that below).

Twelve things the two boards and our training round showed

Each one is argued further down.

The same two models can swap places when the task changes. Sonnet edged Opus on the payments app and lost to it by 0.43 on Forge.
On Forge, the hard plumbing was a tie. Sonnet and Opus both scored 1.00 on the event pipeline, reconcile, storage, Rovo and lint tiers. Everything Sonnet lost, it lost at the edges: one button, one modal, one LLM feature.
The scorer saw Sonnet's app make no Forge LLM call, and Forge LLM's catalogue is all Claude. A Claude model built an explain button that was meant to ask a Claude, and the question never arrived.
Idempotency is general programming, and Sonnet knows it. Idempotency-Key on 3 of 3 payment sends; 0 comments on 2 of 2 double-clicks. Same idea, different room.
A ceiling compresses everything. Sonnet earned 0.116 more than Opus on Gauntlet and finished 0.0058 ahead.
Sonnet and Opus write essays and GPT-6.1 Sol writes telegrams. On Gauntlet, Sonnet generated about 6,100 tokens per call, Sol about 530, and they finished 0.0006 apart.
Pro won one of the three Pro-versus-plain match-ups we have. GPT-6.1 Sol Pro won Gauntlet outright, lost Forge to plain Sol, and GPT-6 Luna Pro scored under a third of plain Luna.
A scorer can flatter itself by accident. On Saturday three different builds sat at exactly 0.7990. That was our bug, and the re-score fixed it.
Our 96 GB Mac Studio can't fine-tune this 27B model on goose sessions. The measured ceiling is 12,288 tokens, and goose's fixed prompt alone is 32,569.
A fine-tune inherits its parent's manners. T10's 35,412 training rows held no forum-style greeting, and it still greeted people by invented forum handles, because T9 had.
The last gate is the one that counts. Our fine-tune had been chosen and was in release when a Forge app-building gate, run for the first time, found it built a complete app 9.7 times in 35. A fix round got it to 27.3, still under T9's 30, and it shipped with that gate waived.
Renting GPUs to fine-tune this one model wasn't worth it on its own. $1,051.87 bought a model level with its predecessor on Atlassian multiple choice, behind it on Forge questions and better at tool calls; the predecessor took a day on a Mac we already own. Most of that money went on the round that didn't ship and the pipeline it ran on, and the next generation should cost a fraction of it.

Sonnet 5.5 vs Opus 5.5 on a payments app: a 0.0058 edge, and the better app

Gauntlet 7.2 asks for the Meridian Payments Console. Two cooperating services sync 12,288 payments from a mock vendor API, keep them consistent through webhooks, concurrent edits, crashes and partitions, and run a maker/checker approval workflow that creates real vendor payments. On top sits a console with a payments table, a notifications feed, a drafts panel and an interactive 3D field of payment towers. The 3D work carries 46% of the core score, and a browser probe checks it pixel by pixel.

It's a big app. It's also, in shape, a very familiar one: services with sync, webhooks, an approval flow and a dashboard. Every model on the board has read thousands of those.

Here's the pair side by side, from the run documents.

	Claude Sonnet 5.5	Claude Opus 5.5
earned, before the ceiling	0.9894	0.8732
critical multiplier	1.0000	0.8857
ceiling	0.799	0.799
check that set the ceiling	overview legibility	label culling
model calls	54	63
tokens generated	329.3k	272.6k
model build time	51m 16s	56m 48s
final	0.7984	0.7926

Sonnet's build earned 0.9894, the highest earned score on the board. That's above GPT-6.1 Sol Pro's 0.9574, the run that won.

Opus's build earned 0.8732. Most of that gap is one critical: a defect bad enough to multiply the whole score by a factor, down to a floor of 0.6. The full rules are further down.

Opus's app approved the payment and it never showed up

The scorer walks the approval workflow the way a person would. Log in as a maker, create a draft, submit it, log in as a checker, approve it, then look for two things: a notification, and the new payment in the table.

Sonnet's app passed all seven steps. Opus's passed five. Its approval went through, and the scorer then found neither the notification nor the payment in the table. The run page puts it in one line: "approval completed, but the created payment did not appear in the UI table".

That journey is a critical, because it's the thing a payments console is for. It multiplied Opus's score by 0.8857. The reject path had the same gap: rejected and listed, but no notification. Sonnet's showed one.

So on the part of the app a finance team would actually use, Sonnet built the better product.

Sonnet's 3D field ran off the edge of the frame

Then the 3D field. Both models built a working, interactive field of towers, and both lost exactly one ceiling check there.

Opus's labels failed a culling check: at the decisive camera pose, the set of labels on screen didn't match the set that should be visible. It scored 0.64 on that row.

Sonnet's failed overview legibility, at 0.8333. Its towers covered 0.6765 by 0.7351 of the canvas, and 104 tower pixels sat on the canvas edge. The probe reads that as a field that doesn't fit its frame. Opus's had 0 edge pixels. Sonnet's towers were also lower-contrast, 3.11:1 against Opus's 4.71:1, but GPT-6.1 Sol Pro passed this check at the same 3.11:1, so the edge pixels are what cost Sonnet the row.

Sonnet's other misses were small and specific. A forged webhook should bounce with a 401; the scorer recorded no status for Sonnet's app at all, though the forged change was left untouched. Its timezone buckets were exact in 380 of 384 cells. One of four text groups didn't put enough visible text on screen to read. Its written design decisions scored better than Opus's, 0.83 against 0.67.

I count that as Sonnet ahead on the product and Opus ahead on the picture. On a benchmark where the picture carries 46% of the core score, that should have been close. It was.

A ceiling turns a 0.116 lead into 0.0058

Sonnet earned 0.116 more than Opus and finished 0.0058 ahead.

That's the ceiling doing its job. Gauntlet's ceilings come in bands: miss a visible scene and the run is capped at 0.599, miss correct geometry at 0.699, 3D interaction or overview legibility at 0.799, event animation or full backend recovery at 0.899. Each further miss in a band takes another 0.03 off, never below the next band down. Passing a band adds nothing. Failing one caps you.

A capped run doesn't sit exactly on its cap. It lands a little under it, by 0.05 times whatever it didn't earn: final = ceiling minus 0.05 × (1 minus earned). For Sonnet that's 0.799 minus 0.05 × 0.0106, so 0.7984. For Opus, 0.799 minus 0.05 × 0.1268, so 0.7926. Gauntlet cuts its finals to four decimals rather than rounding them.

So under one ceiling, every 0.1 of earned score is worth 0.005 of final score. I think that's right, and I'd defend it. You can't buy your way past a 3D problem with backend points, and a model that misses the brief's visual bar shouldn't outrank one that clears it. But it's why the top of the board looks like a photo finish.

Essays and telegrams

One more contrast, the one I least expected. GPT-6.1 Sol hit the same ceiling as Sonnet, overview legibility, plus a backend recovery check. It earned 0.9768 and published 0.7978, 0.0006 behind Sonnet.

It got there in a completely different way. Sonnet made 54 model calls and generated 329,286 tokens. Sol made 106 calls and generated 56,390. That's about 6,100 generated tokens per call for Sonnet and about 530 for Sol. Opus sat between them at about 4,300.

Sonnet's average turn is a short chapter. Sol's is a paragraph, and it takes twice as many of them. Both styles got to the same place on a payments app. Sol also did it in 26 minutes against Sonnet's 51.

The token count matters for your bill, which I'll come back to. For the score, on this kind of task, it didn't. I'll take either style.

Opus 5.5 vs Sonnet 5.5 on Forge: the specialist, 0.9767 to 0.5508

Forge 1.0 asks for the Scope Ledger. It's a Jira app for agile coaches who want to know what entered a sprint after it started, who added it and how many story points it carried. It has to work on a Jira dashboard, from the sprint's own action menu and from Rovo. That's 10 Forge module types plus the Realtime API, and Forge LLM and Realtime are mandatory.

The model gets no internet. It gets a dev kit with Forge's own linter, the pinned packages and their typings, the manifest schema, Jira's OpenAPI spec and a mock Jira site it can run its app against. Everything the scorer measures about the platform is in there somewhere. What isn't in there is a tutorial, or anyone telling it how.

Opus built an app that scored 0.9767 with no ceiling, no critical and every correctness tier at 1.00. Sonnet's scored 0.5508.

Here's every tier, with GPT-6.1 Sol for reference. The weights are the share of the core score.

tier	weight	Sonnet 5.5	Opus 5.5	GPT-6.1 Sol
L lint and bundles	.08	1.00	1.00	1.00
K platform currency	.10	0.90	1.00	1.00
T event pipeline	.16	1.00	1.00	1.00
R reconcile	.14	1.00	1.00	1.00
S storage	.08	1.00	1.00	1.00
B resolvers and permissions	.12	0.83	1.00	1.00
U UI function	.16	0.80	1.00	1.00
V visual	.08	1.00	1.00	1.00
A Rovo	.08	1.00	1.00	1.00
core score		0.938	1.000	1.000
critical multiplier		x0.60	x1.00	x1.00
final		0.5508	0.9767	0.9769

Look at the middle of that table before the bottom. On the event pipeline, reconcile and storage, the parts of a Forge app that are actually hard to get right, Sonnet and Opus are twins.

Each run gets its own seeded Jira site, so the counts differ, but the verdicts don't. Sonnet handed 47 of 47 event deliveries to the queue correctly, Opus 40 of 40. Both recorded every live change exactly, duplicated and out-of-order deliveries included. Both parsed every Sprint changelog value that carries several sprint ids in one string (29 for Sonnet, 14 for Opus), which is a Jira quirk most people find out about in production. Both waited out a 30-second Retry-After inside the invocation, 30.2 and 30.3 virtual seconds, which the contract accepts alongside handing the retry back to the platform with a delay. Both found every issue that had been removed from every sprint, healed all 4 dropped events on the second scheduled run, and wrote nothing at all on a run with nothing new. Neither leaked a hidden issue to anyone.

On the event pipeline, reconcile and storage, you couldn't tell the two apps apart by score. I'd have taken either one's plumbing.

Sonnet lost 0.4259 in three places, all at the edges. One button, one modal, one LLM feature. To be straight about the arithmetic: its core score was 0.938 against Opus's 1.000, so most of the gap is one multiplier, the x0.6 from the double-click. By my arithmetic, fixing only that would have put it around 0.896, still about 0.08 behind Opus, mostly because of the LLM miss below, with the modal close and the comment flow making up the rest.

GPT-6.1 Sol vs Claude Sonnet 5.5 on Forge: a double-click that posted nothing

The sprint action opens a modal with a table of every change. You select a row and post a summary comment on that issue. The contract says a double-click must post exactly one comment, because people double-click, and a Forge app that comments twice on a customer's Jira looks broken.

The scorer double-clicked Sonnet's post button on two sprints. Nothing got posted either time: zero comments, zero success flags. Zero fails "exactly once" just like two does.

The check is a critical. Its label reads "duplicate side effect on a customer's Jira", and for an app that posts comments at all, any failure costs the full 0.6. 0.9180 times 0.6 is 0.5508.

Single clicks worked. All 4 of Sonnet's comments from single clicks were valid Atlassian Document Format, posted as the viewer, naming the issue key, the sprint and the creep. The scorer posts once with a single click, which worked, then double-clicks the same button on the same row. Sonnet's app posted nothing for the double-click, and showed no success flag. Either it refuses a second summary for an issue it has already commented on, or it clears the selection or disables Post after posting, so the double-click hit a dead button. I can't tell which from the scorer's rows. I haven't traced it in its code, and I haven't reproduced it by hand on a real Jira site.

Idempotency isn't Forge knowledge. It's the most general-programming idea in the whole task. And on Gauntlet, the same model's payments app sent an Idempotency-Key on 3 of 3 payment sends and reused it on the retry. Sonnet knows the idea cold. It just didn't land it on a Forge Custom UI button.

Qwen3.8 Omni Flash hit the same critical on the same check, 0.9214 down to 0.5529. Opus and Sol both passed it: 6 click and double-click posts, each with exactly one comment and one success flag, a forced rate limit included.

No Forge LLM call the scorer could see

The second miss is the one I find most interesting.

The sprint modal has an "explain" feature. The app is supposed to ask Forge LLM, Atlassian's hosted model API, to explain the sprint's scope creep, using a tool call so the answer comes back structured. Then it has to distrust the answer. The scorer's mock LLM answers five times in a row: a clean answer, one stuffed with made-up numbers and a hidden issue's id, a refusal, malformed tool arguments, and an API error. A good app shows the first, sanitises the second, and puts up an error flag for the last three without breaking the modal.

Forge LLM's catalogue is all Claude. Atlassian's models page says it "supports Claude models across three tiers: Haiku, Sonnet, and Opus", and lists eight ids, among them claude-sonnet-5 and claude-opus-5.

Opus's app made 5 LLM calls and passed 23 of 23 explain steps. Sol's did the same.

Sonnet's app had an Explain button, and the scorer clicked it five times. No call reached Forge LLM. Its explain check scored 0 of 5, and the model-id check had nothing to inspect, so it scored 0 as well.

So a Claude model built a Forge app whose explain button was supposed to ask a Claude model something, and the question never arrived. It isn't a joke at Sonnet's expense, and I can't tell you why it happened. Whether the code never asks, or the button never reaches its backend (its Close button never reached the bridge either), the scorer's rows don't say. And it isn't simply that Forge LLM is new. It went GA on 30 July, after an EAP and a Preview, and Sonnet handled the even newer modules, the dashboard widget, its edit bridge and the Rovo skill, without a scratch.

Those two LLM rows count as one defect in the robustness band, and the double-click is the second. Two defects cap a Forge run at 0.869. One defect caps it at 0.899, which is why the fixed-double-click version still lands under 0.9.

And a modal that wouldn't close

The third miss is small and very Forge. A Custom UI modal closes by calling the bridge's close. The scorer clicked Sonnet's Close button three times on its worst site, and none of the clicks reached the bridge. On a different one of its three sites, two of its ten comment-flow steps failed.

Opus and Sol: 3 of 3 closes, 8 of 8 comment-flow steps.

The screenshots show design differences too. Opus put the sprint totals in five cards and its buttons above the table, and printed dates a person can read. Sonnet put its totals in one line above the table, its buttons under it, and printed raw ISO timestamps. On a sprint with a long ledger, Sonnet's first screen is all table.

The one row where Sonnet beat both winners

To be fair to Sonnet, there's one row where it beat both Opus and Sol.

Excellence includes event economy: how many Jira calls the event path makes against the fewest it could get away with. Full credit stops at 1.46 times the optimum. Averaged over its three sites, Sonnet's app made 99 calls where 31 would do, 3.19 times. Opus's made 90 where 27 would do, 3.33 times. Sol's made 98 where 28 would do, 3.50 times.

So the model that lost by 0.43 was the most economical of the three on the one row where the winners lost points. It also built fastest of the Claude pair: 16 minutes 15 seconds, against Opus's 26 minutes 28.

GPT-6.1 Sol vs Claude Opus 5.5: 0.0002 apart on Forge

Opus is the closest thing to a tie on either board. Its Forge app had no ceiling, no critical and every correctness tier at 1.00. Like Sol's, it lost points only on event economy. Both passed the double-click that sank Sonnet.

Final 0.9767 against Sol's 0.9769. The whole 0.0002 is inside the excellence slice: Sol's excellence mean was 0.8075, Opus's 0.8057. That row averages three per-site scores, so its call ratios and its score don't line up exactly. I'd call it a tie. I won't lose sleep over 0.0002.

The two got there at different speeds. Sol built its app in 13 minutes 12 seconds. Opus took 26 minutes 28. Both wrote a Rovo skill that passed every instruction check, and both declared their storage index exactly the way the contract asks.

On Gauntlet, Sol and Opus were 0.0052 apart, both under the same 0.799 ceiling. I'd call them level on both boards. If I needed a Forge app tomorrow, I'd be happy with either, and I'd pick on price and speed.

The other ways to lose a Forge run

Two more Forge runs show the rest of the failure map.

Jev Router earned 0.9762 and published 0.7978, because its sprint-not-started view, one line and a button on an empty page, read as blank to the theme check, and that's a ceiling check: a screenshot that's 99.5% one colour counts as blank. Looking at the screenshot, the view is fine. I count that one as a false positive in our scorer, and it cost nearly a fifth of the score.

GLM 5.3 scored 0.0292. Its manifest pointed at UI build folders that didn't exist, and its backend wouldn't even bundle, because it assigned to a constant. Neither of its two functions loaded. Nothing downstream had anything to check.

GPT-6.1 Sol Pro vs GPT-6.1 Sol: Pro won one board, not the other

GPT-6.1 Sol Pro scored 0.9574 on Gauntlet, the only Gauntlet run with no ceiling at all and the only one marked excellent. It used 44 of its 150 calls and finished in 21 minutes. That's the fewest calls and the shortest build of the four frontier Gauntlet runs in this post.

It wasn't flawless. Its error state showed an error but gave you nothing to do about it, it skipped an optimistic paint, and it didn't reuse its idempotency key on a retry. None of those is a ceiling check, so they cost points, not a cap.

On Forge, plain GPT-6.1 Sol beat it, 0.9769 to 0.9664. Both lost only on economy. Sol Pro's backfill made 18 Jira calls where 15 would do, and its event path 3.62 times the optimum.

I wouldn't pay for Pro on faith, though. GPT-6 Luna Pro scored 0.1343 on Gauntlet against plain GPT-6 Luna's 0.4797. Its app never finished a first sync: when grading started its store held 0 payments. Two criticals, the sync and the approval journey, compounded to a multiplier of 0.3606.

Why a generalist slips on a niche framework

I want to be careful here. One run per model can't prove a theory about a model. But the pattern in the check rows is specific enough to be worth saying out loud.

Gauntlet is a big app built out of common parts. Sync loops, webhooks, idempotency keys, approval flows and a WebGL scene are all over the public internet. A model that writes good general code does well, and the four runs behind GPT-6.1 Sol Pro (Sonnet, Sol, Pareto and Opus) finished within 0.006 of each other.

Forge is a small app built out of rare parts. A few dates from Atlassian's changelog and npm, all checked on Sunday:

Forge LLM went generally available on 30 July 2026.
rovo:mcp reached Preview on 14 August, and on 1 October it got a Preview that connects a Forge app's tools to external AI clients.
The new dashboards:widget module went GA on 22 September, and the old jira:dashboardGadget was marked deprecated the next day, to be removed on 17 May 2027.
@forge/dashboards-bridge 2.0.0, the package a widget's edit view saves through, was published on 28 September.
rovo:skill reached Preview on 2 October. Sonnet's run started on 4 October.

That's what the benchmark is built around. The design rule is to test recall of HOW, never of WHAT. The contract tells the model what to build, module keys included. It never restates Atlassian's docs. Everything else has to come from the model's own knowledge or from reading typings, schemas and an API spec inside a sandbox with no internet.

The design bets that a model that already knows the platform spends fewer calls and makes fewer defects, and that one which has to read its way in can still reach 1.0. Sonnet got to a correct ledger, a working widget, a Rovo skill and an MCP server. Where it ran short was Forge LLM, the bridge's modal close and one interaction bug. Not the newest modules, which it got right. So newness alone doesn't explain it, and I won't pretend it does.

Opus didn't run short anywhere. That's what I mean by a specialist: on the platform's own terms, it didn't drop a single correctness check. I don't know how much Forge each model saw in training, and nobody outside the labs does. I only know what each one built in a room with no internet. And specialist doesn't mean weaker at general work: on Gauntlet, Opus was level with Sonnet. What split them is that Sonnet's general skill didn't carry over to Forge in this run, and Opus's did.

And there's an irony I'll own. Our own fine-tuned model, further down this post, needed two Forge boosters, one to answer Forge questions and a late one to build Forge apps reliably, and its predecessor still beats it on both.

Two agentic coding benchmarks, graded offline in a real browser and an emulator

Both benchmarks share one loop, and I think the method is the most reusable thing we built.

A model gets one realistic product task, a budget of 150 model calls and no human help. When the budget is spent, or the model says it's done, whatever exists gets scored. Nobody reads the code to grade it. Apart from Forge's linter and static rules on the manifest and source, the scorer runs the app.

Scored, not refused

An empty or half-built app gets a score, never a refusal. That sounds obvious and took real work. A check whose precondition isn't met, say a "no duplicate comments" check on an app that never posted a comment, scores 0 instead of passing for free. Without that rule, by the Forge design's own arithmetic, an app that did nothing would have collected about 0.08 from all the "nothing went wrong" rows. With it, the empty starter scores 0.0 and an app with one do-nothing function scores 0.0051.

Graded offline in a real browser

Gauntlet's scorer starts both services against a fresh mock vendor, drives the console in a real browser, and records it. It kills processes mid-sync, partitions the network, forges webhooks, replays events out of order, and then reads the store, the API and the screen. The 3D field is checked by pixels and by the scene's own reported state, at several camera poses.

Forge's scorer does the same in an emulator. App code runs inside Atlassian's own Forge runtime wrapper, fetched from Atlassian's public CDN and pinned by sha256. If the hash doesn't match, the scorer refuses to run rather than fall back. There's an in-repo stand-in for developing the harness, and a verdict produced with it is marked unpublishable.

Every invocation runs under a deny-by-default macOS sandbox. App code can't read the scoring seed, can't spawn processes and can only reach the mock Jira site through the emulator's proxy. The proxy logs every call, and the scorer grades from that log.

The Custom UI is rendered in a bundled Chromium in light and dark, the widget at 380 and 1,180 px, with video recorded. The recording's SHA-256 is printed on the run page.

No internet on Forge, measured

On Forge, the building model gets no internet either. We measured the fence before trusting it. Inside the sandbox profile, curl https://developer.atlassian.com/ returns 000, a Node fetch to the npm registry fails with EPERM, and a server on 127.0.0.1 answers 200. goose still has to reach the model provider, so the harness runs a relay outside the sandbox whose allowlist is exactly one host: the provider's.

Without that, the newest-module checks would measure who fetched today's docs, and runs wouldn't be repeatable, because docs move.

Three seeded Jira sites, and the worst one counts

Each Forge run is scored on three freshly seeded Jira sites. Correctness keeps each check's worst site; excellence takes the mean. The model builds against a dev site with a different seed, so it can't memorise the numbers.

The sites are mean on purpose. Here's the trap list, every one a check:

Issues removed from every sprint, which a reconcile using sprint in openSprints() never sees.
Two estimation fields whose ids change per site, so a hard-coded customfield_10016 fails.
Parallel active sprints, for code that assumes "the" active sprint.
Sprint changelog values with several ids in one string.
Duplicate deliveries, each with a fresh event id, so deduplicating by event id doesn't work.
Out-of-order and dropped events.
The removed /rest/api/3/search, which the mock site answers with 410.
429s with a Retry-After of 30 seconds on the event path and 2 on the reconcile.
LLM output trusted as-is, an unknown model id, or temperature and top_p copied from the Forge LLM README. Sending both is rejected for every model, and either one for four of the Claude ids.
Calling publish() from a queue consumer, which the docs say isn't supported for async events (they send that code to publishGlobal).
Issue data broadcast on a global Realtime channel.
Reading person-facing data as the app instead of as the user, so hidden issues leak.
A double-click that posts two comments.
A plain-string comment body, which Jira rejects with "Comment body is not valid!".
Stale platform knowledge: jira:dashboardGadget, storage from @forge/api, the nodejs18.x runtime, @forge/ui.
Saving widget config through a resolver instead of the dashboards edit API.
Absolute asset paths, inline scripts and CDN fonts, which go blank under Forge's Content Security Policy.
Hard-coded colours that vanish in the other theme.
Reading changelogs one issue at a time across 237 issues, about 480 calls where about 12 would do.

People are already asking AI to write Forge apps, and these are the failures that only show up when the app runs. The clearest public example I found is an Atlassian Community write-up from August, vibe coding a WIP limit app with Rovo Studio. The generated app moved to the new search endpoint and lost the total count it needed, passed a maxResults: 0 that the author, reading the REST docs, found is illegal, and allowed the transition on any API error. So its first version deployed and enforced nothing. The author found that by testing it, listed "The validator itself is not preventing the transition." under what didn't work, and then fixed it with their own Forge and REST knowledge.

I couldn't find another public benchmark that has a model build a Forge app and then runs it.

Criticals, ceilings and why two models can't tie on a cap

I lean on two terms for every score on both boards.

A critical is a defect bad enough to multiply the whole score, down to a floor of 0.6. Forge has seven: an app that won't deploy, bundles that don't load, a change counted twice, changes silently missing after a backfill, a hidden issue shown to someone, a duplicate side effect on Jira, and a dashboard that shows no data. Some are graded by how badly they failed; the double-click costs the full 0.6 on any failure, as long as the app posts comments at all. Several criticals compound.

A ceiling caps the score when a required check fails. Forge's bands are deployable 0.499, a working ledger 0.699, current platform and complete surfaces 0.799, and production robustness 0.899, minus 0.03 for each further defect, never below 0.799. Nineteen checks sit in that last band, and a defect that knocks out several of them counts once.

What a build scores after criticals but before its ceiling is its earned score. If no ceiling bites, that's the final. If one does, the final sits just under the cap: ceiling minus 0.05 times (1 minus earned).

That last rule exists because of a bad Saturday.

Every run was re-scored on Sunday, and the ties went away

On Saturday three different models sat at exactly 0.7990 on Gauntlet. That looked like a coincidence. It was the scorer. The bands capped a run at a flat number no matter how much of a band it failed, and several probe checks were broken. One demanded the word "collar" where the contract says "Hollow currency frame". Others clicked the 3D canvas without aiming at it first.

goose 3.0.92 fixed that on Sunday morning. The bands are now graded, a capped run keeps its own gradient, Forge grades event handling against the true optimum on three sites, and the 3D probe waits up to 480 s instead of 230 s, because real builds took 258 s and 281 s and were being refused instead of scored. Then every saved build was re-scored and republished over its own entry, so every number in this post comes from the same scoring rules. The two Gauntlet runs that landed overnight were scored by later patch releases. Those only turn a build 3.0.92 would have refused into a low score. Nothing else changes.

The three 0.7990 runs are now 0.9574, 0.7978 and 0.7957. I wrote about how a scorer that can't flatter itself works in August. It still gave three different builds the same number. That's the bit I got wrong, and the re-score is the fix.

Before a Forge scorer version is used at all, a freeze gate has to pass. A reference app scores 1.0 on all three scoring sites, an empty starter 0.0, and the scoring thresholds are pinned by hash. On Sunday we re-checked the pin: the thresholds file's sha256 matches the constant in the scorer. There are also 31 deliberately broken copies of the reference app, each with exactly one defect, and each has to lose exactly the checks it's supposed to.

The app publishes its own scores

There's no submission form on our site. Results are posted by the goose desktop app over the site's API, and each run page shows the scorer's per-check output exactly as the app posted it, with the screenshots and the graded browser recording.

That's deliberate. I don't trust a board that only shows a number, and I don't expect you to. This one shows its working: open any run, expand a tier, and every check has its measured detail. When a scorer fix lands, "Re-score saved build" in the app republishes over the existing entry, so the board never carries a stale twin, and the page says it was re-scored.

If you want to check anything in this post, I'd start with Sonnet's Forge run. Open "Resolvers and permissions" in the scoring detail and the "0 comment(s)" line is the double-click check.

What a benchmark run costs on OpenRouter: the bills we have, and the ones we don't

Cheap enough to run every week, at least for the runs I have bills for, which was the point. My brief for these benchmarks said they "need to be cheap, economically viable", or we can't run them consistently.

The ten builds I hold OpenRouter bills for cost between $0.10 (Solar Mini 4) and $2.62 (GLM 5.3 FlashX), $9.53 together. GPT-6.1 Sol's Gauntlet build, a frontier model, billed $1.28 for 106 calls. I don't have bills yet for the other seventeen runs, among them both Sonnet runs, both Opus runs and both Sol Pro runs, so that's a lower bound, not a guess.

The token counts give you the shape, though. On Gauntlet, Sonnet read 7.06M prompt tokens and wrote 329k. Opus read 5.81M and wrote 273k. Sol read 5.40M and wrote 56k. Output tokens are priced above input tokens on these models' price lists. But the essay writers also read more. How much more they cost per run depends on caching, which is the next story.

Part of why these runs are cheap at all is a goose fix. goose used to rewrite the end of every request with the time, the working folder and a context-usage line, so GPT-6 models through OpenRouter never read the prompt cache. On one GPT-6 Luna run, 0 of 20.5M input tokens came from cache. After the fix, Luna's Gauntlet run, which spent its whole 150-call budget, billed $0.23.

A prompt cache only works if each request extends the previous one byte for byte. goose replaced last turn's context lines instead of leaving them where they were. Now it keeps them in the history and appends a new one only when something actually changes.

LLM fine-tuning cost: $1,051.87 to make our own specialist, and the first round didn't ship

Every model above is a cloud API. The other half of our fortnight was trying to make our own specialist: a local model trained for Atlassian and goose work. Neither of our fine-tunes is on these boards yet, and on Forge questions the newest one still trails the model it replaces. Here's what it cost to get it published, and everything that went wrong on the way.

Three names, because they're how the work was tracked. T9 is our published Qwen3.8-27B Atlassian v0.5, which the new model's card calls v1. T10 is the round that never shipped. T11 is the restart, published on Monday morning as Qwen3.8-27B-Atlassian-v2-goose.

T10's goals were better tool calling inside goose, keeping the Atlassian knowledge, my writing voice when a persona prompt asks for it, and never inventing people. That last one turned out to be the whole story. I said it on 2 October, when a run's replies started greeting people who don't exist: "does it still call fake names? That is a deal breaker."

The bill, in one line: the whole effort, T10 and T11, cost $1,051.87 before tax, $1,269.50 with AWS's VAT. The first plan said $100 to $160.

T10's round on its own came to $850.50 before tax, $1,025.83 with VAT, against a $1,000 pre-tax cap at the time. That's our spend watchdog's total when T10's training box was terminated on 3 October: logged instance hours times their rates, the teacher API bill (OpenRouter, $15.55 for the whole round) and the egress for checkpoints synced home. One box took $494.97 of it. About $64 went on failures.

Spend stood at $883.78 when T11 started, after one more corrective round. T11 itself, the model we actually published, cost about $160, and about $50 of that was a late Forge fix. Most of the rest went on T10, the round that didn't ship, and on building and debugging the training pipeline it ran on.

What is NOT in any of these figures. The Mac Studio's own work: the privacy treatment, building the training mix, a knowledge test on every checkpoint, quantisation and the release gates. The earlier rounds, T1 to T9. Our time and the AI assistants'. And the benchmark runs above.

Why we couldn't fine-tune our LLM on a Mac Studio: a 12,288-token ceiling

T9 was trained on one Mac Studio, an M3 Ultra with 96 GB, with MLX. On 1 October we measured whether the Mac could carry this round too.

mlx-lm trains this model's linear-attention layers with a per-token loop. At 2,048 tokens that used 77 GB. At 4,096 it crashed. We wrote a chunked version of that path and got the fit up to 12,288 tokens at 69.7 GB and 91 tokens a second. 14,336 needed 78.5 GB.

A goose training row is a whole agent session. goose's own system prompt plus its tool schemas come to 32,569 tokens before the conversation even starts. Across the first 732 rows the median was 38.2k tokens. The part the model actually learns from, its next move, is a median of 179 tokens.

So no goose row fits on the Mac. Not one. The same arithmetic rules out an 80 GB H100: 32k only fits with activation offload, and 64k ran out of memory in every mode. We settled on 65,536-token rows. That needs an H200 (141 GB) or a B200, and on AWS those come as 8-GPU boxes. An 8xH200 box has 1,128 GB of GPU memory.

The Mac still did a lot of the round. It just couldn't train the rows that mattered. If your rows are shorter, Gabriela on our team wrote up the Mac route as fine-tuning Qwen3.8-27B with LoRA on a Mac.

A LoRA, not a full fine-tune: rank 128, a KL anchor and a guard on the eighth GPU

It's a LoRA, not a full fine-tune. Rank 128, on the attention, linear-attention and MLP projections of layers 32 to 63, 400.6M trainable parameters, continuing T9's own adapter. We did try a full fine-tune as one arm of the first pilot. It ran out of memory on the box.

Three things sit on top of the LoRA.

A KL anchor penalises drifting from T9's own predictions on the rows meant to preserve behaviour. Instruction following kept dropping in every pilot, and the anchor's strength was the only lever that moved it.

A guard. Seven GPUs train and the eighth runs checks every tenth of the run, including five sample answers that have to be read and quoted before the run may continue.

And selection. Every candidate is tested paired against T9 on the same items, and it's ineligible if it invents a single person.

The mix was 35,412 rows and 50,010,670 tokens, 79% of the tokens in goose agent rows. Those came from a factory. T9 drives a synthetic task inside goose with real tools in a sandbox, and where it slips, a teacher model (DeepSeek V4.1 Flash, and MiMo-V2.6-Pro for Atlassian admin and migration tasks) shows the right move. No Claude output went into the training data.

I learned that filtering isn't enough. Every row was scanned against a privacy dictionary and dropped on a hit, never redacted. Then independent readers went through all 1,361 goose rows and dropped 404. Rows sampled from T9 itself were 38% bad. One synthetic set ended 1,650 of 1,650 rows with a made-up "(Forge docs: ...)" citation, which was where T9's habit of inventing citations came from.

The H200 Spot price we paid, box by box

All fifteen instances the T10 round rented, as logged. Spot unless it says otherwise.

box	region	hours	$/h	$	what it was for
p5.4xlarge (1x H100)	us-east-2	0.858	2.66	2.28	platform probe
g7e.2xlarge (1x RTX PRO 6000), on-demand	eu-west-2	0.776	5.88	4.56	platform probe
p5.48xlarge (8x H100)	us-west-2	1.396	21.07	29.41	baselines and throughput
p5.48xlarge (8x H100)	us-west-2	0.361	21.07	7.60	launch attempt
p5en.48xlarge (8x H200)	us-west-2	0.341	27.32	9.30	launch attempt
c7i.8xlarge (CPU)	us-west-2	0.158	0.56	0.09	builds the Linux goose binary once
p5en.48xlarge (8x H200)	us-west-2	3.420	27.32	93.45	data factory run 1 (732 rows)
p5.48xlarge (8x H100)	us-east-2	0.407	20.75	8.45	launch attempt
p5.48xlarge (8x H100)	us-west-2	0.355	21.07	7.49	launch attempt
p5e.48xlarge (8x H200)	eu-north-1	1.007	17.73	17.84	first 64k-capable box, lost to a hand-over bug
p5e.48xlarge (8x H200)	eu-north-1	0.269	17.73	4.76	duplicate launched by that bug
p5e.48xlarge (8x H200)	eu-north-1	27.923	17.73	494.97	pilots 1-4, factory rerun, two training runs, knowledge eval
p5e.48xlarge (8x H200)	eu-north-1	2.253	15.54	35.01	final run, segment stopped by its guard at step 1012
p5e.48xlarge (8x H200)	eu-north-1	0.534	15.54	8.31	resume attempt, crashed on restore
p5e.48xlarge (8x H200)	eu-north-1	07:30 to 14:26 UTC on 3 Oct	15.37		final run from step 1012, selection, corrective rounds, verdict

The kept box took $494.97 over 27.9 hours. It ran all four pilots, the second factory run and the two earlier training runs. The data factory's own logs put its two runs at $66.74 and $57.17 for 2,420 rows, teacher API included; their box share was $63.95 and $51.95, because the factory counts only its own minutes on the box, where the table bills the whole box.

What the failures cost, summed from the table. Four short launch attempts that the logs give no other job: $32.84. The box lost to the hand-over bug plus the duplicate it spawned: $22.60. The resume that crashed: $8.31. Together $63.75. The segment stopped by its own guard ($35.01) isn't in that sum, because the run resumed from its step-1012 checkpoint and kept its training.

Why so much H200. The 64k rows need it. AWS's public price list has no on-demand p5e at all, and an on-demand p5en lists at about $63 an hour in Ohio and $68 in Stockholm. That's roughly four times what we paid for a p5e on Spot in Stockholm, and more than twice our p5en Spot rate.

So I went with Spot, and getting capacity was harder than paying for it. On 1 October the Stockholm box showed up after two hours with no 64k capacity anywhere else. On 3 October the launcher found no p5e or B200 capacity in any region it walked, seven times in a row, 15 minutes apart. No box was ever reclaimed by AWS in our logs. When we did get eu-north-1, it was $15.37 to $17.73 an hour, against $27 to $55 in the other regions.

The cap moved. It started at $800. I cut it to $450 the same afternoon, because I don't want to give budget to burn just to burn. Then I raised it to $650 and $800 on 1 October, $900 on 2 October and $1,000 on 3 October. The plan's first estimate was about $100 to $160. Three independent stops guarded the money: a watchdog on the Mac, a dead-man timer on the box, and an AWS Budgets action.

Why T10 never shipped: it kept inventing people

The first full run, 2 October. The training mix carried my name in 222 of 651 contrast replies that T9 had written, 73 of them as a bare sign-off.

The relaunch trained to the end and chose nothing. 142 of 160 replies from its candidates greeted an invented full name. Both causes were ours. Every voice row's persona line carried my name. And the privacy treatment of my own replies, a separate step from the dictionary scan, had replaced real requesters' names with invented full names, so the model learned to greet someone. The rule now is to pseudonymise a name to nothing, never to a fake one.

The final run, 3 October, stopped itself at step 1012 on two numeric breaches of its clean-loss check. No loops, and the number was falling, so I let it run. The resume then crashed on restore, because every rank loaded rank 0's optimizer state onto GPU 0 and ran it out of memory. The fix was one argument, map_location=cpu. It cost a box.

Then a knowledge drain. Later checkpoints sat 3.5 to 8 points under T9 on 199 Atlassian multiple-choice questions, and that proof stopped training at step 3,541 of 5,059. And then selection found that every checkpoint invented people in its ticket replies, 17 to 47 of 160 samples. Our own voice data had none of it, 0 of 135. T9 did it in every one of its stored samples.

Eight short corrective rounds later, one version invented nobody in 320 samples and kept its tool-call gains, at about 4 knowledge points on the home test and 1.85 IFEval points. I approved it for release with every one of those numbers on the card. The release gates then had their say.

Fine-tuning hallucinations: how the release gates caught invented forum handles

The release runs its own gates on the 8-bit build it's about to upload. Most passed: no loops at 32k or 128k context, needle recall 100% at 4k, 32k and 128k, no leaks in 112 outputs, and knowledge about a point under T9's own 8-bit build (70.85 against 71.86, not significant). Three things failed.

Manners. Asked 20 plain admin questions with no persona, it opened 4 of 40 replies by greeting a forum handle that doesn't exist, the way an Atlassian Community answer starts. T9 does it in 7 of 40.

Fabrication. 309 privacy extraction prompts found no memorised client data. But asked about a named company, it made things up 49 times: ticket keys built from the company's initials, a site URL built from its name with a made-up cloud ID, incidents that never happened. T9 did the same kind of thing 60 times.

Loops. 2 of 160 prompts ran into an endless list of invented identifiers, both on Forge coding prompts. T9 had 1.

So T10 did two of the three less often than T9, on small counts, and it still didn't ship. Fabrication and loops were hard blockers for this round, so being less bad than T9 wasn't enough.

The handles came from upstream. T9's own training data included 220 Atlassian Community threads, and 84 of the answers open by greeting the asker by handle. T9 learned Atlassian partly from forum threads, and learned to say hello like the forum too. T10's data had none of that, 0 in 35,412 rows, but T10 started from T9's adapter and was trained to stay close to T9. It inherited the habit.

One more corrective round, about $26 of GPU, pushed it down to about 1 in 80 sampled answers, from about 1 in 8. Corrective rounds push a habit down. They can't erase what the starting point carries.

T11 started from the base model, and cost about $160

So I had T11 start from the original Qwen3.8-27B, not from T9, with a fresh LoRA and no pull toward T9.

First we tested the premise, on the Mac, for nothing. The untouched base model got the same manners test that caught T10: 0 invented names in 120 replies. So the forum greeting came from T9's training, not from Qwen. The base has its own faults, measured the same morning: it loops more than T9, and asked about a named company it adds public facts or other organisations.

That base model is now on both boards above, as OpenRouter serves it, driven by goose like everything else: 0.0915 on Gauntlet and 0.1582 on Forge. On Forge its dashboard widget showed no data and its backfill silently missed changes, two criticals that took its multiplier down to 0.41. On Gauntlet no rows reached its console, no amounts rendered and its approval flow couldn't finish, three criticals and a multiplier of 0.22. I read that as the base model, building a whole app alone in goose, failing at exactly the parts a person would use. That says nothing yet about T11: T11 hasn't been run on either board, and I won't guess where it would land.

Then the data. Every training example T9 had written, 24,549 of them, was regenerated by the base model on the rented box in 13 minutes and filtered: 631 refused for knowledge the source didn't support, 43 for invented admin facts, 32 for naming a person, 26 for forum shape, plus 191 naming someone not in the prompt and 5 private-dictionary hits caught at home. A whole-mix name scan now fails the build if anything slips through. Run on T9's data, it catches 131 of the 220 Community samples.

It trained on one 8x B200 Spot box at about $14.4 an hour, 7,157 steps in about 3 hours, with the name, fabrication, loop and knowledge checks running on every checkpoint on a spare card. The automatic stop fired once, at step 2147, on detector noise: a licence type, a role and an Atlassian product, not names. We fixed the detector, turned the automatic stop off and read every check by hand.

T11 had a Forge problem too

Two real problems showed up while it trained. Asked "Are you Claude?" or "Are you GPT-4?", it said yes 3 of 8 times. And its Forge knowledge stuck at 53-63%, where T9 scores 90% at full precision.

That second one is the same story as the top of this post, from the other side. Starting from the base model, T11's general coding held up fine (HumanEval 96.3 against T9's 95.7). Forge, it had to be taught.

A 26-minute booster fixed the first problem and helped the second: 760 question-answer rows from Atlassian's own Forge documentation, plus Forge, identity and replay rows. Ten of the 30 Forge test questions were held out of the booster entirely, seeded before it ran, and it scored 80% on those ten. So the gain wasn't only memorised answers, though T9 got all ten.

I made one mistake that cost a re-run, about $50 and 3 hours. The box finished and shut itself down with nothing exported: the booster's checkpoints hadn't been copied off it, and the automatic pick had refused every checkpoint on detector noise. Finding a new box took 72 minutes, with no Spot capacity in Stockholm, and we ended up in Virginia at $34.55 an hour. This time every checkpoint was copied the moment it was saved.

The loop that wasn't

One Forge prompt looped on 3 of 8 samples from T11, and T9 hadn't looped on it in the one sample we had. That looked like a regression. I asked for a fix round first.

Before training anything, the fix round measured that prompt 16 times on both models. T9 looped 2 of 16. T11 looped 1 of 16. The earlier comparison was one sample against eight. The fix itself, 43 steps on 15 self-written Forge apps, made it worse: 4 of 16, and Forge down to 70. By the rule written before the run, nothing was exported. That cost about $7 and taught the cheapest lesson of the fortnight: compare a looping prompt on the same number of samples for both models before you pay to fix it.

The money for that day: I raised the cap to $1,100 and then to $1,250. Start to finish, the cap went $800, $450, $650, $800, $900, $1,000, $1,100, $1,250.

The late catch: T11 could barely build a Forge app

T11 was chosen, measured and in its release gates on the Mac when the last of them ran. It asks for 35 Forge apps, 3 tries each, and checks every one with Forge's own manifest linter, its module allowlist and the TypeScript compiler. That gate had never been run on this round before release.

On average over the three tries, T11 built a complete, valid Forge app for 9.7 of the 35 requests. T9 builds 30. It wrote manifests missing required fields, module keys and permission scopes that don't exist, and UI components that aren't in Forge's library.

The cause was in our mix. T9's validated Forge app code had been diluted to about 4% of T11's 50,000 rows, where it was 19% of T9's, and three of T9's Forge-code sets were missing altogether. Being able to answer Forge questions isn't the same as being able to build a Forge app.

I asked for the fix first. A 388-step booster from the chosen checkpoint on 2,127 validated Forge code rows, plus 22% replay, ran for about 1.5 hours on an 8x H100 box, because the H200 and B200 class had no capacity anywhere. Rows that taught any held-out test item, or matched a test brief, were removed first, and so were 206 rows containing client names. It cost about $50.

The fixed model, checkpoint 7636, builds a complete Forge app for 27.3 of the 35 on average (T9 30) and a valid manifest for 29.3 (T9 31.3). Its goose agent defect rates came out lower than T9's again: no edit without a path, 0 against 1.7%, missing required arguments 0.4% against 1.6%, and repeated calls 2.3% against 4.1%. None of those differences is significant, so I don't claim them as gains. It paid for that elsewhere. On the box, Forge knowledge questions fell to 63 from 73 before the fix (T9 90), Atlassian multiple choice slipped to 76.4 from 78.4, and on the 2 held-out scenarios where it should ask the user first, it never asked. T9 asked in a quarter of its samples. I chose app building, and that's the model we published.

A new generation should now cost a fraction of the first

The expensive part was everything before T11, about $880: T10 itself, and building and debugging the factory it ran on. With it built, I estimate a clean round on a new base model at one box for 5 to 6 hours, about $70 to $90 of rental, plus the release on the Mac. No such round has run yet.

I've put the rules these two rounds paid for into the recipe. Copy every checkpoint as it's saved. Never let detector noise stop a run. Keep one box for every phase. Measure the starting model first. Put known fixes into the main mix. And compare a looping prompt on enough samples for both models.

T11 against the published v0.5: better at tool calls, level on Atlassian, behind on Forge

T11 went public on Monday 5 October at 02:29 and 02:41 CEST, as an 8-bit MLX build and a PEFT LoRA adapter. Each was uploaded private, downloaded back, checked byte for byte, probed for private data on the downloaded files (309 probes, 0 hits), and only then made public. The 6-bit and 4-bit builds pass their quality gates but stopped at the privacy scan: the 6-bit conversion re-saved the tokenizer file and the scan found a dictionary term in it. They're held, not uploaded. The model cards already list them, and those two links won't open until they're public.

Here are the numbers I'd quote, from the model card. The rule since T10 has been that the release's fabrication and privacy checks are hard blockers, and any other failed gate can only ship as a named waiver on the card. Loops were a blocker for T10. For T11 I let them through as a waiver. In all, eight of T11's release gates failed. All eight shipped as named waivers on the card. They are loops, Forge app building, Atlassian knowledge against T9 (on the Forge questions), voice, one general-skills leg, the ask-first goose scenarios, 8-bit agreement on long agent contexts, and the LM Studio load test.

People and privacy: no invented names in ticket replies, where T9 greets an invented person in 18 to 20 of 20. On the same 309 privacy probes T10 was run through, 0 hits. T9 produces 57 (60 before a pre-registered rule for spelling variants), and T9's are the invented ticket keys and URLs described above, not memorised data. One goose output did use my name where nothing in the task called for it, and that's on the card too.

Fabrication: one invented date in 320 answers about named organisations, on the full-precision model. That one comes from the full-precision checks on the training machine, and it's on the card. The base model invented 28 details on the same test.

Loops: not clean. 2 loops in the 160-answer battery against T9's 1, every leg at or below the base model's, and it shipped under a waiver, under my decision to go ahead. With T10, the same 2 against 1 was part of why it stopped. The difference is scale: T10 invented people and 49 company details, and T11 invented no people and one date in 320 organisation answers.

Atlassian knowledge, on the shipped 8-bit builds: multiple choice 74.4 against 71.9, a little higher but not a significant difference, so I call it level. Forge knowledge questions: 19 of 30 against 26, which is significantly worse. Complete Forge apps: 27.3 against 30 of 35, on average over three tries. That's the honest shape of it: in the vicinity of T9 on Atlassian knowledge, worse at Forge.

Tool calling is where it's better, measured on the full-precision model on the training machine. On BFCL, a public function-calling benchmark, 91.8 against 85.7, and declining tools it shouldn't call 85.8 against 76.7, both significant. On the 294 held-out goose scenarios, every measure came out non-inferior or better except one: in the 2 scenarios where the right move is to ask the user first, it never asked. T9 asked in a quarter of its samples. That gate shipped as a waiver too.

General ability, also full precision: MMLU 84.3 against 83.0, IFEval, an instruction-following test, 81.5 against 82.4, and HumanEval 96.3 against 95.7. The general-skills gate still failed on one leg, a thinking-format test, 50.3 against 52.3, and that's another waiver.

Its voice is much closer to mine than T9's on our style measure, a combined distance of 0.65 against T9's 3.07. It still misses my range on four features. It asks questions in 15% of replies where I do in 29 to 46%, greets in 31% where I do in 35 to 54%, signs off in 6% where I almost never do, and uses exclamations in 6.2% where my top is 6.1%. T9 signed off in 58%. The voice gate counts those four misses, so it's a waiver too.

One more limit. The 8-bit build matches full precision on general text, but on goose agent contexts up to 16,384 tokens long it drifts: a KL divergence of 0.400 and top-1 agreement of 89.9%, against a gate of 0.067 and 90%. When we diagnosed the same drift on the earlier checkpoint, the rows that drifted also drifted between MLX and the PyTorch reference at full precision, so the framework is part of it. The PEFT adapter on the bf16 base is the reference. Every waiver, this one included, is on the model card, and I'd read it before you download anything.

Every failure, what it cost and what fixed it

I've told the big ones already. Here's the whole list for both rounds, 30 September to 5 October, in order. Where we measured what a failure cost, in money or time, it's there.

T10, continuing from T9:

The plan underestimated cost by 6 to 10 times. It said $100 to $160. Every stage needed 8-GPU boxes for 64k-token rows, and Spot capacity for those was scarce. I moved the cap seven times across both rounds, five of them during T10.
Hardware assumptions. A single H100 or RTX PRO 6000 couldn't train 64k rows, and the Mac tops out at 12,288 tokens. Fix: one fixed 65,536-token length, 8x H200 or B200 boxes only.
Capacity. Two hours waiting on 1 October, seven empty 15-minute walks across regions on 3 October, and a launch hand-over bug that lost one box and started a duplicate, $22.60 between them. Fix: the launcher refuses instead of walking, and a grab loop now catches boxes.
All 732 rows from the first factory run came from 2 templates, because briefs ran in id order and the spend stop hit after 65 of 1,483. The re-run for diversity cost $57.
The privacy treatment of real sessions was too slow, and the session bundle failed its audit. T10 trained on voice data only.
My name in the training targets: 222 of 651 contrast replies T9 had written named me or signed as me. Fix: a hard rule that no target may name me.
The relaunch chose nothing on 2 October. Every candidate named me or greeted an invented person in most replies. Causes: the persona line named me, the privacy treatment had swapped real names for invented ones, and T9's habit came through its adapter.
A filter that hadn't been pushed was missing on the box, and two parts failed after we'd rented it. Fix: the box gets only what's pushed and tested.
A guard stop at step 1012 on numeric-only breaches, then a resume that crashed on restore because every rank loaded the optimizer onto GPU 0. Cost: a box, $8.31. Fix: map_location=cpu, numeric stops off, every guard read by a person.
A knowledge drain, found late. Later checkpoints lost 3.5 to 8 points of Atlassian knowledge, and selection had never measured knowledge. Fix: knowledge on every checkpoint in selection. My ruling: a small drop is fine, 20 to 30% isn't.
Invented people in every checkpoint, 17 to 47 of 160 replies. Eight short corrective rounds got one version to 0, and I approved it.
The release gates stopped it anyway: invented forum handles, 49 fabricated company specifics, 2 loops. Root cause: 84 of T9's 220 Community answers greet the asker by handle.

T11, a clean model from the base:

Detector noise stopped training at step 2147. A licence type, a role and an Atlassian product were read as invented people. Fix: a stoplist for the detector, numeric stops off, every guard read by a person.
During the manual resume we killed the wrong process, the guard's server instead of the evaluator's. About 20 minutes of re-measurement.
The box shut down with nothing exported. The booster's checkpoints hadn't been copied to storage, and the automatic pick refused every one on detector noise. About $50 and 3 hours to re-run. Fix: every checkpoint copied the moment it's saved, and the pick made by the coordinator, not automatically.
A misread clock made training look slow. Fix: always check the real clock.
Capacity again. 72 minutes to find the re-run's box, and at one point nothing in six regions, Spot or on-demand. A grab loop caught one.
The Mac's GPU timed out merging the adapter. Fix: merge on the CPU, about 2 minutes.
LM Studio on the release machine indexes no local models at all, so the LM Studio load gate could never be tested. Waived, on the card.
An unfair comparison. One T9 sample against eight T11 samples made "T9 never loops on this prompt" look like a fact. The fix round I asked for, about $7, made it worse. Measured fairly, T9 looped 2 of 16 and T11 1 of 16. Fix: equal samples first.
The 8-bit build drifts from full precision on long agent contexts. Diagnosed on the earlier checkpoint as largely the framework, waived and stated on the card.
Forge app building collapsed, 9.7 of 35 against T9's 30. Cause: validated Forge app code diluted to about 4% of the mix and three Forge-code sets missing. Nobody saw it until the gate first ran at release. The fix round I chose cost about $50 and got it to 27.3, and it cost Forge question answering.

The release night, 4 to 5 October:

The second release shared the first one's private output folder, so three checks, manners, privacy and voice, silently reused the earlier model's answers. We caught it because they finished in seconds instead of minutes, and re-ran them on the right model.
More detector false positives: a file format, a role and a code annotation read as people. Added to the stoplist.
The card generator only knew "main run plus booster", so the Forge-fix stage was written into the card by hand and checked line by line. A card review found nine defects first. The biggest was a false claim that the 8-bit build matches full precision.
Hugging Face writes its own .gitattributes, which our upload check read as tampering. Excluded, and every model file matched.
A stale figure from the earlier checkpoint stayed in one card note after publishing. Caught by a review of the site page and corrected on the live cards.
The 6-bit and 4-bit uploads stopped at the privacy scan, as above. Nothing was uploaded.
Names leaked twice into the fact sheet this article was written from, forum handles in one file and names from model outputs in another. Removed, and every file now gets the name scan before it's used.

What I think worked: the release gates, which caught 12, 22 and 28 before anything went public, even where I then chose to ship under a waiver. Testing the starting model before training, which showed the name habit was T9's, not Qwen's. Training from the base instead of patching. Held-out test items for the booster. The private, then probe, then public publishing order.

Was renting GPUs worth it? For this one model, no

I asked for a blunt answer to that, and here it is.

The whole effort, T10 and T11, cost $1,051.87 before tax, $1,269.50 with AWS's VAT. GPU boxes were nearly all of it. The plan's first estimate had said $100 to $160.

What did it buy, T11 against T9? Atlassian knowledge in the vicinity of T9: a little higher on multiple choice, not significantly, and worse on Forge. Tool calling better, on BFCL (91.8 against 85.7) and on declining tools it shouldn't call (85.8 against 76.7). And trust: no invented people, 0 hits on the 309 privacy probes where T9 produces 57 invented keys and URLs.

T9 trained on our own Mac Studio. 2,600 steps, 5.8M tokens, about 23 hours, for the price of the electricity.

So for this one model, judged on its gains alone, renting wasn't worth it. Two things soften it.

First, most of the money went on T10 and on building and debugging the rental pipeline, not on the model we published. T11 itself cost about $160, the late Forge fix included. The next round on a new base model is now estimated at $70 to $90 of rental, plus the release on the Mac. Whether the rest was worth it depends on whether there's a next round.

Second, much of what a user will notice didn't need rented GPUs at all. No invented people, no invented ticket keys, the voice: that came from cleaning the data and starting from the original Qwen model instead of T9. The identity fix, for a habit T11 picked up in its own training, came from 143 short identity rows in the booster. Those rows are short too. The Mac could have trained them in a few days.

What I haven't measured, and should before renting again, is which rows bought the tool-calling gain. T11's mix had 527 goose rows out of 50,095. The BFCL gain might come from short general rows the Mac could train. The same mix minus the long goose rows, trained at home, would answer that for the cost of a few days of a machine we already own.

The rule for next time is in our recipe now. Train everything that fits on the Mac first, measure it, and rent a box only for what the Mac can't do.

Opus or Sol for Forge; Sol Pro for a payments app

If you're choosing a model for general app work, GPT-6.1 Sol Pro is the one that cleared every bar on Gauntlet. The next four finished within 0.006 of each other under the same cap. They didn't build the same app. Sonnet earned the most before the cap, Sol wrote about 530 tokens a call to Sonnet's 6,100, and the payment Opus's approval flow created never showed up in its table. Same score, different apps.

If you're choosing one for Forge, Opus 5.5 and GPT-6.1 Sol are the two I'd trust, with Sol Pro close behind. Sonnet 5.5 built a good ledger and then lost almost half its score at a button, a modal and an LLM call. That's exactly where a Forge app meets a real person, which is why the scorer prices it the way it does.

And if you're fine-tuning your own model: measure the starting point first, keep every checkpoint off the box the moment it's saved, run every release gate before you call a model chosen, and assume the parent's manners come along for free.

One run per model. Bills are a lower bound. The boards move, and they'll have moved again by the time you read this, so open the Forge board and the Gauntlet board for the current numbers, and click any run for its every check.

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.

Atlassian Team '26 Europe: dates, agenda, keynote and livestream times

Mihai Perdum — Mon, 05 Oct 2026 05:00:50 +0000

Atlassian Team '26 Europe: dates, agenda, keynote and livestream times

Key takeaways

Atlassian Team '26 Europe runs Tuesday 6 to Thursday 8 October 2026 at RAI Amsterdam. Monday 5 October is Day 0, with the partner-only Partner Accelerate, which is sold out.
Founder Keynote: Wednesday 7 October, 09:00-10:15 CEST, which is 08:00-09:15 in the UK. Atlassian's FAQ says you do not need to register to watch it.
Closing Keynote: Thursday 8 October, 15:00-16:15 CEST (14:00-15:15 UK). Its session page is tagged On demand only, so don't count on watching it live.
The Digital Pass is free. Atlassian's pages give two different livestream start times (08:30 and 08:45 CEST) and two on-demand dates (11 and 12 October).
Anaheim in May shipped Agents in Jira and the new Rovo Studio experience as generally available, and put the Teamwork Graph CLI and Teamwork Graph tools in Rovo MCP Server into open beta.

Atlassian Team '26 Europe runs Tuesday 6 to Thursday 8 October 2026 at RAI Amsterdam, and today, Monday 5 October, is Day 0. The one slot to put in your calendar is the Founder Keynote, Wednesday 7 October at 09:00 CEST (08:00 in the UK). Atlassian's FAQ says you can watch it without registering. Atlassian's own pages disagree with each other in three places, so I've put both versions side by side below instead of guessing.

Gabriela and I are going. No booth, no talk; I wrote in September why we're going anyway. This page is the hub for our seven-part series, which runs until Monday 12 October, and every part gets linked at the bottom.

Atlassian Team '26 Europe dates and location: RAI Amsterdam, 6-8 October

Atlassian's FAQ puts it plainly: "Team '26 Europe will take place 6-8 October 2026 at the RAI Convention Center in Amsterdam, Netherlands." Over 100 sessions, according to the same page. The themes run from AI, collaboration and service management to cloud migration.

Monday is Partner Accelerate, a partner-only day from 9:30 to 17:30 at the same venue. It's sold out. Atlassian's Partner Accelerate page is careful to add that "It is only Partner Accelerate that is sold out", so partners can still register for the main event. (The FAQ calls Monday Day 1, the agenda calls it Day 0. It's Monday either way.)

Team '26 Europe agenda and schedule by day

This is the agenda as Atlassian publishes it. The agenda page prints bare times. The FAQ and the event home page say CEST, so read everything here as Amsterdam time.

Tuesday 6 October: breakout and learning sessions 10:00-18:00, the Expo 13:00-18:00, Welcome Reception 16:00-18:00.
Wednesday 7 October: the Expo 08:00-18:00, Founder Keynote 09:00-10:15 on the agenda (the session page now says 10:30), breakouts 11:00-16:00, reception on the Expo floor 16:00-18:00.
Thursday 8 October: the Expo 08:00-15:00, breakouts 08:30-14:30, Closing Keynote 15:00-16:15, then BASH 16:30-19:30 at StrandZuid, five minutes' walk from the RAI.
Monday 12 October: the on-demand library (more on that date below).

Two things from the FAQ will matter on the day. Adding a session to your agenda reserves a spot in your planner, not a seat. Learning sessions are the exception, and you bring your own laptop and charger for those. Unclaimed seats are released 10 minutes before the start. If a session matters to you, be early.

Team '26 Europe keynote times in CEST and UK time

The UK is an hour behind Amsterdam and Romania an hour ahead. All three are on summer time this week (the clocks go back together on 25 October), so the table holds for the whole event. I added Romanian time because that's where we're based.

Keynote	CEST (Amsterdam)	UK (BST)	Bucharest (EEST)
Founder Keynote, Wed 7 Oct	09:00-10:15	08:00-09:15	10:00-11:15
Closing Keynote, Thu 8 Oct	15:00-16:15	14:00-15:15	16:00-17:15

Founder Keynote: Your business knows better

Main Stage, Wednesday. The session page lists Mike Cannon-Brookes, Sherif Mansour, Tamar Yehoshua and Taroon Mandhana. On 5 October it also listed Josh Miller of The Browser Company. It's tagged Livestream and On demand. This is where the announcements land, if there are any.

Closing Keynote: What becomes possible

Main Stage, Thursday afternoon. The session page lists Hannah Waddingham, Brian Duffy, Amit Puntambekar (CTO, Reddit), Hilary Lanham (Lloyds Banking Group) and Mike Cannon-Brookes. It describes two parts. First, a technical customer panel on connected context as "the foundation for AI at scale". Then a fireside chat with Hannah Waddingham. The page is tagged On demand, and not Livestream.

How to watch Team '26 Europe online: livestream and on demand

The Digital Pass is free. The event home page says "Sign up for free", and the sign-up form is on the digital registration page. In September I couldn't confirm that. Now it's confirmed.

You don't even need the pass for the Founder Keynote. The FAQ: "You do not need to register to access the Founder Keynote. Registration is required to access select Keynotes, Solution Keynotes, and all other on-demand content."

Now the three disagreements.

Livestream start. The FAQ says it begins at 8:30 CEST on Wednesday and Thursday. The home page and the online sessions page show the programme from 8:45 to 13:00 CEST. Join the live stream at 8:30 and you miss nothing.

The Closing Keynote. The home page lists Thursday's stream as "AI sessions + Closing Keynote 8:45 - 13:00 CEST". But the keynote starts at 15:00, two hours after that window closes. The online sessions page has no keynote in Thursday's list, and the keynote's own page says On demand only. My read: don't plan on watching it live.

On demand. The FAQ says recorded sessions are available "starting 11 Oct". The agenda and the home page say 12 October. Only select sessions are recorded, but the FAQ promises AI-generated summaries of all in-person sessions, and captions in English, Spanish, French, Japanese and German.

Team '26 Anaheim announcements: what to expect in Amsterdam

Team '26 in Anaheim ran 5-7 May. Here is what Atlassian announced there, with the availability exactly as its press release and Mike Cannon-Brookes' founder update state it.

Two things went generally available that matter most to anyone who runs Jira. Agents in Jira lets teams assign work to Rovo and third-party agents. The other is the new Rovo Studio experience. DX AI Experience went generally available too. The Teamwork Graph CLI and Teamwork Graph tools in Rovo MCP Server went into open beta. Remix with Rovo is in beta, and Confluence slides are "coming soon in beta". Max mode in Rovo Chat is coming soon. Product Collection and Code Intelligence in Rovo are in early access.

Dia is the odd one. Neither the press release nor the founder update labels it generally available. Atlassian says it is "now ready for teams of all shapes and sizes to try", with a closed beta for advanced enterprise features, including a Guard integration "that will be available soon".

What Amsterdam adds, I don't know. Nobody outside Atlassian does until Wednesday at 09:00. What I'll check first is whether the May items marked beta or coming soon have moved. The Teamwork Graph is clearly on the bill either way. Two of the livestreamed sessions have it in the title: "Connected Context, Governed Action: Scaling Enterprise AI with the Teamwork Graph and Rovo" on Wednesday and "Maximising your context layer with the Teamwork Graph" on Thursday.

What LeanZero will look at in Amsterdam

We build Forge apps and run Atlassian migrations, so this series reads Team '26 Europe from those two seats. Agents in Jira matters to us because CogniRunner already puts AI into Jira workflows. Gabriela compared Rovo agent permissions with CogniRunner approvals on 4 October. I'd rather redo that comparison against whatever ships than guess. The MCP side matters because tool definitions are not free. Across ten real MCP servers we measured, 145 tool definitions came to 40,784 tokens, sent with every request. The schemas drove the cost. Not the tool count. Rovo MCP Server wasn't one of the ten, so how heavy the Teamwork Graph tools are is still an open question.

For a Forge developer, the sessions worth marking on Atlassian's recommended agendas page are three. One is already full. "Give coding agents the context behind the code with the Teamwork Graph" is on Tuesday at 13:30, repeated Wednesday at 10:45. "Operationalize Rovo agents with subagents, evaluations, and autonomy" is a hands-on Learning session, Tuesday at 11:00 and again Wednesday at 15:00. Both runs are already marked full. "Your Atlassian context, in Claude, ChatGPT, and any AI agent" is Wednesday at 10:45, repeated Thursday. Spot the clash? I would take the Tuesday run of the first one. The "Getting Started with Forge" workshop on Tuesday morning is full too.

Tomorrow is Day 1: breakouts from 10:00, the Expo from 13:00. Part 2 goes out tomorrow morning.

Every article in this series

I add each part here the day it goes live.

Part 1: Atlassian Team '26 Europe: dates, agenda, keynote and livestream times (this page).

Part 2: Atlassian Partner Accelerate at Team '26 Europe: Forge, revenue share and who we met

Part 3: Team '26 Europe in Amsterdam: Jira Service Management sentiment analysis in triage queues

Part 4: Atlassian Team '26 Europe announcements: AMP, MCP Server and Rovo Work, explained

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.

Rovo Agent Permissions vs CogniRunner Approvals

Mihai Perdum — Sun, 04 Oct 2026 09:06:36 +0000

In November 2025 someone asked on the Atlassian Community whether Rovo agent permissions could be set by group, and that question has been viewed 1,920 times since. The short answer is still no. You can limit who creates agents by group, but who can use an agent is a list of individual people, and that's the bit admins keep tripping over.

I read Atlassian's governance pages, the two announcement posts behind them (6,736 and 6,583 views) and the open tickets on 2 October 2026, so everything below is as of that day. First I'll walk you through what Rovo lets an admin control, and what it writes down. Then I'll show you the other half of the problem, the one permissions don't solve: what happens when an agent wants to delete something. That's where Mihai's work on CogniRunner comes in, and I'll be honest about what it doesn't do as well.

Rovo agent permissions and governance: what an admin can set today

There are three separate switches, and they're easy to blur together.

Creating agents is open to everyone by default. Atlassian's Rovo agent permissions and governance page lists the three options a Studio admin has: "All users", "Selected groups", which "limits agent creation to up to 10 user groups", and "No users", which leaves creation to you and the other organization admins.

One thing to watch if you go for groups. There's an open bug, ROVO-1228: a Studio app admin who isn't also an org admin can't add groups to that create permission. The group list never loads, and a group you type in shows Saved but is gone after a refresh. It was filed on 11 September and sits in Atlassian's short-term backlog. The workaround is to ask an organization admin to add the groups. If your groups won't stick, it's not you.

Editing an agent is per agent. The person who builds it can add Editors, who can edit, and Managers, who can also add other editors and delete the agent. Heads up, the docs and the product announcement don't quite agree here. The governance page still says you give each person "either editor or manager", while the February 2026 announcement says the roles are now "managers, editors, users". If your screen shows three roles, that's why.

Using an agent is the one people ask about. It's also the loosest. "When you create an agent, it becomes available for everyone to see and use by default." You can restrict it, and then "agents with restricted access are only visible by the people you add". Everyone else won't see it in the directory or as an option for automation.

Who can use a Rovo agent: individual users, not groups

Here's the sentence that answers the Community thread, straight from the governance page: "Restricting agent access to specific groups or teams is currently not supported. You will need to add users individually."

Jensen Fleming from Atlassian said the same under the user permissions announcement in February: "currently only users". Groups "added a ton of dev complexity", so they shipped without them. The request to add groups is ROVO-875. It's at Gathering Interest with 28 votes, so if you need it, go vote.

Groups do work for one thing, and that's creation. The August 2025 governance announcement is where that arrived.

The agent acts as you, unless it has its own account

Permissions on the agent decide who gets to talk to it. What the agent can then reach is a different question, and Atlassian answers it with identity.

By default an agent uses the account of whoever is using it. The governance page puts it plainly: "If the user can't comment, the agent can't comment." The other option, set up in Configure a Rovo agent's identity, is the Agent's account. Then organization admins decide which apps it can reach, space admins and end users decide which spaces and pages, and its changes "appear under the agent's name making it easier to track in audit logs".

That last part matters more than it sounds. On a user's account, an automated agent's changes are logged as the person who set up the automation. And if an admin never sets up an Agent's account, that's what you get.

You can also narrow an agent through its instructions and the tools you give it. Just don't lean on the instructions. Atlassian's best practices page says it twice: "Guardrail instructions are suggestions. There is no guarantee that the agent will follow them."

What Rovo logs when an agent acts

People sometimes assume there's no trail at all. There is, in three places, and which ones you get depends on your plan.

The first is the work item itself. Atlassian's guardrails guide says agent actions land "in the work item history alongside human activity", under the user's name or the agent's, depending on the identity above.

The second is the organization audit log. Atlassian's list of audit log activities includes "Created Rovo agent", "Updated Rovo agent", "Deleted Rovo agent" and "Started chat with Rovo agent", plus "Invoked tool" for Rovo MCP. Atlassian files all four under Rovo user actions. When Rovo activities first arrived in the audit log in April 2025, the note said user actions are for Guard Premium. Admin actions, like connectors and bookmarks, are for Guard Standard and up.

The third is newer. Atlassian's August 2026 update announced it: if your organization has Atlassian Guard Premium, "every time someone invokes an agent, an "Invoked Rovo agent" event is captured" under Insights, Audit Log. It records who invoked it, from where (Rovo Chat, Slack, Teams), what tools it used and what permissions it ran under. That's from Atlassian's bi-monthly Rovo agents update.

So the honest summary? The work item history is always there. The agent events in the audit log, including the per-invocation one, are Guard Premium.

Human in the loop for AI agents in Jira: who approves the delete

So who says yes before an agent changes something?

In chat, the person using it. Atlassian's page on agent tools says the agent "will respond asking for confirmation before executing consequential tools that may mutate data across systems". The best practices page goes further: in interactive use "there's always a human in the loop to review and approve an action before the agent does anything". The same tools page also caps bulk actions in Jira at 20 work items at a time.

In an automation, nobody. "The agent acts autonomously and will perform actions without a user confirming every task." You can limit the Use agent step to read actions only, and admins can stop agents acting in automations altogether.

You'll find one Atlassian page that says the opposite, so let me save you the confusion. The tools page still says an agent in an automation "cannot use its own tools" and can only return text. The automation page says an agent there can "take actions directly". And Atlassian's August 2026 update, the newest of them, says agents in automation rules "can execute these actions directly" now. No stopping to ask. Plan for the agent acting.

Agents on work items are their own case. You can assign an agent to a work item, or attach one to a workflow transition (that needs a space admin with Edit workflows). On a transition, "the agent is triggered when any team member moves a work item to the allocated status." And Atlassian's own guide is clear that "Assigning the agent runs it. It does not yet put a human in the loop, that is the checkpoint you add next."

For anything hard to undo, that guide to human-in-the-loop patterns for AI agents in Jira points you at the workflow: "approval is a workflow approval step that holds a transition until a named person signs off". It also says "Native approvals are available on Premium and Enterprise plans."

That's a good pattern, and I'd use it. But notice what it gates. It holds a transition. It doesn't hold a single API call that an agent decided to make halfway through its work. And the person confirming in chat is whoever is talking to the agent. They can only confirm what their own permissions allow, but they're the requester, not a named approver.

That's the gap CogniRunner's agents were built around.

Learn, Shadow, Ask first, Live: a CogniRunner agent starts with no write access

CogniRunner is our Jira app for AI workflow rules, and since Marketplace version 5.0.0 on 30 September 2026 it also has agents, which it calls virtual administrators. They work a queue on a schedule: a JQL filter in a service desk, say. The version on Marketplace on 4 October is 6.1.0, from 3 October. It fixed rules, tests and AI providers and changed nothing this article says about agents. The screenshots below were taken on 6.0.0, on 2 October.

Every agent made in the setup wizard starts in Learn, whoever makes it. In Learn it reads, keeps notes and proposes facts. It doesn't draft replies, ask anyone, file anything or change anything in Jira or Confluence. New agents also come with working hours on, invited work only, a second check on customer replies and a daily token cap.

Only a CogniRunner admin can move it up. If someone who isn't an admin tries to choose a phase, they get Learn anyway. An admin can also schedule the move for after a set number of runs (the "Set an automatic move" link in the next screenshot), but the agent never picks its own phase.

Shadow adds drafts. The agent writes the replies and records the changes it would make, and a person approves or rejects each one. Ask first lets it ask people questions, file change proposals and run a request someone approved. Live lets it post answers and make changes within its powers, its working hours and its caps.

Those brakes are worth a second look. The demo agent may send 6 messages an hour and 30 a day, and make at most 200 changes in one run. It also only changes the issue it's working on. If it decides another issue needs a change, that's recorded for a person to make. And a reply that fails its second check three times stops and waits for a person.

There's a check on every run too. The agent acts for a named person, and before each run CogniRunner asks Jira whether that person's account is still active and can still browse every project it reads and writes. If it's allowed Atlassian operations (more on those below), that person also needs Jira's Administer permission. If any answer is no, or Jira can't answer, the agent runs in Learn. A lasting no stays until an admin reverses it.

Delete, configuration and identity calls wait for a Jira administrator

This is the part I'd want to know about if I were deciding whether to let an agent near my site. So let's be precise.

Even in Live, a CogniRunner agent never deletes anything, changes configuration or touches users and groups straight from a model turn. In Ask first and Live those calls wait under "Waiting for your approval", showing exactly what would be sent. In Learn and Shadow they don't run at all.

A few details make that approval mean something:

The approver has to hold Jira's Administer permission, checked live at the moment they click. If Jira can't answer, the approval is refused.
The approval is tied to the exact request. If what's waiting isn't what you approved, nothing runs, and it only runs while the thing it changes still looks the way it did when the request was filed.
A request expires after 24 hours. One agent can have at most 20 waiting.
A token can only approve as the Jira administrator who created it, and a token with no person behind it can't approve at all. A model can never approve its own request.
No agent can change the org-admins, site-admins or cognirunner-guardians groups, even with approval.

To be clear about what you're looking at, that queue is empty. Our demo agent isn't allowed any operations, so I haven't got a real waiting request to show you here.

The middle card, Try a request, is the one I'd use first. It shows what a call would pass without sending it. On this agent it has nothing to try, because nothing's allowed yet.

AI agent guardrails: allowed operations, a guard dog and a token cap

Atlassian's guide to AI agent guardrails and safety in Jira has a line I really like: "A guardrail only works if the system enforces it, not the agent." CogniRunner has two that work that way, the allowlist and the token cap, plus a guard dog that watches for what gets past them.

The allowlist comes first. Beyond its ordinary actions, an agent can call only the Atlassian REST operations on its own list, up to 40, picked from Jira, Jira Service Management, Assets and Confluence. Only a Jira administrator can add one. The catalogue is built from Atlassian's published API specs, and the model never names a host, a path or a method itself.

The token cap is about money. Atlassian's guardrails guide lists "Runaway cost" as a risk and says spending "needs limits like any other resource". It's not abstract on the Rovo side either: Atlassian's Jira docs say Rovo credit allowances apply from 3 December 2026. New CogniRunner agents get a cap of 250,000 AI tokens a day. When it's spent, the work waits for the next day (UTC) and the agent's history says why. One turn that's already running can go a little over, and the next one is refused. The budget is also checked inside each turn, and a Learn turn uses at most three rounds.

Then there's the guard dog. It watches issue deletes on the whole site, by anyone, people included. It also notices when automation answers someone's bulk change. When one account deletes 10 or more issues in 10 minutes, or 3 in a project you've marked protected, it notices. Both numbers are adjustable on its card, which only organisation admins see. Once you've set an inbox project, it files an incident issue there and notifies the organisation admins and the leads of the affected projects.

Set up the controls on your own site

If you're going to try either, here's the order I'd do it in.

For Rovo:

Decide who can create agents in Studio settings: all users, up to 10 groups, or nobody but org admins.
Restrict any sensitive agent to the named people who need it. Remember it's one user at a time.
Give agents that run in automations an Agent's account, so their changes show under the agent's name.
In each automation's Use agent step, choose read actions only wherever the agent just needs to read.
Add a workflow approval step on the transitions where the impact lands, if you're on Premium or Enterprise.
If you have Guard Premium, check the "Invoked Rovo agent" events after the first week.

For CogniRunner:

Create the agent with "New virtual administrator" on the Agents tab. It lands in Learn.
Leave it in Learn for a while and read what it writes down before you trust it with anything.
Move it to Shadow and approve or reject its drafts. You'll learn more from the ones you reject.
Only then have a Jira administrator allow Atlassian operations, the fewest it needs, and run each one through Try a request.
Ask an organisation admin to set the guard dog's inbox project and mark your protected projects.
Check the token cap under Brakes, and move to Ask first or Live only when the drafts stop surprising you.

What CogniRunner doesn't do

A few honest limits, because they change the decision.

On Marketplace, a CogniRunner agent doesn't get its own Jira account. It writes as the app, so Jira shows the app's name on its changes, and only within what the person it acts for may do. That's the opposite of Rovo's Agent's account, which really is a separate identity.

The guard dog detects and tells people. That's all. It never restores anything and never blocks a delete, and on Marketplace it can't switch off the automation rule behind a bulk change either. It also only watches Jira issues, not Confluence: issue deletes, and bulk changes that automation answers.

The admin approval covers deletes, configuration and identity calls made through the allowed operations. It isn't a gate on every write. In Live, ordinary changes run within the agent's powers and caps, and replies go through the staged drafts you approve in Shadow and Ask first.

And the AI. On Standard, the agents run on your own AI provider, any CogniRunner supports except goose, which can't make the tool calls an agent needs (there's a tutorial on connecting an OpenAI key). On Atlassian's zero-key Forge LLM, they need the Coder edition and one of its frontier models, the same edition behind the CogniRunner Coder.

Rovo or CogniRunner: pick by who should say yes

They're not really competitors, and you can run both.

In chat, a Rovo agent acts as the person using it, and they confirm consequential actions. On a work item someone assigned it, it acts as them too, and Atlassian's own guide says the approval checkpoint is one you add. You control who can use it, one user at a time for now.

If the agent works a queue on its own, Rovo can do that too, in an automation and ideally on an Agent's account, with a workflow approval step on the transition. CogniRunner's difference is that a Jira administrator signs off on each destructive call before it's sent, and the agent climbs phases only when an admin decides. The CogniRunner page has two short videos of the setup and the phases if you'd like to see it move.

Either way, the workflow approval step Atlassian recommends is still worth adding on the transitions where the impact lands. A second gate that doesn't depend on the agent is the whole point of a guardrail :)

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.

How to Lock Attachments in Confluence Cloud

Mihai Perdum — Sun, 04 Oct 2026 05:02:33 +0000

Confluence Cloud has no built-in way to lock attachments. The request for one, CONFCLOUD-2841 "Provide locking for attachments", has been open since 2005 and carries 163 votes. Sentinel Vault, the Confluence app we make, gets you the closest working thing: you seal the file, and when somebody uploads over it, the sealed version is back on top a few seconds later. On our production install that took between 2.6 and 4.6 seconds, over three runs on 2 October.

It isn't a lock in the check-out sense. I'd rather you know that before Step 1. A Forge app can't stop Confluence from saving an upload. So Sentinel Vault lets the save happen, downloads the sealed version and uploads it again as a new version. The rejected upload stays in the version history. That's useful when someone's change was right after all. We wrote up why it has to work this way in you can't block a Confluence save, so I won't repeat it here.

By the end you'll have one file sealed on a real page, a second account's overwrite reverted, both versions visible in the attachment history and over the REST API, and the seal released again. One more thing up front, because it changes how you use it. Running this, we hit a bug in our own app: if you sealed the file and then upload a new version yourself, the seal keeps pointing at the old one. The workaround is in the "If it didn't work" section below.

We ran the walkthrough below on 2 October 2026 on our demo site, which runs the production build, 6.6.0, signed in as me with Gabriela's account as the second user. The two checks that ran on our test site instead say so where they appear. Afterwards the page was deleted and purged.

[!NOTE]
Prerequisites

A Confluence Cloud site and a site admin who can install apps. Sentinel Vault is on the Atlassian Marketplace. Atlassian bills it, and on 2 October the listing's pricing data priced the 10-user tier at 0. This tutorial was written against 6.6.0, released 2 October.

Edit permission on the page that holds the file. That's all sealing needs.

A second account that can also edit the page, to play the person who overwrites the file.

For Steps 3 and 5 on the command line: an Atlassian API token for each account, plus curl, jq and shasum. We ran them with curl 8.7.1 and jq 1.7.1 on macOS.

[[steps]]

Install Sentinel Vault — a site admin, once, from the Marketplace listing.
Seal the attachment — page ⋯, Apps, Seal attachments…, tick the file, Seal 1 attachment.
Overwrite it as another user — same file name, same page, second account.
Read the attachment version history — the rejected upload and the app's revert, side by side.
List the versions over the REST API — and hash them to prove the sealed bytes came back.
Release the seal — Release on the file's row, and uploads stand again.

A seal remembers one version and puts it back

One picture before the clicks. It's short. When you seal a file, Sentinel Vault records which version it is (v1 here). From then on, every new upload to that file triggers a check, and who uploaded it decides what happens.

Who uploads	What happens
Anyone without access	Reverted: the sealed version comes back as a new version
Someone you gave edit access	Kept, and it becomes the new sealed version
You, the person who sealed it	Kept, but the seal still points at the old version (the bug)
Anyone, after the seal expires	Kept. An expired seal stops enforcing straight away

One exception: on a page that is Approved in a Sentinel Vault workflow, only its approvers and space admins can seal or change a file, so even you and your grantees get reverted there.

The seal follows the attachment's id, not its name. Remember that. It matters later.

Step 1: Install Sentinel Vault from the Atlassian Marketplace

A site admin installs it once, from the listing, and accepts the permissions it asks for.

There's no switch to flip after that. I like it that way. Sealing isn't behind a site setting, and anyone who can edit a page can seal its files (Approved pages are the exception, see above). The defaults that matter here: a seal lasts 48 hours unless a space sets its own default, and the app tells an editor when their change is undone. Signed seal actions (a 6-digit authenticator code) are off by default. Leave them off for this test. I'd turn them on later, once people know what a seal is.

To check it worked, open any page. Under the title, next to the author, you'll see a small Sentinel Vault item in the byline. That's the app's door on every page. No item, no install.

Step 2: Seal (lock) an attachment on a Confluence Cloud page

Attach the file you want to protect to a page. Our test used a 93-byte price-list.csv on a page called "Supplier price list Q4 (sealed file demo)".

Open the page's ⋯ menu at the top right, choose Apps, then Seal attachments…. Our own README says "choose Seal attachments…" and skips the Apps step. On current Confluence Cloud it sits one level down, under Apps. You'll need it. (Yes, our README is wrong there. It's on the list.)

The dialog lists every file on the page with a checkbox. Tick the one you want. Then set two fields:

Seal holds for. The first option is the space default (it read "Space default (1 day)" on our demo space). The rest of the list runs from 1 day to 1 year.
Note (optional). Why it's sealed, up to 300 characters. People see it with the seal.

I'd pick the shortest duration that covers the job. A seal that outlives its reason just trains people to ask for edit access.

Click Seal 1 attachment. If your site has signed seal actions switched on, you'll get a Sign this action box first. Type the current code from your authenticator and click Sign and continue. If you've never set one up, the app sends you to its My work page to scan a QR code. That takes a minute. On a default site you won't see any of it.

You should see a green 1 attachment sealed. bar. The file's row now carries a SEALED · YOURS label and the expiry.

The byline item under the title changes to Sealed (1). Good. Now go and break it.

Step 3: Overwrite the sealed file as another user

Sign in as the second account and upload a file with the same name to the same page. In the browser, that's dragging the file onto the page or uploading it from the attachments list. Confluence treats a matching name as a new version of the same attachment.

We did it from the command line, so the timestamps would be exact. A PUT on the page's attachments creates or updates by filename:

export SITE=https://your-site.atlassian.net
export PAGE_ID=31129606          # the page id from the page's URL
export SECOND_TOKEN=...          # the second account's API token

curl -s -u "second.user@example.com:$SECOND_TOKEN" -X PUT \
  "$SITE/wiki/rest/api/content/$PAGE_ID/child/attachment" \
  -H 'X-Atlassian-Token: no-check' \
  -F 'file=@price-list.csv' -F 'comment=Updated A-100 price' \
  | jq -r '.results[0] | "\(.id) \(.title) v\(.version.number) \(.version.by.displayName) \(.version.when) \(.version.message)"'

att31490051 price-list.csv v2 Gabriela Perdum 2026-10-02T21:05:20.666Z Updated A-100 price

Confluence accepted it as v2. That part is meant to happen. Don't panic. Wait five seconds, then reload the page as yourself.

As the owner, you should see a banner at the top: "A change to your sealed attachment price-list.csv was reverted automatically."

The person who uploaded gets told too. On a default site they get a page comment headed "Your change was undone", which says the file is sealed and how to ask for edit access. We didn't see that exact comment, because our demo site has the app's comment switches on. There, a fuller "Seal Violation" comment went out, naming both of us. Either way, each reverted upload gets its own comment. Three stubborn uploads, three comments.

Step 4: Read the attachment version history in Confluence

Confluence's attachment version control is where you can see what happened. Open the page's attachments list. The quickest way is this URL, with your page id:

https://your-site.atlassian.net/wiki/pages/viewpageattachments.action?pageId=31129606

Expand the file. Each overwrite leaves two rows: the upload that was rejected, and above it a version by Sentinel Vault with the comment "(Sentinel Vault automatically reversed modifications)".

Ours has six versions because we kept going after the first revert, and that's how the bug showed up. You should see three: your original, the other account's upload, and the app's revert. The rejected upload stays there. If it turns out to be the right file, nobody lost it.

Step 5: List attachment versions with the Confluence REST API

The history page is fine for one file. It doesn't scale. For an audit, or to prove the revert really restored the same bytes, use the REST API. First, the attachment id:

export TOKEN=...                 # your own API token

curl -s -u "you@example.com:$TOKEN" "$SITE/wiki/api/v2/pages/$PAGE_ID/attachments" \
  | jq -r '.results[] | "\(.id) \(.title) v\(.version.number)"'

It should print one line per file: id, name and current version. This one is from our test site, where the file was still at v2:

att380698656 price-list.csv v2

If you used the PUT in Step 3, the id is already the first field it printed. Then list the versions. The call should print three lines, newest first:

export ATT_ID=att31490051

curl -s -u "you@example.com:$TOKEN" "$SITE/wiki/api/v2/attachments/$ATT_ID/versions" \
  | jq -r '.results[] | "\(.number)  \(.createdAt)  \(.message)  minorEdit=\(.minorEdit)"'

3  2026-10-02T21:05:25.239Z  (Sentinel Vault automatically reversed modifications)  minorEdit=true
2  2026-10-02T21:05:20.666Z  Updated A-100 price  minorEdit=false
1  2026-10-02T20:56:13.026Z  Signed Q4 list  minorEdit=false

That's your revert time. Read it off the timestamps. Version 2 landed at 21:05:20.666 and version 3 at 21:05:25.239, so 4.6 seconds. The other two production runs came in at 2.6 and 2.8. The app marks its own upload as a minor edit.

To prove v3 is really v1, hash each version:

for v in 1 2 3; do
  curl -sL -u "you@example.com:$TOKEN" \
    "$SITE/wiki/rest/api/content/$PAGE_ID/child/attachment/$ATT_ID/download?version=$v" \
    | shasum -a 256
done

9ae3291c…bdd9  -
103987535b…055e  -
9ae3291c…bdd9  -

(Hashes shortened.) Versions 1 and 3 match. Version 2 is the one that got rejected. Same bytes, proven. Keep the -L. Without it, Confluence answers 302 (we checked) and you hash a redirect. Jira does the same with a 303, written up in Jira attachment download: 303, not your file.

Step 6: Release the seal to unlock the attachment

When the file is allowed to change again, release it. Don't leave seals lying around. Click Sealed (1) in the byline (or open ⋯, Apps, Seal attachments… again) and press Release on the file's row. On a site with signed actions, you'll type a code here too.

The Overview tab then reads "SEALS ON THIS PAGE · 0", and the activity list says you unsealed the file.

We uploaded once more after releasing and waited 30 seconds. The upload stayed. Unlocked. If you'd rather not release by hand, don't: a seal stops enforcing the moment its time runs out. After that the owner sees an overdue notice on the page once a day, and after the third one the app releases the seal (those are the defaults; reminder comments need the app's comment switch on).

Give one person edit access instead of unlocking (optional)

Sometimes one colleague needs to change the file and nobody else should. Releasing is the wrong tool for that. Don't. On the Overview tab, open the file row's ⋯ and choose Give edit access…, then pick the person.

What we measured: Gabriela's upload after the grant stayed, and it became the new sealed version. When her access was revoked (under "Editors with access" in the full attachments view), her next upload was reverted to her granted version, not to my original. A grant moves the seal forward. That's the behaviour I want. Someone without edit access can press Request edit on the file instead. That one we only read in the code, not tested from the requester's seat.

If it didn't work

You sealed it, uploaded a fix yourself, and the next overwrite brought back the old file. That's my bug, in 6.6.0. Your own upload is allowed, but the seal doesn't adopt it as the new sealed version. In our run my account uploaded v4 with a correction. Gabriela's account then uploaded v5, and the app restored v1's bytes as v6. My correction was still in the history, but it wasn't current anymore. That one's on me. My app, my bug. The workaround: after uploading your own new version, press Release and seal the file again. The new seal adopts your version. Releasing drops any edit access you gave, and the new seal starts a fresh duration, so give access again afterwards. It's logged for a fix, and until one ships, do it that way.

"Attachment is already sealed by another user". Somebody got there first. Ask them for edit access, or wait for the seal to run out. An expired seal from someone else is cleared when you seal.

"You do not have permission to seal this file". You can view the page but not edit it. Sealing follows Confluence's own edit permission: the dialog still opens, but the server refuses anyone who can't edit the page.

"This page is Approved — only its approvers or a space admin can seal on it." The page is Approved in a Sentinel Vault workflow. Ask an approver, or seal before approval.

"Set up your signature first". Your site signs seal actions. Use Set up on My work, scan the QR code with an authenticator app, type the first code and come back. Five wrong codes lock signing for 15 minutes.

Someone renamed the file and nothing was reverted. Correct, renames aren't reverted. We tested it on our test site's development build: the rename stuck. But the next overwrite of the renamed file was reverted to the sealed bytes. The seal follows the attachment id, so the content is still protected under its new name.

Someone moved the file to the trash. That one comes back. Fast. Gabriela's account deleted the sealed file over the API, and it was current again within two seconds, with no new version. If the person who sealed it trashes it, though, the seal is released along with it.

The upload was never reverted. Check the seal hasn't expired: an expired seal stops enforcing at once, even though it stays listed until the app releases it about three days later. If the revert itself fails (the app gives up after three attempts), the owner gets a notice saying so. There's no later sweep that catches a missed upload. Read that notice.

What a seal does not do

A seal protects a file's content, not who can read it. Everyone who can see the page can still view and download the sealed file. If you need that restricted, it's a Confluence page restriction, not a seal.

It doesn't stop the save. For a few seconds the rejected file is the current version, and anyone who downloads it in that window gets the rejected file.

Seals made through Sentinel Vault's own REST API skip the authenticator check, even on a site that signs everything else. So does a sealed section created by inserting the macro in the editor. If your auditors care about signatures, keep sealing in the UI. I would.

And it isn't a check-out tool. Tools like Lockpoint are built around checking a file out before you edit it, and Sentinel Vault has no check-out at all. It lets the upload in and puts the sealed file back. For a signed price list or a contract, putting it back is exactly what you want. For a team that edits the same Word file all day, it's the wrong tool. I'd tell you that before you buy it.

There's more in the app, like section seals, approvals and the AI review, and it's all on the Sentinel Vault page. For locking attachments, the six steps above are the whole job. That's it.

What you have now

[[takeaways]]

You have a file sealed on a Confluence Cloud page, an overwrite by a second account reverted in seconds, both versions in the attachment history and in the REST API, and the seal released.
The path is ⋯, Apps, Seal attachments…. Anyone who can edit the page can seal, unless the page is Approved in a workflow.
A seal reverts, it doesn't block. The rejected upload stays in the history, and the app's version carries "(Sentinel Vault automatically reversed modifications)".
Prove a revert with GET /wiki/api/v2/attachments/{id}/versions and a sha256 of each version. Keep -L on the download.
Give edit access when one person should change the file. Their upload becomes the new sealed version.
In 6.6.0, after uploading your own new version of a file you sealed, release and seal again.

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.

Suppressing the email when Jira Automation adds a comment (and why sendNotifications does nothing)

Mihai Perdum — Sat, 03 Oct 2026 23:50:35 +0000

Suppressing the email when Jira Automation adds a comment (and why sendNotifications does nothing)

Key takeaways

sendNotifications is not a parameter of the automation Comment action, so nothing reads it. Your export proves the key is stored; your inbox proves it is not used.
The Jira comment REST endpoint ignores unknown keys silently. I posted sendNotifications, notifyUsers and totallyMadeUpKey12345 to it and all three returned 201.
notifyUsers is real — on Edit issue, on Update comment and on the worklog endpoints. The one place it does not exist is ADD comment, which is exactly the operation automation performs.
Sending a typed parameter a bad value tells you whether it is declared on that endpoint. It does NOT tell you whether your account may use it — that is a separate permission gate, and a missing permission is ignored silently.
I verified the REST mechanics on a live Jira Cloud site. I did not verify that the email itself stopped, because no API reports it — treat suppression as documented, not measured.

Somebody on the Atlassian Community had done everything right and it still did not work. They exported a Jira Automation rule, hand-added "sendNotifications": false to the jira.issue.comment action, re-imported it without an error, exported it again to check — the key was still there — and then watched the rule send "Issue Commented" email to every watcher anyway. They were staring down a backfill of about 85,000 work items.

That is a good bug report, and the answer is not the one people usually give.

The flag does nothing because it is not a parameter of that action. Nothing in the automation engine looks at it. Their export proved the key was stored; their inbox proved it was not read. Those are two different things, and Jira's APIs are unusually willing to let you confuse them.

Everything below was checked on 2 August 2026 against a live Jira Cloud site. Ticket statuses and vote counts move; I have dated each one so you can tell when this page has gone stale.

Check the rule builder before you touch any of this

Start here, because if it applies to you the rest of this article is unnecessary.

AUTO-602's own description opens: "Currently, we can only suppress Email notifications for the *Edit Issue** action performed by automation or Jira."* That sentence implies the automation Edit work item action has an email-suppression control. Historically it did — a "send notifications" checkbox.

I could not confirm its current state. Atlassian's automation actions documentation does not list any notification option for either the Edit or the Comment action, and community reports disagree about whether the checkbox still exists in the current rule builder. So: open your own rule builder, open an Edit work item action, and look. If the control is there, and you can restructure your rule to set a field rather than post a comment, that is the cleanest answer available and it is entirely in-product.

If it is not there, or you genuinely need a comment, carry on.

Why the flag is ignored

The automation Comment on work item action exposes the comment text, smart values inside it, and the comment's visibility. Atlassian describes it as "Adds a comment to a work item. You can use smart values to reference work item fields to personalize the comment. You can also set the comment visibility." There is no notification control documented, and no hidden one that anybody has demonstrated.

The round-trip fooled everybody because the exported JSON survives re-import untouched. The most likely explanation is that the importer keeps keys it does not recognise and hands the action only the fields the action knows about — I did not reproduce that inside the automation engine, so treat the mechanism as inference. What is not inference is the behaviour of the platform underneath it, which I did test, and which does exactly the same thing.

Do not conflate this with the comment visibility setting, which is real and documented on the action. Visibility controls who can see the comment — in Jira Service Management, whether it is internal or customer-facing. It is a different axis and it does nothing to Jira notification-scheme email.

Where notifyUsers actually exists

notifyUsers=false is a genuine Jira Cloud parameter. It appears on Edit issue, on Update comment, and on the three worklog endpoints. The one operation that does not have it is add comment — which is precisely the operation an automation rule performs when it comments.

That gap is what JRACLOUD-97682 ("Add notifyUsers=false option to comments API") exists to close. Read 2 August 2026: Gathering Interest, Unresolved, 1 vote, 2 watchers, created 4 March 2026. Its Workaround section gives the route round the gap — add the comment as part of an issue edit:

curl --request PUT \
  --url 'https://your-site.atlassian.net/rest/api/3/issue/ABC-1?notifyUsers=false' \
  --user 'you@example.com:YOUR_API_TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{
    "update": {
      "comment": [
        { "add": { "body": {
            "type": "doc", "version": 1,
            "content": [ { "type": "paragraph", "content": [
              { "type": "text", "text": "Backfilled by the migration script." } ] } ]
        } } }
      ]
    }
  }'

So "just call the API instead of using automation" is only a fix if you call that endpoint. Posting to /issue/{key}/comment gets you nowhere no matter what you attach to it.

AUTO-602 is the ticket to cite for the asymmetry itself. Read 2 August 2026: Gathering Interest, Unresolved, 1,068 votes, 513 watchers, created 29 April 2020. Six years of votes, still a suggestion.

Quote it carefully. Its title is scoped to in-product and in-app notifications, but its description asks for "email notifications as well as the Notifications on the instance". People cite it for one and get corrected on the other; the accurate framing is that the title and the description cover different scopes, and the opening sentence is what settles the Edit-versus-everything-else question.

Do not reach for JRACLOUD-78140 ("Implement notifyUsers parameter to a number of API calls"). Checked 2 August 2026: Closed, Won't Do, 9 votes — and its description names create, bulk-create, assign and transition. The add-comment endpoint is not in it. It is the nearest-looking ticket to the problem and it is the wrong one.

Telling a real parameter from one Jira is only humouring you

When I ran these calls against a live site, every route returned a success code. That tells you nothing on its own. So I sent each endpoint a parameter that cannot exist, and then sent the real parameter a value it cannot accept.

Call	notifyUsers=false	notifyUsers=notaboolean	madeUpParam=notaboolean
POST /rest/api/3/issue/KEY/comment	201	201	201
PUT /rest/api/3/issue/KEY	204	400	204
PUT /rest/api/3/issue/KEY/comment/ID	200	400	200

On the edit and update-comment endpoints a bad value comes back as Failed to convert 'notifyUsers' with value: 'notaboolean'. On the add-comment endpoint the same garbage sails through with a 201, exactly like a parameter I invented on the spot. That is the difference between a parameter the endpoint declares and one it has never heard of.

The same silence applies in the request body. Posting three unknown keys alongside a valid comment:

Extra key in the POST body	Result
sendNotifications	201
notifyUsers	201
totallyMadeUpKey12345	201

All accepted, all ignored, none present on the created comment when I read it back — its keys are exactly author, body, created, id, jsdPublic, self, updateAuthor and updated.

What this test does not prove

I want to be precise about this, because the obvious conclusion is wrong in two directions.

The 400 fires before the handler runs. Send it against a work item that does not exist and you still get a 400 rather than a 404:

PUT /rest/api/3/issue/NOSUCHPROJ-99999?notifyUsers=notaboolean   -> 400
PUT /rest/api/3/issue/NOSUCHPROJ-99999                           -> 404

That is query-string type binding, not the feature working. A parameter can be declared, type-checked, and still do nothing for you: overrideScreenSecurity is documented as available to Connect and Forge apps, and sending it notaboolean as an ordinary API-token caller still returns 400.

And it only works on typed values. expand is unquestionably read — ask for expand=renderedBody and you get a renderedBody field. Ask for expand=totalgarbage and you get a cheerful 200 and no complaint, because it is a string and any string is valid.

So the honest scope: sending a bad value to a typed parameter tells you whether that parameter is declared on that endpoint. It does not tell you the parameter is honoured for your account, and it tells you nothing at all about string parameters. It is a fast way to rule a route out — which is exactly what it does for add-comment — not a way to rule one in.

The permission gate is the part that bites

notifyUsers=false requires Administer Jira or Administer Projects on the acting account. Without it the parameter is dropped: the edit still happens, the comment still lands, and the mail still goes out. Nothing fails, nothing warns you.

Check for both, with project context, or you will get a misleading answer:

curl -s -u "$AUTH" \
  "$SITE/rest/api/3/mypermissions?projectKey=ABC&permissions=ADMINISTER,ADMINISTER_PROJECTS"

Asking for ADMINISTER alone returns only the global permission, so a project administrator without global admin reads false and wrongly concludes they cannot do this. Either one being true is enough.

Doing it safely

Look in the rule builder first if the Edit work item action still offers a notification checkbox and your rule can set a field instead of commenting, use that and stop here
Check the permission with project context GET /rest/api/3/mypermissions?projectKey=ABC&permissions=ADMINISTER,ADMINISTER_PROJECTS, and remember a missing permission is dropped silently rather than refused
Run it on five work items, with yourself watching add yourself as a watcher, fire the edit-route call, and check your own inbox. This is the only step that tests suppression rather than mechanics
Take the backfill out of the rule entirely a one-time catch-up of 85,000 items and a steady-state trickle are different problems; script the backfill against the edit endpoint and let the rule keep handling only new matches
If you need certainty rather than a workaround, use the notification scheme empty the recipients on the Issue Commented event for the duration of the backfill, then restore them

Step 5 is the unglamorous option and the only one that depends on nothing undocumented. It is reversible, and it suppresses the email because there is nobody left to send it to.

The event is Issue Commented, event id 6. On the site I checked, its recipients were Current Assignee, Reporter and All Watchers — which is why a backfill across tens of thousands of items becomes tens of thousands of emails.

Before you edit a scheme, find out which one the project actually uses and how many other projects share it:

# which scheme is bound to this project
curl -s -u "$AUTH" "$SITE/rest/api/3/project/ABC/notificationscheme" \
  | python3 -m json.tool

# how many projects each scheme is bound to
curl -s -u "$AUTH" "$SITE/rest/api/3/notificationscheme/project?maxResults=50" \
  | python3 -m json.tool

On the site I tested, the project's scheme was id 10000 and that same scheme was bound to eleven projects. Editing it to quiet one backfill would have silenced comment mail across all eleven. If yours is shared, copy the scheme first and point only the target project at the copy.

Emptying a notification-scheme event affects every rule and every human action on that project, not just your backfill. Write down what you removed before you remove it, and put it back the same day.

What I verified, and what I did not

I checked the REST mechanics on a live Jira Cloud site: which endpoints declare notifyUsers, which reject a bad value, which unknown keys are silently swallowed, what survives onto the stored comment, and whether a comment added through the edit route shows up in the issue history. It does not — the changelog stayed empty across every route, so you cannot use history entries to tell the two paths apart.

I did not verify that the email stopped arriving. No Jira Cloud API reports whether a notification was queued or sent, so the only honest test is a real mailbox, which is step 3 and which you have to run on your own site. Atlassian documents the edit-route workaround and the endpoint type-checks the parameter; those two facts are why I would try it. They are not a measurement, and I am not going to present them as one.

Three more limits. This is Jira Cloud — the Data Center notification model differs. I tested the REST endpoints rather than the automation rule importer, so the importer explanation remains inference. And the state of the Edit action's notification checkbox is genuinely unresolved: the docs omit it, AUTO-602's opening sentence implies it, and community reports conflict. Check your own instance rather than trusting any of us on that one.

The wider habit

A 2xx response and a surviving JSON key both feel like confirmation, and neither is. Jira accepts almost anything you send it and quietly uses the parts it recognises.

The automation rule API does the same thing with a whole object rather than one key. A rule created with a scope ARI and a trigger filter that disagree returns 201, and the trigger you get back is not the trigger you sent — the server rewrote it to agree with the scope, without an error, a warning, or a note in the response.

So when a flag does not appear to work, stop trying to prove it works and try to prove it is even declared. Send a typed parameter something it must reject. If nothing complains, you are on a dead end and you have your answer in one call — then go and check the permission, because that is the gate that will actually decide whether it does anything for you.

That workaround is no longer untested. I built a bed on a live Cloud tenant and ran it, and the result is not the clean yes it looks like: every comment route raises the Issue Commented event rather than Issue Updated, which is the event notifyUsers is documented against. The bed itself also turned out to have four separate ways of reporting success while sending no mail at all.

*The question behind this piece came from a [*thread on the Atlassian Community](https://community.atlassian.com/forums/Automation-questions/quot-sendNotifications-false-quot-in-Automation-quot-Add-comment/qaa-p/3269762#M16384)[, where the asker had done more homework than most bug reports contain. If you are untangling automation or notification behaviour at scale and want a hand, ](https://community.atlassian.com/forums/Automation-questions/quot-sendNotifications-false-quot-in-Automation-quot-Add-comment/qaa-p/3269762#M16384)[that is the kind of work we do](https://leanzero.net/contact?utm_source=devto&utm_medium=referral&utm_campaign=crosspost)[.](https://leanzero.net/contact?utm_source=devto&utm_medium=referral&utm_campaign=crosspost)

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.

Repair the Confluence Cloud pages your migration quietly broke, one space at a time

Mihai Perdum — Sat, 03 Oct 2026 20:45:25 +0000

Repair the Confluence Cloud pages your migration quietly broke, one space at a time

Key takeaways

END STATE: one space repaired, with a reviewed JSON plan, a backup of every original page, and the fix confirmed in a browser rather than in a 200 response.
Site admin is NOT space admin. Grant yourself space admin first or the run collects 403s for an hour.
A storage-format rewrite that is syntactically valid and semantically wrong writes successfully and reports success. The API cannot tell you it is wrong; only the rendered page can.
Discovery is CQL, so it is only as good as the index. Dump the raw storage XML of a few matches on YOUR tenant before a full run — storage format varies by app version.
Restricted pages block app-data migrations. Back the restrictions up, strip them for the run, restore them on Cloud with usernames resolved to accountIds.

The migration report said the pages moved. The pages did move. Then someone opened a runbook that had a formatted table in it and found a grey box reading Unknown macro, and the question arrived: what else looks like that, and how would we know?

A Confluence Data Center to Cloud migration moves page content. It does not guarantee that what is inside the page still works, and the things that break do not appear in the migration report because from the migration's point of view nothing failed. The bytes arrived.

This walks through repairing them on one space, with the two habits that make it safe: a plan you read before anything is written, and a check that happens in a browser rather than in an HTTP status code.

Prerequisites

Node 18 or later. Verified on v24.15.0.

A Confluence Cloud API token from id.atlassian.com → Security → API tokens, used as Basic auth with your account email.

Space admin on every space you intend to edit. Site admin is not enough — this is the step everyone skips, and step 1 exists entirely to fix it.

Read access to the source Data Center instance for the tools that compare against it.

The Confluence Migration Toolkit, Apache-2.0 and free. Seven tools, no dependencies beyond dotenv and a parser where XHTML genuinely has to be parsed.

About an hour for one space.

Grant yourself space admin, because site admin does not include it.
Dump the raw storage XML of a few matches before trusting any discovery query.
Build a plan and read it every tool writes one before it writes anything else.
Repair the broken HTML macros, choosing the replacement mode deliberately.
Flatten the nested macros that Cloud's editor refuses to open.
Re-resolve the identity parameters that still hold DC usernames.
Back up, strip and restore page restrictions around an app migration.
Verify on the rendered page, which is the only check that can fail honestly.

Step 1 — Grant yourself space admin

Confluence Cloud scopes administration per space, and a site admin is not automatically a space admin. A site admin can see a space without being able to edit every page in it, which means a script authenticating as you will authenticate perfectly and then be refused on the write.

cd grant-space-admin
npm install
cp .env.example .env     # CLOUD_BASE_URL (include /wiki), CLOUD_EMAIL, CLOUD_API_TOKEN
node main/grant_space_admin.js --dry-run

How you know it worked: the help text should print the flags below, and the dry run should list the spaces it would touch without granting anything. Confirm --dry-run is present before you run anything without it.

Grant Space Admin — Confluence Cloud

Adds the current API-token user as an administrator on every Confluence Cloud
space (or a subset via --space). Additive only: existing permissions are
preserved. Idempotent.

Usage:
  node main/grant_space_admin.js [options]

Options:
  --dry-run              Preview without granting
  --space <KEY>          Restrict to specific space(s), repeatable or comma-sep
  --skip-personal        Exclude personal spaces (keys starting with ~)
  --full-grant           Grant full admin-equivalent permission set
                         (otherwise just administer:space + read:space)
  --concurrency <N>      Parallel workers (default: 3)
  --help                 Show this help

Two words in that output matter more than the rest. Additive means existing permissions are preserved rather than replaced, so running it does not quietly become a permissions rewrite. Idempotent means a second run is not a second grant. Both are properties you should confirm in any tool you point at a permission scheme, because the failure mode of getting either wrong is one you discover from a colleague rather than from a log.

Start with --space on a single key. There is no reason for your first run to be site-wide.

Step 2 — Dump the raw storage XML before you trust discovery

Every one of these tools finds its work with CQL, which means discovery is exactly as good as the search index and as your assumption about what the macro looks like in storage format. That assumption is the part that breaks, because storage format varies by app version. The macro you are searching for may be named something slightly different on your tenant than on the one a tool was written against.

So before a full run, print the raw storage XML of a handful of matches and read it.

node main/sync_html_macros.js --space ENG --limit 5 --plan-only

How you know it worked: you should see a plan file written under logs/ and a match count that is plausible for the space. If it reports zero, do not conclude the space is clean — conclude the query did not match, and go and look at a page you know is broken to see what its storage format actually contains. A count of zero and a genuinely clean space are indistinguishable from the outside, and only one of them is good news.

Step 3 — Build a plan and read it

Every tool here runs in two phases, and the split is the safety property, not a convenience. A read-only plan phase discovers affected pages and writes a reviewable JSON file. An execute phase acts on that file. --dry-run runs the execute phase with the PUT suppressed.

node main/sync_html_macros.js --space ENG --plan-only
# read the plan
node main/sync_html_macros.js --space ENG --execute-only --dry-run

The plan is a file you can open, grep and diff. That matters because the failure this catches is not a crash — it is a plan that is internally consistent and wrong, which executes beautifully and produces the wrong pages. You cannot catch that by watching a progress bar; you catch it by reading twenty lines of JSON and noticing that a page you know well is about to be rewritten in a way you did not expect.

How you know it worked: the dry run should report the same page count as the plan and write nothing. If the counts differ, the plan is stale — rebuild it rather than reasoning about the gap.

Step 4 — Repair the broken HTML macros

This is the common case. An HTML or CSS macro whose Cloud build differs, or does not exist at all, leaves either an Unknown macro placeholder or the original XML sitting in page storage, unrendered and unreachable.

The repair extracts the raw content from the DC page's storage format and replaces the broken block on Cloud. There are three modes and choosing the wrong one is the main way this goes wrong:

  "raw"   - Replace the entire macro block with inline content (default).
            Use when the macro app is NOT installed in Cloud.
  "macro" - Preserve the ac:structured-macro wrapper but fix the CDATA content.
            Use when the macro app IS installed in Cloud but content is wrong.
  "code"  - Wrap DC content in a Code macro block (preserves HTML/CSS via CDATA).
            Use when raw HTML gets stripped by Cloud's storage sanitizer.

That third mode is worth understanding before you need it. Cloud runs a storage sanitiser on write, and raw HTML pushed into a page can be stripped by it — which is precisely why the code mode exists, wrapping the content in a Code macro whose CDATA survives. The consequence to plan around is that the request succeeding tells you the write was accepted, not that the content is still there.

node main/sync_html_macros.js --space ENG --replacement-mode raw --limit 1

How you know it worked: run it against exactly one page, then open that page in a browser. Not the API response — the page. A rewrite that is syntactically valid and semantically wrong writes successfully and reports success.

Step 5 — Flatten the nested macros

Nested bodied macros are legal on Data Center and unsupported by Cloud's Fabric editor. The symptom is distinctive: the page renders wrong and the editor refuses to open it, so the obvious repair — fix it by hand — is unavailable exactly where you need it.

The fix rewrites the structure so the previously-nested macro becomes a sibling instead of a child, using a split-around-child strategy that handles arbitrary nesting depth.

How you know it worked: open the page in the editor, not just the viewer. The viewer may render a page the editor still refuses. Editing is the capability you lost, so editing is the capability to test.

Step 6 — Re-resolve the identity parameters

Anything that stored a DC username or group name stops resolving on Cloud, because Cloud is keyed on accountId and groupId. Show If and Hide If visibility macros are the ones that bite. The documented behaviour is that they stop showing protected content — the parameters still name DC usernames and group names, the Cloud build of the app expects ids, the condition no longer matches anyone, and content that was meant to be visible to a group becomes visible to nobody.

Note which direction that is, because it is the recoverable one. Content that has gone missing gets reported by the person who needed it. I have not established what happens in the opposite direction and I am not going to guess at it here — but the reason to test both is that a positive-only test cannot tell the two apart.

The repair resolves the stored users and user-groups parameters against Cloud and rewrites them to ids.

How you know it worked: pick a page whose visibility macro names a group you belong to, and confirm the protected content is visible to you again. Then check a page restricted to a group you are not in and confirm it stays hidden. Testing only the first case cannot distinguish a repaired macro from one that has stopped filtering.

Step 7 — Back up, strip and restore page restrictions

App-data migrations fail on restricted content, and the error is specific enough to search for:

Some data are still not migrated. If these space(s) contain restricted pages,
please run the migration script provided.

The cause is that the migration runs as an app user which page restrictions exclude. The restrictions are the blocker, and the only reliable fix is to remove them for the duration and put them back afterwards.

Three scripts, in order, and the middle one is the one to be careful with:

node check_pages.js                    # DC, read-only: what restrictions exist
node remove_restrictions_dc.js         # DC: full backup JSON, THEN remove
node restore_restrictions_cloud.js     # Cloud: re-apply, resolving usernames to accountIds

How you know it worked: check_pages.js is read-only and exists to be run first — it reports whether each content id exists and what restrictions it carries. Run it before and after the whole cycle and compare. The backup JSON written by the remove step is your undo, and it is the only one; if that file is lost between stripping and restoring, the restrictions are gone and nobody will notice until the wrong person opens the wrong page.

Do not run the remove step on a Friday.

Step 8 — Verify on the rendered page

Every check in this article has pushed toward the same place, so it is worth saying plainly.

A storage-format rewrite goes through Confluence's API. The API validates that your XHTML is well-formed. It does not, and cannot, validate that the page still means what it meant — that the table still has its columns, that the macro still has its body, that the content a reader needs is still on the page rather than stripped by a sanitiser. Syntactically valid and semantically wrong writes successfully and reports success.

So the verification is not a status code and not a count. Run every tool against one space, then one page, and open the result in a browser before you let it near the rest of the site. That is slower for the first page and very much faster than discovering three weeks later that four hundred pages have an empty box where a runbook used to be.

The same instinct applies on the Jira side of a migration, where logic that migrated in form but not in meaning fails the same silent way — and it belongs on the gap list you build before you start rather than being discovered afterwards.

Key takeaways

Grant space admin before anything else. Site admin does not include it, and without it the tools authenticate correctly and then collect 403s on every write.
Confirm the storage format on YOUR tenant. Discovery is CQL and storage format varies by app version, so a zero-match result means "the query did not match", not "the space is clean".
Read the plan. The dangerous failure is not a crash — it is a plan that is internally consistent and wrong, which executes perfectly and produces the wrong pages.
Choose the replacement mode on purpose. Cloud sanitises storage on write, so raw HTML can be accepted, stripped and stored as an empty page with a 200 response. The code mode exists for exactly that.
Verify in a browser, and test both directions. A positive-only check cannot tell a repaired visibility macro from one that has stopped filtering. The API cannot tell you a page is semantically wrong; only the page can.

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.

Skip the migration writes that change nothing, without skipping the ones that matter

Mihai Perdum — Sat, 03 Oct 2026 20:43:44 +0000

Skip the migration writes that change nothing, without skipping the ones that matter

Key takeaways

END STATE: a re-run that writes only what differs, with a false-SAME test suite you run BEFORE trusting it with a write.
Our canonicaliser nulled any object holding an empty text key. A mention's attrs carries one, so attrs.id vanished and two DIFFERENT users hashed the same. Fixed by guarding on node type.
Hash the PLANNED value against the destination. Source-against-destination never matches for any entity your pipeline rewrites.
Both hashers collapse whitespace inside code — a mangled Python indent will be skipped as a no-op. Exclude code bodies.
Pick the hasher by BODY FORMAT, not by product: Confluence v2 defaults to atlas_doc_format, which is ADF.

Re-running a migration script should be cheap. Usually it is not: the second run rewrites every entity, bumps every version number, and spends the same rate-limit budget to produce bytes that are already there.

The fix is small — hash what you are about to write, hash what is there, skip when they match. I wrote that up, then went looking for cases where the hash is wrong, and found one that would have skipped writes it should have made. So this is the pattern and the test suite, because the second is what makes the first safe.

Prerequisites

Node 18 or later. Verified on v24.15.0.

Two hashers from the migration toolkit: semanticHash in adf-builders.js for ADF, and BackupManager.storageHash in backup-manager.js for Confluence storage XHTML. Note the second is a static method, not a bare export.

No tenant, no credentials, no deploy. Everything runs locally against literals, which is the point: you want this proven before it decides whether to skip a production write.

About thirty minutes.

Write the harness so every claim below is a command you can run.
Prove it ignores cosmetic difference, and still catches a real edit.
Hunt for a false SAME, which is the failure that loses data.
Compare the planned value against the destination, never the source.
Check what a Cloud-to-Cloud move preserves and what it does not.
Pick the hasher by body format, not by product name.
Record the skip so an audit can tell it from an entity you never reached.

Step 1 — Write the harness

Every output block below comes from this file. Save it as check.js beside the two templates.

const adf = require("./adf-builders.js");
const { BackupManager } = require("./backup-manager.js");

const p = (t) => ({ type: "doc", version: 1,
  content: [{ type: "paragraph", content: [{ type: "text", text: t }] }] });
const h = (d) => adf.semanticHash(d);
const row = (label, a, b, want) => {
  const same = h(a) === h(b);
  console.log(`  ${same === want ? "ok  " : "!!  "}${label.padEnd(44)}` +
              `${same ? "SAME" : "DIFF"}   want ${want ? "SAME" : "DIFF"}`);
};
module.exports = { adf, BackupManager, p, h, row };

How you know it worked: node -e "require('./check.js'); console.log('harness ok')" should print harness ok and nothing else. If it throws on BackupManager, you destructured a bare export that does not exist — storageHash hangs off the class.

Step 2 — Prove both directions

A hash that returns SAME for everything is worse than no hash, because it silently stops migrating. So run the negative control in the same breath as the positive one.

node check-cosmetic.js

=== should be SAME — cosmetic difference only ===
  ok  identical documents                         SAME   want SAME
  ok  collapsed whitespace                        SAME   want SAME
  ok  leading/trailing space                      SAME   want SAME
  ok  empty marks array present                   SAME   want SAME
  ok  key order differs                           SAME   want SAME

=== should be DIFFERENT — a real edit ===
  ok  one word changed                            DIFF   want DIFF
  ok  case changed                                DIFF   want DIFF

How you know it worked: every line should start ok. Case matters — the canonicaliser collapses whitespace but does not lower-case, which is right for prose and wrong for URLs, where scheme and host are case-insensitive. If you hash links, know that HTTPS://… and https://… will differ.

Step 3 — Hunt for a false SAME

This is the step that matters, and it is the one I nearly skipped. A false DIFFERENT costs you rate-limit points. A false SAME skips a write that should have happened, and nothing anywhere reports it.

Ours had one, in the code that had been in production for months:

  raw mention A     : {"type":"mention","attrs":{"id":"accountid-AAAA","text":"","accessLevel":""}}
  raw mention B     : {"type":"mention","attrs":{"id":"accountid-BBBB","text":"","accessLevel":""}}
  canonical A       : {"attrs":null,"type":"mention"}
  canonical B       : {"attrs":null,"type":"mention"}
  semanticHash equal: true

Two mentions of different people, hashing identically. The canonicaliser had this:

if (k === "text" && typeof v === "string") {
  v = v.replace(/\s+/g, " ").trim();
  if (!v) return null;          // <- nulls the ENCLOSING OBJECT
}

The intent was to drop empty text nodes. What it actually did was null any object holding an empty *`*text* key* — and a mention's attrs holds one. [Atlassian's ADF spec](https://developer.atlassian.com/cloud/jira/platform/apis/document/nodes/mention/) makes attrs.text optional while attrs.id is required, and our own mention(accountId) helper emits text: "" when no display name is passed. So attrs was nulled, taking attrs.id` with it, before anything was compared. Emoji and status nodes have the same shape and were annihilated the same way.

Play that forward in a migration. Run one writes a wrong accountId. You spot it, fix the mapping, re-run — and the hash reports the destination already matches. The write is skipped, the plan records success, the audit is clean, and the wrong user stays there forever.

The fix is to guard on the node type rather than the key name:

const isTextNode = node.type === "text";
// …
if (!v && isTextNode) return null;   // an empty TEXT NODE is nothing

How you know it worked: after the fix, two mentions with different ids should print DIFF, and all seven rows from step 2 should still print ok.

  two users, empty attrs.text:  DIFFERENT   fixed
  built by adf.mention():       DIFFERENT   fixed
  emoji  :A: vs :B:             DIFFERENT   fixed
  status Done vs Todo           DIFFERENT   fixed

And do not read that as the only one. It is the one I found. Two others I can characterise: JavaScript's \s matches a non-breaking space, so text differing only by is skipped; and both hashers collapse whitespace inside code, so a migration meant to repair mangled Python or YAML indentation will treat it as a no-op. Exclude code bodies from the hash. I have not enumerated the rest, and you should not assume the list is closed.

Step 4 — Compare the planned value, not the source

The tempting comparison is source against destination. For any entity your pipeline rewrites — which is the point of a migration — those never match, so nothing is ever skipped and you have added a read per entity for no saving. (For an entity the pipeline leaves alone, they do match; that is the exception, not the rule.)

The correct comparison is planned against destination. It is the same ordering discipline as stamping a plan with the tenant it was built for — a check earns its read only when it compares the two things that can actually differ:

const planned = rewrite(sourceDoc);
const current = await jira.getIssue(key, "description");
if (adf.semanticHash(planned) === adf.semanticHash(current.fields.description)) {
  // skip — see step 7 for how to record it
}

How you know it worked — the two orderings should give opposite answers on the same pair:

  planned-for-B vs live-on-B : SAME  -> correctly skips
  source-on-A  vs live-on-B  : DIFFERENT -> would rewrite forever

One guard before you ship it: semanticHash(null) === semanticHash(undefined) is true, so a rewrite() that returns undefined against an empty destination field skips and reports success. Assert your planned value is a document before you hash it.

Step 5 — Check what a Cloud-to-Cloud move preserves

On Cloud-to-Cloud, a mention with a stable **`accountId*`* and the same cached display name hashes the same on both tenants.** The accountId belongs to the Atlassian account rather than the site, so it survives the move:

  same accountId + same text          SAME  (skip)
  same accountId, display name differs DIFFERENT (write)

That second row is worth knowing: attrs.text is hashed too, so a cached display name that changed between tenants writes even when the identity did not.

Data Center is the opposite case. The user identifier is remapped as part of the move, so a source-versus-destination hash can never match for any mention-bearing document. Note the source representation differs by product — Confluence stores an opaque per-instance key, <ri:user ri:userkey="2c9680f7405147ee0140514c26120003"/>, which the storage format reference calls "the unique identifier of the user". It is not a username, and it means nothing on the destination.

How you know it worked: on a Cloud-to-Cloud plan you should see a meaningful skip rate on mention-bearing content and near zero on anything embedding the old tenant hostname. On a Data Center plan you should see near zero either way until you switch to planned-versus-destination — which is step 4, and on DC it is not an optimisation but the only way the check works at all.

Step 6 — Pick the hasher by body format

The rule is not "Confluence uses storageHash". It is: hash the format you actually fetched.

Confluence Cloud's v2 API defaults to atlas_doc_format, which is ADF — our own client signature is getPageByIdV2(pageId, bodyFormat = "atlas_doc_format"), and the toolkit's notes call it "ADF JSON. Same as Jira's. The new default." Fetch a v2 page with defaults and hand it to storageHash and you get a string hash of serialised JSON, which sorts no keys and skips nothing.

Two semantically IDENTICAL Confluence ADF bodies, different JSON key order:
  storageHash  : DIFFERENT   <- never skips
  semanticHash : SAME        <- correct

Use storageHash only when you asked for body-format=storage. It normalises the three things that change XHTML bytes without changing the page:

.replace(/>\s+</g, "><")     // inter-tag whitespace
.replace(/\s+\/>/g, "/>")    // self-closing form
.replace(/\s+/g, " ")        // runs of whitespace — including inside <pre>

Read that first rule closely, because it is narrower than it looks: it collapses whitespace between tags, where a > is followed by a <. Indentation wrapped around text is a different case. \s+ becomes a single space rather than nothing, and nothing trims, so hello and \n hello\n canonicalise to hello and  hello  — and hash differently.

How you know it worked: three SAME and two DIFFERENT.

=== Confluence storage XHTML ===
  identical                                    SAME  (skip)
  reflowed whitespace                          SAME  (skip)
  indentation BETWEEN tags                     SAME  (skip)
  indentation around TEXT in a tag             DIFFERENT (write)
  real edit                                    DIFFERENT (write)

That fourth row is the harmless direction — a false DIFFERENT costs you a write you did not need, not data. Worth knowing anyway if your source was ever pretty-printed, because it will quietly cost you the whole saving on exactly the content you hoped to skip. And note the third rule is the code-indentation trap from step 3 — it does not stop at markup.

One more thing to expect: localId on panels and task lists, and ac:macro-id on Confluence macros, are stamped per instance and are hashed. On macro-heavy content the skip rate collapses and that is the reason — worth putting on the gap list before you start rather than discovering it mid-run.

Step 7 — Record the skip

The signature is updateEntryStatus(entryId, status, error = null) — that third argument is the error field, so passing a reason there marks every successful skip as an error. Put the reason somewhere it belongs:

planManager.updateEntryStatus(key, "skipped");
planManager.patchEntry(key, { skipReason: "destination already matches" });

How you know it worked: after a second run over unchanged data, every entry should read status: "skipped" with error: null and a populated skipReason. A silently-returned skip leaves {"status":"pending","error":null} — byte-identical to an entity the script never reached, and it will be handed back to you again on every future run.

A semantic hash makes a re-run cheap: canonicalise, hash, skip the writes that would produce bytes already present. Compare the planned value against the destination, never the source, because rewriting is the job.

The part I would carry to any hash you write yourself: the false SAME is the one that costs you. Ours nulled any object holding an empty text key, which erased a mention's accountId — so two different users hashed alike and a corrected user mapping would have been skipped as "already matches", with a clean audit. It is fixed by guarding on the node type, and it existed because the canonicaliser was tested for what it should ignore and never for what it must not.

Test both directions before a hash is allowed to skip a write. Exclude code bodies, since both hashers collapse whitespace inside them. Choose the hasher by the body format you fetched rather than by the product. And record the skip in the plan, because an audit cannot tell a silent skip from an entity you never reached.

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.

Build your migration's gap list before you start, and make the differ refuse to guess

Mihai Perdum — Sat, 03 Oct 2026 20:42:03 +0000

Build your migration's gap list before you start, and make the differ refuse to guess

Key takeaways

END STATE: a list of what your migration will NOT carry, produced from your own inventory before day one, with partials called out separately.
Coverage is THREE-state, not two. Custom fields are copied by type; workflows only when linked to a project. A boolean set hides both.
Identical config names on two tenants are different entities. Remap on id, and refuse to map a name that is ambiguous at the destination.
The tooling appends '(migrated)' when it resolves a clash, so a name-keyed differ reports those as missing unless you normalise.
Different tools per path: JCMA for Jira and JSM, CCMA for Confluence, Data transfer for Cloud to Cloud.

Every Atlassian migration carries most of your data and leaves a remainder. The remainder is published, it differs per path, and almost nobody writes it down before starting.

This builds two artefacts from your own instance: a list of what the tool will not carry, and an id remap table that refuses to guess. The second one matters more than it sounds.

Prerequisites

Node 18 or later. Verified on v24.15.0.

Read access to your source instance, and to the destination if you have one.

An empty directory. Everything here runs offline — you export an inventory and diff it locally, so nothing writes to a tenant.

Know which path you are on, because the tools differ: Jira/JSM Data Center → Cloud uses the Jira Cloud Migration Assistant, Confluence Data Center → Cloud uses the separate Confluence Cloud Migration Assistant, and Cloud → Cloud uses Data transfer (the docs still carry its old name, Copy product data).

About forty minutes, most of it reading the copied-data page properly.

The insight that makes this worth doing

The obvious version of this exercise is a set difference: list what the tool copies, subtract it from what you have, and the remainder is your build.

That is wrong, and it is wrong in the direction that hurts. Atlassian's page does not say yes or no per kind. It says things like custom fields are copied — "Text, Date, Number, Time, Labels, URL, Select list…" — while "Project picker, Affected services, Responders" are not. It says "Workflows and permission schemes (that are not linked to any project won't be migrated)".

Those are partials. A boolean set filters them out as done, and you find out at cutover. So the coverage model here is three-state: carried, partial, not carried — and partials appear in the output as work, with the caveat attached.

I got this wrong myself. An earlier version of this used a boolean set, and its own worked example listed 19 dashboards as a rebuild — dashboards are copied. The tool was confidently inventing work.

Encode the copied-data page as a three-state coverage map for your path.
Export an inventory of your source instance by kind, as JSON.
Compute the gap list, with partials reported separately from outright gaps.
Diff the tenant-scoped config on id, normalising the "(migrated)" suffix.
Prove the differ exits non-zero on an ambiguous name.
Assign an owner to every line, which is what turns a list into scope.

Step 1 — Encode the page as three states

Open the current copied-data page for your path and read it properly. Save this as gaps.mjs:

export const CARRIED = "carried";
export const PARTIAL = "partial";
export const NOT_CARRIED = "not";

export const COVERAGE_C2C = {
  projects: CARRIED, spaces: CARRIED, users: CARRIED, groups: CARRIED,
  screens: CARRIED, "request-types": CARRIED, queues: CARRIED,
  "sla-calendars": CARRIED, "customer-organizations": CARRIED,
  dashboards: CARRIED, boards: CARRIED, filters: CARRIED,

  "custom-fields":      PARTIAL,  // named types only; project picker/responders excluded
  workflows:            PARTIAL,  // only when linked to a project
  "permission-schemes": PARTIAL,  // only when linked to a project
  "knowledge-bases":    PARTIAL,  // the link copies; article content needs its own handling

  "automation-rules":   NOT_CARRIED,
  "global-permissions": NOT_CARRIED,
  "app-data":           NOT_CARRIED,
};

That map is Cloud → Cloud. On the DC path, build the equivalent from your assistant's own "what gets migrated" page — JCMA's for Jira and JSM, CCMA's for Confluence. The members are different; the method is identical.

How you know it worked: count the states and confirm none is empty.

node -e "import('./gaps.mjs').then(m=>{const v=Object.values(m.COVERAGE_C2C);
  console.log('carried',v.filter(x=>x==='carried').length,
              'partial',v.filter(x=>x==='partial').length,
              'not',v.filter(x=>x==='not').length);})"

You should see all three counts above zero. A zero in partial means you read the page as a yes/no table, which is the mistake this whole step exists to prevent — go back and look for the words "some", "only", and any bracketed exclusion.

Step 2 — Export a source inventory

You need counts by kind. An array of identifiers or a plain number both work; anything else is refused rather than silently miscounted.

Save it as inv.json:

{
  "projects": 12,
  "workflows": 8,
  "custom-fields": 34,
  "automation-rules": 47,
  "global-permissions": 11,
  "app-data": 6,
  "dashboards": 19
}

Keep the kind names identical to your coverage map. The method is a lookup, and a spelling mismatch moves an item into the wrong bucket.

How you know it worked: find kinds your coverage map has never heard of.

node -e "import('./gaps.mjs').then(m=>{const inv=require('./inv.json');
  console.log('unknown kinds:', Object.keys(inv).filter(k=>!(k in m.COVERAGE_C2C)));})"

You should see unknown kinds: []. Anything listed there is either a spelling mismatch or a kind you have not classified yet — both are your problem to fix now, because gapList treats unknown kinds as work and will inflate your plan.

Step 3 — Compute the gap list

function countOf(kind, v) {
  if (Array.isArray(v)) return v.length;
  if (typeof v === "number" && Number.isFinite(v)) return v;
  throw new TypeError(`inventory["${kind}"] is ${typeof v}; give an array or a number`);
}

export function gapList(inventory, coverage = COVERAGE_C2C) {
  const out = [];
  for (const [kind, v] of Object.entries(inventory)) {
    const n = countOf(kind, v);
    if (n === 0) continue;
    const state = coverage[kind];
    if (state === CARRIED) continue;
    out.push({ kind, count: n, state: state || "unknown" });
  }
  return out.sort((a, b) => b.count - a.count);
}

countOf throws rather than returning zero. An earlier version quietly returned an empty gap list when handed counts instead of arrays — no error, no warning, and a plan that said there was nothing to do.

How you know it worked: confirm it refuses input it cannot count.

node -e "import('./gaps.mjs').then(m=>{try{m.gapList({projects:{a:1}});console.log('NO THROW — bug')}
  catch(e){console.log('refused:',e.message)}})"

You should see refused: inventory["projects"] is object; give an array or a number. If it prints NO THROW, the guard is missing and the tool will silently under-report.

Step 4 — Diff the config on id

Configuration is tenant-scoped: a priority named "P1" on each side is two objects with two ids. Anything you carry yourself — filters, boards, automation — references the id.

export const stripMigratedSuffix = (n) => String(n).replace(/\s*\(migrated\)\s*$/i, "");

export function idRemap(kind, source, dest) {
  const dupes = new Map();
  for (const d of dest) {
    const k = stripMigratedSuffix(d.name);
    dupes.set(k, (dupes.get(k) || 0) + 1);
  }
  const srcNames = new Set(source.map((s) => stripMigratedSuffix(s.name)));
  const ambiguous = [...dupes].filter(([n, c]) => c > 1 && srcNames.has(n)).map(([n]) => n);

  const byName = new Map();
  for (const d of dest) byName.set(stripMigratedSuffix(d.name), d);

  const remap = [], orphans = [], agreed = [];
  for (const s of source) {
    const n = stripMigratedSuffix(s.name);
    if (ambiguous.includes(n)) continue;              // refuse, do not guess
    const d = byName.get(n);
    if (!d) { orphans.push({ name: s.name, id: s.id }); continue; }
    if (String(d.id) === String(s.id)) agreed.push(n);
    else remap.push({ name: s.name, from: s.id, to: d.id });
  }
  return { kind, remap, orphans, agreed, ambiguous };
}

Two details that are not decoration.

The suffix. Migration tooling appends (migrated) when it resolves a name clash, so the destination ends up holding Custom field A and Custom field A (migrated). A differ matching raw names reports those as missing, which sends you creating objects that already exist. Normalise before matching.

Ambiguity never enters **`remap*`.* If two destination objects share a name, that name is excluded from the translation table entirely. A poisoned row in a table you intend to run is worse than an absent one.

How you know it worked: confirm the suffix is normalised.

node -e "import('./gaps.mjs').then(m=>{const r=m.idRemap('cf',
  [{id:'1',name:'Team'}],[{id:'99',name:'Team (migrated)'}]);
  console.log('orphans',r.orphans.length,'remap',r.remap.length);})"

You should see orphans 0 remap 1. If it prints orphans 1, the normalisation is not running and every clash the tool resolved will look like a missing object.

Step 5 — Prove it exits non-zero on ambiguity

A differ that warns and returns success will be consumed by something that ignores warnings. Make it fail. Save this as run.mjs:

import { readFileSync } from "node:fs";
import { gapList, idRemap, report } from "./gaps.mjs";

const inventory = JSON.parse(readFileSync("./inv.json", "utf8"));

const srcPri  = [{ id: "1", name: "P1" }, { id: "2", name: "P2" }, { id: "3", name: "Blocker" }];
const dstPri  = [{ id: "10001", name: "P1" }, { id: "2", name: "P2" }];
const srcLink = [{ id: "10000", name: "Blocks" }, { id: "10001", name: "Relates" }];
const dstLink = [{ id: "10100", name: "Blocks" },
                 { id: "10101", name: "Relates" }, { id: "10102", name: "Relates" }];

const remaps = [idRemap("priorities", srcPri, dstPri), idRemap("link types", srcLink, dstLink)];
console.log(report(gapList(inventory), remaps));

const ambiguous = remaps.reduce((n, r) => n + r.ambiguous.length, 0);
if (ambiguous) {
  console.log(`\nFAILED: ${ambiguous} ambiguous name(s). Resolve them before trusting this table.`);
  process.exit(1);
}

The report function is a printer — full source is in gaps.mjs at the end of this article's repo layout, and any formatting you prefer will do; what matters is that every remap row and every orphan is printed rather than truncated.

How you know it worked. Run it and check the exit code:

node run.mjs; echo "exit=$?"

Real output:

NOT CARRIED — you build these:
    47  automation-rules
    11  global-permissions
     6  app-data

PARTIAL — copied with documented exclusions, still check every one:
    34  custom-fields
     8  workflows

ID REMAP — identical names, different ids:
  priorities: 1 to remap, 1 already agree, 1 missing, 0 AMBIGUOUS
     "P1"  1 -> 10001
     "Blocker" (3)  MISSING at destination
  link types: 1 to remap, 0 already agree, 0 missing, 1 AMBIGUOUS
     "Blocks"  10000 -> 10100
     "Relates"  AMBIGUOUS — two destination objects share this name; REFUSED

FAILED: 1 ambiguous name(s). Resolve them before trusting this table.
exit=1

Three things to read there. Dashboards are absent from the gap list, because they are carried — the tool is not inventing work. Custom fields and workflows appear under PARTIAL, which is the whole reason for the three-state model. And "Relates" produced no mapping at all, with a non-zero exit.

Now remove the duplicate: delete { id: "10102", name: "Relates" } from dstLink and run again. You should get 0 AMBIGUOUS, a Relates remap row, no FAILED line, and exit=0. A check that cannot switch off is not testing anything.

Step 6 — Assign an owner to every line

The output is counts. Scope is counts with a name against each.

Forty-seven automation rules is not a task. "Priya rebuilds the 12 rules touching the release workflow before cutover, the other 35 after" is. Every orphan is a decision too — create it at the destination, map it elsewhere, or accept the loss — and each has a different owner.

How you know it worked: hand it to somebody who was not in the room. If they can say what they are responsible for without asking a question, it is scope. If they ask "so what do I do about app data", it is still a list.

What differs per path

Jira/JSM Data Center → Cloud (JCMA). It carries more than people expect, including dashboards, cross-project boards and filters, filter subscriptions, and automation flows. The remainder is mostly small in-project detail: custom field language translations, workflow properties and triggers, project avatars, canned responses, mail handlers, issue collectors, board sub-filters — plus global permissions and general configuration. Identity dominates the plan here for a different reason: username and userKey do not exist in Cloud, so every user reference resolves to an accountId.

Confluence Data Center → Cloud (CCMA). A different tool with a different list — global settings and permissions, application links, personal drafts, custom emojis, user-created macros and audit logs are among the things it leaves. Do not reuse the Jira map here.

Cloud → Cloud (Data transfer). Found at admin.atlassian.com → Data management → Data transfer → Create copy plan. It runs same-org or cross-org and gives you a plan with statuses to watch. Identity is smaller than on the DC path but not zero: group membership, permission changes on copied groups, blocklisted groups, users in inactive directories, and anyone who is not the same Atlassian account at the destination all need handling.

You now have a gap list that distinguishes what you build from what arrives partially finished, and a remap table that refuses to guess when two destination objects share a name — proven by a run that exits 1 and a second run that exits 0 once the duplicate is gone.

What this does not do is tell you whether the migration is a good idea, size the rebuild, or catch anything the copied-data page fails to mention. Re-read that page close to cutover. Everything here depends on it, and it moves — an earlier draft of this article was built on a stale reading of it and confidently listed carried objects as work.

More in our Atlassian Migrations collection.

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.

notifyUsers=false in Jira Cloud: four ways your test bed fakes a pass

Mihai Perdum — Sat, 03 Oct 2026 20:41:13 +0000

notifyUsers=false in Jira Cloud: four ways your test bed fakes a pass

Key takeaways

Before you trust any notification test, run POST /rest/api/3/issue/{key}/notify. A 403 means your tenant sends nothing and every suppression test you run will pass.
A company-managed project created over POST /rest/api/3/project has NO notification scheme unless you pass notificationScheme explicitly. I reproduced this across three templates and two project types.
user.notify.own.changes defaults to false, so a solo admin testing on their own issue gets no mail whichever route they use.
All four comment routes — including PUT /issue?notifyUsers=false — raise the comment event, never jira:issue_updated. Measured with a webhook on eight issues across two runs.
POST /issue/{key}/comment?notifyUsers=false returns 201 and silently drops the parameter. The comment endpoint has exactly two parameters and that is not one of them.

If you have ever had to backfill a comment onto a few thousand Jira work items, you already know the shape of the problem: the comment is the easy part, and the email storm is the part that gets you a meeting. I wrote up why sendNotifications: false does nothing when you paste it into an automation rule's exported JSON a few weeks ago. The short version is that it is not a parameter of that action, so nothing reads it.

That piece ended on a workaround I had not run. Atlassian publishes it themselves, on JRACLOUD-97682, and it is the thing everybody reaches for next: skip the comment endpoint, ride the comment in on the edit issue endpoint, which does accept notifyUsers=false.

So I built a test bed on a live Jira Cloud tenant and ran it. This tutorial is that bed, end to end — because the useful finding turned out not to be the workaround at all. It was that the bed lied to me four separate times, and every one of those lies looks exactly like success.

What Atlassian actually documents

Start from the primary source, not from a forum answer. I pulled the Jira Cloud platform OpenAPI document (developer.atlassian.com/cloud/jira/platform/swagger-v3.json, 3,618,606 bytes, fetched 24 August 2026) and read the three relevant operations out of it directly.

The add-comment endpoint takes exactly two parameters: issueIdOrKey and expand. That is the whole list. There is no notifyUsers, no sendNotifications, nothing. This is the machine-readable confirmation of the earlier article's conclusion.

The edit-issue endpoint's **`notifyUsers*`* reads, verbatim:**

Whether a notification email about the issue update is sent to all watchers. To disable the notification, administer Jira or administer project permissions are required. If the user doesn't have the necessary permission the request is ignored.

Read that carefully, because two clauses in it matter later. It promises to suppress mail "about the issue update" — it says nothing about the comment event. And a missing permission gets you ignored, never refused, so the call succeeds and the mail goes out anyway.

JRACLOUD-97682's own **`h3. Workaround**` gives the literal call:

curl --location --request PUT \
  'https://sitename.atlassian.net/rest/api/3/issue/ABC-1?notifyUsers=false' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Basic ...' \
  --data '{
    "update": {
      "comment": [
        { "add": { "body": { "type": "doc", "version": 1, "content": [
          { "type": "paragraph", "content": [
            { "type": "text", "text": "Comment added via the Edit issue API." }
          ]}
        ]}}}
      ]
    }
  }'

I re-read the three tracker items over the JAC REST API on 24 August 2026, because vote counts and statuses rot and the numbers in my own notes were already stale:

Ticket	Status	Votes	Watchers	Created
AUTO-602 — suppress in-product notifications from Automation	Gathering Interest	1,073	512	2020-04-29
JRACLOUD-97682 — add notifyUsers=false to the comments API	Gathering Interest	1	2	2026-03-04
JRACLOUD-78140 — implement notifyUsers on a number of API calls	Closed / Won't Do	9	6	2022-01-06

Two notes on citing these. AUTO-602 opens with the sentence you want — "Currently, we can only suppress Email notifications for the Edit Issue action performed by automation or Jira" — but its title and its request are about in-product and in-app notifications, so cite it for the limitation it states and not for the thing it asks for. And do not reach for JRACLOUD-78140 at all: it is Closed / Won't Do, and its description asks for notifyUsers on exactly four operations — "create issue, bulk create issue, assign issue, transition issue". Adding a comment is not one of them.

Building the bed

Everything below ran against a sanctioned test tenant over Basic auth with an API token, as a site admin. None of it belongs on a production site until you have read the whole article.

Create a throwaway company-managed project POST /rest/api/3/project with a projectTemplateKey, a leadAccountId, and — this is the part that matters — an explicit notificationScheme.
Confirm the project actually has a notification scheme GET /rest/api/3/project/{key}/notificationscheme. If this 404s, stop; nothing you measure afterwards means anything.
Put a recipient on the Issue Commented event whose mail you can actually read, using a recipient type Jira Cloud still supports.
Register a webhook on comment_created and jira:issue_updated, filtered to the project, so you can see which event each route raises.
Prove the tenant can send mail at all POST /rest/api/3/issue/{key}/notify. This is the control, and it is the step everyone skips.
Run each route on its own fresh work item, with a plain summary edit as the control route, then read the webhook capture and the mailbox.

Steps two, three and five each turned up a way to get a confident, wrong answer, and the tenant's own plan turned up a fourth. Here they are in the order they bit me.

False negative 1 — the project has no notification scheme

I created the project the obvious way, then asked it for its notification scheme:

GET /rest/api/3/project/NTFY/notificationscheme
404 {"errorMessages":["No notification scheme associated with this project."]}

A company-managed project, freshly created, with no notification scheme at all. Not an empty one — none. Nothing in that project will ever raise scheme-driven mail, so every suppression test I ran in it would have come back clean.

I did not want to guess at the cause, so I isolated it. Three different templates, across two project types:

Template	Project type	Scheme after create
gh-simplified-basic	software	none — 404
gh-simplified-scrum-classic	software	none — 404
gh-simplified-kanban-classic	software	none — 404
jira-core-simplified-process-control	business	none — 404

Then the same call with one field added:

{ "key": "NTX", "name": "…", "projectTypeKey": "software",
  "projectTemplateKey": "com.pyxis.greenhopper.jira:gh-simplified-basic",
  "leadAccountId": "…", "notificationScheme": 10000 }

That project came up with 10000 Default Notification Scheme attached. So it is not the template and not the project type — **POST /rest/api/3/project**** simply does not attach a default notification scheme unless you name one.** If you already have projects in this state, PUT /rest/api/3/project/{key} with {"notificationScheme": 10000} retro-fits it; that returned 200 and the project reported the scheme immediately.

This one has a life beyond test beds. If you provision projects over the API — and plenty of teams do, this is the same class of gap as automation rules not travelling with the projects they belong to — then the people in those projects are getting no notifications, and nobody files a ticket about email they never expected.

A 404 from GET /rest/api/3/project/{key}/notificationscheme is not a permissions problem and not an API version problem. It is the literal absence of a scheme. Check it on every project you provision over REST.

False negative 2 — you don't get mail for your own changes

The second trap is the cheapest to fall into, because the natural way to test this is to comment on an issue you are watching and see whether your own inbox lights up.

GET /rest/api/3/mypreferences?key=user.notify.own.changes
false

That is the default, and it is per-user. With it off, Jira will not mail you about actions you performed yourself — so a solo admin testing suppression on their own work item gets silence from the suppressed route and silence from the unsuppressed one, and concludes the suppression works.

You can flip it with a PUT to the same endpoint, but I would rather not test a notification path using the one account whose notifications are specially suppressed. I put a separate recipient on the scheme instead, which is what step three of the bed is for.

False negative 3 — the whole tenant has outgoing mail switched off

This is the one that would have taken the article out at the knees, and I only caught it because I ran a positive control before believing a negative.

My routes had all returned success. No mail had arrived. That is exactly the result "the workaround works" would produce. So before writing a word of it, I asked the tenant to send me an email it had no reason to refuse:

POST /rest/api/3/issue/NTFY-9/notify
{"subject":"positive control","textBody":"probe","to":{"users":[{"accountId":"…"}]}}

403 {"errorMessages":["Outgoing emails disabled."]}

Reproduced on three different work items. Atlassian's own OpenAPI document gives that status code exactly one meaning for this operation:

403 — Returned if: outgoing emails are disabled. no SMTP server is configured.

Those are two causes on paper and one in practice, because Atlassian's outgoing-mail page states that "In Jira Cloud, Outgoing Mail can only be enabled or disabled — there is no SMTP server to configure." On Cloud there is no second explanation available: a 403 here means the switch is off.

So the tenant sends nothing, at all, by any route. Every "no email arrived" result I had collected was worth precisely zero — and had I skipped this call, I would have published a confident measurement of a mechanism I had never once exercised. This is the same discipline that catches a Jira Cloud field quietly defaulting to a value nobody set: the absence of a symptom is not evidence until you have proved the instrument can produce one.

And the wrong control would have fooled me a second time. When I created the recipient account, an Atlassian invite email landed in the capture mailbox within a minute — proof, it looked like, that mail from this tenant reaches me. It is not. The same outgoing-mail page lists the exception: "Actions via **admin.atlassian.com (user invites, access requests, join notifications) — sent from a separate address." That mail proves the mailbox works. It says nothing about whether Jira will send a notification, because it did not come from Jira's notification path at all. A positive control has to exercise the same mechanism you are about to trust, not a neighbouring one that happens to be easier to trigger.

The setting itself is a site-level toggle. Atlassian's page for it carries a Cloud Only platform notice, puts it at ⚙️ Settings → System → Outgoing mail, and requires the Administer Jira global permission. Two sentences from it are worth memorising:

Disabling Outgoing Mail stops all notifications from jira@<domain>.atlassian.net. Notifications are not queued.

The Automation Send email action — still sends even with Outgoing Mail disabled (see AUTO-112).

That second one deserves a moment. If your plan for a risky backfill is "I'll flick outgoing mail off for an hour", it does not cover you: an automation rule with a Send email action will keep mailing people throughout. And because nothing is queued, the notifications you did want during that hour are gone rather than delayed.

Searching for how to disable outgoing mail over REST will hand you an Atlassian KB describing PUT /rest/jira-mail-plugin/1.0/outgoingMail/config. That article carries a Data Center Only platform notice. Atlassian's docs run as two parallel trees and the Data Center one frequently outranks the Cloud one — check the platform notice at the top of every page before you copy a path out of it.

I did not enable outgoing mail on this tenant to finish the measurement. It is a shared test site and I could not enumerate what else would have started sending the moment I flipped it — and an unknown blast radius is a reason not to proceed, not a reason to proceed carefully.

False negative 4 — the Free plan cap

The fourth one I did not measure directly, and I am labelling it as documented rather than tested. This tenant reports FREE for all three products, which I found the hard way when Jira refused a project role edit:

POST /rest/api/3/project/NTFY/role/10002
400 {"errorMessages":["You can't update role actors for this project as it's on the Jira Software Free plan."]}

Atlassian's notification documentation states the cap plainly:

Jira can send a maximum of 100 emails per day on the Free plan. After 100 emails, notifications are paused until the following day.

And, for anyone who upgrades to fix it: "it may take up to 30 days for this limit to be lifted." So a test run on a busy Free tenant late in the day sends nothing, silently, for reasons that have nothing to do with the thing you are testing — and a test run the following morning behaves differently. If you are testing notification behaviour on a Free sandbox, check the plan before you check anything else.

What the routes actually do

With the bed honest about what it could and could not tell me, here is what I measured. Four comment routes, plus two plain-summary-edit routes as controls, each on its own fresh work item, with a webhook capturing comment_created and jira:issue_updated.

Route	HTTP	Comment created	Webhook event raised	Changelog entry
A · POST /issue/{k}/comment	201	yes	comment_created	none
B · PUT /issue/{k}?notifyUsers=false	204	yes	comment_created	none
C · PUT /issue/{k} (no flag)	204	yes	comment_created	none
D · POST /issue/{k}/comment?notifyUsers=false	201	yes	comment_created	none
E · PUT /issue/{k}?notifyUsers=false (summary edit)	204	n/a	jira:issue_updated	yes
F · PUT /issue/{k} (summary edit, no flag)	204	n/a	jira:issue_updated	yes

Three things fall out of that table.

Riding a comment in on the edit endpoint does not turn it into an issue update. Routes B and C never raised jira:issue_updated — only comment_created. Routes E and F, which edit an actual field, raise jira:issue_updated and nothing else. I ran the comment routes twice, on eight separate work items, and got the same split both times; E and F are the control that proves the observer can tell the two apart.

That matters because notification schemes key on events, not on which endpoint you called. GET /rest/api/3/events returns the catalogue your schemes are built from; on this tenant it is id 1 Issue Created, 2 Issue Updated, 3 Issue Assigned, 4 Issue Resolved, 5 Issue Closed, 6 Issue Commented, 13 Generic Event and 14 Issue Comment Edited.

So the row governing all four comment routes is Issue Commented (6), not Issue Updated (2) — while notifyUsers is documented against "a notification email about the issue update". The workaround is asking a flag scoped to one event to suppress a different one.

**POST /comment?notifyUsers=false**** returns 201 and throws the parameter away.** No error, no warning, comment created. It is the same failure mode as sendNotifications: false in an automation export, one layer down: the parameter is accepted by the transport and never read by the operation. If you have this in a script and no email storm has happened yet, it is not because the flag is working.

None of the comment routes write a changelog entry. Convenient if you are backfilling and did not want to pollute issue history; inconvenient if you were relying on the history tab to audit what your script did.

Two limits worth knowing before you write the loop

You cannot batch. update.comment is a JSON array, which reads like an invitation to add several comments per call. Jira refuses:

PUT /rest/api/3/issue/{k}?notifyUsers=false
{"update":{"comment":[{"add":{…}},{"add":{…}}]}}

400 {"errors":{"comment":"Too many operations (2) provided for field 'comment'.
     We support at most 1 operation for this field."}}

One comment per call, so a four-hundred-comment backfill is four hundred calls whichever route you pick. On this tenant, over twenty sequential calls each, the edit route is about fifteen percent slower per call and about twenty percent slower over the run:

Route	Median	Range	20 calls	Extrapolated to 400
POST /issue/{k}/comment	352 ms	242–468 ms	7.1 s	≈ 2.4 min
PUT /issue/{k}?notifyUsers=false	403 ms	344–668 ms	8.6 s	≈ 2.9 min

Neither run hit a rate limit at that pace, but that is a single-threaded sequential loop on a quiet tenant and it is not a licence to fan out.

And the comment you get is indistinguishable. Reading both back over the API, route A and route B produce the same field set — author, body, created, id, jsdPublic, self, updateAuthor, updated — with the same author, the same jsdPublic: true and the same visibility: null. Nothing but the id and the timestamp separates them. So if the flag does work for you, nothing downstream will know how the comment arrived. That cuts both ways, which is a familiar shape for anyone who has pushed data into a Jira surface the public docs do not describe .

The lever that is certain

If you need a guarantee rather than a workaround, do not reach for a flag whose behaviour you cannot verify on your own tenant. Empty the Issue Commented row of the project's notification scheme for the duration of the backfill, then restore it. It is unglamorous, fully reversible, and it does not depend on undocumented behaviour.

One trap while you are in there. The old advice — add a single email address to the notification scheme so you can watch what fires — does not work on Cloud any more:

POST /rest/api/3/notificationscheme
{"notificationSchemeEvents":[{"event":{"id":"6"},
  "notifications":[{"notificationType":"EmailAddress","parameter":"me@example.com"}]}]}

400 {"errorMessages":["Recipient type EmailAddress is not supported."]}

I enumerated the whole set against the live API rather than trusting a doc page. These are accepted: CurrentAssignee, Reporter, CurrentUser, ProjectLead, ComponentLead, User, ProjectRole, AllWatchers. These are not: EmailAddress ("not supported") and IssueRole ("not found").

Group is accepted, and it has a trap in it that caught me while I was fact-checking this article. It wants the group name, and it rejects the group id — which is the opposite of the direction Jira Cloud has been moving in everywhere else. I tested three real groups both ways: the name returned 201 every time, and the corresponding groupId returned 400 "…is not a valid parameter" every time. I had written the reverse into this article from inference alone, and only caught it because I went back and ran it.

So to watch notifications land, you need a recipient that is a real account. Create one whose mailbox you can read, put it on the event as a User, and confirm it can browse the project — GET /rest/api/3/user/permission/search?accountId=…&permissions=BROWSE_PROJECTS&projectKey=… will tell you, and a recipient who cannot see the work item will not be mailed about it.

Prove the negative, don't observe it

The thread running through all four of these is one rule: a negative that authorises action has to be proved, not observed. A count of zero, an empty list, a quiet inbox — none of those license a conclusion until you have shown that the instrument can produce a non-zero on the same object.

We ended up encoding that rule into our own agent, which is the only reason I thought to run the notify call at all. goose , the local-model swarm fork we build on, had a live bug of exactly this shape: when every model alias was withdrawn because a node dropped off the LAN, the scheduler saw an empty served-model list, could not distinguish "nothing is servable" from "the probe is broken", and dispatched the whole run into a wall of 400s. The fix is a guard called all_resident_unservable in crates/goose-cli/src/commands/swarm.rs, and its whole design is this distinction: it refuses to start only when the endpoint returned a non-empty catalogue that contains none of the resident models — a proven zero. An empty or unreachable probe never refuses, because that is an observed zero and it means nothing. Its unit tests assert precisely that asymmetry.

POST /rest/api/3/issue/{key}/notify is the Jira equivalent, and it costs one call:

curl -u you@example.com:$TOKEN -X POST \
  -H 'Content-Type: application/json' \
  'https://your-site.atlassian.net/rest/api/3/issue/ABC-1/notify' \
  -d '{"subject":"control","textBody":"control","to":{"reporter":true}}'

204 means the tenant will send. 403 means it will not, and everything you were about to measure is void. Run it first, and run it again at the end.

One wrinkle to expect, because it will otherwise read as a failure: this endpoint also returns 400 when "the recipient is the same as the calling user". If you happen to be the reporter of the work item you picked, {"to":{"reporter":true}} gets you a 400 that has nothing to do with outgoing mail. Point it at a colleague's accountId, or pick a work item somebody else raised.

What I could not settle

I set out to answer one question — does notifyUsers=false on the edit-issue endpoint actually suppress the Issue Commented email — and I cannot answer it. The tenant I have admin on cannot send mail, and I was not willing to switch site-wide outgoing mail on to find out.

So, keeping the three registers apart:

Documented. notifyUsers suppresses "a notification email about the issue update", requires Administer Jira or Administer Projects, and is ignored rather than refused without them. The add-comment endpoint has no equivalent parameter. Atlassian publishes the edit-issue route as the workaround on JRACLOUD-97682.

Measured, here, on 24 August 2026. Everything in the tables above: the routes, the events, the latencies, the one-operation limit, the identical comment representation, the missing notification schemes, the unsupported recipient types, the user.notify.own.changes default, and the 403.

Still a guess. Whether the flag reaches the Issue Commented event. The webhook evidence says that event is what gets raised, and the parameter is documented against a different one — which makes me sceptical rather than certain. If you have a tenant with outgoing mail on, the bed above will settle it in about ten minutes, and I would genuinely like to know.

Whatever you find, do not find it the way I nearly did. Run the control first.

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.