Re-indenting a scopes list empties the regex check meant to catch a Forge major bump

A scope check written as a regex is anchored to the line shape the author's own manifest happens to use ^[1]. Change the indentation of the scopes list and the pattern stops matching, so the extractor returns an empty set for both manifests, nothing appears as added, and the comparison reports a minor ^[20]. The author describes the failure direction plainly: re-indent the list and every scope vanishes, so a real new scope is reported as minor ^[4].

Size does not decide the bump. Atlassian's versions documentation says "Not all permission changes trigger a major version upgrade. Only changes that require user consent, such as OAuth scopes and Atlassian app permissions, result in a major version change." ^[13] In the author's words, a workflow engine can be a minor and one line of YAML cannot ^[23].

Nine triggers sit on the versions page, remotes and customer-managed egress are documented away from it, and the llm module reference carries its own ^[2]. Enumerating them is a separate problem from parsing them. The first version of the predictor knew six ^[10], which leaves five of the eleven invisible however well it parses ^[19]. So the tool meant to replace guesswork was guessing ^[24]. For eleven to be the complete list for your app, no module you depend on can document a twelfth in its own reference page.

Atlassian's llm module reference says that adding the llm module to your manifest will trigger a major version upgrade ^[9]. Two independent triggers therefore fired on that release, the new scope and the module, and either would have forced 4.0.0 by itself ^[3].

Atlassian's documentation says that by default major version upgrades are not applied to an app installation immediately, because major versions involve significant changes that may require users and admins to re-consent or review the changes before continuing ^[11]. What a major costs depends on whether it escalates privilege. A new scope escalates privilege, and a change that does not can often be pushed with bulk-upgrade ^[22]. Rolling releases let you ship code while admins approve permissions separately ^[14].

Adoption costs little: the analysis is a diff of two files, so it runs offline with no Forge app, no deploy and no tunnel ^[16]. It wants Node 18 or later, verified on v24.15.0 ^[15], two copies of manifest.yml pulled with git show, and about forty minutes ^[17]. @forge/cli is optional, for confirming a prediction against a real deploy ^[18].